Vision and Trust: External and Internal Leadership

Fred Wilson recently wrote a post where he defined leadership as this:

It is charisma, it is strength, it is communication, it is vision, it is listening, it is being there, it is calm, it is connecting, it is trust, faith, and belief

Trust, faith, and belief. These are all words for the same thing, right? Well, not exactly.

I have observed that many leaders, especially the ones called visionary, are often evaluated in the court of public opinion on the following subset of those qualities:

Charisma, strength, communication, vision, connecting, faith, and belief

Listen to them talk to a crowd and they will blow you away with the clarity and strength of their vision, with their ability to connect with their customer. This in turn translates to a level of faith in that vision and belief in the overall direction that they are guiding their company towards. Awesome. Literally, awe-inspiring to witness. These are the public qualities of leadership that show up in the media, that the whole company can see in an all-hands, that you can see firsthand when they speak at a conference. These are the qualities that the board members see, that the venture capitalists invest in, and it is pretty hard to get into the position of successful startup founder without them.

So where do the rest come in? Listening, being there, calm, trust. These qualities are more difficult to evaluate based on an interview or a presentation, these are the “internal” signs of leadership.

Trust is a contract between two people. You are constantly creating and building trust in a long-term relationship with everyone around you. When you listen, and are there for people, and are calm when interacting with them, you build trust. But without that listening, without “being there” in a way that lets people feel the ground beneath their feet, without calm, trust is fragile or non-existent. Trust is regularly tested and negotiated based on our ability to show up. I would say that these more private qualities, these relationship qualities, are the qualities of management that every great leader must possess. Managers know the value of steadiness, of showing up for that 1-1 every week, of reacting slowly and listening to the people around them.

So even great external-facing leaders need some management skills. What about the managers?

Managers fail when they lack communication, connecting, and strength. A manager who can’t communicate with their team cannot execute effectively. A great manager connects with their employees as human beings (without turning into full-time therapist), and has the strength to shoulder the challenges of making hard calls in the trenches with their teams, the firings, the resignations, the projects being cut and the delivery or missing of deadlines. The day-to-day pains are very real for the manager and without strength it is almost impossible to do the job well.

But what about vision? We think that vision is the realm of the strategist, but vision also has a place in the manager's skill set. Instead of business strategy or architectural future, the manager’s vision sees what their organization looks like in 2 years, what their team can grow to be capable of accomplishing, what the successful day to day looks and feels like for the employees on their team.

As a final data point, my former CTO coach and one of his partners wrote about the Management/Leadership split in their new version of The Art Of Scalability, excerpted here. Between these three sentiments, perhaps you can triangulate your own path to being a great leader who manages enough, a great manager who leads enough, or whatever the situation calls for.

Entrepreneurial Gap

I recently came across a blog post that mentioned an intriguing concept, the "entrepreneurial gap." The idea is straightforward: give people more accountability than they have the direct resources to accomplish.

In many organizations employees are generally held accountable only for things fully within their control. So while the CEO has both all the resources of the company and the ability to make decisions that cause major tradeoffs (sacrificing profit for growth, for example), a manager of a team is only given projects big enough for that team to accomplish and goals big enough for that team to meet.

The entrepreneurial gap comes in when you give people bigger accountability than they have the direct ability to execute against. This is in many ways the classic startup move. You hire people and give them enough freedom to accomplish whatever they can manage to accomplish. Because early startup employees tend to be very entrepreneurial they often find a way to do just that, to gather support from other people in the organization and align efforts to produce outsized results. I think this is an important element of a growth business, something that inspires great people to work for a company, and produces a really fun culture to work in.

But, there's a trap.

The entrepreneurial gap works incredibly well when you give teams aligned goals. If you read the first case studies in the paper, you will see that in all of the examples the CEOs focused the company on a few goals, and in fact in all three examples there was a very strong emphasis on the customer. In companies where everyone is working ultimately towards the same goals, the entrepreneurial gap is awesome because it encourages people to work together and identify opportunities and efficiencies, especially cross-functionally, that may otherwise be lost.

