I left Google 3 months ago after almost ten years there. I am now building on a fast track for software development teams. Today I will explain why this is important for me.
Google is extraordinary. With so many smart people trying to change the world, they create cool things every day.
At a high level, Google is a giant center for data processing and software development. You take massive amounts of data, put that in the world’s most scalable computing infrastructure, then ask brilliant people to do something interesting with it. Sometimes their work creates revenue (e.g., optimize ads). Sometimes it just generates more data (e.g., a new product that people use every day, like Gmail, Google Maps, and Android). Either way, it is a virtuous cycle:
software development + data => data + $$
Then you can use $$ to hire software developers and start again.
It is not just Google. More traditional companies are growing their software development teams because they agree with what Marc Andreessen wrote in 2011:“My own theory is that we are in the middle of a dramatic and broad technological and economic shift in which software companies are poised to take over large swathes of the economy.”The traditional companies going through the digital transformation are ranked by the market based on how fast their developers can transform ideas into products and create value for their customers.
When you add to that the competitive dynamics of the connected economy, you see why every company out there is scrambling to hire more developers and help them be more productive.
According to the U.S. Bureau of Labor Statistics, companies are projected to add close to 30k software development jobs per year for the next 10 years or so.
What happens when you add more developers to a team?
When you double the number of developers, you do not get 2x faster software development. It is a well-understood phenomenon. There are many books about it. However, I am intimately familiar with two practical reasons: software monoliths and broken release processes.
Monoliths happen when software services evolve organically.
Curiously, the monolith is a sign of success: when a software project gives good returns, more developers are assigned to work on it with the goal of creating more and more value. So they all start contributing code to the same application.
Over time, problems start to appear. Builds take several minutes or even hours. Tests are very flaky. Software releases are fragile and can take a long time to ship to users.
I am passionate about cloud infrastructure and developer experience. Since leaving the Google bubble, I have been studying how other companies are dealing with the challenge of scaling their software development. Each case is different, but I have identified common challenges:
<ul> <li>teams are stuck with software monoliths, or with microservices ops hell</li> <li>the release process is broken</li> </ul>
I think there’s a significant opportunity here: what would the world look like if every company could move faster and deliver valuable software every day?
I have built infrastructure at Google that helped teams launch and iterate faster. It turns out that other companies also want to move quickly. I think I can help.
So I am starting a project to help teams have a more nimble and graceful development process. Stay tuned for more.
Do the problems above seem familiar to you? Let’s connect on LinkedIn and chat.