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:
- 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 - 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:
- 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)
- 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.