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.
Stumbled upon couple of terms related to negotiations. Adding to my good stuff library and sharing it with you.
IMHO, very interesting concepts which can help to keep discussions constructive and encourage to for win/win situation.
I. Find common ground and red lines
“Indaba” (pronounced IN-DAR-BAH), and is used to simplify discussions between many parties.
An indaba is designed to allow every party to voice its opinion, but still arrive at a consensus quickly. It works because opinions and arguments can only be aired in a particular way:
Instead of repeating stated positions, each party is encouraged to speak personally and state their “red lines,” which are thresholds that they don’t want to cross.
But while telling others their hard limits, they are also asked to provide solutions to find a common ground.
II. Everyone must understand value of the agreement if consequences if it’s not reached.
“Nbatana” stands for “next best alternative to a negotiated agreement”. This means that everybody should be aware of what they will be left with if no agreement is reached; this helps them to understand the value of agreement, and correspondingly how much it is worth compromising before reaching the point where agreement costs you more than not reaching agreement.
p.s. if you know more these kind of hints please share them, would love to explore more on the topic as didn’t find anything more about this easily
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
When all decision making goes only via “Path I” _green_ people a) become a bottleneck b) don’t know details, so either have to trust or c) start asking questions to understand by delaying things even more.
Is it possible to leverage the power of “Path II” and make things faster? Set expectations, provide success criteria, boundaries (time, $, KPIs), principles, identify potential lack of knowledge and start delegating. More control is needed at the start and less when you see that things are working out well.