(Part Two of The Seven Areas Of Software Management)
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: willingness and 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 manage a project to deliver a goal. You manage process to optimize the delivery of multiple goals simultaneously.
Understanding Your Position
To get on top of your state for each:
- What projects are you committed to?
- 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?
- 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?
The main thing here is not just understanding state, but understanding perception of state. A large amount of tension in organizations is disagreements on relative priorities and amount of effort they need, stated though in terms of frustration at execution rate. So strategy in this area is developing mechanisms to enable that communication 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 always working on the most important thing
- 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 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: How much information is gathered to improve quality of future execution.
There is no set of tradeoff right for all teams in all circumstances. Which means there is no 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 that part of that is all stakeholders agree. Again 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 (different teams working to different priorities) and/or mismatched expectations.
The combination can cause other stakeholders to create narratives about why your team isn’t delivering the “right” things. This can in turn cause a lot of negativity in relationships, which you may want to blame on others selfish expectations of their priorities being the “right” priorities. However, unless you are spending the time communicating to help them understand the tradeoffs, what else should you expect? I call this communication “owning the narrative”, and it’s important across almost all 7 areas. 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
The other important thing about strategy in this area is it’s where two techniques become important: “saying no with data”, and “delegating with supervision”. The reason is for a team in a fast moving organization of > 150 (see rule of 150), then after subtracting the time to do the bare minimal in the other 6 areas, all the time of a line manager can easily be taken by this area (i.e. including all the project management and communication). Indeed my first three years in EC2, this was the case. Now if you have a small team with a highly important goal, this can definitely be the right thing for yourself, your team and the company. This was also true for me in EC2, but only the first two years. The challenge is when the org also wants you to start growing your team size, above about 8. Then you need to find more time and focus to be strategic in the other areas.
So what do I mean by 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 obviously you need to ask for priority. But what you find if you ask, and then say “yes that makes sense” is whoever is coming to you is almost always unaware of global prioritization, even when they think and assure you otherwise — “our VP really wants this” (they always want many things), “this is my orgs number 1 priority” (your orgs priorities aren’t the same), “this is our common VPs number 1 priority” (you learn 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 then you do.
Now what you then find is in the moment, reactively resolving all the tradeoffs can take a lot of your time — lots of learning, lots of communicating. 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 understand how 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.
I will come to other mechanisms later. But to start getting on top of Execution, you need to start asking your engineers to own some 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