Bright Apprentice not being taken seriously

Question

We had an apprentice join our team in late 2017, this is the first time an apprentice has been given a rotation in the Software Development Team so it's a new concept to everyone. For the purposes of the question I’ll call him Dave.

Despite being fresh out of A-Levels and having no previous experience in Software Development, he has picked things up so quickly and rarely asks for help from anyone.

The issue is that my other colleagues don't seem to see what I am seeing, Dave is doing things that even some of the Senior members of staff can't do. There's been occasions where someone has struggled with a problem and he's offered to assist and is never taken up on the offer. He's came to me and explained and the solution he had to the problem was pretty good.

On occasion I've even said, "Have you asked Dave, as he's just completed a course in that?" and it'll be blatantly ignored, and they'll proceed to ask another team member who equally has no clue in the subject. On the rare occasion he's able to interject into the conversation, he fixes the problem and often does it very quickly.

I've already tried explaining to everyone how good he is and the achievements he has made in such a short space of time, to no avail. He really wants to make a good impression to help kick-start his career but finds it hard that he has not been listened to.

How do I get this across to the team? Dave has developed multiple programs that are being used in live since starting but people don't seem to take him seriously.

Answer 1

When I started my apprenticeship as a software developer, I was in a similar situation. Although I had no qualifications "on paper", I had a lot of private experience with software development. Just nobody believed me. So what I did was ask the most respected senior developer on the team what he was working on and if I could take a look. I then spent the next day analyzing the sourcecode looking for the worst part I could find. Then I approached him and asked:

Hey [senior developer]. I've looked at your sourcecode and there is one thing I don't understand. What's the reason why you didn't use [more efficient solution] here? I am sure there is a good reason why you used [inefficient solution]. But I don't know this technology as well as you do. So I would really like to know why you did that.

Now, he did of course not have a reason to do it the inefficient way. The efficient way simply didn't occur to him. That moment he understood that I am far more capable than my job title would say, but the way I showed him was submissive and unconfrontational, so he did not perceive me as an obnoxious know-it-all either.

Five years later, I got his position.*

*_{no, don't worry. I did not bully him away. He got an even better paying job offer somewhere else.}

---

One thing you should teach Dave about is the importance of visibility in the workplace. People might underestimate him because they are not aware of his talents and just judge him by his job title.

Things you might want to encourage him to do:

• Hold presentations in front of the team. Conceal it as an exercise to test presentation skills.
• Look for internal projects which are of interest for management.
• Solve long-standing problems everyone is afraid of tackling.

Answer 2

As a software developer, I've been in both your position and Dave's. In software development teams that have worked together for a long time, each colleague starts to develop an idea of who is the 'go-to' for knowledge on a particular project or system (especially if it's something so esoteric that StackOverflow can't help!). It's great that Dave is well-qualified and picking up things quickly, but in cases where time might be against them, a colleague may simply seek out the one they know for certain has experience with the bit they were stuck on. This does not just apply to apprentices or junior developers. In one job, despite having two senior developers above me, my colleagues would ask me questions about C# problems just because I was the 'C# guy'. I had to make it clear to them over time that others knew enough about it too.

One solution could be to make your team more aware of what Dave has been working on (not simply just the achievements). It sounds as if your colleague did not know or had to be reminded that Dave took a relevant course in something. It may also be worthwhile asking to Dave to, for example, shadow a colleague on a JavaScript task after he completed a JavaScript course. This will help Dave make more of a name for himself among the team and it will also make your colleagues more confident that he is more than merely book-smart, and therefore more likely to ask for his help when the time comes. This can even be demonstrated by giving Dave the chance to work on a high-profile or important task (if you feel he is ready).

The more Dave integrates with the team, the more they will come to acknowledge and depend on his knowledge. As Dave is given more chances to demonstrate knowledge that can only come from working with your development team, the more likely it is he will be sought out for advice.

Answer 3

It would be worth speaking to Dave's manager and/or the Development Team Manager (if they're different people) specifically on this subject, and not just in casual conversation.

With the Dev Team Manager you should highlight this issue that you've seen and suggest that they look for opportunities not just for him to grow and contribute, but for him to take actual named responsibility for something. He'll be much harder to inadvertently sideline of he's the go-to on a particular technology or has a position of responsibility in a project. This also has the benefit of being very good next-step learning for him.

With his own manager it can be in the form of feedback for his next appraisal and perhaps even a recommendation of promotion / title bump / pay rise / bonus / re-thinking his career development opportunities in light of his exceptional progress.

You should also offer to mentor him if nobody else is.

If appropriate you could also offer / request for him to join you with some of your work as a way for him to cross-train, gain broader experience, contribute where he's appreciated, and get wider exposure.

Answer 4

Maybe some people in the team don't want a bright apprentice. What should the boss think if the apprentice does some things better than the so called experienced team members? And probably the apprentice is paid a fraction of what the experts get.

