Category Archives: Engineering Leadership

Team Pattern #4: The Self-Managed Product Team

This is the last post in the blog series about team patterns and it’s all about self-managed product teams.

At first this team pattern looks similar to the product team pattern, but unlike the product team pattern there is no engineering manager directly responsible for the team’s work.

This pattern also looks a little like the matrix team as the people on the team report to a manager outside of the team, but unlike the matrix team there is no common theme for the engineers who report to an engineering manager.

That is, a single manager is responsible for a diverse group of engineers working with different technologies (e.g., C++, Android, Node.js) and different products areas (e.g., billing, orders, customers) — and there’s no guarantee that two Android Engineers will report to the same manager or that all people on the Orders product team will report to the same manager.

In this team pattern, the manager is less of a traditional manager who directs and supervises work — and more of a career counsler and coach who can advice the engineer.

In this team pattern the leadership of a team can be split into three separate roles:

  • Product Manager: This role is focused on product leadership, such as talking with customers and preparing product road maps.
  • Engineering Manager: This role is focused on people management, such as recruitment, career guidance, building culture, finding and fix interpersonal issues.
  • Lead Engineer: This role is focused on technical leadership, such as technical best practices, mentoring, and anticipate the future technical needs of the team.

An real-world example of this team pattern is described by Josh Tyler, who is EVP Engineering at Course Hero, in his fine book Building Great Software Engineering Teams; at his company Course Hero, an online learning website, they’ve organized their teams according to their product areas:

On each product team they have a Lead Engineer who takes care of technical mentoring and guidance, define best practices, and make sure they are followed.
The Lead Engineer works closely with the Product Manager to scope projects, prioritize tasks, and give the team the context necessary to be successful.

Where it starts to divert from the product team pattern previous example is that the engineering manager’s role is independent from the Lead Engineers.
The Engineering Manager is responsible for a group of engineers across multiple product teams. The Engineering Manager is no longer involved in technical leadership and
doesn’t supervise the work of the Lead Engineer, but is focused on people management, such as finding and fixing people-related problems.

The roles of Engineering Manager and Lead Engineer are completely independent. So it is possible for a Lead Engineer in one product team to report to an Engineering Manager.
This engineering manager may be part of another product team — as a hands-on engineer — and report to another Lead Engineer for technical matters on that team.

But what do Course Hero do when they have a person who is both talented in people management and technical leadership? They considers those rare people to be precious gems that should be treasured and see them as people with executive potential. But still then, they recommend that the person starts by focusing on one of the two paths (i.e., Lead Engineer or Engineering Manager) and then master the other one later.


The self-organized product team shares many of the strengths we have seen in the other team patterns.

But a distinct strength is that splitting the engineering manager role into two opens up for a genuine two-track career model with a track for managerial leadership
and another for technical leadership. This is important as most first-rate engineers are not really interested in traditional management, but are deeply passionate about technology, so in this
team pattern they have a career path where they grow without losing their technical edge. This will also make it easier to attract and retain highly skilled technical people
as you don’t expect them to become a traditional manager (and lose that all-important technical edge) or force them to report to a incompetent manager who overrides
their technical decisions due to authority, and not merits.

It may also make hiring easier, which should not be underestimated in a competitive job market, as finding a single candidate who excels in both technical leadership and people management is really tough.


At first sight the clear definition and separation of product, technology, and people leadership roles look attractive — as it makes it real easy to figure out who to ask:

  • Should you upgrade to the latest version of Angular? Ask the Lead Engineer!
  • Do you dream of becoming a Full-Stack Developer? Talk with your Engineering Manager!
  • What’s the most important feature to work on right now? Ask the Product Manager!

The risk is that in real life many problems doesn’t fit neatly into one of these categories…

For example, the CEO thinks that the team is not developing fast enough:

  • Is that a product thing? Maybe the team is focusing on low-value, low-visible features?
  • Is it a engineering thing? Maybe there is too much technical debts or poor design?
  • Is it a people thing? Maybe the people on the team lack skills in the technologies used or their motivation is low?
  • Is it a mix of these? All of these? Some of these?

