Leadership on Locally Optimal

Know your neighbors

Sat, 02 Mar 2024 20:05:21 +0000

It's not enough to know your own scope, your own team, and your immediate surroundings. Your work inherently succeeds or fails based on the first (and even second) degree removed participants – customers of your APIs, stakeholders in the invariants you ensure, the hard and soft dependencies you build atop, and the broader ecosystem you thrive or wither within.

Do you know who your neighbors are? Have you met them, talked to them, built rapport?

Can you ask them for urgent favors, or lean on them to help you out of a jam, or trust that they will assume best intentions from that rushed, slightly-too-harsh Slack message you sent in haste? Do you know what matters to them, where you could improve things for them, and what their most important request is for your team/system?

If you aren't sure who your neighbors are or where things stand, put in the time now to fix that while the pressure is relatively low. Relationships (in real life and at work) live or die in hard times based on the investment you put in during the other seasons. There's no time like now to meet that coworker one team over, have a casual curiosity-first conversation about what is going well/poorly for them, and talk about something you have in common.

You never know when it will matter until you know what matters to them. Start learning.

Building consensus iteratively with feedback spirals

Thu, 11 Jul 2019 07:00:00 +0000

Building true consensus is hard work! By its nature, it implies you’ve taken time to hear lots of opinions, convince people on the margins by addressing their concerns, and probably spent some of your time discussing with those who will never agree with you. Often the goal of getting true consensus and buy-in from a broad group of people can feel impossibly hard.

One of the paths toward consensus is eliciting and incorporating feedback regularly. Unfortunately, many projects do this too little, and too late. A classic failure mode is gathering feedback after decisions have been made and executed on, like a long argument in code review about the fundamental architectural choices underpinning the whole design. This produces wasted effort, frustrated people, and overwhelmed reviewers.

Wouldn’t it be better if we treated feedback like we do agile engineering projects — getting feedback early and often instead of in a huge big-bang at the final approval step?

Gathering feedback iteratively

So this is my shot at trying to codify how I approach gathering iterative, small feedback for my own controversial architectures or decisions.

The main mistake we’re trying to avoid is waiting too long for feedback. It is a natural mistake — releasing things for feedback early feels risky! It’s easier for your reviewers to not understand (“why is this so messy?” or “this is incomplete, I can’t review?”) — you must work harder to share the same context and expectations.

If you haven’t seen it before, the concept of “30% feedback” proposes getting earlier feedback on a messier version of your final idea. I really like this, but the most obvious problem is it only splits your feedback into two big chunks (the 30% mark and the final 100% mark). I want to use that same reasoning, but make it fundamentally continuous and let myself regularly check in for feedback whenever I need it along the path from raw idea to final consensus.

Without any further ado, here’s our approach to building consensus with iterative feedback:

Start small with deciding on the basic thrust of your idea and what problem it solves. Share with a core group of project peers or respected advisors. Get feedback on the clarity of problem statement and your directional plan of attack.
Expand the feedback group to include your planned final stakeholders and decision makers. This is the 30% feedback point. Ask for preliminary agreement that this solution looks promising. Get feedback on the shape of your solution and anything you’ve de-scoped from the problem.
Reach the widest point of feedback. Be pretty sure of the details of what you want to do and why. Offer chance for feedback to everyone, especially those who won’t be in the final decision making group.
Start shrinking the feedback circle toward the core group of decision makers, making fewer, smaller changes, and finalizing the plan.
Finally the decision makers make the final go/no-go call, based on the proposal crystallized from all this feedback.

With this pool of reviewers first expanding and then shrinking, you can imagine why I call this “feedback spirals” 😄

Let’s dive into each of these stages in more depth.

Finding your MVP and getting directional feedback

There’s great literature ( The Lean Startup, any book about agile, etc.) endorsing early feedback, cheap MVPs, and iterative work for engineering projects, so let’s steal those concepts.

Our goal is twofold: discover the simplest statement of the problem we’re trying to tackle and form a directional opinion about how we’re going to solve it.

