Petro.blog

Software engineering: a decade later

2026-08-22T00:00:00Z

I’m one month into my transition from engineering management and product to hands-on software engineering after nearly a decade away from it. The biggest change is the role of AI in software development. Here’s what I’ve noticed so far.

One of my first assignments was to create a generic library for building search facets from a dataset: given a table, determine which columns are usable as discrete filters and what their distinct values are. I used frontier AI models to plan and implement it, but I found that this produced a confusing class structure and functions that were difficult to use. This would have been immediately obvious to any human actually trying to use it. I started noticing this same pattern elsewhere.

AI works better for me as a sounding board than as a primary author for designing systems, control flows, and software interfaces (like class structures and function signatures). A good interface depends on a feedback loop where the pain of a bad design decision makes it back to its designer. A bad interface becomes painfully obvious the moment you use it. AI is immune to this pain, breaking that feedback loop. Better prompting seems to help, but only to a point. Lived pain is the best teacher.

For me, no amount of reviewing code produces the same richness of understanding and joy that coauthoring it does. While it certainly feels productive for AI to generate everything for me to review, it also feels hollow. And it defeats the whole point I moved from management back into hands-on engineering: to create, not only manage. I've already started to see experienced engineers I respect move completely away from agentic coding because of this. For me, then, authoring key class structures and function signatures but delegating their internal implementations gives me the best balance of speed, quality, and creativity. This reminds me of README-driven development: define how you want consumers to be able to use your library/class/function, and then design and implement it to achieve that.

The broader lesson I’m seeing is that a human should make the decision when it directly affects another human, or when making the decision is how you get better at making them.

My README

2026-06-16T00:00:00Z

A practice that's emerged with managers is to publish a document explaining what's important to them and what it's like to work with them, inspired by the README files that accompany software. I'm joining North as an engineer, not a manager, but the idea is just as useful between teammates. Here's what you'll learn about me: my background, my beliefs, how I work, my strengths and weaknesses, and how to give me feedback.

My background

Most folks here won't see my resume, so a bit of context. I've spent most of my career as a software engineer, several years as an engineering manager, and a few more as a product manager, at companies like Disney, Next Big Sound (acquired by Pandora), and Pandora/SiriusXM. That mix means I care as much about why we're building something and who it's for as I do about how it's built. I'm here as an engineer, but I'll naturally bring a product and process lens too.

My beliefs

I'm biased by my experience, like everyone is by their own. I try to recognize this by staying open to other perspectives and evolving my own as a result. Still, there are a few ideas I hold more strongly than the rest:

Assume positive intent. "Be kind, for everyone is fighting a hard battle." Everyone is trying their best with what they have, so be kind, and be curious rather than judgmental. When things don't go well, give people the most generous interpretation of their actions instead of the most malicious. It's us versus the problem, not each other. This is one of the beliefs I hold most deeply.
Everything can be changed. Nearly everything we use today was created by people like you and me. Changing things just takes time and pressure. When things don't change, it's not because they can't, but because someone gave up first.
Everything can be learned. Nobody was born knowing how to play the piano or design a rocket. More important than any specific skill is learning how to learn. Learning faster than anyone else is the key to success.
The most impactful people care about the why. Hunger to understand the reasons behind things is what separates chefs from cooks. Cooks implement; chefs create. You can't create well without understanding how things work, why, and what need you're actually trying to satisfy.
Resilience requires diversity, and diverse solutions come from diverse inputs. The quality of your ideas reflects the quality of the information and debate that went into them.
In the long run, you can't tell people what to do. Power by authority is short-lived. To make lasting change you have to persuade people and then design a system that reinforces the change you want.

How I work

Solve the right problem. The highest-leverage work happens early, in defining the problem and designing the solution, not just implementing it. I'd rather spend an extra hour asking "what are we actually trying to solve?" than a week building the wrong thing. Asking questions takes less time than doing the wrong thing.
Ship to learn. Speed drives quality. Quality comes from contact with reality, not from thinking alone, so I get things in front of people early, even painfully early. A boxes-and-lines sketch, a signatures-only draft PR, a rough prototype. If the first time someone sees my work is when it's "done," that's already too late.
Use AI as a force multiplier, not a replacement for judgment. It's great for synthesizing feedback, prototyping, and the mundane parts of implementation. But shipping the wrong thing 10x faster is still the wrong thing, and code is a liability. Every line I don't understand is a line I'll have to maintain forever.
Communicate directly. Start with the why: I do better work when I know why something is needed, not just what. I'm an inbox-zero practitioner, so if you message me, I'll respond. My calendar is always current: if it says I'm free, I can meet.
Collaborate in the open. I prefer working together in realtime over passing handoffs back and forth. Decisions get made faster by pairing on a prototype than by mailing a spec around. I learn in the open so anyone can give feedback or learn too.
Improve as I go. I try to leave things better than I found them, whether that's fixing the docs I just read, cleaning up nearby code, or sharing a better mental model in a review. Small improvements compound. When I join a team, I focus on learning how things work and earning trust first, then proposing changes — not showing up with a list of fixes on day one.

My strengths

I'm receptive to feedback and apply it fast. Critical feedback is the clearest signal I have for how to get better. You shouldn't see me get defensive, and you'll rarely see me make the same mistake twice.
I don't take things personally. My work isn't my identity. It's a snapshot of my current skill and understanding, both of which improve with feedback.
I do what I say. A high do-vs-say ratio is how trust gets built. If I commit to something, I'll deliver it or renegotiate early, never go quiet and miss it.
I'm relentlessly curious and proactive. How do things work? Why are they this way? What would it take to change them? I'd rather set the tempo than wait to be told what to do.

My weaknesses

I think in systems, which means I can over-generalize a specific situation. My mind is always looking for patterns, but some situations are just unique.
My real-time answers to hard questions are low quality. I'm more susceptible to cognitive biases under time pressure (most people are). Give me a bit of time and I'll come back with something much better.
I can overcommit, especially on a new team where I want to build trust and make a good impression. To counter it, I'm deliberately starting small, saying "not now" more often, and ramping up the yeses while keeping my quality bar.

And I hate blind spots, the weaknesses I'm not yet aware of. If you spot one, please tell me.

How to give me feedback

Early, often, and bluntly. There's no such thing as "negative" feedback to me. All of it is useful. The channel (Slack, email, face-to-face) is up to you; I'll probably follow up in person to learn more. These are my preferences, though, and I know others don't all share them, so I try to be thoughtful about how I give feedback to you.

And on that note, what feedback do you have about this README?

You need to calm down

2026-05-13T00:00:00Z

If you work in software, you’ve seen this AI craze firsthand.

You’ve probably heard your leaders hyperventilate about the “transformative nature” of AI. Heard them panic about making sure everyone is “making the most” of AI. Heard them say things like, “engineers who don’t use AI will be replaced by those who do.” And it’s probably exhausting.

Ten years ago, you could have replaced “AI” with “the cloud”. Twenty years ago, it was “mobile”. Thirty years ago, it was “the internet”.

Yes, generative AI promises to be a transformative technology on par with the above. But that doesn’t mean we should lose our heads.

Rushing to use a new tool without carefully considering its tradeoffs and downstream effects is a recipe for building unsustainable things nobody actually needs.

What never changes

What never changes is the need to solve real problems for real people.

Discovering unmet needs. Forming hypotheses for how to address them. Testing those hypotheses with real people. Scaling the hypotheses that worked, killing the ones that didn’t. Repeating.

AI can absolutely make many of these steps easier: identifying patterns in customer feedback, rapid prototyping, and coding the mundane parts of the implementation. But as a partner in decision-making, not as a replacement for human judgment and taste.

Put another way: use AI to move up the abstraction ladder, not replace it.

What AI actually changes

AI doesn’t invalidate many of the best practices we’ve learned the hard way over the years.

You still need to ask the right questions in product discovery. You still need to optimize your delivery lifecycle for learning over shipping. AI makes shipping faster, but shipping was never the point. Meeting customer needs is.

Shipping the wrong thing 10x faster still means you’re shipping the wrong thing.

Used thoughtfully, AI can help you spend more time on higher-leverage work:

Use AI to synthesize customer feedback so you can spend more time crafting better hypotheses.
Use AI to build prototypes faster so you can learn what you should build more sustainably.
Use AI to fill in the more mundane details of a thoughtful architecture so you can focus on higher-leverage design decisions.

Where teams get into trouble

Where teams get into trouble is treating AI as a substitute for judgment instead of a force multiplier for it.

Don’t use AI to do things non-deterministically when a deterministic interface would be superior. Sometimes a button with a dumb workflow is better than an AI chatbot.
Don’t use AI to write more code than you would have written by hand. Code is a liability, and every piece of code you don’t read or understand is code that you will have to maintain indefinitely.

