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).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.
You do something valuable if your clients perceive following:
- A problem of theirs is solved or minimized
- An opportunity they desire is seized, maximized or enabled
- That they are happy
What (if any) is missing in such description? POD_framework_0.3 updated.
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.
“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?
- Build multi-functional team.
- Pick up the problem/challenge/value.
- Define whom it’s important for.
- Define dependencies.
- Define success/failure criteria.
- Slice it.
- Give it to the world.
- Retrieve & analyze feedback.
- 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