On Teams & Problem Spaces

Teams are most effective when they are organized around problem spaces and are explicitly named after the problem space that they’re solving. Unfortunately, if my experience is representative, this isn’t the norm. If I think back on the organizations that I’ve been a part of as an individual contributor or inherited as a manager at Microsoft, Amazon, and Riot, I’ve frequently seen teams organized around products, solution spaces, and code names. To explain each option, consider a fictitious team with the following properties:

  • The team is part of a larger organization that builds tools for feature teams to deploy, operate, and scale backend services on the company’s private cloud.
  • The team previously decided that its mission is “to make it easier for feature teams to operate deployed services” and its vision is that “services are highly available and easily scalable with virtually no operator intervention”.
  • The team’s current flagship product is an alerting and monitoring system called Brometheus.
  • The team happens to be obsessed with Star Wars (who isn’t?).

Now suppose you’re tasked with naming the team. You could name the team the Brometheus Team after it’s most important product. Alternatively, you call them the Monitoring Team, since the solutions that they currently own are in the monitoring space. You could accept the suggestion of a couple of team members that believe that names don’t matter and have pushed to be called the Jedi Order. Or, you could name the team after the broader problem space and call it the Operability Team.

The final option is superior to the others for several reasons:

  • Unlike the product and solution space options, it doesn’t constrain thinking and imply a particular solution. If you’re the Brometheus Team, your work will always revolve around improving that product (you have a hammer and everything will look like nails). Similarly, the Monitoring Team will always focus on building monitoring products. The Operability Team is free to decide that they can make it easier to operate services by working on auto-scaling, service call-tracing, or debuggability instead.
  • Unlike the code name option, it’s immediately obvious what your team does and what sandbox you play in. The Jedi Order may sound cute and the team may rally around that identity in the short term, but at scale, it becomes difficult for customers to keep a mental map of who is working on what. Further, the team’s new identity is not rooted in being a team and not the problem they’re solving; the former tends to fizzle much more quickly.

Reorganizing or renaming teams can be hard work, particularly if the team’s current identity is tightly wound around their current name or organizational structure. But in the long run, doing the work to identify problem spaces, organize teams around those problem spaces, and to explicitly name teams after the problem space they’re tackling is worth it.

On Productivity

Like you, I’m busy! I have a family that includes a 3- and 4-year-old, a fun (but demanding) job at Riot, I’m a student in the Berkeley-Haas MBA for Executives program, I volunteer work as both a mentor at Techstars and a director at a non-profit organization called Potential Energy, and I have a bunch of other hobbies that range from hacking on side projects to learning German to training for a marathon. I list those commitments purely in an attempt to convince you that my survival hinges on my ability to squeeze every minute out of every day. I get asked about time management and my personal productivity system fairly often, so I’m taking the time to describe the way that I operate here in a blog post for three reasons: in case others can learn from my system, in hopes that I can get feedback and improve my system based on what’s working for others, and to give me a place to point people in the future instead of offering a slightly half-assed verbal brain dump on the spot.

If you just want a tl;dr of the high-level best practices that I’ve based my own system on, they are:

  • Get your life’s backlog into a tool. Groom regularly, and setup short (daily?) sprints.
  • Keep yourself off of the endless email treadmill.
  • Track and update your personal growth in a lightweight artifact that you look at on a regular basis.
  • Be extremely tactical about the setup of your workstation when you go heads down.
  • Exercise and eat healthy, so your body isn’t working against you.

With that said, let’s dig into the deets.

I keep my whole life in Evernote, following a sort of Scrum-like system that was inspired by The Secret Weapon and has been customized over the years. Keeping everything in one place gives me the freedom to focus on particular tasks and sleep well at night while knowing that I’m not dropping anything on the floor. I have three primary notebooks in Evernote: Action, Done, and Reference. I have email forwarding set up so that I can forward email to Evernote from both my personal and work email, and I have Evernote’s web clipper add-on installed in Chrome for capturing web pages. I use a tagging system that includes tags for the place that the item pertains to (@home, @riot, @haas, @techstars, @potentialenergy, etc.), the priority of the item (0-Critical, 1-Urgent, 2-Important, 3-Average, 4-Trivial, 5-Irrelevant), and a special tag for when I will tackle the item (Today, Soon, Daily, Recurring). Everything that first comes into Evernote goes into my full backlog, which I can view with a saved search for everything in Action. Once per day, I pull items from my full backlog into my daily backlog by adding the Today tag; I can also view this backlog with a saved search.

I only check my work email once per day, at the end of the workday. I assume that if anything high priority comes up I can be tracked down in real-time via either IM or in-person communication (and thus far, this has only bitten me once or twice). Closing the email window during the day has been a massive win for me both in terms of time savings and a reduction in context switching, although as a brief aside I’m concerned that the migration to Slack for a lot of communication may make this kind of firewalling more challenging moving forward. When I clear email, I make a bottom-to-top sweep of everything in my inbox, and for each mail I take one of a few actions: I mark it read if it requires no action, I reply to it or take the necessary action if it will take me less than a few minutes, or I forward it to Evernote so that it shows up in my full backlog.

At the end of each evening before I read and call it a night, I go through my full backlog in Evernote and add tags (including a priority, and in some cases the Soon or Today tag) to all the new items that have come in. I then take a few minutes to pull the necessary tasks into my daily backlog for the following day (starting with tasks that had the Soon label), and I look at my calendar to be sure that I can accomplish everything in my daily backlog and that I’ve identified the right set of priorities.

I also keep a Personal Development Plan (PDP) in Google Docs, using a lightweight format called the Agile PDP format that was created by a fellow Rioter named Andre Ben-Hamou. The format probably warrants a post of its own, but it essentially involves identifying three to five high-level focus areas along with a list of backlog items that relate to those focus areas. The difference between the backlog items on my PDP and those that make it into my full backlog from other sources is that these items are intentionally growth focused. Once a week I do a deeper sweep of my entire full backlog to be sure that everything is still relevant and prioritized correctly. After that I review my PDP, add new items as appropriate, and pull items into my full backlog in Evernote as appropriate.

During the day I take great pains to be sure that my work environment is setup correctly. I start by making sure that my desk is clutter-free, and that I have both a snack and some water. I close everything except for Google Calendar (so I know what meetings are coming up) and Evernote, and I disable most notifications on my phone. My desk is in an open team environment, so I usually have headphones on playing music from Digitally Imported along with some very light white noise from A Soft Murmur to help drown out background conversations in the area.

To keep my energy level up throughout the day and help me focus, I make sure that my mind and body are both healthy and in a good place. I spend 10–15 minutes practicing mindfulness through meditation in the afternoon, typically following a guided meditation from Calm. I’ve created a personalized DIY Soylent recipe that I use to augment/replace my meals and ensure that I’m getting the nutrients that I need. I also typically exercise three or four times per week, typically either cycling to work or going for a jog in the morning or the evening.

There are a lot of other nuances to the way that I work, but the above is a fairly comprehensive bird’s-eye view of the artifacts and rituals that I’ve developed to keep me sane and productive. I think effective personal work systems are highly specific to people and environments so I’m not certainly not advocating that you should adopt my system out of the box, but I hope that you will find pieces of my routine helpful. Please take advantage of the comments to let me know what’s working for you in your own routine so that I can consider adopting it as well. Thanks!

Death by a Thousand Chickens

Almost every candidate that I have interviewed at Riot Games asks something along the lines of, “Everything about Riot sounds awesome, but it can’t all be roses – what’s the most challenging thing about working here?” I generally start by assuring them that Riot is, in fact, a particularly amazing place to work for a million different reasons. A few examples from my personal experience here: we invest deeply in growing people, we all care a ton about the products that we’re building and the focus on the people who play our games is palpable, and we provide unlimited opportunity to get plugged in and drive real change on everything from product decisions to the way that teams and organizations operate. But the people asking the question are correct – it’s not all roses, and we also want to be transparent about our areas for improvement. That’s why I always describe an area where I think we currently have a lot of room for improvement: we’re often the victim of “Death by a Thousand Chickens.”

Before I define Death by a Thousand Chickens (which I will hereafter abbreviate as DB1kC, because if there’s one thing engineers enjoy, it’s creating acronyms!) I want to emphasize that it isn’t specific to Riot. It’s a phenomenon that can occur in any organization but is more likely to occur within flat organizations where individuals at all levels are empowered and appeals to hierarchy don’t carry weight. I’m using a specific example from my experience at Riot to help explain the concept, but I think the ideas here are broadly applicable, and I would be thrilled if this post can ignite a discussion on how to prevent DB1kC without reverting to a top-down chain of command.

DB1kC occurs when someone is trying to make a decision at an organization and a large number of well-intentioned people want to be consulted and provide input on the decision, but very few want to be responsible for helping to execute on the decision. To steal a couple of terms from the scrum world, it’s trying to operate with a multitude of chickens and precious few pigs, when the chickens keep running in and tripping up the pigs.

To ground this in a real-world example, let’s travel back in time a couple years to when I first joined Riot. My experience interviewing for a position at the company was decent, but having seen the way that we were interviewing engineers from both the inside and out I was convinced that we could do better. The process took a long time, the content and structure of interviews differed (sometimes drastically) between different organizations and interviewers, and it was difficult to mine the data necessary to make data-informed improvements to the process. I took up the mantle and issued a “call to arms” email to all engineering managers and recruiters and asked people to join a virtual team that would meet on a relatively infrequent basis and serve as a central coordination point for work to improve our interview process. I got a lot of responses to the email from managers who wanted to give input into the work that the group was doing, but most people said that they didn’t have the bandwidth to join in the work themselves.

About 10 people did opt into the group and commit to doing work, and over the course of the next 6–12 months we were able to make a bunch of targeted improvements to the interview process. We rolled out a fresh set of interview “kits” to push us towards more standardized and structured situational and behavioral interview questions, we partnered with central recruiting to help launch a survey to collect metrics on the candidate experience, and we made other changes to the process that reduced candidate turnaround time significantly.

The problem is that as we attempted to deploy each of those improvements, we had to do battle with DB1kC. Some folks who didn’t want to commit their time to work with our v-team told us that we had moved the needle forward, but not in the exact way that they wanted things to go. Others spun up parallel efforts to implement targeted improvements in a particular way for their specific team without engaging with us and attempting to generalize what they were doing so that it could be applied to other teams at Riot. All of these chickens were trying to help, but they weren’t on the sidelines *or* on the playing field. They were essentially standing with one foot on either side of the boundary line, and in the process, they were slowing forward progress (and in some cases bringing it to a screeching halt).

Contrast this with the way that I could have attempted to push changes to the hiring process through for my organization at either Microsoft or Amazon. Once I had documented the proposed changes to the interview process, I could have pitched them up my management chain and gotten buy-in from my VP, who would have turned around and told his entire organization “this is how we’re interviewing from now on.” Note that I’m not saying that escalation is the only tool at those companies, but I am saying that it’s a viable tool that exists and gets used to preempt the possibility of DB1kC. The advantage of driving change socially at a flat organization is that at the end of the day, the idea is more refined (by virtue of more input/iterations) and everyone is aligned; you get 100 percent buy-in. The advantage of leveraging hierarchy, on the other hand, is speed. DB1kC is the extreme example where trying to roll out a change socially results in deadlock and speed essentially goes to zero.

Now despite the risk of DB1kC, I firmly believe that the pros of flat organizations that don’t allow for appeals to hierarchy far outweigh the cons. I am, however, passionately interested in mechanisms that can preserve the benefits of a flat organization without sacrificing the ability to move quickly. I suspect that any successful strategy probably hinges on being crystal clear on who is in the game and who is on the sidelines: if you’re a chicken, assume that the pigs are doing good work and don’t get in the game unless you’re asked to do so. From the outside, companies like Apple and Asana appear to be making the pig/chicken distinction explicit by nominating a single Designated Responsible Individual (DRI) to be accountable for a decision, letting the DRI choose who should be looped in, and then trusting that they probably got it “right enough.” I’m waiting for a good opportunity to pilot the DRI concept at Riot, but I haven’t done so yet.

What say you? Are there other ways to solve the dreaded Death by a Thousand Chickens problem? If so, I would love to hear suggestions in the comments! And before I go, a quick shout out to my colleague Michael Chang who first coined the phrase “Death by a Thousand Chickens” – had he copyrighted it, I would owe him at least a dollar by now…

Delight Customers By Not Giving Them What They Want

It sounds odd, doesn’t it? I’ve spent the last 2 years at Amazon, where we preach customer obsession day in and day out. It’s one of the things that makes me love my job. Yet I’m firmly convinced that in some very few cases, the best thing to do for a customer is to not give them exactly what they are asking for.

Consider a recent discussion that happened at work during a meeting. To set the stage, you have to understand that Amazon has made a massive bet in continuous deployment over the last several years. John Jenkins, a long time Amazonian before joining Pinterest, gave some impressive stats on how frequently Amazon deploys code to production during his talk at Velocity in 2011. In the two years since that talk the company has doubled down on it’s investment to ship code to production continuously, and while I can’t disclose specific details the numbers today would blow the 2011 numbers out of the water. We have an internal saying that “bake time is for cookies”, and the normal mode of operation for most teams is that changes flow to production within minutes or hours of when they are checked in. Of course, deploying continuously comes with a cost. First, you have to have tooling in place that can drive the correct integration and deployment workflows and respond to failures gracefully. Second, applications have to be designed and implemented a certain way: interfaces must be hardened to allow independent deployment of components, adequate automated tests must be written, etc. In practice this state can be difficult to achieve when you’re starting from a messy, legacy code base.

In this particular instance a team was trying to move to continuous deployment, but they wanted to take baby steps to get there. They were asking us to build legacy features into our shiny new continuous deployment tooling that would allow them to use some of the tools while still running a bunch of manual tests, batching up changes, and deploying infrequently. My boss has an amazing knack for analogies, and he described the situation this way:

“We’re trying to sell modern medicine. We’ve built a beautiful new hospital that people are excited about. But some people can’t fully justify the cost of buying in, and now they’re starting to come to us and ask us to put rooms in the new hospital for bloodletting.”

There were several problems with building the features that this team was requesting. First, it would enable the team not to make the massive leap that was necessary to change the way that they develop and deploy software. In the world of software engineering, states that are viewed as stepping stones often become much more permanent. Worse yet, it would allow other teams to leverage the features and not make the leap. And finally, the work required to build the features would prevent our team that built the continuous deployment tooling from building cool new features that people who were really doing continuous deployment needed.

Don’t get me wrong, this kind of circumstance is the exception and not the rule. If you think that your users are asking for the wrong thing you should first doubt and question yourself, then question yourself again. But occasionally the impulse is correct and the way to delight a customer you have to not give them what they want. They won’t appreciate it in the short term, but if you’re confident that you’re making the correct call they may thank you down the road.

Getting Rock Stars Excited About Working For You

The most important thing that the manager of a software development team can do is to staff their team up with rock star developers. The “10x Software Development” principle that Steve McConnell and others brought to the mainstream is the biggest reason why: the best developers aren’t just twice as effective as average ones, they’re an order of magnitude better. This is old news, and we’ve all heard it before by now (and on a side note, it’s also why I’ve previously harped on the importance of building a network of talented folks). What isn’t old news is that there are a few straightforward steps that managers can take to maximize their chances of landing those amazingly talented developers.

I’ve managed teams at both Microsoft and Amazon. I’ve recruited the cream of the software development crop against virtually every other big tech company, exciting start-ups, and even against other teams within my company. I’ve won more of those battles than I’ve lost, and I’ve learned my share in the process. I’m going to share a few very tangible suggestions that you can put into practice today that I humbly submit will make you more effective at winning your own recruiting battles. Most of the tips are equally relevant whether you’re managing a team within a huge company, or hiring employee #1 at a start-up operating out of your garage.

To set the stage, let’s start by focusing on a scenario that you’re likely to come across in the recruiting process. Suppose that you’ve been fortune enough to find a rock star developer who’s interested in your team. She breezed through your interview process, and your HR folks (who incidentally may also be you at a small company) have reached out to the her and started to negotiate compensation. The word comes back from HR that the developer is interested in joining your team, but she has other offers out from two other companies with comparable compensation and she’s having a hard time making a decision. The good HR peeps inform you that you’re at the absolute top the compensation range, so there isn’t any way to sweeten the offer and blow her away with dollar bills. They’ve lined up a sell call for you to chat with the developer, answer her last few questions, and get her jazzed about your team. This is a position that I’ve personally been in at least 10 times over the past year.

In this situation there are two sets of inputs that will determine whether the candidate accepts your offer. The first is a set of things that are mostly out of your control at this point, for example: the brand image of the company that you work for, the location of the team offices, differences in the compensation packages being offered, and the appeal of the projects that each team is working on based on that developer’s particular experiences and interests. The second set is in your control, for example: the way that you come across in the phone conversation and any other communication with the candidate, the way that you choose to paint a picture of your team, and how well you and the person connect. The following are tips that I’ve found effective at maximizing that second set of inputs that are in your control and increasing your odds of landing a rock star:

  • Prepare a one pager that sells your team, today. Leave the stuff that isn’t sexy out. Don’t talk about your ops rotation or that legacy product that your team has to keep on life support. You should field questions about those areas honestly when asked, but the one pager isn’t the place to do so. Sell the long term team vision, and make it something that good developers want to sink their teeth into. Emphasize hard technical challenges. Be sure to call out who your customers are and what the impact of the technology is for them, and consider including a powerful quote from at least one of satisfied customer. Email the one pager to the candidate as soon as possible once you’ve decided to hire them and before the sell call to keep them thinking about your team and help them formulate follow up questions for the phone call.
  • Come to the phone call prepared. Know the candidates resume and background inside and out. You studied this extensively prior to interviewing the candidate, but be sure to refresh your memory immediately before the call. Understand that when you chat, you shouldn’t feel the need to cover absolutely everything that your team is doing; in most cases that will be more than a person can digest in a single phone call. Create a list of no more than 3 high level bullet points that you want to be absolutely sure to cover. Tailor those bullet points to the kind of technologies that the candidate is likely to be excited about.
  • Spend the first 5-10 minutes of the phone call learning more about the candidate. Be sure that you’ve accurately identified their interests. Be ready to adjust your message on the fly to emphasize the points that jive with their interests. Ask probing questions to show them that you’re really interested in what they care about, and to be sure that you’re correctly identifying their interests.
  • Walk around while you’re talking. Put the phone on speaker, or get a headset. Use your arms and other body language, even though the candidate can’t see you. It’s easier to speak naturally and get excited about what you’re talking about if you’re not chained to a desk and phone. Your enthusiasm about the team and products is absolutely key to getting the candidate excited, and it’s harder for most people to convey over the phone than in person. It’s also something that is very difficult to fake if you’re working on a product that you aren’t a fan of.
  • Try to take the phone call to a place where it turns into a technical discussion between you and the candidate. If you can get to a point where they’re excited about the technology, making suggestions, and engaging in a dialogue about where they would take the technology you’re in great shape. Intentionally nurture that kind of discussion.
  • End the call by answering questions and offering to connect them with additional resources. I personally always provide my contact info and encourage the candidate to get in touch with me if any future questions come up. I also offer them a chance to schedule a follow up phone call with a senior engineer from the team (that I trust to represent the team well) to dive further into the technical weeds if the candidate is interested. They will only rarely take you up on that offer, but making the offer still goes a long way to establish the technical credibility of the team.
  • If the opportunity presents itself, follow up with something memorable. When I was contemplating Amazon my baby was just a few months old, and the hiring manager sent me an Amazon branded onesie. We sometimes send candidates Kindles to keep Amazon front and center in their mind and show them how much we want them to join us. I had a candidate a few months ago that wanted to join the team but was hesitant about the weather in Seattle, so I took a picture out the office window on the next day (which happened to be beautiful and sunny) and emailed it to him. Anything that keeps your team and company front and center in the candidate’s mind is awesome. Be sure not to force it if the opportunity doesn’t present itself, because that kind of attempt will likely come across as desperate and produce the opposite effect.

I hope you find those ideas helpful and are able to implement them effectively, unless I happen to be managing the team that you’re competing against for that next rock star developer. 🙂 I’ll certainly welcome feedback and/or additional suggestions from others in the comments below. I’ll add the usual disclaimer that these ideas are all my own, and don’t reflect any of the opinions of my current or former employers.

A Strategy For The Dreaded Interview Coding Question

If you’re a software developer and you’re thinking about changing jobs, you’re probably at least a bit anxious (if not downright freaked out) about the prospect of facing a whiteboard armed with only a trusty dry erase marker and your wits while an interviewer fires a coding question at you. That’s not shocking because software development interviews are weird: the skills necessary to answer the technical and behavioral/situational questions that are asked don’t necessarily map 1:1 with the skills to be a good developer. We’re used to developing with access to tools like IDE’s and StackOverflow, without unnatural time constraints and the pressure of landing a job in the balance. I’ve interviewed literally hundreds of candidates in my roles as a manager both at Microsoft and Amazon, and I’ve seen hundreds bomb coding questions. That doesn’t shock me for the reasons previously mentioned, but what does shock me is the number of bright folks who fail on the questions simply because they don’t approach them with a solid strategy.

The anti-patterns are crystal clear and they almost always lead to a wipe, for example: diving straight in on code, assuming that language/syntax doesn’t matter, or failing to consider edge cases before implementation. To avoid these pitfalls, I recommend that every interviewing developer should practice the following strategy before going into interviews and put it into practice (without fail, no matter how simple the question seems) during the process.