Ask yourself: if this AI-generated code was completely wrong, how would I know? What would the blast radius be?

The goal isn’t to maximize AI-generated output.

The goal is to solve meaningful problems sustainably.

Don’t lose the plot

The companies that survive technology shifts aren’t the ones that panic the hardest. They’re the ones that stay focused on fundamentals while everyone else is losing their minds.

So yes: use AI. Learn it. Experiment with it. Find where it genuinely creates leverage. But software history is full of teams that became obsessed with the tool instead of the outcome.

The goal was never to maximize lines of code written, story points shipped, or now, AI-generated output. The goal is still the same as it’s always been: solve meaningful problems for real people.

Just don’t lose sight of that in the process.

You do not need to calm down because AI isn’t important.

You need to calm down because it is.

The highest leverage work happens early

2026-05-07T00:00:00Z

Most people spend too much time implementing solutions and not enough time defining problems and designing solutions.

From a systems thinking perspective, problems become more expensive the later they’re discovered. Effort invested earlier in the process often prevents far more work later.

In practice, this usually breaks down into four stages:

Define the problem
Design the solution
Implement the solution
Maintain the solution

The hardest part is that defining problems and designing solutions rarely feels productive in the moment. But that’s often where the highest leverage actually exists.

Effective delegation

2026-03-25T00:00:00Z

What is delegation?

Simply put, it’s the act of transferring full or partial ownership of a task to someone else, ideally to maximize the collective impact and growth opportunities of everyone involved. When done well, this can create space for delegators to focus on their highest-leverage activities and give delegated individuals opportunities to work on things that help them grow. When done poorly, it can create resentment, frustration, and waste for everyone.

Delegation levels

There are many ways to define delegation styles, but I’ve found the levels below to be the most practical.

Common delegation problems

Delegating well is difficult, and most people aren’t amazing at it (myself included). The most common problem I’ve observed is that delegators don’t use the delegation style that’s appropriate for the task and the delegated individual’s skill at that task. This manifests itself in one of two ways:

Insufficient autonomy: The delegator doesn’t give the delegated individual enough autonomy in completing the task. At one extreme, the delegator doesn’t even delegate the task — they do it themselves. At the other extreme, they micromanage every detail unnecessarily. This can be incredibly frustrating and demotivating for the delegated and a poor use of time by the delegator.
Too much autonomy: The delegator gives the delegated more responsibility than they can effectively handle, and the delegated struggles to deliver. This typically happens when delegated individuals lack experience with the skill required by the task, and what’s asked of them is too far out of their comfort zone and area of competence.

How to fix a delegation problem

Once you’ve identified that you have delegation problem based on the signals above, follow these steps:

Identify which delegation level you’re using for the task.
Diagnose which of the two situations you’re in — too little or too much autonomy — and adjust your delegation level up or down accordingly.

Finally, remember that delegation levels are task-dependent: the same person may be operating at one delegation level for a task but at a completely different level for another task.

Speed drives quality

2026-03-18T00:00:00Z

The faster you deliver, the faster you’ll achieve high quality.

This may seem counterintuitive, but it’s true. Quality is not something that can be achieved through thought alone; it requires contact with reality to get feedback on what is good and what’s not. And the only way to get feedback is to put it out there — to deliver it in the hands of an end user.

This parable from David Bayles and Ted Orland’s book, Art & Fear, puts it best:

[A] ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work — and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

Applied to software product development (the focus of this blog), this takes many forms:

Share a boxes-and-lines napkin drawing of a proposed architecture for feedback in the next hour instead of spending a week putting together a polished technical design
Share a draft pull request that only defines class and method signatures for feedback instead of waiting to implement all code changes
Share a vibe-coded prototype with customers for feedback instead of building out the feature in full

In short:

If the first time someone is asked for feedback is on the finished product, it’s already too late.

Get feedback early — even painfully early. There’s a real truth to the saying that you should release before you feel you’re ready. The risk of waiting is wasted time and effort from going down the wrong path. Feedback is your GPS: check it early and often so you don’t get lost.

How to be successful

2026-03-11T00:00:00Z

I’ve interviewed and worked with hundreds of software engineers, product managers, and designers. Those that delivered outsized impact to the people, processes, and products around them all shared a few common traits that can probably be generalized to life as well:

1. Leave things better than you found them

In everything you to do, there’s always an opportunity to make an improvement, no matter how tiny. Are you doing the bare minimum to accomplish a task, or are you using the task as an opportunity to improve some part of the process? This can come in many forms:

Fixing documentation that you just read
Cleaning up nearby code when implementing a feature
Teaching a better mental model of approaching a problem while reviewing a pull request
Help someone that you see struggling

Small improvements accumulate into major impact. The reverse is also true: large impacts can be broken down into many small improvements. For instance, I once did an experiment called “Refactor-a-day” in which I spent 30 minutes every day identifying, implementing, and delivering a single refactor to the codebase. These were tiny edits — a dozen lines at most — that made incremental improvements to the codebase. At the conclusion of this 3–6 month experiment, I had completely rearchitected and improved the web routing layer of the core product, something that never met the threshold as a dedicated project.

2. Do what you say

What is your do-vs-say ratio? Do you do everything you say you’ll do and by when you said you’d do it? If you want others to trust you, having a high do-vs-say ratio is essential. Nothing erodes trust faster than someone who needs constant followups to get something done. Be the person that others go to to get the job done.

This doesn’t mean you need to do a lot. Not at all! Rather, it means you need to be honest — with yourself and others — about what you can do and by when. It’s easier to work with others whose volume and velocity are known and consistent than with those where it’s inconsistent and unreliable. Low volume and velocity is an easier and better problem to solve than unreliability.

Of course, things can happen that affect your ability to deliver what you said you would. When this happens, the key is to communicate early and align on updated expectations. Don’t wait until you’ve broken your commitment before communicating and renegotiating it.

3. Be proactive

Finally, the common thread in all of this is proactivity. Do you wait to be told what to do or for others to start, or are you the one taking initiative and setting the tempo? The most successful individuals are impatient and refuse to wait for others. A good measure of this is if others are asking you to slow down. If no one is telling you to slow down, you’re probably not being as proactive as you could be.

How to make decisions that don’t suck

2023-01-11T00:00:00Z

The Titanic and its passengers were victims of poor decision-making (i Strings Magazine)

We all make decisions. Constantly. Whether to snooze the alarm, what to have for lunch, or what to watch tonight. Most are inconsequential like these, but others have a larger, unknowable impact on our future. Whether to apply for that job, strike up conversation with that stranger, or book that trip on the Titanic.

Despite its ubiquity, decision-making is a skill. Like many skills, it can benefit from the same principles behind deliberate practice. That’s a technique for taking an activity and breaking it down into parts that can be measured, practiced, and improved in a feedback loop.

So how do you apply this to decision-making?

First, separate the decision from the decision-making process

Don’t judge the quality of your decision-making based on the outcome of an individual decision. Sometimes the worst outcome happens in spite of a good process, and other times you get lucky in spite of a bad one. It’s probabilistic, not deterministic. Good decision-making just increases the probability of success.

Second, realize that success is more often about avoiding mistakes than it is about being gifted

Sports is a great example. At all but the highest levels, winning is mostly about avoiding unforced errors than it is about playing brilliantly. Like sports, most of the improvement in decision-making comes from minimizing the risk of failure and regret.

Third, the goal is to maximize your rate of learning

The most successful individuals and organizations are the ones who learn the fastest about what makes them successful—and what doesn’t. But you can’t learn without trying and failing. A lot.

A decision-making framework

Based on these principles, dedicated training, and years of deliberate practice, I try to follow this structure for all my consequential decisions:

Define the problem
Identify the reversibility of the decision
Select the participants
Define the evaluation criteria
Ideate and evaluate the options
Premortem the best options
Make a decision
Later, retrospect

1. Define the problem

This is both the most important and most often overlooked step in making a decision:

What problem are you trying to solve?

To paraphrase a passage from Alice in Wonderland: If you don’t know what the problem is, then any solution will do.

Many problems are really just symptoms of a deeper problem. Addressing the symptom instead of an underlying cause will probably not solve the problem in the long-term, if at all. One of the qualities of a good decision is its longevity, i.e. how long it lasts before being revisited.

When defining the problem, resist the urge to accept the stated problem at face value, and confirm for yourself whether it’s (a) actually a problem and (b) the right problem to solve instead of a deeper one.

If you follow this rabbit hole of deeper causes to its logical conclusion, you might discover that the ultimate root cause is *change—*in the system or its environment. However, most decisions and decision-makers have a limited scope, so it’s up to you to decide how deep you want to go.

