Kevin Gibbs

Thoughts on engineering and management.

Build a team they'll never leave: the 4 things that matter


I’ve mentioned before that keeping people on your team is one of the most important tasks that a manager has. It’s hard to hire people, and it’s harder still to hire great people. But the hardest task of all is keeping those great people on your team, month after month, year after year. Once you have hired and put together your team, as a manager you should then treat that team like your most valuable possession. You should do everything you can to build an environment where your employees want to stay.

On engineering teams, I have found that there are four things that are primarily responsible for creating an environment where your team members will want to stay. They are:

  • Mission
  • Family
  • Compensation
  • Growth

If everything else within your organization is more or less reasonably managed and stable, then these four areas will become the drivers that will get people to stick around. You can think of them as four independent dimensions that your team can excel in. When you do excel in these areas, you’ll create an an environment where people are happy to come into work and want to stick around in your group, not just for the first few months, but forever.

If you can build a supportive environment around 2 of these areas, like Compensation and Mission, or Family and Growth, then you’ll likely get a solid team that will stick together for a good amount of time. But if you can excel in 3 or all 4 of these areas, then you’ll have something remarkable—a team that your engineers will never want to leave.

Let me talk about what I mean by each of these four areas in turn:


Having a Mission means that you (and your team) are working on something that is bigger than your product or your company.

It means that you’re doing something that you honestly believe will make the world a better place. A Mission is something that gives people passion, and makes someone feel like they are working on something larger than themselves. Importantly, though, your Mission doesn’t need to be (and usually isn’t) the entire endeavor of your team or your company. Rather, the Mission is usually an aspect of the work you are doing: your team isn’t primarily trying to end world hunger, but your new low-cost gardening tool may have a huge impact on farmers in the developing world.

In other words, a Mission in this context can be one part of what you are doing, like providing a new way for groups to quickly organize and communicate (Twitter), or letting anyone in the world run an app for free (Google App Engine). The Mission doesn’t have to be your team’s main thrust. But a Mission is something that gives them a purpose.

A Mission is a dream to follow that provides motivation to your team when times are lean or when the work is hard.

It should be clear that if you work at a business software company, it’s not enough to say that your Mission is “Increasing productivity for e-businesses everywhere.” That is not a Mission. But take Wal-Mart. Wal-Mart may not seem like a paragon of corporate virtue or idealism. But try this Mission on for size: Wal-Mart will relentlessly do anything they can to save the average Joe a little more money every month. Legitimately, love them or hate them, Wal-Mart is making some goods and dreams a reality for many folks who never thought they could have them. If I worked there, I’d fight for that.

A Mission is a dream, a vision, that gets you out of bed in the morning and puts that starry look in your eyes. It’s defined not in terms of profits or pageviews, but in terms of actual people, human beings, and how you’ve changed their lives. If you can provide your team a Mission, one that they truly believe in, then you’ve got one of the most powerful things out there to keep people on your team.


Feeling like a Family means that you feel a real, emotional, connection with your teammates.

That means you look forward to seeing the people you work with. You like spending time with them. They make you smile, you’ve been to their houses, and you know them well enough to make jokes with them or tease them at lunch.

Family means having co-workers that you’d like to spend an afternoon with, even if you didn’t have any work to do.

A feeling of Family is hard to build. In my experience, Family usually comes from having one or two key extroverts on your team that form the glue that brings everyone else together. These key people are usually charismatic folks, social butterflies, who manage (just by being themselves) to make everyone else feel more relaxed and comfortable. They set the tone for relationships on the team. Sometimes these folks are the ones in charge. But more often these social folks are just members of the team, people that bring everyone else out of their shell, pop a few jokes here and there, and get relationships and friendships forming.

Having a team that feels like Family should not be confused with simply getting along with your coworkers, or respecting them. Family are people that you miss when they’re gone. They are people that would make you want to come into the office every day even if you were digging latrines together, rather than writing code.


