Buy My Book, "The Manager's Path," Available March 2017!

Saturday, December 6, 2014

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.

Wednesday, October 22, 2014

"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?

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. 

Thursday, October 9, 2014

When Defining Reality, Don't Forget To Deliver Hope

I had a great 1-1 with one of my tech leads today, who came by my office hours and asked me for advice on becoming a better manager. I gave my usual rambling reply to broad inquiries; we talked about making personal connections, reading a lot of blogs and books, experimenting with different ways of asking questions to get people to reveal their true interests to you, so that you can better help to nurture and serve those interests.

But then, at the end, I had a thought. I asked him, how often do you talk to your team about what the future is about? How well do you know what the future of your team should be like? Not the product roadmap, which is in the capable hands of an amazing product lead, but the technical future. How to think about building systems that are future-thinking, becoming a better team, writing better code.

"Not that often" he admitted.

So, I persisted. How often do you spend some time away from your keyboard, away from the internet, away from meetings, and think about what you think the future of your team should be, the areas that you could focus on, the big opportunities for growth?

Again, the answer was "Not that often."

This is not at all surprising, of course. When you work in an industry where you focus on building out technical skills and getting more things done for the first many years of your career, making that shift into management (really a career change) can lead to the temptation to focus on solving today's problems now. Solving today's problems well is probably how you ended up rising into a tech lead role, and we all know that there is never a shortage of problems.

But when you focus on nothing but today's problems, even if you are a great manager who does everything right, you are unlikely to motivate your team to greatness, or inspire the level of loyalty and passion that makes a team gel and prosper. You are missing the one thing that you cannot overcome with great management skills. You're missing leadership.

You can be the greatest manager in the world, but without leadership and vision, your team will not be truly sticky to you.

Fortunately, leadership is not a skill you have to be born with. It just requires that you identify the future and articulate it. "Define reality, give hope." Too often first-time tech managers focus on reality. We're comfortable with reality, reality is our bread and butter. But the future? Painting a vision for the future, even the future 6 months out, is a risk. You may not be able to deliver on that future vision. It may not be the right thing to do when the time comes. Reacting to today is so easy, and trying to predict the future seems really hard

But there's a simple (note: not easy) secret to breaking that habit and creating a vision: practice. Get away from your keyboard. Force yourself to sit in an empty room with a whiteboard or a pen and paper and write some ideas down. Grab a colleague or two to brainstorm with if you need to, but do some of the work by yourself. Then start painting that future to your team. This is the most important thing you can do to become a truly well-rounded manager, and if you aren't doing it, block your calendar tomorrow and start.

Sunday, August 10, 2014

On Charm, Skills and Management

I had a great twitter conversation today with Julia Grace on the topic of hiring managers, which you can see in pieces here. The outcome was a hard look at the past couple of years of my own management experience.

TL;DR: Being a manager is nothing at all like being a tech lead, and hiring managers on the basis of their strength as individual contributors is not the guaranteed way to great technical leadership.

I got into engineering leadership because, first off, I wanted to have more impact and responsibility, but secondly, because I was the most senior engineer on the team, and a good communicator to boot. This actually worked out fine for quite a while. I could inspire people to work for me largely because they believed that I had things to teach them, and when I had the time to sit individually with engineers I did teach them many things. When I was hands-on, I could easily identify problems with our process, bottlenecks in our systems, and features that we should push back on, and I did all of that and more. In short, I was a really great tech lead.

But tech lead stopped being my job long before I learned how to truly manage well (nb: I may not yet know how to manage well). When you're not actually able to spend lots of 1-1 time with engineers, and you aren't so deep in the code that it's easy for you to see how the process is frustrating, suddenly those bits of management that you could get away with being bad at become more important. The bits like "making time for 1-1s", and "identifying systemic issues via second-hand reports" and "talking about the status of projects that you haven't actually written any of the code for yourself."

If you wonder why you see so few great managers in startup land, I think the answer is obvious: most of us got to our position by being great tech leads, and we haven't all figured out how to make the leap from tech lead to manager. For me, it's taken a ton of coaching from both a general executive coach and a CTO coach provided by my company. On top of that, I am fortunate enough to have gotten some training while I was still at my finance job, and to have seen effective managers do their thing, so I have a general idea of what good management looks like. And even with all that, I've made pretty much every mistake in the book.

