The Team Is The Real Product

Teams As Vehicles For Delivering Software

Despite all our talk of continuous delivery and a shift to a product focus, the project mindset, with it’s deadline focus, is still, sadly, the dominant paradigm in 2023. This has a significant impact on the way most organisations view development teams.

Most organisations see software teams as machines made up of interchangeable parts.

Because of this, management often see no drawbacks in disbanding teams after a major release, thinking they’ll be easy to replace.

Teams are treated as fixed costs to be minimized. From an accounting perspective, development teams are seen as a liability, not an asset.

In too many organisations, a team is seen purely as a mechanism for delivering software.

In these organisations, we see little interest in the teams themselves and what they could become given time and investment.

Software development is essentially a learning process. Teams know far more by the time a product goes into production than they did at the start.

Much of what they’ve learned could be applied to other problems and other products.

This is often at best viewed as a side-benefit of creating software. I’m going to argue today that, very often, it’s actually the main benefit, and that the software is the side-benefit.

Software Delivery as a Vehicle for Growing Teams

Developing products is a risky business. 95% of new products fail. (Prof Clayton Christensen, Harvard Business School).

So 95% of the time, what we’re left with at the end is just the team who made the product, and what they learned in the process.

95% of the time, the primary benefit is increased product development capability.

Stable Teams

In the traditional project-focused view, teams are brought together for a major release and then disbanded once the software’s in production – perhaps keeping one or two of the more junior developers to fix bugs and do maintenance.

If another major release is required, an essentially new team is formed, starting the whole process from scratch.

This has obvious disadvantages. The time and cost of building new development teams – both hiring and waiting for new team members to become fully productive (typically this takes 3-6 months after hiring) – means that a lot of money has already been spent before a line of new code is written.

Moving to a long-term product focus, organisations retain teams in their essence, on the understanding that future releases are inevitable and the big investment in team building, plus what the team has learned should be viewed as an asset.

A stable team is a team that is preserved for the long term. They’re often attached to a product or system, but can be targeted at new problems and new products, leveraging their knowledge of the business, the tech stacks and architectures, and the relationships they’ve built inside the organization.

The practical benefit of stable teams is that when that second release (and third, and fourth) is required, we don’t need to build a new car. We just need to take our foot off the brake.

Of course, there’s more to growing stable teams than just not disbanding them.

The skills of individual team members play an important part in an organization’s ability to foster long-term team composition.

If the majority of individuals are highly specialized, it becomes very difficult to maintain teams. In those organisations, specialists are often flown in and out of projects (e.g., a UX designer, or a database expert, or a “front-end developer”). Teams will often end up being organised around specialisms: the QA team, the UX team, the DevOps team, the Java team, and so on.

If developers have a wider set of skills - a bit of UX, a bit of front-end, a bit of database etc – then forming long-term teams around delivering end-to-end solutions is much easier. But everyone being a “Jack of all trades” can lead teams into deep water when much more in-depth expertise is needed.

An ideal skills mix is a “T” shape. General expertise in a wide range of areas, but deep specialism in one in particular. So each team has a UX specialist, but they don’t become a bottleneck, because 80% of UX decisions can be handled by anyone on the team.

In terms of team composition, people often recommend a diamond-shaped distribution of skill levels and experience, with a small number of very skilled developers, a majority of medium skill levels, and a small number of junior developers who are basically there to learn from the rest of the team.

If teams are routinely be disbanded and reformed, then this mix of skill levels will tend to persist in an organization.

On a stable team, where the turnover of developers is slow, over time this distribution is likely to change, with the majority of team members being highly skilled and very experienced.

This has the benefit of gradually raising the bar within the team, so that over the years they’re able to achieve much more.

This has implications for the career paths organisations offer to developers, though.

Developer Career Tracks

In traditional organizations, avenues for career advancement tend to require developers to move into management roles.

The irony is that promoting the best developers into management doesn’t actually retain your best developers, and it doesn’t necessarily follow that they’ll make great managers.

Also, management roles are much more limited, so not only will your best developers leave development – where they bring the most value – they’re quite likely to leave the organization to seek opportunities. The alternative is to become a top-heavy organisation., which far too many end up as.

