A friend of mine has a tactic to get her group of friends to decide on which restaurant to go to. When she notices that people are being indecisive for too long, she just suggests McDonalds. The conversation usually takes a different turn — her friends start to bring up options that are better, and eventually they converge to something good.

You can use this tactic to improve clairvoyance, and a great way to start is to make bets on the future by predicting some numbers.

Let's take an example: hiring plans. Let's say you'd like to have 10 more people on your team. Assuming that 50% of the people will accept, you'd probably have to send around 20 offers — to 20 candidates that you like. Let's say your bar is high and you typically reject half of the candidates, that's around 40 candidates that would go through your full interview pipeline. And so on, you can predict how many hours will you have to interview, how much training can you give your team, etc.

With these kind of calculations we can see if our goals are too ambitious, and brainstorm some of the resources required to reach them. If, as in the example above, we see that the team will have to spend a lot of time in interviews, we can be more aware of the impact on delivery and align the expectations.

There's another advantage to doing these kinds of calculations. They force us to examine the past, project it into the future, and evaluate whether the context that created the data is still applicable. For example, let's say that your team had 10 new members and 5 people left. How many people do you think will leave this year? Most importantly, why?

I'm often surprised at how much these rough estimations help provide more context  behind blanket, ambitious statements.

It's illuminating and fun. So why not?

Last week I read 📚 The Advice Trap and it's just great — it helps you be a better coach. It also argues that one of the responsibilities of a coach (and ultimately, one of the responsibilities of a manager) is to create a safe and inclusive space for their team.

We often talk about how to create that inclusive space. We share facilitation techniques, things that we shouldn't do, and how to avoid our biases. However, I found that it's difficult to actually know whether a place is inclusive enough — in other words, what an inclusive space actually is. 📚 The Advice Trap answers this question for an individual, and gives a tool to almost measure it. Enter the TERA quotient.

TERA is an acronym of four drivers that our brain uses to assess whether a situation is safe or not. It stands for:

• Tribalism (are you with me, or against me?)
• Expectation (do I know what's going to happen?)
• Rank (are you more important than me?)
• Autonomy (do I have any say in this?)

The book further goes into tactics for increasing the TERA quotient, but I'd like to see this applied in teams. To me, the best thing that a manager can do to support the culture is to make sure that the answers to these questions are clear. Creating a safe space means ensuring that the answers to these questions are clear and positive for everyone in the team.

This is difficult, because, as a manager, you cannot be there for all the individual conversations to support the trust-building. However, you can make it so that the people can identify their own TERA quotient. It doesn't have to be measured explicitly, but we can provide ways for people to understand these answers on their own.

For example, Tribalism. As a manager (or an exec), you can set the frame of identifying with the tribe. The team can later use that frame to gauge whether someone is part of their tribe or not. Let's take an example: the team is defined as "we're top performers who are relentlessly pursuing customer satisfaction". Every individual can measure up everyone in their team — are we all part of the same tribe? — and it would be more difficult to build safety if not everyone belongs to the tribe definition.

Before this begins to sound Macchiavelian — if it hasn't already — the point is not to shape the definitions, since that's too much work to maintain. The key idea is that safety can be measured and improved, and the first step to that is bringing clarity.

So, In order to build a safe environment, we need to make sure that there's clarity surrounding the TERA questions. And that's a manager's first job.

For the past couple of weeks I've been interviewing for a new role. It's a fun exercise that has me take a look at my career, comb through the things I've done and people I've interacted with. As I'm looking through the projects I've been involved with, I see a pattern with deadlines.

There weren't many things that have a strict internal deadline. There are external deadlines, like regulatory due dates (remember GDPR?), major changes in the vendors that are too big to adjust for us, and software deprecation issues.

In the cases when the deadline is internal , it's there to coordinate: "We discussed with marketing that they need this for the campaign three months from now" or "We're showcasing our milestone at our conference".  There's a special case for deadlines to be "as fast as possible" because of a market opportunity, but that's not a specific deadline.

This doesn't discredit deadlines — on the contrary, it lets us examine them for what they are. Since there's no implicit due date, an internal deadline is a tool that is applied to simplify coordination. It's a level of indirection that creates a bias for action and helps us ship things.

Where does that put the word "late"? What does it mean for an effort to be late?

Similarly to underperformance, "being late" means that the expectations don't match the reality anymore. The expectation was set in a context in the past, where it took the form of a date and some success metrics. Over time, the context has changed, and the date wasn't updated to the expectations.

When we're late and the deadline is internal, we have two options.

We can evaluate the cost of changing the date versus the cost of changing the success metrics , a cost of delay. For example, we can look at whether pushing the release by a month will mean that marketing has to prepare the campaign again.

Another option is reexamining the success metrics. If there are things that depend on the release and, considering that we have a lot more context about the scope of the work, we can take a more careful look at the metrics and check if all of the efforts contribute to the metrics. For example, if we're showcasing the new product at our conference, we don't necessarily have to release it to the general public at that moment. We can start testing with a group of users and get their feedback. The product can still be showcased.

If there's no coordination attached to the deadline, and it's not external, then it's probably made up. That doesn't dismiss the deadline, but it calls for a good conversation about expectations — why was this date picked? What is the cost of delay? And what was the need that drove someone to pick a date? All these are great questions for a retrospective.

Recently, as I was preparing for interviews, I was thinking about how I handled underperformance throughout my career. The more I thought about it, the more I understood that I've been looking at underperformance in a way that made it difficult to understand the issue.

The way I looked at underperformance is this: someone isn't meeting the expectations of their role. As a manager, I receive a signal that someone isn't doing well, investigate, and discuss if needed. Cool.

But it's more useful to think of underperformance as a mismatch between expectations and reality. But, as none of these can exist on their own, it's best if we ask ourselves: whose expectations are these? and whose reality?

Adding the possessive to both of these things makes discussing underperformance a lot easier. Because then, your role as a manager changes, to understand the different perspectives on both expectations and reality, and how they affect your team. In that sense, addressing underperformance becomes a quest to understand and align the different perspectives for how we expect someone to be doing versus how they are actually doing.

A year ago, I started doing predictions for my team, and I've found it to be a useful way to engage managers with their teams. It proved to be a good way to support managers, and it helped us prevent several conflicts.

A team prediction is simple table with four columns:

• A person's name,
• 0-10, the likelihood of them leaving within the next 6 months (where 0 stands for "no way" and 10 is "I'm certain of it")
• 0-10, the impact on the team if the person is missing for 1 month (where 0 is "we're not going to notice" and 10 is "we're going to ship nothing")
• What can we do for them?

This list had a couple of roles. First, if there's a difference between the way the manager and I see the scores, it's a great start for a conversation. Do we have different contexts? Where does our experience not match here?

Secondly, the list helped us identify risks, and act upon them. For example, when we saw an increase in probability, we'd have a chat about it. Or, when we saw too high of an impact concentrated in one team member, we would set a plan with the manager to spread that impact more.

Finally, it was a good way for us to align with the managers. We're both looking into the future; excited, and somewhat calculated. If there's an important project coming up, or there's too much risk in one area of development, it was great to solve the problem of retaining knowledge capital, together.

This is the retrospective prime directive and I think that this sentence alone has made me a much better manager.

I've first learned about this sentence when my friend Patrick was facilitating a postmortem of a very, very failed project.

It was a difficult but important integration with a third party with many people involved — consultants, developers, managers, and with many flows of communication going all over the place — some of the commitments were made during lunches with the third party, most of the communication ended up in two people's email inbox, and the development team changed a couple of times while we were building the integration. In short, there were many reasons why we didn't ship the integration and there were many reasons for us to put blame on everyone else.

So Patrick started the retrospective of the project by asking us to read the prime directive. And then read it again. And only when were certain that every one of us understands that we're all trying our best with everything we have, it was then that the retrospective actually started.

And by then, we weren't looking for someone to blame. We weren't looking to defend ourselves and to clear our name. And whenever somebody slipped into something like "yes but the development team was invited to that meeting", Patrick would point to the poster with the prime directive and ask something like: "why do you think the team didn't go? They were doing their best." And then we'd figure out what was the context for every one of us. We were looking at the communication patterns. And most importantly, we were working together to improve the situation for everyone in the future.

Since that time, I've used the prime directive in many situations. It's especially useful when you don't have your usual team setting — when there are new people in the team, or when there's a particularly stressful situation. It helps center the discussion, move some of the defensive behavior out of the way, and with it, the biases and insecurities that every one of us brings to any conversation.

And since then, it's been a valuable tool in my managerial toolbox.

I hope it helps you as well.

Sometimes you'd like to help your team discuss a topic and decide what to do together. But often, these discussions are quite difficult to facilitate. Sometimes people don't listen as much as they should, sometimes they feel less comfortable speaking, either because of their personality or of the other personalities, and sometimes they simply don't relate to the issue.

I found that these conversations become a lot easier if you add a layer of indirection, and I started using that in group conversations. It changed things.

Adding a layer of indirection is quite simple. Let's say, your team shipped a project and you'd like to see how it went for them so that you know how to do it better next time. You can ask that directly, but chances are you'll get simple answers like "it was fine", or "we could've done better with this or that". If you'd want to add a layer of indirection, you want to ask a different question, collect all the data, and then focus your discussion on the data.

For example, instead of asking the team how it went, ask them to write an amazon review of the product they shipped. Something with stars and a title and a body. Then, when everyone finishes writing their review independently, start the discussion not from the individual positions, but on the data you gathered.

This has a couple of advantages: first, different people think at different speeds. people who think at different speeds are able to formulate their thoughts well and in a focussed way. Secondly, it makes sure that everyone is aware of what everyone is thinking well before they start speaking, which is great for the group's self-moderation. In other words, people who are loud don't take too much space and the quiet ones get the support they need. And finally, it gets you a snapshot of the current state that you can use as a reference when something changes so that you see if the decisions have actually improved things.

So next time try this: instead of asking a question directly, add a new layer, collect the data, and decide not based on the question, but on the data.

Good luck!

So you’re finally getting a promotion! You’ve been writing loads of code and shipping stuff and taking responsibility and now you got promoted to be a team lead! First of all, congratulations and welcome to our little club. Secondly, I hope your workplace provides you with some support and guidance. For a lot of us managers or team leads that’s not the case, and we’ve made a lot of mistakes on the way.

After almost 10 years of leading teams, I'd like to take some time and reflect on the things I wish I knew when I started.

1 . Understand that you are a junior manager.

This sounds simple but I’m surprised at how many times I've seen people not get it. I didn’t either, and I was very unhappy in my first couple of years as a manager.

It took me a lot of time to realize that I’m a manager now. This is a different job, that requires different skills, has a different lore and frankly, some of the practices I built over the years as a developer are completely useless here. It’s not moving up, it’s moving sideways.

And secondly, I’m a junior manager. With all the expectations that come with being a junior. This is a taste of what leading is. Just as we expect a junior developer to be curious, critical, pay attention, and reflect on their experience up until they develop that gut feeling that’s informed by their experience, we can expect the same thing from ourselves as junior managers.

2. The values are different

The first thing that you’ll notice as you become a manager is that your system of values will shift. And that is going to be hard. I remember my first week when I didn’t push any code. I remember my first day when I didn’t open my computer, at all. I felt miserable — I felt that I’m not a good engineer and I was trying to compensate by working on weekends and I did a poor job.

After meeting more people I realized that this is okay. I’m not an engineer anymore and the expectations towards me are different. I don’t add, I multiply. I can’t use the same measuring stick to see understand whether I’m doing better or not.

But that is very, very difficult to understand, because it means putting our egos to the side and learning a lot, which takes time. There's a trick to learning that a lot faster, and that is finding people.

3. Find people

Management is pretty lonely and quite taxing as well, especially if you’re not well prepared for this. It took me a very long time to develop my empathy towards the teammates, but not do that too much, so that I don’t become that overbearing parent. I’ve had coaching and therapy to learn not to sacrifice myself for the team, and to learn to feel the difference between my responsibility, and the responsibility of any of my reports.

And the best way to learn these things is to find a safe space to talk about them. There are many communities of managers, there’s meetups and conferences, slack groups and forums. Hell, you can even follow a bunch of managers on twitter so that you get exposed to people who like doing this, and if you ask them a question, they will very likely answer. You’re not alone in this. Build your Voltron.

And also, if you’re lucky, at work. Your team is likely not the team you lead, because there are a lot of things you can’t share with them. Your team is the other team leads, the managers. Reaching out to someone who’s a team lead as well, learning from them, at work, is a thing that will definitely help you not be alone in this.

Extra: Develop your own toolbox

You will make a lot of mistakes.

Even if you know how to do a proper 1:1 or you’ve read horror stories about people letting their biases get in the way, you’ll make these mistakes. It's easier if you accept you’re doing the best you can with the information and the support you have, and every once in a while, reflect on your experience to see if there’s something that can be learned. And I’m sure you will learn and develop your own toolbox.