Years ago when I was just starting out my career, I received an email from my manager that I needed to be in New York for a few important meetings over the next two weeks. Problem was, I had already planned a Vegas trip and booked round-trip flights between San Francisco and Las Vegas for that weekend. While the meetings didn’t conflict with my weekend plans, I really did not want to fly through San Francisco to travel between New York and Vegas. As a forward deployed engineer, I traveled almost every week for work, and any bit of extra flying made it especially mentally exhausting.
I decided to bring it up during my 1:1 with Brian, my manager at the time:
“Hey Brian, about the trip to New York — I had already planned on going to Vegas that weekend in between and booked my tickets from San Francisco to Vegas. Is it fine if I expense my round trip flight between New York and Vegas? I looked up the prices and it’s cheaper than a round trip flight between New York and San Francisco, and it’d save me some travel time.”
“Yes, of course. Also, in the future, don’t even worry about bringing this up to me. It’s only a couple hundred bucks, and I trust you to make the right decision for yourself and the company.”
As a kid just a few years out of college, that was surprising and empowering. I knew that Silicon Valley was all about entrepreneurship and autonomy, and Palantir, in particular, pushed that to the extreme. But I thought that it had only applied to product development, not all aspects of work. That interaction helped shape my approach to management for years to come.
The hard thing about hard things
“The hard thing isn’t setting up an organizational chart. The hard thing is getting people to communicate within the organization that you just designed. The hard thing isn’t dreaming big. The hard thing is waking up in the middle of the night in a cold sweat when the dreams turn into a nightmare.”
That may have been my first lesson on autonomy but, as a manager, I would eventually come to a more nuanced realization about it: the hard thing isn’t providing autonomy in your management style in a company where everyone is given such autonomy. The hard thing is providing autonomy in an organization where no one else does.
Many years later, I joined a startup where most people came from traditional industries that operated in a very top-down manner. For example, the company once did a seating reshuffle. Unfortunately, in an oversight, one of my future reports who was about to start was seated across the office from our team. I slacked Lydia¹, our operations manager, to move him over to one of the empty desks around my team. However, she insisted that we needed sign-off from the CTO — who was on vacation — before she could make any changes to the seating plan. As a result, my report had to wait for a few weeks before he was able to move over (he ended up bringing his laptop over to our area to work with us anyway).
Likewise, on my own team, one of my team members, Micky, would repeatedly say, “Ken, just tell me what to do and I’ll do it.”
Even after hearing it multiple times, this comment would always catch me by surprise. Coming from Silicon Valley and having worked at Palantir and Facebook, I’d never heard anyone voluntarily ask people to just tell them what to do. Everyone I’d met was eager to contribute their ideas, and there was usually a lot of debate and collaboration.
Despite the cultural differences, I was determined to introduce the concept of autonomy to this organization. As we hoped to enter rapid-growth phase, autonomy is essential to scaling an organization: by pushing decisions downward, you level up your employees while freeing yourself up to tackle higher-level problems.
My challenge thus became: how do I provide the right amount of autonomy so I can bring Micky along the way without pushing him too much? Part of establishing autonomy is also cultivating a culture where people have room to fail. Since most people were unfamiliar with such an environment, how can I build Micky up while shielding him from the backlash of his inevitable failures as he grows?
A framework for leveling up autonomy
The first time Micky said “Ken, just tell me what to do and I’ll do it,” was a discussion about a specific implementation detail. I immediately responded,
“No, Micky. You come up with a proposal of what you think we should do and we’ll discuss it.”
Surprised, he commented,
“No one has ever said that to me before.”
Since pushing decision-making down was a new concept, I came up with a framework for the engineers on our team². We needed a name for this framework, so we started calling it “BL”, short for “Business level”.
The levels are follows:
- BL1: Given a task and implements said task. For example, implement a specific widget on the web application that allows users to toggle between various charts.
- BL2: Given a feature, designs the solution and breaks it out into tasks. For example, build out a data model and its corresponding calculations that represents real world transactions.
- BL3: Given a technical project, designs the solution and breaks it down into features and tasks. For example, design versioning for all of our data models and ensure backwards compatibility.
- BL4: Given a business outcome, comes up with the corresponding set of technical projects. For example, users should be able to log into our web application and see all historical transactions with the relevant highlights and calculations within a certain latency. (This may require multiple technical projects to accomplish.)
After establishing this framework, I worked closely with my team members to progress under this framework. I started out giving them tasks, then features, and eventually technical projects. Pushing someone to own a technical project before they can barely own the implementation of a task benefits no one and would only cause frustration for all parties.
As it turned out, Micky just needed someone to light a fire under him. He had a natural curiosity about technology and how code worked under the hood. When channeled correctly, that was incredibly valuable to the team.
I continuously emphasized that I wanted Micky to level up and referenced this framework to track our progress. Over time, I loosened the reins and gave him more and more scope and autonomy. Within six months, he was the default person to consult with whenever we needed to r̶e̶f̶a̶c̶t̶o̶r̶ upgrade our implementation, and eventually led the revamp of our codebase as we upgraded the versions of a few core libraries. In other words, he moved up from BL1 to BL3.
Autonomy is a two-way street
When I first interacted with Lydia regarding the seating change, my immediate reaction was to put the onus on her for not taking ownership of a minor seating change (seriously, would the CTO really care where a junior engineer sat?). However, as I thought through it more, I realized that it takes two to tango. While she didn’t feel comfortable making a minor seating adjustment, leadership at the company also did not set the proper cultural expectations so that she could feel empowered.
Similarly, before I joined, Micky operated in a top-down environment where he was given tasks to complete. He had never experienced autonomy, and did not know that he could in fact make decisions on his own.
As leaders, it is easy to criticize our employees for not taking ownership of projects and decisions. However, it is equally important to self-reflect, “did I create a culture that makes my employees feel empowered to make decisions on their own?”
Ultimately, decisions should be pushed down to the lowest level where people can make the best call. Not only do they have the most context to make the best decision, it also frees up everyone else along the management chain to focus on higher-leverage issues. Next time your report asks you to make a decision, ask yourself, “Should I make this decision, or can I trust her to make it herself?” If she isn’t ready for additional autonomy, consider coming up with a framework to level her up. After all, isn’t that the point of being a leader — to grow your employees and in turn collectively achieve a better outcome?
 Names and identifying details have been changed to protect the privacy of certain individuals
 Although this framework is software engineering-specific, I believe you can adapt it to other functions as well.
For more musings on tech culture, organization building, and management, follow me on Twitter @kenk616.