Management Area 2: Execution

(Part Two of The Seven Areas Of Software Management)

Overview

This is the second easiest area to get on top for new managers, as it’s usually one of the reasons they are made a manager: the ability to get groups of people to coordinate to execute and deliver. There is two aspects of managing execution:

• Project Management: managing individuals to deliver a single goal.
• Process Management: managing what your team members are working on as they are being asked to work on multiple projects/goals.

You project manage to deliver a goal. You process manage to optimize the simultaneous delivery of multiple goals .

Understanding Your Position

To get on top of your state for each:

Process:

• Do you understand the full list of projects and other goals your team needs to deliver?
• Do you understand their relative priorities?
• Are you overcommitted?
• How well is your team executing on the commitment?
• Are people inside the team happy with your state?
• Are your partners, management and customers happy with your delivery rate and schedule?

Projects:

• For each project your team is being asked to do, is there a clear project owner? If not, are people assuming you are the owner?
• What are the deadlines that your team needs to hit to not be the long pole?
• For those projects you own: What buffer do you have? What risks are there that will eat that buffer? Do your partners, management and customer understand the risk?

The thing here is not just understanding state, but also understanding perception of state. A large amount of the the tension in organizations is disagreements on the absolute priorities of projects. However this gets stated by stakeholders frustration at execution rate on their favored project. Thus, succeeding through strategy is developing mechanisms to enable the communication of priorities to happen.

Getting on top of Strategy

Both project and process management have a great deal written about various techniques which I won’t recount. What I will say is they are optimizing differently across:

• Prioritization: Ensuring teams are working on the most important things
• Throughput: Optimizing the delivery pipeline; minimizing throw-away and duplicated work
• Risk: minimizing variability on quality and time of delivery
• Agility: Delivering high-value work earlier to get feedback to allow course correction. This allows risk taking innovation while avoiding rabbit holes.
• Communication: Maximizing information and minimizing overhead in coordination and collaboration of everyone doing the work
• Commitment: solving collective action problems across partners on implementation tradeoffs impacting them differently
• Visibility: Providing management with visibility into delivery state, and so allowing escalation to resolve roadblocks and other challenges
• Feedback: Creating information to improve quality of future execution

There is no set of tradeoff right for all teams for all circumstances, which means there is no single “right” project or process management technique. Instead you need to be continually evaluating if you are optimal at this point in time, with a focus on understanding if all stakeholders agree. The biggest problems in execution are not usually a team not working hard on important things, rather it’s lack of communication about the tradeoffs in priorities on what the team chooses to work on, which causes wasted resources due to different teams working to different priorities, and mismatched expectations.

This can cause stakeholders to create narratives about why your team isn’t delivering the “right” things. This can cause a lot of negativity in relationships, which you want to blame on others selfish expectations of their priorities being the “right” priorities. However, unless you are spending the time communicating to help the organization understand the tradeoffs in all priorities, what else should you expect? I call this communication “owning the narrative”, and what I mean by it is:

• You need to have a strategy
• You need to communicate that strategy
• You need to be seen to deliver on your strategy

Thus proposed goals to take are:

• Goal: Improve team’s process by implementing X (e.g. implement scrum, Kanban, etc)
• Goal: Creating a mechanism to measure and communicate teams ratio of time spent between operations, tech debt reduction, and features, in a way that informs planning and stakeholders
• Goal: Deliver 80% of quarterly OKRs. For all OKRs not hit, they should be escalated as stretch/miss at least a two weeks before due date.
• Goal: Reduce backlog to X items by Y, ensure it never goes above X for the rest of the year
• Goal: Own project management to deliver very important cross-team OKR X on time by date Y

Saying No With Data, And Delegating With Supervision

Two technique for success here are “saying no with data”, and “delegating with supervision”. The reason is for a line manager of a team in a fast moving organization of > 150 (see rule of 150), after subtracting the minimal time to execute tactically in the other 6 areas, the remaining time can easily be fully consumed by this area (i.e. including all the project management and communication). Now if you have a small team with a highly important goal, this can be the right thing for yourself, your team and the company. The challenge is when you start growing your team size, above about 6. Then you need to find more time and focus to be strategic in the other areas.

What is “saying no with data”? My old line in EC2 was “the two wrong answers when you are overloaded and asked to do an additional thing are yes and no.” Just saying “no” means you will be seen an obstructionist, so you need to ask for the priority. But what you find then is whoever is coming to you is almost always unaware of global prioritization, even when they assure you otherwise:

• “our VP really wants this” (but VPs always want many things)
• “this is my orgs number 1 priority” (but your orgs priorities aren’t necessarily the same)
• “this is our common VPs number 1 priority” (here you learn some VPs have many number 1 priorities).

This can include even when it is your manager asking you; they often have a lot less context on your roadmaps priorities and tradeoffs than you do. Now in the moment, as long as you are aware of not assuming what someone says is what is true, then with a decent amount of time and effort you can resolve the ambiguity. But then a different stakeholder will come along with the next ones. And thus being strategic is spending the time and focus ahead of time, gathering the data in a manner you can reuse when these questions come up. Thus suggested goals are:

• Goal: Deliver a scoped 12 month roadmap of currently known executables

With this, seeing the impact of an additional ask is quickly visible to yourself, whoever is asking, and whoever you need to escalate to get a tradeoff decision.

Delegating is for things being asked of your time and focus; finding a way to say yes by giving some of that to someone in your team. Delegating with supervision is an additional notion that comes from Andy Grove with the key aspect that you have some aspect of supervision to help the delegate succeed. There is a bunch of writing on how to delegate. Amazon treated it a very specific way, which was to talk about mechanisms. This meant creating a “mechanic” system whereby the delegate, with your supervision, is set up to succeed. This means 5 things:

• A goal
• Identification of the stakeholders who need to cooperate for the goal to be reached
• Recognition of a clear owner (i.e. the delegate), the important thing is all stakeholders recognizing their ownership
• A criteria for which success/failure can be ongoingly judged
• A periodic or edge triggered communication agreement for all stakeholders that facilitates coordination towards goal.

Project management is one of the easiest mechanisms to set up: a project manager owns a feature with a deadline date, defines milestones as ongoing measurement criteria, hosts a status update meeting for all stakeholders after each milestone. To start getting on top of Execution, you need to start asking your engineers to own some tactical aspects. This is sometimes hard because the only people who seem to like project management are project managers, but project managers are usually not worth their overhead unless a goal is particularly big (nominally >2 dev years, >4 teams). But asking people to do the right thing to grow is part of being a manager. And so the type of goal to take is:

• Goal: Coach lead engineer X to own project management of execution of cross-team OKR X