Script

Introduction

Let begin today’s topic by using a hypothetical example of a hospital. Suppose for a moment you are the manager of a hospital, and you have the following medical specialists working in your team:

1. A heart specialist.
2. A brain specialist.
3. A physiotherapist.

Day after day, they take turns coming to your office to present problems and ask for solutions.

1. The brain specialist gives you a report of the issues faced by an injury patient, and asks you what should be done next?
2. Meanwhile the heart specialist has a patient that is not responding to the prescribed medication, so asks you what to try next?
3. The physiotherapist has a patient that is not getting better in spite of months of exercises, and asks you what do you think should be adjusted in their training program?

Obviously this is a ridiculous situation that would never occur in a real hospital, after all how could one manager possibly have some deep knowledge of different parts of the human anatomy?

Furthermore the medical practitioners have their own reputations to protect, not least their medical licenses and insurance, to be seen dead asking a manager for medical advice.

And yet bizarrely, I seen variations of these sorts of conversations happening in my industry, software engineering, throughout my career that spans over a few decades now.

In many teams where I have worked as the manager, I have had software engineers explaining to me in detail a bug they cannot fix; I have had DBAs telling me about complex joins that where killing database query performance in production; I even had architects who could not draw at a whiteboard, when challenged by me to do so, the architecture of the very systems that they themselves had apparently designed, but they were more-than-happy to try to make bottlenecks in that architecture my problem to resolve.

So why is the software industry different from others in this regard, why do domain experts feel entitled to present problems without a single idea about solving them, and why do they feel that the leader in this situation is going to solve those problems for them?

That is exactly going to be the topic for today’s episode. Firstly I will share with you why I think we see these patterns in our teams, and secondly some tips to correct these negative behaviors.

After all, we hire experts into our teams to own these topics, and advise us on the correct solutions for their speciality.

Lets see how we can get there, but first lets look at the root causes.

Leaders are usually ex-specialists

In our hospital example, typically the person who is leading the organization is not an ex-doctor, which is another reason why our medical specialists do not go to that leader for technical advice.

In contrast, most leaders in a software engineering organization are themselves ex-engineers, and may be still very technical in their know-how. That makes them a very attractive person to present your engineering problems to, as chances are they are very experienced engineers who can offer solutions to younger engineers.

As tempting as that may be for both parties, it should be avoided at all costs. Firstly the younger engineers must learn to solve their own problems, and not rely on engineering leaders to solve them, otherwise they are not improving.

Secondly for the leaders, the want their teams to be independently solving their own technical issues, to ensure the leader does not end up owning those solutions, which is in fact reverse delegation and will prevent the engineering department from scaling (note I covered this in detail in episode 4 of this podcast).

To go to an extreme, even when a technical leader knows the solution based on the problem being presented, they should still send the younger engineers off to solve it themselves, time permitting, as it will help make those engineers smarter and more independent.

Remember as a leader, it is your role to coach the team, to make them grow, and not to solve the technical issues any more. You must learn to step back, which I know can be difficult for ex-engineers, myself included.

Unlike Medicine, Software Engineer is an immature industry

Unlike industries like medicine, software engineering is an immature industry, lacking in professional bodies, licensing, and specialist insurance for protection.

For example, if a customer finds a bug in your software, they are not going to claim your software bug insurance policy. Furthermore, they are not going to ask to see your software engineering certifications, to see what professional bodies your are a member of, because such bodies do not exist.

So long story short, there is no legal frameworks in place to make a software engineer responsible for their output. If a doctor does a bad surgery, or a lawyer fails in a legal matter, they can get sued by their customers, and can then be expelled from their professional bodies, prevented them from practising again. Such professionals really own their output, from a legal perspective. They must solve their own issues.

In contrast, a software engineer has no such consequences, so they can more easily pass responsibility for their issues to someone else, without that legal accountability framework.

Therefore it is your job, as a leader, to fill that accountability gap! You must make them feel accountable to you, in terms of presenting to your their solutions, not their issues.

Let us look at how to achieve this next, starting with their motivation.

Make them feel smart for finding the solutions

Sometimes when we have a big production issue affecting a customer, we place a lot of importance on finding the root cause of that issue, via Root Cause Analysis or RCA. While this is an important step, it is important to remember that is an early step, and now the hard work begins on finding the fix.

In some organizations, I have seen teams celebrating the finding of a root cause, and while they are busily giving each other high-fives, the angry customer is still waiting on the fix.

So we must set the expectation correctly: we celebrate when we deliver the fix to the customer in production, and not before that. Once that milestone is achieved, then I am more-than-happy to rain public praise onto the heads of my team mates, especially if the turn-around between the reported issue and fix being applied is short.

The leader needs to train the team to hit the right target: fixes in production are what matters, every other step before that is simply process. Engineers need to feel good about delivering fixes.

Reward problem-solving with peer praise

Engineers greatly value the respect of their peers, and rightly so. Peer recognition is a big part of any profession, and greatly enhances the self esteem of individuals.

