Simple Messages
When managing a large scale engineering effort, I have always felt the best advice is “Keep the message simple.” If you really want the entire organization to understand and act on something in a consistent way, you have to figure out how to keep it simple. It’s just impossible to communicate a nuanced message to a large team.
A “simple message” means that it can both be concisely stated as well as unambiguously interpreted. For the Microsoft Office organization, the most obvious example has always been the “ship date”. The message “we are going to ship on March 2, 2001 (3/2/1)” was a very concisely stated and easily remembered message for the Office 2002 project. The message was repeated in every email from the head of the division, Steven Sinofsky. For any given team, the implications were complex with respect to features selected, the process of designing and implementing features, managing the bug curve, learning from beta feedback and final stabilization and shipping. But it was really, really clear what the constraints were. Those constraints impacted everything, including features selected and dependencies accepted. It was especially useful in coordinating with different teams since everyone was operating from a clear understanding of the shared constraints and timeline.
In contrast, the message “we’ll ship it when its ready” is concisely stated but wildly ambiguous. It provides no real framing for decision making and no clarity on how other teams are going to behave and act. Coordination becomes complex and painful.
This advice applies at all scales. I would often see this communication challenge on a relatively small team of 25 developers. You carefully work on a well-crafted email. You then reinforce the message in the dev meeting, walking through each step in the plan. And then if you wander down the hall into someone’s office and ask them to play it back for you, 80% get it wrong. So you learn to keep it simple. “We’re working on old bugs this week.” “Fix your dogfood blocking bugs first.” etc. Of course, each person will execute within their local context — you want them to be applying local insight — but you will have gotten your message across clearly.
As Office started working on more products on more platforms, “one big ship date” became less of a clear single message. We started shipping more frequently and breaking some of the constraints that bound things together. That was great for agility, but increased the risks of diffused coordination costs. There were still lots of opportunities to keep the message simple. A couple examples from the Office 2016 project stood out for me.
One of the key engineering tools we drove through Office 2013 and the Office 2016 was a much more rapid and predictable daily build and dogfood process. That’s standard process across the industry but doing that at the scale of the overall Office product across thousands of engineers and thousands of check-ins a day is an enormous challenge.
This rapid deployment drove many of the other behaviors that we were trying to reinforce around continuous integration and stability. As we started standing up the Windows 10 Universal Office apps, we went through a long period where we weren’t producing regular dogfoodable builds. This tends to be a vicious cycle since before the latest blocking bug is fixed and deployed, someone else has checked in the next blocker. As we worked through how to get ourselves to a better state, we discussed whether we should communicate the goal of some intermediate state like “two dogfood builds a week”. Ultimately we decided that that message was too hard to interpret for individual teams. We decided to go with the simple message that we expected every build to be dogfoodable even though we knew it was not feasible immediately. We were able to dig out of our hole and get back to a much more predictable cadence with a clearly understandable goal that everyone was acting against.
Another challenge arose near the end of 2014 as we were working towards finishing the Office on Android project while at the same time readying our Universal apps for the Windows 10 January 2015 technical preview. Since we were sharing much code between the Universal and Android products, this was probably the first time in Office history that we were trying to both ship a final major product and also ship a major preview release at the same time from the same code base. There was lots of concern about how to manage the final stabilization and whether we were going to have “cross-talk” between the two projects where goals for the Windows technical preview and the Android release were going to conflict. We considered lots of different branching approaches and timings to isolate concerns between the two projects.
Ultimately we decided this was just too complex to message and manage. Since much of the code is shared, individual teams and individual engineers were going to be managing decision making for both projects. Having separate triage and stabilization timelines was going to be too hard to manage and keep straight. We also knew that we wanted to be taking the initial steps to getting to a much more regular monthly shipping cycle. We decided that this was the right time to start with the strategy of always shipping from the end-of-month fork, beginning with shipping both Android and the technical preview builds from that fork. Individual teams still had issues to manage and risk to assess with respect to code in both projects, but they had a clear framing and knew that all the other teams were operating against the same goal.
I thought this was a particularly interesting case because it reinforces how you can look back at some of these simple messages and not appreciate how many more complex alternatives were considered and discarded. That can sometimes cause you to undervalue how important “keep it simple” was as a guiding principle. It can sometimes look like “simple” must have been the only choice. In practice we probably have an unlimited potential to make things complicated; it takes intentional effort to keep things simple.