This will make the debugging of the problem harder — as the debugging may spans multiple areas of responsibility owned by different people — it will make finding and fixing the problem take longer.

From a manager perspective: The primary weakness is that the manager is often no longer involved in engineering, neither as a lead nor as a individual contributor, and if this is the case then his or her engineering skills can quickly deteriorate as things are evolving pretty fast within computing these days (it’s a Red Queen’s race!) and the manager is in high danger of fast becoming a dinosaur that suggests solutions that made perfect sense… on mainframes! Or thinking that ASP Classic and React are more of less the same… I mean they are just web development frameworks, right? 😉

The knock-on effect of losing one’s technical instinct is that it can lead to poor judgement.

Of course, these risks can be mitigated — especially with good collaboration and some general curiosity about what’s happening in one’s field — but left unattended they may turn into issues.

That’s it! I hope you enjoy this little blog series on team patterns!

Team Pattern #3: The Product Team

It’s time for the next episode in this blog series on team patterns!

It has been slightly delayed, because I got a last-minute invite to present at TCC 2018 (our annual conference for customers and partners) and to host a roundtable there as well. Both great experiences 🙂 You can see a nice photo on LinkedIn where I’m rehearsing together with Christian (our CEO).

But enough about my everyday work and back to the blog series 🙂

This post is about the product team pattern!

At first sight a product team is very similar to a matrix team. You organize a team around a product area and take all the different roles needed to build the product and put them inside this team.

The big difference from a matrix team is that all team members, regardless of their role, report to the same line manager. So it doesn’t matter whether a team member is a designer, frontend developer, backend developer; everybody on the team reports to the same line manager.

The motivation for doing this is to simplify decision making (i.e., the buck stops at the line manager regardless of the functional area) and to encourage people on the team to learn more about the business that the product area serves (as they will work within that area for a long time, rather than on the matrix team, where they are more likely to be moved to a completely new product area).

When Instagram moved away from the technology team patterns, which we saw in an earlier post in this series, they adopted the product team pattern, as you can see in the org chart below:

As you can see in the org chart above, Instagram organized their team around the product areas (such as content creation). To handle general stuff that doesn’t fit neatly into a product area, they added two platform teams: The Core Client team for developing the container (or app shell) that the product teams develop their product areas within, and a Core Infrastructure team that handles servers and other infrastructure.

At Airbnb they have made an interesting variation on this pattern: They let their product teams focus on a specific persona, such as guest or host, instead of more traditional product areas, such as billing or booking. This makes it really easy for Airbnb to establish business-related KPIs for the team.

The line manager in this team pattern is often called an engineering manager to show that it is not a manager for a specific technology area (such as mobile) or a specific discipline (such as QA), but rather a manager responsible for all engineering within a product area.

The product team pattern tends to grow leaders who can bring different disciplines together and make them build a unified product where all the pieces fit nicely together. And it encourages leaders to focusing on building a product that actually solves a business problem. This is also the motivation for many organizations who use this team pattern: It aligns the engineering teams’ success much more closely with the company’s success and it becomes much easier to define a business-related KPI for the team (compared to the technology team pattern).

Another interesting dynamic is that companies, which move away from technology teams and to product teams, is that full-stack developers with a good understand of the product area tend to replace the technical specialists (e.g., experts in one layer of the tech stack) as the rock stars of the development organization.

The reason is that a specialist can only typically build partial features. For example, a Django developer who can develop the backend functionality, but doesn’t not know React so cannot finish the frontend part of the feature.

But the developer will report to a line manager responsible for the whole product area (and not just a single technology) and who is motivated towards shipping whole features, and hence, more likely to reward people who can actually deliver whole features.

This dynamic is further accelerated if the company uses continuous deployment and is in a business where speed to market matters (which is most businesses).


An advantage of a product team over a technology team is that the team is much closer aligned with business success. The team will not feel like a success if their product has just flunked a major public review — even if their code is so beautiful that it would make Jon Bentley shed a tear.

