Dave wants to set up and run a successful company, Dave’s Waterfalls Ltd. He’s got the drive and ambition to go right to the top, a master at the art of designing beautiful water features.
He has some early successes selling initially to the public, then starting to get larger orders from garden centres and water feature stockists.Time to expand his revenue stream into a river.
Dave employs more people, ramps up production, and starts to pump out water features in bulk. A board of directors and management team are assembled, who are put in place to run the company.
Falling uphill
He then decides to set up three new companies focusing on changes to the pumps, improving the realism of the rocks, and making sure the water features comply to the latest regulations (the amount of regulation needed when combining water and electricity can be shocking).
Each company has different management teams, reporting lines and governance. Once these companies conclude their designs, updates and findings, they spend a week telling staff at Dave’s Waterfalls Ltd what to do with the pumps, rocks and regs. Dave then disbands the three companies and then sets up three more, this time to focus on next year’s improvements, filters, lights and European expansion.
Why would Dave do this? Is it a tax dodge? No, it’s because he used to work in technology for a large financial services company, and that’s how they used to build software. One team to build it, another to support it.
In some cases, it makes a lot of sense to separate production with operations. If you are manufacturing waterfalls it involves a totally different skillset to distribute and support it than to make it, so it makes sense to organise teams this way.
Flow state
Software isn’t like that. To best support it, you need to know how it is made; to develop it effectively, you need to know how it is used. Software delivery can be as complex as running a company, and needs high degrees of connectivity between those who design, build and operate in order to achieve long term success.
- The downsides of transient project team working:
· Management and governance overheads and inefficiencies (due to multiple management teams, structures and reporting lines)
· Conflicting priorities driving bad decision making and behaviour (deliver it quick versus make it maintainable)
· Short-term vs. long-term mentality
· High level of communications needed across silos (and rarely ever seen)
· Trust and effective team practices lost every time you disband and reform
· Design decisions made based on knowledge and skillset of the development team, not what would be best to maintain and evolve
- The benefits of long lived product teams:
· Continuity of ownership and vision of the product
· Fully cross functional teams that work effectively together
· Efficient knowledge sharing, visibility and ownership of technical debt
· Employee retention driven by the longevity of the product, without the need to invent people’s roles every 12 months
· More conducive to developing a continuous improvement mindset
All this speaks to treating software delivery like the process of running the company, not like making and shipping the waterfalls it sells.
Delivering software is a complex and involved process where the inherent value of the company is more in the talent and interactions of the company than the product it ships.
Long-lived product teams or transient project teams. If you were Dave, which would you choose for your company?
Product teams over project teams; this is just one of the variables we think could be used to influence the success of software delivery, which we are measuring in our Adaptive Enterprise Study.
Join us to find out more: take the 2017 Catalyst Adaptive Enterprise Study here.
Note: This opinion piece was first published by Catalyst prior to the Davies merger