Restate the problem and ask clarifying questions.

Repeating the problem in your own words and asking some follow up questions only takes a second, and it’s a good way to quickly tease out any bad assumptions that have been made. It also gives the interviewer confidence that you’re used to attacking real world coding tasks the right way: being sure that you’ve correctly interpreted requirements and thinking through questions that impact various potential approaches. Ask how important optimization is instead of just assuming that implementing the naive solution is bad. Ask what you should optimize for, for example quickest execution speed or smallest memory footprint.

Walk through a basic example in detail and consider a few edge cases.

Take the time to think through at least one straightforward case, as well as a few relevant edge cases. Talk through your thought process as you’re going through them, utilizing the whiteboard as much as you can. Consider null or zero length inputs. Consider very large inputs, and be prepared to answer questions about whether your implementation would fit in memory on specific hardware given specific inputs. The process of walking through these cases should get you very close to pseudocode.

Write up pseudocode.

Be sure that you’re not writing in a real programming language. Pick a spot on the board where you don’t have to erase your pseudocode when you start to write real code, and will be able to read it. Lots of interview questions require thinking about recursive versus iterative implementations, so it doesn’t hurt to always consider whether that question is in play if it is relevant to the problem. Don’t abandon the pseudocode to dive into real code until you have completed the problem. Be sure to continue the dialogue with the interviewer while you’re thinking, and show that you can listen and course correct given hints.

Pick a language, and ask how important syntax is.

Always assume that for actual implementation, the interviewer cares about the details. I’m generally not a stickler for small syntactical minutia, but I get annoyed I get when an interviewer just assumes that it’s alright for the final implementation to be in pseudocode or some hodge-podge of languages. If you decide to code in a language other than the one that you indicated that you’re the most comfortable with on your resume, be sure to explain why. Asking how much the interviewer cares about syntax can help you decide whether to take an extra pass at the end of the loop being sure that everything is spot on; if the interviewer doesn’t care they may see it as a waste of precious time.

Code it!

You’ve done all the hard work, getting from pseudocode to your language of choice should be fairly trivial.

It’s important to remember that a typical interview in a loop will run 45-60 minutes, and most interviewers are going to want to touch on more than a single coding question. The expectation is most likely that you can complete the question in 20-30 minutes, so be sure that you’re not spending a ton of time on each step. A lot of interviewers will tell you that they’re not necessarily looking for you to get to a fully working implementation, but don’t believe them. If you don’t get code up on the board or stall out they will definitely ding you. Don’t spend more than a few minutes restating the question and walking through edge cases. The bulk of your time should be spent in an even split between pseudocode and code.

The beauty of following this strategy is that you will come across as organized and informed even if you don’t understand the question. It also provides an opportunity to work with the interviewer through follow up questions while running through examples and pseudocoding. Remember, the interviewer knows the answer to the question and they probably want to get you hints as you move in the right direction, so engaging them and using them as a resource is critical. Hope that these ideas help, now go nail that interview loop!

Great Documents: A By-Product of Effective Software Development Managers

If you’re managing people who develop software you should probably be spending a nontrivial portion of your time writing documents, and the quality of those documents is critical. Documents matter because there are several questions that every manager needs to answer for their management chain:

  • What’s current state of the union?
  • Where are we headed over the next 12-36 months?
  • What level of staffing do we need to achieve that vision?
  • Are my employees compensated appropriately?

Managers also need to answer a related and partially overlapping set of questions for their employees:

  • Where is the team headed?
  • What’s my role in helping us get there?
  • How have I been performing?
  • How can I improve my performance, and grow my career?

Several tools are available to answer these questions in the modern business setting, but none are as effective as written documents. Face to face conversations or meetings are less efficient, more random, and can’t be archived for easy consumption after the fact. PowerPoint presentations require the context of a speaker (if they don’t you’re abusing PowerPoint and giving bad presentations) who is only presenting to a limited audience, so they share the archive problem of conversations. Videos or audio recordings of either conversations or presentations are impossible to quickly scan, and it’s more difficult for the person consuming the information to backtrack or skip around as needed. Email or instant messenger conversations are less formal and rigorous than documents by convention, so they allow for glossing over areas where deeper thought and investment is essential. Put simply: creating documents forces a manager to codify thoughts or ideas into an artifact that is easy for others to parse at any point down the road, with an effectiveness that no other process can duplicate.

I didn’t realize the value of written documents until I started working at Amazon almost a year ago. It’s very common at Amazon to walk into an hour long meeting and spend the first 20 minutes in silence reading and marking up a hard copy of a particular document, and spend the remaining 40 minutes discussing it. Initially I found that odd, until I went through the exercise of preparing my first long range planning document for my team and getting it iteratively reviewed by my team, peers, and various levels of my management chain. It took a lot of work, but all of that work ended up being hugely beneficial. We spent extra time meeting with customers to update requirements and get product feedback, held brainstorming sessions with team members and senior engineers who were interested in the space, and did some analysis on the cost of operations and ways that we could optimize some of that overhead. The final product was a 6 page plan that I could hand to anyone and rest assured that after a few minutes of reading they would have a great feel for what my team is up to, and why.

As a quick aside, this is a great example of why I previously wrote encouraging both software developers and managers to change companies/environments over the course of their career. There are a lot of things that I learned at Microsoft that I never could have learned at Amazon. There is an equally long list of things that Amazon does really well that I wouldn’t have learned anywhere else. Throwing yourself in a totally different neck of the woods provides a unique opportunity to grow in areas that you couldn’t have developed by staying put.