Finally, how will you know if you’ve actually solved the problem? What would be true? Can it be measured? An essential part of defining the problem is to describe what the world looks like when the problem no longer exists.

2. Identify the reversibility of the decision

Every decision has an opportunity cost. What are the tradeoffs if you decide one way vs. another vs. not making a decision at all?

One of the biggest opportunity costs is learning. You can’t learn what works and what doesn’t until you try, and you can’t try without first making a decision about what to try.

The speed of your decision-making has a direct impact on how soon you’ll be successful. The slower you are at making decisions, the fewer decisions you’ll make, and the less you’ll learn over time. For many organizations, a slow rate of learning can be fatal. But making a rushed decision can be dangerous too, particularly if the cost of making a wrong decision is high.

For many decisions, the speed-vs-quality tradeoff is obvious, and we choose the appropriate one intuitively. You’d certainly spend more effort deciding on your next home vs. what to have for lunch. But for many decisions—especially those in the workplace—it’s more ambiguous. How do you know when to decide quickly vs. carefully?

One answer is to classify decisions based on their reversibility:

How costly or difficult would it be to change the decision if it ends up being the wrong one?

Mostly reversible decisions: Decide as soon as possible

Mostly reversible decisions are like walking through a door: if you don’t like what you see, you can go back. For example, deciding between different products on Amazon is easily reversible due to flexible return policies and free, fast shipping.

For these decisions, decide as soon as possible since the cost of making the wrong decision is probably lower than the cost of indecision.

Mostly irreversible decisions: Decide as late as possible

Mostly irreversible decisions are expensive or impossible to undo. For example, deciding to move to another city is mostly irreversible due to the high cost of switching homes/schools/jobs and the fact that it may not be possible to return to the same ones if you change your mind. Some decisions are completely irreversible, such as whether to be a parent. These are one-way doors.

For these decisions, decide as late as possible since the cost of making the wrong decision is higher than the cost of indecision. Meanwhile, try to lower the risk of making a wrong decision by collecting more information that will help you make a decision. Keep collecting information until (a) you stop collecting useful information or (b) the cost of indecision becomes greater due to missed opportunities and other risks.

Collecting information is more than just research. One of the best ways to collect information is to run experiments. Is there a lower-risk way to test the different options you’re considering? Large decisions can often be broken down into smaller, more easily tested ones.

3. Select the participants

Who should be involved in the decision? An alphabet soup of popular models exist for identifying participants and their roles: DACI, RACI, DARE, RAPID. These models are largely the same and differ mostly in how they draw the lines between the different areas of decision-making activity.

Regardless of the approach, you’ll need to be able to answer the following questions:

Who’s making sure a decision gets made?
Who should be consulted before making a decision? What’s the heuristic for identifying who to include? Primary sources are better than secondary ones.
Does anyone need to formally approve the decision? If so, they should be consulted early in the process to understand their needs and incentives.
Who should be informed of the final decision?
Who will implement or execute the decision?
Do the selected participants represent a diverse set experiences and perspectives?

The last point is particularly subtle and rarely considered, but it has a large effect on the robustness of the decision. A group of people who think alike are likely to, well, think alike and generate a smaller set of similar ideas. Compare this to a group of people with wildly different ways of thinking who are more likely to generate a broad set of divergent ideas. Like we see in nature, solutions born from diverse pools of possibilities are more resilient than those coming from small puddles of homogeneity.

In short, the creativity and resilience of a solution is strongly affected by the diversity of its inputs.

Finally, on a more administrative note: remember to write things down. Not only should the individuals here be identified, but also documented. If it’s not written down, it’s at risk of being forgotten. Nothing sinks a decision faster than forgetting to include key stakeholders or misremembering what problem you’ve agreed to solve.

4. Define the evaluation criteria

How will the success of the decision be evaluated? Without explicit, measurable criteria, it will be difficult to confidently say whether the decision actually solved the original problem. Confirmation bias and the highest paid person’s opinion often then takes hold in these cases.

In addition, decisions often fail because of unvoiced differences in what each of the participants are optimizing for. How likely are participants to align on a decision if they disagree on what the most important factors are? Making these factors explicit and resolving their differences is a critical step in reaching a decision that everyone can move forward with.

This is why it’s vital that evaluation criteria are defined before making a decision. To help identify criteria, consider the following questions:

What factors are important in selecting a viable option? Discriminating factors are more useful than ones that all options will satisfy.
What is the relative importance of these factors? What’s the most important one?
What constraints exist? eg. Cost cannot exceed $X

For example, say you’re looking for a new home. Your evaluation criteria might be:

Distance to work and school: No more than 20 minutes by car
Cost: No more than $X/month
Size: Minimum 2 bedrooms
Amount of light: To what degree does sunlight illuminate the interior?
Proximity to a park/green space: Is it in walking distance?
Quality of interior: wood vs. tile vs. carpet, quality of appliances and fixtures

Defining these criteria and their relative important up front can help you avoid getting seduced by a home that seems great but ends up not actually being what you want—aka buyer’s remorse.

You might also discover that you and your partner’s lists of criteria are pretty different. I can tell you from personal experience that it’s far easier to discuss and resolve those differences before you commit to a home then after.

5. Ideate and evaluate the options

What are all possible options to solving the problem? Time to brainstorm! The goal here is quantity, not quality, so go wide and include options even if they may not be viable.

Try these strategies to discover additional options you might not have otherwise considered:

Eliminate options. If one or more of the most promising options weren’t available, what would you do? These constraints can help you think of more creative solutions.
Combine options. Can parts or the whole of different options be combined in novel ways?
Look at opportunity costs. By pursuing a particular option, you’re forgoing other opportunities. What are they? What if you pursued those instead?

Once you’ve identified a whole menu of possible options, now it’s time to evaluate each of them according to your evaluation criteria. It should be easy if you’ve defined the criteria as measurable things.

6. Premortem the best options

By now you should have at least one viable option for consideration. Imagine that you selected it, but it failed to solve the original problem. Why? What happened?

If success is indeed mostly about avoiding failure than it is about being brilliant, then:

We can ensure a higher probability of success by identifying and mitigating the ways in which we might fail.

In contrast with a postmortem, which attempts to diagnose the causes of failure after the fact, a premortem is a thought exercise that attempts to identify potential sources of failure before they happen.

To do a premortem, start at the end — you’ve failed — and work backwards. What are the things that failed, and what were the steps that led to them?

Continuing the previous home-hunting example, imagine you selected a particular home to move into and quickly discovered that you hate it. Why? The neighborhood sucks. Nothing is in walking distance, and even if you drive to the nearest cafes, bars, and restaurants, they’re all mediocre.

But don’t stop there. Why didn’t you discover earlier that the neighborhood sucks? Perhaps you didn’t realize the importance of walkability, nor did you realize how disappointing the surrounding establishments are. As you continue asking why and working backwards, you may discover important criteria like these that you hadn’t considered.

Mitigations to these sources of failures will become clearer as you work backwards. For instance, perhaps you can spend a few days actually living in the prospective neighborhood (via Airbnb or a hotel) to see how it really feels to be there. Be creative! Remember, time/effort/money spent reducing risk now will often be more cost effective than fixing the problems caused later. As famed architect Frank Lloyd Wright once said, “You can use an eraser on the drafting table or a sledge hammer at the construction site.”

7. Make a decision

Ironically, this is the easiest part once you’ve done the work of the previous steps. During the evaluation phase, a picture of the optimal solution likely emerged: one that addressed the most important criteria better than the others. If a clear winner wasn’t evident, it should have at least made it clear what the main tradeoffs are between the top contenders.

In either case, it’s time to make a decision. Whatever ownership model you’re using (DACI, RAPID, etc.), someone needs to select the appropriate option and get a commitment from the others needed to move forward with it. Others can disagree with the decision but should still commit to trying it. Committing and moving forward is more important than consensus, because after all, any particular decision is still a hypothesis that might be proven wrong. But its success or failure will be unknown until a decision is made and implemented.

8. Later, retrospect

So you’ve made a decision. Champagne! Are we done? Not yet. In addition to the work to actually implement the decision, the most important step remains: to learn from it.

It’s tempting to move onto the next decision right away. However, recall that the goal of this whole process is to maximize your ability to learn what will make you successful. And:

Learning cannot happen without reflection.

Once the decision has had time to take hold—which can take weeks or months—reflect back on both the outcome of the decision and the way in which it was made. Particularly:

Did the decision actually solve the original problem? If not, why?
How could we have made this decision more thoughtfully or efficiently?
What can we learn from it and apply to future decisions?

I’ve found it helpful to schedule the retrospective in advance so it’s not forgotten.

And that’s it! We’re finally done.

⌘

