Leadership requires taking some risk. @ Irrational Exuberance

Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Leadership requires taking some risk.
- Friction isn't velocity.

Leadership requires taking some risk.

At a recent offsite with Carta’s Navigators, we landed on an interesting topic: leadership roles sometimes mean that making progress on a professional initiative requires taking some personal risk.

This lesson was hammered into me a decade ago during my time at Uber, where I kicked off the Uber SRE group and architectured Uber’s self-service service provisioning strategy that defined Uber’s approach to software development (which spawned a thousand thought pieces, not all complimentary). I did both without top-down approval, and made damn sure they worked out. It wasn’t that I was an anarchist, or that I hated all authority, rather that I could have never gotten explicit approval for either approach. It was the sort of culture where occasionally you were told not to do something, but you were only rarely given explicit permission to do anything. My choice was to either point fingers about why I was stuck, or take on some personal risk to make forward progress.

I love making progress, and hate being stuck, so for me it was an easy decision: take ownership and move forward. There’s a reasonable argument to be made that I was a bit reckless here, but I believe that a surprising number of environments distribute leadership decisions exactly this way. Indeed, if you want a bottom-up decision-making environment, but feel that taking on personal risk is an unreasonable demand, then maybe you actually don’t want a bottom-up decision-making environment.

In these environments, decisions aren’t solely the purview of executives. As a staff engineer or a line manager, you’ll be celebrated if you succeed, lampooned if you fail, and you’ll have to own the risk directly rather than shifting the risk to senior leadership by getting their approval. In this mode of operation, senior leadership doesn’t provide direction on navigating demands, rather they provide demands to be satisfied (sometimes described as “context” because that’s a nicer sounding word than “demands”), and outsource solving the constraints to the team.

If you want to make choices, expect that you’re going to be accountable for outcomes.

When should you take risks?

This isn’t a recommendation to always take on personal risks. Sometimes that isn’t just ill-advised, it will put you in active conflict with your company. For example, if your company has a clearly articulated engineering strategy, then explicitly violating that strategy is unlikely to succeed. Further, the risk is magnified, because you’re not just filling in blank space, you’re undermining the organization’s explicit decisions. This is true even when the strategy isn’t explicitly documented, but is nonetheless widely recognized.

You should generally only take bottom-up decision-making risk in two scenarios:

1. It’s a blank space without an articulated or practiced strategy (e.g. rolling out a caching strategy at a company without any consistent approach to caching).
   
   Creating the SRE organization at Uber fell into this bucket, as there simply wasn’t an existing point of view on whether to have such an organization
2. It’s an existential issue, where respecting the strategy is secondary to survival (e.g. solving a compliance problem that your company has irrationally decided to deprioritize).
   
   Our switch to self-service service provisioning at Uber was in this bucket, as part of that strategy was deliberately slowing down support for manual provisioning while we built the new solution, and no one would have approved a slow down

If there’s a way to make progress without taking on personal risk, that’s your first option. Get approval from the decision-making body. Find an executive sponsor for the initiative. It’s only when you run out of “approved paths forward” that you should consider taking on the risk yourself. Depending on your company, you may find there are abundant opportunities for approval, or none at all.

Owning the risk

For a long time, I considered it an enduring irony that executives are rarely held accountable for their decisions. This seems unfair, but it’s also true that the typical executive holds a basket of risks, and some of them are going to come due even if they do an excellent job of managing the overall basket. When you take on a risk as a non-executive, your situation is a bit different. You probably own exactly one significant risk, and similarly to the pressure to ensure your “staff project” succeeds, every time you take on a personal risk, you need to ensure it’s a success.

When attempts to own risk fail, it usually comes down to two issues:

1. a lack of interest in user needs, generally because you’re anchored on the adoption of a particular approach or technology (e.g. we must use a serverless architecture)
2. It’s unclear if the approach is working for so long that it gets canceled from above before showing impact (e.g. you’re nine months into building a vastly superior service framework, but nothing important is able to migrate to it)

There are a handful of techniques to reduce risk:

• Engineering strategy techniques: are useful even if no one will approve your strategy, because they force you to think through the constraints and challenges before jumping into the solution
• Modeling techniques: like systems thinking or Wardley mapping (explained in Simon Wardley’s original book or The Value Flywheel Effect) will help you build conviction that both the problem is real and your solution is viable
• Skunkwork prototyping: don’t take on the risk until you’ve validated your approach is viable
• Effective migrations: iterate rapidly across usage cohorts to understand the full breadth of requirements before driving adoption numbers to ensure you don’t stall out in late stages
• Validate across your network: derisk your approach by reaching out to peers at similar companies who’ve already solved the problem and understanding why your proposed approach did or did not work well for them
• Engage an executive sponsor: convince an executive to care enough about the risk you’re taking on that they’re going to absorb it themselves. This usually requires a strong pre-existing relationship with the executive that you’ve built by listening to them and taking on problems that they’re trying to solve