In continuation of this, it is also my experience that more and more software engineers no longer really fit the old computer geek stereotype, who just wanted to be left alone and code. Now they also want to see their product succeed in the market and make meaningful contributions towards that. As in the old parable about the three stonecutters, they are no longer satisfied with merely cutting stones, they want to build grand cathedrals!

To an even higher degree than with the matrix team, the product team is more likely to build a unified product and have better collaboration across disciplines and lower the risk of a “us-versus-them” culture.

Another advantage of the product team over the matrix team is that decision making becomes much easier as there is only a single line manager involved when a decision needs to be taken or impediment needs to be escalated.

All this usually really contribute to the team’s ability to iterate very fast and launch new product features quickly; and contributes positive to the team’s autonomy.

A caveat is that many of these strengths may be nullified if the team has strong dependencies outside the team’s control. These dependencies could be organizational (like external reviews or approvals) or technical (like an architecture that is a big ball of mud and any change to the codebase can have side effects anywhere else so all teams must coordinate their work).


A serious risk with product teams — especially compared to technology teams — is that they may pay less attention to technical excellence.

There can be several reasons for this:

  1. Engineers may become too focused on market success at the expense of engineering excellence. Especially if there is a strong and opinionated product manager or customer.
  2. Each team may become a silo (reporting to a single line manager) and there can only be so many senior engineers within a single team. So, for example, if the team only has a single junior Android engineer who will make sure that the quality of his or her code is satisfying? Or making sure he or she knows the best Android blogs to follow?

Similarly, there is also a higher risk of code duplication. That is, several product teams may code the same functionality in their individual codebases (which may or may not be a problem depending on your belief system).

Another risk compared to matrix teams is that it may become more difficult to move people between teams. When an engineer changes team in the matrix, he or she continues with the same line manager. But in product team pattern, he or she will change line manager as well, which may be a major change. So there may be more resistance, both the engineer might like his or her current line manager and not want to change and start all over with a new manager. Plus some manager have empire tendencies and may be less willing to “give away” an engineer for good. The consequence of this may be that the company is not allocating its people to its highest priorities or biggest opportunities.

Another risk compared to technology teams is that recruitment may be tougher. It is easier to explain to an Angular engineer that it would be great to be part of an Angular team compared to being part of a Life Insurance product team. Even with the matrix organization you can tell the engineer that he or she will report to a manager well-versed in that area. You can mitigate this by explaining why this area is interesting from a technical point of view or important to society at large.

Some companies brand their product teams (at least in job ads) as full-stack team, and given it is cool to be a full-stack developer, the thinking is that it will be easier to recruit people for a full-stack team compared to a Life Insurance team.

From a manager perspective, my experience (as having been both a development manager and an engineering manager) is that being an engineering manager is a more demanding job. It is not because the job is difficult from a technical point of view, it is just that the responsibility is broader. You will essentially become a mini VP of Engineering for a small development department.

You will also have a more direct impact on the business, which you cannot shy away from. That is, as a development manager (for a technology team) you can say that the product is perfect from a technical point of view and it is not your fault that it cannot sell. Due to the broader scope of the role there are also many more things that can go wrong. You will be responsible for things outside of your primary area of expertise but will be responsible for them anyway.

Finally, as a manager your technical skills will most likely erode faster than in the other team patterns. You will be responsible for multiple technologies, such as backend, frontend, data — and have people management on top of that. The rapid pace of technological progress only accelerates this; for example, you were an expert in AngularJS and then they release Angular 2 and all your hard-earned skills become obsolete. And this is not only happening in one layer of the stack, but on all layers, so keep up with everything can become pretty tough.

Given this broad scope of responsibility for the engineering manager — from people management to technical leadership — some companies keep the product team but split the engineering manager role into two: One person will be responsible for technical leadership (i.e., a lead engineer) and one person will be responsible for people management (i.e., a people manager).