To The Brink Of Burnout And Back Again

2021-09-22T00:00:00Z

I didn’t realize it until it was nearly too late. For several months, I avoided meetings, procrastinated, and couldn’t focus. In hindsight, it was obvious: I was getting burnt out.

How did I get here?

My foray into product management started auspiciously. I was motivated and had a clear plan. What the hell happened? It’s tempting to try to pin it on a single cause, but in reality it was likely the combination of several factors:

No post-onboarding plan
Broad scope of product oversight
Piloting a different hiring process
No clear “wins” after months of effort
Lack of established processes

No post-onboarding operating framework

My initial 90-day onboarding plan was explicit and informed by a learning framework. Past that, my plans were a bit light on specifics. From my onboarding, I identified that we needed to define a clear product vision and strategy in addition to facilitating planning and execution of projects. But how does that translate into what my day-to-day and week-to-week should be? I didn’t have a great framework for organizing how I should operate.

As a result, I had trouble being proactive and ended up reacting to urgent needs and requests from others. Given my broad scope of product oversight, it was easy to become wholly consumed by reactive work. I remember many times when I would cycle endlessly—and mindlessly—between email and Slack to tackle the next reactive thing that came in. It wasn’t healthy.

Broad scope of product oversight

I oversee the products produced by five engineering teams. These are internal data platform products that include:

data pipeline infrastructure tools
data discovery products
foundational analytics datasets
experimentation services

The list of customer segments is broad: software engineers, data analysts, marketers, data scientists, and product managers. And it’s not just product I’m responsible for. Many of these products have a UI as well, but we don’t have any part- or full-time designers dedicated to this area. So UX and UI design falls to me as well.

Piloting a different hiring process

It was clear from even before I started that we’d need to hire a second product manager to help. Since I started in this role, I had been actively hiring. However, the entire process took longer than usual because I wanted to improve the typical product manager hiring process to reduce bias and increase diversity. There was more back-and-forth with recruiting to post an acceptable job description, and more time spent planning and coordinating the interview process. Ironically, this contributed to my already heavy workload and delayed getting help. But regardless, I’m glad I did because we learned a lot from it which I’ll share in an upcoming post. Most importantly, I hired someone who promises to be a great partner in product.

No “wins” after months of effort

I heard someone describe burnout as the application of effort without positive feedback or success. That feels true. My learning plan definitely called out the need to make small changes in order to learn, build trust, and gain momentum. However, applying that was more challenging than expected.

Relatively early on, I identified what I thought was one such small change: sunsetting a legacy SDK and API used for serving A/B experiments. Teams using those legacy components were eager to get off them, but unexpected attrition in engineering meant that our team would have to pause that work to devote more of our staffing to higher-priority projects for the greater org. Unfortunately for me, those higher-priority projects were long-running with completion dates months away.

Surely there were small UX issues I could have addressed? Perhaps, if I hadn’t been so spread thin. I was still learning about customers’ needs across my entire scope of ownership and didn’t have much time to go deep working on any particular UX.

Lack of established processes

We didn’t have definitive answers to any of these questions:

How do we review and change our strategy?
How do we discover, distill, and prioritize customer needs?
How do we capture, synthesize, and act on customer feedback?
How do we plan what to work on for the next few months?
How do we test, build, release, and iterate on solutions?

Don’t get me wrong, I love that none of these had been answered yet. This ambiguity is what attracted me to this role in the first place. It’s a clean slate, our own create-your-own-adventure. However, this ambiguity combined with everything else above probably contributed to my near-burnout.

What did I do?

Several things:

I talked to someone about how I felt.
I created a plan.
I took a break.

Talk to someone

This someone was my manager. The first thing we discussed is why we didn’t talk about my feelings of burnout earlier—especially since we have 1:1s twice a week. We attributed it up to my own lack of self-realization that I was getting burnt out and to a period of fewer 1:1s because of vacations and scheduling conflicts.

My manager and I talked through my feelings and what could be contributing to them. Together, we created a plan to address those probable causes.

Create a plan

Focus on hiring that second product manager.
Identify the steps needed to define the things that are missing: product vision, strategy, operational model, and processes. Coincidentally, I had just finished reading Inspired by Marty Cagan which provided a helpful operating model to try.
Delegate project management to engineering managers or technical program managers (TPMs).
Be less of a bottleneck for filtering low-level or urgent requests from customers by empowering engineering managers to handle many of those requests directly while keeping me in the loop.
Reflect on how I’m feeling and doing every two weeks.
Take a break.

Take a break

I took two weeks off the grid. One with family in Europe, another alone as a staycation. If I’m being honest, the second one was the most restful, because there’s no such thing as fun for the whole family (ha). I would have taken more, but after two weeks I was feeling better and eager to put my plan into action.

What did I learn?

This was a great learning experience. My key takeaways:

Reflect regularly on how you’re feeling and why. I’ve started a daily journaling practice and will continue my regular retrospectives with my manager.
Be kind to yourself. You’re not a robot. It’s a certainty that some days you’ll feel great, and other days you won’t. Don’t beat yourself up on the latter days; treat yourself like you would a friend or loved one in the same situation.
Take time off for mental health. Any amount helps, from a few hours to a whole week. I’ve started using sick time for those days when I’m feeling mentally drained and need a break. Sick days shouldn’t be used only for when you have the flu; your mind is part of your body too.
Work backwards from the end to define the plan. Start with the end—what outcome you want to achieve—and work backwards to identify the steps needed to make it true.

In the end, I’m glad I identified the burnout when I did and didn’t try to power through it like many others do.

Stay safe, stay sane.

Mike

Adventures in Product: The First 90 Days

2021-05-19T00:00:00Z

This is part of a series following my journey into product management.

This year is the second time I’ve made a significant role change. The first was moving from an engineer to an engineering manager role, which was fundamentally about switching from writing software to supporting individuals. In many ways that was a bigger change than my current lateral move into product management, but I’ll save that reflection for another post.

The specifics of these two transitions are different, but both have followed the same underlying paradigm to answer the question:

How do you learn something new, broad, and complex?

One-off approaches to learn some new topic X or discipline Y certainly work, but the biggest gains are found in developing a repeatable way to learn. In other words, a learning system.

My learning system

Source: Visual Paradigm

Mental models are simplified representations for how things work and can be useful to help understand complex systems and make decisions in them. The most prominent mental model in my learning system is the OODA loop, a four-stage cycle for information ingestion, processing, and acting originally developed in the U.S. Air Force.

Stage 1: Observe

This stage is all about information gathering and is where I spend the most of my first 30 days. My goal for this stage is to understand what things exist, how things work, and why things are the way they are.

When I moved into new roles as a people manager and a product manager, I had to gather information on two distinct areas: the new systems I’d be operating within, and the role itself. For example: What systems would I be shaping as a product manager? What does effective product leadership involve?

For both information gathering areas, I started by casting a wide net:

I talked to as many people as possible who I’d be working with or who had first-hand experience with the role. This included folks outside of my org and the company, too. I followed this approach and set up 30-minute 1:1s with each person where I asked the same set of questions: What should I know? What challenges do you see? Who else should I talk to?
I subscribed to newsletters, joined Slack groups, and created reading lists to get a broad and diverse set of perspectives on the role. You can find the full list of resources I used at the end of this post.

It sure felt like information overload at first, but it was necessary. Without first knowing what’s out there, it’s difficult to define better information filtering. As I learned more about the role and the systems I’d be operating within, I was able to be more selective with what I ingested and more specific with the questions I asked.

Stage 2: Orient

The mountain of observations and information collected in the previous stage needs to be processed into something useful. With the context—and especially biases—of each observation in mind, I started to build my own mental models of each of the systems I needed to understand.

As a new engineering manager, this mental model creation was mostly unconscious. As a new product manager, however, I tried to be more explicit by drawing these mental models as system diagrams or by explaining them in posts like these. It’s the Feynman Learning Technique in action: you don’t truly understand something unless you can explain it to a stranger.

These mental models aren’t static; I continuously refine them based on new information and feedback. Feedback from individuals is a good start, but the best feedback comes from experimenting with and observing changes in the real world. Enter the final stages.

Stage 3 & 4: Decide & Act

The feedback and mental models I’ve developed at this point have given me a holistic understanding of the systems involved. Well, holistic enough for me to start pressure testing it by making changes in the real world.

Some people recommend only starting with small changes. Others make large, sweeping changes early in their role. The former can fail to capitalize on the fresh outside perspective you bring to the role—a perspective that’s lost if you wait too long. A common example of the latter is the new leader who immediately reorganizes the reporting and ownership structure of the team. This can be problematic too if you don’t fully understand the reasons why things are the way they are (aka Chesterton’s Fence).

