Identifying a real need or problem to solve is core to a successful product or application. Many teams get distracted along the way resulting in feature bloat or trying to address requests or perceived needs of prospects and customers that may end up in an unmanageable codebase, that may have many forks or custom derivatives.
From my experience and also what I have seen other organizations and teams manage this effectively is through a combination of an effective organization structure combined with good practices for planning and execution.
In designing organization structures, what works best is to stick to the basics of effective teams. Every team and organization wants to achieve great, sustainable performance. The engine to realize this dream is an intrinsic drive or motivation.
Daniel H Pink, in his book Drive, The surprising thing about what motivates us, talks of three elements – Autonomy, Mastery and Purpose.
These are directly applicable to creating and nurturing great teams and organizations.
In the context of Products and Solutions, the Product Vision sets out the purpose that would cover aspects of why are we in this business or why do we want to develop this solution. Sometimes, this could also include higher social purposes.
In order to realize this purpose, a supporting scaffolding or infrastructure must be created. This would include the technical architecture, technology components or stack chosen as well as the capability and capacity to be able to quickly build further on.
This would also influence and define the functional and technical features of the solution.
The product vision is expressed in terms of the features and the underlying architecture.
Once we have the features, as conceived and elaborated pretty much inside out, the success will greatly depend on the user experience. With the goals clear and a supporting infrastructure, teams would be free to experiment and follow a build, measure and learn cycle. This will mean that teams will have not only the capability but also the freedom to innovate, explore alternatives, assess relative impact of alternatives and move ahead steadily.
The above pattern can be seen in different manifestations:
Product management layers of planning and execution:
- The Product Management team sets the product vision and creates a roadmap, aligned to this North Star
- The roadmap would have priorities, dependencies and the rationale of what is needed and why
- In the classic format of a story articulation, the ‘so that …’ provides the why
- That is, in effect, the Purpose
- Engineering management as well as technical support teams or shared teams that become enablers for the development infrastructure [the CM/Release management or DevOps teams] to define the capacity and capabilities of what can be taken up
- This is the Mastery aspect – about being good and getting better always in all responsibilities taken up
- The self managed or self organized teams have the freedom to experiment, explore and learn and improve continually
- That exhibits the Autonomy aspect
The above are ingrained in Agile ways of working.
On a related thought, one of the frequent comments I hear, after an initial exposure to the Spotify model is – oh! It is a matrix model.
While it may appear that way when you look at Tribes [btw, many organizations have started using alternative terms] and Chapters – it is but natural to see that as verticals and horizontals – and hence, a matrix.
This is also reinforced by the structures that have a reporting line that is more direct when viewed horizontally and somewhat indirect, when viewed vertically
But, the way I internalized the spotify model in spirit is that the Tribe is there to set the purpose and define the guardrails to ensure that the organization moves in the intended direction.
The chapters’ primary responsibility is to enable and ensure Mastery. This may be achieved through training, mentoring, peer learning etc. Additional practices such as [peer] reviews and technical practices of architectural governance could also be under the chapter’s responsibility.
Such practices and guidelines help in implementing the guardrails in a structured manner.
With the Purpose set and Mastery facilitated, teams can function with greater Autonomy. The principles and practices that emphasize on close working, such as hypothesis testing, MVP approaches of Build-Measure-Learn loops, A/B testing are made easier for teams to adopt, when they have the autonomy to not only experiment, but also take ownership of the outcomes.
There you have – Autonomy, Mastery and Purpose being given their deserved positions in an organization integrated into their daily ways of working in a natural manner.
What do you think? Where do you see maximum challenges in this approach?
