Scaling yourself when working harder is not an option

Last year I found myself hitting a personal limit on how much work I could execute on simultaneously. At one time, I was concurrently leading three new product lines as a Product Manager, filling in as a designer, and acting as a hiring manager. Ill-equipped to scale with the sudden increase in responsibilities, I started to see the quality of my work plummet. Working harder didn’t help — there just weren’t enough hours in the day to go around. I needed a new system.

It took a combination of prioritizing and learning to delegate to get past that stage. That’s not surprising. But like most lessons from the school of hard knocks, the lessons are obvious — how to execute them isn’t.

Delegating

As an operator, your priority is the team’s efficacy. If you are slowing down overall execution or can’t maintain the quality bar, you need to delegate. But delegating well doesn’t always come naturally. For me, what made delegating hard was:

1. Ensuring quality. I didn’t have confidence that others would be able to meet my bar.
2. A sense of responsibility. I felt like it was unfair to ask others to do what I saw as my job.
3. Ego. I didn’t want to give up projects that I had poured so much effort into.

Ensuring quality

Quality is a training issue. Either the team

1. Lacks knowledge of how to perform at the desired level
2. Lacks context that enables them to execute at the desired level

Both are solvable.

Team lacks knowledge There are definitely times when bringing in an external expert is the right move; a good data scientist or product marketer can change the product’s trajectory. For the majority of tasks, training people internally is more valuable. It nurtures trust and ensures that the team grows with you.

Effective training has three parts:

• A shared understanding of what good work looks like. Exposure to quality is a great starting point for teaching people how to discern the quality of work. Jeff Bezos describes it wonderfully:

I believe high standards are teachable. In fact, people are pretty good at learning high standards simply through exposure. High standards are contagious. Bring a new person onto a high-standards team, and they’ll quickly adapt. The opposite is also true. If low standards prevail, those too will quickly spread.

We used this approach when we needed to ramp people up on writing their own feature specs. The first thing we did was identify examples of well-written product specs and share them out.

• Breaking problems down to primitives. I believe the speed at which someone can pick up a new skill is tied to how fast they can pattern-match. Focusing on the building blocks drastically simplifies the number of situations that need to be learned ahead of time. It also proves to be more resilient as new permutations come up. For us, the specs we needed to create could broadly be broken down to documents that either addressed “how” or “what”. For each question, we tackled what data points would build trust, clarify execution, and drive productive debates. Each of these primitives then became the core of our product spec templates.
• Ongoing real-time feedback. Doing > Learning. Part of training is giving people a safe space to fail. A safe space isn’t one without consequences, but rather one where there is someone to help refine execution. My favorite rugby coach would share copious notes from our games. He made it a point to not only call out when we were screwing up, but also guide us through how we could fix it.

Team lacks context The most common reason for low quality is lack of context. I am a strong believer that rational people given the same set of context and constraints will arrive at similar conclusions. When someone else’s conclusions differ suboptimally, it’s often a signal that I failed to share the context they needed to succeed.

Effective delegation demands the team be able to make the right trade-offs in your absence. Modifying Adam Nash’s definition of a product leader, this means they need to know:

1. What game are we playing?
2. How are we keeping score?
3. What jobs are we being hired to do by our users?

Sense of responsibility

The other reason delegating is challenging is because it feels unfair to ask people to take on more work when they already have so much on their plates. So when do you delegate?

It’s time to delegate if you are slowing down overall execution or can’t maintain the quality bar. When that happens you have become a bottleneck that’s preventing the team from achieving their maximum potential.

Ego

Lastly, delegation fails when taking credit gets in the way. Asking someone to give away their Legos is a tall order.

Personally, I found it helpful to reframe how my success was being measured when I delegated. To get everyone invested in the same outcome, we would grade me on how well I was able to set someone else up for success.

Prioritizing your time

Untracked time is easily lost. When you are in the business of making every second count, that’s unacceptable. Ruthless prioritization requires a system where you can:

1. Track where your time is going
2. Check against the top priority
3. Fix any mismatches

Tracking time

The calendar is an obvious place to start tracking time. Living out of your calendar means being disciplined about capturing any meaningful chunks of time spent.

• Time-block everything. This includes not just meetings but also putting in blocks to write product docs, do research, prep for meetings, and all the other things pulling at your time.
• Use the description to label events so that you can run analytics on them later.
• Reserve time for deep thinking and improving the process so that you can get out of the death spiral of being too busy to be smart.
• Create recurring unstructured time for the team to ask you questions so that you can minimize latency in unblocking others, while still owning your time.

Capturing priorities

After identifying which tasks to track comes tracking the tasks themselves, which can be a challenge especially when the priorities evolve rapidly. Taking a page out of Getting Things Done, I have been using a running doc to capture and prioritize tasks.

• Track three different time horizons: day, week, and quarter.
• Start each day, week, and quarter with the top three priorities for the day.
• Check things off as they get done and re-evaluate after each interval to see if the priorities for the next interval are on track.
• Track due date, owner, and next steps for every task.
• For every new high priority task that comes up, evaluate if it’s more important than what’s on the list.
• Make it public so that your team knows what’s on the list and can give feedback.

Fixing mismatches

Reconciling mismatches requires active intervention. For me, that came in the form of ending the week with deliberate reflection time and asking:

• Is there enough time allocated for the task to be successfully completed?
• Is it still the most important task?
• Am I still the best person to do it?
• Is this still the best way to execute?

I would love to learn from you on how you grew. If you went through this at a different scale, what I should keep an eye out for looking ahead? Let’s keep this conversation going here or on Twitter @mbe