Looking at how product development teams are ideally structured in lean startup organisations, offers a useful framework for how to think about structuring operations in preparation for market scaling. Lean and agile modes of development can be adapted to support operational efficiency with maximum customer impact.
Fat Product Development
In my early career I carved out a niche for myself as someone who could understand and be understood both by teams of commercially-minded individuals and by developers. I had studied humanities but also learned to code. My first roles were in large organisations where teams were segmented granularly by function. In such environments where there were significant hand-offs, mis-communications and frustrations; acting as a go-between or honest broker was an invaluable role. What I increasingly learned however, was not so much that I had a unique and important skillset, but that the way these organisations structured themselves resulted in the individuals within those many discreet teams not being allowed to function at their optimum.
In product development speak, these teams were organised ‘horizontally’, by function or component. Specialists were put together within teams with a narrow focus. All the coders sat together, the database analysts somewhere else and “the business” in a different part of the building or in a different building or country altogether. It was believed that by putting like-minded people together that they would help each other improve in their specific skills. This benefit does of course accrue. Highly specialised people are a significant asset in any organisation, however they can also become bottlenecks. Compound that with the additional problem that the further apart individuals who are responsible for delivering a single customer feature are located from each other, the more delays and the less happy everyone becomes with the final product.
Those teams of similarly-specialised individuals naturally created centres-of-excellence in their function. Put two backend developers sitting together and they will (typically) work hard together to ensure the code base is optimised. They will take pride in their work, naturally. Now remove or distance these developers from their business counterparts and slowly watch how the business agenda becomes less important in the daily task focus. Everyone is on paper working towards the same goal, however the fine balance between the multiple objectives of each individual specialist becomes harder to achieve. You can even end up in bizarre scenarios where IT teams tackle tasks at the tail end of a business backlog, simply because it is easier to deliver and the team had some capacity. Indeed a situation will often emerge were artificial work is created to occupy teams who are not currently required to deliver high-value customer projects.
I’ve even witnessed organisations unravel working modes dismantling cross-functional teams in order to align skillsets within functions. When launching a new product in a large scale organisation, a cross-functional team was established consisting of business managers, product managers, designers, developers, data base analysts, testers and operational resources. Upon successful launch of the product, the team was split to the four winds according to their specialisms. Almost immediately, frustrations set in between each of the newly constructed “teams”. Additional documentation was now required to request small feature changes. Written requests were mandatory. People were less available to answer quick questions. Things seemed to take much longer for IT to achieve. The business teams seemed to be asking stupid questions all the time.
What is the alternative?
One approach that is commonly taken is to create short-term project teams for specific features. This can help to overcome some of the communications barriers between the different resources working to deliver a specific feature. However, this approach also comes with certain weaknesses. In Scaling Lean & Agile Development, Craig Larman and Bas Vodde highlight some of these weaknesses. They contend that there is clear evidence that short-lived groups of people brought together for a project are correlated with lower productivity. This is often because the group needs to invest time and effort into gelling together in order to develop a good working mode. The people who are in such groups tend to have less motivation as they are never given a chance to take long-term interest in a particular feature and there is less opportunity to learn new skills outside of their specialism. Often, resources are only partially assigned to a project and as a result of multi-tasking they are less productive. The multi-tasking of resources on different projects reduces availability and reduces responsiveness. The teams will usually continue to be physically (and often time-zone) dispersed and so will have little relationship with each other and little opportunity for fluid communication. Finally, there will be higher costs, since there is additional project management overhead to co-ordinate the multi-tasking project teams’ deliverables.
Larmann and Vodde propose what they call Feature Teams as the most viable approach for highly performant customer feature delivery. A feature team is “a long-lived cross-functional team that completes many end-to-end customer features one by one”. The team is composed of co-located individuals with specific areas of expertise, but who are working closely together to bring a complete feature to market across all components and disciplines (design, analysis, programming, testing). It is the key mechanism that accelerates time-to-market.
Why is this? Such teams are differentiated from short-lived teams by a number of key characteristics. Feature teams are empowered in decision-making on a given feature, since the teams consists of the range of skills from frontline expertise to backend development for the given feature. The team in its totality is accountable for all aspects of the design, development, debugging, QA, shipping, and so on, and so are more likely to devise ways to share critical observations with one another. With cross-functional feature teams, individuals gradually begin to identify with a part of the product rather than with a narrow specialized skill. Since the point of identification is the feature and since the accountability for the feature is mutual, a certain degree of openness is safe, even necessary. There will also be a good degree of balance in a feature team since the team is constructed with diverse skill sets, diverse assignments, and diverse points of view.
Feature or “vertical” teams are already a very common construct in both large and small enterprises. The authors use Ericsson as a case study, where the feature team approach is explained as follows:
The feature is the natural unit of functionality that we develop and deliver to our customers, and thus it is the ideal task for a team. The feature team is responsible for getting the feature to the customer within a given time, quality and budget. A feature team needs to be cross functional as it needs to cover all phases of the development process from customer contact to system test, as well as all areas [cross component] of the system which is impacted by the feature.
The main benefits of feature teams include:
- Increased value throughput since the team is focused on delivering what the customer or market values most
- Increased learning within the team because of the broader responsibility and because of co-location with colleagues who are specialists in other areas
- Reduced under-utilisation because of the improved learning; each team member can support in areas outside of their core specialism
- Simplified planning since by giving a whole feature to the team the need to plan between teams with conflicting priorities is reduced
- Reduced hand-offs since the entire co-located feature team does all work
- Wait times are reduced with the removal of inter-dependances between different teams
- Improved cost and efficiency since there is less project management
- Better code/design quality results especially when multiple teams work on shared components
- Increased motivation since the team feels they have complete end-to-end responsibility for a customer-impacting feature
- Change is easier since everyone involved and responsible for the original requirement is in the one location and speaking the same language
In my later career roles, we have increasingly taken the approach of creating vertical teams, either to bring new products to market or to create features for existing products. Where we revert to old models, no matter how advanced our communications mechanisms, we end up with the same old frustrations. This vertical approach is also highly applicable when seeking to build scaleable operational models. Operations concerns itself maximising the value to customers through effective rollout of the product features and services offered by the business. The critical new challenge for a company that has discovered a sustainable business model is scaling successfully; taking the organisation from highly-manual, ad hoc and experimental to systematic, structured and reliable. Now the management team needs to think much more about people, processes and internal systems; which is critical but which can also distract from the core focus on customer.
Cross-functional “customer experience teams”, with a mission to deliver awesome experiences to customers can have a similar efficacy to the feature team approach used successfully in product development. In a scaled operations environment, one important distinction needs to be drawn between the “core” and “peripheral” customer experience teams. Both types of team are equally important if the business is to scale, but they serve different roles. The core team, a cross-funtional team of specialists across the range of topics required to support customer experience will be co-located and have a multiplicative effect across the organisation. The peripheral team have an additive effect in their actions and can be potentially dispersed across multiple locations. Even in a mature product, the core team needs to act like a feature team, ensuring maximum fluidity in open communication between all specialisms. For the core team to work effectively as a team, there will be a limit on the number of members of that team. In a Scrum software development environment, for example, it is recommended to not go beyond 7-8 members of a team. This figure could be applied most effective team structures.
A mistake that many businesses make in attempting to scale, is to try to achieve the same level of fluidity amongst all parts of the ecosystem – core and peripheral. For additive tasks, the requirement for a high level of fluidity across specialisms is nowhere near that required for a core team of cross-functional specialists. The tell-tale action that indicates a business is taking the wrong approach to scaling, is the massive increase of the employee headcount within the business. This internal expansion requires significant investment both of working capital and strategic management attention, and it inevitably introduces inefficiencies, brings wastage and reduces flexibility; especially in an age when highly operative tasks can be easily processualised and managed remotely. In establishing structured and controlled operative processes which CAN be managed efficiently in dispersed locations, the business will realise efficiencies that would have otherwise been hidden in the maelstrom of internal operations.
Most importantly, the peripheral teams need to have direct access points to the core team which are not filtered by layers of internal hierarchies. Similarly the core team needs to maintain direct exposure to the customer experience and avoid isolating themselves behind data and management reports. The biggest problem that many larger organisations suffer from is the increasing distance between key decision-makers and the actual users of the company’s products. Ensuring direct lines of communications between the edges of the organisation and the centre, can help to reduce these distances.
(It’s been a while since I wrote some thoughts here, so there is quite a lot piled into this particular post. More will come in time to clarify.)