My Engineering Management Values

In my career, I’ve worked in very different industries, covering all kinds of product development roles. Two patterns emerged early on and stayed with me ever since:

• I have built teams and systems from scratch many many times.
• I have always had direct reports.

Looking back, I find this a tad puzzling.

Some sort of a strange chicken-and-egg problem I can’t untangle: Do I always find myself in leading positions because I’m good at it, or did I become good at it because I’ve always had to lead people?

To be honest, I’m not so sure what’s the right answer.

I bring this up in the introduction of an article called “my engineering management values” because it’s relevant to the conversation. Two reasons:

• I’m self-assessing as a “good leader”.
• I’ve been in leadership positions literally all my career.

Both are worth addressing before I move forward to discuss my values. Especially for readers that do not know me personally (if that’s you, hey 👋 nice to meet you!). Let’s start from “good leader”.

What makes a good leader? My answer is “many things but everything derives from trust”. The people you manage trust you to have their back. They are confident that your focus as a leader is their growth and well-being.

As I believe trust is what makes a good leader, it’s somewhat obvious that it is the common denominator of all my values.

What’s also worth noticing is that I use “leader” instead of “engineering manager”. It’s is a conscious choice that allows me to make a small distinction.

While it’s true I have been in positions of leadership most of my career, I have never held the title of engineering manager. More specifically, I’ve never been responsible only for the people part of leading developers.

I underline this because I can back up “I’m a good leader” with examples from my career, but I can’t actually say “I’m a good engineering manager”. In fact, I’m not so sure I’m a good fit for the job.

That’s the other thing I wanted to underline: I do not know how to gain trust from developers without deep technical conversations.

From my exchanges with engineering manager friends, these conversations are somewhat rare and just tangential to the job so I believe I’d have a hard time in that role.

I’m not saying that these conversations are the only way to gain developers' trust. I’m providing context for what my experience has been so far, so when I outline my values, it will be clear how I apply them to the job.

Before I move on to the values themselves, I’d like to explain why I think that leading teams all my career is also relevant to this article.

In every single job I took I felt a little “tricked” into leading developers. I did not want to lead developers and took on the jobs because:

• It was easy for me. More about this in a minute.
• I would rather lead a team so I could self-organise my own time than “just” be a team member and have a terrible manager. Unfortunately, every single manager I’ve had apart from one (hey Fabian 👋) has been either extremely terrible or really terrible.

Nowadays, I know that these are not good reasons to lead teams so, at the time of writing, I’m not sure there’s an engineering leadership job in my future.

When I say “it was easy for me”, I’m not trying to brag. It’s kind of a sad thought really. Let me explain.

I’ve always thought that my “leadership style” is nothing special:

• Trust the people.
• Treat them with respect.
• Convince them to do something instead of telling them what to do.
• Let them make mistakes.
• Make sure they understand your no-go (I’ll provide examples of this in lead by example).

The average manager out there must be very bad if doing what I’ve just listed is enough to be a good one. Often “the best I had”.

The sad thought is that it felt easy to be better than the average.

With that out of the way, let’s dive in.

• One-on-ones
• Written communication
  • Chats
  • Design proposals
  • Meeting agendas
  • Developer book
  • Internal blogging
• Lead by example
• Fire fast, hire slow
• No privileges
• Be vulnerable

One-on-ones #

One-on-ones are the very core of my leadership style. I would not know how to lead without them.

My goal with one-on-ones is to create a safe environment where my direct reports and I can trust each other. As you may have guessed by now, it’s all about trust for me.

There is a lot of advice around how to structure and how to run one-to-ones. I can’t offer any of that though as I actively try to avoid structure. What drives my approach is this:

People are different and you want to treat them differently. You do not want to treat all of them the same way: you want to be equally fair with all of them.

I don’t plan one-on-ones because my job is to listen. I leave enough room for the other person to make use of the meeting the way they want.

