Trust is absolutely essential for human survival. Until we feel we can rely on the person the the left of us, and the person to the right of us, we can't really achieve anything great.

…

The reason trust is important is because when we’re surrounded by people who believe what we believe, we’re more confident to take risks. We’re more confident to experiment, which requires failure by the way, we’re more confident to go off and explore knowing that there is someone from within our community, someone who believes what we believe, someone we trust and who trusts us who will watch our back, help us when we fall over and watch our stuff and look after our children while we’re gone.

…

When we feel safe trust will emerge. This is what the foundations of leadership really are. The reason we call someone leader is because they choose to go first. They choose to extend trust first, even before there are any signs they should. The willingness to express empathy before anyone else.

It's not inherently harder to be a tech lead while remote or on a distributed team – it's more deliberate.

I tweeted this sentiment recently along with the concept of durable communication. That phrase is inspired by data storage which is typically grouped into two categories: durable and ephemeral. I often hear people say it's obviously harder to work remotely, and very hard to be in a leadership position remotely. I think that's a cop out. I don't buy it for a second.

Before we continue: This post is about being a remote worker or working on a distributed team. I am convinced this is the path software organizations are rightly headed, and I'm determined to help you get there. If your organization has no remote workers, by choice or otherwise, or if you think remote work or remote leadership is out of the question this post may not be for you. That's cool. On the other hand, maybe it'll give you the tools, vocabulary, and confidence to give it a shot. Either way I look forward to hearing about it.

• What is Durable Communication?
• Why do I care?
• Effective Communication Saves Time
• Transparent by Default
• Shared Responsibility
• Change is Hard
• Tools
  • Text Chat
    • ChatOps
  • Audio/Video Communication
  • Screen Sharing
  • Development Tools
    • Commit Messages
    • Code Review
    • Digital Progress Board
  • Collaborative Writing
  • File Store
  • Shared Calendar
  • Email
• Techniques
  • Everyone Should Experience Remote
  • Face Time (Onsite)
  • Invite Remotes to Hallway Conversation
  • Over Communicate
    • Share Your Personality (Off Topic)
    • Have a Visible Pulse
  • Pick a Timezone
• Conway's Law

What is Durable Communication?

Collaboration using deliberately inclusive, transparent, and reliable tools and techniques. It's the cornerstone of successful remote work.

Why do I care?

I currently lead three teams in a distributed engineering organization. One is entirely based in California, another entirely in Pennsylvania, and the third is split between those locations. If I'm going to be successful as a leader it's critical that we that we get communication right. I admit to being a change agent and this is one of the ways I've changed the engineering organization. This essay describes how my teams communicate.

Effective Communication Saves Time

Communication is more deliberate and intentional when you're remote and communicating effectively. In a distributed team where pockets of people are co-located it's easy to unintentionally make decisions and share facts only with team members who are in the same physical location. It happens in the kitchen or at lunch. When communicating with someone far away from you, physically, you have to choose to share. It's not an accident.

If you want to succeed at remote work it requires deliberate changes to the way your team communicates. It's a conscious choice to alter behaviors and culture to better suit a distributed group of people.

This is a skill which can be acquired. It takes practice. Here's the thing: it's no more effort than accidental communication and, in fact, it saves everyone time and energy in the long run when information is freely flowing in channels designed to share broadly.

Over time it becomes more comfortable to communicate in a shared space and you'll soon find yourself choosing that by default. You'll say, "I just learned something weird about our data schema. I'll tell you in our chat room." As you describe the oddity that is your data model, in the chat room, you're sharing with everyone regardless of physical location.

Transparent by Default

One of the most striking changes a team experiences when practicing durable communication is the substantial increase in their transparency. Most communication is in the open. It's archived and indexed. Anyone can read it.

It's like giving your team the super power of time travel. In three years someone is going to be asking, "Why the hell did we define an enum for this obviously boolean attribute and by the way querying it is timing out on large data sets?!" They're going to search your chat archives, read commit history, find tickets, and learn that the attribute was supposed to have five values and was simplified three days before launch because otherwise we weren't going to finish¹.

