How to Build Team Culture in 2019?
A team’s culture isn’t just the way in which team members tackle their work, write code, or treat one another: it’s a set of shared experiences, values, and goals that are unique to every engineering team we’ve ever been on or observed.
The founding members of a team or company define the biggest part of a team’s culture, but it will continue to change and develop over the life of the team. In this blog, we explain how to build a strong and productive team culture.
The elements that make up a team culture vary wildly. Some are directly relevant to the process of doing work: in the case of writing software, you might set up code reviews and test-driven development, and place a high value on having good design docs before starting to crank out reams of code.
Some elements might be more social, like going out to a particular restaurant for lunch every Thursday or going out for drinks at a favorite bar on Fridays.
Some of them might seem completely silly or outlandish to an outsider: the Google Pittsburgh engineering office used to be located next to a freight train track, and every time a train would come by (mind you, a very loud train), everyone would jump up and shoot Nerf darts at one another.
All of these things make up a team’s culture and affect the team’s productivity and ability to attract and retain good team members.
Take a look at any wildly successful software company today—Google, Apple, Microsoft, Oracle—and you’ll find that each company has a very different culture: one that has its roots in the culture that was set by the founders and earliest employees.
As these companies have grown and matured, their cultures have evolved and changed, but they’ve still retained a unique identity that trickles down to just about every aspect of how they develop products, treat their employees, and compete with other companies.
Why Should You Care?
In short, you should care because if you don’t put effort into building and maintaining your culture, your team will eventually be overtaken by strong personalities that cultivate their culture in your team.
This culture may turn out to be a productive, healthy culture that cranks out piles of great code, but more often than not, it won’t turn out as such, and you’ll suddenly find a lot of your energy that used to go into designing and creating your product is suddenly expanded in arguments and infighting.
Beyond that, it’s important to have a culture that your team values and is willing to defend. If your team doesn’t value your culture, not only is it difficult to build strong team identity and collective pride in your work but also it’s very easy for a newcomer to change your culture into something that sucks.
The first mistake most team members make is to assume the team leader curates the culture of a team.
Nothing could be further from the truth: while the founders and leads usually tend to the health of your culture, every member of your team participates in the culture and bears some responsibility for defining, maintaining, and defending the culture.
When someone joins your team, she doesn’t pick up the culture from the team leader alone, but from every team member, she works with. For example, when you carefully review your new team member’s work and explain to her why your team does something in a certain way, she’ll quickly figure out what the team values in their product.
She’ll also learn about your culture from observing how the rest of your team works, interacts and deals with conflict.
A “strong culture” is one that is open to change that improves it, yet is resistant to radical change that harms it. The team cultures that are most successful are those that focus the majority of the team’s effort on shipping great software.
If your team’s primary focus is anything other than that (e.g., partying, attending meetings, practicing one-upmanship) your team may bond tightly, but you won’t get very much software written.
If you’re happiest when writing code and shipping product, it’s definitely in your best interest to find a team that values that and to works to maintain that environment.
It’s not that you can’t create something great without a strong and productive culture, but it’s going to cost you a lot more time and energy to do so without one.
A strong culture gives you focus, efficiency, and strength, and these things make for a happier team.
The interesting thing about team culture is that, if you build a strongly defined one, it will become self-selecting. In the open source world, projects that are built on HRT and focused on writing clean, elegant, the maintainable code will attract engineers who are interested in—surprise, surprise—working with people they respect and trust and writing clean, elegant, maintainable code.
If, however, your team is built on a culture of aggression, hazing, and ad hominem attacks, you’re going to wind up attracting more people like that.
We’ve seen self-selecting cultures many times in the Apache Software Foundation: the ASF is a collection of software development teams that are community-based and that run on a consensus model. Many times a new contributor will join the mailing list and, through either ignorance or malice, will behave in a manner contrary to the team’s culture.
Community members will usually attempt to educate the newcomer (sometimes gently, sometimes, um, well, “not so gently”), and if the newcomer is not interested in how the ASF team does things, they’ll usually head off in search of a more compatible project.
In the corporate world, teams self-select through the hiring process, whether implicitly in the skills and strengths that are valued in potential candidates, or explicitly by considering culture fit as part of the hiring process.
Google takes the explicit approach in its hiring process as it looks specifically for culture fit when interviewing candidates: if Google interviews someone who in all respects looks like an outstanding engineer but is incapable of working with a team of people or requires a very structured environment, the interviewers will raise a red flag in their feedback.
If you don’t pay attention to culture fit as part of the hiring process and hire someone who isn’t a fit, you’ll wind up expending a tremendous amount of energy either getting the new hire to fit in or getting him to leave your team.
Regardless of the result, the cost is high enough that it’s definitely worthwhile to make sure new team members will work well with your existing team.
Interviewing for culture
The only way to make sure new team members will be a culture fit is to interview for it. Many companies (like Google) have culture fit as one of the criteria that interviewers look out for as they’re speaking to a candidate.
Some companies take it even further in their quest to avoid a hiring mistake: they have a separate interview for culture fit before doing the technical interviews because they don’t want to even consider people who would fit technically but not culturally.
This sort of process involvement is critical for creating and preserving a strong culture and it doesn’t happen by accident; in fact, it is usually consciously created by the company’s founders and early employees.
Culture and People
Creative work like writing software is different from simply knocking out widgets on an assembly line. Some types of work can be done with a few days of training and some basic tools, and if your worker quits and leaves (or doesn’t work out), you just drop another worker in and on you go.
In the assembly line environment, employees are accomplishing simple tasks, often by rote, with little creative-thinking or problem-solving skills required. In the software world, a great deal of creative thinking is required of engineers working on a product, and if you want a great product, you need great engineers.
If you want great engineers to do great work (and to stick around), you need to create a culture for them that allows them to safely share ideas and have a voice in the decision-making process.
If you want to get excellent engineers to work on your team, you need to start by hiring, well, some great engineers! That may sound weird, but the fact of the matter is that most great engineers want to be on teams with other great engineers.
Many great engineers we know gravitate toward teams where they can learn from giants of the industry. So how do you attract these engineers in the first place?
For starters, they’re going to want to be able to not only contribute to the development of your product, but also participate in the product’s decision-making process, and that usually means some level of consensus-driven management.
In the case of top-down management, the alpha engineer is the team lead and lesser engineers are hired as team members.
This is because subservient team members cost less and are easier to push around. And you’re going to have a hard time finding great engineers to be on this team because, after all, what really great engineer wants to ride the bus when she can drive the bus at another company? But in the case of consensus-driven management, the entire team participates in the decision-making process.
Many people hear “consensus-based team” and immediately think of a bunch of hippies singing “Kumbaya” around a campfire and never making a decision or getting anything done, but that stereotype is symptomatic of a dysfunctional team much more than a consensus-based team.
What we mean by “consensus” is that everyone has a strong sense of ownership and responsibility for the product’s success and that the leaders really listen to the team (with an emphasis on the “respect” component of HRT).
This may mean there are times when extended discussion and reflection is what the product needs to succeed, and there are other times when the team agrees they need to move quickly. In the latter case, team members may decide to entrust a great deal of the nitty-gritty day-to-day decision making to one or more team leads.
In order for this to happen, the team as a whole needs to agree on the general mission of the team, and believe it or not, the key to that is the development of a team mission statement.
Just as important as your team’s decision-making process is the manner in which team members treat one another because this is more self-selecting than anything else.
If your team has a culture of chest thumping and yelling and screaming at one another, the only people you’ll attract (and retain) are aggressive types who feel right at home in this environment composed of strong individual egos (in fact, most of the women we know find this kind of environment especially off-putting).
If you create a culture of HRT where team members treat one another kindly and take the effort to give constructive criticism, you’ll not only attract a much larger set of people, but you’ll also spend a great deal more of your energy writing software. Having a strong team ego6 is good; a team totally eclipsed by individual egos is a recipe for disaster.
Constructive criticism is essential to the growth and development of any person or team, but many people will go to great lengths to avoid soliciting criticism.
In some cases, this is due to insecurity, but in most cases that we’ve seen, it is because a person thinks that they are required to take action on any criticism received, even if they disagree with it. The best part about getting good constructive criticism is that you can pick and choose which pieces you want to act on.
Let’s say, for example, that you’re getting ready for an important job interview and put on your favorite suit. You approach a trusted friend and ask how you look.
If they say, “You’ve got spinach in your teeth, and I really hate your suit” you can take a quick floss break, but you don’t have to change clothes as well. Criticism is a gift that you can either accept or reject.
If you’re interested in improving your work or fixing your own personal bugs, these very friends and colleagues are the ones that can make you aware of things you do that might be hindering your effectiveness.
Unless you have a truly remarkable level of self-awareness or introspection, without criticism, you’ll just go on making the same mistakes no one wants to tell you about.
For example, in the process of going to press with this blog, we’ve had no fewer than a dozen people look at it and give us constructive criticism on our writing, and most of it was incredibly detailed and completely invaluable.
Regardless of whether you think the blog is good or bad, it would have been considerably worse if we had ignored this valuable feedback or been afraid to ask for it.
It requires a certain amount of self-confidence to take any kind of criticism, and we think constructive criticism is the easiest kind to receive. On the down-side, it’s a lot harder to give someone constructive criticism than to simply lam-bast her or ridicule something she did.
Of course, we realize it’s incredibly difficult to solicit and then receive constructive criticism from most people—they assume that when you ask them to criticize your work, you’re only looking for compliments and assurance.
If you can find friends or colleagues who will constructively criticize your work when you ask them, hang on to these people because they’re worth their weight in unobtainium.
Aggressive people can (usually) be productive in a quieter environment, but quieter, more introverted people rarely excel (or enjoy working) in an aggressive environment—it’s not only harder to hear their voices over the noise, but it also tends to discourage them from being active participants.
If you’re looking for a culture that allows the broadest range of people to work most efficiently, you should build that culture on humility, respect, and trust.
Calm, easygoing cultures built on respect are more vulnerable to disruption by aggressive people than aggressive cultures are vulnerable to disruption from more easygoing people.
Easygoing cultures need to be aware of this and not let the aggressive newcomer take over, typically by refusing to engage this person in an aggressive tone.
In some cases, one or more of the more senior team members may have to meet the aggressive newcomer head-on to prevent her from harming an easygoing team culture.
Communication Patterns of Successful Cultures
Communication can often be a challenge when you’re working with a team, Communication can often be a challenge when working with a team, particularly for engineers, who would rather spend an afternoon with a (predictable, logical) compiler than spend three minutes with an (unpredictable, emotional) human being.
In many cases, engineers see communication work as an obstacle to be overcome on the road to writing more code, but if your team isn’t in agreement or is uninformed, there’s no way to know if you’re writing the right code in the first place.
If you examine any successful, efficient culture, you’ll find high value placed on numerous channels of communication, such as mailing lists, design docs, chat rooms, mission statements, code comments, production how-tos, and more.
It takes considerable effort to make sure everyone on a team agrees on the team’s direction and understands exactly what the team needs to do. All this effort, however, is an investment that pays off in increased productivity and team happiness.
A good general rule around communication is to include as few people as necessary in synchronous communication (like meetings and phone calls), and to go for a broader audience in asynchronous communication (like email, issue trackers, and document comments).
Synchronous communications have a high cost: they require that participants interrupt their workday and receive information on your schedule.
Asynchronous communications, however, can be dealt with at a time and place most convenient for the recipient. Every time you interrupt someone’s work it will take some amount of time for them to get back up to speed—always be conscious of when you’re doing this.
But most importantly, you should make certain that all information is available to as many people as possible in your project’s documentation. Let’s cover the primary communication mechanisms that people use in the process of writing software with a team.
Some of these may seem obvious, but there are many nuances that make them worth reviewing. One thing is certain: if you don’t expend any effort on good communication, you’ll waste considerable effort doing work that’s either unnecessary or already being done by other members of your team.
At the highest level, the team needs to keep common goals in sync and follow best practices around communicating their progress.
THE MISSION STATEMENT—NO, REALLY
When you hear someone say “mission statement,” the odds are good that the first thing that springs to mind is the insipid, overhyped, marketing-speak mission statements that are bandied about by a lot of big companies. An example is the following mission statement from a very large telecommunications company that will remain nameless:
We aspire to be the most admired and valuable company in the world. Our goal is to enrich our customers’ personal lives and to make their businesses more successful by bringing to market exciting and useful communications services, building shareowner value in the process.
Oddly enough, I’ve yet to meet anyone who admires that company! Here’s another example from another major corporation:
Providing solutions in real time to meet our customers’ needs.
What does that even mean? It could mean absolutely anything at all—if we worked for that company, we wouldn’t know if it was more important to wash the car, fix a leaky pipe, or deliver a pizza. It’s this kind of corporate doublespeak that gives mission statements a bad name.
For an effective, efficient team, writing a mission statement is a way to concisely define the direction and limit the scope of your product. Writing a good mission statement takes some time and effort, but it can potentially save you years of work by clarifying what your team should and shouldn’t be working on.
When Google decided to move development of the Google Web Toolkit (GWT) to an open source project, we acted as the team mentors.
We reviewed the many differences between open and closed source development, paying specific attention to the difficulties of designing, discussing, and writing software in an environment where anyone can poke their nose in to offer an opinion, contribute a patch, or criticize the most minute aspect of your product.
After going over these challenges, we told the team they needed to come up with a mission statement as a way to describe to the public at large what their product goals (and nongoals!) were.
Some of the team members balked at this for many of the reasons outlined earlier, but others seemed curious, and the team lead seemed to think it was a great idea. However, when we sat down to start writing the mission statement, a lot of debate about the content, substance, and style of the mission statement ensued.
After a great deal of discussion (and a few more meetings), the team came up not only with a great, concise mission statement, but also an entire document called “Making GWT Better” explaining the statement phrase by phrase. They even included a section that described what the project’s nongoals were. Here’s the mission statement:
GWT’s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.
There’s a ton of substance packed into that sentence, and we think it’s an excellent example of a mission statement: it includes both a direction (improve the web experience…by enabling developers) and a scope limiter (Java tools).
Several years later we were having dinner with the team lead, and Steve told him how thankful we were that he had supported us so strongly in our effort to get the team to write a mission statement.
He responded that he had actually thought the entire exercise was a waste of time when we first proposed it, but that once he started debating it with the team, he discovered something he’d never known: his lead engineers did not agree on the direction of the product!
In this case, writing a mission statement forced them to confront their differences and come to an agreement on their product’s direction, a problem that could have slowed down (or stopped) development of the product as time went on.
They posted their mission statement on the Web, and not only did the entire team have a laser focus on what they wanted to do with their product, but it saved them months of time arguing with potential contributors about the product’s direction—they just pointed newcomers to “Making GWT Better” and most questions were answered.
As your project progresses, the mission statement keeps things on track. It shouldn’t become an insurmountable impediment to change, however. If radical changes happen to the environment or business plan (say, at a startup company), software team members need to be honest with themselves and reevaluate whether the mission still makes sense.
Changing a constitution is a deliberately difficult process, as it prevents people from doing so whimsically. But in dramatic times it’s at least possible to change it and it should be considered. If a company or product pivots suddenly, the mission statement needs to keep up.
Most people would classify meetings as a necessary evil. While they can be highly effective when used skillfully, they’re frequently abused, usually disorganized, and almost always too long. We like our meetings like we like our sewage treatment plants: few, far between, and downwind. So we’ll keep this section brief and just cover team meetings.
Let’s start with the most dreaded meeting of all: the standing meeting. This meeting usually takes place every week, and should absolutely be kept to basic announcements and introductions—going around the room for a status update from every attendee is a recipe for wasted time, rolling eyes, and a burning desire to punch yourself in the throat just to make it end.
The anything worth deeper discussion should take place after the meeting, with only the relevant people sticking around for it. This is also a great way to avoid derailing a meeting when someone starts to do a deep dive into a particular meeting topic: the person running the meeting should just add the topic to a list of “sidebars” and once the meeting is over, review them one at a time.
If your team makes this a habit, it’s easy to call “sidebar” on something that’s getting off-track without putting anyone off.
The key to making this meeting work is that people should be happy to leave the meeting once the main part of it is done, and if there’s nothing that needs to be covered or information that can be disseminated by email, don’t hesitate to cancel the meeting.
We’ve seen some cultures where meeting attendance is equated with status, so nobody wanted to be left out. Not to put too fine a point on it, but that is patently insane.
Some engineers swear by daily standups that are promoted by development methodologies like Agile, and these are acceptable if they are kept short and on point.
These meetings usually start their lives short—15 minutes—with everyone actually standing up and giving a brief update on what they’re working on, but without constant vigilance, they tend to quickly turn into 30-minute-long sit-down meetings where people ramble on and on like they’re in a group therapy session.
If your team is going to have these meetings, someone needs to run them with authority and keep their growth in check.
If you’re trying to design something new, try to include no more than five people in your meeting—it’s practically impossible to come up with new designs and make decisions with more than five people in a room unless there’s only one person in the room making the decisions.
If you don’t believe us, get five of your friends together, go downtown, and try to decide among the six of you how to do a walking tour that hits half a dozen tourist sites.
The odds are good that you’ll stand on the street corner arguing for most of the day unless you simply declare one person to be the final arbiter and then follow her wherever she goes.
Meetings are frequently an interruption to what many refer to as “make time,” inspired by Paul Graham’s “Maker’s Schedule, Manager’s Schedule.”
It can be hard for anyone, especially engineers, to get into the zone if they’re constantly stopping work to attend meetings. Schedule time on your calendar in three- to four-hour blocks and label these blocks as “busy” or even “make time,” and get your work done.
If you have to set up a meeting, try to set it up near another natural break in the day, like lunchtime, or at the very end of the day.
At Google, there’s a long (and unfortunately, often ignored) tradition of “No-meeting Thursdays” in the interest of clearing time to just get work done. This is a good first step on the path to having 20 to 30 hours of make time set aside in larger blocks.
Five simple rules for running a meeting:
1. Only invite people who absolutely need to be there.
2. Have an agenda and distribute it well before the meeting starts.
3. End the meeting early if you’ve accomplished the meeting’s goals.
4. Keep the meeting on track.
5. Try to schedule the meeting near other interrupt points in your day (e.g., lunch, end of day).
If you’re going to have a meeting, create an agenda and distribute it to all attendees at least a day before the meeting so that they’ll know what to expect. Invite a few people as possible (remember the cost of synchronous communication). We know team members, managers, and even directors and VPs who will flat out ignore invitations to a meeting that has no agenda.
Only invite people to the meeting who actually need to be there for the meeting to accomplish its goal.
Some people have taken to banning laptops in meetings after they’ve noticed attendees reading email instead of paying attention, but this is attacking the symptom and not the cause—people start reading email in a meeting because they probably don’t need to be in the meeting in the first place.
Whoever’s running the meeting should actually run the meeting and not hesitate to (gently) cut off someone who veers off-topic or, even worse, tries to monopolize the conversation. Doing this well can be tricky, but is worthwhile. And most importantly, don’t be afraid to end a meeting early if you’ve completed the agenda.
WORKING IN A “GEOGRAPHICALLY CHALLENGED” TEAM
When you’re part of a distributed team or working remotely from them, you not only need to find different ways to communicate but also need to put more work into communication, period.
If you’re on a team that has remote workers, this means documenting and sharing decisions in writing, usually over email.
Online chats, instant messages, and hallway conversations might be where a lot of discussion takes place, but there needs to be some way to broadcast relevant discussions like these to everyone to make sure they’re informed and participating (and as a bonus, archived email lists provide documentation).
Video chat is also incredibly useful as a quick conversation enabler, and besides, these days most laptops have built-in webcams.
In the Subversion project we had a motto: “If the discussion didn’t happen on the email list, then it never really happened.” People spent lots of time bandy-ing around ideas in chat rooms, but in order to make the resolutions “real,” we had to be mindful of everyone else who didn’t witness them.
By forcing conversations to report to email lists, we gave the entire distributed team a chance to see how decisions were arrived at (and to speak up if they wanted to). This is particularly critical if you’re trying to encourage a consensus-based team culture.
Talking to someone from a remote location should be as frictionless as walking over to their desk.
If you’re working remotely, overcommunicate with your team using every available medium (e.g., online chat, instant messages, email, video chat, phone calls, etc.) to make sure everyone knows not only that you exist, but also what you’re working on.
Nothing replaces being in the same room
One thing to note about all of these people is that, despite all the advances in social media and video conferencing technology, nothing even comes close to the bandwidth and the intimacy of being face to face with someone else in real life.
If you’re starting a new project or have an important meeting with someone in your company and you have the budget to be there in person, it’s almost always worth the hassle of traveling. The impact of an in-person discussion etches itself into memory in ways that phone or video chats can’t compete with.
A frequent argument against business travel is that it’s too expensive or, in some cases, not affordable. While this may be the case for small geographically distributed companies, most large companies can afford this expense. The cost of not spending face time with your colleagues is higher than you think.
No matter how much your email, chat, or call, don’t be afraid to regularly get on a plane and visit the rest of your team. This goes for remote employees, remote teams, and remote offices as well—make the time to get out to the home office and talk to people.
If you’re an engineer, it’s sometimes difficult to resist the urge to take a running leap into writing code for a new project, but this is rarely fruitful (unless you’re throwing together a quick and dirty prototype). Just the same, many engineers rush right into coding before designing the software they intend to write, and this usually ends very badly.
A design doc is typically owned by one person, authored by two or three, and reviewed by a larger set. It serves not only as a high-level blueprint of your future project but also as a low-cost way to communicate with your larger team what you want to do and how you intend to do it.
Since you haven’t spent weeks (or months) writing code, it’s a lot easier to accept criticism at this point and you’ll wind up with a better product and a better implementation.
In addition, once you’ve nailed down the design doc, it will serve as your guide for both scheduling and dividing the work on your project.
Once you start coding, however, you should treat your design doc as a living document and not one carved in stone: you and your team should update the document as your project grows and changes, not once you’ve shipped, although this is easier said than done.
Most teams have no docs at all, while the rest have a short period of awesome docs, followed by a long period of out-of-date docs.
Having said that, make sure you don’t take the “design doc religion” to the opposite extreme. We’ve seen control freaks write a four-page design essay for a program that’s only 100 lines of code.
If the project can be rewritten from scratch several times in the same amount of time it takes to write a design doc, a design doc is clearly a waste of time. Use experience and judgment when making these time calculations and trade-offs.
Assuming high-level goals are agreed upon, you need to worry about the tools your team uses for everyday coordination. These tools are useful, but they tend to have narrow communication bandwidth and, usually, a complete lack of meta-data and secondary communication channels such as facial expressions and body language.
As a result, they’re more conducive to miscommunication and an inherent threat to HRT. Still, these tools are invaluable to most teams and (with a little effort) can give a good boost to productivity.
We don’t know of anyone who works with a team these days that doesn’t use at least one mailing list, but there are a few things you can do with your mailing lists to make them more useful.
Many big successful projects have multiple mailing lists, separating development discussions, code reviews, user discussions, announcements, pager emails, and miscellaneous administrivia.
Sometimes smaller projects attempt to emulate this as they’re just getting started and create half a dozen mailing lists when they’ve only got three engineers and two users.
This is the mailing list equivalent of providing six conference rooms for five people to carry on a discussion—you wind up with little coherence, a lot of echoes, and mostly empty rooms.
It’s really best to start with one list and to add lists only when the amount of traffic on one list gets unmanageable (which is typically indicated by list members begging for mercy).
An exception to that rule is to have automated emails and “bot” notifications go to their own list or at the very least use identifiers that make them easy to filter.
Take some time to establish proper etiquette around email discussions— keep discussions civil, and prevent filibustering by a “noisy minority.”
A mailing list isn’t going to be your first choice for a discussion in a team that shares an office, but it’s a good idea to send a copy of meeting agendas, meeting notes, decisions made, design docs and any other relevant textual information to your team’s mailing list so that you have a convenient central record.
Set up these lists to archive all posts in a searchable index, either publicly available in the case of open source projects or on your company’s intranet if you’re working on a closed source project.
Now you have a system of record for the history of your project, and it’s easy to refer back to it when a newcomer asks about the reasoning behind one or more decisions that you made in the past. If you don’t have these discussions archived somewhere, you’ll find yourself repeating them again and again and again and again.
Online chat is an incredibly convenient way for teams to communicate, especially since it provides a way to send a quick request to a teammate without interrupting her work (providing, of course, she has her chat program configured to not interrupt her work!).
It’s a good tool for teams to use if they’re moving quickly on a new project, doing some light work in the evening or on the weekend, or if one team member is out of the office for a day or two.
One-on-one chat is useful and certainly has its place in team communication, but we strongly recommend that teams use some sort of group chat mechanism.
Years before instant messaging became wildly popular, teams would hang out in an Internet Relay Chat (IRC) channel and most of their discussions would be in a group chat.
This could be noisy at times, and it was easy enough for team members to break off to have a private chat if they were discussing something that was not of interest to the larger team, but in most cases, discussions happened “in front of” the rest of the team.
This allowed other people to join in on the conversation, lurk in the background and follow the discussion, or even catch up on discussions they missed earlier. This is convenient not only because of the ease with which ad hoc group discussions can start but also because it helps to build community even in teams that are geographically dispersed.
It’s often surprising how much a newer team member can learn just by watching (or later reading) various discussions he’s not necessarily participating in.
With the advent of instant messaging, many of these conversations that would previously take place in the group chat room moved to private chat, which was the default for instant messenger.
It’s very tempting to indulge your insecurity and take what might be perceived as a stupid question to a one-on-one discussion rather than risk embarrassment in front of the rest of the team.
Unfortunately, this increases the burden on the team because there’s no shared lore created and different team members may ask other team members the same question over and over again.
Slack integrates with dozens of other products and has become the messaging tool of choice in smaller companies, startups, and even loosely connected groups of acquaintances on the Internet.
While it still provides a means to send private messages, team owners get a weekly report telling them the percentage of private messages versus group messages. This makes it easy to give your team a gentle “push” to have more discussions in the group channels rather than one-on-one.
Regardless of the application you use for chat, we strongly recommend that your team have a convenient and accessible mechanism for group chat. It’s well worth the effort in order to have this additional communication bandwidth in your team.
REQUIRE CODE REVIEWS FOR EVERY COMMIT
If you’re going to have coding standards, you need to have a means of monitoring code going into your product. Whether you review the code before committing it or after committing it, you should make sure every line of code that goes into your repository gets a second pair of eyes on it to check for style, quality, and, of course, careless mistakes.
Keep code changes small and reviewable— changesets that are thousands of lines long are unreviewable for anything but formatting nits. This not only results in a higher-quality code base but also goes a long way toward instilling a strong sense of group pride in the quality of your code.
HAVE REAL TEST AND RELEASE PROCESSES
Whether you’re a full-on test-driven development shop or you just have some simple regression tests for your product, the more automated tests you have for your product, the more confident you can be when you’re tearing through fixing bugs or adding new features.
Once your team determines the role that testing will play, it should be part of the coding and review process. Just as importantly, your release process should be lightweight enough that you can do frequent releases (e.g., weekly), but thorough enough that you catch brokenness before it hits your users.
It Really Is About Your Product, After All
Although these habits of culture and communication may seem to represent a certain amount of bias, as they reflect the manner in which we prefer to work, it’s not as subjective as you might think.
We’ve found that building a strong, productive team culture and taking some time to pay attention to communication in the team creates a team that will spend more time writing and shipping product and less time arguing about what product to ship.
Strong teams don’t arise spontaneously; they’re carefully seeded and cultivated by team leads and founders who understand the high cost of trying to write software with a dysfunctional team.
Putting this work in from the outset helps to create a self-selecting culture that builds a team that will spend much more time designing and creating a product than defining and defending their culture.
A big side benefit of this effort—communication and process—is that it drastically reduces the barrier to entry for newcomers to your team. Without these elements in place, newcomers will either waste a lot of time struggling to learn how your team works or give up and try to make your team work like their last team did (for good or for bad).
While getting the right people on your team and the right values instilled in your team is important, the overwhelming majority of effort that goes into a culture turns out to be communication.
Mission statements, meetings, mailing lists, online chat, code comments, documentation, and even decision-making processes all make up the many different ways your team communicates, both with itself and with others.
It’s often a surprise to people that it takes so much communication—including emotional time and effort—to build a strong team for the sole purpose of creating a product, but it’s true. Your product is ultimately about communications with people, not just with a machine.
No matter what your team’s culture is, and regardless of how well your team communicates, every effective team that we’ve ever seen has a leader.
Every Boat Needs a Captain
Even if you’ve sworn on your mother’s grave that you’ll never become a “manager,” at some point in your career you’re going to accidentally trip and fall into a leadership position. This blog will help you understand what to do when this happens.
There are dozens of blogs already written for managers on the topic of management, but this blog is for individual contributors who find themselves in an unofficial position of leadership. Most people fear becoming managers for various reasons, yet no team can function without a leader.
We’re not here to attempt to convince you to become a manager (even though we’re both managers now!), but rather to help show why teams need leaders, why people typically fear becoming managers, and why the best leaders work to serve their team using the principles of humility, respect, and trust. Beyond that, we’ll delve into leadership patterns and antipatterns, and motivation.
Understanding the ins and outs of leadership is a vital skill for influencing the direction of your work. If you want to steer the boat for your project and not just go along for the ride, you need to know how to navigate or you’ll run yourself (and your project) onto a sandbar.
Manager Is a Four-Letter Word
The present-day concept of the pointy-haired manager is partially a carryover, first from military hierarchy and later adopted by the Industrial Revolution— more than 100 years ago! Factories started popping up everywhere, and they required (usually unskilled) workers to keep the assembly lines moving.
Consequently, these workers required supervisors to manage them, and since it was easy to replace these workers with other people who were desperate for a job, the managers had little motivation to treat their employees well or improve conditions for them. Whether humane or not, this method worked well for many years when the employees had nothing more to do than perform rote tasks.
Managers frequently treated employees in the same way that cart drivers would treat their mules: they motivated them by alternately leading them forward with a carrot, and, when that didn’t work, whipping them with a stick.
This continues today in some industries—even in industries that require creative thinking and problem solving—despite numerous studies suggesting that the anachronistic carrot and stick is ineffective and harmful to the productivity of creative people.
While the assembly-line worker of years past could be trained in days and replaced at will, knowledge workers can take months to get up to speed on a new team. Unlike the replaceable assembly-line worker, these people need nurturing, time, and space to think and create.
“LEADER” IS THE NEW “MANAGER”
Most people still use the title “manager” despite the fact that it’s often an anachronism. We think the term manager should be eliminated and the term leader should be used instead.
While we’re hardly members of the stalwart, politically correct crowd, the word manager has become a four-letter word—a role whose very existence encourages new managers to manage their reports.
Managers wind up acting like parents, and consequently, employees react like children. To frame this in the context of HRT: if the manager makes it obvious that she trusts her employee, the employee feels positive pressure to live up to that trust.
Being a “leader” doesn’t necessarily mean you have ultimate responsibility for absolutely everything. There are different types of leadership, some technical and some personal. In the software development world, there are two distinct roles (and titles) for people leading a team: TL (tech lead) and TLM (tech lead manager).
A TL is typically responsible for the technical direction for all (or part) of a product, while a TLM is responsible for the technical direction for all (or part) of a product in addition to the careers and happiness of the people on the team. This enables those who want to focus on leading a project to avoid the people management part of being a leader if they want to.
THE ONLY THING TO FEAR IS…WELL, EVERYTHING
Aside from the general sense of malaise that most people feel when they hear the word manager, there are a number of reasons that most people don’t want to become managers.
The biggest reason you’ll hear in the software development world is that you spend much less time writing code, which is true whether you’re a technical leader or a people leader. We’ll talk more about that later, but first, some more reasons why most of us avoid becoming managers.
If you’ve spent the majority of your career writing code, you typically end a day with something you can point to—whether it’s code, a design document, or a pile of bugs you just closed—and say, “That’s what I did today.”
Based on this metric of productivity, at the end of a busy day of “management”, you’ll usually find yourself thinking, “I didn’t do a damned thing today.”
It’s the equivalent of spending years counting the number of apples you picked each day and changing to a job picking bananas, only to say to yourself at the end of each day, “I didn’t pick any apples,” handily ignoring the giant pile of bananas sitting next to you.
Quantifying management work is more difficult than counting widgets you turned out, and you don’t have to take credit for your team’s work; however, making it possible for them to be happy and productive is a big measure of your job. Just don’t fall into the trap of counting apples when you’re picking bananas.
Another big reason for not becoming a manager is often unspoken but rooted in the famous “Peter Principle,” which states that “In a hierarchy, every employee tends to rise to his level of incompetence.” Most people have had a manager who was incapable of doing her job or was just really bad at managing people, and we know some people who have only worked for bad managers.
If you’ve only been exposed to crappy managers for your entire career, why would you ever want to be a manager? Why would you want to be promoted to a role that you weren’t able to do?
There are great reasons to consider becoming a manager: first, it’s a way to scale yourself. Even if you’re great at writing code, there’s still an upper limit to the amount of code you can write. Imagine how much code a team of great engineers could write under your leadership!
Second, you might just be really good at it—many people who find themselves sucked into the leadership vacuum of a project discover that they’re exceptionally skilled at providing the kind of guidance, help, and air cover a team needs.
The Servant Leader
There seems to be a sort of disease that strikes new managers where they forget about all the awful things their managers did to them and suddenly start doing these same things to “manage” the people that report to them.
The symptoms of this disease include, but are by no means limited to, micromanaging, ignoring low performers, and hiring pushovers. Without prompt treatment, this disease can kill an entire team.
The best advice we got when we first became managers at Google was from Steve Vinter, an engineering director. He said, “Above all, resist the urge to manage.” One of the greatest urges of the newly minted manager is to actively “manage” her employees because that’s what a manager does, right? This typically has disastrous consequences.
The cure for the “management” disease is a liberal application of what we call “servant leadership,” which is a nice way of saying the most important thing a leader can do is to serve her team, much like a butler or majordomo tends to the health and well-being of a household. As a servant leader, you should strive to create an atmosphere of humility, respect, and trust (HRT).
This may mean removing bureaucratic obstacles that a team member can’t remove by herself, helping a team achieve consensus, or even buying dinner for the team when they’re working late at the office. The servant leader fills in the cracks to smooth the way for her team and advises them when necessary, but still isn’t afraid of getting her hands dirty.
The only managing that a servant leader does is to manage both the technical and social health of the team; as tempting as it may be to focus purely on the technical health of the team, the social health of the team is just as important (but often infinitely harder to manage!).
Before we go over a litany of “design patterns” for successful leaders, we’re going to review a collection of the patterns you don’t want to follow if you want to be a successful leader. We’ve observed these destructive patterns in a handful of bad leaders we’ve encountered in our careers, and in more than a few cases, ourselves.
If you’re a manager and you’re feeling insecure in your role (for whatever reason), one way to make sure no one questions your authority or threatens your job is to hire people you can push around. You can achieve this by hiring people who aren’t as smart or ambitious as you are, or just people who are more insecure than you.
While this will cement your position as the team leader and decision maker, it will mean a lot more work for you. Your team won’t be able to make a move without you leading them like dogs on a leash.
If you build a team of push-overs, you probably can’t take a vacation; the moment you leave the room, productivity comes to a screeching halt. But surely this is a small price to pay for feeling secure in your job, right?
Instead, you should strive to hire people who are smarter than you and can replace you. This can be difficult because these very same people will challenge you on a regular basis (in addition to letting you know in no uncertain terms when you screw up). These very same people will also consistently impress you and make great things happen.
They’ll be able to direct themselves to a much greater extent, and some will be eager to lead the team as well.
You shouldn’t see this as an attempt to usurp your power, but rather as an opportunity for you to lead an additional team, investigate new opportunities, or even take a vacation without worrying about checking in on the team every day to make sure they’re getting their work done.
ANTIPATTERN: IGNORE LOW PERFORMERS
Sometimes people miss expectations because they’re not working long enough or hard enough, but the most difficult cases are when someone just isn’t capable of doing his job no matter how long or hard he works.
The team at Google that is responsible for keeping all of their services running has a motto: “Hope is not a strategy.” And nowhere is hoped more overused as a strategy than in dealing with a low performer.
Most team leaders grit their teeth, avert their eyes, and just hope that the low performer either magically gets better or just goes away. Yet it is extremely rare that this person does either.
While the leader is hoping and the low performer isn’t getting better (or leaving), high performers on the team waste valuable time pulling the low performer along and team morale leaks away into the ether.
You can be sure that the team knows they’re there even if you’re ignoring them—the rest of the team is acutely aware of who the low performers are because they have to carry them.
Ignoring low performers is also a way to keep new high performers from joining your team, and a way to encourage existing high performers to leave. You eventually wind up with a whole team of low performers because they’re the only ones who can’t leave of their own volition.
Lastly, you aren’t even doing the low performer any favors by keeping him on the team; often, someone who wouldn’t do well on your team would actually have plenty of impacts somewhere else.
The benefit of dealing with a low performer as quickly as possible is that you can put yourself in the position of helping him up or out. If you deal with a low performer right away, you’ll oftentimes find that he merely needs some encouragement or direction to slip into a higher state of productivity.
If you wait too long to deal with a low performer, his relationship with the team is going to be so sour and you’re going to be so frustrated that you’re not going to be able to help him.
How does one coach a low performer effectively? It turns out that the two of us have (unfortunately) had quite a lot of experience in this area, gained through painful trial and error. The best analogy is to imagine you’re helping a limping person learn to walk again, then jog, then run alongside the rest of the team.
It almost always requires temporary micromanagement—but still a whole lot of HRT, particularly respect. Set up a specific time frame (say, two or three months), and some very specific goals you expect him to achieve in that period.
Make the goals small and incremental, so there’s an opportunity for lots of small successes. Meet with the team member every week to check on progress, and be sure you set really explicit expectations around each upcoming milestone, so it’s easy to measure success or failure. If the low performer can’t keep up, it will become quite obvious to both of you early in the process.
At this point, the person will often acknowledge that things aren’t going well and decide to quit; in other cases, a determination will kick in and he’ll “up his game” to meet expectations. Either way, by working directly with the low performer you’re catalyzing important and necessary changes.
These are a collection of behavior patterns for successful leadership that we’ve learned from experience, from watching other successful leaders, and, most of all, from our own leadership mentors.
These patterns are not only those that we’ve had great success in implementing but the patterns that we’ve always respected the most in the leaders that we follow.
BE A ZEN MASTER
Mediating your reactions and maintaining your calm is more important as you lead more people because your team will (both unconsciously and consciously) look to you for clues on how to act and react to whatever is going on around you.
A simple way to visualize this effect is to see your company’s org chart as a chain of gears, with the individual contributor as a tiny gear with just a few teeth all the way at one end, and each successive manager above her as another gear, ending with the CEO as the largest gear with many hundreds of teeth.
Another way of thinking about this is the maxim that the leader is always on stage. This means that if you’re in an overt leadership position, you are always being watched: not just when you run a meeting or give a talk, but even when you’re just sitting at your desk answering emails.
Your peers are watching you for subtle clues in your body language, your reactions to small talk, and your signals as you eat lunch. Do they read confidence or fear? As a leader, your job is to inspire, but inspiration is a 24/7 job. Your visible attitude about absolutely every-thing—no matter how trivial—is unconsciously noticed and spreads infectiously to your team.
This will usually lead the employee to the answer, and it will be her answer, which leads back to the ownership and responsibility we went over earlier in this blog. Whether you have the answer or not, using this technique will almost always leave the employee with the impression that you did. Tricky, eh? Socrates would be proud of you.
Working to build team consensus is a leadership skill that is often used by unofficial leaders because it’s one way you can lead without any actual authority.
If you have the authority, you can direct and dictate direction, but that’s less effective overall than building consensus. If your team is looking to move quickly, sometimes they’ll voluntarily con-cede authority and direction to one or more team leads. While this might look like a dictatorship or oligarchy, when it’s done voluntarily it’s a form of consensus.
Sometimes your team already has a consensus about what you need to do, but they hit a roadblock and get stuck. This could be a technical or organizational roadblock, but jumping in to help the team get moving again is a common leadership technique.
FAILURE IS AN OPTION
Another way to catalyze your team is to make them feel safe and secure so that they can take greater risks. The risk is a fascinating thing—most humans are terrible at evaluating risk, and most companies try to avoid risk at all costs.
A common saying at Google is that if you try to achieve an impossible goal, there’s a good chance you’ll fail, but if you fail to try to achieve the impossible, you’ll most likely accomplish way more than you would have accomplished had you merely attempted something you knew you could complete.
A good way to build a culture where risk-taking is accepted is to let your team know it’s OK to fail.
So let’s get that out of the way: it’s OK to fail. In fact, we like to think of failure as a way of learning a lot really quickly (providing that you’re not repeatedly failing at the same thing).
In addition, it’s important to see failure as an opportunity to learn and not to point fingers or assign blame. Failing fast is good because there’s not a lot at stake.
Failing slowly can also teach a valuable lesson, but it is more painful because more is at risk and more can be lost (usually engineering time).
Failing in a manner that affects your customers is probably the least desirable failure that we encounter, and one where we have the greatest amount of structure in place to learn from failures. As mentioned earlier, every time there is a production failure at Google, they perform a postmortem.
This procedure is a way to document the events that led to the actual failure and to develop a series of steps that will prevent it from happening in the future.
This is not an opportunity to point fingers, nor is it intended to introduce unnecessary bureaucratic checks; the goal is rather to focus strongly on the core of the problem and fix it once and for all. It’s very difficult but quite effective (and cathartic!).
Individual successes and failures are a bit different. It’s one thing to laud individual successes, but looking to assign individual blame in the case of failure is a great way to divide a team and discourage risk-taking across the board.
It’s OK to fail, but fail as a team and learn from your failures. If an individual succeeds, praise him in front of the team.
If an individual fails, give constructive criticism in private. Whatever the case, take advantage of the opportunity and apply a liberal helping of HRT to help your team to learn from their failures.
This doesn’t mean we’re assuming you are lying to your team, but it merits a mention because you’ll inevitably find yourself in a position where you can’t tell your team something or, even worse, you have to tell them something they don’t want to hear.
A former manager of Steve’s would tell new team members, “I won’t lie to you, but I will tell you when I can’t tell you something or if I just don’t know.”
If a team member approaches you about something you can’t share with her, it’s OK to just tell her you to know the answer but can’t tell her. Even more common is when a team member asks you something you don’t know the answer to you can tell her you don’t know.
This is another one of those things that seem blindingly obvious when you read it, but many people move to a manager role and feel that if they don’t know the answer to something it proves they’re weak or out of touch. In reality, the only thing it proves is that they’re human.
Giving hard feedback is…well, hard. The first time you have to tell one of your reports that he made a mistake or didn’t do his job as well as was expected of him can be incredibly stressful.
Most management texts advise that you use the “compliment sandwich” to soften the blow when delivering hard feedback. A compliment sandwich looks something like this:
“You’re a solid member of the team and one of our smartest engineers. That being said, your code is incredibly convoluted and almost impossible for anyone else on the team to understand. But you’ve got great potential and a wicked cool neckbeard.”
Ben thought hard about how he could get Dean to understand how his actions were adversely affecting the team, and he came up with the following metaphor:
Every time a decision is made, it’s like a train coming through town—when you jump in front of the train to stop it you slow the train down and potentially annoy the engineer driving the train.
A new train comes by every 15 minutes, and if you jump in front of every train, not only do you spend a lot of your time stopping trains, but eventually one of the engineers driving the train is going to get mad enough to run right over you.
So, while it’s OK to jump in front of some trains, pick and choose the ones you want to stop to make sure you’re only stopping the trains that really matter.
This anecdote not only injected a bit of humor into the situation but also made it easier for Ben and Dean to discuss the effect that Dean’s “train stopping” was having on the team in addition to the energy Dean was spending on it.
As a leader, one way you can make your team more productive (and less likely to leave) in the long term is to take some time to gauge their happiness.
The best leaders we’ve worked with have all been amateur psychologists, looking in on their team members’ welfare from time to time, making sure they get recognition for what they do and trying to make certain they are happy with their work.
One leader we know makes a spreadsheet of all the grungy, thankless tasks that need to be done and makes certain these tasks are evenly spread across the team.
Another leader watches the hours his team is working and uses comp time and fun team outings to avoid burnout and exhaustion. Yet another leader starts one-on-one sessions with his team members by dealing with their technical issues as a way to break the ice and then takes some time to make sure each engineer has everything he needs to get his work done.
After they’ve warmed up, he talks to the engineer for a bit about how he’s enjoying the work he’s doing and what he’s looking forward to next.
One of the most valuable tools in tracking your team’s happiness is, at the end of each one-on-one meeting, to ask the team member, “What do you need?” This simple question is a great way to wrap up and make sure each team member has what he needs to be productive and happy, although you may need to carefully probe a bit to get details.
If you ask this every time you have a one-on-one, you’ll find that eventually, your team will remember this and sometimes even come to you with a laundry list of things they need to make their job better.
The Unexpected Question
It can also be worthwhile to pay some attention to your team’s happiness outside the office. Be wary of assuming that people have no life outside of work— having unrealistic expectations about the amount of time people can put into their work will cause people to lose respect for you, or worse, to burn out.
We’re not advocating that you pry into your team members’ personal lives, but being sensitive to personal situations that your team members are going through can give you a lot of insight into why they may be more or less productive at any given time.
Giving a little extra slack to a team member who is having a tough time at home now can make him a lot more willing to put in longer hours when your team has a tight deadline to hit later.
A big part of tracking your team members’ happiness is tracking their careers. If you ask a team member where she sees her career in five years, most of the time you’ll get a shrug and a blank look.
When put on the spot, most people won’t say much about this, but there are usually a few things that everyone would like to do in the next five years: get promoted, learn something new, launch something important, and work with smart people. Regardless of whether they verbalize this, most people are thinking about it.
If you’re going to be an effective leader, you should be thinking about how you can help make all those things happen and let your team know you’re thinking about this.
The most important part of this is to take these implicit goals and make them explicit so that when you’re giving career advice you have a real set of metrics on which to evaluate situations and opportunities.
Tracking happiness comes down to not just monitoring careers, but also giving your team members opportunities to improve themselves, get recognized for the work they do and have a little fun along the way.
OTHER TIPS AND TRICKS
Delegate, but get your hands dirty. When moving from an individual contributor role to a leadership role, achieving a balance is one of the hardest things to do: initially, you’re inclined to do all of the work yourself, and after being in a leadership role for a long time, it’s easy to get into the habit of doing none of the work yourself.
If you’re new to a leadership role, you probably need to work hard to delegate work to other engineers on your team, even if it will take them a lot longer than you to accomplish that work. Not only is this one way for you to maintain your sanity, but also it’s how the rest of your team will learn.
If you’ve been leading teams for a while or if you pick up a new team, one of the easiest ways to gain the team’s respect and get up to speed on what they’re doing is to get your hands dirty—usually, by taking on a grungy task no one else wants to do.
You can have a résumé and a list of achievements a mile long, but nothing lets a team know how skillful and dedicated (and humble) you are like jumping in and actually doing some hard work.
Seek to replace yourself. Unless you want to keep doing the exact same job for the rest of your career, seek to replace yourself.
This starts, as we mentioned earlier, with the hiring process: if you want a member of your team to replace you, you need to hire people capable of replacing you, which we usually sum up by saying you need to “hire people smarter than you.”
Once you have team members capable of doing your job, you need to give them opportunities to take on more responsibilities or occasionally lead the team.
If you do this, you’ll quickly see who has the most aptitude to lead as well as who wants to lead the team. Remember that some people prefer to just be high-performing individual contributors, and that’s OK.
We’ve always been amazed at companies that take their best engineers and—against their wishes—throw these engineers into management roles. This usually subtracts a great engineer from your team and adds a subpar manager.
Don’t fall into this trap—these are the situations where you need to make the biggest waves and you need to make them now. Rarely will these problems work themselves out, and the longer you wait to address them, the more they’ll adversely affect the rest of the team and the more they’ll keep you up at night thinking about them.
By waiting, you’re only delaying the inevitable and causing untold damage in the process. So act, and act quickly.
Shield your team from chaos. When you step into a leadership role, the first thing you’ll usually discover is that outside your team is a world of chaos and uncertainty (or even insanity) that you never saw when you were an individual contributor.
Share as much information as you can with your team, but don’t distract them with the organizational craziness that is extremely unlikely to ever actually affect them.
Let your team know when they’re doing well. Many new team leads can get so caught up in dealing with the shortcomings of their team members that they neglect to provide positive feedback often enough.
Just as you let someone know when he screws up, be sure to let him know when he does well, and be sure to let him (and the rest of the team) know when he knocks one out of the park.
Lastly, here’s something the best leaders know and use often when they have adventurous team members who want to try new things often: it’s easy to say “yes” if it’s easy to undo something.
Intrinsic Versus Extrinsic Motivation
There are two types of motivation: extrinsic, which originates from outside forces (such as monetary compensation), and intrinsic, which comes from within.
A person has autonomy when she has the ability to act on her own without someone micromanaging her. With autonomous employees, you might give them the general direction in which they need to take the product, but leave it up to them to decide how to get there.
This helps with the motivation not only because they have a closer relationship with the product (and likely know better than you how to build it), but also because it gives them a much greater sense of ownership of the product.
The bigger their stake is in the success of the product, the greater their interest is in seeing it succeed.
Mastery in its basest form simply means you need to give someone the opportunity to learn new skills and improve existing skills. Giving ample opportunities for mastery not only helps to motivate people but also makes them better over time, which makes for stronger teams.
An employee’s skills are like the blade of a knife: you may spend tens of thousands of dollars to find people with the sharpest skills for your team, but if you “use” that knife for years without sharpening it, you will wind up with a dull knife that is inefficient, and in some cases useless.
Ample opportunities for team members to learn new things and master their craft will keep them sharp, efficient, and effective.
Of course, all the autonomy and mastery in the world isn’t going to help motivate someone if she’s doing work for no reason at all, which is why you need to give her work purpose.
Many people work on products that have great significance, but they are kept at arm’s length from the positive effects their products may have on their company, their customers, or even the world.
Even in cases where the product may have a much smaller impact, you can motivate your team by seeking the reason for their efforts and making this reason clear to them. If you can help them to see this purpose in their work, you’ll see a tremendous increase in their motivation and productivity.
One manager we know keeps a close eye on the email feedback the company gets for its product (one of the “smaller-impact” products), and whenever she sees a message from a customer talking about how the company’s product has helped the customer personally or helped the customer’s business, she immediately forwards it to the engineering team.
This not only motivates the team but also frequently inspires them to think about ways they can make their product even better.