Truthfully, if your company doesn't provide you with a ton of structure and guidance or experienced managers to learn from, you've got a long road ahead of you if you want to become a great manager. Because it is not just about charm and engineering skills, and that is probably how you got here. When you want to hire and retain great engineers, they need someone they can learn from, and what do you do when you don't have the time to be that person? How do you hire the people that can teach and inspire in your place? How do you grow the engineers you have now into the great tech lead you once were? You thought you were good at recruiting when you had someone else sourcing and closing all the candidates, but now that person is you. Oh, and have you ever justified hiring plans? For a team whose code you've never actually written?

Beyond recruiting: You can identify process bottlenecks, but can you identify them when you are not personally impacted by them? You've heard that clear goal setting is the key to strong leadership, but do you know how to do it? No, really, are you prepared to spend your Sunday evening writing quarterly goals, which is what I'm supposed to be doing right now? Have you ever measured engineering efficiency? Do you know what that is? Made a strategic multi-year roadmap? While worrying about preparing a deck for a team meeting where you'll be explaining why your team should care about these goals at all, and writing mid-year reviews to boot?

I've hired and promoted various engineering managers since becoming the head of a growing team. Some have been experienced managers, some have been great tech leads looking to make the jump to becoming managers. They've all had ups and downs, but make no mistake, I've had to spend lots of time creating structures for all of them to be successful. The great tech leads may have an easier time winning over the engineers, but they still need to be taught the basics of structured management, and they won't all be successful or happy in that role. There's no silver bullet to creating a great leadership team except for putting in a structure that makes their responsibilities clear, for their sake and yours.

So, if you're a great tech lead who's moving into management, congrats! Just be aware, the only useful thing that gives you to take into future leadership is a general sense of best practices and hopefully the ability to communicate to other engineers and non-engineers. Engineering management is not just being the tech lead of bigger and bigger teams, and the faster you realize that, the better off your team will be.

Saturday, June 7, 2014

Accountability and authoritarians

A not-so-secret aspect of my personality is that I have no problem with the policing aspects of leadership. I have a law and order side to me, if I believe in a rule/practice, and I see people breaking it, I have no problem being the one to call them to task.

This habit actually works out ok in a room full of peers; it doesn't exactly endear me to people but it means that, eg, the build doesn't stay broken for long. Unfortunately as I have gone up in the management chain, it has become a problem. Why does having a peer that holds you day-to-day accountable work, but having a boss that does so fail?

First, it seems that having me hold individuals accountable ends up causing some individuals to stop holding each other accountable. It is viewed as the thing I do, the boss' responsibility. If it's important, the boss will care, and she will come down and call us out. This is obviously far from ideal. A high performing team will hold each other accountable; after all, you want feedback to come as quickly and naturally as possible, and that can only happen when individual team members call out each other.

Second, I have come to discover that it is rather demoralizing for team members to be called out be me. I know, I know, why is this a surprise? It is still hard to get used to the idea that I am not just one of the team, and that everything I do is amplified and taken in ways I don't always anticipate. In fact, I think that it is important that most negative/corrective feedback from me go to my direct reports instead of farther down the chain. That doesn't mean that I can't offer suggestions on architectural improvements or process tweaks, but it is demoralizing for me to ask a developer why the build is broken. In fact, it is important that I'm seen as an inspirational figure to my team, someone they look up to and look forward to interacting with, and not vice-versa.

Finally, I'm actually pretty far away from the impact of the rules these days. What might have made sense when I was in a team writing code may not be ideal for the current team, the current environment. The only true best practice out there is to let your team take a concept or process and iterate on it until it takes on a form that works effectively for them. It simply doesn't make sense for me to make and enforce the rules myself; it is my job to provide the high-level goals (such as "creating a Cinderella experience for our customers and ourselves") and to push the team to find the right ways to implement those goals.