Thank your lucky stars! All the engineers who worked on that feature have moved on to new opportunities and there's nobody left to ask in the hallway. Good thing your communication was durable. Always err on the side of transparency. It'll save your future ass.

Shared Responsibility

Responsibility for durable communication is shared among everyone in a distributed organization; everyone is accountable for their part in making collaboration maximally effective.

Your organization

has a responsibility to provide a collection of tools to enable distributed collaboration.

Your team

has a collective responsibility to cultivate a culture built on the techniques of durable communication.

You

have a responsibility to provide continual feedback when communication is becoming ineffective.

 

This may be during a conference call when two people are having a side conversation and suddenly you can't follow anything being said. "Excuse me, I can't follow multiple conversations at once. Can we do one at a time?"

 

It may be during a retrospective to highlight key decisions made beyond your visibility. "I was surprised to learn we decided on Elixir for the spike. If it was written down I didn't see it."

Change is Hard

If your organization is expanding from co-located to distributed it will come with growing pains. Once durable communication has been fully embraced it will feel effortless. Transition won't feel that way, and that's okay. Change requires additional effort and that is hard, but it's effort spent going in the right direction so it's well spent.

What follows are concrete methods for reducing the pain of distributed work. It's tailored for teams building software.

Tools

I'm going to list a handful of options ranging from completely free to paid. These are things I know about. They aren't endorsements unless explicitly stated. In other words, you should do the cost/benefit analysis for your organization and choose wisely.

Text Chat

This is the primary device for durable communication. In my experience it's the most critical tool in your collaboration toolbox. There are some specific features which make it invaluable, and any deployment should have them one way or another:

Archive

An indexed, searchable archive is particularly important. This is a history of your teams' informal communication and, just like in the hallway, a ton of knowledge sharing and key decisions are made here. You want to remember that.

Group Chat

It's not enough to have one-on-one chat capability, however…

Private Chat

it's also important for individuals to be able to communicate.

Full Participation

Everyone in your organization should be able to use it, and should be using it.

Try HipChat, Slack, IRC, Google Hangouts, or jabber.

ChatOps

ChatOps is the use of text chat tools for the transparent automation of business practices. It's so awesome it has a heading. Typically ChatOps is achieved by deploying a bot, which connects to your chat system, and can be programmed to do tasks for you. For example, it could build a new release, do a full deployment, pick a place for lunch, or find the perfect animated GIF for the conversation. It's fun and useful!

ChatOps also helps introduce context into your conversations. It can be hard to know what's going on when you're on a distributed team and we can bridge that gap by doing some of that work right in a chat room where everyone can see it. No more wondering when a release is happening. You just saw someone start a release, and you just saw your bot report the release happened successfully.

Try hubot or Lita. HipChat and Slack also have a lot of built-in integrations with external services to provide the reporting aspects of ChatOps out of the box.

More on ChatOps: Carol Nichols, "How is ChatOps Formed?" (video).

Audio/Video Communication

Everyone should be able to have a phone call, or Internet equivalent, when they're at work. Voice is fine, usually, and video is higher bandwidth. Non-verbal communication is a huge part of human communication and it should absolutely be a part of your remote work environment. (Please don't make the joke about not wearing pants. It's not funny anymore.)

This tool requires some hardware. It's necessary equipment to effectively do your job and your company should provide it or reimburse you for reasonable expenses.

Headphones

Yes, you need headphones. Unless you're sharing audio with a room you should be wearing headphones on a call or video chat. If you don't you run the risk of an audio feedback loop. Software is still spotty at avoiding this.

 

The other reason for headphones is if you're working on a distributed team with pockets of co-located people there's a likelihood you'll end up on the same call as several people around you. There's nothing worse than hearing someone speak twice, on a slight delay, so it sounds like an echo. Oh, there is something worse: hearing yourself when you're talking, on a slight delay.

Microphone

I recommend getting a set of headphones with a built-in microphone. A lot of the reasons for having one are the same as above.

 

