This document is part of a series of posts which I started in December 2020 to remind myself of experiences and best practices as agile cloud software product owner and manager. I’ll be extending and updating it over time so I would be keen to get your feedback. What are the questions puzzling you?
- Why is balancing desirable, feasible and viable key?
- What is the difference between custom- and standard-software development?
- Why does simplicity take more time?
- Why are organizational debts even worse than requirements gaps or technical debts?
- What are the skills for an enterprise software product manager?
- How to find the right perspective and how to focus on the right requirements?
- How to define & manage a roadmap and convert it into a backlog?
Many organizations struggle and fail due to the innovator’s dilemma. They miss the time to invest into their future because of being so busy earning money and maintaining existing products. The reasons for this to happen are manifold and also good ideas how to avoid it float around. Looking on software companies I would like to add another reason which is blocking break-thru innovation which is:
Organizational debt
- Agile software development as the de facto standard for team collaboration has lots of challenges especially in big and deep nested development organizations. Often it is misunderstood (or misused) by management as the silver bullet which makes every dream possible.
- The line organizations (i.e. the team as per org model) often have conflicts with the virtual product organization (i.e. product owners, product managers, scrum masters etc.) which interacts with the line in a matrix setup.
- Both the line and the product organization have an inherent risk for “diffusion of responsibility” which leads to low quality and blurry customer value being delivered.
- In contrast to organizational debts, product requirement and technical debts are surfacing rather quickly. Organizational debts tend to be harder to spot and therefore being ignored for way longer.
- High amount of cross team dependencies and the resulting deadlocks between teams
- Lack of end-to-end ownership and therefore bad quality and low customer value being delivered
- More people talking long about what might be done than people actually having time to do the work e.g. coding or implementing
Silo vs. layer vs. matrix
Reasons for those complaints might be that line organizations are rather stable and cannot as quickly be changed as the market might require it. Line organizations are eco-systems which need a solid foundation and also constant inflow of ideas and people to stay healthy. People have relations which take time to be setup and maintained. In contrast to the line the product organization is often virtual and meant to change quickly to adapt to market needs. It is meant to react fast and being fluid and flexible. Product teams care for the health of products, happiness of customers, and market success and less about the teams or the people.
So line and product organizations often have conflicting priorities but need to harmonize as they depend on each other. The line manager has to care for and to keep his eco-system and team healthy. The product owners, product managers, scrum masters, architects etc. focus on the product first.
Top-down vs. bottom-up / Talkers vs. Doers
In the software industry there is often a huge divide between the talkers (which are often on the top e.g. managers & owners) and doers (which are often on the bottom e.g. coders) in the team. Therefore balance, ratio and right mixture of people is key, in a good and healthy development team. The top of the organization needs to listen to bottom and the bottom needs to understand top. Its hard to keep that eco-system healthy but its even harder to heal a system which has become toxic or to change an established organization which only has the capacity left for keeping the lights on but not to invent new ways of sheding light.
There is no meaningful way to define a target from top and push it down to the whole development organization. Reliable plans are build by having two-way conversation top-down, bottom-up, top-down, bottom-up .....and so on.
Visions, Strategies and Targets come from the top and are often broad and blurry. To formulate those ideas and goals is easy but its hard to make actionable and to keep the direction.
Detail knowledge is on the bottom but it is distributed in layers and silos which we call our line organization. The line organization is usually very old and does not follow nor fit to the dynamics of the market or strategy changes. That’s why potential targets easily communicated but way harder to make actionable and to agree on the action across the organization.
There is also no meaningful way how software concepts and designs can be defined top-down and thrown over the fence to someone to execute on it.
Good concepts and designs incorporate input and feedback loops from both directions: top-down, from the product management vision to the developer AND bottom-up from the developers to the product manager. Only the interplay between product management, product owners, developers, architects, customers and partners ensure good designs and finally deliver good software.
…to be continued
While you are are giving me feedback and propose topics, questions and links to be added here are a couple of links which inspired me. Looking forward to hearing from you either if you like my thoughts or not – as Lenny Leonard said “Everybody makes mistakes. That’s why they put erasers on pencils” ;o)
Message from Christian Klein
The life of a product manager in GIFs
Not having a plan is not agile
You can’t connect the dots looking forward; you can only connect them looking backwards.
We seek, not to know the answers…but to understand the questions
- SAP Managed Tags:
