Leave a comment

A universal tool

When you become a manager, you may find yourself wondering how you can have a tangible impact on the performance of all of your staff. After all, they are at different levels of experience and have very different skills.

For staff that you share a similar skill set with, such as JavaScript development, you may still be able to offer mentorship for technical problems. But what about for those that you don’t have a common skills background with, such as UX or Data Science? You will also potentially find yourself managing staff who are older and have much more experience than you. How can you get the best out of them when you might not have any direct advice to offer?

A relationship with your staff based purely on directive interactions (e.g. “Do this in this way”, “Have you done that?”, “When will that be done?”) quickly becomes shallow. That should only be part of the relationship, and with time, should become an increasingly smaller part of it. Your top performers probably don’t need this kind of input at all; they’ll have a keen sense of what’s important and will just get on with it.

The skill that can help you increase the performance of your staff and open up a number of other opportunities for you is coaching, and it’s actually a lot easier than you think. We’ll take a look at some techniques in this article.


So what is coaching? At an abstract level, it’s a technique for helping your staff improve their performance. But that sentence is so lofty it almost means nothing. My own take on coaching is that it is a framework for interactions with your colleagues that makes them more likely to have tangible positive effects on their work.

I learned about the techniques from Effective Modern Coaching, which I’d recommend if you’d like to explore the details. There are three main concepts that really stuck with me when reading it, and these are the tips that I would like to share here.

Before we dive in, let’s get this clear: coaching doesn’t require special planning, skills, performance, or, well, anything really. It’s just a bunch of tools that you can use when having a conversation with someone. You can use these tools in formal settings such as your 1 to 1s with your staff, or you could use them while having a chat about work in the kitchen. Equally, they can be used whilst in conversation with one person, or they can be used to steer a group discussion. If you try them out, you’ll be surprised at how useful they are.


So if coaching is effectively just having a structured conversation, how should you be talking to the person being coached? You’ll need to work out which mode you’re going to be in at different parts of the conversation. There are two mutually exclusive modes:

  • Directive: This is where you’re instructing someone on what they should do. This is considered to be a “push” action, i.e. you are solving their problem for them.
  • Following interest: Here you’re predominantly listening to understand, reflecting on what they are saying and summarizing. This is a “pull” action, i.e. you are helping them solve their own problems.

In-between these modes are questions, suggestions, and summaries that you can give to steer the conversation.

  • “What’s the difficulty with doing it in that way?”
  • “Why did you pick that method?”
  • “What’s up with Bill this week?”
  • “Why’s that?”
  • “Tell me more about that API.”
  • “Walk me through your thought process.”
  • “Can you draw me a diagram on the whiteboard?”
  • “So what you’re saying is…”
  • “So am I right in thinking that…”

As the conversation progresses, you’ll work out whether you need to be directive or continue to follow their interest until they work it out on their own. You may find that less experienced staff require you to be more directive than their more experienced colleagues. This is normal. With time, as your staff become more experienced, you will find yourself following their interests much more than you will find yourself directing them. The positive side-effect of this is that as you become more experienced yourself as a coach, you realize that you can help anyone out with pretty much any problem, as you’ll be mostly listening!

At each point of the conversation, be conscious as to whether they are honing in on the answer, and keep listening and suggesting until they do. If you think they’ll never get there, be more directive.

Keep the thought bubble over their head

Unless being explicitly directive, in order to help your staff develop their skills, both in technical and abstract problem solving, it’s to keep the thought bubble over their head. Here’s a little example.

You: “So how’s progress been this week?”
Them: “Not great. The backend is much harder than we expected, and we’re not sure how to approach it.”

Even if you are the world’s most expert engineer, don’t tell them what to do, especially if you know what the solution is. Instead, every time that you feel that you would naturally jump in and solve a problem, imagine yourself pushing a big cartoon thought bubble away from your own head and putting it over theirs.

You: “OK, so what’s hard about it?”
Them: “We were going to store it in MySQL, but there’s way too much data and it’ll be slow when we access it.”

Now, at this point, you may know exactly how to solve this problem. But you shouldn’t. Push the thought bubble back to them.

You: “Interesting. Have we solved any storage problems like this before?”
Them: “Hmm. When Alice’s team were storing alerts a few years ago, I remember they couldn’t use a relational database either.”
You: “That project was quite successful. Do you know what they used?”
Them: “I don’t. But I’m going to go and grab her for a chat after this meeting and find out.”

Note that all you did was ask some fairly open, leading questions. Not only does this solve the problem for them, it coaches an approach to thinking about problems that your staff can reuse in the future. Additionally, it encourages thinking through problems in the open, together, collaboratively.

Now, if they were totally stuck, you could be more directive, but in a way that still lets them figure it out on their own. Let’s replay that last exchange. Rewind…

You: “Interesting. Have we solved any storage problems like this before?”
Them: “I don’t know. I’m stuck.”
You: “I’ve got a feeling that Alice’s team did something similar. I think you should have a chat with her.”
Them: “OK. I’ll try and find her after this.”

The GROW model

For more structured coaching sessions, i.e. those centred around solving a specific problem, it can be useful to frame the exchange in a sequence of stages to ensure that it stays on course. This is called the GROW model, and the letters stand for the following. For a given topic or problem, you’ll want to iterate through:

  • Goal: What’s the goal of this session? What problem are we trying to solve?
  • Reality: What’s the situation like now? Who, what, where, and how much?
  • Options: What are all of the different ways in which we can tackle this issue?
  • Wrap-up: Become clear on a choice, commit to it, and discuss what support is needed.

This might seem exceedingly obvious, but it helps keep conversations from deviating. Let’s think about the above example using this model.

  • Goal: We need to work out how to store the data in some way that’s fast enough to support our use case.
  • Reality: We know a lot about relational databases, but they won’t be fast enough for this problem. We have a hard deadline and we need to get some support.
  • Options: We could get an external consultant, but that’s very expensive and they might not be available immediately. We could try out some different databases ourselves, but we are not expert enough to make an informed decision about what to use in production. We could see whether anyone else in the company has had to solve a similar problem and seek their advice.
  • Wrap-up: We’ve decided to seek advice from Alice’s team because they may have implemented a similar solution in the past. We are meeting with her later, and we’ll loop back with a decision on how we’re going to proceed. Then we’ll make a call on what to do.

Honestly, this seems so obvious when it’s written down. Yet, it works every time and prevents conversation from deviating, which is a regular occurrence when exploring technical matters.

Giving coaching elsewhere in the business

Directing your conversations using a coaching framework will greatly improve the quality of your interactions with your own staff. You’ll notice that with time you’ll get better at doing it, and similar to driving a car or riding a bike, you’ll just do it naturally.

If you get really good at it, you’ll notice that you can pretty much talk about any problem with anyone, and assist them in thinking it through. This can open up an opportunity for you to increase your influence in your department and company: you can coach others that don’t report to you. If you have demonstrated to your peers and your manager that you are a good coach, why not ask if there is anyone that they would recommend starting a regular coaching session with you?

Being a neutral third-party in the coaching relationship, rather than someone’s line manager, means that you can form a close connection with the person that you coach, without the worry that you ultimately need to judge their performance. It also allows you to have a positive impact on other parts of the business without feeling that you are meddling in their affairs. Instead, you are enabling others to solve problems for themselves by working them through with you. It’s very rewarding.

Receiving coaching

The higher up in the org chart that you go, the tricker it may be to receive the coaching support that you need. Your line manager may already be very busy, frequently traveling or based in a different country. Additionally, if you are quite senior and managerial, you may be wanting help working through problems that could be too sensitive to share with your peers or your direct reports.

It may be beneficial to ask whether the company could set you up with an external coach, who you can meet with regularly in order to unpick the knots around issues in your brain using the same techniques that we’ve described in this article. Prices vary and can potentially be quite expensive, but there is the possibility that the executive team may have connections that could offer some coaching services for free or at heavily discounted prices.

In summary

Coaching is a framework that you can use to have much more impactful and rewarding conversations with others in your organizations. Some simple techniques can dramatically improve interactions and make them more focussed, useful and impactful.

If you’d like to dive more deeply into tools and techniques then I would recommend Effective Modern Coaching as a good place to start.

The contribution curve

Leave a comment

The curve

As a manager, your performance is going to be judged on your output. As we’ve explored in previous articles, you can measure the output of a manager as the output of their organisation plus the output of the organizations under their influence. How can you make sure that your staff are performing as well as they possibly can in an environment in which they can grow?

Your best individuals will contribute a significant amount to your department through impactful work and their positive network effect on others. Your least impactful individuals can be a drain on your department, and you need to make sure that you choose the right tactic for helping them improve as quickly as you can.

Below is a hypothetical example of an contribution curve for a talented graduate joining a company for the first time.

At the ends of the line you have net-negative and (currently maximal) net-positive contribution:

  • Net-negative: A particular individual, for the input of their work over time, produces a net-negative output for the business. As horrible as it sounds, the organization would be producing more output if they weren’t there.
  • Net-positive: A particular individual, for the input of their work over time, produces a net-positive output for the business. Some people produce more of a net-positive output than others, and you would hope that those people are rewarded fairly for doing so.

Three reasons

Clearly we want individuals to be as net-positive as they possibly can be. But why are people net-negative? Typically there are three reasons:

  • Inexperience: The best case (if there has to be one). An individual needs education and mentorship to push through to being net-positive. This is a training problem.
  • Poor placement: An individual is doing work that is either too challenging for them or they are unclear on how they should be effective in their role. This is a management problem.
  • Poor performance: An individual is not performing well in their role, despite having the support that they need. This is a performance problem.

Let’s take a look at them individually.


Everyone is a net-negative contributor at some point. From a graduate engineer starting out in industry for the first time, to a senior engineer beginning a new job, we all will repeatedly find ourselves in positions where to be net-positive requires time and support from other people. For talented people with the right attitude, as managers, we should be looking to allocate as much resource as possible to getting them ramped up and productive.

One of the simplest examples of this progression is from a graduate engineer to a tenured senior engineer.

  • A new graduate will be new to the industry and the company, so they will require support through training and mentorship in order to understand the technology being worked on, the business problems being solved, and the codebases and tools used to solve them. Their code will typically require a fair amount of checking whilst it is being written and also a higher level of scrutiny when it is being reviewed. They are net-negative because of the amount of time they require from others to get their work done.
  • A tenured senior requires less support when developing new code, and is often doing so in such a way that will enable others in the future. They know the business and the codebases well and create new features pretty quickly as a result. They review a lot of code from others and are often paired with more junior staff from drawing designs on the whiteboard to pair programming. They are net-positive and enable themselves and others to be successful.

For a talented and hard-working individual, both of these extremes in the contribution curve are completely normal places to be. The only fault that makes the graduate net-negative is that they are at the beginning of their career and they need time and support to become more expert. This is why this is a training problem. You need to be able to spot when people are in need of assistance and give them the resources that are required to move into being a net-positive contributor. You have a number of tools at your disposal to do this: assigning them a mentor, sending them on training courses, giving them books and online materials, and just making sure you’re on top of their career development and motivating them along the way.

It’s worth noting that it won’t always be those with less experience who find themselves in a net-negative situation. Even talented senior engineers will find themselves being net-negative when they start a new job, or when they change team to work on a different area of the application. The true measure of a good support structure is being able to accelerate engineers through to net-positive as quickly as possible.

Poor placement

Sometimes people can be hard working and talented but the particular project that they find themselves on just isn’t right for them. This can be for a multitude of reasons: they may not fully understand it, it may be in a programming language or framework that they find harder than others, or it may just be a project that is too challenging for their current level of experience.

