Created at: 2024-10-01
There are excellent quotes for a tech manager in this book. The reading is nice and easy, so good for times where the brain is not running on full pistons.
As you become more senior, the amount of personal feedback you get, both good
and bad, is likely to decrease. You are operating at a higher level, and your
manager is operating at a very high level. Expect the type of feedback to
change somewhat from personal feedback to team- or strategy-related input.
It’s even more important as you become more senior that you feel comfortable
driving your 1-1s and bringing topics for discussion or feedback to your
manager, because she is otherwise unlikely to spend a lot of time on this
outside of performance reviews.
Especially as you become more senior, remember that your manager expects you
to bring solutions, not problems. Try not to make every 1-1 about how you
need something, how something is wrong, or how you want something more. When
you have a problem, instead of demanding that your manager solve it for you,
try asking her for advice on how she might approach the problem.
There’s a difference between a strong manager and a manager that you like as
a friend, or even one you respect as an engineer. Plenty of great engineers
make ineffective managers because they don’t know or want to deal with the
politics of leadership in their companies. A strong engineer may make a great
mentor-manager to someone early in his career, but a terrible
advocate-manager for someone who is more senior.
So you find yourself mentoring a college student with little real experience.
How can you make sure that his summer is awesome? Even if your company
doesn’t love him, you want him to love you, because he’ll go back and tell
all his friends about the summer he had working for your company.
Listening is the first and most basic skill of managing people. Listening is
a precursor to empathy, which is one of the core skills of a quality manager.
You need this skill wherever your career takes you; even principal engineers
with no reports need to be able to hear what others are really saying. So,
when your mentee is speaking to you, pay attention to your own behavior. Are
you spending all your time thinking about what you want to say next? Are you
thinking about your own work? Are you doing anything other than listening to
the words coming out of his mouth? If so, you’re not listening well.
The alpha geek is driven to be the best engineer on the team, to always have
the right answer, and to be the person who solves all the hard problems. The
alpha geek values intelligence and technical skill above all other traits,
and believes these attributes should determine who gets to make decisions.
The alpha geek usually can’t deal with dissent, and is easily threatened by
those she perceives as trying to steal her spotlight or who might upstage
her. She believes herself to be the best, and responds only to messages that
support that view. The alpha geek tries to create a culture of excellence,
but ends up creating a culture of fear.
If you’re ever in the position to promote people to management, be very, very
careful in giving your alpha geeks team management positions, and keep a
close eye on the impact they have in that role. The alpha geek culture can be
very harmful to collaboration and can deeply undermine those who feel unable
to fight back. Alpha geeks who believe that their value comes from knowing
more than others can also hide information in order to maintain their edge,
which makes everyone on the team less effective.
Senior engineers can develop bad habits, and one of the worst is the tendency
to lecture and debate with anyone who does not understand them or who
disagrees with what they are saying. To work successfully with a newcomer or
a more junior teammate, you must be able to listen and communicate in a way
that person can understand, even if you have to try several times to get it
right.
The idea that the tech lead role should automatically be given to the most
experienced engineer, the one who can handle the most complex features or who
writes the best code, is a common misconception that even experienced
managers fall for. Tech lead is not the job for the person who wants the
freedom to focus deeply on the details of her own code. A tech lead who does
this is not doing her
The tech lead is learning how to be a strong technical project manager, and
as such, they are scaling themselves by delegating work effectively without
micromanaging. They focus on the whole team’s productivity and strive to
increase the impact of the team’s work product. They are empowered to make
independent decisions for the team and are learning how to handle difficult
management and leadership situations. They are also learning how to partner
effectively with product, analytics, and other areas of the business. It is
not required that an engineer work as a tech lead to progress, but it is the
most common way for engineers to grow from senior engineer 1 -> 2 and is
required to grow from senior engineer 2 to engineering lead. Realistically it
is very hard to grow past senior engineer 2 without ever having acted as a
tech lead, even on the individual contributor track, due to the importance at
senior levels of leadership and responsibility.
The work of breaking down a project has a lot of similarity to the work of
designing systems, and learning this skill is valuable even for engineers who
don’t want to manage people.
Becoming a tech lead required me to change my focus. Work is now less about
me and working on the most technically challenging idea or the most fun
project; instead, my focus is more on my team. How do I empower them? How do
I remove the obstacles slowing them down? Working on a rewrite, or some new
exciting feature that helped me express the full extent of my technical
prowess, might have been more fun, but what the team needed at the time was
to tackle technical debt and to focus on operations.
You also know that it’s important to get your team into a schedule that
allows them to be focused on development for long stretches of time, because
they will need to focus for several days on coding problems. Part of your
leadership is helping the other stakeholders, such as your boss and the
product manager, respect the team’s focus and set up meeting calendars that
are not overwhelming for individual contributors.
In your position as tech lead, you should continue writing code, but not too
much. Even if you are tempted to pull a rabbit out of the hat yourself, you
must communicate this obstacle first. Your product manager should know as
early as possible about any possible challenges. Enlist the help of your
engineering manager as needed. In a healthy organization, there is no shame
or harm in raising issues early. Teams often fail because they overworked
themselves on a feature that their product manager would have been willing to
compromise on.
Project management isn’t something that needs to happen in detail for every
single effort, and it’s overused in some organizations. I don’t even like
hiring project managers because they often act as a crutch for engineers to
use instead of learning to think through their future work and ask real
questions about what they’re doing and why, and their presence means that you
have more waterfall-style projects instead of an agile process. Still,
project management has to happen, and as tech lead, you should be doing it
when it is needed, especially for deeply technical projects.
Ultimately, the value of planning isn’t that you execute the plan perfectly,
that you catch every detail beforehand, or that you predict the future; it’s
that you enforce the self-discipline to think about the project in some depth
before diving in and seeing what happens. A degree of forethought, in places
where you can reasonably make predictions and plans, is the goal. The plan
itself, however accurate it turns out, is less important than spending time
on the act of planning.
Good managers are looking out for talented people who could be given bigger
leadership roles, but sometimes this leads them to push people away from
coding before they’re ready. This practice can have a very negative impact on
your career, because at more senior levels people who are considered “not
technical enough” can find it hard to be promoted into management positions
with more responsibility. It’s much easier to stay in a focused individual
contributor role and learn what you need to learn there than it is to try to
learn all of those skills while also learning management skills.
productivity of the whole team. Often, this means that you pay the price of
communication overhead. Instead of having every team member sit in a meeting,
you represent the team, communicate their needs, and bring information from
that meeting back to the team. If one universal talent separates successful
leaders from the pack, it’s communication skills. Successful leaders write
well, they read carefully, and they can get up in front of a group and speak.
They pay attention in meetings and are constantly testing the limits of their
knowledge and the knowledge of the team.
is to help their new reports create a 30/60/90-day plan. This can include
basic goals, like getting up to speed on the code, committing a bug fix, or
performing a release, and is especially valuable for new hires and people
transferring from other areas of the company. The more senior the hire, the
more he should participate in creating this plan. You want him to have some
clear goals that will show whether he’s learning the right things as he gets
up to speed. These goals will also require some work from you and from the
team, because it’s very rare that everything is self-evident, well
documented, and totally obvious to a newcomer.
Another approach that many experienced managers use is to help their new
reports create a 30/60/90-day plan. This can include basic goals, like
getting up to speed on the code, committing a bug fix, or performing a
release, and is especially valuable for new hires and people transferring
from other areas of the company. The more senior the hire, the more he should
participate in creating this plan. You want him to have some clear goals that
will show whether he’s learning the right things as he gets up to speed.
These goals will also require some work from you and from the team, because
it’s very rare that everything is self-evident, well documented, and totally
obvious to a newcomer.
Regular 1-1s are like oil changes; if you skip them, plan to get stranded on
the side of the highway at the worst possible time. Marc Hedlund
The downfall of the rambling 1-1 is that, if it’s left unchecked, it can turn
into a complaining session or therapy. Empathetic leaders can sometimes allow
themselves to get sucked into an unhealthy closeness with their direct
reports. If you start focusing a lot of energy on hearing reports’ complaints
and commiserating, you’re quite possibly making the problem worse. You don’t
have to have a to-do list, but problems in the workplace need to be either
dealt with or put aside by mutual agreement. There is very little value to
repeatedly focusing on drama.
When you get to the stage where you’re managing managers, a lot of your 1-1
meetings will be diving into details of projects they’re overseeing that you
don’t have time to dig into on your own. When you are managing only a handful
of individuals, the only time you should be using a 1-1 to do progress
reporting is when you have someone who’s off on a side project that you’re
not personally overseeing. Getting progress reports from people you’re
already working closely with is a waste of time because all you’re hearing
about is the delta of work between now and the last standup or project
review.
In the best case, there are a couple of clear themes that run through peer
feedback, and that you have observed, to comment on. Here are some examples
of themes that I have seen. There are people who: Struggle with saying no to
distractions and end up helping with other projects instead of finishing
their own Do good work but are hard for others to work with, tending to be
overly critical or rude in meetings, code reviews, or other collaborative
activities Struggle to break their work up into intermediate deliverables,
and don’t balance planning and design with getting things done Work well
with other engineers but do not work well with other departments or teams
Struggle to follow the accepted best practices of the team, cut corners, or
otherwise do sloppy work
The important thing for you to start doing now that you’re in management is
to learn how the game is played at your company. Every company has its own
variation of the promotion process, and you’re probably in this role because
you survived it. If you don’t know how it’s done, ask your manager for
advice. How are these decisions made? How early do you need to start
preparing packets? Are there limits on the number of promotions that can
happen in any given year? As you learn how to play the game, I encourage you
to be fairly transparent with your team. When members express the desire to
be promoted and they don’t have a strong case for promotion, telling them
what goes into the process will help them understand what they may need to
change.
As much as you may want to believe that management is a natural progression
of the skills you develop as a senior engineer, it’s really a whole new set
of skills and challenges.
if you don’t stay in the code, you risk making yourself technically obsolete
too early in your career. You may be on a management career path, but that
doesn’t mean that you should wash your hands of technical responsibilities.
In fact, I mention specifically in my engineering lead job description that I
expect managers at this level to implement small features and bug fixes.
Sometimes we let ourselves hang onto that brilliant asshole for too long. You
know, that person you think can’t be replaced because he’s just so productive
and so smart, but who isn’t a team player and makes everyone around him
unhappy. (For more on this kind of toxic employee, see “The Brilliant Jerk”.)
A less critical version of this situation is the person who just stirs up
drama, who dwells on negative experiences, or who spends a bit too much time
on gossip and playing games of us-against-them. You have to be brave and nip
people drama in the bud quickly. It’s OK to ask your manager for help with
this, especially if it’s your first time doing it, but be aware that your
manager may actually have an even harder time dealing with the brilliant jerk
than you do. She isn’t seeing the immediate impact on team dynamics; she’s
just seeing someone who gets things done. Be prepared to have a series of
conversations with both the employee and your boss. It may be that a move to
a different team will clear up the situation.
Using your managerial power to override technical decisions is usually a bad
idea. Resist the temptation to micromanage people — especially those who used
to be your peers. They’re going to be sensitive to the feeling that you’ve
been “rewarded,” even if they didn’t want to become managers themselves. If
you question their every move and try to make every single decision yourself,
you’ll make this sensitivity much worse.
It’s valuable for everyone to realize that they can and should focus on the
things they can impact and change, and ignore the things they can’t. Drama in
the workplace is usually little more than an ego-entertaining drain.
Don’t rely exclusively on consensus or voting. Consensus can appear morally
authoritative, but that assumes that everyone involved in the voting process
is impartial, has an equal stake in the various outcomes, and has equal
knowledge of the context. These conditions are rarely met on teams where each
person has different levels of expertise and different roles. As when the
team voted down Charles’s work, consensus can be downright cruel. Don’t set
people up for votes that you know will fail instead of taking the
responsibility as a manager of delivering that bad news yourself.
avoidant managers often seek conflict when it comes to other teams. They
identify strongly with their own team and will aggressively react to what
they perceive as threats from outsiders. When something goes wrong, like an
incident that spans across teams, the manager turns into a bully and demands
justice for his team, or blames the problems on the other team. Sometimes,
this behavior is an outlet for the manager’s suppressed feelings about his
own team. As one friend put it, “I was not telling my people the 10% of
things they needed to be improving because I was afraid they would miss the
message about the 90% of things that were good, and so I took that desire for
accountability out on other teams. I really just wanted everyone to be fully
accountable, and I needed to figure out how to express that internally and
externally in a healthy manner.” Do remember to be kind. It’s natural
Don’t take it out on other teams. Ironically, conflict-avoidant managers
often seek conflict when it comes to other teams. They identify strongly with
their own team and will aggressively react to what they perceive as threats
from outsiders. When something goes wrong, like an incident that spans across
teams, the manager turns into a bully and demands justice for his team, or
blames the problems on the other team. Sometimes, this behavior is an outlet
for the manager’s suppressed feelings about his own team. As one friend put
it, “I was not telling my people the 10% of things they needed to be
improving because I was afraid they would miss the message about the 90% of
things that were good, and so I took that desire for accountability out on
other teams. I really just wanted everyone to be fully accountable, and I
needed to figure out how to express that internally and externally in a
healthy manner.”
The real goal here is psychological safety — that is, a team whose members
are willing to take risks and make mistakes in front of one another. This is
the underpinning of a successful team. The work of gelling a team begins by
creating the friendliness that leads to psychological safety.
who, as we discussed earlier, produces individually outsized results, but is
so ego-driven that she creates a mixture of fear and dislike in almost
everyone around her. The challenge of the brilliant jerk is that she’s
probably been rewarded for a very long time for her brilliance, and she
clings to it like a life raft. Acknowledging that there is value in the world
beyond sheer intelligence or productivity would challenge her place in the
world and tends to be a scary proposition for her. So she bullies with her
intellect, cutting down dissenting voices in a harsh way, ignoring those she
believes are not her equal, and letting her frustration with anything she
sees as stupid seep out openly.
who, as we discussed earlier, produces individually outsized results, but is
so ego-driven that she creates a mixture of fear and dislike in almost
everyone around her. The challenge of the brilliant jerk is that she’s
probably been rewarded for a very long time for her brilliance, and she
clings to it like a life raft. Acknowledging that there is value in the world
beyond sheer intelligence or productivity would challenge her place in the
world and tends to be a scary proposition for her. So she bullies with her
intellect, cutting down dissenting voices in a harsh way, ignoring those she
believes are not her equal, and letting her frustration with anything she
sees as stupid seep out openly. These days, most places claim that they don’t
tolerate brilliant jerks, but I personally don’t believe that is true. It’s
incredibly hard for a manager to justify getting rid of someone who produces
great work, even though she’s a drain on everyone around her — especially if
this person is only irregularly a jerk. How much jerk is too much? You start
to run rings around the idea to try to justify keeping her on. You give her
feedback, and she gets a little bit better for a while, but then she gets
worse.
One variant of the toxic employee is the brilliant jerk, who, as we discussed
earlier, produces individually outsized results, but is so ego-driven that
she creates a mixture of fear and dislike in almost everyone around her. The
challenge of the brilliant jerk is that she’s probably been rewarded for a
very long time for her brilliance, and she clings to it like a life raft.
Acknowledging that there is value in the world beyond sheer intelligence or
productivity would challenge her place in the world and tends to be a scary
proposition for her. So she bullies with her intellect, cutting down
dissenting voices in a harsh way, ignoring those she believes are not her
equal, and letting her frustration with anything she sees as stupid seep out
openly. These days, most places claim that they don’t tolerate brilliant
jerks, but I personally don’t believe that is true. It’s incredibly hard for
a manager to justify getting rid of someone who produces great work, even
though she’s a drain on everyone around her — especially if this person is
only irregularly a jerk. How much jerk is too much? You start to run rings
around the idea to try to justify keeping her on. You give her feedback, and
she gets a little bit better for a while, but then she gets worse.
It takes a strong manager to deal with a brilliant jerk onboard. Expect her
to fight you tooth and nail on all feedback. This isn’t going to be easy on
either of you. The difficulty is, if she doesn’t see her behavior as a
problem, she won’t change it. It’s unlikely that you alone will be able to
convince her that her behavior is a problem. All the evidence in the world
can’t change a person who doesn’t want to change.
You have 10 productive engineering weeks per engineer per quarter There are
52 weeks in a year, or about 13 per quarter. However, realistically your team
will lose a lot of that time. Vacations, meetings, review season, production
outages, onboarding new employees — all of these things take away from focus.
Budget 20% of time for generic sustaining engineering work across the board
By “generic sustaining engineering work,” I mean testing, debugging, cleaning
up legacy code, migrating language or platform versions, and doing other work
that has to happen. If you make this a habit, you can use it to tackle some
of the midsize legacy code every quarter and get decent improvements.
Cleaning up systems as you go keeps those systems easy to work in, which
keeps your teams moving forward on new features. In the worst case, you can
use this slack to smooth over unexpected delays in feature development, but
if you fill the schedule to 100% with feature development, expect that the
feature development will quickly slow down as a result of this
overscheduling.
previous level is that your boss will expect you to be mature enough to
manage yourself and your teams independently. This means that your manager
trusts you to proactively deal with all those important but not urgent things
before they become urgent, and especially before they become urgent for your
manager. No one will tell you how to manage
One of the major changes at this level compared to the previous level is that
your boss will expect you to be mature enough to manage yourself and your
teams independently. This means that your manager trusts you to proactively
deal with all those important but not urgent things before they become
urgent, and especially before they become urgent for your manager. No one
will tell you how to manage your calendar to give yourself the time to do
this. I’ve seen managers fail at this point because they just could not
juggle all the different tasks in an organized fashion.
engineer, you have to accept that being that manager means that you by
definition can’t be that engineer. I know some people manage both, but you
need to decide, if you’re going to suck at one, which one that will be. I
feel bad when I suck at being an engineer, but sucking at being a manager
would be a choice I inflicted on other people. That’s not fair. So at the end
of another day when I feel like I didn’t write enough code and I have no way
to quantify what I’ve achieved, I tell myself I was being
If your team needs a manager more than they need an engineer, you have to
accept that being that manager means that you by definition can’t be that
engineer. I know some people manage both, but you need to decide, if you’re
going to suck at one, which one that will be. I feel bad when I suck at being
an engineer, but sucking at being a manager would be a choice I inflicted on
other people. That’s not fair. So at the end of another day when I feel like
I didn’t write enough code and I have no way to quantify what I’ve achieved,
I tell myself I was being as good a manager as I know how to be. And that has
to be enough for today.
carefully about dropping out of meetings, and part of the reason is that
those meetings are where you learn what healthy and unhealthy dynamics look
like. This is also why I strongly advise you maintain your practice of
regular, reliable 1-1 meetings with everyone who reports directly to you. If
you have too many people, you may need to shorten those meetings or hold
I recommended in the last section that you think carefully about dropping out
of meetings, and part of the reason is that those meetings are where you
learn what healthy and unhealthy dynamics look like. This is also why I
strongly advise you maintain your practice of regular, reliable 1-1 meetings
with everyone who reports directly to you. If you have too many people, you
may need to shorten those meetings or hold them biweekly instead of weekly,
but skipping 1-1s because you’re too busy with other things is a great way to
miss the warning signs of an employee who is going to quit.
Delegation is a process that starts slow but turns into the essential element
for career growth. If you teams can’t operate well without you around, you’ll
find it hard to be promoted. Develop your talent and push decisions down to
that talent so that you can find new and interesting plates to learn how to
spin.
Saying no to your boss rarely looks like a simple “no” when you’re a manager.
Instead, it looks like the “yes, and” technique of improvisational comedy.
“Yes, we can do that project, and all we will need to do is delay the start
of this other project that is currently on the roadmap.” Responding with
positivity while still articulating the boundaries of reality will get you
into the major leagues of senior leadership. This type of positive no is a
pretty hard skill for most engineers to master.
discusses several questions you can answer to help predict team productivity
and satisfaction. Among them are: Do I know what is expected of me at work?
Do I have the materials and equipment I need to do my work right? Do I have
the opportunity to do what I do best every day?
your team’s ability to do what they do best every day. Overfocusing on
building systems that are defect-free, or pushing for error prevention by
slowing down the development process, is often almost as bad as moving too
fast and releasing
An overemphasis on incident prevention can also reduce your team’s ability to
do what they do best every day. Overfocusing on building systems that are
defect-free, or pushing for error prevention by slowing down the development
process, is often almost as bad as moving too fast and releasing unstable
code. When risk reduction turns into weeks of manual QA, excessive and slow
code reviews, infrequent releases, or a drawn-out planning process, the
increased analysis can leave developers idle and restless, without
necessarily reducing the risk of incidents.
When you’re managing a people pleaser, one of the best things you can do is
show the person that he’s exhibiting the behavior, and highlight the
downsides. Sometimes all it takes is awareness that his habit of saying yes
is a problem for the team. Recognize that this usually comes from a personal
value of being selfless and caring about others, and honor these values even
as you try to correct the unhealthy behaviors. People pleasers, after all,
just want to make you happy.
As you may remember from your first time managing a team, you don’t know what
you don’t know. You probably did whatever good managers had done with you in
the past, if you had a good manager to emulate. Perhaps you got a little
training or read a book like this one, but more likely you muddled your way
through it. Unless, of course, you had a good manager yourself helping you
learn the ropes.
Overwork is also often a sign of another new manager danger: the person who
thinks she’s now in control, the taskmaster of the team, responsible for
making all of the decisions. Managers who neglect the job are bad, but
managers who take to the job with gusto because they believe it’s the key to
realizing authority are sometimes even worse. A manager on a power trip
domineers her team, and a skip-level meeting with more senior members of the
team will reveal their frustration that they have no ability to make
decisions themselves. This is slightly different from but related to the
micromanager, who expects detailed reports from every member of the team at
all times. The micromanager annoys her team to death by asking for
Overwork is also often a sign of another new manager danger: the person who
thinks she’s now in control, the taskmaster of the team, responsible for
making all of the decisions. Managers who neglect the job are bad, but
managers who take to the job with gusto because they believe it’s the key to
realizing authority are sometimes even worse. A manager on a power trip
domineers her team, and a skip-level meeting with more senior members of the
team will reveal their frustration that they have no ability to make
decisions themselves. This is slightly different from but related to the
micromanager, who expects detailed reports from every member of the team at
all times.
First-time managers are tricky because if they truly don’t have the
willingness to learn and aptitude to become solid managers, they’re a big
problem. Making the wrong person a manager is a mistake, but keeping her in
that position once you’ve realize she’s wrong for it is a critical error. I
am hugely in favor of making engineers who wish to go into management take
baby steps of mentoring and managing very small teams, but this is not always
possible and doesn’t always shake out problems that come with scale. Control
freak managers, for example, don’t often show up as clearly in smaller
management situations, instead holding that impulse back until they feel they
have the true authority of title. Keep an eye on your new managers. You may
need to provide not only coaching but strong corrective feedback in the first
six months.
In almost every model of motivation, people need to feel an understanding and
connection with the purpose of their work. Who are they building these
systems for; what is the potential impact on the customer, the business, the
team? Did they have any part in deciding these goals, and the projects that
they’re doing to achieve them? If not, why not? When you see a team spending
all of their time on engineering-sponsored projects and neglecting
product/business projects, it’s likely that the team doesn’t appreciate or
understand the value of the product/business projects they’re supposed to be
working on, and therefore they lack the motivation to tackle them.
Engineers often don’t want to estimate at all, or estimate beyond the
boundary of an agile sprint (generally two weeks). This philosophy is
completely reasonable if you believe that estimates must be fairly accurate,
that the requirements are unknown or will change frequently, and that most of
the work should be bound to features that mostly fit within one or two sprint
efforts. With that said, few of these things are always true. Estimates are
often useful even if they aren’t perfectly accurate because they help
escalate complexity to the rest of the team. Not every project necessarily
has requirements that change frequently, and it’s possible to do up-front
work to drastically reduce the unknowns that make software estimation
difficult. You may argue that the up-front work sometimes makes the overall
process take longer than simply looking at the project sprint by sprint, and
you may be right, but again, we’re not just talking about engineering teams
here. We’re talking about businesses that want to plan and get ideas of costs
for effort. We’re also, in some sense, talking about goal setting and
learning how to get better at understanding the complexity of our software
and systems.
Dedicate 20% of your team’s schedule to “sustaining engineering.” This means
allowing time for refactoring, fixing outstanding bugs, improving engineering
processes, doing minor cleanup, and providing ongoing support. Take this into
account in every planning session. Unfortunately, 20% is not enough to do big
projects, so additional planning will be needed to get major technical
rewrites or other big technical improvements. But without that 20% time,
there will be negative consequences with missed delivery goals and unplanned
and unpleasant cleanup work.
When an engineer comes to you with an engineering project that she wants to
do, think about framing the project by answering these questions: How big is
that project? How important is it? Can you articulate the value of that
project to anyone who asks? What would successful completion of the project
mean for the team?
I’ll leave you with some advice my own VP of Engineering once gave me:
“Wanting to be a CTO (or VP of Engineering) is like wanting to be married.
Remember that it’s not just the title, it’s also the company and the people
that matter.” Titles are definitely not everything.
It can come from placing a high value on being correct and following the
rules, and having a strong affinity for hierarchy-based leadership. I also
believe that coming from places where conflict was openly tolerated, if not
actively encouraged, made me even more likely to create this culture.
How do you know if you’re creating a culture of fear? It can come from
placing a high value on being correct and following the rules, and having a
strong affinity for hierarchy-based leadership. I also believe that coming
from places where conflict was openly tolerated, if not actively encouraged,
made me even more likely to create this culture.
Apologies don’t need to be drawn-out affairs. A short apology that takes
responsibility for your role in creating a negative situation or hurting
another person is all that is necessary. If you go too long, it often turns
into an excuse or a distraction. The goal with apologizing is to show people
that you know your behavior has an impact on others, and to role-model for
them that it’s OK to make a mistake but that you should apologize when you
hurt other people. You’re showing the team that apologizing doesn’t make you
weaker — it makes the whole team stronger.
is a piece called “The Tyranny of Structurelessness” by Jo Freeman. While the
article is about early feminist/anarchist collectives, Freeman’s insights
apply equally well to startup culture. Pretending to lack structure tends to
create hidden power structures resulting from the nature of human
communication and the challenges of trying to scale that communication.
Interestingly, Freeman describes a set of circumstances in which the
unstructured group can, in fact, work:
Structure grows as the company grows and ages. In fact, there’s even a law
that accounts for this, from John Gall’s book Systemantics:1 A complex system
that works is invariably found to have evolved from a simple system that
worked. A complex system designed from scratch never works and cannot be
patched up to make it work. You have to start over with a working simple
system.
When every new hire slows the team down for months because there is no
onboarding process, that is a failure due to lack of structure. When people
regularly leave the company because they have no path to advancement or
career growth, that is a failure due to lack of structure. The third time you
have a production outage because someone logged directly into the database
and accidentally dropped a critical table, that is a failure due to lack of
structure. I said earlier that I prefer to talk about learning and
transparency rather than using the word structure, because really what we’re
talking about here is identifying the causes of failures, especially frequent
failures, and trying to figure out what we can change to solve for those
failures. This is fundamentally about learning.
What is the lowest level at which people can sit forever, never getting
promoted but also not underperforming? This is your breakpoint level. For
many companies, it’s somewhere around senior engineer. Someone who’s made it
this far is a solid team member, but he may stay at this level indefinitely
by his own choice. It’s good to have a notion of where this is. You may even
want to use it as the point at which your ladder levels get harder to
achieve. Expect your team to cluster around this level, with fewer people
above or below it.
Be clear about code review expectations. For the most part, code reviews
don’t catch bugs; tests catch bugs. The exceptions to this rule are that code
review can catch missing updates to comments or documentation or missing
changes to related features, and code reviewers can sometimes tell when there
is inadequate testing of the new or changed code. Code review is largely a
socialization exercise, so that multiple team members have seen and are aware
of the changed code.
Use a linter for style issues. Engineers can waste absurd amounts of time on
questions of style, specifically formatting. This should not be up for debate
in code review. Decide on a style, and put that style into a linter that
formats the code automatically. Allowing style to be up for discussion in
code review often leads to nitpicking and criticism that can feel
unproductive at best, and bullying at worst.
Resist the urge to point fingers and blame. It is incredibly tempting, after
a stressful outage, to point fingers and ask people why they failed to
foresee the consequences of their behavior. Why did they run that command on
that box? Why didn’t they test that? Why did they ignore that alert?
Unfortunately, this blaming only results in people being afraid to make
mistakes.
Meditation isn’t a cure-all, but it can be a useful exercise to practice that
awareness of your own reactions, and for that reason I recommend trying it
for a while if you are interested. Some of my favorite resources include the
podcasts on tarabrach.com and the writings of Pema Chödrön.