As I recently posted on Twitter, I really believe that building great software products, services and solutions is a team sport. In some team sports, teams are made up of a fixed number of people, playing fixed roles. In others, squads of multidisciplinary players swap in and out for each game, even mid game.
Then there are the supporting roles, the people who coach the team, the physio who keep them well. How many people does it take to allow two formula one drivers to race a single race, for one team? Hundreds at least!
Building software based products is a similar story, one of teams of people coming together all playing important roles. And like sports, how many people, in what roles, is dependent on a number or key things. Two of these factors are scale and budget.
At the most basic, ten people could out together two five-a-side football teams, hire a pitch and play a game of football. They have no coach, or physio or any of the many other supporting roles. How many people do Manchester United have? Scale, budget, context.
Teams building software are no different. One developer can make software. Budget is low, but there is only one mouth to feed (and maybe their Family). At this scale, any bug fix interrupts development. If multiple customers have competing priorities, one has to wait.
Anything new must be learnt before they can use it. If they go on vacation everything stops. There is no one else to support customers. Some customers will avoid using products from a single developer, because in their context they need uninterrupted support. So... We scale.
As we scale companies, we might have goals we want to achieve with this new capacity. Being able to attract larger customers with deeper pockets and commit for longer. Scope for taking holidays. Building new features faster. Build and operate reliable products.
This is where we start to introduce roles. We no longer have only Developers. Now we have people who look after Product, Sales, Support, Operations, Legal, HR, Quality and more. Depending on context, and scale, these maybe people or services from other organisations.
Somewhere along the way, as the company grows we might run into problems. We grew our budget, added roles but we still haven't met our goals and some of us are miss the days a small team could ship their own product without help.
One way we might try and fix this, is by shaping our teams into multidisciplinary powerhouses. With Devs, Ops, Product and Quality all together, maybe more too! This power team can play their part of the game. But did we solve our problem? Meet our goals? Are we tracking them?
Over time, sports teams and hope they are supported have evolved. Formula One today is light years ahead of where it was in the 1980s. And so too software teams and organisational structures change.
What is important is to understand your goals, identify your problems and measure your progress. Don't get distracted by how others are playing the game, focus on what works for your team! This is a journey. I've heard again and again "No such thing as a DevOps engineer"
I've also heard, that there should be no Testers. Just Developers who are coached and taught how to test. This might work great for some teams That doesn't mean you should feel bad for having your DevOps and QEs in your success team. In your current context, budget and scale.
Originally posted on my blog: https://www.dowen.me.uk/creating-software-is-a-team-sport/
Cover Photo by NEOSiAM 2021: https://www.pexels.com/photo/selective-focus-photography-of-foosball-table-595229/
Oldest comments (0)