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.
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.
Often notice that people tend to be “black and white” when talking about practices in any field, let it be management, design, development or whatever… e.g. go completely scientific and measure everything and be very structured or become completely ad-hoc and reactive.
Of course it’s an option to work in a binary way, but in my opinion it is not necessarily the best way to go while facing complex problem. You must have various “tools” in your toolbox and be creative in applying them depending on a situation or context.
So, can design be a science? Sometimes yes, sometimes no. Can it be empirically based, evidence driven? Yes. Will it have to reply on intuition and the creativity of individual designers? Sometimes, yes.
Imagine what would happen if the end of the Month would be treated as the end of the Year? What if most common end of year activities would happen monthly? Would it be better place to work? What do you think would change in your team or company? Here are some of them
Evaluating what was good and what was bad during a year
Planning (dreaming) ahead
Thinking about improvements and changes (either personal or work related)
There are tons of books where you can read about power of questions – how they are important, how they can help. Questions are powerful for following reasons:
give us valuable information
put us in control
get people to open up
lead to quality listening
get people to sell themselves
Questions also allow you to challenge the status quo and challenge the team. That’s why it is so widely used in Retrospectives by Scrum Masters.
Judge a man by his questions rather than his answers. ~ Voltaire
But wait… But should you really question everything? Isn’t there a risk to reach highest level of absurd? “Asking Questions” is the most powerful tool to encourage, challenge and affect people. Be careful!
How are these principles applied in your company? Do you have modern management system? Let me know if you want to discuss this more or have any practical hints how to move that direction in the company with more than 5 people.
Orientation towards client – teams are seeking highest clients satisfaction level rather than achievement of fixed targets from the top management
Responsibility – not central hierarchical units, but small network units are responsible for the results
Effective environment – environment where team’s success is measured according market success, instead of internal fixed targets achievement
Actions freedom – decentralized teams, which are directly working with clients, have all freedom to make decisions and take actions
Management style – everything is managed based on clear and understandable values and boundaries instead of rules and fixed budgets
Transparency – important information is easily accessible to everybody
Targets setting – making challenging flexible targets, oriented towards continuous relative improvement instead of fixed targets defined for a year. You can call it a direction.
Bonuses and awards – evaluation of overall success and rewarding based on relative improvement instead of rewarding for certain achievements, fixed targets
Planning – collaborative continuous activity that is oriented towards actions, no separation between thinkers and doers.
Control – control is performed based on relative metrics compared with market trends/other teams/previous periods instead of comparing deviations between planned and actual results
Resources – resources are provided on demand without upfront planning and budgeting
Adjustments – adjustments are made as reactions to market changes or new demand, instead of agreed planning cycles or hierarchical coordination