Compensation, unlike the rest of the areas I’ve talked about, is pretty simple. It’s money.

Money can be in the form of dollars that have value today, or it can be in the form options or other compensation that your team believes will be valuable later. But mostly, it’s about cash on hand right now. When you’re dealing with Compensation, you’re competing with the big companies, who have big salaries to throw around, and the hottest startups, that already have billion-dollar valuations and options or RSUs that seem almost as good as cash.

In most situations, the compensation that really matters for employee retention isn’t equity—it’s the salary that you pay out each month.

Another way to look at this is that the salary that you give your employees is what they’ll bring home each month to share with their partner or their family. Their salary is what determines whether they’ll be having ramen or going out to Gary Danko tonight. Salary has an emotional affect on how you feel right now, and on the various decisions and comforts that are part of your daily life. And comfort and your family situation, over the course of years, usually has a bigger impact on the decisions in your life than a percentage of equity.

Although in some ways compensation is the hardest of these areas for a manager to change, in other ways it is the easiest. Improving Mission, Family, or providing Growth takes careful, sensitive planning, sometimes over years. Improving Compensation just takes a number. It may be a gamble for you, and it may increase the risk of your startup’s balance sheet, or it may raise your team’s profile and expectations at a big company.

But when thinking about Compensation, it’s important to remember how hard it was to hire the stars on your team, and where you’d be over the next 3 quarters if one of them was to suddenly leave. Lack of money can wear someone down over time, often in ways they may not even be aware of. The impact of Compensation may be silently influenced by a partner, a peer, a new job offer, or a life change you don’t know about. Compensation can have a real effect on whether someone will stay on your team, in ways you may not be able to see until it is too late.


Fostering Growth means making sure that each member of your team feels like they have concrete opportunities on the horizon for personal growth and advancement.

Most often, Growth means that people feel like they have a chance to be promoted. But Growth can mean many other things as well. Growth can be the opportunity to eventually lead a team, or the chance to learn a new type of task from some more experienced peers. Or Growth can be the opportunity to change your role, say from engineering to management, or from sales to product design.

Not everyone cares about this area. Across the people I’ve managed, of all ages and backgrounds, I’ve seen the whole spectrum: those who’ve happily done the same job for 5 years with little change or interruption; those who want to grow a little bit each year, with a few new types of tasks and challenges; and those who are so aggressive about advancing themselves that they need a big new challenge to work towards constantly.

For those who do care about growth, this area is critical. Moreover, the engineers interested in growth are often the overachievers, the informal organizers, and the quiet, dedicated folks that do the critical work that holds your team together. They’re the folks that want to channel their passion, their competitiveness, or their love of learning into their job. If you’re smart, you’ll give them a path so that they can find good reasons to keep channeling that passion into your team.

If nobody on your team cared about personal growth, you probably wouldn’t have a very talented team. Everyone became as talented as they are today somehow.

At a large, growing company, or at the hottest startups, you may not have to worry as much about providing new opportunities. Fast growing teams always have something new and exciting coming up, as they restructure and expand.

But the meteoric rise of those companies are the exception, not the rule. At most companies and in most situations, things change slowly. It’s not unusual for a group to grow by adding only a single engineer a year. Thus, as a manager, if you want to keep people engaged and excited about their future, you need to plan for their growth, and create opportunities for them, rather than waiting for opportunities to happen. It’s your job to ensure that each person on your team has a ring to reach for, whether or not that planning comes at a convenient time for you.

I’ve worked on a number of teams in my life, and it’s interesting to look back on those experiences in the context of the four areas I’ve talked about above.

At IBM, my team was strong in one of these areas (Family), and I stayed for about 2 years. On the Infrastructure team at Google, which I felt was strong in two of these areas (Growth, Compensation), I stayed for three and a half years. The App Engine team, which I’ve tried to run with all of four these ideals in mind (to some level of success), I’ve stayed on for 5 years. I’m still there today.