It seems the apprentice is too good for that team. They want someone who is not good and does not learn fast. They want someone who asks the experts and who does not have good ideas which the experts don't have.

I guess you have the choice to be on the side of the team or on the side of the apprentice and against the team...

Answer 5

Give it time

Though there are plenty programmers who try to stay ahead of the game by adopting new techniques, in my experience I've concluded that, in general:
Programmers who've never/not for a while experienced new input like status quo.

They're not fond of new techniques/programs/methods/... they know how the current ones behave and what quircks they have. Switching to, say, a new programming style could take quite some effort and IMO even more effort from the older people. And now imagine some random new guy saying it. And he's getting all this praise for it too, where they maintain a balance which never gets complimentented¹!

I don't like using clichés, but this is a situation where 'respect' has to be earned. First show he's a team playing, a bit more passive aproach. After a while he will appear competent, even without showing code. After a bit, if he has his own tasks, he could throw in a "hey, I've written this snippet, I'd like your thoughs about it". That way he can show his level and at the same time learn how the rest of the company works (all new ideas sound great, but are they a fit?).

After some time, the status quo will include him. In my experience the more you push change, the more you get pushback. Find the flow, join it, influence it.

¹ Might be incorrect, but it explains the emotion a bit.

Answer 6

This answer is based on my experience as an apprentice.

Fresh out of school with A-Levels I got a position as an apprentice in a multinational consulting company, we went through an initial training period most of which did not expand significantly upon my already existing self-taught knowledge. But what this did provide was access to mentors whose role it was to provide guidance, answer technical and conceptual questions, and whose influence provided major benefit to my growth.

Upon being launched into the main company I was put in the 'innovation' team, there were lots of exciting things being developed which we could only have cursory participation in due to our needing to progress through the 'training program' & apprenticeship coursework.

Whilst there I entered into discussions with the head of a department about onboarding, and was assigned by them the task of developing an onboarding app prototype. I found a few apprentices to run this with on the side and everything was going well.

After a period of developing this during my evenings I realised that I was likely missing certain knowledge which would improve the development process, technical information regarding technologies of the time such as Angular, which the innovation team were making use of on a daily basis. I approached the lead engineer on the team for advice, was told he would not put aside any time for me as I had yet to finish the coursework (which I had no interest in, I would rather be coding), and was subsequently interviewed by him about how I was assigned this project rather than the team as a whole, he did not understand why a head of a department would choose me to run this and wanted to claim ownership of it.

This significantly demoralised me, I continued without guidance on the development but did not know how to process this situation or to seek help from elsewhere. Around this time I was going through a breakup with a longtime partner, this combined with being away from home and having little emotional support meant I started arriving late to work (despite always leaving last). A week or two of this, a missed medical appointment (I started using my existing condition as a crutch to explain away my late arrivals), I was pulled into a HR meeting by myself and given the option of being fired on the spot or signing my resignation letter, I wrote my resignation email in the interview room as I felt I had no other choice and was gone before lunch.

My manager, the team, the head of the other department, no-one know this HR action was being taken against me, the HR figure that did this to me was let go shortly afterwards.

In short, if possible try to protect him, bring his situation to the awareness of the higher ups and shine a light on his potential within the organisation in a role outside of the apprenticeship itself, explain to him the bureaucracy and how to exist within it, whilst guiding him towards mentors and being mindful of his situation, he is likely full of optimism and courage, but there is a fine line being tread between thrilling challenge and being left to wither within a corporation without support or nurturing of his talents.

Answer 7

You and Dave should be more direct in your offering of help.