Unfortunately, it is just as common to see companies put in place both an entrepreneurial gap and too many or misaligned goals. When you are in direct competition with your peers for scarce resources and you are not going to be graded on the same outcomes, the entrepreneurial gap produces a toxic environment of politics and power plays. Perhaps the best idea sometimes wins in these situations, but more often the best political players rule the day.

So what do we take away from this?

Organizational alignment is important because it lets you successfully ask more from people than the resources they have at hand. Without organizational alignment, you get political maneuvering. Without stretching people beyond their direct control, you get a lack of collaboration and creative cross-functional engagement. Set the right priorities and give people the freedom to stretch to them, and you will see the full potential of your organization come to life.

(The paper again: The Entrepreneurial Gap: How Managers Adjust Span of Accountability and Span of Control to Implement Business Strategy)

Get Curious

The best advice I’ve gotten in recent years is simple. Get Curious. For those of you who don’t know me personally, I can be rather aggressive, especially with things I don’t trust. Whether by virtue of personality or experience, my instincts always lead me to attack and take apart the unknown. This is in some ways a good trait in an engineer, after all, the unknown is what causes you to get paged at 2am. Unfortunately, when it comes to interpersonal interactions, aggressively looking for flaws in things you don’t understand looks less like smart defensive behavior and more like obnoxious trolling.

So how can one honor the need for clarity without attacking and picking apart things in a way that causes others to get defensive? The tactic I’m using is “Get curious.” Instead of assuming that the other party hasn’t thought of your objections, try to understand deeply the context in which they are making their statements. Why do they seem to want to do something that may sound illogical to me? What is their perspective on the circumstances? What have they tried to do already?

A few years ago I wrote about “Yes, and...” I won’t lie; I still struggle to this day with “yes, and”. For me, “get curious” is a bigger picture version of "yes, and," one that I find easier to keep in mind. If you’re always curious and looking for the context, you’re open to the possibilities that are out there. The possibility that you’re missing something important. And that openness makes people want to work with you.

“Get curious” could be the mantra for the learning organization. Curiosity in the face of failure, instead of blame, leads to a safe environment for people to fail, and lets us discuss our failures. Curiosity leaves us open to new ideas. Curiosity enables us to recognize our differences and embrace them to create a stronger whole.

So for those of you who are quick to blame and judge and want to get out of this habit, get curious. For those of you who feel like your team is afraid to take chances and fail, get curious. Even for those of you who are afraid that you’re being too nice and are not challenging your team or colleagues enough, instead of getting mean or aggressive, get more curious. You’ll be surprised at how much more effectively you can create change when you approach situations with open curiosity.

Meaningful 2014: Everybody Hurts (notes on SparkCamp)

It is valuable to get out of your own head, and see what others are thinking.

It is even more valuable to get out of your own industry and see what others are struggling with.

This summer, I had the privilege of attending Spark Camp: Visionaries, Leaders, and Managers. Spark Camp is a gathering focused on media and newsroom folks that also pulls from external areas including the arts and technology, and I was invited to attend as a representative outside of media.

To be honest, on the first day I was rather intimidated. I am not a creative. I am not a writer, a media luminary. Everyone there had done so much. Here was the choreographer of a famous musical! There was the editor in chief of a major magazine! The mayor of a city! The writer of a blog I love and admire! The head curator of my favorite art museum! (hello, impostor syndrome)

The sessions started, and we talked about problems we faced as managers. The challenges of performance reviews. Managing people from different generations. Some of the notes I took include:
"Performance reviews as a measure of culture"
"Vulnerability inspires investment. Management is not performance art."
"Designers and engineers both define themselves often by their process"
"Conversation's role in creativity"
"Victim vs Player: Teaching folks how to be players" (more on this some other time)

My biggest takeaway was that we in tech think we are dealing with a special situation, a special workforce. Knowledge workers who have options, who can strike out on their own, who are temperamental and amazing and can change the world or give us migraines. We are not alone. In fact, people in the media industry (and beyond) deal with the same thing. Writers and artists are not all starving, and the talented ones have as many options as talented engineers.

