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:
Day after day, they take turns coming to your office to present problems and ask for solutions.
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.
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 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.
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.
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.
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.
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"  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".
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.
Lets recap what we have covered today:
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!
 : Five whys - https://en.wikipedia.org/wiki/Five_whys
File details: 21.7 MB MP3, 15 mins 05 secs duration.
Title music is "Still Cold" by Crystal Shards, licensed via www.epidemicsound.com
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!