This pattern, where the engineering manager role is split into two, will be the topic for the next post in this blog series. Stay tuned!

Team Pattern #2: The Matrix Team

This is the third post in my blog series on team patterns, and this time we will look at the matrix team pattern.

A matrix team is a temporary product (or project) team, which is made up of specialists from different functional areas. The idea with the cross-functional nature of the team is to increase collaboration between different functions to create better products and faster releases.

An old-school example of this team pattern is Microsoft Solutions Framework (MSF), which was hot back when Microsoft ruled the (software) world:

A feature team is usually focused on a product area and will typically last for the duration of a product release or longer. For example, in Microsoft you would have multiple feature teams working on Microsoft Excel, and one of them would focus on Excel Macros.

An example of the members of a feature team could a Program Manager (responsible for functional specifications and project management within the team), 4 developers, and 2 testers. The Program Manager will tell the developers and testers which is the most important feature to work on and handle the planning and coordination of the feature team’s work.

However, developers report to a development manager who provides guidelines on how they should do their job (e.g., job descriptions, development process, engineering practices, coding standards) and be responsible for people management (e.g., promotions, training, move to a new team, etc.) — and it is the same for the other roles, so program managers report to a group program manager, and testers report to a test manager.

The underlying idea is that it will encourage cross-functional collaboration when specialists are literally on the same team, but the specialists will continue to report to a functional manager who is an expert in their area of expertise.

Tuning the Matrix

The most common parameters to tune in this team pattern are the influence of the line manager on the team’s work (degree of team autonomy) and the duration of the matrix team (short-lived versus long-lived).

Yammer: Very short-lived matrix teams

A modern variation of this team pattern is used by Yammer, a social network for enterprises. A key difference between Yammer and Microsoft is that Yammer continually deploy new features to production and don’t have major product release like Microsoft used to have for their shrink-wrap products.

Yammer’s developers share the ownership of the entire codebase, so there is no thing such as “my code” or “my module”. Each time a task needs to be performed on the codebase, they establish a temporary team for this specific task. When the task is done the code is released to production and the task force is disbanded and developers are free again to join new ad-hoc team to address new tasks.

The thinking is that this is highly agile, and people will not be limited to work on a single product area but can quickly go wherever there is the biggest need for them.

The development manager is responsible for developers within his or her technical area, such as Ruby on Rails, Java, or React. But the development manager is no longer defining guidelines for how the developers should work, but instead a coach who is focus on turning his or her developers into top-notch experts in their given technology.

Spotify: Long-lived, autonomous matrix teams

At Spotify, an online music player, they take a different approach and encourage long-lived, stable matrix teams (which they call “squads”). Their reasoning is that it takes a long time to master a product area, such as Spotify Radio, and mastery is needed to build an awesome product for their users.

They also empower their matrix teams and give them greater autonomy than many more traditional matrix organizations.

However, Spotify still have line managers (which they call “chapter leads”), but with the important twist that the line manager is also an active member of a matrix team (for example, as a back-end developer) to make sure he or she stay in touch with reality.


The primary strength of the matrix team (compared to the technology team pattern from the previous post) is that it fosters much closer collaboration across functional disciplines. Now the developers and testers are part of the same team; especially, if the program manager successfully makes a shared vision for the product area.

On top of that being a cross-functional team means that all the necessary skills will be immediately available within the team, so there won’t be these gaps between the teams which we saw in the technology team pattern. This improves time to market:

It also encourages developers and testers to learn more about the business domain, such as banking or medicine, that the matrix team is working in. This is really useful when it is a highly complex business domain with lots of counter-intuitive business rules. For simple domains, such as social networks or blogging, it may be less important.

It also brings engineers closer to the business and makes it easier to see how they contribute to the success of the company, while they can still continue to seek mastery within their chosen technology and continue to report to a line manager who appreciates and understands their technical work. The line manager also enforces alignment and quality across teams, and the engineers will have a second opinion (and supporter) in case of a powerful and persuasive program manager on the team or they feel uncomfortable with the decisions taken within the team.