The times when this breaks down are meetings where most people are co-located and a lot of them are speaking. An example is standup with a couple remote workers and everyone else physically gathered. For these cases I recommend a microphone which can be passed around when someone is speaking. This serves two purposes: high quality audio for the speaker regardless of their location in the room, and it tends to force the group to speak one at a time.

Camera

Most laptops and all-in-one desktops come with cameras these days and they're usually good enough for these purposes.

 

The times when this breaks down is conference room meetings, often with whiteboards, where a small number of participants are remote. If your company is fancy they can buy great solutions for this problem. A cheap option is an external camera which someone in the meeting can pan and zoom for you. Cheap and effective.

There are three important features of any effective audio/video communication tool: the ability to have one-on-one calls, the ability to conduct group conference calls, and the ability to do either in 60 seconds or less. This collection of features isn't always available in a single tool, and that's okay. Use a few if you have to. It'll pay off.

Try HipChat (one on one), Skype, Zoom, Webex, talky, sqwiggle, or Google Hangouts.

Screen Sharing

This is your fast-track to remote pair programming, troubleshooting, hallway testing, and collaborating with other disciplines. The important features are the same as for audio/video calls: one-on-one sharing, group sharing, and the ability to do either in 60 seconds or less.

Try Screenhero (for Slack), HipChat, join.me, or Webex.

Development Tools

Commit Messages

"The only difference between science and screwing around is writing it down." – Adam Savage, Mythbusters

Commits are like emails to future developers. Please write good commit messages for our future selves. And not just ourselves, but any future developers working on this code.

Think of it as time travel. When Marty wrote Doc that letter, it wasn’t a cryptic, short message he would only understand in-context. It wasn't simply a P.O. Box address for Doc to go find the details at. It was a clear description of the problem and solution. It was helpful as soon as it was read.

Commits are always in sync with the code. This is awesome. It means we can write documentation about our code without the worry of it getting stale. That's better than comments, even. A commit message for a piece of code lasts exactly as long as the code it's talking about lasts.

More on commit messages:

• Alex 'Skud' Bayley, "Start Your Commit Message with a Verb"
• Stephen Ball, "Deliberate Git" (video)

Code Review

Written, asynchronous code review is a central part of any solid development cycle. Don't take my word for it. From the excellent book, Code Complete:

…software testing alone has limited effectiveness – the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

• In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
• In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
• The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
• IBM's 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
• A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
• Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.

Copied from Coding Horror's copy.

Yes, you still need to write tests. Automated testing is not enough to find defects early. Combining them with code review is a winning strategy. Code review reduces defects, increases learning and knowledge sharing, and serves as a written artifact of technical decisions made over time.

Some options for deploying code reviews include GitHub Pull Requests, Gerrit, ReviewBoard, Code Collaborator

More on code review: Derek Prior, "Implementing a Strong Code-Review Culture" (video).

Digital Progress Board

Sticky notes don't scale. I'll caution you here: this is not an opportunity to over-architect your development process. You need a few queues to understand the workload of each step in your development pipeline. This gives you insight into capacity and constraints, and provides a high-level picture of work in progress.

Try Trello, Pivotal Tracker, JIRA's Agile Plugin, Waffle, or GitHub Issues.

Collaborative Writing

Being able to take notes together in meetings is very powerful. A real-time document sharing tool brings people together in meetings and serves as a very powerful alternative to a whiteboard. Someone can decide to take live notes while others cleanup structure and edit behind them. Everyone can see the conversational history and it can be preserved for posterity.

Preservation should take place elsewhere. These tools usually aren't good choices for long-term, curated document stores. Instead it may make sense to copy your artifacts from here to a story, or a README, or a specific document under a docs/ directory in a repository.

Try Etherpad, Hackpad, Google Docs, GitHub Wiki, or Confluence.

File Store

Sharing large files is hard, still. Especially at work. It might be PSDs, PDFs, or OVAs. Making this easier will ease a common pain point of distributed teams. The solution you choose will depend on your particular risk profile.

