How to help an experienced developer transition from junior to senior developer

Question

I have a subordinate developer on my team who has 15 years experience and has decent technical skills, yet requires the kind of handholding that I usually associate with junior developers.

He asks for low-level detailed requirements and I have been giving them to him despite the fact that I have only been with the company less than a year and he has been with the company for 11 years. If he had only a few years experience then fair enough, but I feel he has enough domain knowledge than he should be able breakdown high level requirement into low level requirements by himself. If the requirements are truly ambiguous he should be able to get clarification from users, BA, QA or the trainers.

Unless he goes beyond his comfort zone, I feel he will be stuck as a junior developer forever.

I have discussed the problem with him and he insists that the problem is due to poor requirements. I prefer high level requirement myself as they give me more room to move. I have tried to sell the freedom aspect to him, but he prefers lack of ambiguity.

He is also better at low level code than he is at design or architecture. His professional development is also focused on improving low-level code rather than his design, architecture or other aspects of the SDLC. I have taught a number of classes to the team on design and architecture, but the adoption of these aspects have been limited.

How can I increase psychological safety, so that he can make decisions instead of asking me to decide everything for him. How can I help him broaden his perspective on what it means to be a developer?

Part of the problem could be that he comes from a high power culture, and another that the company is very command and control. It is possible that this is a case of learned helplessness? Is it possible for me to reverse this, to teach him to be less helpless?

Answer 1

This guy is a valuable asset as is. There is no need to change.

He does low level work within precise parameters without problems and he's not looking to move out of his comfort zone. There is absolutely nothing wrong with this. It's worked out ok for him for 15 years and now you're trying to ruin it for his own good?

You have done a good job recognising the capabilities of an asset, so now you should utilise it within those capabilities rather than try and make it into something else. You may find that his comfort zone being threatened leads him out the door.

People like this are often the bread and butter workers who get through the tasks quietly. They don't want responsibility or risk or anything else, just to do a job they're competent at and get paid.

Answer 2

You can lead a horse to water, but you can't make it drink [*]

So this will depend a lot on the person. If he doesn't want to engage, he won't, no matter what you do to bring forth a change.

This has most likely a complex cause, but you mentioned some things in your question that I think deserve some attention:

• "15 years of experience yet requires hand holding" and "is also better at low level code than he is at design or architecture". This looks more like one year of experience repeated 15 times. In other words, he acts more like a programmer than a developer. Even though the words are often used interchangeably, they are not. A programmer mostly codes, while a software developer designs systems and is involved in all stages of software development.
• "I have discussed the problem with him and he insists that the problem is due to poor requirements". Seems like he wants to remain a programmer and be provided with complete requirements, and doesn't want to make the extra effort to invest in collaboration and asking for clarifications when he doesn't get what he wants (i.e. not engage with a broader set of activities that would belong to the developer role, not the programmer one);
• "How can I increase psychological safety, so that he can make decisions instead of asking me to decide everything for him", "he comes from a high power culture", and "the company is very command and control". These things might be some big issues. Do you notice similar behavior in others in your team? Maybe to lesser extent, but are there similar issues in others, things that can be caused by the working environment? If the problem is indeed with the environment, you need to first fix the environment, not the person. The person might be fine, the environment could be the one broken. He has 11 years of employment in the company, 10 years more than you, so maybe he knows something you don't, maybe he got burned in the past or punished for some mistake or unfortunate outcome, and now just keeps his head down and does what he considers his job and nothing more.
• continuing on the previous point, maybe this is just a job for him. I know everyone expects programmers and developers to be passionate about what they do, eager to learn continuously, better themselves and sharpen their skills, etc, but for some people it's just a job. There is nothing wrong with that of course, unless they end up doing a poor job.

These situations aren't easy to change. If you expect more from this person, you should tell him so. Decide together on a plan of action to take him from where he is now to where you want him to be (i.e. decide on some goals), decide on a timeline, help him with everything is in your power to do so (i.e. he is your subordinate, but you are in this together), monitor and follow up on progress, then re-evaluate the situation once you have more data.

Dealing with this is similar to agreeing on an Employee Performance Improvement Plan with employees who are struggling. How official or unofficial (preferable in this case, I believe) you want to make this process will depend on you. But like I mentioned above, make sure you look at the whole picture not only this person. If there are bigger issues over which the employee has no control over then those might need addressing first, and depending on how "command and control" the company is, or how deep its hierarchy, you might have issues fixing them yourself.

First make sure you understand better where this is coming from. Only then can you go for a solution that can work, not just a solution that can be applied.

Answer 3

The first thing you need to do is stop assuming that you know best for others.

