Make Boring Plans

You’re probably familiar with the concept of Choose Boring Technology. If you’re not, I’ll wait for you to read the excellent blog post by Dan McKinley that inspired a much-needed correction in tech to balance “innovation” with stability. I’m here to take this to the next level, and talk about how “boring” should apply not just to your technology choices, but to your plans.

I spoke to someone several months ago who was frustrated with their management chain. They were anxious about the fact that the management chain was always pushing on delivery in an unpredictable way. The team felt really high pressure, even though the projects they were working on were all part of long-running infrastructure renovations. Why was this so stressful? Why, they asked, was the plan not already laid out? Why isn’t this boring?

Why isn’t this boring?

It might say something about the area that I focus on, Platform Engineering*, that “why isn’t this boring” would ever come up. You see, usually when people are in this situation, they blame everything but the lack of planning for their problems. It is a common belief in engineering that, with a clear enough vision, the rest of the pieces of work will fall into place. With a well-understood goal and smart engineers, the idea is that you can trust that people will work towards that vision faithfully and deliver something great. And this does, in rare cases, seem to work. After all, half of the hiring wisdom of the past has been “hire smart people and get out of their way.” Magic can happen with a small, highly-motivated group of people building a new thing towards a clear goal.

However, this concept of building towards a grand vision falls apart when you are building the underlying software that other engineers rely on. For better and for worse, Platform often has to be the place where we push new things to the rest of the company. A big change in the platform is the definition of an innovation token being spent. You want to move to Kubernetes? You’re gonna spend a lot of time figuring out how to operate it well in your environment, to start. You want to support a massive monorepo for the whole company? Hello innovation tokens everywhere, as you try to make it scale and perform well for all of your engineers and all of the languages they want to use. Speaking of new languages, you want to introduce Rust, or O’Caml, or even just C++17? The platform will have to support it.

Before you go blaming the Platform team for spending all of the innovation tokens for the company, remember that these initiatives are often driven by someone else. If Platform doesn’t support Kubernetes, some team will decide to build shadow infrastructure because they’re convinced that it will solve the problem they have to handle with their tens of microservices, and then it will land in the lap of Platform after a year with none of the work done to make it easy to operate, but all of the operational expectations anyway. Our goal is to build just enough ahead of you so that when you realize you need the capacity, it’s there, or can be with minimal fuss, and it’s reliable to boot.

Novel Technology Deserves Boring Plans

Since we often end up in the land of novel technology, we owe it to ourselves and our customers to be boring in other ways. And the most important way that a Platform team can be boring is by writing boring plans.

It’s great to have a vision for the future of the platform. To achieve this vision, a non-trivial amount of our job is not just building new big, scalable, complex software infrastructure, but moving everyone from the last generation of this software infrastructure to the next generation. Upgrade the programming languages, the operating systems, the libraries. Move from OpenStack to Kubernetes, from on-prem to the cloud, from maven to bazel, from svn to git. Migrate from the old storage system that was optimized for a rare legacy usecase, to a new storage system with higher availability and performance.

Making these changes happen, under the covers, has both interesting parts and boring parts. If you’re not a platform engineer, you shouldn’t see the interesting parts. The interesting parts are where we go and tune the kernel to perform well for our workloads. The interesting parts are where we build out automatic failover, so that we can meet the availability needs of the workloads. The interesting parts are the many patches we might contribute back to the inevitably-broken open source projects that hold half the world together but still don’t seem to understand how to work with FQDNs. The interesting parts are where we understand deeply the dependencies of our technology stack, the opportunities and limitations, and build solutions for our customers that fix limitations and unlock new opportunities.

When we don’t attend to the boring parts by making our plans predictable, the interesting parts turn into extra stress on top of the overwhelming anxiety of juggling these moves. When you make plans that start and end with the vision “we will move everyone to the public cloud, and it will be great,” you find yourself in the exhausting situation of running all of your old infrastructure, trying to figure out the new cloud stuff, and dealing with customers who are confused and angry that the thing they want to do doesn’t seem to quite work in either world.

Contrast this to the team that turns that vision into boring plans. They start with a small proof of concept, migrating perhaps a single application and learning in the process. Then they do the work of looking across other applications on the old platform, to see which ones are similar to the one that is now in the cloud. They work with those users to get them migrated and running, all the while gaining comfort with this new environment and uncovering the interesting gotchas. They write down what they’re learning, so that each new step in the migration builds on the last, and others can be pulled in without a huge knowledge transfer. The team focuses on the hard parts of the moment, whether they are figuring out data mirroring, or fixing a bug in a popular open source project, and they are free from the anxious overhead of wondering what is happening tomorrow. The users are also free from the stress of wondering when the work they need will be delivered, because the team has communicated plans that account for this process of iteration, learning, and gradual migration.

A Strategic Plan Is Obvious and Simple, Even Boring

Making boring plans is a foundational step in getting good at setting engineering strategy. Strategy is often confused with innovation and vision in tech circles, but they are far from the same thing. Having a future vision and recognizing the potential of innovations is valuable in building great strategy, but strategies that rely on unproven magic bullets are not good strategies. Good strategy identifies a problem with the current situation, proposes a principled approach to overcome it, and then shows you a coherent roadmap to follow. Strategy is not in the business of razzle-dazzle, it’s in the business of getting to the core of the issues so that the solution becomes simple and obvious. Good strategy provides the clarity that enables boring plans.

To become great at technology strategy, start by getting good at making boring plans. Get clear about the problem you are overcoming with your plans. Make the principles of the work at each stage clear:

• How do we know when we’re in exploration mode, and how do we know when we’re ready to commit to a direction?

• Have we talked to our users? Do we understand how they are using our systems, and have we made plans that account for their needs?

• What are the problems we’re focused on solving right now, and which problems are we leaving to worry about another day?

• How do we know if we’re on the wrong track, what are the guardrails, milestones, or metrics that tell us whether the plan needs review?

Your teams need more than a clear idea of the end state and the hope that smart engineers will inevitably get you there. Plans that are formed around hope are failing plans; hope is not a plan. Plans that change constantly are failing plans. When your plans are constantly changing, it is a sign that you either are making plans that express a certainty you don’t have, or you haven’t done your research to get the right certainty in place. Either of these is a waste of time and an unnecessary stress on the team.

So leaders, you owe it your teams, and to your users, to free them from the tyranny and stress of uncertainty. You must do the work to go beyond vision, create concrete actions, and make boring plans.

* I’ve defined Platform Engineering before, but the simple description is “the software infrastructure that all of engineering relies on.” Your operation system, storage systems, distributed compute frameworks, and software development tools may all fall into this bucket. To be clear, however, everything in this post tends to apply to any team that is working outside of pure greenfield product development, particularly when the work they do has a lot of downstream impact on users of their systems.

Enjoy this post? You might like my book, The Manager’s Path, available on Amazon and Safari Online! I also recommend the book Good Strategy, Bad Strategy, for those who want to improve their strategic skills. 

You can bring a horse to water...

Trying to Convince People to Change

I was talking to a friend who was frustrated with one of her engineers. This engineer had a tendency to fall into some bad habits when stressed out, and my friend had given him a book to read on the topic, but he hadn't bothered to read it. Why not read the book, which would shortcut all of these conversations and corrections my friend needed to make over and over?

Are you familiar with this story? I am, having lived it several times. I have given my team various books to read over the years. Some of those books include:

Turn the Ship Around
Leadership and Self Deception
Making Things Happen
The Five Dysfunctions of a Team

I have even held reading groups for some of these, I wanted so much for my team to read them.

I love to read, and I have grown to love books in the "self-help/business/leadership" genre. These books have taught me a ton, heck, I blogged my defense of the repetitive business book because I find so much value in them. They're great!

However, getting value out of books like these is predicated on two important factors:

1) You have to actually read them
2) You have to read them with an open mind to learning from them

Asking my team to read books has had mixed results. The most successful book I tried to get folks to read was Turn the Ship Around. I read it with my leadership team, and we would discuss it in our team meetings. It is a book that is so deeply applicable to the practice of managing engineering teams that I think it was easy for my team to appreciate its value.

For most of the rest of the books, the people who were already interested in the topics read them, and the people who did not want to change what they were doing did not. Even when the doubters read them, they read them with a mind towards disagreeing with their message, and I'm not sure they got anything out of the books.

This is not a fun lesson, but it is an important one for anyone who is managing a team. You can't force people to want to change. You can give them information, books, classes, coaching, but if they don't see a need to change, none of that will help. So the first thing you have to do, before giving them books, is to really convince them that they need to change.

 

Ah, but this is tricky! Do they actually need to change? If they change, it will make your life easier. Will it make their life easier? 

Sometimes, we want people to change when in fact what needs to change is the situation we've put them in. If someone on your team is acting really negative, do they need to change their attitude? Or perhaps, do you need to move them to a team where they are not being ignored by their manager?

Before you look to change the people, make sure that the change that needs to happen isn't in fact something in the environment that you can control. 

Most people are going to behave in unhealthy ways when they are in unhealthy environments. Asking someone to change the way they react to stress is a tall order. Sure, it would probably be good for them to chill out, be nicer, stop blaming others for their problems, but I've been working on my unhealthy reactions to stress for years and I know I still have a long way to go. Even when people want to change, personal change doesn't happen overnight. It is usually easier for a manager to change the environment than it is to change a person's reaction to that environment.

Looking back to my successful reading suggestions, they have almost all come when people had control over their environment, and the book was about helping them drive change in the team. It is pretty rare that I've given an unhappy person a book for reacting better to unhappy circumstances and seen them embrace it.

Poor reactions to difficult situations can negatively impact the team and it's your job as a manager to help people identify these behavioral issues. Books can be great for this, but they are rarely going to shortcut the process of change. No matter what, don't forget to look at the circumstances that are triggering the behavior. It is unlikely that you'll coach your team to Buddha nature but you might be able to reduce the stress that is causing the problems in the first place, and that's a win for everyone.

