During WWII, while serving as a staff officer Dwight Eisenhower developed the idea of Complete Staff Work. The idea is written up well in The Characteristics Traits And Skills Of The Successful CEO. I think the idea need not just be for CEOs and their directs, everyone from an organization could benefit. The idea is that when communicating with your manager it should include all the necessary research organized into clear thinking. Specifically, it should include:
- Identify the decision to be made;
- Identify the stakeholders in that decision;
- Identify the constraints and resources available;
- Frame the question and obtain input from the stakeholders;
- Review and evaluate all of the possible decisions including doing nothing;
- Present the decision to the decider with all of the alternatives fully discussed
- Make a single recommendation, explain why and be prepared to defend it
I would add a few more specific to software teams:
- If multiple teams are involved:
- Who owns which parts?
- What are the cross team dependencies? When will upstream dependencies be completed for downstream partners?
- How will progress be measured? How do we get feedback throughout on how we’re doing?
It’s a tough bar, I definitely don’t always do these things when taking ideas to my own manager. For example, I a couple times I’ve asked if we can get budget for activities without bringing a clear value prop and project plan to the table. It’s hard to argue that it would be better for everyone if I consistently did this right. Or at least if I was gathering input from her, to tell her that’s what I’m doing, and I’ll bring back a full proposal later.
Several great things happen as people start doing this.
- Manager and employee don’t have to go back and forth playing 20 questions
- The organization makes better and faster decisions
- The employee prepares themselves to be promoted to be the manager
The core idea of complete staff work doesn’t have solely for proposals. It’s can also be thought of as really doing the complete job when being delegated something, and at every twist and turn figuring out “if my manager wasn’t here, what would I do to take this all the way to the finish line?”
This is something I notice in standups a lot where updates often communicate activity, but not meaningful executive insight and recommendations. A good example of how this shows up in standups for software organizations: “I got pulled into a this issue with our production server yesterday, we finally got it fixed.” The manager is left wondering several things, “what do we need to do to prevent this surprise issue in the future? Do we have the right staffing and role assignment in place? What about the work you forsook to do this? Presumably it’s now off track and not going to come in on deadline. Who do we need to tell about that? Is there a mitigation plan we can compose to keep the project on track? If not, tell me you thought that through and that we should expect this work to be back in the next sprint.
Part of how employees can master this is to look at the questions that get asked when they do bring half baked plans to the table. If you keep getting asked a question, start preempting it. Another helpful tip is to think backwards from your company/team OKRs all the way to your project. If you want to change something, does it positively affect OKRs? If it’s neutral or negative, is that because we have the wrong goals or your idea is maybe a bad one?
An easy objection to the notion of complete work is “hey this is going to make my job really hard!” or “does this mean I can’t just casually chat with my manager and get feedback?” One simplifying principle is to apply this principle of complete work when the stakes are highest, and know that you can relax a bit when the results at stake are less important. Also if you think it’s going to take you more time, think about all the questions your are saving yourself from having to volley with your manager–not to mention the time you’ll be saving for them.
I’m starting an experiment to work with my more Senior Engineers to have them try pushing the thinking a little bit further forward, and see if that speeds us up as a team.
Further Reading
The original memo from Eisenhower pages 1 and 2.
Jade Rubick, also writing from the perspective of an Engineering Manager, explains the idea and also mentions that you can break complete staff work down into iterative chunks so that it’s not such an overwhelming project to complete up with a fully complete answer to a wider issue.