This is a management problem, and you need to solve it. Depending on how your organization works, your teams may stay fairly static but your projects will change over time. One member of your staff may be extremely productive on a particular project only for the next one to leave them working on something that doesn’t best suit their skill set.

In an ideal world, your staff will tell you when they find themselves in this situation. However, in reality, they’re probably not going to say. It’s embarrassing to say that you’re struggling. Even worse, they might think that they will be punished for poor performance! Instead, as a manager, you need to build a close rapport with your staff so that you can sense when this is happening. Probe into how they feel about their current work, whether it motivates them, and how it plays to their strengths.

Also, try to encourage a culture where individuals can change teams easily without any awkward feelings about doing so. In the end it doesn’t really matter what team somebody is on, as long as they are productive. It shouldn’t be seen as a bad mark against a manager if one of their staff goes and works for another team. After all, everyone is contributing to the company regardless. Consider allowing staff to freely vote to move teams at the end of projects, or at the end of every quarter. If your headcount is quite restricted, why not introduce a matchmaking scheme where those that want to swap teams can as long as they find someone to swap with?

Poor performance

The worst one. Whereas a net-negative graduate engineer with a lot of potential will require time from others, the process and outcome is pleasurable: senior staff get to improve their mentorship skills and see another person grow.

A net-negative poor performer has a bigger blast radius for their net-negativity compared to the previous examples because they are a drain on collective morale as well as the time and attention of other staff. Their team mates will have to pick up their slack, which in turn makes them do a worse job because they are frustrated. They will be less willing to give up their time to the poor performer because of the drag that it causes. This is a performance problem that needs your attention.

When considering the overall output of a team, sometimes it can be improved by removing the poor performer altogether, which highlights the importance of your role as a manager. In the same way that the team would be frustrated if their manager had provided them with laptops from 2003 to do their work on, they will be frustrated that they have to work with a poor performer. As a manager you have allowed the poor performer to be part of their working environment, and they’ll be looking to you to sort that out.

Perhaps they can be moved on to another team with some clear goals for their performance improvement, whilst at the same time giving them a fresh start with new team mates. You cannot treat net-negative poor performers in the same way that you treat net-negative inexperienced engineers and hope that the team will somehow train them out of being poor. It won’t work that way: instead, you are showing that your bar is low for the quality of your staff, and others are being made to suffer because of it. Take ownership, have the hard conversation, and see where is their best chance to succeed in the organization.

In summary

You need to keep a close eye on how productive your staff are being: it can change over time with experience, the projects they are on, and their performance. Keep pushing everyone to be as net-positive in their contributions as possible, even if it means having some tricky conversations. Not everyone will be as skilled as you want, and not everyone will be on their ideal project. However, with careful balance of people on the right projects, you can gradually increase the net contribution of your teams, ensure that the next generation of engineers are learning their trade, and concurrently allow other staff to become excellent mentors.

Unfortunately, the poor performers are up to you to sort out. Sorry about that.

Mount Stupid

comments 4

But it’s easy, right?

Your team is getting it in the neck today. After months of technical exploration and prototypes, they have been unable to produce anything that looks like it will make the backend of the new product work in the way that it was imagined. The team are frustrated and are further convinced that without provisioning potentially millions of dollars in hardware and annotator time, they’re never going to be able to deliver anything of value. It’s just not plausible.

This isn’t sitting well with the VP Engineering and the Sales Director, who needs to shift units. In fact, they’re completely livid.

The Sales Director is first to interject. “You’re honestly telling us that after 3 months you have nothing that is going to get this thing built?” Your engineers aren’t particularly used to this kind of intense confrontation, especially from such senior people in the company. It makes them feel like they are pretty stupid.

“We tried. It’s just a really difficult problem.” Their nervousness makes them fail to say they’ve produced some very interesting prototypes and insights into tangential problems along the way.