Similarly, I'm not alone in feeling creatively stifled by the challenges of management. People with backgrounds in the creative arts discover themselves with leadership positions that offer little time, space, or appropriate opportunity for creativity. Finding that creative outlet is a universal leadership struggle.

I'm grateful for the opportunity to get some perspective on my own battles, and share my experiences with a diverse group of leaders. We often see writing on "impostor syndrome" and tricks for combatting it. Here's my trick: say yes to situations, and try to handle them with grace even when you feel completely out of your depth. Because under the surface we all struggle, and we all doubt, and sharing those struggles and doubts with strangers is sometimes the best way to free yourself from them.

The Best Decision I Made in 2014

Many people think that the role of leadership is decision-making. The desire to be the one who makes the calls drives some to climb the ladder so that they can become "The Decider."

I'm sorry to disappoint those who want this to be true, but in my experience the role of leadership is in fact to make as few decisions as possible, and to make the decisions that you are forced to make utterly mundane. Here are some of the mundane decisions I've made this year:
The first pass of a seating chart
Perfunctory approvals around uncontroversial hiring
Rubber stamping of well-thought-out architectural decisions
Signoff on budgets for vendor products we clearly need

I set up a lot of policies over the past few years. Some of them I've blogged about, for example, promotion committees. But I've also created policies around how new languages and frameworks are introduced, on-call rotations, even how we buy office equipment (oh the glamorous job of a CTO!). The goal of pretty much all of these policies is to make future decisions easier, and to empower various people on my team to make decisions without me.

So, I don't believe that good leadership is heavy on decision-making. That being said, you can't be a leader without occasionally setting a direction, which leads me to The Best Decision I Made in 2014. It started with a twitter conversation about continuous delivery, on January 3. I have been thinking about continuous delivery forever, and trying to move Rent the Runway in that direction for as long as I've been running engineering. At the end of 2013, we created a task force to make our deployments, then-weekly and taking up to 6 hours to do, faster and less painful. The team was well on their way to success by January 3. And so, inspired by my conversation, I sent this email:

Starting in Feb

---

Camille Fournier	Sat, Jan 4, 2014 at 9:40 AM
To: tuskforce
I want the one ring to release every day. Even if there's no user visible changes. Even if there's traffic. Even if it means we break things

That's it. I held my breath to see the responses. And as they rolled in, one by one, all of the engineers agreed. They were excited, even! So I started to tell others. Our Head of Product. My CEO. I told them "this might cause some pain, the first couple of weeks, as we figure out how to do this safely, but it's important." 

And so, come February, we began releasing every work day. And it was glorious. 

What made this decision so successful? What did I learn from this?

A great decision is often not a revolutionary move. We were doing the technical work to enable this already. The team wanted to be deploying more frequently. All I did was provide the push, to raise the bar just a little bit higher and express my confidence that we would easily clear it. 

The thing I learned from making this call wasn't anything about the decision itself. It was about the process that got me there. You see, this came about right after new year's, when things were quiet at work and I had some time to sit alone and think (or, in this case, tweet). All the sudden, I had ideas again! And it hit me: I need regular time alone, away from meetings and people, in a quiet room with a whiteboard. 

So I started blocking my calendar every Wednesday afternoon, and things started to change for me. In those Wednesday afternoons, I thought through the next evolution of our architecture. I thought through our engineering ladder, and our promotions process. I thought about problems I was having with people and how I could make those relationships better. I did some of the foundational work to create the 7 completely new talks that I wrote and delivered in 2014. I made time for the important but not urgent. In short, I grew from a head of engineering focused on the day-to-day into a CTO who thought a lot about the future.

The best decision I made in 2014 wasn't, actually, to tell my team to release every day. That's just the story I've been telling myself all year. The best decision, really, was to make time to think.

"Meritocracy" and the Tyranny of Structurelessness

Engineers like to believe in the idea of meritocracy. We want to believe that the best idea wins, that the person who produces the most value is rewarded, that we judge only on what a person brings to the table and nothing more.