From everything you've laid out, this developer is perfectly happy where he is; he has found his place in the world. Why do you seek to push him out of it?

Not everyone wants to be the next Elon Musk. Not everyone wants to put up with the responsibilities and stress and backstabbing of climbing the corporate ladder. Not everyone wants the flashy car and the big house and the expensive vacations and the latest gadgets. Some people really are just simple souls with simple needs that are easily fulfilled, and there's nothing wrong with that.

This doesn't mean that you shouldn't encourage him to step out of his comfort zone and aim higher - just remember that "encourage" is not the same as "force". But ultimately, it's his choice and the fact that he's been doing this for over a decade implies he probably isn't going to change.

So if your junior developer wants to remain a junior developer forever, let him. At the very least he's predictable, and predictability is something that managers love.

Answer 4

There seem to be 2 issues here that you have identified. One of them can be solved, the other maybe shouldn't

Specifically:

Training a programmer to use high-level specs, is something you can work on fixing. Teach him to "guess" the missing pieces, for example. Or to discuss it quickly with somebody instead of having it all written out.

Another suggested way to do this: when he asks that he be given more detailed requirements, ask him to propose what the missing pieces should be, and you'll take that proposal back to the requester for confirmation. Make it clear that the proposal will be signed off by the requester, so that he doesn't feel like he'll be held to account if the requirements are insufficient.

This is something he will become more comfortable doing, with practice, and make life easier for everybody.

The second issue, that you think he should progress to senior developer and then to management, I assume, may not be a good idea. Some programmers are best at being "junior". Give them a promotion and the Dilbert principle kicks in.

Many a Senior Programmer is such only on title, since people feel uncomfortable to have such a senior fellow without a decent title. But in reality they are doing junior's work - and they are doing it well.

It may be better to have them doing what they know how to do, than to break them and have an incompetent "senior" programmer.

Answer 5

• Make sure it's something he wants.

  Have a discussion with him about his career goal, where he sees himself in 5 years, etc.

  Also, does he strictly need to communicate with other stakeholders, or transition to design and architecture, to become a "senior" in your company? These might be commonly associated with senior developers, but every company is different and I wouldn't say these are in any sense an objective definition of seniority. I especially wouldn't expect developers to communicate directly with users in all companies, regardless of how senior they are, and some people just don't like doing that.

  It might be that he's happy staying where he is (which might mean not really learning more or new things, or it might mean learning things you just don't value as much or that aren't as valuable in the context of your company). In this case it might be a question of whether you're happy having him stay where he is, and how you want to handle that if you're not.

• Make sure he has the technical knowledge.

  It sounds like you've already done this to some extent, but this is just to highlight that he needs the prerequisite technical knowledge to do certain things.

  This might involve you explicitly training him, giving time for personal development, recommending to him or instructing him to take a specific course, etc.

