Feature Teams vs Component Teams

Feature teams are the idea that multiple teams can work together to create a piece of software, structured so that each team builds features of the product and is responsible for  whatever changes are necessary to every portion of the application involved in delivering that feature. This is contrasted against component teams, where an individual team owns a particular portion of the application and is responsible for making all changes to that portion for every feature.

Component teams historically seemed a good response to scaling up work. You went from having one person alone building a thing to one team building a thing. Within the team, each individual had unofficial ownership of the code they wrote because they knew it best and people would naturally gravitate towards them with questions and requests related to that code. Ownership corresponds with a better understanding of that specific portion of the domain. It can also encourage you to take pride in your work and creates an incentive to do your best since any issues with it will come back to you. Then, having a single team wasn’t enough, so you had to start having multiple teams for a piece of software. As you formed a team for the component, either the team overall took ownership or individuals owned and maintained smaller portions of the overall component.

It made sense in the boxed software world, where you built version one and never needed to really change it. In the modern software world the system evolves regularly, by design. And evolving software has different needs; a component will have different amounts of change required at different points in its lifecycle. This means that a team could be overwhelmed sometimes and idle others. This can cause blocking issues for other teams and scheduling work.

Feature teams resolve a lot of these issues by unblocking work, but you lose the benefits of ownership. You can try and apply collective code ownership to all of the feature teams, but the domain knowledge wouldn’t develop the same way. And once you hit a certain size of team or code, the pride of ownership can go away too.

There are a couple of ways to balance the two. You can use feature teams with an affinity towards features with impacts on particular parts of the system, but that can easily become more complicated with the exclusion of others. Building Microservices proposes using a structure like an open source project internally to allow others to put in a proposed change and have a team who is responsible for being sure it integrates cleanly and to be responsible for the overall cohesion of the component. I haven’t had a chance to try this, but it seems highly promising.

Neither approach to structuring your teams is right or wrong, but by looking at both, understanding the pros and cons, and picking the right one for your needs can be a great boon, rather than dogmatically picking one or the other.

Conway’s Law Cause and Effect

Conway’s Law is the idea that software represents the organization that created it. It is often described  wherein the organization creates design, like “Four developers make a compiler and you get a four-pass compiler.” But it could also make sense that it would go the other way. There is a three tier architecture and as you scale up you end up with teams for each tier. Is either causal relationship  more true than the other?

The initial paper describing the concept seems to be arguing for the former, but the examples I’ve seen have been more the latter. The team grew after the software started and then you brought in additional teams to scale out development that were given responsibility for a chunk of the system. I went looking for data about this and was unable to find any, so I’ll propose a thought experiment. You’ve got an existing system with three teams working on four parts. If you were to create a fourth team and not have them work on any particular part, how do you think it would go? I see frustration until responsibilities shift to make space for the new team. What about with the same three teams and the same four parts, creating a fifth part and having an existing team own it? That situation seems like it would work fine.

“Your org structure isn’t solving your problem. It’s an artifact of how it was solved before” – Adam Jacob (I’m assuming the one from Chef). This seems to support that the system grew the organization around it, not that the system reflects a preexisting organizational structure. If the system influences the organization to this degree, then that means as we architect software we wield outsized influence of the organization that will form around it.

This influence can’t fix all organizational structural problems, but it can be used to help guide the organization’s growth. I recognize that there’s a bit of a cart before the horse problem, in that if your organization has set staffing level budgets by team, you’re probably stuck with those and can’t easily reallocate each team’s staffing level to what you’d like the development to reflect. You can, however, structure responsibilities so each team owns multiple things, rather than one big thing. This would allow you to grow a team and then split it and split up their responsibilities to the resulting teams.


The rockstar programmer or the 10x engineer is someone who is so much more productive than anyone else on the team. The initial research that created this idea has had its underlying design contested, but continuing research still supports it (see a discussion of the research here). If it is possible to be 10x as productive as other engineers how are these rockstars accomplishing it? Is it tools or languages or architecture choices? The research has shown that the answer appear to be none of the above.

Instead, the difference appeared to be the amount of learning done while working. Rockstars do very little learning, since their time is effectively too valuable to spend learning, it must be spent focused on problems within their existing comfort zone. It makes sense – if you know your tools and your domain then you start off more productive and can stamp out cookie-cutter solutions very quickly. I have worked with a guy who was a rockstar that could solve most problems we came across in the fraction of the time compared to everyone else on the team. However, he became almost helpless when presented with something outside his comfort zone. He had spent so long just stamping out similar solutions to similar problems that he became really good at it but the rest of his skills had deteriorated. More importantly for a true career in software development is the exercise of your learning muscles.

You need to be challenged with new things, not just for to learn those new things but also to practice the learning process. If you are continually learning new things you can stay in the flow channel more easily. Each time you learn something you get better at the process of learning. Concentrated learning in a single domain reinforces itself; as you learn one way to look at a domain you can leverage that knowledge to learn more about the domain faster.

This all meshes with the idea of flow. You need a problem to adequately challenge you in order to help you learn. If the problem is too easy you get bored, and don’t learn much. If the problem is too hard you get frustrated and don’t learn much.



This, combined with additive effects of learning, says that if you are a rockstar you are stuck in a lose-lose situation. You have difficulty learning new skills until you get pushed out of rockstar status, because staying in your comfort zone would prevent you from being as productive and it creates perverse incentives. Your employer is incentivized to prevent you from practicing new skills at work and concentrate you on the things you are best at, but that will slowly push you further and further into the same specialization in a way you may not be interested in. Also, you have spent so long honing the same skills that you have neglected learning new skills, making it harder to pick up new skills. This disincentive towards learning can impede your ability to move around in your career, since you would only fit in a very specific environment. There is lots more on this idea here.

There are three takeaways I see from all of this. First, some developers are much better than others. This is especially true in the sense that someone can have a negative productivity, i.e., someone can delay others more than it would have taken them to have completed a task themselves (Brooks’ Law). The second takeaway is that someone who is significantly more productive than the norm has acquired a specialization, not just in the technical sense, but the domain as well. Third, being super productive can have negative long-term aspects, in that you are tied to a technical stack and domain, which limits your control of your own career.

Having been the rockstar myself at one point I can say there is a rush from it; it feels great when others depend on you and marvel at what you can accomplish. But it becomes frustrating, since to me, I didn’t feel like I was doing anything special, and seeing the others around me struggle to keep up and follow along started to feel like they weren’t pulling their weight. And, I could feel my other skills stagnating, which brought a separate kind of frustration. In the end I chose to move to a new job, rather than being the rockstar big fish in a little pond, so that I could continue to challenge myself and have the freedom to learn new things. I can see the appeal of being the rockstar, but I think if you choose that path, you have to be very careful not to let yourself become obsolete by being too focused.