Back to documents. To clarify, I’m not talking exclusively about technical documentation like functional specifications, design documents, or test plans. I’m more focused on things like vision documents (which direction things are headed), long range planning documents (the nitty gritty on how to move in that direction), and documents about things like employee growth or promotion readiness. The neigh-sayers will argue against the value of these kinds documents because they aren’t part of what ultimately ships to the customer: the bits and bytes that get burned to a disc or deployed to a server somewhere. I would argue the exact opposite. For example taking the time to produce a long range plan that you can hand to engineers, customers, and partners can help you avoid building meaningless features, and help customers and partners give earlier feedback on where you’re headed. Similarly, taking the extra time to prepare a document evaluating an employee’s readiness for promotion is a great way to keep that employee apprised of growth areas, ensure that the employee is happy in their career progression and nip problems in the bud, and in the end save you from reduced productivity while back-filling for the attrition of an unhappy team member.

So without further ado, here are a few tips that I think will make you better at producing high quality documents:

Define your audience before you start.

In most cases it’s not possible to effectively address multiple audiences in a single document. Before you put pen to paper, define your audience. If the audience seems too broad, consider writing multiple documents instead of one. For example if you’re writing a document that tells what your team will deliver over the next 12 months, it may be appropriate to have 2 flavors of the doc: one for your management chain, and one for your customers. Your managers may want to know some of the dirty details like how much time your team spends on operations or how much test debt you need to backfill, but your customers may only care about what new incremental features your team will deliver. I’ve also seen cases where authors don’t define their audience right out the gate where the end result is a document that’s not really meaningful to any group of people.

Make bold claims. Don’t use weasel words. Be specific about dates.

Weasel words kill the impact of a document, and are a mechanism to avoid hard thinking or research that needs to happen. Consider a sentence like “Implementing this feature will represent a significant win for customers.” The sentence begs the questions: what feature, how significant, and what kind of win? Now consider the impact of rewriting it to “Implementing the features to allow multi-tenancy will allow customers to reduce the size of their fleet by 50%, resulting in a million dollar reduction in TCO.” Note that getting from A to B requires a lot of research, but the result is a statement that is much more impactful and makes it easier to gauge the value of the feature in question.

It’s equally important to be specific about dates. For example when you read something like “The feature will be completed later this year”, you should automatically ask the question: when this year? Are we talking next week, or late December? If my team has a dependency on your feature, I’ll need some more granular deets. If it’s impossible for some reason to provide a date, then provide a date by which you’ll have a date.

Finish Early, Allow Bake Time

This is critical. If your document is due in 3 weeks, plan to complete it in 1. Before you write the document you should identify peers that you want to read it, ping them to be sure that they block out time to do so, and then be sure to get them a copy on schedule. Consider iterative rounds of reviews with different groups of people that are stakeholders for the document. For example if you’re a line manager creating a vision document for your team you may want to start by getting it reviewed with a few of your peers and senior engineers, then take it to folks up your management chain, and then review the document with a few key customers. In my experience the resulting document is often drastically different (read: drastically better) than the original version.

Review, and review again. Use hard copy.

On a similar note, review your work often. Don’t write a document in one shot and call it good. When you finish it, step aside for a day and then read it afresh. Print the document out and review it in hard copy, pen in hand (and then go plant a tree). Staring at a piece of paper puts your brain in a different mindset than staring at Word on the computer screen. When you’re staring at your screen your mind is thinking rough draft, or work in progress. When you’re staring at ink on paper your mind is thinking finished product. You’re more likely to be a good editor of your document in the latter mode.

Conclusion

This isn’t an exhaustive list by any means, but it does include the tips that I’ve personally found to have the biggest impact on document quality. At some point I may put together a follow up list with some additional ideas on writing docs that I’ve excluded from this post. I personally apply these ideas to everything I write, including blog posts like this one. I hope that you find this helpful, and if you have additional ideas on either the value of documents or how to produce great ones I would love to hear them in the comments!

Love to Code (& the Goals of an Engineering Manager)

Some time ago, I published a blog post entitled “Love to Code”. The post was loosely inspired by a blog post from Jeff Atwood and another by Joel Spolsky, only my post was specifically advocating that people who *manage* Software Engineers should love to code. In hindsight it didn’t offer much in the way of interesting content; it was essentially an emotional appeal for managers to stay in the weeds and keep their hands dirty, because intuitively as a manager I felt those things made a difference.

In the time since, I’ve crystallized my thinking on both 1) the goals for an Engineering Manager (and I’m using that term loosely to mean “anyone who manages engineers”, whether it’s a small team or a large organization) and 2) why an Engineering Manager needs to love to code and stay technical to achieve those goals, and I figured that it made sense to go and touch up the old post with some of my more recent musings. In my mind the primary goals of every Engineering Manager are to increase team engineering throughput and channel that throughput in the right direction by:

  1. Mentoring and growing engineers on the team.
  2. Hiring (and occasionally firing) engineers so that the team is staffed with the right number and mix of people.
  3. Organizing engineers on the team to minimize friction and execute on the product vision.
  4. Directly contributing engineering horsepower when appropriate/necessary.