When you’re thinking about your own team, it’s helpful to think about which one of these areas you think your team is the weakest in. Thinking about which of your areas is weakest is easier than trying to figure out which of the areas you are strong in, because it’s tough to be both objective and complimentary about yourself. (I think it’s a little easier to be honest about your shortcomings.)

Once you’re thinking about one specific area you’d like to improve on, it can be surprising the small changes that are within your reach that can make a difference. Here are some examples of small changes that I’ve made over the years on my teams that had an impact:

  • Family: Introduced a team lunch on Fridays, where everyone left the office together.
  • Compensation: Spot bonuses after a big launch. They’re easier to afford than a raise, and they show people directly that you notice and appreciate them.
  • Growth: Earmarked people to lead specific upcoming projects—and let them know about it. It’s not a guarantee, but it gives the person a plan and makes you transparent.
  • Mission: Told a story from my childhood that connected me to our team’s mission, and explained how. I got emotional about it.

When you’re leading a team, it’s easy to get distracted by the urgent stuff, and miss the important stuff. Perhaps unsurprisingly, “employee retention” and a well-balanced work environment will never seem like an urgent topic. But it does matter. Spending time to emphasize the meaning behind your team’s work, fostering comfortable and relaxed personal relationships, giving each person on your team a meaningful future opportunity to work towards, and then budgeting enough money to show everyone that you mean it, matters.

As a manager, I have found that focusing on these four areas will help get your team to stick around.

Written by Kevin

March 19th, 2012 at 3:09 p.m.

Posted in Management, Teams

Ed Catmull: 1000s of little ideas


One of my favorite quotes about engineering is from Ed Catmull, the head of engineering at Pixar. It’s a great insight into the reality of how amazing products are made.

There is a confusion, I thinkā€¦ in that we think about “an idea.” When we think of ideas for movies, we think about ideas for products. And it’s usually thought of the some singular thing. But the reality is, their successful movies – as with all successful products – have got thousands of ideas. It’s just all sorts of things necessary to make it be successful. And you have to get most of them right to do it.

Written by Kevin

October 14th, 2011 at 12:59 a.m.

Posted in Quotes, Engineering, Teams

3 suggestions for engineering managers


Software companies, even successful software companies, often have trouble hiring and retaining good engineering managers. Software engineering management isn’t a career you generally study in school, or that you get specific training for at work. Thus, there isn’t a pipeline of new engineering managers being created in the way university computer science programs are creating programmers. Beyond problems of supply, many of the managers that are hired and retained by software firms are often regarded as not being very credible or effective by the teams that work for them. For many programmers, the reaction they have to managers is a wish that they didn’t have one.

I got into engineering management as a result of this gap. When my boss Vic asked me to take over management of the team I was leading, I initially wasn’t wild about it. I loved my job as an engineer, and I loved my team, and I was hesitant to change that relationship. At the time, though, I already realized that this gap between the demand for managers and good candidates existed, and I didn’t feel great about what manager my team might get if I didn’t take the reins. So I dove into the role, and I started learning on the job.

Since then, I’ve learned a few things that I believe help separate good engineering management from the sort of management that you wish, maybe, just wouldn’t come into the office today. These are the three guiding principles that have worked for me as a manager.

Do the Work

The members of your team need to feel like you (as a manager) can do the work they are doing as well, or almost as well, as they can. That’s a tough thing to do, and I know a lot of people in a management role might feel like this objective is out of their reach. But I think it’s perhaps the single most important trait of a good manager.

You can’t lead a group of engineers if you haven’t worked intimately, for months, on the same codebase that your engineers have. Period.