If none of those are directly applicable, then at a minimum ensure that you’re anchored in the data about your users and have done the work to understand their needs.

Obfuscated capacity

As hinted at earlier, sometimes bottom-up leadership requires obfuscating the work being done, because it addresses an implied system problem rather than directly solving their current problem. Sometimes your approach will even make things worse short-term, which is an idea I touch on in the Trunk and Branches Model for Scaling Infrastructure Organizations. In that case, we had so many incoming requests that servicing them effectively would have consumed our entire bandwidth, and we created time to invest into systems work by degrading our response to short-term requests.

Overwhelmed teams generally turn to executive leadership to prioritize their incoming asks, but overwhelmed teams in a bottom-up decision-making environment will generally find that approach doesn’t work very well. Executives have become comfortable articulating demands, and will restate their demands, but are often not particularly good at solving for underlying constraints. The bottom-up team itself has to take the risk to solve their own constraints.

In most cases, that means that these teams develop some mechanism for hiding internal work that needs to be done but doesn’t directly solve an executive demand. They’ll all describe this somewhat differently, whether it’s “engineering-allocated story points”, mildly inflating the sizing of every project, preventing on-call engineers from being tasked with product work, a platform team that’s not included in roadmapping, or just a sufficiently messy planning process that an engineer or two’s efforts can be quietly redirected.

Long-term, teams retain the right to obfuscate capacity by delivering something useful with the capacity they previously obfuscated. If not, long-term that capacity is “detected” and recaptured by the encompassing organization. Most organizations are glad to ignore the details of your team’s allocation for a quarter, but very few will ignore your output for an entire year. If you obfuscate capacity without solving something meaningful with it, you’ll find that trust takes quite a long time to rebuild.

Leadership requires some risks

Taking direct, personal risk is a prerequisite to taking ownershsip of interesting problems that matter to your company. A risk-free existence isn’t a leadership role, regardless of whatever your title might be. Indeed, an uncomfortable belief of mine is that leadership is predicated on risk. The upside is that almost all meaningful personal and career growth is hidden behind the risk-taking door. There’s a lot of interesting lessons to learn out there, and while you can learn a lot from others, some of them you have to learn yourself.

Friction isn't velocity.

When you’re driving a car down a road, you might get a bit stuffy and decide to roll your windows down. The air will flow in, the wind will get louder, and the sensation of moving will intensify. Your engine will start working a bit harder–and louder–to maintain the same speed. Every sensation will tell you that you’re moving faster, but lowering the window has increased your car’s air resistance, and you’re actually going slower. Or at minimum you’re using more fuel to maintain the same speed.

There’s nothing that you didn’t already know in the first paragraph, but it remains the most common category of reasoning error that I see stressed executives make. If you’re not sure how to make progress, then emotionally it feels a lot better to substitute motion for lack of progress, but in practice you’re worse off.

Grounding this in a few examples:

• Many companies realize that their monolithic codebase is slowing them down. It’s easy to decide to migrate from your monolith to services to “solve” this problem, but without a clear service architecture, most attempts take a long time without improving on the underlying issues. That’s because an effective service migration requires the same skill to operate an effective monolith: good technical design.

  However, the microservice migration itself provides a reassuring sensation of progress, delaying for a year or two the realization that you’re in roughly the same place that you started in.

• When your engineering organization doesn’t seem to be shipping enough software, an easy solution is to rollout a new development process. For example, you might say that an ineffective team needs to start following the scrum development technique.

  In rare case that the team has never considered any approach to organize their work, then this might well help. In most cases, this will just paper over whatever problem is causing the slow down, creating an appearance of progress that’ll quickly fade away.

• It’s common for new executives to rollout their preferrenced knowledge base, e.g. Notion or Confluence or whatnot, operating from the belief that the tool itself is the fundamental driver of an effective knowledge base.

  This will create months of work to move to a new knowledge base, but generally does not improve the underlying knowledge being managed. Poorly managed knowledge bases are always related to incentives and culture, not checkbox ready feature lists like “effective search.”

The pattern here is generally an intuition-driven decision driven by a senior leader, unclear criteria for success, an orientation towards motion as an effective proxy for progress, and being too busy to reflect on whether prior actions accomplished their intended goals. This recipe passes as leadership, and does share some of the characteristics from leading from conviction, but is always an inferior tactic to another available option.

If you see someone following this tactic, it’s a genuine kindness to point it out to them. If they’re not interested in that feedback, you’ve learned something important: they’re more focused on the performance act of leadership than in the impact of their work.

To provide one caveat, in cases where you’re wholly stuck, then minimizing friction doesn’t matter so much. In that case, Travis Kalanick’s classic quote is appropriate, “Fear is the disease. Hustle is the antidote.” Frenetic motion is worse than thoughtful pursuit, but some frenzy is preferable to going quietly into that good night.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!

This email was sent to you why did I get this?    unsubscribe from this list    update subscription preferences Will Larson · 77 Geary St · co Calm 3rd Floor · San Francisco, CA 94108-5723 · USA