Category: management

External provider

Posted on asdasd asdasdLeave a commentPosted in management

When do you use external service provider? I tried following:

  • To provide commodity infrastructure services - in progress, think will work
  • Commercial offerings without mixing in people from your company (defined scope and budget) - failed
  • Fast experiments to validate options (no integration with platform, no involvement of internal people) - success
  • Commercial offerings with heavily involving teams from your company (not fixing scope, but only cooperation period) - success
  • Bringing in industry accepted expert for knowledge sharing, problem solving, review (short-term: up to 2 weeks) - success

Work-to-rule

Posted on asdasd asdasdLeave a commentPosted in management

When you start defining too many rules. Be aware that people might start working according them!

Work-to-rule is an industrial action in which employees are entitled to do no more than the minimum required by the rules of their contract, and precisely follow all safety or other regulations, which may cause a slowdown or decrease in productivity, as they are no longer working during breaks or during unpaid extended hours and weekends (checking email, for instance).[1][2]Such an action is considered less disruptive than a strike or lockout; and obeying the rules is less susceptible to disciplinary action. Notable examples have included nurses refusing to answer telephones, teachers refusing to work for free at night and during weekends and holidays, and police officers refusing to issue citations. Refusal to work overtime, travel on duty, or sign up to other tasks requiring employee assent are other manifestations of using work-to-rule as industrial action.

APIs are important part of (network) organization

Posted on asdasd asdasdLeave a commentPosted in management

As network organization is evolutionary and must be constantly adjusted to actual value being delivered you must have evolutionary architecture. Both approaches are aimed to decompose “Big Ball of Mud …”

Even though i think it is essential for network organisation company structured in any way will benefit from this type of product architecture.

You can read more about that in this great article - https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture

Microservices meet this definition because of its strong bounded context principle, making the logical division described in Evan’s Domain Driven Design a physical separation. Microservices achieve this separation via advanced DevOps practices like machine provisioning, testing, and automated deployments. Because each service is decoupled from all other services (at the structural level), replacing one microservice with another resembles swapping one Lego brick for another.

Silos

Posted on asdasd asdasdLeave a commentPosted in management

“resources are often divided into silos despite the fact that virtually everyone working in the field acknowledges that solving the problem requires cross-discipline collaboration.”

Quote from the book - Liberating structures

Why do we still divide organization into functional siloses?

Network organization in a nutshell

Posted on asdasd asdasdLeave a commentPosted in management

Important

  1. Build multi-functional team.
  2. Pick up the problem/challenge/value.
  3. Define whom it’s important for.
  4. Define dependencies.
  5. Define success/failure criteria.
  6. Slice it.
  7. Prepare.
  8. Make.
  9. Give it to the world.
  10. Retrieve & analyze feedback.
  11. Keep #6, #7, #8, #9, #10 - cycle short.

Depends (not important)

  • Process you use - less is more. underestimated cost of spreading heavyweight process accross users.
  • Tools you use - bottom up standardization normally works much better. but would be interesting to make an investigation how/if tools standardization really helps.
  • Planning - as lots of work is invested into making a plan, people try to a void changing it to match the reality.
  • Various definition and templates - often do not match real work even before being issued.
  • Roles descriptions - typically defined for people below high level management.

p.s. Tayloristic organisation defines “not important” as highly important