Having a career path that inevitably leads to management also works against stable teams.

An alternative model, that makes it much easier to keep developers doing what they do best – retaining your investment in them – is a non-management career track that enables the best developers to attain the status and rewards of senior management in hands-on development roles.

In some of the largest software companies, a Distinguished Engineer can earn in excess of $1 million a year, and engineers may even end up in the C-suite, helping to define the organisation’s strategy from a perspective that’s all too often missing in the boardroom in an age when "software is eating the world".

Managers can then be hired or promoted for their management skills, and the technical excellence that stable teams can foster is preserved.

Developers sit within the organisation at a level that’s orthogonal to their hands-on roles.

Someone with the equivalent authority of a CTO might lead a development team day-to-day, but outside of that, they would have significant influence in overall development strategy.

They would also be in a position to lead by example within product teams, having a much more direct impact on the rest of the developers.

Avoiding Stagnation

Not all long-lived teams evolve. I’ve worked with mainframe teams where the average length of service was more than 10 years, but is that 10 years of experience, or 1 year’s experience 10 times? How do we avoid stable teams falling into the trap of just repeating the same mistakes year after year?

For the capability of stable teams to grow, we must build learning into the process.

With much more skilled and experienced developers staying “at the code face”, more junior developers can benefit from their knowledge.

Senior developers make mentoring a big part of their job. Ad hoc mentoring is common, but it may benefit teams to make mentoring arrangements more structured and formal, to better ensure everyone gets the attention they need.

Pair programming and mob (or “ensemble”) programming is another way developers can learn from each other. Knowledge sharing in teams who pair and mob regularly tends to be much wider, and good ideas spread through the teams faster.

Investing in learning resources like books and libraries and online training is a great way to bring knowledge into teams. Also, investing in or creating learning opportunities like training courses, conferences, internal workshops are not just a valuable way to promote learning, but can be great opportunities to meet new developers and be exposed to ideas from other teams and from outside the organisation.

Note that businesses who nurture stable teams tend to also be active within wider software development communities.

These are also good opportunities to more senior developers to lead by example.

Some organisations explicitly make regular time available for learning and growth, building it into the working week. While many managers balk at the thought of lost productivity, more advanced organisations think instead of the gain in capability.

Don’t worry about what you might be losing in 4-8 hours a week. Think about what you’re gaining in the other 32-36 hours.

Exchanging developers between teams for limited periods can bring new perspectives and spread knowledge across the organisation faster. Some organisations also swap developers with other organisations, sharing knowledge on a much wider scale.

Much of the learning that happens in software teams is unstructured and ad hoc, often happening to address an immediate need. It’s very common for developers to miss out on important skills, especially in the early stages of their careers.

Providing a structured road map for learning and development helps to ensure these key skills aren’t overlooked, and also provides direction for developer career paths. These roadmaps can be managed within the organisation by the developers, and evolve as the organisation’s technical needs change.

In a structured learning environment, a logical next step might be to reward developers with recognized qualifications, such as a degree or post-graduate qualification, or a government-approved apprenticeship.

Investing in this demonstrates your organisation’s ongoing commitment to developing the talents of their teams, and can add an extra incentive to stay longer.

The Team-Powered Business

While teams are building software products, they’re also building capability. Stable teams can become much more capable over time, enabling them to do things most other teams can’t.

As well as offering a business a competitive advantage through superior software development capability, it can also create a positive feedback loop, where the reputation of developers in the business makes it easier to attract talent.

Having high-performing teams ready to go, and capable of learning rapidly, can enable a business to pivot faster then their competitors when they need to. We’re seeing how new digital banks are stealing a march on their less agile bricks-and-mortar competition. (But, Jason; aren’t all banks digital? Yes, but some are realizing it a little too late!)

Ultimately, the essence of the value proposition of stable teams is not just more throws of the dice, but better dice too – more new products and more iterations, with increasing capability in each cycle enabling teams to reach beyond what competitors might be capable of.

Through Codemanship, I provide the training, mentoring and organisational guidance for growing and nurturing T-shaped developers and stable, high-performing development teams. I'm the Chief Software Developer most organisations currently lack. If you're interested in building capability for the long term, drop me a line. It's right up my street.