Dave is surrounded by senior software engineers. Telling them "I know something" is easily ignored (maybe out of pride, maybe because they honestly don't see how Dave might help them). Telling them "You need to use X in this way and Y in another way to accomplish Z" is very concrete, proves his knowledge and makes it hard to dismiss.

The same applies to you. Asking a senior engineer "have you asked Dave" can be understood as

• "Take Dave under your wing and try solving the problem together" - which may not seem very reasonable
• "Have you tried randomly asking your colleagues for help?" - which he did, he just randomly asked another colleague
• "I know that Dave knows how to help you"

Instead tell them "Dave mentioned that he knows a solution to your problem."

Answer 8

While I agree with pretty much all answers already here with the following pieces of advice:

• Give it time
• 'Respect' is earned over time
• Make him medior/senior
• Assign bigger/more complex tasks
• Get Dave to do pair-programming with the others/seniors

I think something is missing. In your question you mention that you've already been trying this and that:

I've already tried explaining to everyone how good he is and the achievements he has made in such a short space of time, to no avail. He really wants to make a good impression to help kick-start his career but finds it hard that he has not been listened to.

There's 2 things that stand out, 1 of which becomes a question:

1. "[...] kick-start his career but finds it hard that he has not been listened to"
2. You've been trying to explain - How long has this been going on?

If this is "pretty long" (fill that amount in yourself, you're the best judge in the situation), I come to this advice:

Tell him to find a job elsewhere.

I mean this in the best-case for Dave. If you've been trying the above and have probably tried most of the advice/answers to your question here, tell him to just leave. Software developers are in short supply, being somewhere where you're not listened to sucks. Ok ok, you listen, but "the rest" doesn't, that sucks.

Anyway, that's what I'd do if I had an intern become a not-so-much-intern anymore and have this happen. I would also tell him to put me down as a reference and to no longer apply for intern jobs; junior minimum (based on amount of time in jobs, managers tend to get their knickers in a twist over "too" young mediors/seniors).

Answer 9

Why is Dave still a junior if he can outdo Senior staff and pick up on things quickly? The only way I see to force this is to make Dave a Senior or Mid-level dev and assign bug tickets - assuming you're using scrum or kanban - to him.

Other than that, you just need to improve his reputation with things that actually matter; achievements, not standard grades in standard courses.

Answer 10

There's more to being a senior developer or a team leader than programming skill, there's communication, accountability, and responsibility for starters as a senior dev you're responsible for more and are more of a go to person(s) for... everything, you don't get to pick and choose usually.

Then there's architecture / design patterns, I've had folks on some of my teams who can solve most technical problems (some I've failed at), but the moment you ask them to design something is a WTF moment to put it nicely.

So what should Dave do? Make a big deal of the problems he solves, demonstrate an understanding, rather than stating "it's done" ( which is synonymous with "it was simple"), show an understanding of the system, and produce code with minimal bugs.

What should you do? Encourage Dave to explain his problem solving to the rest of the team. Also, if he's picked up the skills he feels he needs, you should encourage him to apply for a non-apprentice position there or elsewhere.

Answer 11

Dave could use the Ben Franklin effect...it sounds like he is kind of on the bad side of it right now.

The idea is that we like to believe that we are fair, so if we do someone a favor we subconsciously rationalize that they must be a good person who deserved a favor, and conversely if we do someone harm (even by accident) we try to rationalize that they somehow deserved to be harmed.

Pitfalls to watch out for: If you ask for too many favors, or too large of favors, that doesn't work. If you preemptively do things in return, it doesn't work. And if a neutral third party asks for favors on your behalf, it doesn't work (and may be detrimental).

It seems like you and Dave have been falling into categories two and three. Dave's large backlog of favors that he has done for others leave them feeling like they owe him, which actually makes him less popular. And your cheering him on as a third party makes him less popular.

If Dave, on the other hand, asks to be shown or taught something, the person showing/teaching will 1) feel good about Dave because they did him a favor, 2) feel good about themselves because they had knowledge that was useful, and 3) maybe think Dave is smart, if he asks good questions and learns quickly.

Unfortunately Dave isn't here, but my advice to you is to stop cheerleading Dave quite so loudly--that is, stop bringing Dave up any time someone needs help. If Dave does help you, then that's OK to mention, or if Dave does really good on a solo project--but at roughly the same level you would mention any other teammate.

Instead, try to get Dave to talk to other team mates as an apprentice, instead of as a teacher. For example, there's always domain specific knowledge that isn't available in written resources. If Dave runs into any problems like that, you can point him to a colleague who is both knowledgeable and likely to be flattered by him asking questions. ("You should ask Sally and Bob--they worked on this originally and know all of the picky details about why certain things are the way they are.")

https://en.wikipedia.org/wiki/Ben_Franklin_effect#Uses

Answer 12

It's always been the plan that I should just convince the top people in the industry -- CEOs, CTOs, academics, top-level consultants, heads of government sectors needing advanced techn, and more or less let the know-nothings say what they wanna say. Then I'd have a startup and when I start earning money (a lot of it), that should speak loudly for itself.

But things have changed from then. Excessive ridicule had worn away my and my product's credibility. At first, I was very, very opposed to having my work be shown in public, but I eased up a when I found it countered those false rumors of what my work is about. With how quickly I eased up, I didn't even realized that it bothered me that much that my capability was questioned.

Right now, there's even a good chance that I will lose and that will take out the deterrent. The people I've angered would then do everything in their power to stop me from launching my startup.

---

About those programs "David" wrote. If those programs are no more than many hundreds to thousands LOC, then I doubt what he's solved a commendable problem. And to disappoint you, it's either I write sizable software (ENR still being the biggest) as products or small wrappers for Unix tools and such. I don't bother with small program prompting you to enter values through the CLI, doing minor things.

I have a folder of my solutions to combinatronic problems -- permutation, combinations, solved with small functions. The functions' corresponding test C files are the only small programs that I have. At the very start of this journey, I thought I was gonna need those functions. Didn't turn out to be that way. Well, it had to be written down anyways.