Until you’ve done the job of the people on your team, and done it well, it is very hard for the people working for you to respect you. Why should they? If they think you don’t really know the system or the area they are working in, they’re probably right. If you haven’t tried to earn your team’s respect, by showing them that you have done their job and know how they feel, you’re always going to have the bozo bit set when talking to your team. They may listen to you, and they may well do what you say, but they’ll always perceive you as someone who doesn’t understand, someone from the outside— someone who’s architecting from the bench.

When you’ve worked in your team’s codebase, and you know for your specific team why various individual engineers are respected more or less because of what they’ve done, you can hope to interact with your team on engineering topics from common ground— and hopefully with a deep reservation of shifting decisions from the smart guys on your team, because you respect what they do. You’ve done it, too.

Getting to know your team’s code, and working in their codebase, doesn’t need to feel like an insurmountable goal. It’s important to remember that when diving in to the code of the project, you don’t need to become the best engineer on your team. In fact, you don’t need to become a mediocre engineer on your team. Your goal is just to learn enough to have a meaningful involvement with the project, and your team. Move slow. Take on a small bug or feature first. It’s OK to need a lot of help, and to have to do a lot of reading. Your team will be impressed that you’re humble enough to learn from them.

For managers that have never worked on the code that your team works on, I know this task will seem hard to do. You might nod, acknowledge the benefit, but not get around to it. You’re too busy right now, you’ve got a a full schedule every week, maybe 6 months from now.

But just do it. It’ll be the best 3 months you ever spent.

Be a Shit Umbrella

You’ve probably heard this expression applied to managers by now: “You can either be a shit funnel, or a shit umbrella.” If you haven’t, here’s a quick explanation: Umbrellas see their primary role as shielding those under them, protecting them from the problems that come down. Funnels see their role as directing the problems they receive down to the people who work below them.

The dichotomy between umbrella and funnel is first off a matter of attitude— a matter of whether you as a manager consider your primary purpose to be looking good in front of your own boss or being a good boss to the people who report to you.

Being a shit umbrella for your team (pardon my French) is a critically important part of being a good manager. Being the umbrella will be the most unappreciated, and unnoticed, thing that you’ll do as a manager. When you’re doing it right, your employees don’t notice anything at all— they just notice that they enjoy their jobs more. Over time, they may talk to their peers at other teams or companies, and realize that they’re in a pretty good situation— no pointless meetings, no unnecessary interruptions, no random changes of course, no new problems from on high dumped in their lap each month.

But they may never notice. You don’t become a shit umbrella so that anyone will notice. You do it because it’s probably the single most important thing you can do to make your team effective and happy. But more importantly, you do it because engineers will get more done under an umbrella— and getting more done ultimately makes you more effective at your own job.

Although the difference between an umbrella and a funnel is a matter of attitude, in practice being a shit umbrella is an instinctive response. Say your manager hands you a problem with a new set of requirements, ones that you don’t believe in and that were unexpected. As he describes this new request to you, immediately your stomach churns and your anxiety levels rise. What’s your first response? If your first thought is to dodge, question the problem, drag out the conversation, try to broker a solution with him, cajole and use any trick to get out of it you can think of, then you might be a shit umbrella.

If your first response is to nod politely, and say you’ll handle it, and then to immediately schedule a meeting with the best member of your team— well, then you might want to take a harder look at what you just dropped.

Every Day, Earn Their Loyalty

As a manager, having a team that is loyal to you is priceless. Every manager knows that getting, and then keeping, the right people on your team is your most important task. Everything else you do is just a means to that end: building and holding together a great team.

When trying to keep a great team together, loyalty is a more important factor than many managers realize. It’s also easier to cultivate than you think.

A team that feels loyal to you as a manager is a team that stands by you in hard times, sticks with you longer, and recruits their friends to join them. But a team’s loyalty is not automatic. Any engineer that’s been around for a while knows that important-sounding positions and titles aren’t worth the card stock they’re printed on. Your team’s first reaction to you is likely to be wary and skeptical.

In my experience, the primary motivators of professional loyalty among engineers are personal admiration and self-interest. The first factor is irrational, but the second factor makes sense: you stick with those that you believe will continue to work in your interest.