Try Dropbox, Box, NFS, WebDAV, or Google Drive.

Shared Calendar

Availability must be constantly communicated. Picking a time to get people together across locations and timezones can be a challenge. Shared calendars solve that problem. Frankly, I wish there were more options here. If you know of any solid alternatives I'd love to hear about them.

Try Exchange or Google Calendar.

Email

No, not really. Email is often one of the slowest, least effective means of collaboration and I don't recommend relying on it for that purpose. It does have a place, and I feel that place is in non-critical communication with no time pressure. For example, when you want to chat with someone who isn't "in the office" at that particular moment and it's not important enough to call them.

It's also an effective way to receive reports and notifications which, often, will lead you to the other collaboration tools mentioned in this document.

If you need a quick answer from a co-worker or team and you're starting to write an email I have this advice: stop. You're about to waste time and introduce needless delay. I bet you'll get a faster answer on text chat.

Techniques

Everyone Should Experience Remote

At some point you should send every team member home, or to their local coffee shop, or into separated conference rooms to simulate being remote. Empathy is a great motivator, and if the folks at headquarters are having trouble adjusting to your remote workforce this is a fast-track way to help.

I love the idea of having everyone work from home (or wherever) every Friday. A policy like this tends to make people happy. They like it. However, it's not a big enough burden to change minds most of the time. It'll become your "heads down day" and the point of the exercise will be lost.

I recommend at least a full week. Everyone is remote. Meetings continue as scheduled. So do pair programming and planning sessions. Standup? Yes. Meetings with other departments? Yes, plan to dial in or video conference.

There's a higher-level business benefit to doing this regularly, too. It can serve as a good, real test of your operational business continuity plans. It's a sustained use of the tools you've put in place for when your office burns to the ground. You are thinking about how to operate the company when your office is on fire, right?

There are team members for whom home is not a suitable work environment. Speaking as a dad who had toddlers I can tell you sometimes it just isn't going to be viable. Don't require everyone to be at home. For folks who can't they should be offered the option of renting a desk at a co-working space (to be expensed), or commandeering a conference room for the week. If they stay in the office, in a conference room, set a rule of no talking in person. Stay true to the simulation.

Face Time (Onsite)

Get people together. Relationships are best created in person and can be sustained remotely for a while. Minimum twice a year. Being together is too valuable to waste on business as usual. Close the laptops and get to know each other for a while.

Invite Remotes to Hallway Conversation

It is inevitable, and still good and healthy, that you'll strike up an ad hoc conversation at your desk. It'll probably be about work, and chances are someone in another location is interested in that topic. This is a moment to invite them in. How do you do that when they're in another timezone? A few ways.

Invite them on video chat. This is the best. It's like you're right there in the room because your head is! Unplug your headphones so they can hear everyone and everyone can hear them. You can also invite them to audio, or you can all hop on chat and have the conversation in text. Video is still the highest bandwidth option and for that reason I recommend it.

If you work in an open office you're probably saying something I hear all the time, "but we'll need to find a conference room because it's rude to be on a call in the pit." No, it's not. It's no more rude than the conversation you're having right now. Will it surprise people? Yes, at first. They'll get over it. This is a stigma that should be eliminated. It's also what headphones were invented for.

Over Communicate

Your working relationships will benefit from the old adage "always over-communicate", just like any relationship.

Share Your Personality (Off Topic)

A benefit to being co-located with your peers is they get to know you. They learn about your kids, your hobbies, and your affinity for mango flavored tea. Even if you never said anything about it out loud they'd learn about you just from being nearby.

Remote co-workers don't have the luxury of osmosis. Our relationships grow over time through familiarity and comfort. The more we know someone the closer we feel. That's why it's important to share your personality. Share it a lot. How? Off topic.

Every organization needs an Off Topic chat room. This is where the stream of nonsense we all spew every day goes to live. This is where you tell someone you're getting coffee, where you post pictures from last weekend's mountain biking adventure, or where you drop a link to the latest badass thing Neil deGrasse Tyson just said. Off Topic is a safe place to chat about whatever you want with your co-workers.

