“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
(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
How Guild works:
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
Main Principles of Work
- Sell, not control
- Pull, not push
- Be valuable
- Be transparent
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.
Watching objectified film generated lots of insights for myself about product design – https://youtu.be/HlT611TFJvk
People are talking about physical objects, but lots of good things can be applied to software development either.
Here is the definition of a Good design provided by Dieter Rams:
- must be innovative
- must make product useful
- is aesthetic design
- will make product understandable
- is honest
- is unobtrusive
- is long-lived
- is consistent in every detail
- is environmentally friendly
- is as little design as possible
Also during a film you notice such repetitive behaviour of those who design products:
- how much time they spend on prove of concepts, so it would be possible make changes easier and cheaper, try things out and gather feedback
- keep asking the question if this is going to solve the problem of the user
- desire to design things that get better with use
- desire to create products that reflect users behaviour, not trying to change it
- desire to understand users context. getting out of the room concept