Meetings

Meetings are a central part of the culture of any company because we spend a great deal of time attending them. In our industry, there is a common sentiment that meetings are a distraction from real work. Developers feel unproductive when they go to meetings. They can't wait to go back to real work. This sentiment has my sympathy, but it generally creates more problems that it solves. Saying no to meetings is a good example of non-constructive criticism. People don't see the value of most meetings they attend, therefore they feel they need to go back to the real work. You fix the problem by running meetings that create value, meetings that people look forward to attending.

What meetings you make compulsory says a lot about your culture. By definition, making something mandatory for the people you work with means you have a strong opinion about it. Therefore, I suggest you think very carefully about the meetings that must be compulsory. The shorter the list, the better. My list has only two items: one-on-ones and retrospectives. Be aware that just declaring some meetings compulsory doesn't work: people still need to find them valuable, otherwise you get the worst possible effect. You forced people into recurrently doing something they don't want to do. That's often how people start thinking of leaving a company.

One-on-ones

As a young programmer, I worked for a giant consulting company and one-on-ones were a nightmare for me. My manager used the meeting for negative feedback only, so when I was first asked to have one-on-ones with my direct reports, I was afraid that my team would see me like I saw my manager. I wanted to mentor people and support their growth. I was sceptical that one-on-ones would be in line with my leadership style because I had only known bad one-on-ones. It's funny how perspective can change with experience. Nowadays, one-on-ones are the core of my leadership style and I wouldn't know how to lead without them.

In the industry, there is a lot of advice around how to structure and how to run one-on-ones. My advice is to try hard to avoid structure: the meeting is about one person at the time. All people are different, so good one-on-ones reflect their diversity. The goal is to create a safe environment to foster trust. You can't help people if you don't know what their inspirations are, what they struggle with, what annoys them. Many people don't feel like they have the space at their daily job for figuring out their professional and personal development. Most people never bring up such vulnerable topics if not offered a safe space. It's your job as a leader to create such a space.

If you are planning what to say in a one-on-one, it means you aren't leaving enough room for the other person to make use of the meeting. You can't plan the discussion because your primary job is to listen. Do the simple thing: ask people how they want to use the meeting. Your job is to help them and they often know better than you what they're struggling with. Ask questions to clarify doubts and misunderstandings. Only propose topics if nothing comes up. If people want to talk about non work related things, don't drive the conversation back to work. One-on-ones are wonderful because they create the space to know each other better. It's quite ironic how this works: we spend more hours per week with people we know very little about than with people we know everything about. I'm not sure how it works in other industries, but I'm sure we can't do a good job building software if we don't know what is going on with our teams. It's basic human decency and common sense. The strength of a team comes from its collective intelligence: the better people know each other, the better their collaboration is.

Even more ironic is how reluctant people are when I talk about one-on-ones as a meeting that isn't about work during working hours. To be fair, my phrasing may not be great. I say that one-on-ones aren't about work, and that's true only if you consider work as a set of tasks to complete. We should not have such a narrow view of what work is. We work with people and people complete tasks, so one-on-ones are about the core of the job: the people doing it.

There is one thing you need to plan carefully though: your action points after a one-on-one. When I'm teaching young leaders to run one-on-ones, I always spend a great deal of time on this. One-on-ones can dramatically improve your relationship with the people you work with, but they can also destroy it. I did learn the hard way, and so did many leaders I mentored. Successfully creating a safe space for people to tell you what bothers them and what their aspirations are puts great expectations on you. People trusted you, so now you have to prove that they did the right thing. Often, one-on-ones lead to action points like "I will work on X because I understand now that it bothers you". The problem is that you can't forget X anymore. If you do, people will stop trusting you. It took me too long to understand that I needed to take great care of the action points generated in one-on-ones. That's the main reason why you can hardly have more than 4 or 5 direct reports and do a good job at the same time. It's too much work and too much information, so it's easy to make mistakes. This limitation has practical implications on your organisational design, which I discuss in When to split teams.