• Ask him how he thinks he should do things.

  This prompts him to figure it out himself in a very direct way, while providing the safety net of you being right there to fill in the blanks or correct him if he's wrong.

  It's kind of difficult to explain how to do this, so here are 2 partial artificial (and probably not amazing) examples:

  Him: Which design pattern should I use to foo the bar?

  You: Which design pattern do you think you should use?

  Him: I have no idea.

  You: Well, which design patterns are you familiar with?

  Him: I don't know, the factory pattern?

  You: What does the factory pattern do / What functionality do we want here / How would you use that here / What about the flyweight pattern; do you think that would work here; how / ...

  ---

  Him: Should I pick SQL or NoSQL for this?

  You: What are the advantages of each one?

  Him: Uhhhhh... I don't know.

  You: What about scalability? How does each one scale? / What kind of queries do we want to run here? What kind of queries is each one best for? / ...

  ---

  [You get the idea hopefully: ask lots of questions, expect a lot of "I don't know" responses initially, suggest the answer and ask him to justify it if asking questions didn't lead him there. If you get to something he hasn't heard of, then you know he's lacking the knowledge there and you can address that appropriately by either explaining it on the spot or recommending he read up on it or take a course that includes that]

• Point him to where he should be getting the answer.

  You say "if the requirements are truly ambiguous he should be able to get clarification from users, BA, QA or the trainers". So the solution seems simple here: if he comes to you with a question that should be answered by the users, politely direct him towards the users.

  If he has some objections or reservations here, you can deal with those.

  This also applies to some extent if you want him to do some research himself, but I would be a bit more careful there, as "go Google it" is a rather dismissive sentiment.

In a nutshell: get him to do things himself as far as he's capable to, and support him where he needs it. This should apply to anyone you manage.

Answer 6

This is why experience is a poor predictor of future performance and should be weighted quite low when using it for selection purposes.

You can look for all kinds of external variables that have contributed to his current performance levels and they will likely have some degree of influence; however, most of this is likely due to nothing more than naturally occurring human variability.

After x number of years, you will have poor performers, mediocre performers, average performers, great performers, excellent performers, and hyper extraordinary performers. And the numbers on that right side of this curve are quite low while most will be somewhere in the first three levels. You can put any number you want in the "x."

While it's great to find ways to continue training him, you and he might be better served to understand that he might be at his ceiling in development and begin searching for other areas where he has more naturally occurring strengths. Or simply assign him the kinds of tasks where he has exhibited at least okay performance. If he is taking up a seat where you cannot afford, either in cost or output, his level of contribution, then you need to make a very hard decision that managers have to make from time to time.

Answer 7

You would like to see more initiative in working from high level requirements.

Your co-worker would apparently prefer the certainty and security of having very detailed marching orders before they begin the implementation journey

Perhaps you can find a middle strategy that's a path of growth, specifically: Ask this person to take a try at interpreting the high level needs into a proposed detail requirement which you will then discuss together and then with stakeholders before the actual implementation effort begins. In short, ask them to make an educated guess, but with support such that it's perfectly okay for that guess to be wrong.

And this is, of course, what most experienced developers tend to at least informally do as a matter of habit: interpret, restate, and seek confirmation - "When you say x, do you mean that the y should z?"

Answer 8

Do you think the team's way of working is giving him the chance to contribute? For example a team that is a) cross-functional, b) self-organising, c) closely collaborating with its stakeholders, d) regularly inspecting and improving its ways of working? Such an environment tends to get people out of the kind of rut you describe and into a more positive spirit of contribution. The fact that you are supplying detailed requirements and the other aspects of SDLC that you mention suggests that the team as a whole could benefit from a more agile way of working.

Answer 9

Whilst the other answers here are really good, what you have described here is a common scenario that I use to explain to my junior team members when I on board them:

With enough experience, many of us can become great programmers, some of us may also become good developers.

A good programmer knows their language and tools and how to use them to write code to satisfy low level requirements. To be a good developer, a firm programming ability is essential but they prefer to operate with higher level instructions and often explore the design and structure of a solution that might extend outside of the requirements.

I need good programmers on my team to get the work done, in many cases they are not solving problems in the business domain, instead they are solving the problem of how to express the requirements in terms of code.

But I also need a balance of developers who can flesh out the high level requirements into the detail needed for the programmers to complete, they make the decisions on how the lower-level code will be implemented, they will often drive the core design of structures and processes but may not necessarily carry out all the work. A good programmer will often delegate the final implementation of code once all the decisions are made, these developers are on their way to becoming architects.

Too many developers can lead to frequently running over budget or time constraints as they may get distracted with the many "what if" scenarios that they come across, too few and it may be hard to keep up with the necessary documentation to keep the programmers engaged and operating at their peek.

They are two different methodologies and thought processes, many of us get comfortable or complacent in one mindset and may not be interested in developing our skills in the other one.

If your subordinate is truly interested in transitioning to becoming a developer then deliberately give them a task (one at a time, you need to manage this process carefully) of breaking down a high level requirement into more detailed low level tasks that he will NOT complete. To get the full experience, you should allocate the completion of these tasks to yourself, in this way you can give direct evidence based feedback without hypothesising about how their requirements might be interpreted.

• Through this process you can often quickly determine some key areas of their thought process or experience that they are lacking in, as a good programmer yourself you may be able to design some other thought exercises to help them overcome their issues. ;)

Answer 10

One of the terms you can search for more information is called "task relevant maturity". It sounds like your guy is very mature within his certain tasks. But other tasks (like design) require and entirely different skill set.

If you want to help someone transition into a new set of skills, you need to identify the skills that are essential to that role, and help them develop those skills.

Of course, this also assumes that they want to engage with those new tasks! Some people do not -- and as long as they're fulfilling their role, as long as they enjoy the work that they're doing and don't feel stifled, that should be fine.

Typically people want to grow, though, so I would be surprised if they were doing quality work and are just 100% content with where they are in their career. They could be, though, in which case, hooray!

But these are the kinds of things that you should know about and be discussing in your 1:1s. You are having 1:1s, right?

Answer 11

I want to add another possibility that has not really been covered by the other answers. Perhaps hinted at, but not explicitly. Obviously, this may not apply in this particular case due to the people being unknown to me, and myself not having the professional credentials to say if it applies either. But:

People with a certain "mental makeup" are often drawn towards Software Development work, and initially this works mostly well: they function securely in the precise machine-interaction world. It starts to become difficult when they need to interact with (and perhaps exert management control over) humans and the human world of ambiguities, idiosyncrasies, unknowns and unknowables.

What I loosely term "mental makeup" above is sometimes diagnosed as (Adult) ADHD, Aspbergers', (High-functioning) Autism, or the general term Autism Spectrum Disorder, which has physical, developmental and environmental underpinnings amongst others - so not necessarily the person's "own fault". I understand that this area still generates a lot of controversy in the psychiatric profession, which along with other factors causes it to be under-recognized and under-diagnosed (from one side of the debate).

Whether or not one agrees with this being a genuine condition, I feel a number of very beneficial practices have been developed for the management of the outcomes via behavioral therapy, and a person could probably apply such if he feels they are applicable, diagnosed or not.

Just taking the general points made by the ADHD article above, intelligent people often learn coping skills into adult life, and while those coping skills are usually sufficient for a basic function (such as his current job tasks), they are not sufficient for excelling (which also explains the comfort zone). The positive point made in various articles is that given the right help, and playing to the person's strengths instead of trying to correct weaknesses, may transform the employee into an excelling asset to the company (and himself). The danger here is that the traditional corporate "career path" task/responsibility assignments, and the path of "improvement plan or else firing" will often exacerbate the problem due to the increase in stress. Also, the normal pop-culture platitudes (e.g. "challenge your comfort zone!" or "it's all in your head!", while they may be true in a literal sense, are not helpful.) Such conditions can also lead to a lot of destructive behaviour, one should acknowledge when a person is adult enough to have curbed such impulses.

Such a person often finds it difficult to "figure out the adult/corporate world" and function in it at a seniority-appropriate level (a.k.a. "adulting"). Typicals/"normal" people may not appreciate how deep this goes, and may be exasperated by the "basic" things gotten wrong that the typical takes for granted. (Friendship and mentoring with a typical with enough empathy to work through this may be beneficial.) One will also often find a lack of confidence and self-esteem, leading to a risk-aversion in taking on new challenges due to an (overblown) fear of failure. And lastly, figuring out social interactions and relationships is also a challenge, so they will probably appreciate someone taking interest in them as a person (not only as a fungible corporate asset).

Sexed terminology: You refer to your co-worker as "he" and in this case it might be relevant: about twice as many diagnosed people are male as female, and there may be some genetic link (see articles). However, it is reported that females' experiences of the condition(s) differ subtly from males - although a lot applies to both sexes. Here is a recent article about ADHD from an adult woman's perspecive which I found insightful.

A lot of helpful material may be found via websearches: "adult adhd career | work" etc. Here is the relevant section of a site I stumbled on just today, way-out country and all, after reading the above women's article. I've initially become interested in the subject due to various personal stories on IT-related discussion forums I've read over the years, shared by people in a work-related context.

If I were in your place, I'd approach the issue along the following line (incidentally, I think it may be appropriate for all subordinates, so nobody needs to feel left out):

1. Spend time with subordinate(s) to get to know them on a personal level. E.g. have a one-on-one coffee/lunch break with each one, twice a month or more if practical. (Or if you are both smokers, I've seen that in the age of indoor smoking prohibitions a lot of bonding can happen at the designated smoking spot.) Just steer in a more focused direction: How do you experience ? I find sitting close to the coffee machine distracting due to all the chatter, what about you?
2. As a supervisor, discuss a "career improvement" initiative with subordinate(s). If not company sanctioned, this can be informal and lo/no-budget. I'd suggest finding out each person's strengths, exploring those, and sharing out tasks according those to improve team performance.
3. Some tools like the Gallup/Clifton strengths finder (paid) or 16personalities (free + extended material paid) among many others may be helpful. And I acknowledge again that these are considered not scientifically rigorous enough by some practitioners, but may still be helpful to get something going, for lack of better tools.
4. At some point during the above, and knowing your coworker well enough on a friendly level to allow such a remark, you could gently steer him towards reading up on ADHD (etc.). Even something sneaky like "I read this article on ADHD today, wow, didn't know that was a thing, just imagine having to struggle through life thinking there is something wrong with you but not knowing what, and just struggling on in the old rut." If he recognizes himself in it, he can find out more and seek help. I'm not sure, but I feel that in many jurisdictions it would be illegal or at least unethical for an employer to allege a certain medical condition in an employee and demand he undergo medical treatment - has to come from the employee informing the employer if he asks for Reasonable Accommodation.
5. ... Then follow through with applying the team members according to their strengths where possible; it might just be that your team, your company and yourself might benefit from it too.