You may end up with more off topic channels, for specific interests, than work-specific channels. That's okay! I see channels for music, cooking, exercise, and DIY often. Let this thrive and grow organically.

For those of you who lead remote or distributed organizations: (with the exception of offensive content) don't monitor or question the traffic in this room. There will probably be a lot of it, and if you've forgotten what it's like to build a thing you'll probably also wonder how these people get anything done all day. Don't worry about it. This is work. Instead of hearing it in the halls you're seeing it on the screen. No big deal.

Have a Visible Pulse

When you're remote it's your responsibility to exhibit a visible pulse. You may think nobody cares about every time you make a pot of coffee or push a branch, and you're probably right about that. What they do care about is knowing you're alive, there, and available when needed. Sending those seemingly useless messages is sending them a more important signal: you are reliable and okay.

Pick a Timezone

Your company probably has a home office. It can be helpful to agree that its timezone is your Standard Operating Time (SOT). I've employed this technique before and it works.

When is standup every day? 10am SOT

I'll be leaving the office a little early today so reach be before 1PM SOT if you need anything.

When discussing time you should always be explicit about timezones. The Standard Operating Time technique provides an generalized solution. Each individual can translate SOT to their native timezone. After a little practice it'll be second nature.

Conway's Law

Durable communication exhibits the same characteristics as accidental, convenient communication in a co-located space. The powerful difference is how inclusive, transparent, and reliable it is. Durable communication tools and techniques not only scale well with your organization, they'll empower your organization scale well, too.

Conway's law states that "organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations".

The health and quality of your product will be a direct reflection of the health and quality of your organization. Take great care of your organization and it will pay off in your product.

Asking for help can be hard for some of us. For others it may come too quickly. Wait an hour¹ to ask for help. No more, no less.

This is advice I give to my team members regardless of experience, background, or confidence level. There are two primary behaviors when asking for help. Waiting too long or not waiting long enough. These behaviors are opposite but the advice is the same: one hour. This is how it usually sounds.

Head Banging	Hand Throwing
I know you want to figure this out on your own. Given enough time you surely can. Try this:	I know you're confused. This is a new problem! You've never done this before! Try this:
When you find yourself beating your head on the wall set a timer for an hour. When time is up ask for help immediately. We're here for you and you'll get that help and move on to the next challenge.	When you find yourself giving up and throwing your hands in the air set a timer for an hour. When time is up ask for help immediately. We're here for you and you'll get that help and move on to the next challenge.

It doesn't matter which stereotypical behavior you identify with. Whether you're giving in after an hour or forcing yourself to wait an hour it's time well spent.

The Benefit of Waiting One Hour

You will read so much about the technologies, libraries, and protocols giving you trouble. Maybe you won't find the answer but you will learn a ton anyway and that knowledge has value.

The Benefit of Asking for Help

There's an inflection point when struggle becomes spinning your wheels and wasted effort. There's no honor lost in stopping and asking for help. At some point it's time to bring other brains into this. Your team is your support system. Use them!

Making it Safe

The Help Timer works best in a healthy environment. There's a give and take to it. If you wish a teammate would ask for help sooner, or another teammate would spend a little more time on the problem before asking for help, you have to do your part to make that a safe thing to do.

Practicing this approach to asking for help requires trust in your teammates. It's the foundation of any healthy team.² Trust is built through practice. It's built through the continual reception of positive responses to acts of vulnerability.

When your teammate exhibits vulnerability you must respond positively.

An Act of Vulnerability

If this resonates with you it might feel uncomfortable. I get it. Asking for help is a vulnerable act. So is struggling! Being vulnerable can be hard, and it can feel alien, but it's worth it! I encourage you to watch the following excellent TED talk by Brené Brown (full transcript.). She describes the benefits of embracing vulnerability.

"There was only one variable that separated the people who have a strong sense of love and belonging and the people who really struggle for it. And that was, the people who have a strong sense of love and belonging believe they're worthy of love and belonging. That's it. They believe they're worthy."

