Experience shows that approaches that worked for Scale A will not work for Scale B and you need to change practices you apply, way to organise work, communicate and etc.
You might say it’s obvious, but somehow everybody still tends to stick to what they know and do not challenge themselves.
The need for a change as you grow pretty well described in the video -
Successful guys also confirm that to get from point A to point B you need to start preparing for a shift. The better you prepare and understand this more successful you are.
Following things must change in order to succeed as you grow:
- how you work with people: generalists vs specialists, on-boarding
- how you work with product: market fit, competitors, ..
- how you approach technical platform: from monolith to micro-services
- how you find balance between adaptation and excellence in operations and tech
And one thing remains constant - innovation. i understand this in a way that you always have to experiment to find best ways to tackle the challenge in your context as there are no such things as right and wrong.
“Where simplifications fail, causing most damage, is when something nonlinear is simplified with the linear as a substitute.” (from the book - http://www.amazon.com/Antifragile-Things-That-Disorder-Incerto/dp/0812979680)
That’s why project management, scientific management, planning 5 years ahead and similar things should be used as a tool at maximum, not way of thinking. Thinking should be based on principles (e.g. 12 principles of new organization), which are reviewed based on the current context.
1. Conduct Guild days on a weekly basis across whole product development organisation. Agenda and format is random and should be always adapted to the context: conferences, trainings, watching conference, workshops, contribution into shared services… Guild leader is completely responsible for running it.
2. Guild leader is fully dedicated for that job and he is an expert in the field
3. Guild core members naturally migrate from existing teams or hired externally. Core team members are working full-time on horizontal activities and shared services. Rest of community participate part-time or during guild days and are part of the feedback loop
4. Guild leader has all financial and organizational tools to achieve required engagement in activities of the community: prizes, bounty program, direct contact with business and technical leaders and more
5. Guild leader and core team actively involve others into guild work and tasks through constantly sharing information with community, solving problems, being transparent
6. Teams are guaranteed to get support from Guild if they use services and output of the community, but if quality of services is low teams are not obliged to use crap they can always take the risk and responsibility to do things on their own
Challenges of horizontal community:
Strong guild leader with enough practical knowledge and experience
Build motivated core team who has the same passion for the topic
Defined end state and path of achievable mid-targets (desire to skip some steps in evolution might lead to some losses in long-term)
Dedicated days for all development to participate in guild days
Setup out of the box services and tools that can be used by the teams
Is it possible to build an organisation which benefits from uncertainty, errors and randomness?
How small should be the teams?
What should be minimum process?
What is the level of centralisation/decentralisation?
How often achieved agreements must be reviewed?
What behaviour is needed?
What is the ratio between explicit and self-discipline?
What is the level of autonomy?
Can growth be the target?
Should it reflect value delivery?
Should org. look different depending on the context?
Should unstable be new stable?
Those are curse words for any member in a company. Often companies are designed as if for any non-repetitive task it is exactly known what is going to happen and what is the most efficient way to do that.
We always want to know future especially when it’s related to delivery of complex software projects. I personally failed in making plans almost always in my career, but improved myself in planning: setting boundaries, watching trends, adjusting often, planning very little ahead, changing direction completely and more…
Also realised that creating too much overhead in formalizing plans and decision making slows you down and reduces motivation in making changes in the plan. We need to change fast and often (at least in certain types of activities) for the following reasons:
imperfect, incomplete knowledge
variety of outcomes
simplification of activities
Probably any person who wants to have a very good plan
must have some checklist with things mentioned above which helps to evaluate context. And the more “yes” you have for you context than less formalised plan you should have, adjust it often and shift faster towards network organisation.