Startup Engineering Management
3
Getting Started
Once you’ve accepted an engineering management role, this chapter describes the basic tools you will use each day. While these tools in and of
themselves will not make you a great engineering manager, they will keep
you from being the kind of manager who is so out of touch with his team
that they go elsewhere for help.
The 1:1
Most management should be done one on one (1:1). This is not to say
that group meetings are useless, but your most essential interactions with
people should be on a one to one basis. The meeting can be in a meeting
room, in an engineer’s cube, in your office, or even while walking around
outside. As a general rule, you should meet with every member of your
team at least once every other week, but the reality is that for good managers, such formally scheduled meetings are only the tips of the iceberg,
even if most casual encounters are of the “how are you doing?” variety as
you enter or leave the office.
It is important to keep such contact frequent and positive, because by default, managers come looking for engineers only when things go wrong.
15
Getting Started
If engineers learn that you bring only bad news and emergency debugging sessions, they will avoid you.
If there’s one thing managers fail to do often enough with highly talented
engineers, it’s to provide positive feedback. One of my favorite days when
working for Jeff Rothschild was him coming into my cube on Tuesday
one day and saying, “Hey, I heard that you invented a language, wrote
a byte-compiler and interpreter for it last weekend and had the working
implementation yesterday for the new product.” He didn’t even have to
tell me whether or not I had done a good job. That your manager pays
attention to your work is often enough to keep an engineer happy. For
especially introverted engineers, private praise is a much more positive
experience than singling out the engineer for an award in public, which
might make them uncomfortable. One well respected engineer at Facebook told me that he found public praise similar to being called out in
class, even though he always knew the answer when called upon—it felt
like he was being singled out as an example for others.
Many new managers are so uncomfortable with providing feedback that
they fail to provide any feedback whatsoever. When I was at Google, a
new engineer said to me, “I think I’m about to be fired. My manager
hasn’t talked to me for 3 months!” A lack of feedback does not mean
positive feedback, especially for a new or inexperienced engineer. Her
manager didn’t realize that, and hence neglected his engineer.
Formal 1:1s can be used to raise or bring up some of the following:
•
Improving the work environment. Are development machines
fast enough? Is it too noisy? Is it too difficult to coordinate with
another engineer who’s in a different building?
• Discussing negative feedback. Needless to say, the 1:1 is the best
place to bring it up for discussion. In general, try to look at the
problem behavior objectively, rather than placing it on the engineer. If there’s an obvious solution, (such as an in person meeting
to clarify an issue) discuss it.
•
16
Setting goals. While corporations generally perform goal setting
on a quarterly basis, I find that it’s too infrequent when it comes
to managing a team. Priorities change, and what was thought
to be an easy problem could turn out to be difficult, so you will
Startup Engineering Management
probably have to do this several times a quarter. In all cases, it is
best to phrase priorities as a question. If the entire’s team is affected by shifting priorities, you will probably have to discuss this
at a team meeting and during the 1:1s.
•
Gathering feedback about other people’s work. Although you
should be able to judge each engineer’s work for the team, you
can learn a lot by asking one engineer their opinion of another’s
work. Do the engineers respect each other? Does each engineer
discuss upcoming changes with team members that will be affected by those changes? Are engineers teaching each other?
•
Providing information the engineer wants. For instance, at
larger companies, there may be a formal engineering ladder and
promotion process. It would be useful to provide engineers who
are up for promotion an overview of what happens and what
is key for their next promotion. Sometimes, engineers might be
curious about the latest board meeting, or some other gossip that
might be circulating around the company. You will then either
have to say, “I don’t know” and appear clueless, or “I’ll find out
and get back to you.” If it’s particularly sensitive and can’t be
shared with the engineer, feel free to say so. That’s far better than
ignoring the question or lying to the engineer. Things change
frequently enough that you’ll inadvertently lie to people anyway
too often, so there’s no need to add to that.
•
Mentoring. You might want to provide tips on good working
habits; this is especially useful for new engineers. You might suggest not checking e-mail except for specific times of the day or
packaging changes in small sizes for easier review.
•
Setting expectations. I like my first 1:1 with engineers be about
expectations. In particular, I emphasize that it’s a two way street.
“I expect to give you continual and constant feedback about your
performance throughout the year. The annual performance review
is a paper process and takes too long. What that means is that if
your annual review is a surprise when you get it, I screwed up by
not providing you with sufficient and good constant feedback.
Let me know if you’re not getting the right kind of feedback!”
17
Getting Started
Things Not To Do During 1:1s
•
Skipping the 1:1 altogether. There is no better way to tell your
engineers that you don’t care about them than to cancel your 1:1s
frequently, or skipping them without notification. If something
comes up and you can’t make it, make sure you connect with the
engineer in some way to make up for it!
•
Status reports. These can be done via e-mail or by you subscribing
and reading engineering submits. There’s no reason to do these in
person since these are best done reflecting over a week or so.
•
Discussing problems that span multiple engineers’ scope. You
should do this over a meeting (formal or informal) to discuss the
problem. If such a problem arises during your discussions about
other topics, discuss who else is involved and whether a formal
meeting is required.
•
Settling technical disputes. While as the engineering manager
you’re able to settle many technical disputes by fiat, in most cases
it is best to let the team make the decision on its own. In fact, if
you have sufficient reports, for the most important technical issues it is most likely that you have spent the least time thinking
about them. Unless it is a gating issue, managers should stay away
from settling technical disputes via fiat.
Micro-management
If you have experienced and motivated engineers, micro-management is
to be avoided at all costs—your best bet is to get out of the way, providing
very subtle hints about where you want the group to go. Bill Coughran
(AT&T Bell Labs, Google) was the master of this. When he decided he
wanted my team to work with a certain group, he arranged to seat us next
to each other during a building relocation. We took the hint, and he did
not even have to have a meeting with us to discuss this.
There are situations, however, where micro-managing an engineer is
something you have to do:
• Unproductive engineers. If an engineer is having particular
18
Startup Engineering Management
problems delivering or is being deliberately unproductive, then
you have no choice but to micro-manage him. If you have to, that
means checking in with him every morning and every evening
to see what progress has been made. If you’re not getting results
that way within two weeks, it is time to initiate his exit from your
team (and preferably from your company).
•
Active coaching. For new tech leads and managers who might
not be confident in dealing with people, you might have to attend meetings and interactions with other engineers to see how
they are doing. In those cases, try not to intervene during the
meeting, but provide a post-mortem and a blow-by-blow recap to
the engineer after the meeting. This is one of the best methods for
training an engineer how to do interviews effectively.
Lunch Meetings instead of Group Meetings
The weekly group meeting is a long standing tradition in many engineering teams. While there might be good reasons to have one, frequently
they degenerate into what DeMarco and Lister in Peopleware call ritual:
a sequence of status reports between the engineering manager and an engineer with the others in the meeting listening in with minimal curiosity
and no involvement. If you examine the productive parts of those meetings, you will discover that the most productive sections happen when
someone otherwise tangential jumps into the discussion with a “oh, I was
just thinking about that problem the other day, and here’s what you do.”
But how can you get that part of the meeting without the boring status
reports ritual?
The engineering manager must work harder. In particular, status reports
should be done on a weekly basis and possibly informally with the engineering manager keeping his finger on the pulse of each engineer every so
often. When a problem comes up, either the manager suggests a meeting
or pulls in the appropriate engineers into an office to discuss potential
problems. To the extent that this doesn’t engage the entire engineering
team at once, that’s a benefit—it’s a time savings for everyone else who
didn’t need to be involved!
But surely there’s a role for the “all-hands” group meeting to happen?
Since the role of such meetings is largely ritual anyway, I suggest that for
19
Getting Started
most groups we treat it as a very important meeting and turn it from the
weekly engineering meeting into the weekly engineering lunch. By having everyone in the group show up and dine together on a regular basis
you do several things:
•
Dining together bonds the team together in a way meetings don’t.
•
The atmosphere is relaxed, and the engineering manager is one of
many, not the dominant personality in the group. This makes it
easier for the team to jell.
•
Any outstanding technical problems will naturally be discussed,
and in particular, you can take notes as to which problems involve external teams and resources that you should engage with.
•
In an informal environment, you can even get the quieter members of the team to speak.
I can’t emphasize how important dining together is for teams. Arup
Mukherjee, who managed Google’s web crawl team (known as WebMirror) considers it so important that he doesn’t just dine with his group once
a week—he does so nearly every day! The result was a highly focused and
very coherent team that could respond to changing needs in amazingly
quick fashion. New requirements were typically processed and rolled out
in a matter of days rather than weeks. For those of you with hands on
the purse strings, keep in mind that one reason why Google’s engineering
teams were so productive was that free on-site lunches made it possible
for nearly every one of Google’s engineering teams to dine together and
hence bond on such a daily basis. The net benefits were incalculable.
Good Uses of Group Meetings
20
•
Introduce new team members or to send off exiting team members.
•
Promotions and other such corporate rituals.
•
Milestone celebrations.
•
Technical presentations by members of the team to the entire
team. This could be a proposed design (or re-design) so everyone
Startup Engineering Management
on a team understands a sub-component, or a review of a piece of
infrastructure that everyone has to depend on.
•
Planning and Design, if they involve all members of your team.
Note that in most cases, design should be done by just the one
or two engineers responsible, rather than by the entire team. The
only design meetings that should involve more than those responsible should be where interface specifications are presented,
so that users of the design can provide feedback as to whether the
interface presented is reasonable.
•
Helping each other learn. If whole team is learning a new topic
(e.g., if MapReduce is new to everyone and you need it to implement garbage collection for your non-SQL database), then group
meetings are a good way to facilitate learning. You can break up
the topic into little presentations and have each person bone up
on a part of the new item and present it to everyone. Eric Veach,
when he led a team to design new routing algorithms for Google
Maps went as far as to have his team read papers on prior art for
a month before embarking on a design.
The careful reader will observe that most group meetings are rituals.
There’s room in the work place for such rituals (especially when bringing
in new members of a team), but by and large, think carefully before reflexively calling an “all-hands” meeting. If there’s any question as to whether
everyone might potentially make a contribution, then it shouldn’t be one.
Status Reports
Most managers are addicted to status reports, and frequently confuse a
highly productive engineer with one who’s good at keeping you updated
with his current status. The latter can look far busier while actually producing less! While I don’t want to dissuade you from asking for formal
written (or e-mailed) weekly status reports, I also strongly urge engineering managers to earn their pay by acquiring information through several
other channels:
•
Bug reports. In particular, track the number of bugs fixed, closed,
and re-opened by engineer, component, and release. This frequently turns up problems that are otherwise hidden. It should
21
Getting Started
be noted, though, that user-facing components frequently get
bugs misattributed to them when they would belong to some
other systems. Such mislabeled bugs can give you a skewed view
of product quality. It is also easy for people to file “bugs” when
their preference simply differs from the developer’s.
•
Checkins. In many source control systems, it’s possible to subscribe to changes being made by other engineers in the group.
You can use this to look for important changes that will affect the
entire group, or to provide positive feedback when someone gets
his work done ahead of schedule.
•
Actually test-driving the product under development. You can do
this yourself, or through usability studies, or by talking to actual
users of the output of your team.
•
Subscribe to the code review tool engineers are using if they’re
using one. If they’re not using one, propose a code review tool.
Even if you don’t have time (or the technical ability) to review
every code submit, you can still use the tool as a bully pulpit for
important initiatives. For instance, if one problem with the engineering culture is that tests are not valued and written, you can
chime in on every code review and ask “Where are the unit tests?”
if new code isn’t accompanied by the tests. By paying attention at
the code review level, you will drive engineers on the team to be
more vigilant about such issues. You have succeeded with culture
change when engineers on the team ask such pertinent questions
without you having to raise it!
Schedules
When software was largely sold on shelves and difficult to update once
it got onto a customer’s desktop, consumer/shrink-wrapped software
product was considered the pinnacle of software development. Since the
marketing roll-outs for such launches ran into the millions of dollars and
involved people standing in line to buy software (think of the Windows
95 launch), getting a schedule out of a team was critical, and countless
engineering books like The Mythical Man-Month were written. Slipping a
schedule could cost millions of dollars.
22