Head Banging	Hand Throwing
If you tried hard and still can't figure it out it's okay and you are worthy of help.	If you're lost even after looking at a bunch of maps it's okay and you are worthy of help.

You have 30 minutes to guess at the capability and fit of an incoming candidate. How do you do that? You have to assess a few key areas quickly.

Here are my tips for the person conducting the screening, written from the perspective of the inner monologue I have when I do phone screens.

Preparation

Skim the resume but mostly ignore it. If a recruiter was involved it's been re-arranged and re-worded to match keywords in your job posting anyway¹.

Opening Questions

On your most recent project, which areas did you focus on and contribute to, and what did you have the most fun with?

I'm not asking you to read your resume to me. I've seen it (and mostly ignored it). What I'm looking for here is some technical detail of your contribution. Can you articulate what you actually do? I'm technical, and you're going to be working with me all the time, so I want to hear you explain your work so I can understand it.

Even more importantly, hopefully you have enjoyed some aspect of this project. Hopefully enough to tell me about it.

Why $company_i_work_for?

I want you to have at least a passing interest in our company. If it's just, "my recruiter told me you had an opening" I'm much less interested in you. Do you know what we do? Have you at least seen our website?

Continued Education

How do you keep up to date with the software landscape?

Do you read books or blogs, or subscribe to JavaScript Weekly? Do you listen to podcasts? If you don't show any interest in keeping yourself up to date this won't go well, because it means you'll allow our software to become stale, too. You don't need to be on the bleeding edge or anything, but please have read something related to your work recently.

What is your favorite open source project? Anything is valid, from a library to a framework to something bigger.

This is two-fold. First, I have a bias for open source and I want to hire for that bias. I have a strong bias for building software on top of excellent pre-existing work. Not Invented Here (NIH) syndrome is bad news and I don't want to hire for it.

Second, something brings you joy in the work you do, right? At some point you've used a tool and been like, "This is the beset thing in the world!" For me that tool is ponysay, obviously.

Testing

How do you test your current project? Do you use BDD? Do you use CI? What's your preferred testing tool?

Even if your current project has no tests, I want to hear you be unhappy about that. I want you to know what BDD means, and CI, and use them (or want to use them). Nearly every software context has multiple testing tools to choose from. JavaScript has QUnit, Jasmine, Mocha, and others. Which one do you prefer and why? Details mean you aren't reciting the manual.

I'll be more specific on this one, because it trips up the folks who screen candidates and love testing: it isn't the candidate's fault if their company doesn't write automated tests so don't hold that against them.

Technical Knowledge

What's your favorite feature of $language_or_framework_you_have_used? What's your least favorite?

This question can use information gained from the resume, their recent project at work, or their favorite open source project.

You should have answers to both. Something is good and something is bad, and I want to hear your opinion. Hopefully I'll even learn something new. If I disagree with you that'll be an interesting conversation for a couple minutes as we debate.

Have you worked with $language_or_framework_we_are_hiring_for? Tell me about that.

If you've already convinced me you're a polyglot with an open, curious mind, this question isn't as critical but it's still important. I will dig into the details with you about this a bit, and explore what you've been exposed to. This is something I know well, and I'll share with you some of our real challenges in this part of the conversation.

What I'm hoping for is that when I share some of our challenges you have ideas, or questions, or both about how we're addressing them. This is particularly relevant to me, for this job, and it's your primary opportunity to convince me you can help.

Tooling

What's your favorite git feature?

I want you to know of git. You don't have to prefer it, but you should know of it. If you have only heard of it and had no exposure I'm sure something piqued your interest.

My favorite is the git commit --fixup; git rebase -i --autosquash combo. If you have used SVN I'm sure you can at least tell me better merging is something you want?

Development Process

Have you worked on a software team recently? How was that?

Working on a team is essential. Having some experience means you're more likely to fit into our culture. If you've spent the last five years in a silo it may be hard to adjust to a highly collaborative environment.

Are you comfortable with agile software development? What does 'agile' mean to you?