One-on-ones make sense only as a recurring meeting, so their frequency is relevant. My advice is not to choose the frequency yourself. Different people have different needs, let them choose how often they want to meet. My only requirement is upper bound: not less than once a month. Now, it can be once per month, once per week, every day or whatever. I'm serious though, you work for the people, remember? If someone needs to meet you everyday for a while, there is no good reason to say no. In my experience, the frequency tends to fall somewhere between every two weeks and once per month. During the first one-on-one, I explain that this is their meeting and they can use it in whatever way and however often they prefer.

If your one-on-ones have a different focus, mood, and rhythm depending on the person you're talking to, it's a clear sign you're doing a good job. If the experience varies a lot, you're going in the right direction:

People are different and you want to treat them differently. You don't want to treat all of them in the same way: you want to be equally fair with all of them.

Keep the meeting informal and, if people are fine with it, do it outside of the typical office setup. Long walks are healthy and they stimulate a good conversation, so that's a good choice and creates a ritual. Some people hate walking and talking though, so make sure your direct reports agree with the setup. Having the meeting outside of the default meeting setup helps you reinforce the message that "This meeting has a special meaning because it's only about you and not all the other work stuff". The meetings are more formal with some people and "exactly like going for a coffee" with other people. Both are fine.

Retrospectives

Every day at work there is so much to accomplish. We test new ideas, ship new features, break our systems, then fix them. These things often happen multiple times per day, often simultaneously. It's exciting to work in such an environment; it's dynamic and fun and there aren't two days that look the same. But, as almost everything in life, it may have negative side-effects: it's easy to end up running in a hamster wheel without really realising it. We constantly think about what is next: the next feature, the next bug fix, the next problem to solve. Always looking at the next thing doesn't tell you enough about the direction and progress. You need a point of reference for that: your past. If you don't stop and look back at where you're coming from, you don't really know where you're going. So you need to stop and look back on a regular basis as much to make sure you aren't running in circles.

Retrospectives are how you systematically look at the past. One interesting aspect of retrospectives is their "kaizen" effect. Kaizen is Japanese for "improve" and it's a fancy term the industry uses to refer to "continuous improvement". Retrospectives are a great tool for self-improvement, but here is another great aspect of retrospectives: it makes people stop running for some time. The messages you can reinforce with these meetings are:

• You don't need to run all the time.
• It's OK to stop and reflect.
• It's OK to spend some time just thinking.

Messages are easier to digest when repeated over time, so set up the meeting to be recurrent. Decide with your teams how often you want to run retrospectives. I find 2-week cycles to work well: it's long enough to gather topics for a discussion, but short enough to keep the conversation focused.

As a leader, how should you approach retrospectives? A good approach is to think of them as a collective one-on-one. You are there to clarify misunderstanding, to make small suggestions. You don't need to drive the conversation in any specific direction. Sometimes though, you may find yourself in a retrospective where people don't know what to talk about or where to start. This happens, and here is my way out of it: ask the team to name one thing they would like to improve. It's a start. Avoid suggesting topics for retrospectives. A good topic is whatever your team think they should improve on. It can be about improving the way you test things, it can be about getting more light in the room, a better webcam for remote work. The actual topic doesn't really matter. What matters is that you have the meeting on a recurrent basis and then act on the outcomes. During the meeting, think of yourself as a mediator. Some people are very vocal, others not so much. You are there to ensure everyone gets a chance to share their opinion. This is extremely important because often vocal people have little to say. That's why they're so vocal about it: they're afraid no one would care about their opinion if they wouldn't shout it out. If you let this phenomenon run its course, you may lose constructive feedback. I call it "the Hacker News comments effect". Most times, people that don't shout out their opinion have something meaningful to say. Listen to them and give them the opportunity to voice their opinion.

A good retrospective has clear outcomes. Your job is to look for those outcomes and make sure the team works on them. People doing the job are too focused on the details of what they're doing, so there is a chance they get caught in the everyday "run, run, run" vibe and forget about their own intentions to improve. Having a document that stores the discussions and the outcomes of retrospectives is helpful. People can go back to it and members of other teams can learn from it. As for one-on-ones, following up on the outcomes is the most important aspect.

Let me indulge on the parallel with one-on-ones a little more, it helps me explain how to run a good retrospective. There are many techniques to run retrospectives, but it's risky to apply the same techniques to different teams. Don't assume you can structure and run retrospectives for different teams in the same way. It's hard to imagine techniques that "just work" for any team. I'm not suggesting that you don't need to know about good techniques to run retrospectives. I'm suggesting that you try things out until you find something that works for each team. Every team is unique, so chances are different techniques work for different teams.