Nothing could be further from the truth, of course, because we are ultimately human, and humans are biased in many ways both subtle and not. This post is not going to attempt to educate you on human bias. If you're unfamiliar with this concept, I'd welcome you to watch this talk put together by Google on the realities of bias in the workplace and efforts you can take to combat this.

Now, all that being said, I love the idea of meritocracy. After all, I am a CTO, surely I am here mostly due to my merit! OK, even ignoring my own position, I would really like to create an organization that does behave in a meritocratic fashion. I don't want to say that someone has to have X years of experience to do something, or Y arbitrary title. I want to reward people who show up, take on big tasks, and produce great results.

The most common way that people at startups attempt to create meritocratic environments, to avoid this title-driven fake hierarchy, is to eschew titles entirely. Eschew titles, have "flat" organizations. Removing the trappings of hierarchy will mean that we are all equals, and will create a place where the best idea wins, right?

Yeah, right.

Removing titles and pretending that the hierarchy doesn't exist does exactly the opposite of creating a meritocracy. It most often creates a self-reinforcing system where shadow hierarchies rule the day and those outside the in-group have even less opportunity to see their ideas come to life. It frustrates newcomers, and alienates diverse opinions. It is, in short, the enemy of meritocracy.

What is a poor meritocratic-seeking engineering leader to do?

The only answer I have found is echoed in the video I linked above. Far from eschewing titles and pretending no hierarchy exist, you must acknowledge this reality. And, furthermore, you need to be really, really explicit about what it means to actually be working at the level indicated by these titles. You need to first, make it really clear to yourself what is required at every level, and then make it really clear to your team what it means to be at every level. 

This is not easy to do. My greatest fear in implementing this has been the fear that people will come to me and try to "lawyerball" me into promoting them to a level that I don't feel they are working at. Or that people will become obsessed with their title and constantly be trying to get promoted and treating each other differently due to titles.

To point 1, though, if a person truly is meeting everything I have laid out as being necessary for working at a level, why would I not want to promote them to that level? It either means that I haven't really articulated the level clearly enough to really encompass the responsibilities, or in fact, they really deserve to be promoted and I am letting my bias get in the way of evaluating merit.

To point 2, if I lay out levels that I believe are genuinely increasing in impact and responsibility and have high bars to clear, why would I be upset if people strive and work hard to grow into them? "Meritocracy" doesn't mean "Only reward people who are naturally gifted at what I value." That's the thing I'm trying to stop doing!

On treating each other differently due to titles, well, that's a two part problem. The first part is this: creating a culture where ideas are welcome from anywhere requires cultivation with or without titles. The second is that generally people get promoted because they have shown bigger impact and influence on the organization, and so it's not that surprising that they will have bigger voices. I'm not sure that is a terrible thing, if those people are living up to the high standards that come with that influence.

Finally, of course, to get a group to embrace this is tough. So why not take the decision-making power to promote people out of the hands of managers? That is what we have done in my team. We now use promotion committees, composed of engineers at a level or two above the person trying to get promoted. Now the whole team is bought into the idea that promoting someone is not a gift bestowed by management but an acknowledgement by a group of peers that one should join their ranks. 

This is not going to be perfect, and it is a lot of work for me to implement. But in my experience taking the time to establish clarity in anything is a worthwhile exercise, and creates a better and ultimately more efficient organization. 

Revisiting ideas: Promotion from Within

Ages ago a friend of mine wrote a rather seminal post on "promotion from within". It is interesting to go back and read this post through the lens of hiring and leading a team for a few years. It is a great post, but I think that one major point often gets overlooked, and this point causes many companies who follow its advice to fail. That point is this:

2) Using either the few experienced managers you've been able to internally promote or failing that, outside executive coaches, intensely mentor your more inexperienced managers to develop their skills. Typically, because many of your management candidates were less than fully-qualified, they will demonstrate potential but still be unsure in their new roles. Until they are comfortable and practiced in their roles, both they, their peers, and their teams will exist in a state of some distress. 

