In part 1 of this 2-part blog series, we explore why many of the enterprises Dell Technologies work with are starting an organisational shift towards emulating the velocity and innovation achieved by the product teams of epic start-up successes and disruptor giants.
When we try to replicate these best practices in an enterprise, some questions emerge, especially around people and their roles in the new model and it’s not always obvious or simple to answer them. The following concerns are by no means exhaustive, but are often the most common:
What is the role of a SME and who decides how to resource a product team?- How do we recruit and/or manage scarce skills and how realistic is it to have these skills represented in a Product Team long term when these skills are already in short supply?
- Do product teams stay static in their structure? Do people really want to stay in product teams long term?
- How do you balance the work long term in a product team if not everyone can do everything?
- What happens to operational functions like RM, line management, and the PMO in this brave new world?
- Can an enterprise product team aspire to “own” their products?
To try and answer these questions, it’s worth considering some of the fundamentals about what a product team is expected to do in the long term. Product teams are meant to create the product, evolve the product and support it (soup to nuts). They are effectively meant to own the product. It’s a fantastic model in theory because it means that these teams have complete autonomy, silos which slow down product deployment disappear, and each team is working to achieve the same goal – a successful functioning product that adds value to its consumer.
The Nature of the Product Lifecycle
At the core of the product lifecycle model is a concept of continuous improvement and product evolution; however, the reality is somewhat different. The pace of product evolution slows down over time. There is an initial burst of change as we experiment through iterative MVPs but at some point, the product starts to stabilize and there is a shift in work type from build to support.
If you think about the disruptor companies we aspire to emulate – Netflix, Spotify, Dropbox, Uber – the core functionality of their respective products have stabilized and the amount of change we see is far less than the initial few product releases which changed our world. The reason for this is simple. The painful customer journeys that provided the initial opportunities for disruption have already been massively improved and so future iterations is icing on the cake. The natural lifecycle of a product is to evolve fast and then slow down. We still build new stuff, but we build less and focus on optimising more on what we have, for a while at least.
If you think about what this philosophy means under the hood and what kind of impact it has on the work that makes up the product team’s backlog, there will be a fundamental shift over time which reflects this slower evolution. The backlog will move from being mostly creative to mostly supportive and the mix of skills needed to implement the backlog will naturally shift to keep up.
Ah well, that’s fine, we say. We have cross-functional product teams that can do anything! This perspective, however, doesn’t take into account the various motivations and talents of each person on the team.
Creative Problem Solvers Don’t Like Babysitting Their Code Long Term
One of the reasons why enterprise IT organisation structures have evolved the way they have is because they mirror the way people tick. Some people love making new stuff, some people like to find amazing ways of optimising and tuning existing stuff. Natural communities start appearing, based on what people like to do.
So why do we hear repeatedly that product teams are the secret sauce to success? Because the magic happens in these natural communities, which form very specific environments.
The product team model has been borrowed not only from significant disruptions but startups. Modern enterprises are trying to replicate the success of the likes of Spotify by copying what they do. Sensible, but only if you copy everything. Product teams in start-ups are made up of people that tend to have significant skin in the game and will suck up what they see as “toil” for the sake of their stake (reward) in the company. Everyone will do a bit of everything because if they don’t, the company goes out of business.
Product Teams in Enterprises Do Not Actually “Own” Their Products
The problem is this culture does not exist in enterprises. An enterprise’s product teams can attempt to spin off mini-businesses and aim to reap huge rewards on the success of the products they’re working on but will most likely find themselves out of a job because the startup model can’t be replicated. Moreover, if you “force” individuals to stay in a product team long term and they don’t like the work they’re doing or earning the type of risk/reward akin to the startup culture, they will become unsatisfied, not perform well and eventually leave.
But don’t dismay!
Enterprises can better emulate the disruptor/start up model by employing one of these two approaches:
- Completely overhaul the way the product team is compensated within a risk/reward framework. This approach requires a massive change; however, it imparts a feeling of product ownership and the motivation to achieve excellence.
- Advocate and support people moving or sharing their time between product teams. We must acknowledge that without similar start-up risk/rewards, product teams will NOT be static in an enterprise. If we embrace this idea and put in a structure that supports this movement, we may be able to get the best of both worlds.
Many enterprises today are not ready for the first approach, but the second is more realistic and taking place at Dell Technologies Consulting. Through advocating and supporting fluidity in product teams, we are fostering autonomy and self-organisation and hiring people that will not respond well to command-control (thereby staying with the same product team just because RM or PMO tell them to). We are breaking down the silos as we have already done to the Dev and Ops teams.
The building blocks of this approach already exist in most enterprises. The stakeholders – RM, PMO, HR, Enablement – are just not yet in tune with the risk/reward product team philosophy.
Summary
In the next blog in this series, we’ll discuss how you go about breaking down the silos in the support organisation which has proven successful with Dev and Ops teams, and creating cross-functional “people teams” whose sole purpose is to ensure every product team is resourced with the right people, at the right time but most importantly, providing everyone in that product team with choice and supported autonomy over their own destiny.
For more information on transitioning from traditional matrixed organization models to product development teams, see this recently whitepaper.
If your team would like help with getting started in transitioning from traditional matrixed organization models to product development teams, please visit Dell Technologies DevOps Transformation Services or reach out to your Dell Technologies Consulting representative.
