AFTER YOU DEFINE A great product idea and generate strong organization support, you need to pull together a team that can build and ship that product. Building the right team is the most important thing you can do, after choosing the right user problem to solve. A brilliant team can also end up being a durable competitive advantage. Most important, a great team helps eliminate problems in all the remaining steps of your software development.
Think about it: if you have a terrible designer, you’ll end up reworking the same feature three times as you get randomized by user feedback. Bad systems design from a second-rate development lead will cause bizarre outages that will negatively impact users and cause your developers to stay up late, cursing each other and their pagers. And a bad product manager—they’re the worst—will constantly randomize your team with a poorly thought-out set of bad ideas.
On the other hand, a great team is fun, makes you feel like you can accomplish anything, and will lead to lifetime friendships and profit. You must have a great team, and you can play an essential role in team building regardless of your explicit title. Here’s how to do it.
To start a team effectively, you must find engineering, product, and design leads with whom you can work well. When you find these individuals, treasure them. Write them poems, buy them candy, and offer to wash their cars. You are only as effective as your engineering team, so finding a leader who can run a well-oiled engineering machine will radically offload work from you and substantially accelerate your other efforts. Throughout the industry, you’ll find that the same people work together across businesses and projects for precisely this reason.
It is impossible to care too much about your team, its quality, and the happiness of your team members. Read Beverly Kaye and Sharon Jordan-Evans’s book Love ’Em or Lose ’Em (Berrett-Koehler) and practice what it preaches, even if you’re not a people manager. It talks about how to retain your best people and get the most out of them. Leads can have a substantial impact on the careers and happiness of their teammates by doing things like directing the right projects, problems, or recognition to people who need it. Love ’Em or Lose ’Em will give you great ideas for actions you can take and techniques for figuring out what actions will work.
Frequently, the job of a team lead is too much work for a single person to accomplish. The job is nearly always too much for any one person to do it well. You are going to need to hire an engineering manager, a product manager, a program manager, a project manager, or some combination of all four. For brevity, let’s call this person a PM.
PM hires are the most critical hires you can make. Hiring the wrong person to be a PM on your team more than sucks—it’s like jabbing a salted knife into the collective kidney of your engineering team on a daily basis. The wrong person can change the product direction for the worse, hide information from you, delay tasks that would otherwise be done poorly but quickly, and will cause great angst within an engineering team. Needless to say, hire carefully, and err on the side of not hiring a PM.
If you need to hire a PM, you should start by defining the role you’re hiring someone to perform. Generally in the software industry, there are program managers, product managers, project managers, and engineering managers. The actual definition of each role varies based on the company, but the following sections give some guidelines on how the roles differ.
I once interviewed for a program manager role at Microsoft that I ultimately declined. During my interview I was asked, “What does a PM do?” That this would even be an interview question speaks to the difficulty of the job! My answer? “A PM ships software.”
More specifically, a program manager focuses on integrating different teams and job functions. Josh Herst, the CEO of Walk Score and a former venture partner at Madrona Venture Group, once said, “Program management is a glue-and-grease role. You pull disparate functions together so that the machine can work and then grease the machine to make it work better.”
Another way to look at program management is that it is a technical role with less business focus than product management and less project focus than project management. The deliverables a program manager will produce are therefore more ambiguous than some other roles and the focus on “glue and grease” is manifest.
Product managers traditionally focus more on the business side of software. There are even product managers who don’t work on software. These product managers are typically MBAs who focus on brand management, pricing, go-to-market strategies, and so on. Your software product manager will do these jobs and will help prioritize feature development by attempting to speak with the voice of the customer.
Product managers at Google do pretty much everything but write code. That said, I know of more than one product manager (including myself) who wrote code while at Google. Product managers at Facebook and the newer Bay Area startups tend to have the same responsibilities, mainly because the startups and Facebook seem to be largely staffed by ex-Googlers.
Project managers, or technical program managers as they’re known at Google, focus primarily on the schedule and coordinating team efforts. They ask for estimates, they identify dependencies, and they figure out how to get more done in less time. Want to know if having great project management chops is worthwhile? In 2007, a truck carrying 8,600 gallons of gasoline crashed on the ramp connecting I-80 to I-580 in California, destroying a major artery and sending local traffic into a state of intense disarray.[4] Initial estimates to repair the damage exceeded $10 million, but gutsy C. C. Myers, Inc., came in with a bid of just less than $900,000—and a clause that said they’d be paid a $200,000 per-day bonus for every day they came in ahead of schedule. Given that the state was estimating an economic loss of $6 million per day, this seemed like a good deal to California. The C. C. Myers crew, through a combination of brilliant project management and good old hard work, beat the target date by a full month, earning a 500% ($5 million) bonus.
Engineering managers are frequently coders grown older. The best “eng managers” are those who have been promoted into the role because they love their teams, understand people, know how to ship, and want to build brilliant products. The worst are those frustrated engineers who only wanted more control and more money. You know who you are. Cut it out.
Engineering managers may or may not have product managers, program managers, project managers, or even technical program managers working for or with them. Some engineering managers see their primary role as maintaining the happiness of the engineering team. Others see it as maintaining engineering quality through hiring, process, and other tools. Still others see their role as similar to a product manager, but with access to the engineering resources to build the stuff they want to build.
Every engineering team will have an engineering manager, but not every team will have a product, program, or project manager. Therefore, if you have one of these other titles you must partner well with your engineering manager, because if your engineering team is unhappy, unskilled, or lacks a quality process, you’ll have a very hard time shipping. Similarly, if you’re an engineering manager, finding people who can support your weaknesses and enable you to ship faster and better is very important.
Hiring leads for a team is very hard. I believe that Google, Amazon, Microsoft, and similar companies are terrible at finding great leads through the interview process; you can see this in how candidates are evaluated. For example, at Google some of the strongest inputs into hiring decisions are the candidate’s GPA, the schools he or she attended, and internal referrals. None of these factors is part of the interview process, which should tell you something. At Amazon, candidates must be very technical, but the questions they’re asked are trivial to answer with a little studying (more on this in Chapter 9). I think that the process of hiring leads is largely broken, but it’s a major part of your job as a lead, so you need to know how to do it. There are five major rules for hiring leads:
Hire people who are smarter than you.
Hire people who understand they are not the boss.
Hire people with clear, data-driven communications practices.
Hire people who are quantitative.
Hire people with gumption.
First, you should hire people who are smarter than you. However, Mike Smith, a former Google GPM who used to coordinate product management hiring in the Seattle/Kirkland Google offices, says, “This statement ignores basic human instincts…[you want] to exert control.” Therefore, you must hire only people who are smarter than you if you are willing to empower them and trust them to be team leads in their own right. I honestly believe Eric Schmidt both espoused and lived to this principle. I heard him say, “Thank you for ignoring me; that’s why we hired you.” Sadly, he said this about someone else—I didn’t have the guts to ignore Eric because he was really much, much smarter than I. Someone else hired me; that’s how I got hired. If you can hire people who are smarter than you and empower them to ignore you, read on. Otherwise, don’t hire anyone. Just do the job yourself.
Since you’ve decided to hire team leads who are smarter than you, you’re going to want to know how to assess brains. I triple-dislike the Microsoft approach to asking “brain teaser”–type questions because I think they don’t actually test smarts. For example, here’s a real question I was asked during an interview at Microsoft:
Q: You’re in a boat, and you’re holding a big rock. You throw the rock into the lake. What happens to the level of the lake?
A: It goes down because the rock in the water displaces only the volume of the rock, rather than the volume of water equivalent to the mass of the rock, which is what happens in the boat.
Q: <long pause> Wait, had you heard this before?
A: No, but I studied engineering…?
The only interesting part of candidates’ responses to a question of this nature is what happens to them if they get stuck. It is a good sign if the candidate can get unstuck without help. Beyond that, people’s ability to think their way through a brain teaser has little to do with their ability to get to root cause, measure their business well, or think about competitive markets. Please don’t ask these kinds of questions.
To those of you saying, “Yes, but what if the stone was pumice and could, in fact, float?” I say, you’re missing the point.
The best way to test raw smarts is by checking references. Ram Charan, coauthor of Execution: The Discipline of Getting Things Done (Crown Business), makes it a point to check his candidate’s references personally. Great PM managers I know do the same thing. If it’s too early in the process to check references, the candidate’s résumé is a good enough proxy. A strong GPA at great schools is an additional predictor of success in the role, but it is not the only indicator.
Substantial launches with real deliverables is a key indicator of success; after all, if we’re trying to achieve shipping greatness, a history of shipping should count for a lot. A leadership candidate who has a long, wishy-washy résumé is almost certainly a no-hire, but a lead with a single-page résumé that highlights product releases and their monetary or user impact is a “must interview” candidate.
OK, so you’re not yet convinced. You’re ready to present the classic heavy-marble problem (find the heavy marble out of 23 otherwise equally weighted marbles with just a balance) or some variant of it. Let me help you out. Potential candidates listen up: the answer to this and all questions in this class is a binary search. It is Log N K fast, where N is 2 for splitting the marbles in half and 3 if you use three piles.
Now go ask for the candidate’s GPA, check references, and don’t ask any more silly questions.
You should hire people who can be Not-The-Boss even if you are hiring an engineering people manager. You want your engineering team to do what they think is right and lean on the engineering manager for support, not orders. The only way to know that a PM understands the Not-The-Boss requirement is by meeting with the candidate face-to-face.
When I interview a candidate face-to-face, I pose a question I borrowed from McKinsey and Company: “Tell me about a time when you changed someone’s mind, and what techniques you used.” I listen for information about how the candidate responded to not being in charge. I look for evidence of collaborative decision making (see Chapter 11). I look for data-based arguments (see Chapter 6) and smart escalation (see Chapter 11 again). If the candidate says, “Well, I just convinced the tech lead to try it,” that’s a good indicator that this lead is used to being the boss.
Here’s an example of what happens when you hire a bad communicator:
Me: Is <redacted> done?
<redacted also>@amazon.com: Yeah.
Me: Like, tested and running?
<redacted also>@amazon.com: Oh, no, but it looks mostly like Java.
True story! I need real, concrete answers from leads, so when I ask a specific follow-up question, such as “How did you convince Larry to approve your launch?” a bad answer is “We talked about it, and he kind of came around.” A great answer is:
First, I scheduled a meeting with the stakeholders to get them onboard. Next, I had my SVP send a note. After Larry was presold with that note, I had a 10-slide deck that I presented to Larry and we listened to his feedback. We were able to address his concerns in that meeting and moved forward.
Note that this latter answer is brief. It is specific. It has a beginning and an end. It speaks to what the individual did and also to how the individual worked as part of a team.
A good technical leader should be able to do math on his or her feet. Candidates who use numbers, even when referring to the number of slides they had, get good marks from me. I occasionally ask candidates market-sizing questions, but my goal is not to assess if they can segment a market, but rather to see if they can make good approximations and do math on their feet. A typical market-sizing question might be “What’s the market for a new smartphone in the US?” Most MBAs can answer this type of question in their sleep, as they practice them before they go out for consulting interviews. Here’s how I’d answer the new smartphone market-size question (I doubt the answer is right, but you can see how it demonstrates that I’m not afraid of numbers):
There are 350 million people in the US. I estimate that of those 350 million people, folks between 12 and 75 have need for a mobile phone. That’s probably a total US mobile market of about 300 million users, give or take.
Now, the market for smartphones is different. Let’s segment the market into callers, social media users, and business users.
Social media is most dominant from 12–30, so that’s about 30% of the market: 90 million. Add to that estimate the business users, who are, say, 50% of the 30–60 market, and you get 50% of an additional 30%. Half of 90 million is 45 million, so that’s an additional 45 million users, for a total of 135 million users. Let’s put the remainder of those 300 million users into callers—we don’t care about them right now.
So 135 million might want a smartphone. I think Apple is planning on shipping 20 million iPhone 5s out of the gate, and Android will be double that, so it checks out roughly right.
If we are introducing a new phone, we probably are selling to two major groups: new smartphone users and upgraders. So, if you assume that there are probably 40 million iPhones and 80 million Android phones, that’s 120 million smartphones deployed, leaving 15 million as new users. Of the 120 million phones, figure a three-year upgrade cycle—that’s conservative. So, one-third of those 120 million will upgrade in a year. That’s 40 million.
In other words, I think you have a potential market of 55 million phones in your first year—40 million upgraders and 15 million new users. Now, how many phones you sell is a very different story! Isn’t this mobile business fascinating, how fast it is growing?
That is how you answer a market-sizing question. Start by making a numerical assumption. Check your assumptions with other data as you go along. Use round numbers and whittle down your estimate using rational market segmentation. Arrive at a real number. Finally, show your enthusiasm, even though you probably don’t want to work at a company that asks this type of question.
Leaders are frequently the driving force behind your team, and if they don’t bring energy with them your cause is lost. If one goal of your mission statement is to inspire (see Chapter 1), the person who delivers the mission best would be inspirational, and inspiration comes from energy. One sign of good energy that you might be able to see in an interview is a novel idea, because candidates who are willing to invest a lot of energy thinking beyond your specific question are likely to do so with their own team. I also look for excitement around problem solving. The design problems I ask are all very interesting to me; great candidates get excited about the problem with me and can explore the problem space.
It’s not unusual for larger companies to acquire a smaller company at the initial phase of the project. It’s a prebaked team, isn’t it? It’s also not unusual for a software project leader to seek out potential acquisitions in order to solve a problem or get to market faster. Acquisitions are rarely easy, so it’s important to know how to handle them properly.
There are generally four reasons why you might consider acquiring a company.
- Intellectual property
You can use the technology, content, or patents that the company built.
- Talent
You can use the people the company hired.
- Customers
You can use the company’s customers to accelerate the growth of your business.
- Defense
You’re buying the company so somebody else can’t.
Of these four reasons, Mike Smith, a VP of engineering at Disney who has experience with acquisitions at Disney and Microsoft, says, “Hope to get two out of the four. Expect one. If you’re being sold on more than two, nine times out of ten you’re going to be disappointed.”
Before you even consider acquiring technology or content, you need to do the basic math of build versus buy. The math is truly basic: how many engineers for how many months will it take to build, test, and ship similar software? Multiply this number of engineering months by the cost of a fully loaded engineer for a month. Subtract the cost—measured again in units of engineering person months—of integrating the company’s intellectual property. The result is how much you should be willing to pay, assuming time to market is not critical.
However, time to market is always critical, so do some more rough math to figure out what the value of potential sales is if you are selling your software after the acquisition and integration is complete and before you would otherwise ship your own software. Or, pick six months’ sales because that’s probably equivalent to the revenue you may gain. Add this figure to your first estimate, and you’ll have the full value of the deal.
If you think that you can get to a deal for a number less than what you just computed, then it’s reasonable to move forward.
Next, you need to look carefully at the software you will acquire. You can’t trust that the company’s code is good. Well, maybe you can trust that it’s good, but you need to verify that it is. You need to get a senior engineer from your team who will not work with the business in the future to review the code. Startups get very twitchy about exposing their secret sauce, and your lawyers are going to get worried about “tainting” your team if the deal doesn’t go through. But there’s no help for it. You must have someone whom you and your team trust review the code and architecture. If you don’t, you’re buying a rental car without taking it to a mechanic first.
If you’ve reviewed the code and it looks OK, make sure you can put together a plan to integrate the team and the technology. Like most projects, the integration project will take longer than you expect. Unlike most projects, however, it will take much longer than you expect because you have new people, foreign servers, different software licenses, and all sorts of undocumented details to deal with.
Talent acquisitions are the trickiest of all acquisitions. This is not surprising, since they’re all about people and people can be tricky. You must evaluate people like you normally do: interview them. The more people you interview, the lower your acquisition risk will be, because you have more complete information. Conversely, the more people you interview, the more you disrupt both businesses. You must conduct your interviews carefully.
A caveat here: don’t interview people without them knowing that it’s an interview. I know of at least one case in which this happened, and it backfired. The deal team ended up redoing all of the interviews, and it soured the deal.
Interviews will also help you understand where the employees fit into your organization. I use three core buckets for talent:
- Key individuals
These are the people who keep the lights on, and without them, you’d have to backfill immediately. They might be hard to backfill because their domain knowledge is so deep.
- Good hires
These are people you’d happily hire into your current business. They are A-class candidates, but you could also spend a few months hiring on your own and land a similar candidate.
- Surplus talent
These are employees who don’t meet your hiring bar, so you’re going to do one of two things with them: a) put them on contract for a period so you can transition them out, or b) terminate their employment. This may seem like a hard transition, but this is the reality of acquisitions.
Talent acquisitions of more than a few people are very hard because of the process, the interviewing, and the subjectivity of the deal valuation. They can also be very difficult to integrate. Mike Smith shares a frightening anecdote from his time at Microsoft:
I drove the acquisition of a company called Conversagent (to be Microsoft Windows Live agents). In evaluating the talent, it was clear that there was a good need to hire between 20–30 additional engineers to get the scale that met the business needs. The acquisition was approved with that constraint, but then finance decided that it would sit on releasing the headcount to be hired against. For 9 months. Core talent left at 12 months, with no backfill. The acquisition failed and is now worth less than a tenth of its purchase value.
This story shows how important it is to get all parties, including HR, legal, and finance, bought into your talent acquisition before you close the deal.
If you make $2 per user over the lifetime of that user and you’re going to acquire a company with 10 million users, you should be able to make $20 million bucks, right? Wrong. You’re only going to make a fraction of that. What fraction you make depends on what you do with the business.
If the business you intend to acquire is self-sustaining, you can keep it running largely as is and attempt to upsell those customers to your new product. However, you’ll probably have a pretty low take rate. If your take rate on those 10 million users is about 20%, the deal is worth less than $4 million.
If you plan to shut down the business and convert its users into your own, you will likely pay substantial costs to shutter the business and you’ll lose customers along the way. You might estimate that a deal done this way is worth about 50% of the potential value, or approximately $5 million.
Because these numbers are so low, you’re most likely to look at a customer acquisition deal as a sales accelerator for situations in which there’s a highly competitive market and getting big fast matters. If you’re in one of those businesses, you might want to get out now before the stress kills you. Or at least switch to Tylenol, because your stomach will thank you. Assuming you don’t get out, you’re going to value this deal by estimating your sales increases, which is highly speculative math.
No matter how you value this deal, make sure that you’re using the right baseline data. That means looking at logs. Look at not just impressions and signed-up users, but “seven-day active” user counts. You’re after repeat customers, so you want to measure returning users and engagement (time spent on the site or using the app). Have your team review the log data, or at least understand the systems that are generating the reports, whether those are Webtrends or Google Analytics.
I have not led a defensive deal. In my opinion, they’re not very nice and smell of fear-based decision making. If you have the pockets to do a defensive deal, please don’t be evil when you do one.
If you’re even considering doing a defensive deal, you probably need to think about what monopolistic practices are. “I’m not a lawyer” is the first thing you should get used to saying because at least your comments will be in context. I’m not a lawyer, so I won’t tell you what not to do.
Here are some final tips and warnings to keep in mind when you’re considering acquiring another company.
Embedding some of your senior staff into the acquired team works great because it brings the culture, practices, and policies of your business into the new team. In addition, a good, scrappy development lead will unblock the new team and help them be much more efficient more quickly. Your new team will be more likely to be happy as a result, because they will be productive, and productivity breeds happiness. You should budget approximately 1 senior engineer for every 10 acquired engineers. If you don’t have anyone you can spare, then you need to look for ways to pull talent off of the new team and use them to backfill this dev lead so he or she can join the new team. It’s that important.
Don’t underestimate the importance of culture fit and the time it takes new people to figure out how to operate under your unique brand of insanity. To do so is to create an unruly group of engineers who are biding their time until the one-year mark is up and they can cash out their options. That’s a miserable way for those people to work, and it’s bad for the rest of your business. Make sure you get the new company well integrated into your old company. Embedding your best engineers into the new team is a great way to help this.
You need to know not only how you’re going to stick their servers behind your virtual IP, but also what you’re going to do with their brand and how their billing systems will work with your billing systems. Many acquisitions are less successful than they could be because the acquirer ends up paying a multiyear engineering cost to integrate the business. A clear plan makes transitions easier for teams, too.
It’s always a bummer to discover late in the game that the founder owes someone a million bucks. It’s not your problem, but for some reason, founders always want you to take care of them, so it becomes your problem. Having a good conversation about debts, liabilities, and any deals the company might have signed before you reach a number is very important. A good attorney will help you with this, but it’s best to do your own homework, too.
It’s pretty hard to work with a good engineering team in the best of times. It’s very difficult to work with a team that’s in another office. It’s approaching impossible if you add a 12-hour time difference to the equation. The situation is basically hilarious when you try to coordinate across mutually exclusive time zones like Sydney, Stockholm, India, and the West Coast of the US. I’ve led these kinds of distributed projects, and I’m giggling still.
Remote—or “distributed” in Google vernacular—teams are a necessary evil at this stage of software development. One reason you will use remote teams is that areas are known for their specialties and acquire like-minded geniuses. For example, Tel Aviv and Stockholm have video gurus. Romania has security geeks. Big distributed-systems brains tend to come from college towns like Pittsburgh and Seattle. More than 50% of Google’s employees work outside the home office of Mountain View. Facebook, Google, Ticketmaster, and an increasingly large number of Bay Area companies have all opened offices in Seattle, just as one example. US Immigration has made it difficult for some of the world’s top engineering talent to work from the US—but not for the US.
Given these industry trends, and your near-infinite need for brilliant engineering talent, you’re going to encounter a time when you think about working with engineers outside your hometown. It will be challenging, but there are some things you can do to make your life easier. Nine things, in fact:
Don’t rent an engineer—build an engineering team.
Overcommunicate.
Do not outsource design or PM roles.
Adapt to cultural differences.
Build clear requirements.
Suck up the time difference and meet anyway.
Establish great leads.
Travel a lot or barely at all.
Drink with the remote team.
Engineering projects are long term and complex, and benefit substantially from peer collaboration. The best way to embrace and leverage these dynamics is by building a team of at least three engineers who all share a charter. Three engineers amounts to what I call “critical mass,” meaning there are enough people that the team can power itself. The charter gives the team a sense of direction. It also helps the team make decisions autonomously, which is something you need when you have less direct oversight. For example, when a developer finishes one project or gets stuck, the charter helps inform what he or she works on next. Defining a clear charter for the team also helps them feel less anxious about their future.
There’s a truism I’ve noticed working with remote teams: the farther the team is from you, the more anxious they are. If you’re based in California, for example, New York will only assume something was miscommunicated, get on a plane, fly to California, and complain loudly. Even the best engineering teams in Sydney and India, on the other hand, straight-up panic. They’re so far away from the States that they assume they’re misunderstood, underappreciated, and kept out of the loop. The best thing you can do to ameliorate these feelings is to overcommunicate.
Use Skype, Google+ Hangouts, WebEx, and generally anything you can get your hands on to increase the quality of your communication with your remote teams. Because developers hate using telephones, reducing initiation friction is really important. One team I had at Google was split between Seattle and Mountain View. We bought small, dedicated videoconference units for each team so that we could quickly call the other team in for daily standups or random design discussions. This worked really well. You can do the same thing through Google+’s Hangouts With Extras.
It’s possible to make outsourced design work well, but you are leaving huge value behind on the table. A great designer will fix a multitude of problems you didn’t even know you had, and can do this best when he or she has full visibility into everything you’re doing. You can find more information on how to work with designers in Chapter 3. Do everything you can to hire someone internally and outsource only visual design.
Similar to designers, product, program, and project managers benefit hugely from being immersed in the team. For example, they may overhear snippets of conversations that expose miscommunication. They discover areas where engineering teams are blocked. They repeat your mission and strategy so that the team stays aligned. They build personal relationships with the engineering team that enable engineers to feel comfortable making task-size estimates. For these reasons and many more, I can’t imagine outsourcing a product, program, or project manager role.
I went through an eye-opening personal performance review cycle once. I worked closely with a female engineer who did fantastic work. We’ll call her Sarah so you can’t track her down. Sarah showed strong leadership and wrote great code, and I thought she had wonderful ideas and we made great product progress. I was a huge supporter of her promotion case. You know how this is going to end, right?
Sarah’s engineering director and I sat down one day, and he told me I had a problem. Sarah didn’t feel like I was listening to her. I was stunned. And this very smart Chinese-American engineering director explained something to me. He said, to paraphrase, “You should take into account two things: Sarah’s a woman, and she’s a Chinese-American woman. She has a lot of experience not being heard and not being able to speak up. And you’re a 6'4" white guy who talks really loud.”
Cultural differences are fascinating. I certainly shouldn’t treat or evaluate Sarah any differently because of her race or gender—that would be dumb, evil, and illegal. But in a parallel situation, where I’m working with a big white guy from Romania who has a weaker grasp of English than he has of C++, I might well choose not to use all my Ivy League words. That’s just good sense, and it might make sense to adjust the way I communicate for the unique audience that Sarah represents.
This is only one example of a cultural difference. I could go on and on. For example, I’ve seen teams in Zurich be far more concerned, compared to US teams, about getting to a “right” solution than getting a prototype built. My local team in Seattle found this infuriating. But when the Seattle team understood that this was the Zurich team’s approach and it would be OK in the long run, it helped us give the Swiss the space they needed.
You do not need to understand how each and every culture uniquely works, but rather to recognize that teams on the East Coast of the US are going to behave differently than teams on the West Coast, and teams on the West Coast are going to behave differently than teams in the UK. You must actively work to understand where you may have differences and then compensate. You can start understanding these differences by overcommunicating and looking for patterns in reactions.
New teams have some similarities regardless of where they are located. One such similarity is that they don’t really know what they’re supposed to do or why they’re supposed to do it. Remote teams are the worst, though, because they don’t have you sitting in the middle of their office answering offhand questions, repeating your mission to investors on the phone 10 times per day, and harassing your development lead about how critical your next deadline is. Since you’re not there, you need to provide a “virtual you” in the form of bulletproof requirements. If you do a good job with the product requirements document described in Chapter 2, you’ll be in good shape. While great requirements are critical for all teams, they are even more necessary for remote teams.
A 12-hour time difference stinks, but there’s nothing you can do about it. You have to absorb it in some way, because you need to have status meetings and one-on-ones, and sometimes you just need to take a half-hour of your life to listen to someone talk about his or her life. That half-hour isn’t for you, it’s for the other person, and it can be a bummer when you’d rather be watching The Daily Show.
I’ve only come up with two ways to cope with this problem:
Get a TiVo.
Work early mornings or late evenings, but don’t work both. Whichever works better for you, set up your meetings to always happen at the beginning or end of your day.
That’s all I have. You just have to suck it up. Communication and face time are important, and it’s easy to skip them when the timing is hard, so pay attention to how you spend your time and invest in your remote teams.
You may try to be everywhere at once, but you are only going to end up being at a few places, and you’ll probably be there late. Being a little ball of stress doesn’t help anyone, and the scotch you’re drinking to mellow out isn’t good for your liver. You need lieutenants in your remote locations. If you can, ship one of your best leads from your home office over to the new team for a month or so. Sending a great technical leader to embed with the team is a great way of transplanting culture and process, which is why I recommend it for acquired teams.
Establishing a local lead will eliminate at least a couple of late-night meetings for you, because that local lead will meet one-on-one with your home office engineering lead. Not only do these meetings help reduce the volume of technical conversations you participate in and increase space for cultural conversation, but they can also help reduce the time required to discover a crisis. For example, if you meet with the remote office on Monday, and your home office engineering lead meets on Thursday, your home office engineering lead may discover the crisis two whole developer days faster than you would have, because your meeting wasn’t scheduled until Monday.
If you talk to frequent travelers, you’ll learn that if you travel every other week, it gets easier. Traveling is still rotten, but it’s better, because you fly better classes, your bags stay packed, and your mileage status gets you through security faster. You stay at the same hotel consistently, and as a result you lose things less frequently. You learn how to eat well on the road and have a harder time avoiding the gym in the hotel.
The other simple travel trick is the one-day turnaround. I know it sounds crazy—go out and come back the same day—but it has great benefits for flights shorter than three hours. You sleep in your own bed. You don’t change clothes. You catch up on email on the plane. Ultimately, you’ll find something that works, but if you can convince yourself to get up crazy-early, you may find you like it more than you like hotel room coffee.
Traveling a significant distance every month or two just stinks. You would think that it’s less frequent and therefore better, but in many ways it’s worse.
I once spent some time in Korea pitching a major consumer electronics company on an opportunity to build some service-specific hardware. My business development colleague, Jake, and I went out to dinner with their biz guy and their engineering guy, who told us a fascinating story.
Many Koreans drink this vodka-like alcohol called soju. I did my best to like it, and anyway, I was sufficiently jet-lagged that I lacked the judgment to not drink it. The engineering guy proceeded to tell us that in Korea, many engineers have strong feelings but feel that they can’t express them in the workplace. In fact, the reason why the Korean engineers enjoy the soju so much is that they can go out with their coworkers after work, drink this stuff, and say what’s really on their minds.
The lesson here is that, in addition to respecting cultural differences, you should understand that different environments can expose different truths. Bars and restaurants are two of them (two of the best, if you ask me) and are enabled by alcohol.
It’s important to note that you don’t need to be a big drinker to have beer help you. While there may be some international protocol around business drinking, your engineering team is probably happy to drink around a teetotaler. They really want you to let them drink and tell you want they want. Oh, and they want you to pick up the tab, too.
Regardless of whether you have built a new team or were dropped from a high altitude into a train wreck to sort things out, you’re going to need to do two critical things: figure out what role you should play, and make the right first moves.
It’s critical that you figure out what your ideal role on this specific team should be. Some engineering teams don’t want any project management—in which case, you need to figure out how to do as little as possible but still track your project. Some engineering teams want you to focus on marketing, while others will invite you into technical discussions and will welcome your input if you’re sufficiently deep technically.
To figure out what your role on the team should be, you must be sensitive to what the team needs. You can check the pulse of the team through one-on-one weekly meetings with the team’s other leaders. Build relationships by meeting monthly one-on-one with each engineer on your team just to touch base. It’s also important to drive transparency into all your processes so you build trust. These actions will enable you to focus on doing things that only you can do and being a great servant to your team. They are also investments that will pay off during the challenging sprint to the finish.
There is one unique hiccup you might encounter at this point. It’s happened to me only once, but it was painful. You may figure out what the team needs and wants, but find that you’re not empowered to do what you need to in order to ship greatness. This could be because you’re being micromanaged, or because you’ve tried and there’s strong resistance to change, or a host of other reasons. Some of these problems are solvable, like teams being resistant to change. Others, like having leaders marginalize the job you believe needs to be done, are less solvable. When you hit a situation like this, you might consider joining a different team.
If you plan to stay on the team now that you have a sense of what to focus on, and you’ve gathered a little information about the team, its project, and its problems, you’ve probably discovered that the product, program, or project is a mess. Half of the time, all three look like zombie leftovers. It doesn’t matter how good the engineering team is, most projects look like a disaster when you show up.
If, for some bizarre reason, you show up and everything looks clean and happy, check again, and then start saving your pennies so you can buy your options. But you’re probably like most of us. You’ve got a mess on your hands, and you need to do two important things right away.
First, don’t tell the team that the product is a mess! They probably don’t think the situation is a mess and won’t take kindly to you calling it out. Trust me on this—you don’t want to learn this lesson the hard way. Remember that they’ve been working on this longer than you, and that there are many reasons why the product is a mess. The odds are pretty good that the engineers on the team are reasonably smart, so there’s a good chance that there’s a leadership problem. More often than not, the leadership problem is a lack of leadership, which is why it’s good that you joined the team. When there is a leadership problem, escalate.
I’m a pretty straightforward guy, so early in my career I embraced the notion of “speaking truth to power.” This led me to cheerfully and directly point out the problems I saw in some teams. Even when I did this pointing as delicately as I could (which is not very delicately, unfortunately), it was not well received. I was an outsider and I clearly didn’t understand that “we do things differently on <foo>; you need to spend more time ramping up.” In some circumstances, like when I drilled into the work of a group of designers on Google Maps, I caused real turmoil and pain. I’ve learned that in most circumstances it’s best to work from the inside out whenever possible, so don’t tell the team that the product is a mess.
The second thing you must do upon discovering a mess is make a choice: you can slip your date and fix the mess, or you can suck it up and ship. The best time to slip your ship date is right when you join the team. Because you are new, you’re not responsible for the slip; you’re just pointing out that the team’s not going to make the date. If you make your case with objective data like bug counts, engineering estimates, and vacation schedules, you can have a dispassionate conversation about the ship date.
On the other hand, sometimes you’ve been brought in to ship at all costs, and that’s what you must do. Freshness and improvements matter to users, so this makes some sense. Make sure that you don’t have massive privacy or security bugs, and then force the software out the door. Fix the team and process problems when you can build on the success of having shipped. Sack the lame-o’s later when you have the time to work them through a reasonable PIP (performance improvement plan) process and give them a chance.
In my experience, there are five major types of teams you will join. In each situation there’s a best way to react. Table 8-1 shows how you can identify the teams by what they say and suggests good responses you can give.
Table 8-1. Team types and reactions
What they say | What you say |
|---|---|
Shiny Ball! Let’s build 100 features! | How about V2? Let’s focus on a single story for V1. |
We’ve been screwed 100 times, you’re 101. | I know things are rough. Let’s craft a really short-term plan that we all believe in and sell it, and go from there. |
We know what we’re doing. Why are you here? | I’m here to do some business stuff and help you manage up. We’ll figure out other things over time (and then work through the leads to drive change). |
Well, our boss didn’t tell us about this. | Let’s all get together with the boss and get on the same page. |
We’re having a good time. We made these fun demos! | Sounds good. (…and go talk to senior management. There’s no point in asking a team that’s happily playing catch to win the World Series unless that’s actually the stated goal.) |
Thank God you’re here. | You’re welcome. What did the last person do that helped you so much? |