As a leader, naturally you are not part of that peer group. However you do have an important role to play in facilitating those peer relationships, for example by ensuring there are internal forums in place for peers to get together, and to present to one another for feedback, and to celebrate successes together.

If you are following the scrum methodology, a natural forum for such feedback is the sprint reviews and retrospectives. The best thing to do is to get the engineers to present their solutions, and to gain from peer feedback and more importantly praise.

Everybody likes to hear they done a good job, especially from their peer group.

Some engineers can’t be coached out of this

In spite of your best efforts as a leader, sadly some engineers get stuck in that mental loop of finding and presenting problems, and never break out of that.

I have worked with engineers in the past that, when given one problem to solve, will come back in a few days and present half a dozen more problems they have found in the application. Its bizarre to me, but some genuinely think they are doing a great job by finding all of these problems.

I tell them bluntly: if you find the problem, you own the fix. You do not get to blame someone else in the team, or a predecessor, and simply walk away to find the next problem. You need to fix this one first.

However in spite of clear expectations being set, sadly I have had to let engineers go from my teams that just could not get past this mentally, and no effort in coaching was going to solve it. You have to cut your loses sometimes.

Instead I want to focus my efforts on those team mates that get things done. The absolutely superstars are those to find and fix issues without you even knowing about it. All engineers should strive for that mentality. So lets next focus on how you can coach that in your team.

Tips for those who can be coached

So how do you get your best engineers to be those superstars? Ultimately for me it comes down to getting them to care about the quality of the product they are building, and feeling a sense of embarrassment when that quality does not meet their personal expectations, let alone anyone else's.

A few years back, there was a movement to get software developers to think about themselves as artisans. I really loved this movement, as the aim was to get engineers to take a lot of professional pride in their work, in particular with regard to delivering high quality.

Even the best engineers need help on occasion though, and they should feel comfortable asking for it.

So when they do come to you for help, of course you must need to support them. One way to do this is via the "Five whys" [1] questioning technique, when you ask the engineer "why" in order to help them reach a logical conclusion, for example take the following problem statement:

"The home page has become really slow to load".

1. Why? "Its taken 30 seconds to load, yesterday it took 3 seconds."
2. Why? "I checked the logs, and we seem to be getting a lot more traffic today."
3. Why? "The traffic is coming from Hacker News, it seems we are on the home page now."
4. Why? "We need to add more server resources."
5. Why? "Let me go and add more application servers to the load balancer."

Smart engineers already know the solution, sometimes they just need someone to bounce around ideas with. Your job as a leader is to facilitate that process when required, or largely stay out of the way.

Wrap-up:

Lets recap what we have covered today:

1. We discussed why you need to set the expectation with your teams that they need to present solutions, not problems.
2. We covered a fictional example of a hospital full of medical specialists, who instead of owning their solutions, were instead presenting their problems to the manager of that hospital.
3. Clearly that is a ridiculous example that would never happen in a real life hospital, but yet bizarrely a similar situation can occur in software engineering departments, when technical experts start presenting their problems to their leader to solve.
4. Software engineering lacks professional bodies, mandated professional insurance, and certifications to make those engineers legally accountable, unlike other professions like medicine or law.
5. I am not advocating for such regulation, however we must accept that in the absence of some formal frameworks, it is up to the leader to enforce that accountability internally within the department.
6. Rather than making people accountable for issues, it is better to celebrate their solutions. Make pride around the delivery of fixes to production for customers the main goal to celebrate in your teams, give praise as the leader, and ensure that peers are also encouraged to give praise, after all we all succeed together.
7. In spite of your best efforts, some engineers cannot be coached out of finding and presenting problems, and leaving the solutions for others to find. You have to cut your loses with such characters eventually, and instead focus your efforts on coaching your up-and-coming superstars.
8. One approach you can use for coaching these star performers is the “Five whys” technique, where you ask “why?” five times until the engineer starts to arrive at a solution by themselves. You want to be a facilitator in these engagements, not the direct source of the solution.
9. Smart engineers already know the answers, they just need enough time and space to arrive there. If they ask for help, facilitate that, otherwise stay out of the way and let them do what they do best: find the solutions.

I hope you enjoyed this episode, and I look forward to covering the next topic in this series with you! In the interim if you want to follow me online, you can find my blog at TechLeader.pro, or follow me on Twitter @TechLeaderPro.

Thanks for your time, take care and have a great week!

References:

[1] : Five whys - https://en.wikipedia.org/wiki/Five_whys

Download

techleaderpro-episode-8.mp3

File details: 21.7 MB MP3, 15 mins 05 secs duration.

Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com

Subscribe

Apple Podcasts (iTunes)

Spotify

Google Podcasts

Amazon Music

Main RSS feed

Sponsor

Five.Today is a highly-secure personal productivity application designed to help you to manage your priorities more effectively, by focusing on your five most important tasks you need to achieve each day.

Our goal is to help you to keep track of all your tasks, notes and journals in one beautifully simple place, which is highly secure via end-to-end encryption. Visit the URL Five.Today to sign up for free!