Last year I found myself hitting a personal limit on how much work I could execute on simultaneously. At one time, I was concurrently PMing 3 new product lines, 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.
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: Ensuring quality, didn’t have confidence that others would be able to meet my bar Sense of responsibility, felt like it was unfair to ask others to do what I saw was my job Ego, didn’t want to give up projects that I had poured so much effort into
Quality is a training issue. Either the team
- Lacks knowledge of how to perform at the desired level
- 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 provides higher returns on trust and ensures that the team grows with you. Effective training shares three parts:
- Shared understanding of what good looks like. Exposure to quality is a great starting point to discriminate between quality of work. Jeff Bezos has a wonderful line in the Amazon’s shareholder letter:
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.
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. This served both as the baseline to aspire to and as
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 primitives drastically simplifies the number of situations that need to be matched upon and proves to be more resilient as new permutations come up. The specs we need 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, communicate execution, and drive productive debates. We ran critiques on the specs to tease out what made them good.
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 coach in high school would share copious notes from our games, tracking our inefficiencies, identifying the changed that needs to be made, and then communicating them in such a way that they can be acted upon.
Team lacks context The far more 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 we failed to share the context they needed to succeed. Solutions are only as good as the problems they set out to solve. Repurposing Adam Nash’s definition of a product leader, for effective delegation the team needs to be able to make the right trade-offs in your absence. Which means they need to know:
- What game we are playing
- How we are keeping score
- What jobs are we being hired to do by our users
Sense of responsibility
The other reason delegating is challenging because at a it feels unfair to ask people to take on more work when they already have so much on their plate. So when do you know to delegate? In Eli Goldratt’s book, The Goal, he popularizes the idea of speeding up the entire system by finding and eliminating bottlenecks. If you are slowing down overall execution or can’t maintain the quality bar, you have become a bottleneck that’s preventing the team from achieving their maximum potential and it’s time to delegate.
Lastly, delegation fails when taking credit gets in the way. But asking someone to give away their legos without reframing their measure of personal success is a tall order. Personally, I found it helpful to have a conversation with my manager and peers in other functions to discuss who would learn the most by taking on the task. To get everyone invested in the same outcome, we then grade ourselves on how well we set them 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:
- Track where your time is going
- Check against the top priority
- Fix any mismatches
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.
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 reevaluate 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.
Reconciling between where time is being spent vs where it should be requires active intervention. For me, that came in the form of ending the week with deliberate reflection time and asking
- Is enough time allocated for the task to be 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 on it?
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.