Vertical integration
17 January 2016
Vertical integration. It's one of those words that they use so much business school that makes you wonder if it actually means anything. I hate those words as much as the next developer, but this is the best word I can think of to call the concept I want to write about.
If your company builds a product, the more of the different kinds of work your company does itself that go into the product, the more vertically integrated the company is. Most software startups are fairly vertically integrated as a whole even though we like to take advantage of other people's awesome work that they give away for free.
Vertical integration is one of the reasons why Apple is able to continuously put out the kind of high quality products that they are known for. Apple continues to try and be more vertically integrated, like when they brought the production of the processors for iPhones and iPads in house and started building their own chips. Lately, some of the software Apple has put out has been a bit rough and seems like it needs a bit more attention to detail. Vertical integration at that scale and any scale is always hard, but the quality of product it generally produces is hard to argue with.
It's not just companies that can be vertically integrated. People can be vertically integrated as well. We just don't call it vertical integration, what we call these people are things like: full-stack developers, unicorn designers (who both design and write code), and product CEOs.
People with these cross functional skills are hard to come by. But when you do, and they are a good culture fit, they are worth every penny. Why? Because when you hire one, you've just prevented yourself from having to add the communications overhead between two people doing each function that, now, just that one person does. This doesn't sound like much, but as you scale your company communication overhead exponentially effects the quality of your product and the speed at which you can get stuff out the door.
In practice, these people can take entire features you want to to ship and get them out the door. When one person is ultimately responsible for that feature shipping and not relying a ton on anyone else, besides a few quick sanity-checking chats, maybe a technical clarification, and then finally, a peer-review before it goes out the door. That eliminates an incredibly significant body of work in a normal development environment that is pretty much just coordination between the different parties that build the different things.
Clearly, some features are going to require more areas of expertise than a single person can provide. If you try and make sure your entire team has a significant degree of vertical integration, you will drastically cut down the number of people and the number of communications channels needed to make decisions and ship that feature.
Tasks are still assigned to a single person, and they are responsible for making sure that thing ships and that they bring the right person or people in to help if they need it.
This seems simple, but I think it is worth further clarification: you get that benefit on every feature, everything the team does, from now until you start hiring differently. This alone can give you an insurmountable competitive advantage, even if you're coming from behind. You can grow faster, while having to hire fewer employees.
This might seem like it could be quite inefficient. One person doing all the work for a specific feature and not being able to focus on what they are best at? But, remember the concept of small batches. If any one person on your team can take a feature from spec to completion by themselves and you have 6 people on your team, you can work on shipping 6 different things concurrently. Yeah, you might introduce some distractions asking questions about the areas you might be less familiar with, but it is pretty much guaranteed that those delays will be less than the delays involved in coordinating two or more people working on the same chunk of code.
When you work on a team that is vertically integrated it is extremely important that the members of the team know that they are apart of the team and that the team cares about quality, both in terms of code and the finished product, and they care about shipping. You can't just sit there making something perfect for two months, we need you to ship it. Then, watch how it works after it ships and then iterate on it with real world feedback.
I believe that this kind of setup fosters this attention to quality within the team. Everyone knows exactly who was responsible for building something and so, this tends to make you only want to do your best work.
You might also think that structuring the team in this way won't let anyone learn too deeply about something that they need to do for their job. I've found that this quite simply is not the case. People can spend more time talking out how they are thinking about implementation, while they are doing implementation in teams like this. This talking, then seeing how it ended up being implemented in the peer review does a pretty good job of distributing knowledge throughout the team. Plus, you can use the time you would have used coordinating with all those others to take an hour or two and figure out that MongoDB query syntax, or to read up on Redis, or maybe to split that module out into its own repo so that we can use it in our other services.
This is the way our team is structured at Freightview and it was and continues to be a revelation. Having our entire stack written in CoffeeScript probably makes this much easier to implement in practice. All of us can take an feature from spec to completion, no waiting on an API, or a database table to be added, or another team to have a meeting because they are worried you're encroaching on their territory. Obviously, it requires taking into account each person's abilities relative to the task you want to assign them, but you were already doing that right?
This is just one of the seemingly small ideas that end up having a huge impact which I've learned at Freightview. People call our development team a well-oiled machine and we get told all the time that they can't believe how fast we adapt to customer feedback. This is one the things that lets us do just that.
It wouldn't have been possible without Jason and Charles who didn't want to just accept conventional thinking and respect the status quo, but who instead spent a lot of time thinking about how we should do things and why and the types of people that they wanted to bring in to the team. I will be forever grateful to them for teaching me how a development team should operate.