“3 months and 6 people and we have nothing? That’s the problem with this team. I just don’t think you’re working hard enough, especially when compared to the sales team. They’re on it all of the time. When are you going to step up and take ownership?”

“I’m sorry; it just doesn’t seem possible,” replies your data scientist sheepishly, again failing to mention that they’ve produced a number of useful experiments that could make their way into the product.

Your VP Engineering is gripping her pen tighter, as one of her teams is making her look stupid in front of her peers. “You do realize that other companies are just solving this with machine learning now? It’s all off the shelf. Should take a couple of weeks tops. I’ve seen our competitors launch stuff really quickly this way. Why can’t you?”

“It’s not that straight forward; it’s really hard to get right.”
“I don’t believe you. Others are doing it. Did you not see their press release last week? I just don’t think you’re working hard enough. I reckon we should have just outsourced this problem. That would have got it done in half the time.”

Everyone is angry and at loggerheads. Senior management who are disappointed with performance and a team on the receiving end feeling utterly stupid yet unable to demonstrate they’ve done some worthwhile work. How did we get here?

I’ve been on both sides myself. It’s likely you will as well.

Two psychological concepts

The hypothetical situation described above frames two interesting concepts in psychology, which I often see played out in the workplace. To an extent, one could be seen as the inverse of the other.

  • Dunning-Kruger effect: A cognitive bias of illusory superiority in people of lower ability.
  • Impostor syndrome: A concept where high-achieving individuals are unable to internalize their achievements and fear being exposed as a fake or fraud.

We’ll have a look at both of these and identify situations where they can occur in the world of technology.

Dunning-Kruger effect

A 1999 study by David Dunning and Justin Kruger presented the results of experiments that proved that, in many social and intellectual domains, people tend to hold overly favorable views of their abilities. Not only does this lead to poor decisions, it also means that people are unaware that they are making them! The paradox is that in those same areas, when the skills of the participants were improved, they were able to recognize the limitations of their abilities and therefore realize that particular decisions were bad.

What does this mean for us in engineering? Unfortunately, it means that there will be limitless situations where those that know the least about particular problems will feel the most bullish and comfortable with making a decision and will not realize that the decision is bad. This effect can be seen from both ends of the seniority scale.

  • Poor decisions by junior engineers: High-achieving and confident junior members of staff, notably those who have just graduated with excellent grades, may not have the experience to make considered decisions about doing engineering in production. Their overconfidence in being able to solve a problem may give a project a green light, only for it all to not work further down the line. Their limited experience of production systems combined with their confidence in their own abilities can result in them not seeing any warning signs in their initial beliefs.
  • Rash decisions by managerial staff: They will be too far from the technical details to intuitively know whether a project is achievable or completely intractable. If they are confident, as your senior managers usually are, then they may be unable to be convinced that there isn’t a simple solution that your team hasn’t yet found, despite being told otherwise. This can lead to bad decisions about starting or stopping projects, outsourcing work, or blaming poor performance for a particular outcome.

The most dangerous place in the Dunning-Kruger effect was plotted to humorous effect by the Saturday Morning Breakfast Cereal comic. The graph has been reproduced with permission.

It’s very easy to be on Mount Stupid, and the worst part about it is that you won’t know that you’re there. We can all experience it as it happens to all of us. Unfortunately, this can lead to a decision being made where nobody really knows anything at all as there is no counter-balance to an argument, or where the person with the most power, who happens to be on Mount Stupid, exercises their executive right, making everyone else feel dumb.

Impostor syndrome

It is possible that high achieving individuals who are very good may not give an outward appearance that is congruent with how good they actually are. This is called imposter syndrome and was published in a 1978 study. This internal contradiction about one’s ability can result in excellent individuals feeling like they are somehow a fraud; that they are faking it and will soon get found out. This leads to nervousness and lack of confidence.