Running retrospectives takes practice, so don't fear going a little meta. It's good to sit down and discuss how you run retrospectives and what you can change to get even more out of them. The thinking process slows down your teams even more, and that's a great side-effect. People take their time to think how to improve the way they work.

Our goal is to build software that works for customers. Building something really fast that no one can use isn't a recipe for success. Our industry puts a lot of emphasis on the speed of development and not enough on the quality of the outcomes. Boyd's law of iteration says it all:

Speed of iteration beats quality of iteration.

It's often misinterpreted. We pay too much attention to the wrong aspect of the law. It's not much about speed per se, it's about the speed of iteration of your processes. Retrospectives may slow you down a little, but they give you fast feedback about your processes and the health status of a team you wouldn't have otherwise. These meetings help you stay focused on the right aspect of Boyd's law.

Set up your policies

In Process, I state that no process is a process too, and most likely a bad one. The same concept applies to culture and meeting policies. From time to time, you may run into statements like "we have no HR department" or "we have no managers", "we're a flat org", and so on. It's a fashion, especially in the startup world, to take thing X with a bad reputation and say out loud "We have no X" or "We don't do X anymore". This fashion has no substance and fosters what I call the "Hacker News white dudes readers" culture. Other people call it the "tech bros" culture. A much better attitude toward things with a bad reputation is "We don't like X too, so we did Y about it". You often hear "We don't have meeting policies because we hate meetings". This is just not helpful:

• No policy is just a bad policy.
• No meetings at all isn't a practical answer.

A better strategy is to make meetings better instead of hating them. I suggest to maintain a living document that specifies at least:

• Strategies to avoid meetings.
• How to determine who is required.
• How to determine who is optional.
• How to write a meeting invitation that says who is running the meeting, includes an agenda and expected outcomes.
• How to take notes, what to document as an outcome, and how to document it.

Writing suggestions on how to avoid having a meeting isn't so easy to do. Moreover, it's not easy to build a culture that strives to avoid meetings. Instead, you can define what makes a meeting a productive activity. I consider a meeting productive if we don't have to meet again to discuss the same topics or until there is significant progress. For example, if the topic is something like "We want to introduce X as a storage because Y doesn't scale anymore", I consider the meeting productive if the outcome is either "We decided not to introduce X because we're still fine with Y, we will meet in 6 months again to check the status" or "We decided to introduce X. We plan to do this and that. We will meet again once a prototype is in place". Based on this definition, a meeting can't be productive unless it has a clear goal; you can rely on the goal's clarity to figure out if you are ready to meet. Don't underestimate meeting preparation: you can talk to the people one-on-one or write a proposal about what you intend to discuss in the meeting. Such activities help you figure out if you really need a group of people to stop doing whatever they're doing and meet you. There is a big difference between "I need to book your time because I have no clue how to do X" and "I researched X and I can't proceed without your input on X because Y".

In my career, I've received thousands of meeting invitations with no description. I'm not entirely sure I know why that is, but I now know it's a bad sign. I tend to overdo descriptions because I believe that over-communication wins against under-communication every day. Be emphatic with invitees. If you get invited to a meeting, there are some things you need to know, and you feel comfortable attending if you have that information. You want to know why, what, who. You want to know the agenda and the expected outcome. Otherwise, it's like going to a party without knowing the address nor the host, the dressing code, the kind of food or music. It's possible to attend such a party, but it's probably not going to be enjoyable. It's supposed to be common sense to write down a good description, but since that doesn't seem to be the case, sharing guidelines helps people write their own descriptions.

Sometimes you go into a meeting and no one kicks it off. No one knows who is supposed to say what. These are the uncomfortable seconds in which people look at their phones, check their email on their laptop (it's worth mentioning in the policy document when it's OK to bring the laptop to a meeting). If a meeting starts this way, the host didn't do their job. Someone must run the meeting and the host is my default choice. What really matters though is that someone does run the meeting, and their name is explicitly stated in the invitation. This way people have a guide, and the host has a clear a responsibility. It generally leads to better run meetings where people get a chance to voice their opinion and no one thinks they wasted their time.