The matrix organization also scales well and can be used for delivering very large products. Microsoft released many of their greatest hits, such as Windows and Microsoft Office, using this team pattern. They were even able to compete with young startups, such as Netscape, while using this model. Obviously, Microsoft used some dirty business tricks to win the browser war against Netscape, but they would not have been able to compete with Netscape if they had not been able to keep up with Netscape’s development speed.


In theory, a matrix team has a high degree of autonomy, but in practice multiple line managers will often enforce controls that limit the team’s autonomy and the team will need to consult with the line managers before trying anything too radical.

There is also a risk that work process inside the team will turn into small waterfalls with extensive handovers between the disciplines inside the team. This can happen when the line manager is not actually part of the team but defines the process that his or her people must follow within the team.

There is also a risk that the line managers may not see the big picture and start to suboptimize for their functional area. For example, the test manager wants to introduce NASA-like quality controls, while the customers are actually happy with the current quality level and is much more interested in getting new features quicker (at the current quality level).

Many developers who worked in a matrix team feel like they have two managers (i.e., the development manager and the program manager) and they often receive conflicting signals about what is important. For example, the program manager says that the developer can skip the unit testing to meet the deadline, but the development manager says that unit tests must be written for all new code — and the developer is caught in the middle. Unclear or overlapping responsibilities are a frequent source of conflict and frustration in a matrix organization.

Decision making related to how the team works may even turn into a lengthy process as multiple line managers may need to be involved in a single decision. For example, the development manager wants to introduce static code analysis (and pay the technical debts it reveals), which should be a pure development activity. But the program manager feels that it will delay the development activities already on the team’s roadmap, so she wants to be involved. The test manager feels that it is an initiative related to quality, and hence, he should have a say in it, and incorporate it as part of an overall test strategy.

To address these weaknesses, some engineering organizations introduced product teams where they would continue to organize teams around product areas to harvest the benefits of cross-functional teams, but to boost the team’s autonomy and speed up decision making, they decided to drop the matrix organization (with multiple line managers) and instead have the all people on a product team — regardless of their specialties — report to the same line manager.

We will look at this pattern in the next post in this blog series on team patterns. Stay tuned!

Team Pattern #1: The Technology Team

This is the second post in my blog series about team patterns, and it’s about the technology team pattern.

A technology team is focused on a technical area, such as front-end or back-end, and all members of the team are specialists in that area. So there will be no product managers, QA specialists, or engineers specialized in other technologies on the team. All members of the team report to a manager who is also a specialist in this particular technical area.

For example, it could be a mobile team with a number of mobile developers reporting to a mobile development manager:

When there are multiple technology teams, such as a mobile team and a back-end team, there is usually very little (if any) code shared between the teams. This is because the code is often written in different languages/framework (e.g., Swift versus Python) and exists in different code repositories. The interaction between the teams will often happen through REST APIs or similar.

A real-world example of this team pattern is early Instagram (around 2015) where they had split their engineering organization into three development teams (they eventually moved away from this setup, but more about that in a later post):

The reporting lines in such an organization is based on expertise. In other words, a mobile developer will not report to back-end development manager, but to the mobile development manager.

The managers in such an organization is likely to be a senior engineer who has been promoted into management, and now also takes care of people management on his or her team. The manager may still be writing code (or at least have the ability to do so). It is also likely that the manager will handle project management for the team’s work and coordination with other teams.

The rock star in such an engineering organization is likely be a technical specialist measured by some technical standard, such as mastering all the advanced features of the chosen language, or writing the most elegant, concise code.


The primary strength of the technology team is its technical mastery, which is likely to be higher than in any of the other team patterns which we will explore in the following posts in this blog series.

The team’s codebase is likely to be of a high quality and take full advantage of the latest advancements within the chosen technology — and there is likely to be little technical debts.

It can also be easier to recruit technical experts for such a team. For example, if an engineer is intensely passionate about Django then the idea of working in a Django team, reporting to a Django manager and being surrounded by Django engineers is pretty attractive by default.

