Managing at Scale by Terry Crowley
These are notes from Terry Crowley on how to manage at scale, like when running Microsoft Office:
• Don’t do stupid shit: Stopping yourself from doing stupid shit is at least as important as being brilliant and wise:
• Simple and unambiguous messages: Leaders of big teams need to come up with and communicate simple messages. When Office was taken agile in 2010, the simple message was that instead of going weeks with the build broken, “every build will be a dogfood-ready build.” Management initially considered saying that “there should be two dogfood builds a week” but abandoned that message since it’s prone to interpretation: if the team delivered a dogfood build on Monday, when was the next one due? Wednesday? Teams may put it off till Friday, at which point some other team might destabilise the build thinking that the second dogfood build for this week has already been delivered. Or the work may turn out to be complex, and the second build may not be possible till next week. Complex, nuanced messages won’t be understood by people in a large org. When you run a meeting as a manager, after the meeting, ask people to repeat what you said. You’ll be horrified to hear summaries that have nothing to do with what you said. Even simple messages will need to be repeated again and again to be understood.
Note that simple and ambiguous messages are no good, either, like “We’ll launch when it’s ready”. Different people will have a different bar for “ready”. So messaging should be simple and unambiguous.
• Measuring the right thing: In a complex system, ensuring that you’re measuring and iterating on the right things is a huge part of the problem. To take office agile, continuous stability is important. When the team worked to create a dogfood build every day, they automatically stabilised master. Often, teams work diligently for multiple iterations over many months, only to find they didn’t make progress, because they iterated on the wrong problem. Or they didn’t measure, so they had no way to compare where they are today vs when they began.
• Modeling: Large organisations need significant modeling and analysis to validate goals before committing to them. For example, before deciding to create a dogfood build every day, the team first needed to validate that it was possible considering that there were thousands of engineers, hundreds of lines of code, and terabytes of build output.
• Business model: Network effects like sharing and collaborative authoring benefit hugely from having everyone on the same version of the code, which requires a business model that supports it. That’s either subscription or ad-supported. If you’re selling a perpetual license to version 4 of your software, your business model comes in the way of agile and in the way of product improvements reaching the most users with the best user experience resulting in increased usage of the product.
• Framing goals: Managers need to clearly frame goals like “Reduce the battery consumption of Windows”. This framing should include constraints like time: “Reduce the battery consumption of Windows in 1 year without redesigning the hardware like Apple.”
• Accountability of explanation: As a manager, you’re accountable to articulate the goal, why that is the right goal to work towards, and what your basic thesis is. Once you’ve communicated this to the team, you should be open to an honest challenge from their team. In fact, the more power you hold, the more open you should be to honest challenge. Your argument typically starts with facts and then uses logic to reach a conclusion. You should be open to be challenged on both the facts and the logic.
• Listening: When there’s a disagreement, managers need to listen to each person carefully, write down what they’ve said, and validate it. Writing down ensures that the manager has actually understood what the person is saying. It’s a mistake for a manager to disagree without understanding. Once people are convinced they’ve been heard, they’re fine even if the final decision isn’t what they’d have taken. People want their input to be factored into the decision.
• Transparency: Managers should create ensure transparency by tracking progress day-to-day. Dashboards should show objective metrics like how many bugs have been fixed. Not subjective metrics like thumbs-up/thumbs-down, or red/yellow/green. For example, asking each engineer whether he’s on track is a subjective metric. People may say yes because they don’t know any better, or they didn’t have time to think of an answer when they’re asked a question but needed to answer somehow, or because they don’t want to look bad to colleagues. A burndown chart is an objective and therefore better way of answering the same question.