I’m obsessed with getting to the essence of things. What is this I’m looking at really about? What makes it tick? When you squeeze it, what comes out?

I’m also obsessed with the idea of leadership. What is it that impels and compels leaders to lead and followers to go along? What’s in a leader, really?

Maybe this quest to get to the bottom of things is ill-advised, a wild goose chase. Maybe it’s not that important.

Maybe so.

But I continue to believe that real wisdom lies around the essence. It’s no accident this newsletter is called Hagakure: it means something like “hidden by the leaves”.

What’s Leadership?

Definitions of leadership abound. Some are clarifying, some are inspirational, a few are both. Building up to your own personal definition is a necessary part of your leadership journey. It’s like the meaning of life—everyone has to make up their own.

That does not mean you have to create one for yourself anew. Reinventing the wheel is seldom necessary. You can borrow from here and there, mix and match, then make it unapologetically yours.

I’m not sure I have a definition of leadership of my own, but a few moons ago I came closer to its essence. As so often happens with these things, it came from a somewhat unlikely place.

The Essence of Leadership

Chamath Palihapitiya is a Sri Lankan-born Canadian and American venture capitalist, the founder and CEO of Social Capital.1 He made a name for himself a decade ago leading the early Growth team for Facebook. In the video below, he tells of the process they used to grow to millions—and then billions—of users.

Towards the end, almost unnoticeably, he says “all I did was enable a framework and create discipline.”

That’s the essence of leadership right there.

Chamath’s framework was simple. Everything had to be about answering the 3 most difficult questions for any consumer product:

• How do you get people in the front door?

• How do you get them to an aha! moment as quickly as possible?

• How do you deliver core product value as often as possible?

Anything that deviated from this—including “how do we get virality?”—was intentionally taboo. Why? Because only a ruthless focus on core product value (i.e. on users) would bring long-term business value. Virality is not about the user.

That’s discipline.

Framework x Discipline

They say a picture is worth a thousand words.

There’s no shortage of people talking about either “frameworks” or “discipline”. What you won’t find as much is leaders talking about both together, and acting accordingly.

The devil, as they say, is in the details. What frameworks can and should you enable? And how do you create the necessary discipline around them?

One good set of answers lies within the book Working Backwards: Insights, Stories, and Secrets from Inside Amazon.2 Colin Bryar and Bill Carr, two long-tenured former Amazonians, give their inside view on how the Leadership Principles have framed—and continue to frame—Amazon’s success. They infuse a set of mechanisms, detailed in the book, which together form a consistent framework for internal innovation. The rest is, quite literally, history.

To make it more personal, let me draw an example from my own past experience.

Enabling a Framework

When I joined as the VP of Engineering at one of my past employers, I found a lot of good, competent people. However, it was clear that we had to do better than ship only every couple of months. Our Product colleagues were spending a lot of time with customers, so I was confident enough we were focused on the right user value. What we had was a delivery problem.

We eventually started shipping at least once every other week, with many more production deployments in between. This was possible due to a simple framework that helped channel everyone’s efforts:

Ship more often by focusing on increasing flow.

I spent a bit of time up front helping the team understand the (often counter-intuitive) ideas of flow and lean software development. And I tried my best to inspire them with a vision of building a “product with a pulse”—something customers see and feel is constantly getting better.

Given the north star of increasing flow, everyone understood we had to find and remove the bottleneck—and then move on to the next one. So the rest of the framework helped concentrate on that:

1. Clear, measurable and continuously improving development process. These are the guardrails for everything a team does. We had to first clarify and document what it looked like, and why. We also instrumented it so we could understand if our actions to improve it were working. JIRA’s control chart helped us zero in on the bottlenecks and address them in retrospectives.

2. Reduce critical technical debt. There was low hanging fruit on this but no coherent strategy to address it. We agreed on something simple: “Where does it hurt? How often does it hurt?” The team understood that code that is difficult to change and needs to be frequently modified is a big liability. So we honed in on that. Part of this work was also implementing the most frequently used UI components as part of an existing design system.

3. When in doubt, take a risk. Another cause for the poor throughput was engineers expecting perfect product requirements. While it’s important to be dilligent with those, they’ll never be perfect. Oftentimes they could be opinionated and easily fill in the gap themselves. They were simply too risk-averse, and I encouraged them to make their own judgment calls. If it’s the wrong call, that’s OK—we’ll learn. Plus, this empowered them and (again, counterintuitively) brought them closer to Product in the end.

Creating Discipline

While the framework is explicit and documented, creating discipline is a fuzzier concept. As I wrote in a previous post, you want commitment, not compliance. Discipline is about building better habits, not coercing.

More important than how good we are right now is how we are trending. Continuous improvement is how you win in the long run. Part of the revised development process was a simple template for living, asynchronous “sprint logs”, including the goal, decisions made, etc. This allowed us to have better retrospectives (also “logged” in a similar format) and have the discipline to focus there on what was most hindering flow.

My role as VP Engineering was to make sure this process was religiously followed. I tried my best to coach the team members on running it effectively, developing their writing and thinking skills, and addressing their concerns.

Lastly, repetition is a key part of discipline. As Chamath also points out in the video, every all hands, every Q&A was about those 3 questions. In our case, I used to send a “top of mind” weekly email3 to the whole team and leadership. It reinforced the priority, the progress we had made, what was still difficult, and any relevant resources for skill development. Part of the discipline was also making clear I expected these emails to be read as they were a key part of shared context creation.

The Takeaway

As a leader, it’s essential that you create and nurture a way of systemically driving focus Frameworks are frames of reference that help people concentrate on what truly matters. Remember that total freedom is disorienting and the right constraints are enabling. People will welcome anything that helps them productively channel their effort and creativity.

However, without discipline the best frameworks are useless. Strategy without execution is pointless. As an architect of the system, it’s not enough to design the blueprint. You also have to make sure it’s followed, day in day out. If not, and despite best intentions, you’ll ultimately miss the mark.

🙌🏽 Thank you for reading! Enjoyed this week’s edition? Have feedback on how I can make this more valuable to you? I’d love to hear it — just leave a comment below.

👉 You can also follow and DM me on Twitter @prla

Share

1. Chamath is also a great writer, which can be gleaned from his annual letters.

2. Cedrin Chin wrote an excellent summary of this book in his phenomenal Commonplace blog.

3. I wrote in more depth about this specific type of email in my recent guest post on the Pragmatic Engineer newsletter and also highlighted here.