This is problem I have seen both at my own company and also observed at others': We promote from within, but provide no mentoring or guidance to those so promoted. Great managers are truly not born. They are made, and usually made through both being sat down and patiently taught the ways to effectively lead projects and people, but also through observing both successes and failures.  They are also made by being called to task on their own personal failures, something that many startups are unwilling or unable to do. The cult of personality around founders and early employees can work against the one thing necessary to make "promote from within" successful: some form of external help.

Most of us in the startup world are working amongst people that have very little experience managing. And we've taken these ideas that Yishan so eloquently voiced, that culture is paramount, and elevated them to high status, while forgetting that there is a lot to learn to be a successful manager. I know that I came into this job two years ago thinking that given my natural willingness to be in charge and my strong technical skills I would be a great manager. Haha! Truthfully I'm only now getting to the point where I have an inkling of all the things I don't know, and a large part of that is thanks to a ton of coaching. I would not be able to lead my team successfully without coaching, and even with my own coach, I need a coach to help the managers that report to me.

So, promote from within. But don't cheap out on the process by forgetting that these new managers and leaders need help, need training, need to be held responsible for both the good and the bad that they will inevitably produce in their first months and years as managers. Otherwise you might as well hire experienced external managers, because my hunch is that the payoff is actually equivalent, risking culture vs risking unguided learning.

Getting From Here to There

As part of my work to make myself a better leader, I'm reading the book "What Got You Here Won't Get You There." The phrase itself resonates with me strongly now as I'm in reviews season and writing reviews for a number of senior engineers and engineering managers. One of the standard refrains I see in self-review "areas for improvement" is the desire to improve something very technology specific. A manager might say "I want to jump in more to the code so I can help take problems off my team." A senior engineer looking to grow to the staff engineer level might say something like "I want to get better at understanding distributed systems." Heck, even I am tempted to put "I want to spend more time in the early phases of architecture design so that I can help improve our overall technology stack." We're all falling victim to the problem of "what got us here won't get us there."

Engineers should spend their first several years on the job getting better at technology. I consider that a given and don't love to see that goal in reviews even for junior engineers, unless the technology named is very specific. Of course you're getting better at technology, programming, engineering, that's your job. You are a junior individual contributor, and your contribution is additive. You take tasks off of a team's list, get them done, create value by doing, and work on getting better at doing more and more. You got here because you put this coding time in.

After a certain point, it is more important to focus on what will make you a multiplier on the team. Very very few engineers write code of such volume and complexity that simply by writing code they enhance the entire organization. For most of us, even those in individual contributor roles, the value comes through our work across the team, teaching junior engineers, improving processes, working on the architecture and strategy so that we simply don't write as much code to begin with. There is a certain level of technical expertise that is necessary to get to this multiplier stage. As an individual contributor, a lot of that expertise is in knowing what you don't know. What do you need to research to make this project successful? You don't have to be a distributed systems expert but you should know when you're wading into CAP theorem territory.

It's harder for managers. Every time you switch jobs, you're interviewed with an eye towards the question, "can this person write code?" We don't trust managers that can't code, we worry that they're paper-pushers, out of touch. But when you hire an engineering manager, you often don't want them writing code. Managers that stubbornly hold onto the idea that they must write a lot of code are often either overworked, bottlenecks, or both. The further up you go in the management chain, the less time you will have to write code in your day job. The lesson here is not "managers should carve out lots of time to write code". It is, instead, don't get pushed into management until you've spent enough time coding that it is second nature. If you think that writing more code is the unlock for you to manage your team better, to grow as a better leader, you're going backwards. The way forward into true team leadership is not through writing more code and doing the team's scutwork programming. It is through taking a step back, observing what is working, what is not working, and helping your team fix it from a macro level. You're not going to code your team out of crunch mode by yourself, so spend your time preventing them from getting into crunch mode in the first place.

Coding is how you got here, engineering is what we do. But growing to levels of leadership requires more than just engineering. You've gotta go beyond what got you where you are, and get out of your comfort zone. Work on what makes you a multiplier, and you'll get there.