management


**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 not always correlates 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: [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 is required

Empathy is the most important social virtue. French writer Montaigne showed a great deal of it throughout his masterwork Les Essais, for instance when describing cannibals. Similarly, managers should be always thinking about their team’s feeling, listening to their instincts. Do you feel that this person is not happy with her project? Do you think that those two engineers don’t get along well? You 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 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. Front-line managers will lose empathy for the difficulty of engineers’ job if they stop coding. If managers are supposed to lead by example, then coding is also a good opportunity to assert some of the principles you believe 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. 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.

dein.fr

Category: management

Negative feedback antipatterns

Engineering managers’ priorities in a hyper-growth startup

Learnings from six months as a first-time engineering manager