In this episode of McKinsey on Building Products, a podcast dedicated to the exploration of software product management and engineering, McKinsey partner Rikki Singh spoke to Scott Johnston, CEO of Docker. They discuss the importance of continual experimentation and adaptation in scaling platforms, the role of internal tools and infrastructure, and the process of building a sustainable, high-performing developer culture. This interview took place in September 2023 as part of McKinsey’s Engineering Academy speaker series. An abridged version of their conversation follows.
Scaling platforms through focus, simplification, alignment, and repetition
Rikki Singh: What moments shaped your career leading up to your role as CEO of Docker?
Scott Johnston: One of my first jobs was as a software developer at Sun Microsystems when it was still a standalone business in the late ’80s and early ’90s. We were working on a fantastic high-end graphics system. It included hardware and software, and it was a beast. We spent two to three years working on the project, then we shipped it, and it failed. Customers did not like it. In retrospect, early in my career, it taught me an important lesson of ensuring that there’s clarity throughout the organization on who our customer is, what their pain is, what they are willing to pay for to solve that pain, and what alternatives they have to solve that pain.
Now, as a CEO, this experience taught me to make sure I am leading my team with a clarity and understanding of what we are solving for and what we are driving toward. In a start-up, high-growth environment, it can be difficult because the information is imperfect—it is unclear where markets are going. But my role as a leader is to drive for that clarity every day.
Rikki Singh: As you go from being a builder to the CEO of a fast growth company, what are your top learnings on scaling a company successfully?
Scott Johnston: We’re all students in some sense because as tech changes, the industry changes, and there are always new things to learn. Four themes have been most resonant when scaling companies: focus, simplification, alignment, and repetition.
All systems are subject to entropy. The more employees you have, the more customers you acquire, and the more technology you use, the greater the risk. I have scaled several start-ups, and having focus is incredibly important. For Docker 1.0, we had to undergo a recapitalization restructure because we had too many irons in the fire: too many customers, personas, use cases, and products. The recapitalization aimed to help the company to regain focus on one persona, one product, and one use case.
Subscribe to the McKinsey on Building Products podcast
That leads to simplification. Simplifying the communication around the go-to-market strategy, the product development, and all the teams involved is vital. If teams do not know who the users are and what their problem is, new employees will not be as grounded or focused, which can disrupt alignment.
Alignment involves embedding your strategy into your company’s operating system: the rewards, promotions, and OKRs [objectives and key results] that tie back to focus and simplification. At Docker, we have two major KPIs, which distill into the OKRs, the reward system, and the promotion system. No one should wonder how they get measured or how the company works, because we have established alignment using the company objectives.
Last is repetition. As leaders, we are “chief communication officers.” We should be repeating the focus, simplification, and alignment in all forms of our communication, so it always comes through.
Rikki Singh: How do you know that you have picked the right thing to focus on? How would you then think about prioritization?
Scott Johnston: As a small company or a small team, you can’t do everything—you can’t do more than one or two things. We have found that focusing on one thesis and experimenting against it—whether it is for go-to-market or product strategies—gives small companies the confidence to keep going and keep investing when they find success. In 90 days, for example, if it is not working, that’s when you can cut losses and rethink your thesis. We should be nimble and ready to change course when ideas are not working. As we have gotten scale, we can afford to do more portfolio management. But those portfolio bets are still scoped with a thoughtful thesis and still given a tight lifeline.
Rikki Singh: For larger organizations, that “kill it if it’s not working” part is sometimes harder because of the sunk cost fallacy.
Scott Johnston: People make their careers recommending one thing, and they will find ways to justify it. It is hard. For leaders, it can’t be about the person or their decisions—it’s about the company. If you’ve made a decision and have looked at the results and the outcomes aren’t there, it’s best corporately to kill it and move on.
Empowering developers to unleash innovation
Rikki Singh: Developers are key to the success of software organizations, and they need infrastructure to support them. What is your vision for the future of developer tools and infrastructure?
Scott Johnston: We always have found it helpful to view developers as creators. If you treat them as a creative class, then you can consider what tooling they need and what guardrails or broad frameworks you can give them so they can be successful. Have standards and tools that let developers accomplish what you think their outcome is and make the tools flexible enough that developers can create something that you couldn’t envision. We couldn’t have envisioned a lot of what has been created on Docker’s Hub. Finding the right balance between guidance and flexibility has unleashed a lot of innovation, which is cool to see.
Rikki Singh: How do you create scalable, automated tools and infrastructure that remove friction but also allow developers to focus on the right pieces?
Scott Johnston: As a creator class, developers want choice, but there are extremes that are unfavorable. Without constraints, it gets unruly and everyone’s reinventing the wheel, which hinders productivity. Too many constraints are also dangerous. The best developers leave because they cannot flex their creativity or explore.
Here’s an example that we have seen at several of our large customers. They’ll segment the network and give developers a lot of flexibility. They can download open-source packages and play around, but there’s a hard segmentation between the dev [developer] network and the staging and beyond networks. To get through the dev network into staging and beyond, the rope is much tighter. There are criteria for submitting and kicking off the CI [continuous integration] and checks to go through before you can continue down the pipeline. That’s one way to encourage exploration early in projects. Developers can try different technologies, but to move on into a staging environment or production environment, there are clear guardrails. It’s a good balance.
It’s also important to give developers choice—but not too much choice. So provide two or three languages and two or three frameworks in those languages but not infinite languages or frameworks.
Measuring success
Rikki Singh: What is the right level of investment in these horizontal capabilities? How can organizations prioritize and value these investments without getting distracted by new products to build?
Scott Johnston: We’ve seen some metrics emerging. There’s demand for 750 million new apps in the next couple of years,1 which is enhancing the demand for developers. Since COVID-19, the demand for developers has grown much faster than other occupations, but demand is outstripping the supply. So one KPI many companies have is ensuring developers are productive as soon as possible. It entails measuring if companies are getting value out of their investments in developers. The second KPI is the velocity at which a company can move from an idea on a laptop to running in production. Every day, our customers are trying to compress that time frame.
Rikki Singh: The time it takes to go from idea to production speaks a lot about the efficiency of the pipeline. Is there tooling that helps measure cycle time from the first edit to production?
Scott Johnston: There’s an emerging category of tools to help customers with this, and some customers build out custom tooling to measure these outcomes as well. We’re huge fans of ‘release early, release often.’ If a company hasn’t shipped to a customer in six months, they’re failing. So the last time you shipped to a customer is an interesting metric—if it is more than a couple of weeks, something is wrong.
Rikki Singh: How do companies typically measure this?
Scott Johnston: Our customer base tends to focus on two dimensions. One is the quality of the code: in addition to passing tests, is it designed for maintainability, security, and the other criteria you need to meet after you ship? Second, they measure if they are helping their customers to become amplifiers or multipliers in their organization: are they working with the junior developers to show them how to extend their impact?
If you hire outstanding developers and include them in interview panels for new talent and developing the team, then it can create a virtuous cycle. If you get your team right, then it can self-moderate to make sure everyone is meeting the standards of the organization.
Making the right investments in tooling and infrastructure
Rikki Singh: How can companies drive the adoption of the tools and infrastructure they’ve invested in across the organization?
Scott Johnston: The most successful pattern we’ve seen is offering developers choices. With those choices, everything’s automated all the way through CI and production. Getting that right requires companies to treat their internal tools like a product. Successful teams are bringing in internal product managers to understand the needs of the developers. When they get that right, success breeds success. When one team adopts automation, for example, and starts shipping at a higher quality, other teams will notice and want to try those tools, too. Teaching developers what tools can do can be demonstrated successfully through internal hackathons and internal brown bags.
Rikki Singh: Should companies set up a developer ops team or something similar to identify developers that can empathize with others and bring them together to do these internal problem-solving sessions?
Scott Johnston: They would have to be someone who has been in the developer’s shoes or used to be a developer and has now shifted gears to product management. There is a deep need for empathy when defining the requirements that determine what a platform looks like. DevOps teams have tended to focus on pipelines and aligning standards between developers and operations; only recently they have become responsible for the developer experience as well. Successful product managers have developer experience and the empathy to ensure the platform works around the automations and frameworks and is aligned with what the engineers need.
Rikki Singh: How do generative AI [gen AI] tools affect the engineering experience? What are the pros and cons?
Scott Johnston: It is an exciting time—but it’s also very fragmented and moving quickly. Because of the fragmentation, no one knows where to start. If you can get started, the productivity benefits are off the charts because you eliminate a lot of the toil of development. For example, you can get Docker Compose and Docker files up and running with a pretty good out-of-box experience as a result of the gen AI LLM [large language model] work. It is important to watch what the gen AI is producing because it can hallucinate, but the fact that these tools can do this work for you to check is very different from you doing it all from the bottom up. That has been a game-changer, and it’s going to get better as we learn how to make these tools more accurate.
One challenge or opportunity is to get data scientists more involved in the engineering discipline. Software engineers know a lot about change management, the discipline of pull requests and code reviews, and the discipline of product releases. Data scientists are not as dialed in to those, so getting them more involved would help them apply that engineering discipline to ML [machine learning] and gen AI.
In the future, gen AI and building applications should be part of one pipeline. Building an app takes data and models in addition to source code and container images. Making gen AI part of that pipeline too will help bring the two disciplines together before you ship the product.
Rikki Singh: Do you see companies bringing together these pipelines?
Scott Johnston: Yes. For example, at Docker, container images are being used as the unit of shipping for ML models. Container images make the models reproducible. For ML modeling, it’s not the best abstraction. There are ways to get more power out of ML models outside of container images. Therefore, we have some work to do, but the community is all racing toward this together.
Rikki Singh: What are some of the most successful ways companies can harness the power of open source and community engagement at scale?
Scott Johnston: Host internal hackathons and then make the results of that accessible to the rest of the company. We’ve seen companies set up internal registries for developers to contribute their own creative works, which has been helpful. Organizations that are proactive and innovative can also dispatch their senior developers to explore spaces outside the company and report back their findings. Those are ways to use both the dynamics of open source internally and benefit from open-source innovation that’s happening outside the four walls.
One challenge to keep in mind is making sure you’re not giving away too much code for free. If companies don’t have a thesis about how to monetize what they’re putting out there or have a way to measure it, they may end up giving away too much—other organizations could take that open source and start making a lot of money on it. Draw the lines of where you monetize versus where you allow consumption and bottom-up open-source dynamics to work.
There are a lot of precedents that have gone before us that can help you think through it. For example, security people care about SSL [secure sockets layer], but developers don’t. SSL is a monetizable feature, and you don’t have to put that in the open-source world for developers. Think through your thesis on what’s going to monetize and where you’re going to draw those lines before you provide it to the public.
Building high-performing engineering teams
Rikki Singh: What is the role of culture in creating high-performing engineering teams? And how do you quantify what a good engineering culture looks like?
Scott Johnston: At the end of the day, developers want to see their work in the light of day and have it be loved by their customers. I’ve seen healthy engineering cultures that are aligned behind this motive. They’re not working just to play with tech for tech’s sake; they’re working to use powerful tech, have fun learning as a team, and deliver outcomes for their customers. In my experience, aligning on the outcomes is a healthy way to prove if you have a high-performing engineering culture.
Rikki Singh: How have you enabled high-performing teams at Docker?
Scott Johnston: We have encouraged our developers to get out into the community. We have a community chat group that everyone has access to, for instance. We also have a standing monthly sync with our community that developers are invited to so they can demo their stuff and get feedback from the community directly. We try to set up venues for developers to talk to other developers.
In terms of reward, developers who do well in the organization are the ones who are talking to customers. We signal the community through rewards and promotions.
To create a very positive virtual feedback loop, you have to give teams low-friction access to both the customer voice and the developer voice.