The missing link, then, is finding a way for you to demonstrate to your team that you are the best game around for their self-interest: a compromise between your needs as manager and a leader, and your employees’ expectations of reward and fairness.

The way you achieve this goal as a manager is by being completely, obsessively fair, in every little thing you do.

When you are a manager, or a team lead, you’re in a position of incredible of power. It might not seem so: after all, we’re only talking about the little details of daily work, and most of the decisions a manager makes each day are small.

But each one of those decisions is not small to the people working for you. In engineering, and in our modern culture, a tremendous amount of self-worth and identity comes from the workplace. Which project your team members get to work on, what specific words you use when providing them feedback, who gets a 4% raise and who gets 5%: each one of these little decisions matters the world to your team. And because those decisions are usually made in private, by you, your team is trusting you to be fair. They have to.

Being worthy of your team’s trust every minute, of every day, is what earns you your team’s loyalty.

Because you have so many little decisions to make, so many tradeoffs to make, it’s very easy as a manager to lose sight of how much these decisions matter. And the worst part is that you know that most of the time, your team will never know if you don’t give each of these little decisions the attention they deserve. So what if you phone it in, and just re-use your performance ratings from last quarter? They’re pretty close, and nobody will know.

But you’re wrong. Over time, your team will know. It’s a slow, very slow thing, because it’s the sum of a million little decisions and a million little reactions that your team only hears echoes of. But it’s the sense of confidence that comes from hearing the correct echoes over time that creates trust. People become loyal to you because they find that they can trust you to represent them fairly over time.

So there’s only one way to earn your team’s loyalty. You have to always be completely, entirely, 100% fair, in everything you do for and between your employees, no matter how tedious it gets and how much paperwork piles up. This may be hard to do, but you will never know which detail is going to be the one that comes back to bite you. If word of an unfair decision gets out, taking just one shortcut, performing just one lazy injustice, puts you at risk of losing you all the trust you’ve earned with your team members. So don’t let up. Be worthy of your team’s trust every minute of the day. Doing this is something your employees can’t detect in the first 3 months, or in the first 6 months. But around the first year of working with you, when everything they’ve heard in the hallways sounds right, and they’ve seen the right people get rewarded and the wrong people left behind, the members of your team may start to feel confidence in you.

And as time goes on, it’s that confidence that inspires their loyalty.

This management gap isn’t going away. The rate at which students are enrolling in computer science programs, and that we are creating programmers, is increasing rapidly. But the rate at which we’re training and educating managers isn’t. That said, no matter how good or bad a manager is, the most important thing about any engineering team will always remain the engineers themselves. A great team will usually survive a bad manager, but a great manager can’t turn a bad team into gold.

However, for a good engineering team, a good manager can make a dramatic difference in how effective that team is— how happy the team members are, how effectively they work, and how long they stick together. These three suggestions represent the principles that have worked for me as an engineering manager.

Written by Kevin

August 19th, 2011 at 1:39 p.m.

Posted in Engineering, Management

Who and Why


Welcome to my blog. It’s difficult to know what to write in a first post, as the point of a blog is to get to the meat of the subject you want to talk about, not to make needless introductions.

With that said, here’s some background in rapid-fire format:

  • Why? I wanted an outlet for insights I’ve had while leading engineering teams.
  • Who? Me. I’m a software engineer by background, and a combination of software engineer / tech lead / product person / engineering manager by trade.
  • Why do I come to work every morning? Because I love building products.
  • Why should you care? I haven’t seen many people talk about leading engineering teams, or about what makes management work (and what doesn’t).

Often, when someone wants to have a beer with me and pick my brain about something, I’ve found that’s what they want to ask about: how do you manage successful teams?

This blog is my answer to that question.

Written by Kevin

June 29th, 2011 at 12:55 p.m.

Posted in Background