The way I do this is the simplest: I ask people how they want to use the meeting. They know better than me what they are struggling with.

I provide discussion topics only if asked to. That happens more often with younger developers. In fact, their most common struggle is that they don’t know what good or bad looks like yet.

If people want to talk about things that are not work related, I do not drive the conversation back to work.

There is one thing I do plan carefully though: my action points after a one-on-one.

Creating a safe space for people to tell me what bothers them and what their aspirations are comes with great expectations. People trusted me so now I have to “prove” they did the right thing.

It took me too long to understand I needed to take great care of the action points that a one-on-one generates.

That is the main reason why I think you can hardly have more than 5 or 6 direct reports and do a good job at the same time. It is too much work and too much information.

One-on-ones make sense only as a recurring meeting, so their frequency is relevant to the conversation. I don’t choose or have a standard frequency.

Different people have different needs, I let them choose how often they want to meet. My only requirement is an upper bound: not less frequently than once per month.

It can be once per month, once per week, every day, or whatever. In my experience, the frequency tends to stabilise between every two weeks and once per month.

I keep the meeting informal and, if people are fine with it, we do it outside of the typical office setup. This helps you reinforce the message “this meeting has a special meaning because it is only about you”.

The meetings will be more formal with some people and “exactly like going for a coffee” with other people. Both are fine.

In 2015, I wrote some notes about one-on-ones. If you’re looking for more details, I revised the article in 2022.

Written communication #

I was, and still am, a big fan of in-person, face-to-face, meetings. They worked great for me as a leader when I had small teams to take care of.

I still use this approach as my primary communication style when I can.

When I started leading more than one team (defined by the two-pizza rule) at the time, I quickly realised that this communication style wouldn’t scale.

Lots of people felt out of the loop, there was no structure around how my teams took decisions.

It made sense: my communication style was, by definition, non-inclusive. Either you were there or you weren’t.

I started writing things down for my teams and never looked back ever since. It’s now my favourite way to broadcast information.

I treat written communication “channels” very differently from each other. Written words can’t always weight the same. The context (“the channel”) matters quite a bit. Let me break it down.

Chats #

I’m deliberately silly in chats. I make jokes. I police people out of a chat if the conversation gets serious.

This is designed to constantly send the message that chats aren’t the place for any serious work.

I may use chats as a secondary broadcast channel. Meaning that I link important writing living somewhere else (like a google doc or a GitHub issue) in a chat and remind the team to discuss anything related to it in the relevant place.

Design proposals #

When I’m designing a non trivial feature, I most often use google docs as a starting point.

It’s an approach that is very indicative of my leadership style: I want to make sure we’re going in a direction I’m comfortable with (so I often draft a first version) while making sure people have the time and place to contribute as much as possible to the design.

I love the approach: it’s more inclusive than a meeting because it doesn’t require attendance at a specific time while also requiring less maintenance from me as a moderator.

Discussions in written form tend to be more thoughtful than in-person ones because people have time to think things through.

I also require people in my teams to approach large features this way. My experience has been that forcing people to write down their plans improves the quality of the plans themselves.

Meeting agendas #

Writing detailed meeting agendas is a relatively cheap way to ensure meetings are useful and correctly moderated.

I write down meeting invitations in this form:

• The point of the meeting.
• The topics we want to cover (their order is often relevant).
• The expected outcome.

This simplifies my job a little as I can quickly context-switch into “meeting mode” as soon as I read the agenda. This also helps me moderate the meeting.

If the meeting is about some on-going topic, I most likely have a google doc attached to it so that the attendees can take real-time notes.

You may be thinking that this is a lot of work to set up a meeting but that is my point: If I’m demanding people to take time out of their day, it means the topics are important. My effort must reflect that.

I enforce a “no agenda no meeting” policy when it makes sense. While I personally like it very much, I found that meeting culture is too company-specific for such a strict rule to always work.

Developer book #

