How to get developers to take more initiative and ownership and think through problems before escalating?

Question

How do you handle developers who every time they encounter a problem immediately forwards it to the tech lead without doing enough of their own research to resolve it? The tech lead is getting frustrated because the issues are relatively basic and the developer should have been able to work it out for themselves. Yet time after time the tech lead is having to resolve very basic issues for them and it ends up in the tech lead becoming a bottleneck for progress.

We don't understand why the developer is struggling with what we think are basic common issues when they're supposed to be a senior developer with experience in the tech.

This is like that management book "the one minute manager meets the monkey" but would like to see how others have addressed this.

Answer 1

It sounds to me like you have two possible root causes here:

• The developers could triage but are instead escalating
• The developers should be capable of triage but are not able to because they do not have the knowledge or skill, and so escalate

In the first instance, if you want to change their behaviours you need to do several things; you need to inform them of the required behaviour, you need to measure and monitor their on-going behaviour (i.e. track their escalations) and you need to feed back whether their performance meets expectations on an on-going basis. It is also worth pointing out that the Team Lead could surely reject their escalation and demand they do more triage before bringing the issues back to him/her. Before long they would learn that if they are going to escalate then they need to triage first.

In the second instance, irrespective of whether you believe they should be able to undertake the basic level of triage, it is clear that they are not able to for whatever reason. You need to look at your hiring policies and practises to understand how this key requirement was missed and you also need to examine options for how to increase the skillsets of the developers- this could be more hires, internal and external training, walkthroughs, peer assistance etc. But you need to recognise as an organisation that your capability is not as effective as it needs to be and find ways to make it more effective.

In respect of "We don't understand why the developer is struggling with what we think are basic common issues when they're supposed to be a senior developer with experience in the tech." - Have you tried asking them why they are struggling?

Answer 2

Marv's answer is a good one but I think there is one missing element and that is the REAL expectation of the organization. I highlight "real" because organizations often pitch an ideal expectation that sounds forward thinking, enlightened, etc., but behaves inconsistent to it. For example with this scenario, the organization is wanting the team to take more initiative and ownership but may also inadvertently punish that exact same behavior when it occurs, thus training its folks on what is "really" desired. How does this occur? Someone takes ownership of a problem, does outstanding analysis of alternatives and chooses a course of action, the results turn out poor (one of those pesky things when you make a decision without all the information--which we never have), and that someone takes it on the chin versus rewarded for the outstanding analysis and taking control. This happens all the time, in my observations.

Bad decisions yielding good results are rewarded; good decisions yielding bad results are punished.

So take a hard look at the organization's true behavior. You may be inhibiting the very thing you are wanting to enable.

Answer 3

As a team lead i experienced similar behaviors in my team , in my case the impact was worse as the tech lead was external and the dependency almost slowed us down to a crawl.

How I handled it ?

1. Got the team together (including the tech lead) and brought the problem out in the open . I needed to balance my message , so that it did not come across as not supporting the team or trying to overly emphasize impact on the tech lead. The key message to the team was "it is hurting the team's throughput, it is impeding the tech lead and most importantly it is impeding your learning as the team's capability to solve problems is not rising"

2. Set out some escalation ground rules....every issue that needs escalation or external resolution need through go through an evidence based triaged process .... "why does this needs to be escalated?" "what have we done to solve this problem..as an individual and within the team ?" "why are we not able to solve this problem?" "how is this problem impeding us"

3. The above questions prompted the team to look within /internally in the team first and drove the team towards taking "initiative" to solve their own problems

4. Then only "genuine" problems got escalated

5. And I also worked with the tech lead to ensure that he just does not jump in and solve the team's problems ...that they hand hold the team and work with them through a learning exercise and ensuring that the learnings are documented to be reused.

Answer 4

What I usually do is when someone come to me with a silly question or silly issue, I sit beside him/her, and I ask to show what s/he has tried, then I suggest things that won't solve the problem, I make them research in front of me, reproduce the issue, explain me the issue, etc. So the conclusion, is that the next time, because when they ask me it require them to work more, they won't ask again. This solve the problem if they are lazy, but if they were not able to solve the problem even if they tried, I will drive them to find the solution, so the next time they will find the solution/answer themselves.