This post is part 1 of a series on how you can take advantage of processes and tooling that large public open-source projects have developed to build a foundation that will help you scale your engineering organization and better take advantage of each engineer’s talents to meet your engineering goals. You an read the entire series here.
The software development industry is in the midst of an enormous growth cycle. At the end of 2019, the software industry was growing roughly twice as fast as the overall economy in the United States [1]. Software is everywhere and companies are looking for more engineers than ever before. Simply being able to hire enough people to fill your teams isn’t enough to ensure that your engineering organization runs smoothly and delivers the solutions that the company needs.
The Problem
As companies look to scale their engineering practices, they have traditionally charged their engineering leadership with building teams based around individual projects. Some refer to this organizational structure as “component teams” or “product teams”. Organizations that have multiple products that don’t intersect with one another may find that this staffing model works just fine for them. However, many companies building large collections of web-based applications find that this approach oftentimes leads to multiple disconnected teams that don’t collaborate and end up working mostly in isolation from one another.
Many engineering organizations operate using what I refer to as the “golden fences” philosophy regarding who can access their code. These golden fences exist to protect the developers from feedback from people outside the team. I’ve been that engineer before that didn’t want people looking at the code I was writing for fear that they would point out something I’d done wrong. The issue here is that allowing these golden fences to exist in your organization stunts every engineer’s growth. Not one of us individually has all the good ideas. Keeping to the traditional isolated component team model makes it very difficult to surface those good ideas to other engineers that might be able to take advantage of them.
Additionally, not having cross-team collaboration hurts the applications themselves. How many times have our organizations built the same feature or function into multiple applications because the teams didn’t know that some other team had already built something very similar. These duplicate features always function differently. Sometimes they don’t even produce the same results since they are getting data from different sources and acting on that data using different logic. This leads to dissatisfaction with the solutions that we are delivering to users as well as more work that the organization as a whole has to accomplish to keep multiple solutions updated.
A (Possible) Solution
We as engineers know that no one solution fits every situation. What I’ll be describing in this series of posts is something that worked for my organization. My goal with this series is to offer an alternative to the traditional component team organization and development methodology. Others have coined the term “innersource” or “internal open source” as a way to describe this way of enabling multiple teams to work in a more collaborative way. It borrows heavily from how public open-source projects are able to operate with sometimes thousands of developers contributing source code from all over the world. At it’s core, it’s centered around 4 key ideas:
- Removing the “Golden Fences” from your culture and your code
- Making good choices with software stacks
- Encouraging (even mandating) cross-team communication and collaboration
- Automating nearly everything
These ideas aren’t something your organization can implement overnight. In many cases, some of these won’t be possible in your organization at all for any number of reasons specific to your company. As we go through this series, remember that the old programmer adage “it depends” applies to every one of these ideas. My hope is that at least some of these will be of use to you in your organizations to help you better manage your teams as your organization grow.
[1] “These States Benefit Most From the Software Industry” – U.S News & World Report, Sep 19, 2019