What do I do with my time?

Question:

I'm a new manager, new to both the company I work for and to management. When I joined this company there were several fires for me to help put out, and every day I was busy dealing with one urgent task or another. But now I'm drifting. My boss doesn't have time to tell me what to do, I don't have any features that I am responsible for, and no one is urgently requesting my time. What is my job, now that things are no longer on fire?

Ah, yes. One of the challenges of management that we don't often talk about is those times when you have no clear urgent tasks. Engineers deal with uncertainty in relatively bounded forms, such as, how should I break down this big project into smaller chunks, how should I architect this system, who should I talk to for information about this feature, what library should I choose? These are enough to stymie some, but usually by the time you've been working for a few years you know how to get started on these types of problems.

Management, however, is a different beast. Management is like being in operations. Operations engineers must balance a series of ad hoc needs (system configurations or permission granting, say), with fires (outages), and long-term strategic projects (moving to a new data center, upgrading a major piece of critical infrastructure). As a manager you also have regular ad hoc needs (1-1s, meetings, small decisions) and fires (hiring, firing, projects in trouble, outages). And you have long-term strategic projects (planning for the team growth, thinking about the next quarter's goals, anticipating future obstacles). Like operations engineers, many managers get really good at the ad hoc and the fires, and really bad at the long-term strategic projects. It's much easier to do things right in front of you than it is to think abstractly about unclear topics.

When faced with the blank slate of empty time and no obvious deliverables, what can a manager do to make the best use of that time?

As a new manager to a new company, downtime is a good chance to learn the existing systems. Learning things that you aren't actually working on can be really challenging, so if it's feasible you might find small bugs to fix or minor improvements to build, things that aren't urgent (in case another fire crops up) but that will give you the feel for working in these systems. You can also use the downtime to meet with other teams that your team works with, learn about their projects and challenges, look at what they're busy with. Lend a hand to their managers, or help your boss fill that gap if they don't have one.

At some point, though, you will have gotten comfortable with the teams, the code, the projects, and you'll still find yourself with downtime. This is the chance to flex your strategic thinking. Take a bigger-picture look. What are you not doing that is important, but not urgent? Maybe it's planning for reviews next month, setting up a team dinner, doing some proactive outreach to candidates you may want to hire in six months, or finishing that presentation that you have promised to give on testing but keep putting off. What are the recurring problems your team is having? What is not going smoothly? What could you be doing to resolve that? Remember, part of your job now is to define what work needs to be done. Your boss won't always be able to tell you what to do, and she probably expects you to tell her what needs to be done. Use this time to answer that question.

Sometimes we put downtime to use in bad ways, and I don't mean procrastination. There are times when the best thing you can do with downtime is take a breath, check in on the internet, watch a talk you have been meaning to see. All of that is better than using downtime as an excuse to make work for other people, which can happen if you're not thoughtful. If you use your downtime to half-bake a feature and throw it into prod for your team to support, that is harmful. If you use your downtime to wander around and interrupt your engineers who are busy working, that is harmful (and yes, I'm guilty of that sometimes!).

You are responsible for finding productive uses of downtime, and part of that is resisting the urge to meddle, micromanage, and distract your team just because you don't know what else to do. Is everything going ok? Are your teams productive, getting things done, working on the right stuff? Great! Use your time to think about the future, write a blog post, catch up on small unfinished errands. Don't worry, there will be another meeting, another fire soon enough. Enjoy it while it lasts.

Qualitative or Quantitative but always Analytical

I did a panel at Etsy's engineering leadership offsite today, which was amusing. One of the topics of the panel was:
Challenges of balancing data-light product bets vs purely data driven incremental improvements.

All three of the panelists agreed, although each of us phrased it a different way. The first panelist (Dan McKinley) spoke about the need, even for products that are not purely A/B test driven, to drill down on the goals and try to find something to measure about how a project will actually achieve a goal. If the project is part of a larger goal to increase revenue by 25% this year, what way is it contributing to that? How do we measure its success? Even when you are driving decisions by "vision" there is some quantitative goal you are trying to achieve, so state what it is.

The second panelist (Albert Wenger) spoke of the importance of balancing the quantitative with the qualitative. Some things cannot be purely quantitatively measured, and there are qualitative measures that are incredibly valuable to the process of discovering product market fit. User testing, user research, watching how people actually engage with a product are all essential to creating something great, beyond simply finding numbers to measure and trying to increase them.

My perspective on the issue is that qualitative methods are important, but qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.

So, instinct and guesses are necessary. But we needn't lose our analytical approach just because we don't have data. When you build something, you have a hypothesis about the person you are building it for. You have a guess as to what they will like, and most of the time you have a reason for that guess. When you're trying to build a business, you need a chain of events that you expect could happen that would indicate a product is successful. You have a sense of what to start measuring once the thing is released that will show whether it is working. Answering the questions of who is my customer, why would she use this, and what will signs of interest and engagement look like is essential to going from vague instinct to thoughtful first product.

Data can't make all our decisions for us because data isn't there to get us from 0->1. We have to use our powers of observation, of empathy with our customers, and of deduction, to create smart hypothesis in a qualitative way. Qualitative analysis will always have a role in product development, and customer empathy is likely to drive us more quickly to great products than simply relying on numbers alone.

Thanks to Etsy for hosting and my apologies to my fellow panelists if I misrepresented your views!

Hiring Engineering Managers: Screening for Potential

I have been in many discussions on the best way to interview and hire engineering managers. Here are my thoughts, having done this both successfully and less successfully, including some things that I have looked for in the past when being interviewed. 

First: Be thoughtful about what you are looking for. There are people out there who are looking for the opportunity to go into management. Lots of them, in my experience. These are good people to hire, because many of them will turn out to be good, thoughtful managers. Most of the time I hired this sort of person into a senior engineering role that quickly became a tech lead role. I was explicit at hiring that we didn't have a team to give them immediately but that I would be expecting that as the overall team grew they would move into such a role when it became available.

Now, I should be clear, this exchange requires a lot of trust on both parties, as well as the possibly unspoken assumption that they still have to prove themselves capable of doing the job once on the team. I have turned down jobs that asked me to make this bet, and I would not hold it against anyone who felt that it was too risky. But on the flip side, if you really want to grow your management from within, hiring people who both want to be eventually moving to leadership roles but are comfortable coming in as individual contributors first is pretty essential to making that work. If you want to grow management from within but don't bother to look for people who want to grow into management roles when you're hiring, you may end up with mostly people who just want to code, and that is not good for anyone.

OK, so you're hiring a specific management position. What do you look for?

There are two camps here. The first camp is that you look for incredibly smart tech lead-level developers who may have had limited management experience and put them in the role. They will easily pass whatever technical screens you put in front of them, but hiring is a risk because they may not really be good managers. If this is the way you want to go about hiring managers, you need to spend a good deal of time focused on screening for management potential. Screening for potential is different than screening for experience. Right now, I'm going to talk about screening for potential; in part 2, I'll talk about experience.

Questions to tease out potential: 

Tell me about a project where you have acted as the tech lead. What was your role like, as tech lead? What were things you did that were different from the rest of the team? How did you ensure that the project was successful?

What you are looking for: Someone who answers with more than just "I designed the architecture, chose the libraries, and wrote the most technically challenging pieces of the code." They should have taken an active role in the project management, even if there was another person explicitly or implicitly in that role. They should have contributed to predicting problems with the delivery and working with the people on the team or cross-team to ensure success.

When you bring a new team member onto your team, what kinds of things do you personally do as part of their onboarding? Have you ever been a mentor to a new hire or intern? What was that like, what did you learn from it?

What you are looking for: Someone who is actively engaged in the work of bringing on new people, and thoughtful about making that process better. Someone who respected the work of mentoring, who isn't just trying to shed human interactions quickly to get back to code.

Tell me about some things you have done to make the process of writing or delivering code in your organization better.

What you are looking for: Some strong examples of seeing process/people/systems problems and raising their hand to suggest improvements.

One suggestion I have heard, but not tried, is to do a role-playing exercise with the candidate. Set up a circumstance that might happen, such as, an employee is unhappy that they did not get promoted. Provide an overview to the candidate and give the interviewer some details that may include information that the manager doesn't necessarily know. Have a third party observe the interaction, and then at the end of the role play all three talk about what went well and didn't. This could be an interesting tool for hiring either the experienced manager or the potential-driven manager, but I also suspect it is easy on the flip side for it to go poorly if the interviewer isn't good at guiding the roleplay and knowing what to look for. (Credit to Marc Hedlund for this idea!)

Finally, when hiring this type of candidate, you are probably going to get (and maybe even should be intentionally seeking out) someone who is going to not only manage people but drive technical decision-making. Make sure that the people who currently drive technical direction (if they exist) are aligned on that front with the candidate. If the candidate is gung-ho about functional programming and microservices and you are happy in a more conservative technical space, you may end up with someone who wants to make big technical changes that you might not agree with. The team should feel a general alignment to their technical perspective, and ideally people are excited about working for this person because they feel that they will learn something, but don't just hire them as a manager because people are excited about their technical chops.

Overall, when screening for potential, look for signs of stepping up, caring about the people on the team, and thoughtfulness about the processes. In general you should also be looking for excellent communication skills, and everyone who interviews the person should feel pretty comfortable with the idea of working for them. Be wise to potential bias here. The best managers are often overlooked because they don't pattern match to certain characteristics, whether they are "tall and male" or "forceful personality" or whatever. Talk to the team before the interview and give them examples of great managers who sit outside of those stereotypes to reset their stereotype bias a little bit.

When you mishire on potential, it tends to come from overvaluing technical skills + pattern matching on "what a leader looks like", and the failure mode is managers who just don't deliver coherent teams and/or can't deliver projects effectively. Never ever hire a person you feel is overly ego-driven.

One final word on this candidate: If you hire someone for potential, be prepared to train them. They are going to need help. Whether it is formal training or a lot of mentorship from you or a mix of both, no one is born knowing how to manage. I think it is worth sometimes taking a risk on people like this (I'm glad someone did that for me once!) but they will struggle if they have to do it all alone.

What is a Technology Company, Really?

I have been thinking a lot about what I want in my next job, and part of that thinking has been asking the question of what, exactly, it means to have “technology” as a core cultural value of a company.

Let’s quickly put away the idea that a “technology” company is one that produces bits, and that any company that produces bits is a technology company. By some definitions of technology that is true, but equally by some definitions of technology pretty much every modern company is a technology company, and so it dilutes into meaninglessness. Certainly, I do not think the product being produced is the interesting element for me personally. It’s likely I will always be involved in producing software of some sort, but that doesn’t say much of anything about the values of the company I produce it in. So, the production of software is certainly insufficient for a company to hold “technology” as a core cultural value, and furthermore it is silly to think that a company must ONLY produce bits to hold “technology” as a core cultural value.

As part of this thinking I started to ask myself the question, What the hell does technology mean, anyway?, and I came across the fascinating Ursula Franklin. She wrote a book called The Real World of Technology, in which she differentiates technology practices into two types: holistic and prescriptive. The holistic practice has control of the production in the hands of one person or group involved from start to finish, from determining the product, sourcing of materials, to crafting of parts, to finishing. The prescriptive process, on the other hand, is more of the assembly-line model. The steps to create the final product are broken into discrete, standardized steps that can be accomplished by different people in stages.

What does this have to do with “technology” as a company value? Well, perhaps the company value we are interested in is not in fact technology, but it is the valuing of holistic technology. As industries and practices mature, they tend to become prescriptive, whether or not it produces the “best” outcomes. Prescriptive application of technology (“technology” here being the techniques for achieving some outcome) allows for control over the process, predictability of the outcomes, and surveillance. Decisions can be made by the manager, passed down to the workers, and enforced.

However, the process of writing code is rarely completely prescriptive. Because of the difficulty in predicting what will need to change and the compounding impacts of choices made in the past, as well as the necessity for constant support and evolution that most business expect from their software these days, strong engineering teams tend to run somewhat more holistically. You may be given a discrete task (or “ticket”), but there can be a great deal of freedom in how it is implemented, depending on the size and scope, and there will almost always be need for work that cannot be easily scoped into a simple discrete task. Software has so far rebuffed efforts to fully turn it into a prescriptive style of work over long periods of time. If you are a working engineer you may think I’m joking, but while senior engineering leaders may be expected to talk a big game about “velocity” of the teams and all the measures they use to determine engineering efficiency, in reality, vanishingly few feel comfortable in the tools out there available to monitor such a vague concept, and most of us instead go by gut instinct and secondary measures like release volume and defect frequency.

So, let’s go a step further and talk about startups. In a young startup, most work is holistic. Whether you are in engineering, marketing, even some parts of finance, there are so few people that you are often given full control over your process. You are allowed to do things differently, no one is watching, there is no prescriber to tell you that you must send that marketing email on Wednesday instead of Tuesday. So early startups behave in a holistic-driven way, whether or not they hold that as a core value, because they must. However, as the startup grows, it will start to experience some need for prescriptive processes, and here then becomes the question: Can a startup that does not value fundamentally holistic technology be a “tech” startup, in the modern sense?

Most startups claim to be “tech companies”, but what do they value?

If you value “technology”, you might be saying that you value the ability to see a problem and make the changes necessary to address that problem, at a speed that would not be possible if you were having to change the behavior of humans instead of the behavior of bits. For this to happen, though, the person or group who sees the problem needs to be able to go in and do the fix. They need to be able to access the information that lets them see the problem holistically to identify that solution. This becomes relatively difficult in a prescriptive implementation, because each individual may only understand their part of the task, and only perhaps the manager or overseer understands the whole. In complex software, it is likely that no individual understands the whole, but that the group must get together and act holistically to address and solve problems. Furthermore, because of the difficulty for any one individual to see all problems, members of the group must be empowered to raise problems to the overall group, communication as peers across hierarchy and function needs to be supported and encouraged. Thus the tech company common value of “transparency.”

Or, perhaps you are saying that you value the ability for a small number of people to do work that impacts a huge number of people due to the relatively low physical footprint of software and the ease of scaling it relative to physical goods and services. The flip side is that a few people can also negatively impact huge numbers of people by making a mistake, releasing a bad feature, taking down a system. In the case of unknown and ever-changing complexity (due to ever-changing and evolving systems), you can only mitigate this by placing a high value on learning from those mistakes, and evolving your tools and practices. Because almost any member of the team has the potential to cause these problems, all members must be part of the learning process. Thus the tech company common value of “learning.”

You may just be saying that you value a type of thinking that is a combination of creative about seeing possibilities, scientific enough to quantify those possibilities, and forward-thinking enough to actually enable the ideas to thrive beyond conception. A type of thinking, furthermore, that is comfortable with change, and pushes for change as needed. This sort of thinking doesn’t generally happen in a windowless room, where people have no creative freedom and must execute the tasks handed down to them in the way they were handed down. Some companies value this but only in certain classes of people, “research” or “creative”, for example. I think that a company that places value on holistic technology will encourage this in all types of employees, and this value may be expressed as the tech company values of “data-driven”, having a “focus on impact”, and “embracing and driving change.”

And then there’s the “tech company” that isn’t

Some companies claim to be tech companies because they view technology as the company’s competitive advantage. This is the easiest, but slipperiest definition. To value it as a competitive advantage, intellectual property that forms a moat around your business, without valuing the common shared cultural values of engineers themselves, is insincere and hollow. This is the value of someone who would happily turn their engineering team into robots who produce exactly what they are asked to produce, when asked. The “value” is entirely in the difficulty of accessing the skills to turn these ideas into reality, and therefore it is only as high as the cost of acquiring those skills. This, to me, is not therefore a “technology” company. It is a company that needs technology, but does not fundamentally value it.

What does this all mean?

These are just some idle thoughts I’ve had while considering my next move. I know that I want to work somewhere that values itself not as a tech company for the intellectual property, but as a tech company for the values that I believe great engineering teams embrace. As you look around at your companies and your own values, I hope this will help you consider what it might mean for your career and future as well.

Cross-posted from Medium

Reorgs Happen

Yesterday I gave a talk at the NYC CTO Summit on Reorgs (slides). Here's a rough summary of the content, prior to the video release.

The general theme of this summit was "Driving Change." When I came across that theme, I immediately decided to talk about the process of reorganizations. In particular, the process of being a leader of a team involved in a large top-down reorganization. I have been in the leadership team through three of those over the past four years or so, and I have had many conversations with friends at other companies over the years who were in the middle of them, either leading them or as a person swept up in them.

My first point about reorgs is that fundamentally, in companies big and small, they happen. They are disruptive and stressful, but I personally think they are often a necessary evil, the "full GC" of organizational structure change. You can get a lot of value having smaller parts of the organization morph and change as needed, but sometimes a higher-level view of the business drives the need for larger and more top-down change.

I happened to see a tweet that led me indirectly to this blog post, and in particular, the following structure:

This is a great structure for talking about a reorganization, and in particular, your role as a leader in a reorganization.

Vision: The Vision is the "why" of what is happening. You may not be the initiator of the "why", it might be your CEO or someone else in the leadership team, but you must understand it and focus it. Usually the reasons leading to a reorg are one or more of:

• Inefficient communication and collaboration between teams
• Adding or removing major products or focus areas
• Change in the size or makeup of the team

These are all well and good as a root cause, but you need to provide a lot more nuance to make this something that people buy into and want to follow. Especially when a reorg is in response to strategic change of focus. You're the leader of tech, so first make sure you understand and are on-board with the why, and then think about the way to communicate it to the rest of the engineering team in a way that makes sense. Without a clear vision, people will be confused as to why this is happening, even if what they are supposed to do when and how makes sense.

Skills: Do you have the skills to actually make the change happen? You may think that a reorg shouldn't require a lot of skills you don't already possess as a manager, but I disagree. There are many details to be ironed out in a reorg, many steps to follow, especially in a large team.

The first reorg I helped with moved our tech team from functional teams (frontend/storefront, backend) to what we called "pods", cross-functional teams with tech and product and high-level business goals. It was driven by both inefficient communication and a growing team. This was probably the easiest reorg that I led because the team was pretty small, and the lesson here is important: things that are practically free for a 20-25 person team are much more complicated when you're dealing with 60 people, let alone hundreds. The reasons were clear, we didn't need a ton of planning or incentives for people to do it, we just needed to clearly communicate what was happening why and move it through.

The most important skill for you as the leader of a large team through a reorg is communication. (In general, this is the most important skill that leaders need for pretty much everything). When reorgs go bad, one of the ways they go bad is that the reason for the change is not communicated well to the whole team, and the timing of communication is not coordinated, so some people know what's happening, others don't, and thus starts the rumor mill and the anxiety skyrockets. You are the leader. Write down exactly what the purpose is, the nuance behind it. If you need to write versions for your managers and versions for the whole team, do so. Think about your communication, and plan it as best you can.

Incentives: Why should people play along? What are they going to get out of it? You need to advocate for your team, and make sure they are going to be eager to embrace this. This is not selfish but rather sensible. If your team doesn't buy in, the reorg won't go as well, and the company will suffer for it.

Resources: Do you have available now what you need to make this happen? In the case of a reorg, that usually means time and focus. If your whole team is pushing out a major release of your mobile app, or focused on some other new launch, are you really going to distract them right now with the turmoil of a structure change? I hope not. Yes, a reorg may very well mean things need to slow down for a period of time while you figure it out and get the new teams formed, and gelled.

Of course, the other element of resources is in the new organizational structure you create. This brings us to the story of my second reorg. We had good success with the "pod" structure, but we saw that the focus for the pods was too high-level and we wanted to really get a focus on certain business strategies. We also wanted to expand the teams beyond tech/product to include other areas of the business who would be involved in the business strategies such as marketing, customer service, finance, operations. So we created what we called "strategic pillars". These were somewhat like business units, with a general manager who was responsible for the strategy of the cross-functional team (although not the people management), and members from technology, product, and the business.

Both incentives and resources were a big part of this reorg. On the initial list of candidates for general manager we did not have anyone from engineering, and I pushed to make sure that we did end up with a general manager chosen from the tech team. This was to ensure that engineering continued to be seen as an important strategic partner in the overall company, instead of an execution arm for product and business leaders. We also created a specific tech lead role for each pillar, who served as part of the pillar leadership.

As for the issue of resources, one of the mistakes I believe of the initial pillar list was creating one more pillar than we had adequate staff to support. Instead of spreading the team too thin, we simply did not staff that pillar with tech, saying that it would start out with more business analysis and research and as we came up with concrete plans we would hire into it. We ended up never getting the staffing the pillar needed to be successful, and eliminating it, which in turn was a big disappointment for the people who had been on that pillar. If you put people into leadership opportunities and then take them away, even if it is a good business decision and not an indictment of the person, they will still see it as a loss and you are very likely to lose them over it.

It's a cliché that every "Yes" you say implies a "no" to something else, but saying "no" to stretching your team too thin in a reorg is an essential part of making it successful.

Finally, the action plan. Without a clear action plan, you end up trying to start, realizing you're not ready, stopping, and starting again, sometimes many times over. You may not be the right person to make the entire action plan yourself, I know that is not my personal skill set. But you will still be involved in the planning process. If your reorg is intended to help focus people on new business strategies and goals, take your analytical mind and scrutinize those goals. Do they make sense? Are teams going to be able to work on their goals without negatively impacting other teams? If you have multiple teams with conflicting goals, you will quite possibly end up with turf wars.

This was one of the major elements of the final reorg I worked through. We had a nuanced set of goals that we wanted the teams to accomplish, and it took us several rounds of revisions to get to teams with goals that were productively aligned, independent enough to allow separate measurement without being in conflict. This process was necessary, but we suffered the downside of lacking a clear action plan, false starts, while we ironed it out. The team knew changes were coming, and they tried to tie up loose ends and finish up their work to be ready to move with the new organization. But we took longer to get the new organization together than anyone expected. With better planning earlier, we may have been able to avoid this period of uncertainty.

All of the reorgs I went through helped to move the company towards a more healthy, productive and focused structure, and I believe they were generally good for us. My final two pieces of advice for anyone managing a large team in a reorg are to remember that you don't have to do it alone, and that in the end you have to let go. Work closely with your peers to plan this, and expect that you will do some negotiating and have some outcomes that you like and some that you hate. Then, when it's out, let go. The teams will take a while to fully gel, the goals will probably shake out even more as they go through the actual process of planning on the teams. Some people will be happy with their new place, others will be unhappy and may even quit.

So, vision + skills + incentives + resources + action plan = success, right? Hopefully! However:

Reorgs are unlikely to solve all of your problems overnight. They are not a magic bullet exercise that fixes cultural issues or a lack of business strategy. If you aren't careful, your reorg will feel like rearranging deck chairs on the Titanic, a pointless waste of time for everyone involved. So don't be afraid to do them as necessary, but be realistic. This is a major disruption that impacts everyone, don't just do it for fun.

The Manager as Debugger

I have observed that the best engineering managers I know are often also great debuggers. Why would this be? What is it about these two tasks that has such an overlapping skill set?

A great debugger is relentless in their pursuit of the “why” for a bug. This is simple when we are looking for errors in application logic, but we all know that bugs can go many layers deep, particularly in complex systems that involve many separate parts operating over time-delayed networks. A sign of a poor debugger is a person who, when they add a log statement to a piece of concurrent code to attempt to find an error and see that the error can’t be reproduced, assumes that they have therefore fixed the problem. It’s a lazy habit but a common one. Sometimes there are problems that seem impossible to determine, and many people don’t have the patience to dig through layers of code, theirs and others’, log files, system settings, and whatever else is needed to get to the bottom of something that only happened once. I can’t blame them. Obsessive debugging of one-off issues is not always a great use of your time, but it does show a mind that cannot be satisfied with the unknown, especially when that unknown might cause them to be paged at two o’clock in the morning.

What does this have to do with management? Managing teams is a series of complex, black boxes interacting with other complex, black boxes. These black boxes have inputs and outputs that can be observed, but when the outputs aren’t as expected, figuring out why requires trying to open up the black box and see what is going on inside. And, just as sometimes you don’t have the source code, or the source code is in a language you don’t understand, or the log files aren’t readable, the black boxes of teams can resist yielding their inner workings. 

Teams also share the characteristic of another famous box, the one containing Schrödinger’s Cat. The point of that experiment is to show that the act of observing changes the outcome, or rather, causes an outcome to happen. You can’t go into a team and not change the behavior of that team by being around them, sitting in their meetings, watching their standups. Your presence changes the team behavior and may hide the problem you are trying to find, in the same way that a log statement can cause a concurrency issue to be magically erased, at least for some time.

To debug a system properly you have to be able to have a reasonable hypothesis that explains how the system got into the failed state, preferably one that you can reproduce, so that you can fix the bug (or at least prevent it from happening in the future). To debug a team, you also want to attempt to get a hypothesis for why the team was having problems. You want to do this in as minimally-invasive way as possible, to prevent your meddling from obscuring the problems. You have the added challenge of team problems not generally being single failures but more like performance issues, the system is running but it seems to slow down from time to time, the machines are ok except occasionally they crash, people seem happy but attrition is too high. 

Let’s work through an example. We have a team that feels slow. You have heard complaints from their business partners and product manager that they are slow, and you agree that the team just seems to lack the same energy as your other teams. How do we figure this out?

Debugging this deserves the same rigor you would apply to debugging a serious systems issue. When I debug a systems issue, the first thing I look at is generally log files and any other record of system state from the time of the incident. When talking about a team that is not producing work fast enough, look at the records. Look at the team chats and emails, look at the tickets, look at the repository code reviews and checkins. What do you see? Are there production incidents happening that are taking too much time? Are a bunch of people sick? Are they bickering over coding style constantly in their code review comments? Are the tickets that are being written vague, too big, too small? Does the team seem upbeat in their communication style, sharing fun things as well as important work in chat, or are they purely business? Look at their calendars. Is the team spending many hours a week in meetings? Is their manager doing 1-1s? None of these things is necessarily a smoking gun, but they may point to an area to address.

Perhaps everything seems ok in all of these indicators, but the team still just is not performing as well as you believe they should. You know the talent is there, the team is happy, they’re not overburdened by production support. What is happening? Now is the time to start doing some potentially destructive investigations. Sit in their meetings. Are they boring to you? Is the team bored? Who is speaking most of the time? Are there regular meetings with the whole team where the vast majority of the time is spent listening to the manager or product lead talk? Boring meetings are a sign. They may be a sign of inefficient planning on the part of the organizers. There may be too many meetings happening for the information covered. They may be a sign that the team members don’t feel that they can actually help set the direction of the team, choose the work that will happen. Boring meetings are a sure sign of time wasted, if not bigger leadership problems.

Ask the team what their goals are, can they tell you? Do they understand why those are the goals? If they don’t understand the goals of their work, their leaders (manager, tech lead, product manager) are not doing a good job engaging the team in the purpose of the work. In almost every model of motivation, people need to feel an understanding and connection with the purpose of their work. Who are they building these systems for, what is the potential impact on the customer, the business, the team? Did they have any part in deciding these goals, and the projects that they’re doing to achieve them? If not, why not? When you see a team spending all of their time on engineering-sponsored projects and neglecting product/business projects, it’s likely that the team does not appreciate or understand the value of the product/business projects that they are supposed to be working on, and therefore they are lacking in motivation to tackle them.

Finally, you might take a look at the actual team dynamics. Do people like each other? Are they friendly? Do they collaborate on projects or is every person working on something independently? Is there banter in the chat room, in emails? Do they have a good working relationship with other adjacent departments, and with their product managers? These are little things but even very professional groups tend to have a degree of personal connection between the members. A bunch of people who never talk to each other and are always working on independent projects are not really working as a team. There would be nothing wrong with that, if the team were performing well, but given that they are not, this may be contributing to your problem.

Sometimes managers of managers choose to take such problems as something that the manager of the team just needs to fix. You measure the manager on the output of their team, after all, and it is their responsibility to fix it if things are not going well. This is true, but just as I sometimes jump in and help debug complex system outages even though I rarely write code, it is ok to jump in and help debug team issues as you see them, particularly when the manager in question is struggling. It can be an opportunity to teach the manager and help them grow. It can also reveal more foundational problems with the organization, such as a lack of senior business leadership that even the best managers can’t identify or resolve alone. 

The pursuit of why when it comes to organizational problems is the thing that gives you patterns to match on, and lessons to lead with. We get better at debugging by doing it often, and learn which areas tend to break first and which indicators provide the most value for understanding issues. We become better leaders by pushing ourselves and our management teams to really get to the bottom of organizational issues, searching for why so that we can more quickly resolve such issues in the future. Without the drive to understand why, we rely on charm and luck to see us through our management career, we hire and fire based on charm and luck, and we have a huge blindspot when it comes to truly learning from our mistakes.

Truth and Consequences of the Technical Track

About a year ago, Dan McKinley aka McFunley wrote a bit on the technical track. The piece has stuck in the back of my mind for quite a while, and continues to influence certain points I make when discussing career progressions of engineers. Let's get them out.

I think that Dan's take is cynical, but not entirely incorrect. We need managers. As companies grow, at some point, you need people whose job it is to organize other people. I think the idealistic goal of management is to help teams live up to their talent potential. The realistic experience of management is often an abstraction layer between upstream and downstream, to help flow information, each layer helping to make a finer-grained set of decisions and adjustments to keep the overall company moving in the right direction.

Let's talk first about why I personally went into management. I was successfully performing in one of those technical track positions, at a company where I felt pretty confident I would be able to continue to be promoted in the technical track positions up to the highest level if I put the work in and continued to perform well. I was working on interesting things, paid very well, and on paper, everything was perfect. And yet, I quit to move to a smaller company and go into a management position. Why?

I realized pretty clearly that the scope of my ambitions was greater than the scope of my ability to produce things independently. I could not write enough code alone to achieve the kind of impact that I wanted to achieve on the company I was working for. Even with a small team, I felt that my ability to make a difference would be limited. I would have to make extremely good choices as to what to guide the team to do, and my effectiveness would always be limited by what I now realize is actually "product market fit." If I made a great product that no one else in engineering wanted to use (I was working in infrastructure engineering at the time), I would not have much of an impact.

So, instead, I gave up some degree of hands-on technical time in order to have a broader ability to focus people on projects where I felt their impact would make the most difference on the company. Ultimately, that is a core part of any technical leadership job, not doing all of the work yourself, but helping to both see what needs to be done and focus people on getting it done in the right way.

Now, you can imagine a situation where you have an engineering manager who deals with all the "people" side of things, paired with a technical specialist who makes all the decisions about what needs to be done and how it should be done, as per their technical expertise. Why doesn't this situation exist? Well, imagine putting yourself into the shoes of the engineering manager. You are basically a glorified project manager with little decision-making power. Except... all of the people report to you. You have hiring and firing power. You write their reviews. Do you really have no decision-making power? If you disagree with the technical specialist about what needs to be done, why would the technical specialist have final say? It is unrealistic to believe that the person with management authority over the people would have no influence over what they do, even with best intentions assumed.

The technical specialist, with no management authority, is limited. They are limited in what they can produce by the scope of resources (people, time, support from other departments, computers, etc) they have available to them. A people manager may give them a team to focus on their ideas, but that will always be balanced by their ability to produce valuable output as defined by whatever that people manager is being measured on. Miss an alignment with whatever the manager (or THEIR manager more likely) sees as valuable, and you risk losing those resources or having them siphoned off for "more important/pressing" work.

If a company has mostly reluctant/unhappy managers who would truly rather be coding, they have created a culture where code is more valued than management. Think about that. I created a team where the managers, by and large, were happy to be managing, and in the few times when they were not happy to be doing it, they went back to technical focus and we adjusted the teams. I was accused at least once of undervaluing technical contribution, so you should feel free to take this with a grain of salt, but reluctant management is a sign of a broken system, not a necessary an expected outcome of a growing engineering organization.

Dan mentions in his piece that one solution is that we could be promoting people more aggressively on the technical track. I agree with this, if the problem we are solving is giving productive individual contributors more money/bigger titles. Here is the alternate cynical perspective: the technical track exists so that we won't lose people who do good work and have valuable institutional knowledge, but the impact that those people have is often not equivalent to the impact that managers have (for good and for evil). Most companies don't actually need nearly as many people at senior levels of the technical track. We don't want to lose all of them, but there are diminishing returns for people who are possibly just incrementally better at building software. That's why you start to see language about scope of impact in staff engineering job ladders. As leaders, we want to encourage people to actually show results at broader scopes before we promote them. This just takes longer if you have to do it alone or with a small team. At a functional company, people aren't usually promoted as managers until they have shown they can do the next job by managing larger teams and actually doing the work to show the results. Why should the technical track be any different?

What about superpowers that could be given to technical specialists to make up for the authority given to managers? I would personally observe that often, senior technical staff work less hard than senior managers. The superpower of a senior technical staffer is that they get to work on harder intellectual problems and/or more speculative work, they get the luxury of a calendar that is far freer of obligatory meetings and tasks, and they are pressured far less than management for results on tight timelines. In short, by taking the technical path, they have traded off getting to continue to focus on what many engineers consider to be the fun stuff in exchange for a lot less clarity on how to progress and make an outsized meaningful difference. They don't have to work as hard as managers, they often don't work as hard, but on the flip side when they want to work harder to accomplish more it's less clear where to put that effort to gain value.

We all make tradeoffs. Engineering managers are making the tradeoff of getting farther away from the immediate reward (and, I will note, general tech cultural cachet) of day-to-day coding, as well as giving up control of their time, for a clearer career path and possibly more authority. Those who choose to stay technical should expect a likely slower career progression, and they will have to put in the difficult work to learn how to influence without management authority, but they should have more freedom from other people's demands and more control over when they put in the hard work to grow. Make no mistake, growth is hard no matter which way you go. You may have a clearer workout plan as a manager, but you still have to hit the gym and get sore. If you're not a little uncomfortable, what makes you think you're really growing into a new role?

Open Source Culture

One of the biggest achievements of my career to date, one of the biggest impacts that I have made so far, happened almost as an after-thought. On March 26th of 2015, I released publicly the engineering ladder that the team created for Rent the Runway. I want to reflect on that for a moment because I keep hearing more and more people refer to this ladder.

Why has the Rent the Runway ladder been so viral? I've been told that companies from Kickstarter to Slack to Lyft and beyond have used it to inspire discussion and serve as a starting point. Why now?

We are in a point of rapid evolution in startup culture. A few years ago, everyone was obsessed with flat organizations, zero-process anarchy. And then we all started to live through the consequences of that, and many of us realized that it wasn't the utopia we were promised. Suddenly we saw that having no title didn't actually mean that every voice in the organization was heard equally, it often just meant that the loudest voices were the only voices heard at all. People began to push back on this.

We have become aware of unconscious biases and the challenges presented there. There's a huge temptation to have a very lightweight, low-detail engineering ladder. Unfortunately, that gives people only a vague idea of how to move forward. As we become more aware of the impact of bias on human decision-making, we attempt to provide more clarity to combat this bias. I realize that no amount of ink spilled can ensure a perfectly quantifiable process that takes all human bias out of it, but I also think there's little harm in trying for more clarity. And it turns out that many people appreciate it, and not just the people most affected by unconscious bias.

The devil is in the details. But putting in those details is hard, so providing a thoughtful starting point is better than providing a basic outline. Just as you only use the features of open source software that you actually need, you only need to take the details from open source culture that you want. Companies can (and often have) taken out details from this ladder that they don't like, but it's much harder to take a basic outline and flesh out all of the details yourself.

People want to know what they are getting themselves into. A recruiter commented to me once that the public engineering ladder was a massively useful tool for recruiting. Candidates knew what the structure of the org looked like, what the potential paths forward from a career growth perspective were available to them, and what we were looking for at a given level. It gave them more clarity into the workings of the organization in a way that most companies at the time were not providing.

This has gone beyond hiring people. Leaders of other companies who have adopted the ladder tell me that the process of getting the ladder done and adopted internally has gone smoothly partly because they started with a known, widely-adopted ladder that their teams already felt comfortable with. People are getting used to the idea of an engineering ladder as a tool to help them progress in their career, not a tool to stifle them or create unnecessary hierarchy.

Engineers like to share and learn from each other. The veil of secrecy around HR-related issues has existed without questioning for a long time. Let's question it! When I proposed publishing the ladder, no one in HR batted an eye. We're all comfortable with sharing our source code, and we might blog or speak about the processes for running our teams, but few of us have ever shared the core documents for running our organizations. It is awesome to see Clef share their entire handbook on GitHub, and I hope to see more organizations share not only the processes that they use to run their companies, but the actual documents they rely on for core policies, procedures, and standards.

Open source culture requires you to openly care about culture. You can't open source what you haven't created or modified. I'm excited to see people truly caring about the craft of creating healthy organizational cultures, processes, and documents, and sharing them with the world. I'm excited that people are proud to show that they care about making the culture of the technical workplace better in tangible ways. This is the best of techno-optimism. We can share ideas, and make things better for the whole tech community and the workplace as a whole. I'm proud to be an early adopter of open source culture, and I hope many others will continue to join in the movement.

Autonomy, Mastery, Purpose... What's Missing?

I've been thinking a lot about motivation lately. Anyone who has ever managed teams has probably spent some time being alternately perplexed and frustrated with the difficulty of motivating people, especially engineers. We go through contortions to engage, inspire, and most importantly, hire and retain our valuable engineering teams, and yet we still often fail to provide workplaces where people feel truly motivated.

When Daniel Pink's Drive came out, it was the talk of the tech community. Finally a concept that makes sense, especially to engineers! It is still heavily quoted in engineering management conversations, and the TED talk refers to two tech companies (Atlassian and Google) as part of his examples of doing this right. A quick refresher:

Autonomy: Our desire to direct our own lives, to feel that we have choices, and what we are doing is of our own volition.

Mastery: Our urge to get better, to master our craft.

Purpose: The feeling and intention that we can make a difference in the world.

These concepts are said to be intrinsic motivators, meaning they are something that the person does because they want to do it, without expecting a reward from an external party. They stand in contrast to external motivators like money, status, power, or praise, which tend to be more of a baseline that is insufficient to motivate consistently. Note that without some degree of pay, praise, or reward for their work most people will also lack motivation because they need to have their basic needs met. You can also refer to a baseline of pay, safe working conditions, etc as hygiene.

So, back to our big three intrinsic motivators. Engineers resonate with these. Even junior engineers want to have some control in what code they are writing; everyone is constantly driven to learn the next new thing and get better at the craft of software engineering; and any manager will tell you that good employees want to know WHY they are doing the tasks they are doing and who/what is benefitting by their work on these tasks.

I like these motivators, but they have always seemed lacking to me. The natural extreme translation of them in my mind is the job of self-directed researcher. You're choosing what to do, learning new things, and making the world better by exploring the unknown! Except that I tried to do that job, or at least went to grad school where we simulated it, and I absolutely hated it. I had no idea where to go, no idea what to do, and felt like my work had no point and moreover I had no one to help me.

So, I've been very happy to read more lately on the wider topic of motivation, specifically The Three Signs of a Miserable Job and Why Motivating People Doesn't Work, both of which talk about the elements that keep people engaged at work. Including Drive, these three books define, not three, but four distinct motivators:

Measurement/Competence/Mastery: Having a goal, reaching it, getting better, being objectively "good" at what you do

Autonomy: The ability to choose your measures, have some say in what you focus on

Purpose: Knowing who you are making a difference for, whether it is your customers, or your coworkers, or the world at large

Relatedness: Being known at work, feeling a relationship to your coworkers

Relatedness is the fourth element that is absent from Drive. It does not surprise me that engineers would cling to the first three motivators without thinking of the fourth. Relatedness is very touchy-feely. It's hard to quantify. It requires interpersonal engagement. And for many of us, it's probably a distant fourth motivator behind the other three.

And yet. As a leader, you will lead people who want Relatedness in their job. They want you to know about their family, their hobbies. They want to chat with you about their weekend, their trips away. They want to get lunch sometimes.

The nice thing about Relatedness is that it is the easiest thing to provide. You don't have to have management buy-in to ask people about their weekends. You don't have to go through contortions to find business cases for sharing an occasional meal or coffee. And you may find that once you start caring about people, you feel a bit happier yourself at work.

So my advice to new leaders and managers is to be mindful of the fourth element, and don't forget about it. Treat your peers as interesting fellow humans, and you may be surprised what it does for their motivation, dedication, and engagement.

Notes on Startup Engineering Management for Young Bloods

(With apologies to my good friend Jeff Hodges this is a takeoff on Distributed Systems for Young Bloods).

I’ve been thinking about the lessons startup engineering managers learn on the job. A great deal of our instruction is by making mistakes, and as leaders, those mistakes often cost us real opportunities: people who don't join the company, people who quit, projects that don't ship, sometimes even our jobs. These scars are useful reminders, sure, but it’d be better to have more managers with the full count of their fingers.

Below is a list of some lessons I’ve learned as an startup engineering manager that are worth being told to a new manager. Some are subtle, and some are surprising, and this being human beings, some are inevitably controversial. This list is for the new head of engineering to guide their thinking about the job they are taking on. It’s not comprehensive, but it’s a good beginning.

The best characteristic of this list is that it focuses on social problems with little discussion of technical problems a manager may run into. The social stuff is usually the hardest part of any software developer’s job, and of course this goes triply for engineering managers.

I'm a distributed systems engineer by training, and I enjoy drawing lessons and making comparisons between the two worlds. I wrote this post with many indirect references to Jeff's original screed because I found it mapped quite well. It's long, and each entry is itself worthy of one or several posts, but I hope you will find it a valuable introduction.

OK, having copied Jeff's intro and lightly reworded it, let's dive in.

Managing people at startups is different because you have no safety net. You may think, having spent a few years at a big company in a management position, that you know how to manage already. You've given performance reviews, done interviews, dealt with project timelines, played politics. You know the basics. Right?

Here's what you don't see until you leave the safety of a big company. You don't see the millions of invisible systems all around you that have set you up for success. The army of recruiting personnel, the pipeline of aggregated talent, the power of a known brand. You don't have to figure out salary bands. You have standards, you have processes, you have rules, and you have people who make it relatively easy for you to live by those standards, processes, and rules. You have no idea what it is like not to have someone to check your work, to make sure that people get paid on time, that reviews happen, that holidays are tracked, that budgets get approved. You've never looked at an excel spreadsheet of numbers for year-end compensation only to find it full of errors that needed correcting.

Or maybe you've never been a manager at a big company. Your whole career has been spent in startups, and you have not only no management experience at all, but you've never experienced the safety net. You too are in for problems, but they will be much harder for you to detect, because you don't know what a smooth-running operation even looks like. You are comfortable making your own rules, but you may not appreciate the value of having a machine behind you. Instead of chafing at the chaos, you not only thrive in it, but create more of it. 

In both cases, creating the safety net yourself is part of the job, whether you realize it or not. Create sane processes, sane standards, and shared values, so that the team can scale without you having to make every decision yourself. If you find your team has doubled and you're still making roughly the same decisions you were before it doubled and you're just working twice as hard to get it all done, you are trying to paper over the safety net via effort. It doesn't work.

Coordination is very hard. "I hate agile!" Yeah, I get it. But when you are expected to know the progress of 10 very different projects off the top of your head, and teams across the company from each other cannot seem to get on the same page and you find yourself in meeting upon meeting upon meeting trying to align roadmaps and get some clarity as to what the hell is going on, you may feel that at least getting some shared vocabulary and process across the company is a valuable exercise. Many tactics and theories exist for how to solve this problem, but we must acknowledge that it is fundamentally difficult, and it is unlikely that you are going to solve it perfectly on your first try.

The amount of overhead that goes into managing coordination of people cannot be overstated. It's so great that the industry invented microservices because we'd rather invest engineering headcount and dollars into software orchestration than force disparate engineering teams to work together. And even that is an illusion when it comes to true cross-functional efforts. It turns out, there is a reason big companies end up with project managers who spend all day making sure people are talking to one another.

If the set of projects going on can fit into your head, your project list is probably trivial. I do not say this to malign your company, but there is a huge separation between the management style that you can afford when you know everything that is happening in detail, and the management style when you have to do some deep reading to even know what is going on in an area.

If the set of people is small enough that everyone knows everyone else, politics is trivial. You'll have it, sure, but it will almost always be very visible very quickly. Now is the time to get out in front of it. Politics at this scale is probably a sign of either organizational illness or a lack of cultural unity. If you can easily put a label on the type of people most often bearing the brunt of the politics (engineers, marketers, women, new grads, etc), it's probably a sign of organizational illness that you need to address unless you want it to fester and cause bigger problems as you go. Unless you can literally grow your business without that group represented, you don't want to create a culture that completely excludes an entire group. If, on the other hand, the people who bring politics share personality characteristics that are not strongly correlated with their gender/race/job/experience-level/etc, then you need to figure out what kind of culture your company actually is, and start screening for that in hiring. The sooner you realize what values your company truly holds, the easier avoiding these types of problems will be. If you do not figure out your company's values, as you grow, politics will become worse and worse.

“The team is moving too slow” is the hardest problem you’ll ever debug. When your CEO asks you why nothing is getting done, why we can't do everything on their laundry list, why the project they expected would launch next quarter is still two quarters out, accurately answering that question is incredibly difficult. Once you are a level or two removed from the actual people doing the work, your previous debugging process of "going to every meeting, watching the work being committed, understanding every detail of the project" does not scale. You have to figure this out from a distance. 

Implement trust and communication throughout your team. Your management team MUST trust you, and their developers MUST trust them. The basis of trust is doing what you say what you will do. At the most basic level, this is done by scheduling regular 1-1s and then showing up for them. If you don't have time to do this, think about whether you can handle having so many direct reports. You have to lead by example. Whatever you do to your direct reports will probably flow down the chain. If you disrespect their time, they will disrespect the time of their direct reports. In addition to 1-1s, find ways to be available to your whole team. I am a fan of office hours held weekly that anyone can sign up for. Spend time in the channels where the team hangs out. Show up for drinks and demos. Participate in hackweek. Enjoy this rare opportunity to build a team yourself by spending time with the team you built!

Metrics are not the only way to get your job done, but they can be useful. How often do releases happen? How often do people check in code? How many tickets are outstanding? How much time do people spend in meetings? How many people do you really need to hire this month? Here's the challenge: you're dealing with small data sets (lies, damn lies, and overfitting the data). Even if you have a year of github activity data, understanding WHY a person is coding infrequently requires an understanding of what is going on in that person's life. They may have just become a manager!

This also applies to goal-setting. If you miss your KPIs, what does that mean? Fundamentally, are you measuring the most important things? 

Learn to estimate your capacity, and your team's capacity. You should know how much you can realistically do in a week. If you constantly find yourself not finishing something you said you would, you are overestimating your capacity. When you aren't finishing important things, it is a sign that you need to either delegate or simply STOP DOING SOMETHING. That something you need to stop doing is often writing code. 

Lots of engineering leaders think that the way to maintain empathy for their team and to understand where problems lie is by continuing to write code. Here's the deal: if you have the time to do the full process of writing code (write code + tests, get review, release to QA, validate, release to prod, fix loose ends, document/hand-off/maintain), by all means, write code. It may be valuable to do this for one or two small things a year (protip: hackweek can be good for this). But as your team grows it is completely unrealistic that you are going to understand the pain of every engineer by walking a mile in their shoes. You may be able to do this for a service, but not the javascript, or the javascript, but not the app, or the app, but not the tooling. You must figure out how to get information about the bottlenecks and problems in the development process without actually having to do it all yourself. That is the job. It is not easy, and it is usually less fun than writing code. 

Here's a useful trick for estimating team capacity:

If we got some number of features done this year with our current engineering staff, we will need ~20% more engineers next year to get the same number of features done.

Technical debt and production support implies long-term cost for every new feature. You have to account for that. This is why big tech companies seem to grow massively every year.

Prepare for long feedback loops, and look for opportunities to shorten them. The feedback loop from "hired someone" to "figured out their total impact on the organization" is the duration of a person's time at a company. You will write strategies that may take years to implement. When you are coaching someone to improve in an area, that coaching will often take weeks or months to actually result in behavioral change. You are no longer in a red-green-refactor cycle. Anything you can do to build out quicker feedback loops into the company and your personal style will generally pay dividends. Beyond the common wisdom of not waiting for review cycles to give people both praise and areas for improvement, some things you can and should do:

1. Get your teams in the habit of releasing code as frequently as is reasonably possible. That may not be "continuous", but it probably looks like more than once a week. If your team is unable to release code frequently (barring stupid shit like Apple store processes), it is a sign of potential bottlenecks.
2. Postmortem time? Try to make sure it is held the day after the incident, when it is fresh in people's minds.
3. Look for ways to prove out ideas early. This includes your architectural and strategic ideas. Work them organically into the product roadmap, to show value early.

Choose your structure (or lack thereof) wisely. You may not personally be creating technical debt much anymore, but that doesn't mean you aren't creating organizational debt. When you roll out a half-assed engineering ladder, this new structure may actually make your life harder, because now you're going to have to negotiate with engineers eager to debate the finer points of broad and vague language. Early on, structure doesn't matter much, but at some point you have to address it. Interested in going the Holacracy or other self-organizing route? I highly recommend reading Reinventing Organizations. Because guess what? They also require some thought and process to work! Be prepared to be thoughtful about this and put some time into it.

The worst situation is having random titles, random pay, random equity. I have stopped counting the number of people who have told me that they discovered massive unfairness in the salaries and equity paid to members of their team. It happens easily. You pay early employees less, assuming you'll give them more valuable equity, but that does not always happen. As the company gets bigger and the market rates change, you hire new people in at higher salaries, but never adjust older people. Cleaning this up probably requires setting up a structure for levels, pay ranges for those levels, and actually increasing the salaries of many people to bring them up to level. 

You'll probably get this a little bit wrong the first time, but in an effort to make your life slightly easier, if you decide you want to do an engineering ladder feel free to use the Rent the Runway Ladder that we shared as a starting point. 

People can do more than they think they can. This goes for you, and for your entire team. I can't tell you about the failure patterns of people who overwork their teams because that's not my personal failure pattern (yet). But I do sometimes fail to push people hard enough. Engineers want to ship. This goes double for startup engineers. If they are not shipping much, they will start to complain of boredom, and go looking for ways to make trouble. This may result in you having overengineered systems in prod, engineers who quit to go to a new shiny company, or worst, engineers who first push overengineered systems halfway to prod then quit to go to a new shiny company.

I know my boundaries and rarely respond well to people trying to push me to do things. I push myself hard enough. This is true for some engineers, but not all. When you are not pushing them to get something done, you may be trying to give them space, and they may consciously appreciate that while unconsciously start to think that their work doesn't matter that much. If it mattered, my boss would be pushing me!

So, if you have an engineer complaining of boredom, ask them to finish what they're doing faster. I once heard this on the topic of infrastructure engineering: "If you're bored, try doing it all 20% cheaper". Engineers will often identify interesting hard problems when they try to do things faster. Such as: it's hard for me to run tests because they're too slow, getting to prod takes a long time, the build is always broken, this downstream system is not responsive. You were saying you're bored?

People will quit. As sure as the sun rises, as sure as networks occasionally partition, people will quit. They will quit because you are a bad boss. The will quit despite you being their best boss ever. They will quit to move across the country. They will quit because they don't see the future with your company. They will quit because they got another offer they can't turn down. They will quit because it is time for them to move on.

You cannot control all the reasons that people quit, but it will feel like a punch in the gut every time it happens. Your job is to keep going. To put on a smile and go out and recruit. To rally the team. To celebrate that person even as you are seething inside, how dare they leave me right now! Try to identify common causes for people quitting your organization, and address them as best you can. Especially if those causes relate to the environment that you help create (harassing, aggressive, burnout, underpaying, favoritism, politics). If you can in good conscience look at your environment and believe that it is in pretty good shape, then be kind to yourself. 

One of my greatest accomplishments was this: I told my team over the years that if they were seriously looking to move on, to tell me and let me help them find a new job. This finally happened for the first time this year and it felt like a massive win. If you care about your team, helping them move on when they want to move on is a great honor.

Jeff didn't manage to find a concluding paragraph. It's hard to put a conclusion on what is ultimately a brain dump. But here is mine:

Your job is to survive. Put one foot in front of the next. Keep going. Be open-minded. Be curious. Read about what other people are doing. Make friends who are running tech at other companies. Be kind to yourself, even if you fail. You have the power to make the world better for all of those people on your team. Use it responsibly.

Have a Theory

There is a phrase I find myself employing pretty frequently at work, when discussing new features or products. While I am not a product manager, I am responsible for making sure that we implement features well, and thinking strategically about what we are spending our precious time implementing. So, when I am asked about my thoughts on a new product or feature, I usually have one and only one question:

"What is your theory?"

In this day and age we sometimes get lazy about thoughtfulness, and rely on data and experimentation to hill-climb our way through the world around us. Or at least we say that we rely on data and experimentation to drive our features. But the reality is that we're working in such complex multivariate environments that we cannot possibly test all permutations of even the simplest change. We do make choices about what features we build, and these choices are not entirely data-driven.

So, given that our choices cannot be entirely perfectly data-driven, how then do we decide what to build? The only way that we can make sane choices in a complex world is by actually being thoughtful about the choices we are making, creating a theory, and creating experiments that actually test that theory.

For example, in my current world of e-commerce, we often are faced with the mandate to implement a new feature that will make the customer feel better about the product in some nebulous way (it's cooler! it's more high fashion! millennials will love it! whatever). This feature, while it might not cause customers to immediately buy more up front, should cause them to be more loyal over time. Sometimes, this is the right instinct. But beware: if you're going to try to get second or third order effects from a feature, you'd better have a really solid theory of the chain of events that leads to those second or third order impacts. And you need to figure out what you can measure to validate the chain of events. Don't just look at the number of people buying the product and hope it goes up. What does making the look and feel "cooler" DO for your customer? Do they visit more often? Spend more time? Tell more friends? Have a theory!

Failing to have a theory, and a solid experimentation plan for proving that theory, leaves you open to all kinds of irrational outcomes. The worst of these is the "you just didn't implement it well enough" outcome. The original idea was good, but you implemented it poorly, and that's why it failed. And that could very well be true! But it's impossible to prove or disprove without anticipating the question ahead of time, thinking through the logical conclusions of the theory, and setting up a good test to understand its outcome.

So the next time you are building a feature, ask yourself: Do we have a theory? What is it? Are we measuring the immediate expected effects of the theory, or are we just measuring the same stuff we always measure and hoping that it changes?

Ask the CTO: Going Rogue

I often get asked one-off questions about engineering leadership and management, and thought it would be fun to share my answers here. Asker's question has been anonymized and generalized.

The challenge:
I have an employee that was supposed to be adding a needed feature to one of our core systems. A few days ago I notice in GitHub that he has created a new repo and been working solely in that repo for the past two weeks. Instead of adding a feature to the new system, he is completely rewriting it! Furthermore, the repo is in a new language that no one in the team uses and that we have never put into production. I feel bad, I should have noticed this before it got this far, but I never expected someone we consider to be a senior engineer to go off and do this without at least checking in. How should I address this?

My thoughts:

Oof. This has happened to most of us at least once, in some fashion. Engineers want to be able to use what they think is the right tool for the job, even when the right tool is brand-new to the company. And generally speaking, this should be OK! The last thing you want to do is stifle people's initiative to create solid solutions and learn new things.

That being said, there is a high overhead to adding new things to your stack, and at some point, it usually makes sense to have some policy around how to add new things. I whipped together such a policy for my team about a year ago, when we had reached around 40 on the team and there were some folks discussing creating a new service in a language that we had very limited experience with. Our policy looks something like this:

Before any new language/framework is chosen for a production system, the following needs to be in place and approved by Camille and an architecture review board (group of senior engineers who are knowledgable in the area of change and would be impacted by it)

1. the engineers advocating for the language/framework will present a case as to the benefits it will provide over existing choices
2. there is a plan for what sorts of systems this language/framework should be used to implement, and what existing systems could be rewritten in it
3. a style guide and templates for readability, testing, continuous integration, monitoring, logging, deployment and production standards will have been created
4. at least four engineers on the team must sign up on learning how to write readable, production quality code and support the new systems in production

This must be done before the start of any project for engineering to commit to supporting the resultant code.

 This is a bit of a heavyweight list, but it articulates some of the challenges with bringing new languages and frameworks into teams. If you are in a team that wants to be conservative with new languages, frameworks and tools, clearly articulating the process for adding new things is an important element to avoid unexpected surprises on both sides of the equation.

So, you can put such a policy in place and point to it in the future to try and prevent such things from happening, but it has happened now, and there is an argument to be made that part of being a senior engineer is knowing when to communicate scope changes such as the need to move to new languages or frameworks. Even if you don't agree with my conservative approach to adding new things, you probably appreciate it when you get a heads-up on important changes early in the process.

The conversation you have now should involve first understanding their perspective: Why the new language? Why didn't they grab you earlier to tell you about it? What you learn from their perspective might surprise you. Perhaps you skip all of their 1-1s and they think you are unapproachable. Perhaps they are frustrated with the way you make decisions. Perhaps they knew you would be mad and were simply afraid to show you new work early when you would shoot it down.

Once you have gotten their perspective (and perhaps some takeaways for you), now it is time to clarify your perspective and expectations of them. As a senior engineer, you need them to push information to you. You expect them to communicate the scope of changes and approximate timelines, and let you know when these things change. They need to think about their peers, and have empathy for the needs of the team as well as their own interests; all too often teams will reject projects they weren't aware of and didn't have any say in. Socializing change not only to your manager but to your team is part of the role of the senior engineer.

So, to sum it up:

If you care about having a somewhat conservative process for new languages/frameworks, clarify what that process is and share it with your team

When someone ignores the process or otherwise surprises you, first ask why and try to understand their perspective

Finally, clarify your expectations to them, helping them understand the impact that their actions have on others and the importance of communcation

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.

The Trials and Temptations of the New Leader: "Cool Factor"

Being a new leader at a startup is hard for many reasons. You think you're good at a lot of things, only to discover that you're not. You were fooled by success gained inside of a company with hidden structures that helped you succeed, the invisible backpack of big(ger) company privilege.

One very common area of weakness is recruiting. When I started to lead engineering at Rent the Runway I fancied myself pretty good at recruiting. After all I had done it well in prior gigs, I was friendly and engaging in interviews, so I'd be fine! Of course I quickly realized that startup recruiting is enormously different than at a company with a whole recruiting department sourcing candidates, making sure the process goes relatively smoothly, and of course, paying them fat industry++ salaries. Outside of this structure you experience a world where you reach out to so many people and get nothing but silence, blank stares, or polite dismissals. Your CEO tells you that you've gotta sell, and asks for your sales pitch. And often, faced with a string of failures and pressure to grow, you land on the need to do something "cool" with technology to up your "cool factor."

You know what I mean. Chase the buzzwords: microservices, Go, big data, event-driven, reactive, functional, etc etc etc. The only way engineers will want to come work for me on my relatively straight-forward application development is if I give them the carrot of Cool New Technology!

I have learned a few things over the years, and one of those things is that usually engineers that are only interested in Cool New Technology are not going to stick with your Boring Business Problem for long enough to be worthwhile, or worse, they'll stick with it long enough to leave a trail of one-off solutions that no one else on the team understands before they walk away and leave you holding the bag.

If you're tempted to reach for Cool Tech, then I'm going to guess that you're not at a company where the primary challenge is purely technical or scaling. Instead, the interesting problem that your company is solving is almost certainly a combination of a) figuring out how your business, possibly the first of its kind, is going to survive, and b) growing, changing, and evolving to create a functioning organization. Once your company is successful, many of the problems that seemed trivial become surprisingly challenging to solve at scale, but in the early days oversolving with cool tech only leads to distraction from tackling the real challenges.

So resist the urge to adopt any technology for the cool factor of recruiting. Instead, look for people who want to own big parts of the system, who are interested in the business, who are really passionate about the customers you're serving, who are looking for leadership opportunities. Don't undersell the opportunity you have just because it isn't Cool New Technology. Be honest with yourself about the real problems that make you excited about the business that you're in, and that's where you'll find your best sales pitch.

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.

On the role of CTO

I get asked frequently to define the role of CTO, and I thought I would share some of my thoughts.

First, let's start by talking about what a CTO is not.

1) CTO is not an engineering role. CTO is not the top of the technical ladder, it is not the natural progression for engineers over the course of their careers to strive to achieve. It's not a role most people who love coding, architecture, and deep technical design would enjoy doing.

2) From 1, it follows that the CTO is not necessarily the best engineer in the company.

Now, with that out of the way, what is a CTO, if not the best writer of code and natural conclusion of the engineering ladder?

The challenge with defining CTO is that if you look across the folks who hold that title you will see many different manifestations. Some are the technical cofounders. Others were the best of the early engineers. Some started at the company with the title, while others such as myself were promoted into it over time. Some became CTO after holding the title of VP of Engineering. Some focus on the people and processes of engineering, hiring/recruiting. Others focus on the technical architecture, or the product roadmap. Some are the face of the company to the outside technical world. Some CTOs have no direct reports, others manage the entire engineering organization.

In looking at these examples the best definition that we can make is that the CTO is the technical leader the company has in its current stage of evolution. To me, that is rather unsatisfying, and missing the hardest part of the job. I believe instead that the CTO should be the strategic technical executive the company needs in its current stage of evolution.

Strategic: Thinking about the longer-term, and helping to plan the future of the business and the elements that make that possible

Executive: Taking that strategic thinking and helping to make it real and operational by breaking down the problem and directing people to execute against it

So, what does a CTO actually DO?

First and foremost, a CTO must care about and understand the business, and have the ability to shape business strategy through the lens of technology. The CTO is an executive first, a technologist second. If the CTO does not have a seat at the executive table and does not understand the business challenges the company is facing, there is no way the CTO can guide the technology to solve those problems. The CTO may identify areas where technology can be used to create new or bigger lines of business for the company that align with the overall company strategies. Or the CTO may simply ensure that the technology is always evolving to anticipate and enable the potential futures of the business and product roadmap.

No matter what, the CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them. When you see a CTO focused on recruiting, retention, process and people management, that is because it is the most important thing for the technology team to focus on at the time.

Strong CTOs also have significant management responsibility and influence. This does not always mean that they are deeply involved in the day to day management, but part of maintaining your ability to shape the direction of the business and the business strategy is the ability to put people behind solving the problems you believe will impact the business. Other executives will have ideas and needs for technology. The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.

Things get tricky when the team grows to be very large, and the CTO starts to hire VPs to manage all the people. Many CTOs give up all of their management responsibilities to their VPs, sometimes going so far as to not even have the VPs reporting to them. It is incredibly difficult to maintain influence and effectiveness as an executive with no reporting power.

I saw this clearly at my previous employer, where the most senior members of the technical staff in large business areas would often hold the title of CTO for that area. These people were always highly respected and technically capable. They understood the business and the technical challenges for the business, and were often called upon to help inspire the engineering team and help with recruiting.

Their downfall was that they often lacked the direct management oversight of any teams, and because technology was frequently viewed as an execution arm, they did not have much strategic influence.

If you are a leader with no power over business strategy and no ability to allocate people to important tasks, you are at best at the mercy of your influence with other executives and managers, and at worst a figurehead. You cannot give up the responsibility of management without giving up the power that comes with it.

The CTO who does not also have the authority of management must be able to get things done purely by influencing the organization. If the managers won't actually give people and time to work on the areas that the CTO believes are important, the CTO is rendered effectively powerless.  If you give up management, you're giving up the most important power you ever had over the business strategy, and you effectively have nothing but your organizational goodwill and your own two hands. Hope you're really a 10X engineer!

My advice for aspiring CTOs is to remember that it's a business strategy job, first and foremost. It's also a management job. If you don't care about the business your company is running, if you're not willing to take ultimate responsibility for having a large team of people effectively attacking that business, then CTO is not the job for you.

Special thanks to my editors Amanda Peyton, Cate Huston and EIC ChrisK.

A Letter to My Team for Review Season

I wrote this email to my team and sent it yesterday. It covers some of my thinking about reviews, a perennially controversial topic everywhere. Even though I believe that it is not a perfect exercise, I think that the benefits can outweigh the downsides, and I cover some of my thinking here.

Team,

As you all know performance review season is beginning. I thought I would take this time to talk to you about the goals of the review process, why I personally believe in it despite its many downsides and inconveniences, and what I hope that you can all get out of it.

Why performance reviews?

The first purpose is to give everyone a time to reflect on the past year, the accomplishments and growth that we have each individually achieved, and to celebrate that. Yes, celebrate it. Take the time to think about not just what didn't go so well, but what went really well. Part of the training your managers receive is to dwell on the positive parts of the review. Many of us want to skip over that and get to the "areas for improvement", but there is as much value in knowing what you are good at and what others appreciate in you as there is in knowing what to change. We celebrate accomplishments throughout the year, but it's also important to take the time to sum them up. Learning happens when we study our successes as well as our failures.

Speaking of successes, spend time yourself accounting for them. Self-promotion feels bad to some people, but it is important to learn the skill enough to write about your accomplishments. Even if your current manager is excellent at tracking the things you have done and the skills you bring to the table, you will have many managers throughout your career and they will not always have this ability. We can work to change the world so that self-promotion isn't so important, but it is good for you to be armed with the basics for your future career. If you need help with this, talk to your manager, or feel free to stop by my office hours.

You will also get a chance to write and see a summation of areas for improvement. Hopefully you will take the act of writing this for your peers and manager seriously. This isn't the time to be petty but it is the time to be thoughtful and honest. Feedback for areas to improve is something that you hopefully hear as needed (and not just once a year), but we don't often have the time to take in the entirety of observed habits and behaviors throughout the year and comment on trends. I have gotten some of the most valuable feedback of my career throughout this process; if you're curious ask me about the time I got review feedback that told me I was creating a "culture of fear."

One of the most important goals of this exercise is for us to think about our company values and to reinforce those values throughout the team. You've all seen the list of company values over and over again. We celebrate them in team meetings and we talk about them in reviews because the values are what bind everyone in the company together. We can all exhibit them through the lens of our individual roles and skills. You were hired partially because we believe that you share many of these values and thinking about the great things you've done as expressions of these values helps us all remember what we stand for as a company.

Finally, there is the goal setting section. Goal setting is hard, and there's no reason it must be tied to the review, but this is a good opportunity to check in with your manager about what you like about your current job and where you want to change and grow. Do you want to speak at conferences? Become a tech lead? Move into mobile development? Start managing people? Maybe the answer is just "I want to keep getting better at what I'm doing now" which is totally fine. This is an opportunity to start making a plan with your manager about how you're going to achieve what you want.

I promise that your manager will put in effort to give you a thoughtful review and help you grow, and I hope that you will put in the effort to write thoughtful reviews for others. The prose is less important than the content, a bulleted list that says something meaningful is fine if that is your style.

When this is all done I welcome feedback from all of you as to how we can make the process better. I have gotten a lot of value out of my reviews over the years, above and beyond regular feedback, and I believe we can make this process worthwhile for all of us.

Happy writing!
Camille