A Vision for Software Development: It’s All About Teams

I’ve thought a lot in recent years about how our profession is kind of fundamentally broken, and how we might be able to fix it.

The more I consider it, the more I think the underlying dysfunction revolves around software development teams, and the way they’re perceived as having only transient value.

Typically, when a business wants some new software, it builds a team specifically to deliver it. This can take many months and cost a lot of money. First, you have to find the people with the skills and experience you need. That in itself usually works out expensive – to the tune of tens of thousands of pounds per developer – before you’ve paid them a penny.

But the work doesn’t end there. Once you’ve formed your team, you then need to go through the “storming and norming” phases of team-building, during which they figure out how to work together. This, too, can work out very expensive.

So a formed, stormed and normed software team represents a very significant investment before you get a line of working code.

And, as we know, some teams never get past the forming stage, being stuck permanently in storming and norming and never really finding a satisfactory way to move forward together as they all pull in different directions.

The high-performing teams – the ones who work well together and can deliver good, valuable working software – are relative rarities, then: the truffles of the software industry.

Indeed, I’ve seen on many occasions how the most valuable end product from a software development effort turned out to be the team itself. They work well together, they enjoy working together, and they’re capable of doing great work. It’s just a pity the software itself was such a bad idea in the first place.

It seems somewhat odd then that businesses are usually so eager to break up these teams as soon as they see the work is “done”. It’s a sad fact of tech that the businesses who rely on the people who make it prefer to suffer us for as short a time as possible.

And this is where I think we got it wrong: should it be up to the customer to decide when to break up a high-performing dev team?

I can think of examples where such teams seized the day and, upon receiving their marching orders, set up their own company and bid for projects as a team, and it’s worked well.

This is very different to the standard model of development outsourcing, where a consultancy is effectively just a list of names of developers who might be thrown together for a specific piece of work, and then disbanded just as quickly at the end. Vanishingly few consultancies are selling teams. Most have to go through the hiring and team-building process themselves to fulfil their bids, acting as little more than recruitment agencies – albeit more expensive ones.

But I can’t help thinking that it’s teams that we should be focusing on, and teams our profession should be organising around:

  • Teams as the primary unit of software delivery
  • Teams as the primary commercial unit, self-organising and self-managing – possibly with expert helps for accounts and HR etc. Maybe it’s dev teams who should be outsourcing?
  • Teams as the primary route for training and development in our profession – i.e., through structured long-term apprenticeships

I have a vision of a software development profession restructured around teams. We don’t work for big companies who know nothing about software development. We work in partnerships that are made up of one or more teams, each team member specialised enough for certain kinds of work but also generalised enough to handle a wide range of work.

Each team would take on a small number of apprentices, and guide and mentor them – investing in training and development over a 3-5 year programme of learning and on-the-job experience – to grow the 10% of new developers our industry needs each year.

Each team would manage itself, work directly with customers. This should be part of the skillset of any professional developer.

Each team would make its own hiring decisions when it feels it needs specialised expertise from outside, or needs to grow (although my feelings on team size are well known), or wants to take on apprentices. So much that’s wrong with our industry stems from hiring decisions being taken by unqualified managers – our original sin, if you like.

And, for sure, these teams wouldn’t be immutable forever and all time. There would be an organic process of growth and change, perhaps of splitting into new teams as demand grows, and bringing in new blood to stop the pond from stagnating. But, just as even though pretty much every cell in my body’s been replaced many times but I’m somehow still recognisably me, it is possible with ongoing change to maintain a pattern of team identity and cohesion. There will always be a background level of forming, storming and norming. The trick is to keep that at a manageable level so we can keep delivering in the foreground.

Author: codemanship

Founder of Codemanship Ltd and code craft coach and trainer

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s