Either approach applied exclusively will likely be less successful than a blended, highly contextual approach. This is what I follow:

What are the least disruptive improvements I can make that will (a) allow me to safely test my understanding and (b) start to build trust and momentum?
What are the highest-leverage improvements that will have an outsized effect on the people, systems, and organization?

Rinse & repeat

Like the name says, this OODA loop is a repeating cycle. The first iteration can take 30–90 days, but additional cycles are much faster. By the end of the first iteration, I try to have a set of processes established that enable regular information gathering, feedback, synthesis, and action. For example:

Weekly 1:1s with individuals I work with to get feedback on what I should do and what I’ve done
Regular surveys to everyone I’ve worked with to learn what I’m doing well, what I can improve, and any blind spots
A regularly-reviewed decision log that identifies decisions that need to be or have been made, why, the approaches considered, and the outcomes
A regular writing habit to clarify my thinking (like this post)
A daily reading habit to continually discover new and divergent ideas

Learning resources

Product

Courses:

Intro to Product Discovery

Newsletters:

Articles:

Books on vision, strategy, and organization:

Build What Matters: Delivering Key Outcomes with Vision-Led Product Management by Ben Foster
Outcomes Over Output: Why customer behavior is the key metric for business success by Josh Seiden
INSPIRED: How to Create Tech Products Customers Love by Marty Cagan
EMPOWERED: Ordinary People, Extraordinary Products by Marty Cagan
Escaping the Build Trap: How Effective Product Management Creates Real Value by Melissa Perri
Product Leadership: How Top Product Managers Launch Awesome Products and Build Successful Teams by Richard Banfield
Good Strategy/Bad Strategy: The difference and why it matters by Richard Rumelt
Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs by John Doerr
Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts by Annie Duke
Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton

Books on customer research:

The Mom Test: How to talk to customers & learn if your business is a good idea when everyone is lying to you by Rob Fitzpatrick
Why You Are Asking the Wrong Customer Interview Questions by Teresa Torres

Engineering

Newsletters:

Books:

An Elegant Puzzle by Will Larson

People leadership

Books:

Drive by Daniel Pink

Blogs:

Rands in Repose (there’s a Slack group as well)

General problem solving and systems thinking

Courses:

Decision by Design

Newsletters:

Farnam Street (clearly one of my favorites, if you can’t tell by the number of links in this post)

Books:

Thinking, Fast and Slow by Daniel Kahneman
The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge
The Fifth Discipline Fieldbook: Strategies for Building a Learning Organization by Art Kleiner
The Great Mental Models: Volume 1 by Shane Parrish
Out of the Crisis by W. Edwards Deming
Thinking in Systems by Donella H. Meadows

The Three Dominoes

2021-05-14T00:00:00Z

Every team is a system containing inputs, outputs, processes, constraints, and incentives. Like any system, everything is connected, and often in subtle ways. Change one behavior over here, and a seemingly unrelated behavior over there changes, too. Second, third, and Nth-order effects abound.

I’ve worked in, managed, and observed software engineering teams across a variety of conditions. Not an especially large number, but enough to see common patterns emerge. I’ve distilled these patterns into a set of three simple rules that appear to trigger a domino effect of downstream behaviors. When followed, it seems easier for a team to operate well. When ignored, problems are more likely.

The 3 dominoes

1. Limit work-in-progress

How may independent bodies of work have been started but not yet finished?

When fewer things are in progress, it enables more people to work together on the same things. When more people work together on a problem, more diverse perspectives go into the solution. This creates a more robust solution. More people collaborating on a problem also leads to increased knowledge sharing, less context switching, and fewer delays due to illness, vacation, attrition, on-call, or contributors being pulled off to work on something else. And in software development, it results in more people who understand and can support the software.

Limiting work-in-progress gives the team enough slack to adapt to unknowable future changes.

What happens when this rule is ignored? I’ve witnessed similar effects every time. When each individual is working on a completely different problem, it’s harder to meaningfully review each other’s work. Quality across these workstreams becomes inconsistent. One day, a team member becomes unavailable for a prolonged period (or they leave). The rest of the team has to scramble to understand the problem and their work. On another day, an urgent new priority is handed to the team. One of the existing in-flight projects must be sacrificed and put on hold. The longer it stays unfinished, the longer it’s likely to remain so.

Limiting work-in-progress gives the team enough slack to adapt to unknowable future changes. It’s supported by queueing theory, which states that as the usage of a system approaches 100%, delays increase exponentially. These effects can be clearly modeled.

Of course there are limitations. Not all things can be worked on by multiple people simultaneously, and at some point there are diminishing returns as you add more contributors to a project. But doing fewer things with more contributors is a better default than the inverse.

2. Minimize specialization

How many tasks can only be done by a few people on the team?

It’s common to see specialization at a high level between design, product, engineering, science, sales, marketing, and finance. At this level, specialization is probably necessary because of how hard it is for an individual to be a effective across many of these disciplines simultaneously. However, problems are more likely when specialization gets more granular than that.

Specialization creates handoffs, and handoffs lead to more work-in-progress.

It’s easy to see the handoffs that occur between high-level specializations. Engineers wait for designers to hand off UI designs, designers wait for product managers to hand off product requirements, and so on.

Less obvious are the handoffs that occur between more granular specializations like UX vs. UI designers or UI vs. API vs. data vs. system engineers. UI engineers wait for API engineers to hand off a working API, API engineers wait for data engineers to hand off a datastore with the data needed, and data engineers wait for system engineers to provision the datastore. It’s turtles all the way down.

What do you think each of these engineers is doing while they wait? Watching cat videos? Sword fighting? Nope. They’re probably each working on something completely different, which now increases the team’s amount of work in progress. Whoops.

Now imagine if there was no sub-specialization and every engineer could provision datastores, ingest and process data, develop APIs, and create UIs. They could work together on each step of that dependency chain, generating more collaborative solutions faster than when alone. Nobody is waiting idly, and work-in-progress is minimized.

“But the UI/API/data/system engineers don’t know or want to learn how to do system/data/API/UI engineering,” you say. As a manager, you have a choice to make: Do you want to optimize for the long-term success of the team or to optimize for avoiding the short-term pain of getting individuals out of their comfort zones? Expanding your comfort zone by continually learning new skills is necessary to gain a T-shaped skillset.

Do you want to optimize for the long-term success of the team or optimize for avoiding the short-term pain of getting individuals out of their comfort zones?

If your team has granular specializations like these, changing them will be difficult at first. You’ll probably encounter resistance from nearly everyone, and your team will feel less productive and more frustrated in the first few months. Be patient. When learning anything new, it takes time to get over the initial hump of imposter syndrome and feelings of failure. But if you start small with simple tasks with lots of pairing and coaching, those small wins will grow and confidence in those new abilities will follow. A virtuous feedback loop will be created.

However, there are limits to what’s possible here, too. Your organization may have constraints on who can provision datastores, or the specializations may be so niche and hard to learn that it’s just not practical to avoid them. But don’t fall into the trap of avoiding short-term growth pains at the expense of better long-term success.

3. Avoid sacrificing quality

Does the team cut corners in order to hit a target?

You may be familiar with this classic triple-constraint:

Time, scope, or resources: Pick two to constrain; the other should be left unconstrained.

It’s a useful model for choosing what to optimize for. However, there’s an implicit fourth dimension that can be unintentionally affected: quality. Specifically, quality of both what a team produces and how they produce it.

An all-too-common story

Let’s imagine a team has to deliver an important piece of software in time to reveal it at a popular conference. Given this deadline and their fixed headcount, the team decides to constrain time and resources but leave scope unconstrained. That is, they’ll adjust the feature set to fit within the fixed timeframe and capacity of the team. So far, so good.

Partway through development, however, the engineering manager shares some bad news with the product manager. “We won’t be able to include feature X in the initial release after all,” laments the engineering manager. “Some of the features have proven more difficult to develop and test than originally planned, so we have to cut scope.”

“Oh no, are you sure?” the product manager responds. “The CEO was going to spend a lot of time highlighting feature X in the conference keynote presentation. They’ll be pissed.”

“Is there anything else less important that we can cut?” asks the engineering manager. “No,” the product manager replies, “everything else is critical. We can’t ship without the rest.”

You can replace “conference” with “marketing push”, “huge client deadline”, or any number of deadline motivations — the mechanics are the same. This situation is so common it could be a bedtime story. But it would probably give the parent nightmares.

At this point in our story, the team can take two possible paths. Let’s see which one you’d choose.

The easy path

In the first path, the team changes the only other dimension that it can: quality. They agree to lower the quality of their process and work by reducing the degree of testing that’s been slowing them down. “It’s fine,” the engineering manager says, “This is temporary, and after the release we’ll revisit this and improve our testing.” You might be able to predict what happens next.