Everyone is likely to say yes to the first question. I'm more interested in the answer to the second.

We use code review heavily as part of the development process. Are you comfortable with transparent, professional critique of your work? Are you comfortable giving it, too?

This is important to us. Part of working on a team, and working with agility, is being highly collaborative and open to exploring ideas. Hesitation in response is ok, because I'm telling you we will criticize your work. However, I'm not telling you we will criticize you. I need to know you understand the difference.

Closing Questions

What do you want to do next? Obviously you're looking for a new gig, so what is it you want to be doing?

I'm looking for some kind of interest in what you do all day. Enough that you have an idea of what you'd like to be doing next. Do you want to do DevOps? Management? Become a Senior-level developer? Learn Ruby?

If you can't come up with anything then you haven't thought about it. Maybe you're going through the motions of finding a new job. Maybe you're just trying to leave a toxic, disgusting culture. That's OK. Sometimes the answer to this question is, "I want to do the same thing I'm doing now, which I'm great at, for a new company."

Do you have any questions for me?

Please ask me something, anything. If you have zero questions you aren't really that interested in working with me. There's no way I satisfied every curiosity in this short phone call.

Don't promote your most talented technologists into people management. Promote them into technical leadership roles instead. You'll keep happy, engaged leaders and avoid the perils of the Peter Principle.

It's a common policy in hierarchical organizations to promote top performers into people management. Your best programmer comes up with great ideas, the team listens to her, she can fix anything. It's review time and what happens? She's offered a job in management. What are her new responsibilities? Paperwork, reviews, operational alignment summits, budgets. How much code is she writing now? Not much and she's probably miserable.

"I don't want to stop coding." — Almost every good programmer, ever.

There's another alternative. Technical leadership. Here are some common tech leadership roles:

Lead Engineer

You're coding everyday and helping others to code better, too. You have deep experience with the tools and technologies, as well as the problem domain, and you use that to inform internal system design. You keep the code healthy.

Software Architect

You're designing the story arc of how this software fits into its problem domain. You have visibility into the long-term plans for the software, and strong technical skills to work with engineering to build something that keeps the software focused. You keep the software healthy.

CTO

The most senior architect. You know what every product line is aiming for. You know how it fits into the long-term story of the product and the industry. You share this insight with your architects and leads to give them vital context for making great choices. You keep the company healthy.

This is the intersection of technology and people.

People are at the heart of tech leadership roles. It's a socio-technical role, a mix of people and technology. Hacking on one and not the other will cause the performance of both to suffer. This is the critical glue missing from most engineering organizations where engineers are promoted to managers. This is where technical leadership plays its key role. You're not managing people: you're leading them.

Why is there a gap? Because newly-promoted managers now have too many jobs. Promoting a tech lead into a manager forces them into the problem of having too many roles. Their boss is expecting them to be a full-time people manager, but their team depends on their technical leadership. They'll either have to choose one or do both poorly, for lack of time, which will eventually force their hand into choosing people management. Again, because their boss is expecting them to do that role. Now there's a void in technical leadership.

In a healthy organization the tech lead (lets say a Principal Architect) and the people manager are a powerful pair. When they're working together the people on their team are taken care of at every level. The team is comfortable because they know what to build and why, and that they're building on the right path. They're also getting the individual attention of their manager.

Tech leadership is a force multiplier.

As a technical leader you aren't always writing code. If you're a recognized leader chances are you already know that. You spend a lot of time helping others. Teaching, mentoring, reviewing code, standing at the whiteboard and explaining the permissions model for the hundredth time. Or whatever your pet thing is…

You may not always be pressing many keys and causing an implementation to occur, but for the people who are you're a valuable asset. You help them do it better. You help them avoid the pitfalls and mistakes you've already made five times in your career.

This work is vital to the health of an organization. It has a direct impact on productivity and happiness. You are helping each team member avoid pain, and you're helping the organization avoid pain. How is this a force multiplier? The evidence is proven over time.

Applying the skill of technical leadership is a force multiplier in several ways. If any of the following apply to you, you might be a tech lead:

• Your experience helps engineers at all skill levels create solutions that last longer, are easier to maintain, and respond to change better.
• You've thought through integration problems so there are fewer surprises.
• You understand the long-term goals for the software so your short-term solutions don't paint everyone into an architectural corner.
• Your team is constantly learning from you so retention rates are high because everyone is growing.
• When a customer is upset you can code up a solution which keeps the team focused on their planned work.
• You've been planning ahead for the next big development effort — have five prototypes ready for comment by the time the team is ready — so nobody feels lost in the face of a new challenge.

This is how a technical leader is a force multiplier: enhancing the attributes of your organization to make it more effective than others. It's like skill boosts in role-playing games (be honest, if you're reading this you know exactly what I mean).

Lead by example.

Technical leadership is the role best suited for my skill set. I was fortunate enough to have been supported by a fantastic people manager at my current company. With support I used everything in my technical leadership toolbox to build teams of outstanding engineers, create a culture for them to thrive in, write the story of our next great architectural revolution, and lead the team down that path.

I love this work. I'm passionate about it. As a programmer who always wants to code, I don't get to do it as much as I'd like, but when when I do it's usually pairing with someone on my team. As a leader I get to work directly on the problems getting in the way of my team, very real people-problems, and resolve them. I do that with the support of people management.

One of the core values in my team culture is transparency. I'll exercise that by sharing a piece of my self evaluation from last fall. It's the part where I'm supposed to say what I ought to work on for the next year. This is a high-level view of my approach to technical leadership:

What should the focus be for the next review period?

I'd will continue to focus on the areas I feel are the greatest value to WhiteHat. This has been my focus for the last year and will remain so. Specifically:

Empower Others — I will continue to create space and opportunity for the members of my team, my organization, and anyone in the company to contribute at their best level.

Challenge Assumptions — I will continue to challenge the things we do, how we do them, and why we do them in a relentless effort to eliminate waste in our organization.

Eliminate Pain Points — I will continue to learn about others' work in order to find resolution for things that are difficult and painful in their daily work. I will empower my team to find ways to automate most of those pain points away, or challenge assumptions in our process and workflow which may have created them.

Influence Culture — I will continue to be the change I want to see at WhiteHat, and be myself with no bad politics or hidden agendas, in order to help create the culture of trust, learning, productivity, fun, and reward I want to work in; that I want to recruit my friends to work in.

Lead Technology and Architecture — I will continue to be a leader, mentor, and teacher to my team members and organization members. I will take an active role in leading the development and design of our software and operational architectures to ensure we make aggressive strides toward modern, sustainable solutions that meet our customers' needs.

By this time next year I will have been successful if the Engineering organization is delivering high quality software that delights our customers.

I expect my team to have delivered an infrastructure and web application framework that puts us in the position to aggressively compete in our market, to have delivered several key features which empower WhiteHat to make impressive advancements within our industry and in comparison to our key competitors.

We need a tech leadership track.

I'm sure you've heard this before: "we're going to put you on the management track." The management track is a career advancement concept designed to mold high performers into managers. Within engineering we need a new, parallel track. We need a technical leadership track.

Top performers who want to remain technical and advance their career should have the option. Organizations are in desperate need of highly qualified, deeply experienced leaders making strategic decisions for the health of their software. A technical leadership track is the best way to source that talent from within.

If you are a mid to senior level engineer right now, and you don't want to advance to management, I want to encourage you to advance to technical leadership instead. Insist on a promotion to Lead Engineer, then Architect, then Principal Architect.

If you run an engineering department and want to offer career advancement that keeps your top performers engaged and happy, don't force them into management. Create an advancement track designed to build a strong technical leadership pipeline. Your software will be better for it.

Find your best technologist and promote them to Director of Architecture. Your new Director should have people managers in her peer group. This creates space for the tech leaders in your organization to grow. Build your technical leadership team under her in the hierarchy, but let them keep working with the teams their leading in day-to-day work. Let them continue to do what they're great at. This is how you make technical leadership just as important as people management.