Six Leadership Principles and the career moments that helped shape them
My principles for leading through ambiguity and the experiences that shaped them.
Over my career, I’ve developed 6 principles that guide most of what I do in work. These were picked up by blending experiences of my own with advice I found in people, books, and various other sources. This article covers how some of those developed, but for the impatient - the 6 principles are these:
Be Curious: You are likely surrounded by experts, rely on them, allowing them to do their job and keeping the BS out of their way. Don’t let your assumptions guide your decisions, ask for feedback, ask others to challenge your thinking, and listen after you ask a question.
Set the Pace: When you are first to take a run at a problem, you set the pace, the BS is less, and this makes the whole experience smoother. My preferred way to respond to an ambiguous request is to propose a point of view, let others give you feedback, and evolve from there.
Distribute Context and Decision-making: Share context liberally with those around you so they can directly act as the experts they are capable of being. Distribute decision making as far to the edge of your teams as possible.
Align Responsibility and Authority: If someone has authority for a decision, they are responsible for the impact. Many of the most stubborn technical problems are not technical at all — they exist because authority sits with a person or team who does not have direct responsibility for the impact of their decisions.
Build a Signal Network: Invest in building relationships you and your team can depend on in the future. Signal networks are your eyes and ears in an organization. The better your signal, the sooner you’ll pick up on upcoming opportunities, risks, and changes.
Be Sustainable and Predictable: I focus on building sustainable and predictable teams. Sustainable means we aren’t burning more fuel than we are able to recover. We can maintain our pace indefinitely (and enjoy it). Predictable means others can count on us to do what we say, and as a result we can make and meet commitments.
I believe these principles are also well suited for a world where AI is prominent. When things are changing rapidly and the future is uncertain, these principles help you gather context quickly, distribute that to your team, and set your team up to navigate uncharted waters in adaptive ways.
What follows are some of the experiences that shaped these principles.
Being Lucky
My first real job, the one that would open the door to a 25 year career, wasn’t a job I got because of my experience. You’ve been told for years “it’s not what you know, it’s who you know”, and you probably have a job or two that wouldn’t have happened without someone helping you out. Sometimes people help you out in ways you wouldn’t expect. In my case, they leveraged their stumbles to help me avoid the same.
I applied to my first job in tech with a bunch of other friends — most of whom weren’t technical at all. Unprepared and nervous, most of them flopped the phone screen. The questions they didn’t know were seared in their memory. But a few of us didn’t answer the phone screen. Then, the calls started to flow in — “Man, I bombed that phone screen”. As each friend called, we shared a moment of sympathy, and then… “So, umm, what did they ask?”. After 3-4 calls from disappointed friends, we had a list of about 15 questions. My friend and I stayed up all night researching answers.
It is strange to me to think that, of my friends at that time, it was only those who passed that phone screen that ended up with a career in tech. Some moments are pivotal.
I memorized all the questions I knew I’d be asked and hoped to hell that they’d have mercy on my soul because I was sure they’d know I was lying my ass off. But I got that job anyway, and it has led to a long and fulfilling career.
Through that career I’ve connected with some amazingly smart and capable folks - the most amazing of them were those who just figured shit out. Those were my people. Degree in geology turned Sysadmin running corp IT systems. Degree in chemical biology turned software developer building the CRM system. Degree in sports law turned program manager.
That’s me, with half a semester of music theory and no degree, now a software development and platform engineering leader.
There are substitutes for luck - hard work and persistence are known workarounds. But the privilege of being lucky is difficult to ignore in all of these stories. Where I was born (California Bay Area), the friends I had (already into computers when I wasn’t), and the timing of me entering the workforce (just as tech was taking off) are all things one doesn’t manufacture. I can’t take much credit for those circumstances; I can only express gratitude to the universe and acknowledge the role luck played in this path.
Curiosity and Resourcefulness
I got that job in 1997 - the year before Netcom declared Internet was a verb (”Your way to Internet!”). You’ll have to trust me, this is further back than the wayback machine goes back. God, I feel old. The job was providing call center tech support to every poor soul who couldn’t connect to the Internet.
What I found at Netcom was a group of people who were ambitious - not to climb the corporate ladder, but to learn and have agency over their future. Netcom couldn’t hire pre-trained folks, they had to train them, and they looked for a basic level of competency and expected to fill in the rest. Their training was basic - once you got on the phone with customers you had to adapt quickly. You’d think call center techs might stand around talking about the interesting technical problems they had - and sometimes you’d be right, but more often, we talked about the humans we talked to. Those awesome, awful, confused, impatient, hilarious, and distraught humans who just wanted to Internet. I was now surrounded by people like me who were learning how to do this job day by day, call by call, experiment by experiment.
I once spent 30 minutes talking to a man whose “Internet wouldn’t do anything”, only to discover he had shrunk his browser window to a few inches small (try it, it still works) making the web page invisible. Do you have any idea what kind of Columbo-style curiosity it takes to figure that shit out over the phone?
I learned to be resourceful, leveraging all the tools at my disposal to figure out problems. I learned how to be patient with people, how to listen to every-single-word-they-said. How to pay attention to the tone, the rhythms, what relatives were yelling at me in the background. I learned how to calm someone down, how to give them confidence that we could solve their problem, that even though I was the 5th person they talked to today, it was going to be ME who got them back to Interneting.
Progress required self discipline, study, and experimentation
When I wanted to progress in my career, I had to go read books and run my own experiments. There were some books about how the Internet was wired together, how ISPs built networks, how Unix systems worked, and those were fine. However, I quickly learned that my brain was coated with some industrial-grade Teflon when it came to absorbing information that didn’t solve some problem I had. I’d read an article and think “Oh, wow, I didn’t know grep could do that!” and then promptly forget that grep can do that.
What became clear to me was that I had to engineer problems to scrub that Teflon off and allow new information to stick. If I wanted to learn networking, I had to try to build networks. If I wanted to learn Linux, I had to install Linux. If I wanted to learn to scale systems, I had to work somewhere with that problem. Taking classes and getting certifications did nothing for my understanding of the world.
In the first few years of my career - along with many of my friends doing the same - I’m pretty sure I installed Linux about 500 times. You got your degree dissecting cow eyeballs and human cadavers? Awesome. I got my degree watching green text whiz by my eyes at 2am.
But slowly I discovered solutions to the problems I ran into, and by rinsing and repeating I found that I would retain that information. I could recall it even! A few years into this journey I would have someone accuse me of being “a sponge” for information. Can you imagine?
Writing it down
At some point along the journey to learning something, you want to show others how to do it. You bring your unique background and way of looking at things, and people may start to seek out your opinion. You see an opportunity to be valued for your experience, and writing things down scales your knowledge in ways that talking about it doesn’t (remember, I’m old - no TikTok or YouTube yet).
I found a love for writing, first for just documenting things and then for explaining it to others. I would get a pang of inspiration when someone had asked the same question for the nth time and I’d become hyper-focused on writing a single response that could be referenced into the future. I created documentation that was right in your face in systems - like instructions under the hood of a car (also something they don’t do anymore), they showed up right when you needed them.
The most powerful form of writing though, was writing for myself. It was as if the idea changed the moment it was observed. If I wrote things down, my perspective on them evolved. My frustrations would dissipate. I also found new collaboration partners who would engage with my writing in ways they wouldn’t otherwise.
Writing would become a core tool for me to evolve my thinking, collaborate with others, put ideas out into the world, and drive influence. My ability to write made it easier for me to set the pace, and describe a point of view, which made it easier to shape the landscape in which I operated.
Learning Craftsmanship
Sometimes you get a chance to have real agency and set a high bar for yourself. Agency doesn’t mean you alone make all the decisions, it means you are able to influence your destiny. I usually did this in collaboration with others, and the opportunity to have a small team collaborating toward some end goal has always been the most engaging and rewarding experience. Along the way you learn about craftsmanship - that deep pride in the work you are doing that makes you sweat the small stuff. Craftsmanship requires some confidence in yourself, some sense that the extra effort you are putting in is worth the time. For me, the idea that some future human may come across this thing I did drove a lot of the craftsmanship I put into my work.
Build it well. Document it well. Leave behind something for someone else to learn from and appreciate.
I had this opportunity when I moved into IT, running systems and networks. There were really just two of us driving most of the decisions around how we did things, and we had deep trust in each other’s expertise and judgment. We had each other’s back, and we tried to build the thing that would make us proud. Over 5 years and two computer room builds, we did just that, and the results spoke for themselves - the thing worked great.
And maintaining it was… boring. So I went looking for something more challenging.
Counter examples are education too
The year was 2006, and I had decided to move on from the corporate IT world into SaaS Operations at a fast-paced startup. Despite the dot-com boom and bust being years behind us, I managed to find a company that was undeterred - they partied like it was 1999, and they built software like… well, like a bunch of hackers. They were delivering video to mobile devices and PCs.
YouTube existed by this point, but it was pretty new, and the idea of running YouTube on a phone was fantasy. It would be 2 years before the first iPhone would be released. Every phone available was what we would today call a “dumb phone” - no apps, just basic texting. Blackberry was the most advanced device out there. It was in this climate that this company was delivering video to your mobile phone - one JPEG at a time. Motion JPEG, baby!
Oh, and we streamed live TV to your phone - you could watch live NFL games on your RAZR flip phone. Yes, it worked. Yes, delivering it was an absolute nightmare.
I racked up some impactful career experiences here:
Largest number of “3 hour” service deployments that took 8 hours
Longest service outage to date, lasting ~36 hours due to a corrupted distributed filesystem
Largest amount of money spent on something I could have gotten open source
Some of the most surprising HR experiences of my career (still standing strong almost 20 years later)
The place was fast paced, chaotic in many ways, but it attracted super bright folks. Everyone worked hard to just get shit done.
Over an 18 month period at this company I went from being a Sr Systems Engineer to a Sr Manager who reported to the COO responsible for Operations and IT. Nobody really explained how to manage humans, and I had zero spare time to learn from books. Upon reflection, it seems like my team mostly felt okay about the job I did - but I did not. I didn’t find a sustainable pace in this role, and the resulting burnout would be the catalyst for my family moving from California to Colorado to find a different relationship with life and work.
I left that place with a network of fantastic folks, and a head full of things I never wanted to see in any company ever again as long as I lived. Some of my most successful decisions have been shaped by what I perceived as failures at this company. I also left that place not wanting to manage humans - an avoidance that lasted for about a decade afterward. I had set a high bar for myself that I hadn’t met, and I wasn’t sure how to resolve that.
This experience left me with a challenge I needed to overcome, and I’ve since figured out how to make things more sustainable. I’ve also learned that careers can move in many directions, like Willy Wonka’s Glass Elevator - going up isn’t the only option. It can be really enjoyable to go down and sideways sometimes.
Embracing Ambiguity and Agency
The second and third thirds of my career have been a mix of startups and larger organizations. Every company had unique aspects - but most had one thing in common: Many people were not great at navigating ambiguity. When new challenges arose that required learning, experimentation, collaboration, and creativity - a bright line would form between different types of people. There were those who could find their way through it, and those who followed them.
I also met many people who were completely undeterred by ambiguity and who thrived when they had a hard and undefined problem to solve. From those folks I learned how to experiment rapidly, influence others, document your journey, and package all that up into a proposal and final decision record. I had multiple opportunities to work with small teams, sometimes just a pair of us, who had an outsized impact on the teams around us.
I learned that I really enjoyed this process because it thinned the herd - the people who could hang with ambiguity tended to be the people I loved being around. The other thing it thinned out was bureaucracy - when you are the first one doing hard things, often people leave you alone to pilot it. And so I gravitated toward taking on the hard stuff that didn’t have a clear solution - and especially where it involved changing hearts and minds. Many engineers hate doing that shit.
Certainty kills Curiosity
The biggest distraction, I learned, is certainty that your idea is right. This isn’t trivial pursuit where there is only one correct answer - the right answer also has to take into account how achievable and, often, how profitable the idea is. Over the last 15 years a huge part of my job has been evolving the good idea into the achievable idea. Ideas don’t win on merit alone, no matter how right they are.
In practice, this means developing collaborative alliances with others to build on a good idea, mobilize organizational support, and get enough people with skin in the game to make execution possible. Along the way you may learn your idea needs to evolve to get others on board - you may even learn that there’s a different idea that could positively impact more teams. Keeping your own ideas loosely held is very powerful. Listening as a collaborative process — asking questions to pull ideas from someone else’s mind, giving them space to think out loud, iterate, and re-shape their own ideas — has more power than you can imagine.
Think of your own ideas as fuel for entering relationships, currency that you exchange for other people’s ideas, and in this process your ideas are consumed - burned in the flames of collaboration to become something else. They become a new idea that was only possible because of the chemical reaction that happened between two ideas that needed each other’s fuel to become great. The oxygen for this combustion to occur is curiosity - without it, both ideas remain potential energy that can’t ignite.
The phrase “certainty kills curiosity” echoes in my head regularly. It reminds me to find ways to challenge my own thinking and to engage others in my problem solving process.
Leading in Ambiguity
I was presented an opportunity about 10 years ago to lead teams again. I took that opportunity because I cared more about how the team was led than I did about my own reservations with being the leader. That experience turned out wonderfully, and for the decade that followed my abstinence from leading humans, I’ve grown in ways I could never have predicted. What made this time different was realizing that I had a particular job to do. This job mostly revolved around enabling my team, but not helping them do their jobs - they’re great at their jobs. The parts that are my job don’t always feel like work to me. But just because it doesn’t feel like work to me does not mean it’s unimportant or low value. I’ve found quite the opposite.
I wrote down the 6 principles at the start of this article to capture key points I think are really important, but my guess is that those who have worked with me would identify others I missed. In time maybe I’ll complete the list, but for now I’ll present them again in a different order:
Be Curious: You are likely surrounded by experts, rely on them, allowing them to do their job and keeping the BS out of their way. Don’t let your assumptions guide your decisions, ask for feedback, ask others to challenge your thinking, and listen after you ask a question.
Set the Pace: When you are first to take a run at a problem, you set the pace, the BS is less, and this makes the whole experience smoother. My preferred way to respond to an ambiguous request is to propose a point of view, let others give you feedback, and evolve from there.
Distribute Context and Decision-making: Share context liberally with those around you so they can directly act as the experts they are capable of being. Distribute decision making as far to the edge of your teams as possible.
Align Responsibility and Authority: If someone has authority for a decision, they are responsible for the impact. Many of the most stubborn technical problems are not technical at all — they exist because authority sits with a person or team who does not have direct responsibility for the impact of their decisions.
Build a Signal Network: Invest in building relationships you and your team can depend on in the future. Signal networks are your eyes and ears in an organization. The better your signal, the sooner you’ll pick up on upcoming opportunities, risks, and changes.
Be Sustainable and Predictable: I focus on building sustainable and predictable teams. Sustainable means we aren’t burning more fuel than we are able to recover. We can maintain our pace indefinitely (and enjoy it). Predictable means others can count on us to do what we say, and as a result we can make and meet commitments.
With these basic principles I’ve led through some very ambiguous situations and emerged with a fantastic result that my team and I were proud of. I’ve watched this play out over and over again. You don’t always win the day - but it isn’t usually because you didn’t navigate the uncertainty well.
I re-ordered the principles a bit in this second set, because I think some principles build on the others. It all begins with curiosity and an ability to listen collaboratively to others. This makes you enjoyable to collaborate with, talk and listen to, and helps you build your signal network so that you can sense what’s going on around you. The context you get from those conversations is distributed to those around you, allowing you to delegate and distribute decisions. This makes your organization operate faster and more autonomously. With that space, you are able to set the pace, focusing your energy on shaping the landscape and clearing the path for your team to operate. Within your own teams you align responsibility and authority, so teams who have authority to make decisions also have responsibility for the impact of their decisions. This allows them to inspect and adapt rapidly and weigh consequences seriously. When put together, all of this creates a sustainable machine that is capable of operating smoothly, quickly, and predictably for long periods of time.
This can feel like a delicate balance at times, but listening to what’s going on around you is key to maintaining that balance.
One more note on predictability, it goes for leaders as well as teams. Teams want to be able to predict what their leader is going to do, or think, or ask. You don’t build a predictable organization unless your thought process is itself predictable. Unpredictable leaders create chaos and disrupt all of this. There might be a set of principles that work with an unpredictable operating model — but these aren’t that.
What has your experience been?
While these are my experiences, I recognize they represent just one perspective. How have you navigated ambiguity in your life and career? I would love to hear your story, and together we can collaborate on a representation of that history that helps others.