Early in my career I got very frustrated every time I joined a new team. Most of the day-by-day operations were not documented anywhere.

So when it was my time to design an on-boarding experience, I realised I could make use of written communication by creating a “developer book”.

This document provides at least the following information:

• How to on-board.
• How we work.
• How we operate.
• How to off-board.

The idea is that if someone is unsure about how to approach a problem, they have some starting point in the developer book.

I store the developer book wherever the team stores code because it allows me to implement a process I find beautiful in its simplicity: I ask my teams to discuss changes to processes via pull-requests to the developer book.

The developer book in the repository then becomes the point of reference for every discussion about the way the teams operate.

It achieves some things I value very much:

• The rest of pull-requests (meaning code) stay free from tangential conversations about style, conventions and what not (those would be defined in the developer book as “how we work”).
• The team will have a history of how operational decisions were made.
• The developer book is always in sync. Can you believe that I have run teams with up-to-date docs?

Of course, the list of topics I provided is only an example. Different companies have different needs and the developer book should reflect that.

Good examples of topics you may want to cover in the document are:

• Diagrams (sequences, architecture).
• Incident management.
• Reference readings.

Internal blogging #

I call this communication channel “internal blogging” for the lack of a better term. What I mean is that I always have a place where I can share long pieces of writing.

I want to be able to refer to specific content over time. My experience is that repetition is very much needed when leading.

Writing a “blog post” is also my favourite way to smooth difficult operational transitions that occur in the lifetime of a company.

For example, I wrote internal blog posts on “the benefits of moving to a mono-repository”, “why we’re going to use trunk based development”, or “the next generation of our Kafka infrastructure”.

I share such blog posts long before the actual transition happens. This gives me time to collect feedback and minimise the scenario in which a change occurs and people don’t know about it.

As teams scale, sharing knowledge becomes more and more important to make sure that different teams don’t solve the same problem multiple times. An internal blog is a simple way to share these learnings.

That’s the other reason why I write these blog posts. It paves the way for other people to write.

Fostering a culture of writing helps teams in many ways:

• Learning to be a better writer helps you become a better developer.
• People can proudly share their achievements and simultaneously help other team members to learn something new.

The first question that comes to mind is: What is the right topic for blog posts? A good answer is whatever people feel like sharing as long as it’s work related.

It only works if people use it as an actual technical blog, because that is the only way to ensure that the usage spreads among team members.

Bonus side-effect: internal blogging makes public blogging much easier.

The delta between “something we wrote for ourselves” and “something we want to share with the world” is often small, so internal blogging facilitates public blogging.

Lead by example #

I believe that leading by example is the best way to shape culture:

Instead of telling people how to behave, be the person you want your direct reports to be.

Leading by example does wonders because it is self-reproducing. People have the tendency to emulate the behaviour of those they trust.

If people trust me as a leader, I can shape the culture of my team just by doing what I think is right.

This applies to everything we do at work every day so I often felt overwhelmed by the idea that “people are observing my behaviour”.

The way I overcame this problem is by making sure I make a conscious effort to draw the boundaries of my values.

The idea is that I clarify, with daily examples, what the things I really care about are. Let me provide some real-world examples from my teams:

• I call out people when they use non-inclusive language.
• I leave at 6pm every day unless the system is on fire.
• I don’t give up on a disruptive production issue until it’s solved.
• I don’t have work chat apps on my phone.
• I don’t work outside of working hours.
• You can’t really reach me when I’m off.

These are just examples, the point is: I learned that you can’t tell people to do “the right thing” and expect them to follow you. You have to be the person that does “the right thing”.

It’s obviously harder to lead by example when teams grow. Most of the people don’t interact with me every day so I can’t really provide daily examples.

Once again, written communication comes very handy. I write down “do and don’t” documents.

These documents look a little like the list I just shared but they use a different writing style. Items look like “Use inclusive language” or “it’s always OK to ask questions”.

Fire fast, hire slow #