Note that I’m not claiming that this is an exhaustive list of goals, and in many contexts an Engineering Manager may have a many other goals in addition to this set. For example as an Engineering Manager on the Service Availability initiative at Riot Games, I spend a lot of time thinking about the roadmap for the technical products that we’re building and thinking holistically about our company-wide hiring strategy for engineers (which are related to, but not identical to #3 and #2 in the list). I am claiming that this list is as close as it gets to a lean set of goals that apply to managing Software Engineers in any context. I would argue that none of those goals are fully achievable by a manager who isn’t technical or doesn’t spend some time doing engineering work, and I’ll briefly explain why.

Mentoring engineers requires some measure of empathy and understanding on the part of the mentor and respect on the part of the mentee, and those things are best established by spending some time shoulder to shoulder in the trenches. The process of hiring engineers involves making a call on a candidate’s technical chops based on a very thin slice of data, and a hiring manager will make better hiring decisions if she is doing engineering work because she understands the nuances of what it takes to be successful. The effects of Conway’s law dictate that teams will produce software that mirrors the shape of the organization, which makes it vital that managers driving the discussion on how to best organize are familiar with the technical domain. And finally, every team will go thru crunches where an extra set of experienced hands on deck can make the difference between shipping the product on time or missing deadlines.

The skeptic will argue that each of these things can be outsourced to others (for example to Senior Software Engineers on the team or elsewhere in the organization). To be clear, I don’t fully disagree; goals are fluid and both the priority and ownership of the goals may change based on context. I fully acknowledge that in large cross-functional organizations at some level, a leader can’t be an expert in every function. As a brief aside, this is why I think that an organizational structure like Riot’s “matrixed” model is more effective (which probably warrants a post of it’s own). I will claim that over the course of a career, Engineering Managers who stay technical, love to code, and focus on this set of goals will be far more effective than those who drift into “pure people management” territory and cross-their fingers, hoping that others can fill in the gaps and help them to accomplish goals that they aren’t equipped to deliver on.

Being A World Class Software Development Manager

Over the past few years I’ve managed 3 software development teams at 2 very different companies and I’ve learned a lot in the process. I also read several blogs on software development somewhat religiously and I’ve liberally borrowed good ideas and added them to my toolbox. I’ve witnessed amazing managers as well as ineffective mangers, and I’ve spent time pondering on what differentiates the two. I don’t consider myself a guru on effective software development management or anything, but I thought I would share my thoughts on some traits that I would look for if I were hiring a software development manager to work for me because I think that a manager who exhibits these traits has the greatest chance of success.

Be a Computer Geek

Why does it matter? Because geeks are drawn to fellow geeks. Before I went into management at Microsoft I was consistently drawn to teams who were led by someone who I respected not only as a leader, but also for their technical chops. I knew that I could learn more from those sorts of people. I also felt more confident that my geek manager would understand and help contribute to the correct technical direction for a product and would be more prone to allocate time to do things the right way. I’ve always had a special respect for Scott Guthrie because he maintains a technical blog while operating as a VP. When ASP.Net MVC was new and I was searching for a tutorial I stumbled on his Nerd Dinners post which is pretty much the canonical search result for the topic and I was in shock: here’s a dude that manages more people than I ever will and he’s really taking the time to get to know the tech! That’s the kind of person I always want to work for and it’s the kind of manager that I want to be. Michael Lopp (aka Rands) does a great job providing his own thoughts on managing nerdsand providing some additional context on why it matters.

So how do you become a geek if you’re not one already? Allocate time to read nerdy stuff, every day. Keep coding, if you don’t have time for it in your daily job go take classes or work on a side project (even if it means waking up at 5am). Participate in team code reviews, I try to carefully review at least 1 out of every ~10-15 or so changes that my developers are submitting for review to let them know that I care and to encourage both thorough reviews and a high bar when it comes to code quality. Follow nerdy technocrats on Twitter or Blogs. Read a book on Operating Systems or Compilers. Technology is changing so quickly that not intentionally allocating time to immerse yourself in it will render you obsolete in a hurry. There are plenty of non-technical people who are competent managers that can lead a content team into oblivion because they can’t see the correct technical direction to follow. There are relatively few people who are both competent managers and technical rock stars who can both lead a team and provide the correct technical direction to make a team both happy and really successful.

Manage Projects that you Care Obsessively About

This one is a bit loaded because in the real world you can’t always pick what the teams that you manage are delivering, but your odds of cranking out a world class product are exponentially greater if you really believe in what you’re doing. I don’t just mean you think it’s mildly interesting, I mean you think that it has the potential to change your company (if not the world) in some tangible way that excites you. If you really buy into what your team is working on you’ll spend more time working, you’ll lay awake at night when you can’t sleep iterating on the technical vision for the product that your team is creating, and your enthusiasm will show through to the people who report to you. It sounds cheesy but it’s true, people won’t work hard for someone who doesn’t believe in what the team is doing.If you think that you’re working on something that isn’t exciting but you’re skeptical about your ability to move, you probably need to push yourself and do some shopping around. Towards the end of my time at Microsoft my team was re-org’d (and essentially re-purposed) to work on some things that I wasn’t as excited about. Despite getting good reviews my entire time at the company I had this sort of skepticism about my ability to interview well and move around either within the company or externally. It wasn’t until a recruiter contacted me randomly after stumbling across my resume on LinkedIn and described a technology that sounded exciting that I finally pulled the trigger and went through the interview process. And guess what? I didn’t end up getting an offer. In his shameless Google plug Steve Yegge does a great job describing something that he calls the “anti-loop”: an interview loop with a set of people that even the most qualified candidate will not survive, and something that I’ve personally observed while hiring. I bring up the anti-loop because it’s mere existence means that not getting an offer your very first time thru the process shouldn’t in any way discourage you from continuing to hunt. Shortly after my initial failed loop Amazon contacted me about a position to manage a team to work on something that I felt could completely change the game for how software development is done, and an interview loop later I had a job offer. Software Development is a weird industry in that the skills to be successful at the job aren’t necessarily directly related to the skills necessary to successfully interview for the job, so if you’re not interviewing at least once per year to keep your skills sharp you may want to consider doing so. Regardless of how often you’re interviewing you shouldn’t let yourself be paralyzed by fear of the unknown, it’s an eye opening experience to immerse yourself in a totally foreign team/organization/place and it’s a huge way to both promote personal growth and position yourself to work on things that excite you.

Surround Yourself with Amazing People

Sounds obvious, but I really can’t overstate the point. One of the most important assets that you have as a manager is your network of connections in the industry. LinkedIn and the competitive nature of talent acquisition in the industry has changed the game, and if you’re not adding talented people to your network that you can call on when your team needs to quickly staff up then you’re putting yourself in a hole. Talented people change teams and even companies fairly frequently today and as a manager you will be faced with situations where you have to hire on a time crunch. Even the greatest sourcing strategies can’t substitute for firsthand knowledge of how good someone is and having a rapport in place, which means you need rock stars in your network that enjoy working for you and may be willing to follow you to work on new things. A side effect of this phenomenon is that if you’re not changing teams/jobs every several years then you’re probably not adding new talented folks to your network as quickly as you could be, and you may either want to look around at other opportunities or consciously try put yourself in positions to regularly form relationships with people outside your network.

The ability to build a good team and hire effectively is the single most important trait in a software development manager and it requires both a solid network and being a great interviewer, a separate topic that has been covered in a lot of detail all over the place and that I will likely touch on in a separate post. The best manager in the world cannot succeed without an amazing team, and a bad manager who inherits a good team will do better than a good manager who can’t hire (in the short haul, until the talent leaves).

Clear a Path for Those People

After building a great team a manager’s job comes down to clearing a path for those people to succeed. Think of your team as a pipeline for delivering goodness, and your job is to point the pipe in the right direction and remove friction that can slow the speed of the goodness. Aiming the pipeline requires crafting clear and concise vision documents that the team buys into within the parameters of the organization. There is no substitute for being able to write great documents, they are one of the primary deliverables of any good manager. Documents stand the test of time in a way that a Power Point presentation doesn’t because it can’t be read by anyone in any situation without the context of the presenter. If you can write an effective document to describe what your team will be working on over the next 12 months with specific dates for delieverables that both meet customer requirements and are realistic based on team bandwidth then you already possess an underrated skill that many managers lack.

Removing friction from the pipeline means a variety of things depending on the team, organization, and product. It doesn’t necessarily mean getting rid of as many meetings or as much process as possible. It does generally mean things like putting an effective process in place, weighing in on technical design, and providing motivation to folks on your team. There are plenty of articles discussing why money doesn’tnecessarily directly contribute to job satisfaction or effectiveness over the long run, as a manager it’s your responsibility to know how to keep your employees satisfied and motivated. Let your employees know that you genuinely care about them by asking them how life is going outside of work. Setup effective 1:1’s on a weekly basis, and be sure that you’re not just covering things that are tactical. Be invested in your employees career growth. Setup bi-weekly staff meetings where employees can comfortably ask questions about the direction of the team or provide feedback on the process.

Install a Lightweight Process and be Flexible

One of the most common mistakes that I see managers make is a “my way or the highway” type approach when it comes to team process. Scrum has obviously become the hawtness that many teams use today. Scrum was developed for manufacturing. Software development is not manufacturing. I don’t mean to say that scrum is bad by any stretch of the imagination, but it works well in some situations and fails miserably in others. On the last team that I managed at Microsoft we operated on a fairly strict scrum model. We kept a super detailed product backlog that we groomed regularly. When we pulled items from the product backlog into the sprint backlog during sprint planning we had a great idea of how much bandwidth we had, what load factor we were operating at, and exactly what we could get accomplished. We did a pretty good job scheduling demos at the end of sprints, and we always held retrospective meetings and carefully considered and integrated feedback from the team. In the context of our organization we were operating as model citizens, and it worked well.

The first thing I realized when I came to Amazon is that if I ran my team the same way my developers would probably all commit mutiny and the team wouldn’t run effectively. The culture is different and the product that we’re working on happens to be in a very early “protype-ish” phase so requirements are changing very rapidly. It’s taken a bit of trial and error but we’re starting to really hit our stride on a hybrid scrum model with mini weekly iterations within each sprint. The scrum purists would roll over in their grave, but I’m alright with that.

When a manager takes over a new team the first step should be observing how the team has run in the past (unless it’s a brand new team). The next step should be investigating how other effective teams within the organization are operating. The last question they should ask themselves is how their past experiences can play into the process within the context of the new team. The goal in the entire excercise should be to build a process that is as lightweight as possible while effectively meeting the requirements for partners and customers and keeping engineers happy. If it sounds like a lot to ask, it is. The odds that you’ll get it right on your first try for any team are low, which is why it’s important to approach new team processes with humility and a willingness to be flexible. The last thing you want to do is create what Jeff Atwood aptly describes as micromanagement zombies by installing an over restrictive process just because it worked at your last gig.

If you’re nailing everything mentioned in that list I’m willing to bet that you’re enjoying work and leading a highly effective software development team, and that you’re probably a better manager than I am. Alternatively if you disagree I would certainly love to hear your feedback so that I can be convinced and update my list accordingly.