Like the Dunning-Kruger effect, it can play out at differing seniority levels:

  • Overly shy junior engineers: High-achieving juniors may observe a lot of smart and senior folks around them and believe that they have absolutely no right to be there and that, in comparison, their ability is poor.
  • Overly cautious senior staff: They forget that many of the things that come totally naturally to them due to experience are through their hard work, not luck. This may turn them inward and make them cautious and risk-averse, as they know the devil is always in the details. It may prevent them from speaking out for risk of being “found out”.

Elements of impostor syndrome can be viewed as the inverse of the Dunning-Kruger effect. Whereas those on Mount Stupid may be overly confident and brash because of their lack of knowledge about their own inabilities, those who have impostor syndrome may be overly unconfident and shy because they believe their own success is due to something other than their intelligence and hard work. This gives the impression to others that they may not know what they are doing, creating a nasty clash with the outspoken and confident people on Mount Stupid.

Bridging the gap

So, as a manager, how can you help?

In short, you need to exercise your emotional intelligence to spot when people are displaying traits that fall in either camp, and then work with that behavior to help your staff overcome it.

Dealing with the Dunning-Kruger effect

For junior members of staff being potentially reckless due to not knowing the ramifications of what they are doing, you need to show sensitivity. We’ve all been there. You definitely don’t want to make anyone feel shot down by demonstrating your superior knowledge. Instead, you want to try and make junior staff come to the conclusion that they are being overconfident by themselves. Think of a coaching mentality here: how can you keep the thought bubble over their head while they tackle a problem? Can you pair program with them and subtly lead them to discover where the problem is much harder than they thought, or can you do the same on a whiteboard? Once they discover that a great number of technical problems are harder than they initially seem, they will have developed more mature techniques to analyze approaches and find the right balance of confidence and skepticism.

Senior staff who find themselves on Mount Stupid can often be difficult to deal with, because a senior person may be highly confident in a group; others present may by worried about arguing with them. Here you need to subject them to a similar process as that of junior staff, where they can arrive at the conclusion that something is harder than originally seemed by themselves. You need to pick your battles here: some personalities may be totally open for a reasoned debate or working it through together on a whiteboard, but others, depending on the situation, may benefit from discussion being taken offline, where some proper research can be done and results presented in a less confrontational format, such as an email or short document. Mount Stupid combined with ego can cause degenerate in-person conversation. Instead, present only the facts; resist the urge to tell someone that they are being dumb. Sometimes you have to submit and leave a meeting in a haze of anger in order to revisit the facts later.

Dealing with Impostor Syndrome

Brilliant junior staff who experience impostor syndrome need to experience repeated success to overcome how they feel. One way of doing this is by pairing them with a senior member of staff who is a good mentor, and having them work through problems both abstractly, on paper and whiteboards, and concretely, implementing them together through pair programming. We often forget that in education we are receiving specific grades and scores for the quality of our work, and over time, self-confidence can be fostered by seeing repeated positive results. The workplace doesn’t offer frequent quantitative feedback like this, therefore regular interactions with more senior staff who can show the junior that they’re doing a great job. This is critical to build their confidence.

Senior staff experiencing impostor syndrome can forget just how much they know and can contribute. To reinforce their knowledge, pair them with junior staff. This actually benefits both parties, as shown in the previous paragraph. They will realize just how much they have to teach. For those that are reserved verbally, then as a manager, try to weave them into debates by asking their opinion directly. “How’s this problem playing out in your head right now? What are you thinking?” Make a concerted effort to bring their opinion into the room as often as possible. They will soon see that their knowledge is valued, hard-earned and useful.

In summary

The Dunning-Kruger effect and Impostor Syndrome play out in the workplace much more often than you think. Many people haven’t heard of either. It’s up to you to use your emotional intelligence to spot when your staff may be experiencing them, acknowledge that it is totally normal, and then try to employ some techniques to help them overcome them, without making anybody feel stupid or embarrassed.

Educating others about these concepts can also enable them to call you out when you’re being brash about a decision you know little about, or are being overly reserved when you actually have a lot to contribute.