With the quality seal broken, the team feels more comfortable lowering quality elsewhere when it gets in the way. Code and architecture reviews are less thorough and “LGTM” (Looks Good To Me) are frequently the only feedback. When there is feedback, “We’ll fix it after the release” becomes the refrain. What was previously a disciplined, quality-first process has unintentionally slipped into a ship-first-ask-questions-later Wild West. I may be dramatizing for effect, but not by much.

“But it really is only a temporary reduction in quality,” you retort. “Surely a team has the discipline to responsibly and temporarily lower quality once in a while in order to hit a key target.” My answer: Few teams do, and rarely. Why? It’s psychological.

When quality is sacrificed once, it’s more likely to be sacrificed again.

Enforcing quality provides long-term benefits, and sacrificing quality can offer short-term benefits in situations like this one. When faced with a choice between favoring the short-term at the expense of the long-term vs. the inverse, humans consistently demonstrate a bias for the short term. Human history and psychology is littered with examples: gambling and substance addiction, the Great Recession, carbon emissions, overfishing, diet, and exercise. Once a team gives themselves permission to lower quality and sees that everything stays fine in the short term (it usually does), the more likely they are to do it again in the future. But problems arise as soon as the short term is over—and it’s sooner than you think.

“We’re more disciplined than the average team,” you argue. Are you sure about that? If you weren’t disciplined enough to protect quality the first time, what makes you think you’ll do any better the next time? Why do you think you’re better than the average team? This reminds me of several studies that show that significantly more than 50% of the population thinks they’re smarter than average.

“Well, next time I’ll use this situation as an IOU from leadership to allow the team to cut more scope instead of quality next time,” you might say. If you believe that, I have a bridge to sell you. If anything, it’ll be the opposite: leadership will use this example as a reason to sacrifice quality again. Why wouldn’t they? It got them what they wanted with no apparent ill effects (because the problems only appear after the short term). Once they get a hit of that magical ship-fast-worry-about-quality-later drug, they’re hooked, and there’s no 12-step plan for this addiction.

The best antidote is to avoid the situation altogether. It may be harder in the near term, but it makes things easier in the long term. How? By taking the second path.

The path less traveled by

In the second path, the engineering manager replies, “I understand how important feature X is to the CEO. But unless it’s more important than any of the other ones we’re delivering, we can’t deliver it on this timeline with the quality necessary for it to be successful.”

There’s a minimum level of quality defined by the team that’s non-negotiable. Everything else is negotiable—time, scope, resources, cost. Ironically, in this story it was the team themselves that offered the option to sacrifice quality. This is too often the case. The engineering manager and/or team themselves feel pressure to deliver, so they sacrifice what’s made them successful: the quality of what and how they create.

ESPECIALLY under challenging conditions, a team should reinforce—not sacrifice—what’s made them successful in the past: the quality of what they do and how they do it.

The rare team with an exceptionally high level of trust, discipline, and a track record to prove it might be able to successfully sacrifice quality once in a while. But even then, it should be exceptional and rare. Odds are your team isn’t one of these rare ones (I’ve seen maybe a single one), so tread carefully.

A deadline is the driving constraint in this story, but replace it with another (like cost) and the approach is the same. For example, when he was asked about Apple’s pricing of its Macs during a 2008 earnings call, Steve Jobs famously said, “We don’t know how to make a $500 computer that’s not a piece of junk.” (They eventually did.)

In the end

In the end, it’s about the end—the long-term state of the team. Do you want to optimize for its near-term or long-term success? The habits your team makes today will define who they are tomorrow.

To recap, the 3 dominoes are:

Limit work-in-progress
Minimize specialization
Avoid sacrificing quality

FIN

From Engineering To Product: The Adventure Begins

2021-05-10T00:00:00Z

About two months ago, I became a product manager for the first time. Before, I had been in engineering for over a decade as a software engineer and engineering manager. The transition from engineering to product isn’t that common, and I didn’t find many others who talked about their experiences with similar career changes. I want to change that and share my story.

Over the coming weeks and months, I’ll bring you along my journey into the land of product. It’ll be a magical, winding path full of wonders, traps, and surprises—and lots of learning. Grab some comfortable shoes, a warm drink, and hit that subscribe button. Let’s go exploring!

The #1 Rule When Talking To Customers

2021-04-26T00:00:00Z

I’ve been watching New Amsterdam, a medical drama series about a fictional NYC hospital. One of the attending ER physicians, Dr. Vijay Kapoor, is a neurologist who approaches his patients’ needs differently than others.

Instead of working up a diagnosis and treatment based only on his patients’ symptoms, Dr. Kapoor asks them to talk about their lives. Their stories meander from mother-in-law frustrations to family holidays, annoying both the impatient head of the ER and patients alike.

Dr. Kapoor talking with a patient on New Amsterdam

These seemingly pointless rambles ultimately have a purpose. Details that initially seemed irrelevant suddenly connect to form a pattern that Dr. Kapoor stitches into a coherent diagnosis. Even though it’s all fictional, his approach is useful outside of medicine.

As a product manager, your mission is to serve customers in ways that work for the business. This naturally involves talking to customers to understand their needs. But it’s easy to mess up unless you remember the single most important rule:

Ask customers about their past, never about their opinions.

Customer opinions are unreliable. What do you think of this idea? Would you buy it? Answers to these questions are worthless at best and lies at worst. People generally want to be agreeable and will lie to you to make you happy, especially if you’re asking for an opinion on something you seem invested in.

Specific experiences from their past are far more useful because they’re historical fact. When’s the last time you did X? Walk me through what happened. Dig into the reasons behind each of their actions. You will learn more about how their world actually works this way.

It can be tempting to ask customers how they want their world to work. Beware: this is another opinion. It’s your job—not theirs—to figure out what problems exist, why, and which ones are worth solving.

The customer owns the problem. The product manager owns the solution.

Stop looking for validation or direction. Seek to understand the past instead. Let’s be more like Dr. Kapoor.

Manager README

2021-04-23T00:00:00Z

A practice that’s emerged with people managers is to publish a document that explains what’s important to them and what it’s like to work with them. This helps prospective and current employees understand what to expect from their manager. It’s called a manager README, inspired from instructional README documents that often accompany software.

I decided it was time I wrote my own README, but one focused on more than just my people management role. Here’s what you’ll learn about me after reading this:

My experience and how it’s shaped me
My beliefs
My strengths
My weaknesses
How I work
How to give me feedback

My experience and how it’s shaped me

I’ve spent most of my career as a software engineer, several years as an engineering manager, and a few more as product manager.

Next Big Sound

My perspective on software engineering, people management, and product leadership was shaped the most by my time at Next Big Sound, a music analytics startup founded in 2008 and acquired by Pandora in 2015. At Next Big Sound, I learned the value of:

A clear mission and product strategy
Self-organizing, autonomous teams
Driving the what and delegating the how
Tight collaboration between disciplines, working together in realtime instead of via handoffs
Direct communication between engineers and customers
Continuous experimentation on how we work
Defining what success looks like before making a change
Communication and empathy, especially as a 100% remote leader
A team that is friends outside of work

Pandora / SiriusXM

My time at Pandora (acquired by SiriusXM in 2019) was divided between engineering, engineering management, and product management roles. My foray into product management was particularly eye-opening and instructive, where I learned that:

Teams without someone focused on discovering and distilling customer needs are likely to operate in a very reactive way, constantly pulled by the loudest customer and building things in disjointed ways without a strategy or a vision.
Software product development is an inherently unpredictable process, so it’s usually more effective to optimize for agility than predictability.
Months without shipping is an incredibly demotivating experience, for engineers and product managers alike.
It can be easy to focus so much on solving the problem that everyone forgets what problem they’re trying to solve. Through well-intentioned iteration and problem-solving, the solution can unintentionally morph into one that solves a completely different problem—often because this different problem is easier. It’s the classic streetlight effect.

Are You Interested?

Before Next Big Sound, I worked as a web engineer for a NYC startup, AYI.com. AYI—short for Are You Interested?—was one of the first dating websites on the Facebook platform and used your Facebook social graph to recommend friend-of-friend matches. This was the first startup I worked for. The unique environment of a startup and a high-volume dating website informed my perspective on:

The value of A/B experimentation in making consistent, incremental improvements
…as well as the pitfalls of focusing on incremental A/B experimentation at the expense of larger innovations and business opportunities
The fatal mistake of having great execution but no product vision
The benefits of realtime interdisciplinary pairing

Disney

My first job as a web engineer was at Disney for the rebuild of Disneyworld.com. What started as a few engineering teams in a small office became 20 teams across 3 continents within the span of a year. This rapid growth taught me a lot, including:

A team with fewer dependencies on other teams will work faster and more efficiently than a team with more dependencies. This sounds obvious, but many organizations seem to be designed without this in mind. We saw that the teams with embedded API engineers and QA were much faster than the ones who outsourced those tasks to separate API-only and QA-only teams.
Downstream effects and incentives can surprise you. A requirement that all code have 98% test coverage led some teams to write tests that met the requirement but were worse than useless — they didn’t actually test anything and they slowed down the development process for every other team.

My beliefs

I’m biased by my experience. So is everyone by their own. I try to recognize this by being eternally open to learning from other perspectives, and by continuously evolving my own as a result. Nonetheless, there are a few ideas that I believe more strongly than the rest:

Everything can be changed. Nearly everything we use today was created by people like you and me. Changing them just takes time and pressure. When things don’t change, it’s not because they cannot, but because someone gave up first.
Everything can be learned. Nobody was born knowing how to play the piano or design a rocket. More impactful than learning any specific skill, however, is learning how to learn. Learning faster than anyone else is the key to success.
The most impactful individuals care about the why. Hunger to understand the reasons behind things is what separates chefs from cooks. Cooks implement; chefs create. You can’t successfully create without understanding how things work, why, and what ultimate needs you’re trying to satisfy.
Resilience requires diversity, and diverse solutions come from diverse inputs. A diverse set of solutions can mitigate blind spots. The quality of your ideas and decisions reflect the quality of information and debate that went into them. Diversity comes in many different forms: diversity of experience, beliefs, and backgrounds.
In the long run, you can’t tell people what to do. They’ll do what they want. Power by authority is naturally short-lived. You can get away with telling people what to do for a short time, but they’ll eventually leave or revolt. To make long-lasting change, you need to (1) persuade others and then (2) design a system that reinforces the change you want.

My strengths

There are a few behaviors I deliberately practice based on what I’ve seen successful and unsuccessful in other managers, leaders, and peers:

I’m receptive to feedback. I thrive on critical feedback, because it’s the clearest signal for me to learn how to operate better. When receiving critical feedback, I like to dive in and understand why. You shouldn’t ever see me get defensive.
I apply feedback quickly. Learning is useless if you don’t apply it, and the sooner it’s applied, the sooner the benefits are reaped. Once I’m aware of a mistake, you’ll rarely see me make the same one twice.
I don’t take things personally. Learning is more important to me than my ego. You think something I did was a crappy job? Help me understand why you believe so. I’ll probably agree with you. My work is never a reflection of my identity, it’s only a reflection of my current skill and understanding of the world. Both of those can be improved with learning through feedback.
I’m relentlessly curious. Like my first belief above, changing things requires perseverance—specifically, perseverance of curiosity. How do things work? Why are they the way they are? What needs to be true for them to change? I rarely tire of pursuing these questions, sometimes to the frustration of my peers (sorry!).

My weaknesses

I’m not perfect and have several faults that I’m aware of. I’ve discovered these primarily via individual feedback and personal reflection on situations that don’t go as well as they could have:

I have a bias for thinking in terms of systems, which means that I can prematurely generalize a specific situation. My mind is constantly looking for patterns and connections between things. But some situations are just unique.
If you ask me for a real-time response to a nontrivial question or feedback, it will be low quality. I’ve learned the hard way that I’m especially susceptible to cognitive biases when under time pressure. (Most other people probably are, too.) This explains why I might freeze during whiteboard interviews. I’ll be able to answer more thoughtfully if I have more time to think about it and respond.
I’m slightly averse to confrontation. I’m working on being more comfortable with disagreement, saying “no”, and speaking up, especially when emotions are involved. My natural inclination is to be helpful and accommodating, but this backfires when I agree to things I don’t truly believe in or when I fail to provide critical feedback soon enough. If you know me, you may be surprised by this since I’m already more vocal than most people. But I still believe I can do better.
Sometimes I overcommit. Fueled by excitement and a desire to be helpful, I can end up saying “yes” to too many things before discovering that it’s too much and then dialing back. In the past, this happened in situations where I was on a new team and wanted to be build trust and make a good impression but didn’t have a good understanding of the level of effort required on the things I was saying yes to.

To mitigate these, I’ve been making a conscious effort to start small, say “no” or “not now” more often, and slowly ramp up the yeses while maintaining my minimum desired quality. In addition, I’ve tried to build better feedback loops that help me sense and adapt.

For example, I’ve been trying to avoid be a hero by working overtime to address a backlog of requests. Instead, I let the backlog build up so it can apply backpressure and indicate that something in the system or process needs to change. Regular surveys to my peers about what I should do more/less of have also been providing good signals.

Finally, I hate blind spots — weaknesses of mine that I’m not yet aware of. If you know of any others, please let me know :)

How I work

Communication

I’m an “inbox zero” practitioner. If you email or Slack me, I WILL respond.
Start with the why. I can do better work if you tell me why something is needed in addition to what is needed.

Collaboration

I prefer to work collaboratively in realtime instead of via handoffs. Decisions can be made much more quickly by pairing on a prototype than by passing a documented spec back and forth.
I learn and work in the open so that anyone can give feedback or learn too. I try to include individual contributors as early as possible in things that will affect them. For example, inviting engineers to customer interviews.

Meetings

My calendar is always up to date. If my calendar shows that I’m available, I can meet. If not, I can’t.
I’m strict about my work and non-work hours, and they’re captured on my calendar. I’ve been working remotely since 2013 and have learned the importance of sticking to a consistent schedule.
I have little patience for poorly-run meetings that lack an objective or agenda, are too long, have too many people, or could have been a video recording or an email instead.
I prefer thoughtful asynchronous discussions vs. let’s-just-wing-it meetings. Meetings are more difficult to do well and should be reserved for discussions that benefit most from realtime communication. Also, see my weakness above about providing realtime responses to complex questions.

Managing

I practice servant leadership, which means my job is to support—not command—the people that report to me.
My mission as a people manager is to foster an environment where people can do their best work. It’s about designing a culture of feedback and learning, not about telling people what to do.
My goal as a people manager is to eventually make myself unnecessary by building self-sufficiency into the team. I should be a bonus, not a bottleneck.
If you have feedback or ideas for how I or the team can do things better, I want to hear them.

How to give me feedback

Early, often, and bluntly.

As I mentioned in my strengths above, I’ve deliberately practiced how to receive and make the most of feedback — especially critical feedback. There’s no such thing as “negative” feedback to me. All feedback I receive is useful and a positive thing.

“What about emotional, unconstructive feedback?” you might ask. Feedback like that is a useful insight into someone’s emotional state. What’s going on in their life? Are they ok? What can I do to help? are all questions I might try to answer.

“What about feedback that’s not actionable or even relevant to what I do/did?” you might ask. Why did they give me this feedback? Are they looking for me to help solve a problem? Or just to vent? are questions I might try to answer.

I could go on with examples. My point is that any feedback someone gives can be useful if you also look past the content and try to understand why they gave feedback in the way they did.

Logistically, the communication channel (email, slack, or face-to-face) is up to you, but I’ll probably follow up face-to-face to learn more.

It’s important to note that these are my personal preferences for receiving feedback. Others may not share them, so I try to be conscious about how I give feedback to others.

And on that final note… What feedback do you have about this README?

Book Summary: Build What Matters

2021-04-01T00:00:00Z

I’ve started a practice of reading one book every week. To help me actually remember what I read, I’m following the Feynman technique by writing a synthesis of what I’ve learned from each book.

This week, I finished reading Build What Matters by Ben Foster.

TL;DR

Follow these steps to avoid common product organization dysfunctions and enable the delivery of significant customer and business value.

Define customer and business outcome pyramids to identify KPIs.
Create a customer journey vision that would 10x the customer and business outcomes, using visual artifacts like a comic strip and mock-ups.
Work backwards from that vision to define a strategy and milestones to achieve it.
Decide on how to organize product ownership: by product, by feature, by tech layer, by customer segment, by customer journey stage, or by performance metric.
Proactively decide on the level of investment in innovation vs. iteration vs. operation work based on each product’s lifecycle stage.
Communicate directly with customers and collaborate closely with teams to keep a tight execution-feedback loop.
Hire the most diverse team possible — across race, gender, expertise, and experience.

The mission of product management

Product management’s mission is not solely to extract value from today’s customers. It’s to deliver customer value at levels never before thought possible.

Product management’s mission is to deliver customer value at levels never before thought possible.

Common dysfunctions

What impedes product management on this mission? Frequent dysfunctions of a product organization are:

Counting House: Internal metrics are more important than delivering customer value.
Science Lab: Incremental A/B testing is overused at the cost of real innovation.
Business School: Decisions are predominantly driven by unvalidated ROI analyses instead of a product strategy.
Throne Room: The CEO/CPO doesn’t delegate decisions and frequently changes prioritizes on a whim.
Roller Coaster: The business constantly changes priorities because they’re impatient to see results, but seeing results takes learning and iteration.
Bridge To Nowhere: Engineering prematurely builds or over-builds systems.
Hamster Wheel: The organization measures output over outcome.
Feature Factory: One feature is built after another, often at the expense of entire market opportunities. “This will be the feature that changes everything,” they say.
Ivory Tower: The product team doesn’t talk to customers because they think they know customers better than customers know themselves.
Negotiating Table: Product tries to maximize stakeholder happiness by reactively saying yes as much as possible instead of driving a holistic product vision.

The antidote to these dysfunctions is strong product leadership with a vision.

How to achieve a product vision

Define the key customer outcome. If the customer is able to achieve this, business success will follow. (No, MAUs is not a customer outcome)
Define the customer journey vision. How would a customer discover, use, and achieve their key outcome with the product?
Define the product strategy. How do you go from today’s customer journey to the one envisioned?

Outcome pyramids

Starting with the key customer outcome, identify the supporting outcomes that lead to it, and then the supporting outcomes that lead to those, and so on. This dependency tree can be arranged into a pyramid with the key customer outcome at the top.

For example, imagine a business whose mission is to help users prepare and serve home-cooked meals. Their customer outcome pyramid could be:

Source: Prodify

In addition, the business has a key outcome tied to the customer outcome. After all, it probably needs to make money. A separate business outcome pyramid can be created to capture important business measures:

Source: Prodify

Elements of a good product vision

Bold; it should try to 10x the key customer outcome
Time-bound, eg. for the next 3–5 years
Includes each stage of the customer journey
Has competitive differentiators
Written down
Communicated clearly, best in the form of a comic strip or customer diary with visual mockups

Stages of the customer journey

Trigger: How do customers realize they have a problem (that the product can solve)?
Discovery: How do customers discover that the product can solve that problem?
Evaluation: Do customers want to try out the product?
Trial: Customers try the product and decide if they want to continue with it.
Engagement: How deeply do customers use the product and all of its features?
Retention: Are customers getting the value they expected from the product? Are they aware of that?

Feature categories to focus on

These are derived from the Kano model.

Must-haves: Potential customers won’t consider the product without these features. Customer satisfaction doesn’t scale much with these.
Performance: What features do customers use to evaluate and compare the product? The product should do ALL of these features better than competitors for at least one customer segment. Customer satisfaction scales linearly with these.
Delighters: Unexpected bonus features that customers will talk about the most. Customer satisfaction scales exponentially with these. They’re important even for an MVP.

How to choose between product ownership organization models

Seams between ownership areas will always exist due to Conway’s Law. Find the organizational structure that minimizes the negative business impacts of them based on what you’re optimizing for:

Maximizing team autonomy
Minimizing seams in customer UX
Clarity of product ownership
Product lifecycle stage

Possible ways to organize:

By product: Clear ownership but not customer focused. Product vision/strategy is constrained to specific products. Requires coordination if products have dependencies. Good for companies with few dependencies between products.
By feature: Clear ownership, fewer dependencies than other options — except when larger infrastructure/architecture changes are needed. Product vision/strategy is constrained to specific features. Best for companies with mature, meaty features.
By technical layer: Clear technical area ownership, but can lead to inconsistent UX between platforms. Can lead to dependency hell where no single team can ship anything on their own. Appropriate for highly technical or algorithmic companies.
By customer segment or persona: Focuses on needs of users but requires heavy coordination to avoid duplication of effort and to stay aligned on strategy and standards. Easier for individual teams to become experts of a particular customer segment. Appropriate for companies with very different customer segments.
By customer journey stage: Facilitates delegation of business outcomes/metrics at each stage, but requires heavy collaboration to ensure consistency of UX across the journey, esp. for cross-stage viral loops. Appropriate for companies with stable linear customer journeys with a heavy emphasis on growth.
By performance metric: Facilitates delegation of those metrics, but product/feature ownership becomes muddled, esp. when multiple teams need to collaborate on the same products/features. Appropriate for companies with stable KPIs that capture customer and business outcomes.

How to balance product priorities

Trying to prioritize innovative, exploratory work vs. iterative feature development vs. operational support and bug fixes can feel like comparing apples to oranges to bananas. Instead of reactively prioritizing these types of work that arrive, proactively establish percentages for how much time should be spent in each area for each product: innovation, iteration, or operation.

These percentages will depend on the stage of each product:

Pre launch: High innovation / Low iteration / Low operation
Post launch: Low innovation / High iteration / Low operation
Product market fit: Low innovation / High iteration / Low operation
Scaling: Low innovation / Low iteration / High operation
Steady: High innovation / Low iteration / Low operation

Prioritization heuristics can be different within each category of work:

Innovation: What moves towards strategy & vision?
Iteration: Informed by RICE scores
Operation: SLAs, bug quotas, quality thresholds

The 2 questions that lead to better decisions, every time

2021-03-04T00:00:00Z

There are countless decision-making frameworks out there and an equally paralyzing amount of advice on how to make good decisions. It can be overwhelming. A lot of the advice boils down to the 2 simple questions below.

What problem are you trying to solve?

Crafting a solution without a clear definition of the problem can produce a solution that doesn’t actually solve the underlying problem.

Even if you might have a clear understanding of the problem, do others share the same understanding? Multiple people, each solving for a different problem, will probably not produce a solution that actually works.

Ask this question at the beginning of any decision-making process, and document the answer. Make sure everyone agrees with it before moving on, and frequently remind yourselves of it to avoid unproductive detours. At the end, revisit it: Does the solution actually solve the original problem?

How do you know that?

This question cuts through assumptions and beliefs that aren’t grounded in facts. It’s incredibly versatile and can even be applied to the first question above. A few examples:

How do you know that the problem you’re trying to solve is actually a problem? And important enough to solve? Is there a way to measure it?
How do you know that X is the root cause of the problem? What led to X?
How do you know that an important piece of information is true? Is it an assumption or direct observation? Is it a primary or secondary source?
How do you know that your decision was correct? Is there a way to evaluate it?

Like the 5 whys, keep asking this question until you get an answer that’s based on direct observations or first principles.

The answer to this question can also give you a good way to measure the success of the decision. Proactively measuring what you change is an important part of any decision-making process.

Lead time is the KPI for process

2021-02-24T00:00:00Z

Lead time is a useful metric for a team’s production ability. It should be measured before and after any process change to learn whether the change is helpful or harmful.

What is lead time?

Lead time measures the time between deciding to work on something and delivering it. For businesses that deliver software, it can be measured as the time between identifying a new feature to create and releasing the feature to customers.

Petro.blog

Software engineering: a decade later

My README

My background

My beliefs

How I work

My strengths

My weaknesses

How to give me feedback

You need to calm down

What never changes

What AI actually changes

Where teams get into trouble

Don’t lose the plot

The highest leverage work happens early

Effective delegation

What is delegation?

Delegation levels

Common delegation problems

How to fix a delegation problem

Speed drives quality

The faster you deliver, the faster you’ll achieve high quality.

How to be successful

1. Leave things better than you found them

2. Do what you say

3. Be proactive

How to make decisions that don’t suck

First, separate the decision from the decision-making process

Second, realize that success is more often about avoiding mistakes than it is about being gifted

Third, the goal is to maximize your rate of learning

A decision-making framework

1. Define the problem

2. Identify the reversibility of the decision

Mostly reversible decisions: Decide as soon as possible

Mostly irreversible decisions: Decide as late as possible

3. Select the participants

4. Define the evaluation criteria

5. Ideate and evaluate the options

6. Premortem the best options

7. Make a decision

8. Later, retrospect

To The Brink Of Burnout And Back Again

How did I get here?

No post-onboarding operating framework

Broad scope of product oversight

Piloting a different hiring process

No “wins” after months of effort

Lack of established processes

What did I do?

Talk to someone

Create a plan

Take a break

What did I learn?

Adventures in Product: The First 90 Days

My learning system

Stage 1: Observe

Stage 2: Orient

Stage 3 & 4: Decide & Act

Rinse & repeat

Learning resources

Product

Engineering

People leadership

General problem solving and systems thinking

Psychology

Design

Other

The Three Dominoes

The 3 dominoes

1. Limit work-in-progress

2. Minimize specialization

3. Avoid sacrificing quality

An all-too-common story

The easy path

The path less traveled by

In the end

From Engineering To Product: The Adventure Begins

The #1 Rule When Talking To Customers

Manager README

My experience and how it’s shaped me