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 3 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 were not enough hours in the day to go around. To put it mildly, I needed a new system.

It took a combination of learning to delegate and prioritizing 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 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. Sense of responsibility, I felt like it was unfair to ask others to do what I saw was 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 the tasks, training people internally is more valuable. It nurtures trust and ensures that the team grows with you.

Effective training has three parts:

  • Shared understanding of what good looks like. Exposure to quality is a great starting point for teaching people how to discriminate between 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 up people on writing their own feature specs, the first thing we did was identify examples of well-written product specs and shared them out.

  • Breaking problems down to primitives. I believe the speed at which someone can pick up a new skill is tied to the speed with which they can pattern match. Focusing on the building blocks drastically simplifies the number of situations that need to be learnt 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 type of question, we tackled what data points would build trust, clarify execution, and drive productive debates. Each of these primitives than 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 guiding 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 are likely to arrive at similar conclusions. When someone else’s conclusions differ in a suboptimal manner, 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 because it feels unfair to ask people to take on more work when they already have so much on their plate. 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. But 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 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 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

Independent of what tasks to prioritize, is tracking the tasks themselves, 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.
  • Make it public so that your team knows what’s on the list and can give feedback.
  • For every new priority that comes up, evaluate if it’s more important than what’s on the list and track due date, owner, and next steps.

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, and if you went through this at a different scale, what I should keep an eye out for going forward.