Finally, the team’s manager is likely to be highly competent in the work that the team performs, which is key to high job satisfaction according to recent research. This also means that the manager can evaluate the engineers based on merit, and not some measure which can be easily faked (like who stays the longest in the office). The manager will also be able to provide detailed coaching, such as how to write better code and be aware when an engineer is ready to be promoted to the next level.


A common problem for engineering organizations which use the technology team pattern is that time to market (for new features) tends to be slow.

The reason is that one team may finish its part of the feature fast, but the next team might be busy with something else and cannot pick up the task any time soon — as shown in the diagram below:

This means that work queues up between the teams. The cost of a feature may not be higher in actual development time, but it can be very expensive in calendar time.

This problem should not be underestimated. Time to market is hugely important for most businesses. In Lean thinking, unfinished features are expensive inventory that cost the company money, because they don’t generate business value until it’s in production and being used by the end-user.

This team pattern will also nudge you towards phased (or waterfall) development where each team finishes its part of the work before passing it on to the next team. This will discourage iterative development and feedback loops — and when mistakes start to occur due to limited communication between the teams, the handovers are likely to become elaborate and time consuming — and it can even lead to a destructive “us-versus-them” mentality between the teams.

In an attempt to overcome the weaknesses of technology teams, some engineering organizations introduced cross-functional matrix teams. The thinking was that this would lead to improved collaboration between functions (e.g., product management, development, testing) because they would now literally be the same (matrix) team. On top of that, the expectation was also that time to market would improve, because when a matrix team takes on a new feature it will have all the necessary skills inside the team to finish it!

So in the next post in this blog series, we will explore the matrix team pattern. Stay tuned!

Team Patterns: How to Structure an Engineering Team?

This is the first post in a blog series about how top-performing software companies are organizing their engineering teams.

You don’t need to network a lot before you realize that software companies are organizing their teams in very different ways.

But after you’ve heard about a few dozens companies, you start to detect patterns. You start to realize that even though there are lots of small variations then their team structures can all be boiled down to a handful of general patterns.

In my experience there are four general team patterns that most companies follow. Yes, they have tweaked them to fit their circumstances, but the overall idea behind the pattern remains the same:

  1. Technology Team: The team is formed around a technology, such as Android. For example, a team of mobile developers who build and maintain a mobile app.
  2. Matrix Team: The developers report to a Development Manager, but they are “lend out” to cross-functional product or project teams where they do their daily work.
  3. Product Team: The team is oriented around a product area, such as billing. It’s cross-functional, but all people on the team, regardless of their specialization, report to the same line manager.
  4. Self-Managed Product Team: The team is oriented around a product area. But the management of the team is divided into technical leadership, typically handled by an Engineering Lead on the team, and people management, typically handled by an Engineering Manager outside the team.

My plan is that each post in this blog series will explore one of these team patterns in depth to identify its strengths and weaknesses — and then spice the whole thing up with plenty of examples of top-performing companies who are actually using the team pattern in the real-world.

The blog series will continue over the next month. I’ll add links to the posts in the series below when they have been published:

  1. Team Patterns: How to Structure an Engineering Team?
  2. Team Pattern #1: The Technology Team
  3. Team Pattern #2: The Matrix Team
  4. Team Pattern #3: The Product Team
  5. Team Pattern #4: The Self-Managed Product Team

You can subscribe to my blog to automatically get an email when the next post is published.

If you have any questions or comments to this blog series, feel free to send me an .

9 Tips for Effective One-on-Ones

The purpose of a one-on-one meeting is to listen to what your people has to say.

In this way, you can learn about potential issues before they turn into serious problems.

Your managerial reward of effective one-on-ones is a lack of drama in your team, which enables your people to spend their time on doing great work!

So how do you do effective one-on-ones? Here are 9 tips to get you started.

1. Be consistent and never-ever cancel it

You should schedule one-on-one meetings as a reoccurring event in your calendar. The meeting should be 30-60 minutes. You should schedule it for every week, but if you have more than 6 employees then consider scheduling it biweekly due to the time involved.