So, what is the takeaway here? I'm getting out of the business of being the rule maker and rule enforcer. Instead, I'm setting goals and very high-level guidelines, and giving the power to create policies and practices to the members of my team. I want to work myself out of a job, after all, and the best ideas don't come from me, so why should the policing?

Wednesday, May 28, 2014

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.

Saturday, May 10, 2014

Please stop threatening me with Moore's Law

For as long as I can remember, Moore's Law has been one of the great tech bogeymen. It's going to end, we fret, and the way we write code is going to have to change dramatically! The sky will fall, and we need to prepare ourselves for this end times!
When you hear the same message for well over ten years, its efficacy starts to fade a bit. You start to wonder, when exactly is Moore's Law going to end any more than it already has? When is this going to happen in a way that actually affects me more than it did five years ago? What even IS right around the corner, if the foretold end of performance hasn't much affected me in ten plus years?
The truth of the matter is this: if you care about Moore's Law, you're probably already writing code that combats it, because you care about performance. The trick of Moore's Law, as we all have been beaten over the head about, is parallelism. But why would I wait for the end of Moore's Law to bite me? The times I have cared about performance, I haven't waited. I've parallelized the crap out of code to move performance sensitive code bases from few fast cores to many slow cores. And as soon as I could, I ripped most of it out in favor of a distributed system that was faster and more scalable. And then that was ripped out in favor of smart streaming from SSD. The circle of tech life takes advantage of the latest hotness as needed to get the job done, and I have no reason to believe that Moore's Law is anything more than a factor in that equation.
These days most of us are concerned about a much more complex interaction of performance issues than simple processor speed. We're network sensitive, IO bound, dealing with crazy amounts of data, or simply trying to deal with a ton of simple things at once. We already have systems built to make IO and network calls asynchronous. We're already processing completely separate work independently. Because we can, because even without the terrible end of Moore's Law we care about performance. There's no need to call up the bogeyman to make your case. He's sitting in the next cube, making sure we parallelized all our outgoing requests, and he'd rather you stopped getting so hysterical on his behalf.

Wednesday, February 5, 2014

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.

Wednesday, January 15, 2014

SOA and team structure

This week I sat on a panel to discuss my experiences moving to a service-oriented architecture (SOA) at Rent the Runway. Many of the topics were pretty standard: when to do such a thing, best practices, gotchas. Towards the end there was an interesting question. It was phrased roughly like this:
What do you do when you need to create a new feature, and it crosses all sorts of different services? How do you wrangle all the different teams so that you can easily create new features?
I think this is a great question, and illustrates one of the common misperceptions, and common failure modes, of going to a service-oriented architecture.

Let me be clear: SOA is not designed to separate your developers from each other. In my team, developers may work across many different services in order to accomplish their tasks, and we try to make it clear that the systems are "internal open source". You may not be the expert in that system, but when a feature is needed, it's expected that the team creating the feature will roll up their sleeves and get coding.

At big companies SOA is sometimes done in order to create areas of ownership and development. At my previous company, SOA was (among other things) a better way to expose data in an ad-hoc, but monitored, manner, without having to send messages or allow access to databases. The teams owning the services may be in a totally different area of the company from their clients. To access new data, you needed to coordinate with the owning team to expose new endpoints. It created overhead, but data ownership and quality of the services themselves was an important standard and losing velocity to maintain these standards was an acceptable tradeoff.

That is not the way a small startup should approach SOA, but if you don't anticipate this it may become an unintended outcome. When your SOA is architected as mine is, with a different language powering the services than that which powers the client experience (Java on the backend, Ruby on the frontend), you start to segregate your team into backend and frontend developers. We address this separation by working in business-focused teams that have both backend and frontend developers. Other SOA-based companies approach the challenge of separation by creating microservices that only do enough to support a single feature, so that a new feature doesn't always require touching existing functionality. Some companies do SOA with the same framework (say, Ruby on Rails) that powers their user-facing code, so there's no language or framework barrier to overcome when crossing service boundaries.

SOA is a powerful model for creating scalable software, but many developers are reluctant to adopt it because of this separation myth. There are many ways to approach SOA that work around this downside. Acknowledging the risk here and architecting your teams with an eye to avoiding it is important in successfully adopting this model in an agile environment.