I think a lot about how teams should be structured when building software. Many companies choose to distinguish their teams by discipline. There is the Development team. The UX team. The Product team. The QA team. The Support team. The Marketing team.
It makes sense at first. The manager for folks in a given discipline should have experience performing the job in that discipline. You wouldn’t want a developer managing UX designers and vice versa.
However, there are many challenges with this approach. The first is making sure the goals for all the teams are aligned. Developers usually have the incentive to make estimates well ahead of time and ship product quickly. Their managers often have this expectation for better or worse.
QA testers have the incentive that no bugs are released with the product. Their job is to ensure quality after all. If that means delaying releases to be extra sure, so be it. To let a bug through is to appear as if they are not doing a good job.
UX designers have the incentive to make the most polished product. They are often judged solely on how the product looks. That means their preference is always to take more time to make things look nice.
These goals all make sense for the disciplines in isolation. Notice the conflicts of interest though. In software development, we can focus on release dates, quality, or features. Only 2 of these focuses can be accomplished for a complex product. Nothing is perfect and you can’t have it all.
That means one discipline is not going to get what they want. How do you decide which? Few talk openly about this challenge so the resolution comes from office politics.
The most effective team I was ever on was structured very differently. Everyone who was necessary to deliver software was on a single cross functional team. There wasn’t a separate development team or art team or QA team. We built games so we had game teams. The team consisted of developers, artists, testers, game designers, and project managers. We didn’t have a team of artists do their work and then hand it off to the developers. Everyone built software together.
The most important thing that this structure does is it aligns everyone’s goals. If there was a deadline, the deadline was not owned by a single discipline. It was owned by the whole team. If speed was the most important thing for the company, then we focused on getting things released quicker. If getting a feature right was the most important thing for the company, then we took the time to get it right.
There was no “why does the game designer always want impossible features?”
There was no “why are the developers so difficult to deal with?”
There was no “why can’t the artists get their act together?”
There was only the team. We succeeded together and we failed together.
What also helped was the better communication that came with this team structure. Artists and developers weren’t seated across the hall or on different floors. The team sat together which meant that developers were seated right next to artists. This was a huge boon given how tied together the work was. There was no time wasted waiting for someone to answer a question about how work should be integrated. You just needed to turn your head. Often times 5-10 minutes of one person’s time can save an hour or more for another person. That’s value given to the business.
Interestingly enough, none of us were the best in our fields at the time. We’re all much more effective in our respective disciplines today than we were back then. Yet I have never been on a team that could deliver quality software as fast as that one.
Software development is a complex process. There are serious limits to what an individual can do. That means there are also limits to how far the abilities of an individual can get you. There are no limits with good teamwork.
That being said, not everything is perfect with this structure. In the end, you still want developers reporting to developers, artists reporting to artists, and product managers reporting to product managers. A developer is most likely going to be unable to help an artist improve their art skills. A product manager is most likely going to be unable to help a developer improve their development skills.
The cross functional team I was in worked because the company was 36 people at its peak. That was a low enough number that everyone reported to one of the 3 partners at the company. Each team had autonomy to act as they saw fit, but there was always a manager to help folks of a specific discipline grow in that discipline. I have not seen this model scale to a larger company, but I can easily see the reporting structure getting very complex.
Despite that challenge, I can’t let go of how productive we were. I have tried and failed to replicate that team culture ever since. I think the difficulty of getting the reporting structure right is why I encounter so much resistance. It’s so much easier to just stick with the status quo after all.
Do you have any thoughts on what would make an effective team? I would love to hear from you!
This post was originally published on blog.professorbeekums.com
Top comments (0)