Most startups hire fast and fire slow and that is considered somehow normal. I apply the reversed principle: hire slow and fire fast.

This sounds great in theory but, to be honest, it is hard in practice because:

• You could always do more with more people.
• Hiring has no short-term positive performance effect on your teams.

So there’s quite some incentive on hiring people really fast especially in a “VC backed startup”.

Unfortunately, hiring cannot fix now problems. It is an investment.

I try to stay ahead of my own needs and hire just a little before I actually need more people.

This also helps me to make sure I can indeed hire slowly. If I’m not trying to solve a now problem I can take my time with it.

Hiring slow is how I minimise false positives. If I hire the wrong people, the best I can do is to fire them.

Unfortunately, that is an awful solution. Firing is always my failure: something went wrong and now there is no better option than giving up.

Firing is ugly, there is no better way to put it. That is why I do it as soon as possible.

I think of firing as the worst possible outcome of the on-boarding process which I organise in the following checkpoints:

• First week.
• First month.
• First quarter.

There is more to on-boarding than just looking for hiring failure, but let me focus on that aspect here.

In the first week, I only look for big red alerts. The kind of inappropriate behaviour that must result in immediate firing; sexist or racist behaviour comes to mind.

The one-month checkpoint is the first chance for both parties to ask themselves if they did the right thing. It is generally enough time to assess if you enjoy working together or not.

At the three-month checkpoint, I ask myself the question “do we to work together for the next X years?”

If the answer is not “Of course, it’s awesome!” I know there’s a problem to fix and I have to act fast.

Sometimes though, people do not fit anymore. They have been working with you for a while and they realise they are not happy anymore.

Companies are living entities and they often evolve too fast. There is nothing wrong with it.

In such cases, I pay extra attention to how I let people go. It is easy for both parties to show lack of care and leave behind a bad feeling.

The solution is to talk about it as much as possible. They helped you achieve your goals, now it is your turn to show them you appreciate what they have done.

The best possible outcome is to help them find a new job and ensure a smooth transition.

Unfortunately, some people do not behave nicely in their last weeks. It can happen even with people you really liked working with. It is human: their heart is somewhere else already and they cannot help it.

Observe the situation closely. If it gets unprofessional, talk to them and let them go as soon as possible. It is the best option for both parties.

No privileges #

In most environments, there is some degree of privilege when it comes to specific topics like deployment rights, access to different environments. A common explanation for these privileges is risk mitigation. Those in charge want to minimise the mistakes made so they grant privileged access only to a handful of people.

This approach creates a false sense of security but in fact it doesn’t help you do better than any other company out there. Everyone has outages and breaks things.

In reality, such privileges create the worst dynamic: they frustrate newer team members that cannot access some of the knowledge which would increase their seniority. It also ensures that only senior people can make mistakes.

So at some point in my career, I got rid of all privileges because I realised that:

Everyone can do everything does not mean that everyone will.

On average, not much changed in terms of risk. I did not get more outages but I saw people grow faster.

I apply the “no privileges” policy aggressively. People should not be confined to only one phase of the product development process.

It is important to let people freely develop in the direction they want.

This approach often led to internal hiring (which is the best kind of hiring) because people started trying new things (because they could!) and realised they liked them more than their current job.

Be vulnerable #

Leading teams by example has an obvious downside: people tend to imitate your mistakes too.

It has always been difficult for me to see people consider my own mistakes as acceptable behaviour.

When I figure out I made a mistake, I go with radical honesty about it.

I tell my team why what I did is a mistake, I apologise, and commit to do better.

This too is leading by example, because that’s precisely the kind of behaviour I want to see in the people I work with. The message is:

• It is OK to make mistakes.
• This behaviour is not up to my own values.
• I must do better.
• So must everyone else.

This dynamic has a positive effect on you too. Being a good leader means helping people go wherever they want to go.

Sharing your own mistakes with your team can be a powerful moment of self-reflection and can get you closer to your direct reports.