management


## Why is it important to talk about what can be expected from senior engineers?

- Align expectations within the team: what does it mean to be "senior"?
- Set career goals for everyone: what do I need to learn to become "senior"?
- Influence behaviors: what's ok & what's not ok?

## Side note: what about "junior" engineers?

It makes sense to have a specific job title for "senior": not only does it
validate somebody's career progression, it also serves as a clear signal that
the person has extra responsibilities.

That being said, I don't think we should have a job title "junior engineers" as
the entry level title for software engineering. People might resent their lack
of experience being constantly reminded to everyone by having "junior" in their
title. This might be purely about communication, but I find that "we need
an experienced engineer for this job" more positive than "we can't have a junior hold
this role".

## The technical and the management career track

Most companies distinguish between the technical and the management track:

- Technical
  - Engineer
  - Senior Engineer
  - Staff Engineer
  - Principal Engineer
  - Fellow
- Management:
  - Manager
  - Senior Manager
  - Director
  - VP of Engineering
  - CTO

In such a two-track system, becoming a manager is **not** a promotion. It is a completely different role, so it should be considered a lateral move.

In this presentation we will focus on the **technical** track.

## How can we define a senior engineers?

There are multiple ways to define a senior:

- **Autonomy**: senior engineers can work with very little supervision, and can provide direction to less experienced members of their team.
- **Skills**: [some](https://frontside.com/blog/2016-07-07-the-conjoined-triangles-of-senior-level-development/) see senior engineers at the intersection of technical capability
  (rigor, discipline, propensity to ship, etc.), leadership (owner's mindset,
  communication, persuasion, purpose...) and connectedness (mentorship,
  courage, honesty, community...).

Those are useful but I find it easier to think about impact level. At what
level do we feel this person's impact the most?

- Engineer: task, user story
- Senior Engineer: team and its projects
- Staff Engineer: org or company
- Fellow: industry

To get a feel for what a fellow can achieve and the kind of enormous impact they can have, here's Google Fellow Jeff Dean's shortened résumé:

- v1 of Google's ad system
- 5 versions of Google's core search systems
- MapReduce
- BigTable
- GoogleTranslate
- TensorFlow

Jeff Dean's such a legend that folks have been compiling this hilarious [list of Jeff Dean facts](https://github.com/LRitzdorf/TheJeffDeanFacts).

For now, we'll have this definition:

_Senior engineer_: person whose impact is felt throughout the **team** from a technical **and** organisational standpoint

Some companies expect engineers to become seniors within 5-7 years. If they
don't reach that level in this timeframe, they are politely asked to find an
opportunity for growth elsewhere. Also, some companies consider this level
a "career goal", i.e. it is acceptable to stay at this level your whole career if you
want.

## What to expect from seniors?

In the shortest form:

- Senior engineers **ship** business value
- Senior engineers **lift** people up

Peter's principle states that people get promoted to their level of
incompetence. In most places, you are promoted when you are doing great at your
current level, which logically implies that you'll end up being promoted
one time too many.

To avoid that, it is usually better to promote once you are
effectively performing at the next level. So, even though below we say "senior
engineers do X" and "senior engineers don't do Z", that does not mean you
should not try to do that if you're not senior yet. Quite the contrary.

### ✅ Shipping pattern: rock-solid engineering.

![bridge not connecting image](https://i.imgur.com/Col3C6c.jpg)

It all starts with strong technical chops, and a ton of respect for software engineering as a craft. Senior engs invest in continuous learning and self introspection. They should make the right technical decision most of the time, based on either data or (hard-earned) intuition.

When building, they should take into account functional and non-functional
requirements. In the image above, while the specs might have stated the maximum
weight the bridge should be able to sustain, it might not have specified the
obvious, i.e. that the two end should meet. The same happens in technical
projects: product managers often focus on features, but that does not mean
that the feature should be unstable, or slow, or incorrect. It is your role as
a senior engineer to anticipate.

### ✅ Shipping pattern: sharing product and project ideas

![problem solving as imagined by each role](https://i.imgur.com/WTfvRiv.png)

A senior engineer finds unique ways to leverage technology to bring business
value. For instance, they will deploy an off-the-shelf solution so that the
marketing team can self-serve sending promotional emails.

They see their role as a partnership with product management - not as executing
whatever the PMs have cooked up for them to work on. They will constructively
criticize designs, product roadmaps etc.

This applies to product and platform senior engineers: just because you're
working on infra does not mean you don't have an impact on product, quite the
contrary: how can you help other product engineers ship product features faster
and at a higher level of quality?

### ✅ Shipping pattern: leading projects

In startups, it often feels like everything has to be reinvented, including how
we deliver projects. It often leads to reinventing the wheel, process-wise, and
disguising common sense concepts under preposterous terms.

Yet the concept of project (delivering something of value before a specific date) is really at the
core of what engineers work on, and senior engineers should take the lead on
them, owning their success.

It starts with understanding their raison d'être and being relentless on
aligning the team with the project's objectives. Identifying blockers, risk and
dependencies (usually the three of them are the same...). Splitting
a large effort into subprojects and subtasks and finding owners for them. Not
being afraid of giving estimates (if you ever work on a project
without a deadline - that means nobody cares about it) and communicating
proactively about delays.

### ✅ Shipping pattern: act like a CEO

"Extreme ownership" speaks for itself. Senior engineers don't wait to be told.
They have control over their team's destiny.

### ✅ Shipping pattern: be the unblocker

An undervalued skill in engineering (and companies in general): courage.
Courage with perseverance work great together!

> Learn to never, ever accept being blocked; find a way by persuasion, escalation, or technical creativity. (Dan Heller, [Ten Principles for Growth as an Engineer](https://medium.com/@daniel.heller/ten-principles-for-growth-69015e08c35b))

### ❌ Shipping antipattern: being dogmatic

![image nail with hammer](https://i.imgur.com/n4eFAHN.png)

Not understanding the ETTO principle (Efficiency/Thoroughness Trade-Off) leads
senior engineers to be blocked by over-engineering. Technical debt is not a bad
thing if it's maintained (the sad thing about technical debt is that it's often
confused with recklessness). Also: YAGNI (you ain't gonna need it).

This is also about perception: a strong senior engineer knows that technical
decisions need to be communicated crisply, showing the tradeoffs that have been
weighed. The section "ideas considered but dropped" of an RFC is usually the
most useful.

### ❌ Shipping antipattern: thinking only about code

Senior engineers understand that code is not the only thing that needs to happen for a project to be successful.

### ❌ Shipping antipattern: expecting PMs to do your job

Product managers do not lose sleep over tech debt. Senior engineers understand
that maintaining the technical quality of their platform is their
responsibility. They keep the business team up to date with their upcoming
plans for reducing technical debt, fixing up technical risks, etc.

### ❌ Shipping antipattern: all talking, no coding

At the end of the day, senior engineers are still expected to ship code,
because that's what it takes to deliver most products. Just because it is
important to communicate well does not mean that they should stop coding, lest
they lose their technical edge.

### ✅ Lifting pattern: mentor

![image yoda](https://media.giphy.com/media/3ornk03njkdi5mNKJG/giphy.gif)

If you want to move forward as a team, you'll have to teach
others (just like you've been taught). Senior engineers share their learnings,
they share their reading ideas, they share their feedback in code reviews, they
share their process in documentation and pair programming.

Being a good mentor is difficult. Sometimes mentoring
means giving people autonomy and letting them make their own mistakes. You
can't teach everything and most of the time this is just about setting the
right context so that (1) the mistake is not a career-ending one (2) your
mentee learns from it quickly. Don't teach only the how: explain the why!

### ✅ Lifting pattern: lead by example

![Gandi](https://i.imgur.com/jo3eqEd.png)

The only person you can change is yourself, so start with _that_ person. Treat
others like how you'd like to be treated. Be rigorous, reliable, and
constructive. Be ok with chores.

### ✅ Lifting pattern: investing in your communication

Just like coding, writing is a skill that takes honing: clarity, concision, inspiring without being cheesy...
If you want to scale your impact, there's no better way
than learning to write effectively.

This is written in 2021, in a world of lockdown and by-default working from
home. Writing skills are key to effective remote work.

### ✅ Lifting pattern: be humble

![boss at the front](https://i.imgur.com/4mAB66a.jpg)

A great leader is courageous _and_ humble. You were a junior once. You don't
know everything and never will: keep learning, and welcome diverse opinions.

Also: take things with humor. Used intelligently, humor can defuse a tense
situation. You can convey very powerful messages with humor and
self-deprecation. Everybody makes mistake: own them. People will relate to your
experience and learn from it.

#### ❌ Lifting antipattern: deciding by consensus

![bike shedding](https://i.imgur.com/BQhpCKN.png)

The more people, the less you can drive by consensus. Appoint a leader and let
them make a decision. Sometimes this leader must be you: accept it, make the
decision, unblock the team.

Disagree and commit when you're not the decision
maker: there is a time for discussion, and there's a time for moving forward
with somebody's decision. Identify and escape
[bikeshedding](https://en.wikipedia.org/wiki/Law_of_triviality). Don't expect
to be part of every decision.

### ❌ Lifting antipattern: being a demotivator

A senior should strive to uplift others around them, becoming a multiplier for
the team by helping everyone move faster. It is unacceptable for a senior to
be a demotivator: when they become cynical, they bring everybody done, and
because of their experience and impact, they divide everyone's productivity.

![team work](https://i.imgur.com/fP9iJIb.png)

### Conclusion: putting things into perspective

I'll always remember what my first boss Thuan Pham (CTO of Uber at the time) said when
I made the switch to engineering management:

> Sure, we work with cool technology building great products, but those products have a pretty short impact timeframe: 1-3 years maximum. Above all we work with human beings on a team, and our behavior might impact their career and their life.

Putting things into perspective: how do you want to be remembered?

### Resources about senior engineers

- Dan Heller, [Ten Principles for Growth as an Engineer](https://medium.com/@daniel.heller/ten-principles-for-growth-69015e08c35b)
- Brandon Hays, [The Conjoined Triangles of Senior-Level Development](https://frontside.com/blog/2016-07-07-the-conjoined-triangles-of-senior-level-development/)
- John Allspaw, [On Being A Senior Engineer](https://www.kitchensoap.com/2012/10/25/on-being-a-senior-engineer/)
- Gergely Orosz, [What is a Senior Software Engineer at Wise and Amazon?](https://blog.pragmaticengineer.com/what-is-a-senior-software-engineer-at-wise-and-amazon/)
- My repository on Github: [charlax/professional-programming: A collection of learning resources for curious software engineers (Career Growth section)](https://github.com/charlax/professional-programming#career-growth)


Senior engineers should be expected to ship business value and uplift others around them.

Senior engineers ship and uplift


Starting a new job as an engineering manager can be tricky. Human beings
fear change, and a new manager usually means more change than a new individual
contributor.

Luckily, you can do your part on making this an easy transition for everyone by
preparing your arrival beforehand. Here are a couple ideas.

## Before your first week

**Research** the company's mission & vision (bonus point if you can already pitch it!), its products. Brush up on what you read preparing for interviews. Talk with customers, learn about what they like/don't like, use/don't use. Check out its competitors.

**Prepare a self introduction**, explain clearly why you joined. Make it fun and engaging. Rehearse it.

**Ask questions to your predecessor**. What's urgent? What did you wish you organized differently?

## On your first day

**Show up on time**. Dress appropriately (which might be different from what you were wearing during interviews). Make sure you have a notebook to take notes.

Ask people if there are meetings on your first week that you should attend. This will create some structure in your agenda.

## On your first week

**Go through the engineering onboarding process**. It will give you empathy for
the engineers on your team, and enable you to debug systems more rapidly. It is critical for you to understand the stack and
team's technological choices (everything is about engineering decisions). Get the architecture schema and ask question about historical decision. Read code to get an understanding of best
practices and areas of improvement. Keep a list of components and technologies you'll have to
research later.

**Listen**. Meet with everyone in 1-1, take notes, do very little talking.
Resist the temptation to say "at X, that's how we were doing it". Do not give
advice yet. Defer judgment and listen. You don't know what you
don't know yet. Be honestly interested in your coworkers. Introduce yourself and your background
(enthusiastically and succinctly, do not dwell for too long on your past
achievements), start giving hints about how you envision your role.

**Prepare your one-on-one questions**. Here's a list:

1. Tell me about you
2. What's working?
3. What's holding you back?
4. What are the current emergencies? How are they tackled? Why are they hard to solve?
5. How can I support you better than you've been in the past? (hat tip to my manager Brian Attwell for this one!)

**Enjoy the process**. Accepting a new team member, especially a manager, is always
a source of anxiety for a team. Fight that with an upbeat attitude. Bring
a gift from your country/region if you're moving. Learn people's name rapidly.
Meet with as many as possible face-to-face. Enjoy and leave
time for casual conversation. If you're running around on you first week you're
doing something wrong.

**Spend time with the previous manager**, or person in charge. Go through team
members. Understand the hiring decision for each team member. Get a list of
stakeholders.

**Meet with your boss**. What are his/her expectations? How will you be
measured? What does it take to succeed? Who should you meet with? What meeting
should you attend? Ask for the best way to communicate with them, especially
on your first week.

**Keep a "to learn/to read" list**. Prioritize it regularly. Drop things from
it. Review it with your boss.

## After your first few week

**Give feedback.** Find three things that can be improved about the onboarding
or the offer or the interview process. Give the feedback respectfully. Find out
how it's received.

**Bring immediate value.** Identify 1-3 things you will secretly and personally
work on to improve your coworkers' life. Learn how to clean up the coffee
machine. Do not go all-in and do not start changing everything.

**Define ambitious goals for the next three months.** Review them with your
manager. Setup a three month review.

# References

- [Nailing your first months as a new Engineering Manager](https://hackernoon.com/nailing-your-first-months-as-a-new-engineering-manager-ew4n3zgx)


how should you onboard yourself as an engineering manager?

Starting a new job as an engineering manager


**This article is also available as a [presentation](https://speakerdeck.com/charlax/how-to-give-feedback)**

<script async class="speakerdeck-embed" data-id="cd52f1dd8aac431c864903af4b44f1d9" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

Uber practices "T3B3", which encourages everyone to share feedback regularly with their peers and their manager. The feedback format is:

- "Ts": 3 things that the person does well
- "Bs": 3 things that they can improve on

I will be focusing on the latter category in this post, identifying a few redirecting feedback antipatterns I've seen. Examples will be about software engineering but can easily be transferred to another area.

_Note: "negative feedback" is not a particularly good expression - I usually prefer "redirecting feedback"._

## Introduction to giving redirecting feedback

Giving negative/redirecting feedback is a vital skill you'll need for your whole life. It's not a skill that is only useful in the workplace - you're already giving feedback to your friends and family members. Why not learn to be better at it?

### Book recommendation

[Crucial Conversations: Tools for Talking When Stakes Are High](https://www.amazon.com/Crucial-Conversations-Talking-Stakes-Second/dp/1469266822) is the classic reference on this topic. I recommend reading it. It's a bit repetitive though - you can find some good summaries on the web.

Another similar school of thought on the topic is **non-violent communication** ([wikipedia](https://en.wikipedia.org/wiki/Nonviolent_Communication)). The book that lays out the method is [Nonviolent Communication: A Language of Life, 3rd Edition: Life-Changing Tools for Healthy Relationships](https://www.amazon.com/Nonviolent-Communication-Language-Life-Changing-Relationships-ebook/dp/B014OISVU4/ref=sr_1_1?s=books&ie=UTF8&qid=1480675015&sr=1-1&keywords=non+violent). It provides a similar model as Crucial Conversations.

### My feedback model: OFNR

Here's the model I follow to deliver feedback (it's the non-violent communication one).

1. **O**bservation of a fact. A fact is rarely controversial, so it's a great way to start a conversation.
2. **F**eeling: express your feelings and your story. Clarify that it's your story.
3. **N**eed: state what you value, or the kind of impact you'd like to see.
4. **R**equest: explain what concrete action the person who's receiving the feedback would need to take.

E.g.:

> [Fact] You said during the review meeting that the wifi-enabled toaster's code was "a piece of shitty spaghetti code". [Story] I think people were put off by that comment, and I felt a bit demotivated because I had spent so much time on it. [Need] We need team members to deliver concerns in a respectful and constructive manner. [Request] You should have proposed some concrete ways we can improve the code, for instance a different code architecture, examples of refactor to take on, and holding people accountable for code quality.

### Concrete ways to train

- The best way to learn to deliver good negative feedback is to **start by being great at delivering positive feedback**, because there's less barriers to do so. Train yourself to use the model above to deliver positive/reinforcing feedback.
- Write the feedback down and **hold yourself accountable** to deliver it. Often we either forget about the feedback itself, or because we have to think too much about the delivery model, we never actually deliver it.
- **Don't deliver it in public** unless you know exactly what you're doing. Make it safe for the other person to receive it, and for you to fail at delivering it.
- **Acknowledge that you're trying** to improve your delivery. Start the feedback session with "I'm not great at delivering feedback, so I'm using this new model since a couple days. Tell me how I'm doing".
- **Acknowledge when you failed** to deliver it properly. "I'm sorry - I did not deliver this well and I've hurt your feelings. Let me try again."

## Antipatterns

Let's look at a few antipatterns.

### The "Untargeted feedback" antipattern

This is a pretty classical one. Here's an example:

> Our team could have been faster at shipping this wifi-enabled toaster.

It's totally unclear how this piece of feedback applies to the individual in question. I usually write my feedback writing with the second person ("you"), and then I quickly sanity check that I'm using it in the redirecting feedback section. This way I'm sure the feedback is targeted to this person.

Better:

> During the kick-off meeting for the wifi-enabled toaster project, **you** did not clarify that there was a strict timeline behind it. As a result, we missed our customer's expectation and delivered late.

### The "Things you can't impact anyway" antipattern

A very common antipattern is to talk about things that the feedback receiver has no impact on.

E.g. (assuming the feedback receiver is an hardware engineer):

> The toaster was missing a key feature: toasting an image of the weather on the bread.

This feedback is totally pointless if the feedback receiver has no impact on feature prioritization. Or, if they have, it needs to be made clear in the feedback (see "Untargeted feedback").

### The "I'll only talk about things you didn't do" antipattern

It can be tempting to make the Ts very insightful and specific, and to keep Bs evasive (human beings tend to not like giving redirecting feedback). Here's a classical example:

> T1: You did ... which resulted in ...

> T2: You did ... which resulted in ...

> T3: You did ... which resulted in ...

> B1: You could have done more hiring.

> B2: You could have done more training.

> B3: You could have done more mentoring.

While it's not necessarily a bad idea to talk about things the receiver did not do, it's not very helpful if that's the only feedback there is. What's more, the impact of those things missing is usually not laid out for the receiver, which makes the feedback even harder to receive.

I recommend to have at least two items which are about concrete things the person did, but could have done better. This will be much more actionable. Then you can have one or two "stretch" Bs, i.e. pieces of feedback that focus on things your interlocutor could have done more of. In that case, make sure to clarify why they were part of your expectations, and how it could have been done (e.g. better time prioritization, delegation).

E.g.:

> B1: Yesterday, you said X but did Y.

> B2: You decided to keep working on adding bluetooth to the toaster, even though we decided against it. ...

### The "Let's not be specific" antipattern

E.g.:

> You sometimes tend to cut corner and sacrifice quality over speed.

Not only this misses an example, but it reads as a personal attack. It is very improbable that the person will react well and find it constructive. Always start with one or two examples, and make sure you link them very concretely to one of the receiver's action.

Better:

> During the toaster project, you decided to not spend any time on manual testing, relying on other people to test your code. As a result, a number of bugs (including ticket T000 and T001) were introduced, and led to a decrease in the product's quality.

### The "Ts but no Bs" antipattern

E.g.:

> T1: ...

> T2: ...

> T3: ...

> B1: ...

> B2: Sorry I don't have any.

> B3: Sorry I don't have any.

A good rule of thumb is that if you have enough context to give three positive feedback, you need to be able to give three pieces of redirecting feedback. While positive feedback gives a good "tap on the back", negative/redirecting feedback helps us grow. You're actually not helping the receiver if you don't give them actionable and concrete feedback.

### The "Feedback sandwich" antipattern

E.g.:

> You did an amazing work with the toaster's admin panel. You did not take into consideration accessibility though - which means that our handicapped users won't be able to use it. But the look and feel of the icons is amazing!

The idea behind the feedback sandwich is to soften the blow by putting the piece of redirecting feedback between two positive ones.

It's an antipattern because it makes the overall point much weaker, and as a result, will decrease its effectiveness with the receiver. Compare with:

> You did not take into consideration accessibility in the toaster's admin panel - which means that our handicapped users won't be able to use it.

The point is much more direct and focused.

## Conclusion

Try the OFNR model in your next feedback session!

_Did you like this article? Check out my [engineering-management](https://github.com/charlax/engineering-management) Github repository where I curate a list of useful management resources._


Untargeted feedback. Things you can't impact. Things you didn't do.  Unspecific feedback. Only positives. The feedback sandwich.

Negative feedback antipatterns


<img src='http://media.tumblr.com/7d28e3f33fc6bf64d884be3818f02b53/tumblr_inline_n0tj743HjE1qfkyvc.jpg' />

This is my take on an engineering manager’s priorities at a hyper-growth startup. I quite often forget about them – it turns out a task’s engagingness does not always correlate with its importance… Having such a framework does help making tradeoff.

## 1. Growing the team

The first and foremost priority should be to grow the team. The problem with shipping features fast is that it’s a vicious circle: the faster you ship, the slower you get because you have to maintain existing product and features. You can only hire your way out, growing the team by hiring. This way you can (1) take on more projects (2) better balance the maintenance duties across the team.

It also involves making sure current team member grow in their career and skills. For people who love teaching and mentoring, being in this position is a blessing… For example, in my biweekly one-and-one, I try to avoid talking about current projects and prefer to focus about the mentoring part, because I feel like this is where I can deliver more value to engineers and the company. Our team also has weekly brown bags where somebody teaches us about a specific topic (concurrency in UNIX-like OSes, CPython datastructures, profiling Python code, etc.). It provides a great place for charging our mental batteries: people love to teach and to learn! As an engineering manager, your role is just to provide the environment for this to take place.

## 2. Maintaining a vision

I’ve always been convinced that a good product is made of 1% inspiration and 99% perspiration, to paraphrase Thomas Edison. That being said, as an engineering manager you have to take the time to think about the vision. Making sure it is shared within the team and trusting your engineers to make sound decisions is much more efficient and powerful than micromanaging.

I particularly like two books’ take on this topic: Guy Kawasaki’s [Reality Check](http://www.amazon.com/Reality-Check-Outsmarting-Outmanaging-Outmarketing/dp/1591843944) and Patrick M. Lencioni’s [The Advantage: Why Organizational Health Trumps Everything Else In Business](http://www.amazon.com/Advantage-Organizational-Everything-Business-Lencioni-ebook/dp/B006ORWT3Y/ref=sr_1_1?s=books&ie=UTF8&qid=1391988464&sr=1-1&keywords=the+advantage+why+organizational+health+trumps+everything+else+in+business). The strategy is basically (1) to make it as clear as possible (2) to overcommunicate it (pedagogy through repetition). Maintaining the vision (with the help of product managers) helps make sure engineering time is fully leveraged to achieve something big.

Engineering managers also need to spend time aligning their team’s vision with company priorities that can be changing pretty rapidly.

## 3. Managing projects

Things move very fast in a hyper-growth company, leaving a lot of room for miscommunication and wasted energy. A project manager’s role is basically to keep the ball rolling, spending their time unblocking people by maintaining a constant flow of communication. This is vital for complex, cross-functional projects where interdependencies need to be carefully thought of so that there’s no duplicated effort.

Because engineering managers keep track of current projects and interact with other teams, they are uniquely positioned to provide this context to existing projects, discovering and leveraging synergies.

## 4. Organizing

The basic premise behind the engineering manager role is that having a hierarchical organization is more efficient than having a free-for-all anarchy. I think they should also be thinking about the team’s internal organization. Should you create subteams to support the business’ needs? Should you experiment with new roles to make the team more efficient?

This is even more the case with hyper-growth startups, where the uninterrupted flow of feature requests and bug reports can be quite disruptive. We experimented with having a rolling support engineer who would be fixing the bugs so that other people can focus on their project. This way people get regularly exposed to the overall codebase – something that can hopefully inform their project’s implementation details as well.

## 5. Coding

As I said in my previous article [Learnings from six months as a first-time engineering manager](/posts/2014-01-29-learnings-from-six-months-as-a-first-time), I think that managers should keep on coding. This is the best way to lead by example. For instance, if you have troubles convincing other engineers that writing tests is valuable, then make sure to write some when working on a fix, showing why and how that made your more efficient.

_Picture from Paul Falardeau_


Grow the team. Maintain a vision. Manage projects. Organize. Code.

Engineering managers’ priorities in a hyper-growth startup


**Update (Feb 2017): I am keeping a list of resources for engineering managers on Github: [charlax/engineering-management](https://github.com/charlax/engineering-management). I have also changed my mind about some of the points below, but certainly not the last two ones: management is an amazing responsibility, and it requires constant learning.**

## It’s demanding

“Humans are much more complicated than machines”: one never experiences this saying more than when moving from a technical contributor role to a manager one. While debugging can be an exasperating task, discouragement is a feeling all managers need to learn to control, both in their team and in themselves.

Interrupt becomes the norm. You will become a marketplace for priorities. As in any marketplace, the immediate cost is often evident, but the long-term value is never obvious. That’s why all managers should take some time to reassess all of their current priorities and see if they’re not missing one. For instance, it’s very easy to forget about managers’ priority number one (hiring) when dealing with a complex project.

As regard transitioning from a world where you are praised for the code you ship to a world where you are a multiplier of other’s work, it won’t happen in one month. It takes some time to find the good balance between under- and over-managing. I don’t think I found it yet. One way I balance contributing with multiplying is through taking small coding tasks that nobody has time to do, letting team members do the big and complex projects. This way I’m sure I won’t interfere too much.

## Empathy

More than anybody else, managers should be on the watch our for their teammates' feelings and emotions. Do you feel that this person is not happy with her project? Does it seem that those two engineers don't get along? You might need to take action. As the prayer of St. Francis goes, "we must seek to understand more than to be understood" [1]. It’s not anymore about you - it’s about the team.

You also need to be constantly thinking about the consequences of everything you do. One thing that I learned the hard way is that anything that has the potential to be misinterpreted will be. For instance, when dealing with a project that is late, you might unwillingly make remarks that will be deemed disrespectful.

People often talk about “trust but verify”. My management framework is more along the lines of “be helpful”. You need to become an helpful resource to your team members. For instance, if you do quality code reviews, engineers will know you will help them improve their code and spot bugs. If you do good architectural reviews, engineers will know you will help them succeed. If you provide candid feedback professionally, people will know that you take on this difficult task to help them blossom.

## You should keep coding

Should managers code? Programming requires long period of uninterrupted time. It is almost totally at odds with a manager’s role which is to be the person who will be interrupted so that team members aren't. I once took a critical path coding project to reduce the load on my team. The effect was immediate and lasting, with decreased morale and wrong product directions.

That being said, not doing any coding is too risky for a manager. Just don't pick a critical path project :) Front-line managers will lose empathy for the difficulty of engineers’ job if they stop coding. Coding is also a good opportunity to exemplify the principles you're trying to establish in (writing tests and documentation, having a clean API, open sourcing software…). If you aren't coding, you won't be as resourceful when helping new team members navigate through the code, when debugging a production issue, or when responding to an incident.

You risk also losing a good understanding of the technology you’re using.

## It’s easy to make a difference

Some of those action items are common sense - but as Voltaire puts it, “common sense is quite rare”:

- Acknowledge your mistakes often, clearly and early.
- Listen twice as much as you talk.
- Strive for your engineer’s success, not for yours. Yours will come as a consequence of theirs.

One simple thing that very few managers do is to ask what people would like to work on. It’s very easy for a manager to become a task dispatcher. Whenever you have the opportunity to do so, try to get a better understanding of what your engineer like to work on: front-end/back-end, clear/unclear requirements, user-facing/developer facing, Python/JavaScript… Brainstorm ideas instead of trying to impose your own, because your idea might not be the best, and people need to have some buy-in. Their happiness and the quality of their work will increase.

There’s a poster at Facebook that says “do things and tell others”. If your team ship awesome features but nobody knows, what’s the point? More than anyone else (especially for engineers who might think it’s a chore), you need to communicate with the rest of the company. This is also a good opportunity to find synergies with other teams. You’ll also stay on top of what your team is doing. Engineers on your team will feel rewarded and recognized for their work.

## The virtue of disconnecting

Lean startup, agile, MVP, etc.: current development practices seem to recommend focusing on the act of implementing, at the expense of preparation. It is probably true that when solving problems through code, the emphasis should be put on the implementation. Things are moving so fast that most technologies are new for everyone, and only through shipping features will you be able to get a better sense of the problem.

Not so much with management: there is a lot of value in weighing pros and cons, listening to everyone (especially in interpersonal conflicts), taking some disconnected time to research and quietly think about the problem. It’s especially useful to seek mentoring when contemplating difficult decisions.

## You will grow through mentoring

There are numerous resources on the web to improve your programming skills. There’s also a wealth of resources about management, though it’s less structured. The Software Lead Weekly has been very helpful to me - I’ve never seen such a good curation of content.

There is something fundamentally different with improving your managerial skills. While you improve your code through your peers, as a manager you very rarely expect other managers to give you feedback. Similarly, your team member might (and should) give you feedback, but they might not be able to give you the best way to improve. Therefore, the best source of mentorship is probably your own manager.

You need to have senior management really believe in management as a craft. Having managers who really care about their work, think highly of it and always strive to improve themselves is key. There is a multiplying effect: people who really care about their work infect others to do the same, creating a virtuous circle inside the company.

## It’s incredibly rewarding

An engineer works closely with 2-3 persons. You have the awesome opportunity of working with your whole team (around 7 awesome engineers), other engineer managers, product managers, designers, etc. Your impact will also be much larger. There’s a high chance nobody will remember the feature you built in 20 years. But people do remember their managers, especially those who mentored them at the start of their career.

I would like to conclude with the following: there are numerous common points between parenting and managing. The main one is the following: everyone has an opinion about it. You need to seek mentoring, but you also need to find your management style. Especially when under pressure, it may seem simpler to embrace a style that is not yours (e.g. micromanaging). Resist the temptation, because it will backfire (it did for me). Your management style depends a lot on your own character - which you can always improve, but you can’t fake it. Through self-improving by experimenting and learning, you will blossom in this awesome role.

[1] Lencioni, Patrick M. (2012-03-14). The Advantage: Why Organizational Health Trumps Everything Else In Business (J-B Lencioni Series) (p. 33). Wiley. Kindle Edition.

Picture by [August Gregg](http://www.flickr.com/photos/augustgregg/)


It's demanding. Empathy is required. You should keep coding. It's easy to make a difference. You can and should disconnect. You will grow through mentoring and feedback. It's incredibly rewarding.

Category: management

Senior engineers ship and uplift

Starting a new job as an engineering manager

Negative feedback antipatterns

Engineering managers’ priorities in a hyper-growth startup

Learnings from six months as a first-time engineering manager