I recommend using a structured format and keeping your first approach small. I like the Amazon 2 pager in this case, and focusing in particular on making sure my proposed solution is particularly high level. The written format is particularly good at forcing a clear problem statement up front and offering a concrete artifact of the plan as you go along.

The MVP I like is a directional position on how we’re going to solve our problem. This should not be a concrete, detailed proposal at this point, but rather a “big idea” or directional solution. If a later proposal will be “30% done”, this is more like 10%. Our goal is to frame the very general target of our solution, of course with the knowledge that future investigation may well change our opinion on the best approach.

Once we are satisfied with our initial 2 pager, we get the very earliest feedback! I recommend the first reviewers is a small group of supporters and interested parties with enough experience to be able to give loose, direction feedback about an idea that is barely even defined. Use this feedback to build a consensus direction for the start of your project.

Expanding to 30% feedback and beyond

After we’ve settled on our problem we’re trying to solve, and a directional solution, it is time for us to iteratively work out the details, getting feedback as we go.

The 30% mark is arbitrary here — remember the value of our fully iterated approach is there isn’t a single magical point where we need to get our early feedback exactly right. Instead treat it as a continuum, where we’re regularly expanding whom we get feedback from and hopefully also regularly reducing how much change this feedback has on our project’s design.

Our goal is a narrowing of changes, where over time we can be building confidence in our project’s proposal. Though you might worry about all this feedback slowing a project down, in practice I’ve found it actually increases how quickly I can safely move, secure in the belief that there’s growing momentum behind what I’m proposing.

Reaching the point of maximum feedback

At this point, your proposal should be mostly unchanging. I aim now for the largest circle of reviewers, including the majority of the engineers or other teams who will be most impacted by the change. This offers me the most chances for hearing novel feedback and lets the whole team buy into the idea. My goal here is not to get review from “experts only” — but to now confirm with the larger team that the idea makes sense and will work. Often this is where you’ll discover last minute details that seemed fine in the abstract but don’t work in the detail.

This is not only the largest reviewer group, it’s also hopefully the last time our project’s actual details change. From here on out we’ll be moving from building consensus to acting on the final result of that consensus.

Making a decision and committing to it

Now for all that hard work, we return to a final small group to make the final call. I like this to contain a lot of the original 10–30% reviewers, since they’ve had the longest context over the lifetime of the design. The upside of this process is we’ve formed a proposal that’s included feedback from a huge diversity of sources, and got repeated, ongoing consensus as we went along.

In a more traditional, waterfall approach to project decisions, this would be the moment of truth where you throw the project to reviewers and cross your fingers. Some feedback would be minor, but some will be second guessing the very underpinnings of your solution. Reviewers in this situation can slip into a role that is more antagonist than collaborator — bringing objections that are too fundamental to be solved with any change except going back to the drawing board.

However that’s the beauty of our iterative approach. The final call is made on the strength of layered feedback at every step of the process, including an original direction set and ratified by at least some members of the final decision committee. The goal is always to discover disagreement or fundamental concerns as early as possible.

Put another way, I strongly believe that every final decision point should be as boring and pre-determined as possible. Be skeptical of long periods without feedback, and of a decision process that produces surprises at the end.

In conclusion (what does this get us)

Consensus is incredibly valuable, but it’s also hard won. A smooth feedback process gives you the best of both worlds — smooth momentum that isn’t delayed by arguing over proposal fundamentals and a final decision that feels effortless and widely agreed upon.

To get there, avoid “design everything up front” quagmires by focusing on a problem statement and directional MVP and immediately getting feedback from a core group.

Build regular consensus up gradually over time, growing confidence that your idea makes sense in the concrete, and broadening your feedback circle to build consensus wider and watch for mistakes others might catch.

As feedback starts to solidify behind a consistent solution, start shrinking the feedback circle. Watch to make sure the magnitude of changes is reducing regularly, and build confidence that this is a good enough “first approach” to commit to executing.