You should never-ever cancel it, as that will basically communicate that your people are not that important to you.

If you keep it consistent your people will know that this is the time to discuss issues. This will make your schedule more predictable as you are less likely to be interrupted at other times if your people know that there’s a one-on-one where they can bring up their concerns.

2. Start with “How are you?”

Michael Lopp, a veteran software engineering manager, writes in The Update, The Vent, The Disaster that you start the one-on-one meeting with a simple, “How are you?

It’s a soft opener, but the idea is that whatever the reply, you can learn something useful and take the conversation from there.

3. Listen, Listen and Listen Some More

The one-on-one should be a bottom-up meeting where your people share information with you, rather than a top-down where you are pushing information down their throats!

While most managers are extremely busy, and honestly don’t want to hear about more problems, which will only make them more busy and perhaps even shake the boat! But the hard truth is that the earlier a problem is detected, analyzed and dealt with, the cheaper it will be to solve. And all practical experience shows that ignoring problems will (unfortunately!) not make them disappear.

4. It Ain’t a Status update!

The one-on-one is not for operational stuff. There are project meetings and stand-up meetings for handling the daily status of tasks.

One-on-ones are for strategic stuff; like, looking into how we are doing stuff and how we can do it better.

If your employee starts to go through status, interrupt after some 5 minutes and say, ”It sounds like you got the project/task under control, but how about the [insert strategic activity] that we talked about earlier?”

5. Ask Powerful Questions

Sometimes it can be difficult to get the conversations rolling. For example, when you have new people, or very quiet people, or people who have had a poor manager in the past.

So to get the talking started it always help to have some powerful questions prepared. For example:

  1. What excites you at work?
  2. Do you have ideas for how we can do things better?
  3. Where is your job satisfaction on a scale 1-10? Follow-up with: What would it take to make it a 10?
  4. Do you have ideas for the next release of our product?
  5. How’s the family?

A one-on-one is also an excellent opportunity to debrief recent work. For example, to discuss what went well, what didn’t went well, and what are the lessons learned for next time.

6. Ask for Gossip (really!)

It’s always good to ask for gossip. Especially, if there has been a recent re-org or any other major event.

Ask your people about their opinion about the event, rather than starting with your own opinion. Then, afterwards, you can always come with your interpretation of the event and explain how it fits into the big picture.

7. Follow-up (action speaks louder than words!)

If there are any actions coming out of the meeting, be sure to follow-up and execute them.

If actions are agreed and nothing ever happens with them, it will destroy trust in the relationship.

Be the manager who shows that good ideas are acted upon. Show with your actions that what’s being said in a one-on-one is important to you. Build trustworthiness through your actions.

8. A Dedicated Day for One-on-Ones

Software development manager and blogger Ed Gibbs writes in One-on-Ones in a Single Day that he prefers to have all his one-on-ones in a single day (Wednesday).

The benefits are that it’s easier to defend a full day (than large chunks of time throughout the week), it frees large chunks of time on the other days for other activities, you are better prepared for the one-on-ones, and it gives you a better sense of how the whole team is doing.

9. Try a Different Location

Executive coach Beth Miller recommends in Revamp Your Approach to Monthly One-to-One Meetings that you sometimes move away from the office to shake up the one-on-one, add a more casual theme to it and get to know your people on a different level.

For example, by going out for lunch or by going for a walk outside, which was a favorite of Steve Jobs.

At the end of the day, a one-on-one is an opportunity for your people to share their ideas, concerns and need for personal development. Your task as a manager is to ask good questions, listen to what is being said, provide sensible feedback, and follow-up constructively.

Some managers will undoubtedly read this and think that it sounds like a humongous time stealer from another dimension! But they must remember that their job is management and that one-on-ones are one of the most effective management tools out there.

In the words of Johanna Rothman, a bestselling author of software management books, “Managers who use one-on-one meetings consistently find them one of the most effective and productive uses of their management time.”