Finally return to a relatively small decision making group you trust to make the final call. Running this process in the open and including feedback from a large group balances transparency for big decisions with an efficient decision process that doesn’t devolve into design-by-committee. Document your final decision and the justification for it in public, so those not in the deciding group can follow your reasoning.

In the end, hopefully you get the best of all worlds with excellent decisions and easy consensus. There’s a reason we prefer agile projects over waterfall ones — your decision making process deserves the same. Try out feedback spirals and let me know how well it works for you, or what process you’ve used to avoid these same pitfalls.

Originally published at http://www.locallyoptimal.com on July 11, 2019.

Delegating safely and successfully

Thu, 28 Mar 2019 00:00:00 +0000

At Yelp, I’ve been in a role we call Group Technical Lead (GTL) for a little over a year now. In short, it involves being the technical (aka non-people-manager) leader of a technical space that spans teams. The closest industry standard analog is probably Senior Staff Engineer. I worked in 2017–2018 as the GTL of Yelp’s commerce platform — payments and billing infrastructure that powers food delivery, advertisements, and other paid products. However this year I’ve just transitioned to serving in the same GTL role for Yelp’s ad platform. This is a pretty dramatic shift in teams and results in me owning a very different set of tasks.

One of the obvious changes caused by me leaving Commerce is the work I used to do needs an owner! The one most at the front of my mind is the group’s technical roadmap for the next couple years, but there are a number of other responsibilities that were very central to my job description and are left unowned in my absence.

There are strong technical leaders staying in Commerce who I want to grow into my old role(s), but there’s a fair concern that they might not be ready to immediately perform the same function. This comes up a lot even when you aren’t switching teams. As you regularly acquire new, harder tasks the old work you used to do has to go somewhere. The question is how to delegate work you used to do while setting its new owner up for success.

Delegation a task doesn’t imply zero involvement

A normal fear whenever you try to delegate something you used to own is that whoever you give it to might not know how to do it well. This is even more common when (like for me right now) you’re delegating a task that wasn’t easy for you down to someone who has less experience doing it than you.

A common (but bad!) response to this is to just not delegate your task. This results in you getting overloaded (more work always arrives), the people around you never getting challenging opportunities to grow, and silos of knowledge where expertise doesn’t get shared.

I like to hack around this by frequently reminding myself that delegating a task doesn’t need to imply having zero involvement! The RACI model encourages thinking of four possible ways to be involved in a project:

Responsible: You do the work to complete the task
Accountable: You are ultimately answerable for the correct and thorough completion of the deliverable or task
Consulted: You are consulted for your expert opinions when needed
Informed: You just hear about the task’s progress (without blocking any decisions)

Partial delegation via RACI

Thinking about this, you can see that I can hand off Accountability for the Commerce Roadmap while still helping (lightly Responsible), and definitely offering lots of Consulting help. This lets me not lead the effort, but still be around a lot for advice and keep an eye on any worst-case outcomes. My normal transition from full ownership to full delegation looks like this over time:

I start fully Accountable, and probably Responsible too.
I involve my replacement first, making them also co-Responsible for the task. We focus on talking through and pairing up for any work I do in my Accountable capacity.
Next I delegate Accountable, but stay Consulted for sure and possibly Responsible if needed. This is the training wheels period — I’m still very involved and can spot mistakes, but I’m reducing the choices I make and expecting my replacement to be more self sufficient.
I try to let go of Responsible once I’m sure my day-to-day involvement isn’t necessary, but stay Consulted. This is easiest if you slowly reduce your involvement over a period of time.
Consulted often lasts for a while, but I aim to make sure the amount of time I’m spending is reducing over time.
And eventually I can drop Consulted and just trust the delegate to handle it completely. If I long term need to care about the task, I can choose to stay Informed.

Even though using acronyms runs the risk of making me start wearing a suit to work and saying SYNERGY a lot, I really like RACI as a way of helping me remember delegation isn’t a big-bang binary choice. If you find it this useful, you might like me talking about it and other things in this talk on surviving overloading at work. It’s certainly feeling very relevant to me maintaining sanity during this team transition.

Originally published at www.locallyoptimal.com on March 28, 2019.