The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
Several months ago, I hired someone to join my team of 5. Even though they had no prior work experience, they showed promising signs during the interview.
It's been 10 months, but I feel like their progress has been quite slow.
They are forgetful
They make a lot of mistakes
Overall, they've made improvements so far, but I feel really exhausted. The smallest things are being spoon-fed.
What is the appropriate timeline I should give to meet those goals? When do you throw in the towel?
My strategy is to focus on a juniors strengths and give them work that is in line with their strengths so that they get a positive experience and build confidence. So if they can't plan a project, I don't give them a project to plan.
In your case the junior doesn't appear to have any strengths in terms of the work that was available (which I've seen a couple of times). 7 months is more than enough to have systematically gone through the whole finding their strengths thing. If they're not compatible with the work, then they're not compatible.
Alternatively you just haven't explored their potential thoroughly yet. It's really something only you can know.
I believe people deserve a chance, but what is the appropriate timeline I should give to meet those goals? When do you throw in the towel?
There's no magic number regarding how long you attempt to coach someone up. But I suspect 7 months is more than enough.
You throw in the towel once you conclude that the individual will not become able to meet the requirements of the job, even with more coaching.
You have work that has to be done. Once you conclude that the individual isn't capable of doing the work, it's time to move on.
When you say "no prior work experience", it sounds like they're fresh out of college? If so, 7 months is still a borderline reasonable time for someone to still be working on proficiency in the daily grind. It could easily take longer depending on how chaotic the environment is or if there are unfavorable team dynamics.
That said, this does NOT sound like it's merely a matter of fine-tuning habits and practices but rather motivation.
It's very common for people starting their careers to begin with a job that's not for them. Either they discover their job/career isn't what they thought it would be and thus can't get motivated or they lack the coping tools for just dealing with the day-to-day motions of a workplace with hierarchy. These problems are common with folks leaving an academic environment who don't have much practice in a workplace through something like an internship.
I think it's best to just communicate frankly with the person and gain some insight into their point of view while keeping in mind that it's likely very different from yours.
There might be nothing that you can do to address and correct the problems. If that's the case, then you can try to counsel them to start thinking about other roles either within the company or elsewhere. It doesn't have to be a "PIP" or "you-re fired" conversation. It could be they need a more interactive manager, or even just a more collaborative cohort of juniors who can model the correct behaviors. The only way to find out is to try. If it fails, the employee will soon start looking for other positions and eventually leave.
Of course, termination is on the table. I sense from your language that you want to avoid that, but sometimes it's what needs to be done. Getting fired from one's first job in less than a year isn't such a bad thing. It's not uncommon and future potential employers will usually understand and accept that it was a bad fit.
From your examples I see a theme of not retaining information from conversations or meetings. Could this person have a tendency to be overwhelmed by social interactions? In particular the stories of picking random pages in a notebook or zoning out during revision meetings give me this impression. There can be a number of psychological reasons for this, social anxiety or autism spectrum disorders come to mind. Neither you nor I are qualified to speculate on this, of course.
This is of course not an excuse for bad self-organisation, but if taking in information in conversations is a culprit there are ways for you to help them. Chiefly writing stuff down, so they can reread and consider the relevant information once the stressful situation is over.
Do you take meeting notes? Having someone write down the crucial topics and decisions on a shared screen is a good practice in general. Not having to worry about retention of information lets people focus more on the topic at hand. (Make sure that all relevant information for this particular junior ends up there.)
If you are speaking one-on-one, you could accompany your spoken interactions with written ones. Line out the broad strokes in a quick conversation and type out the detailed information in an email or ticket. The comment section of a ticket also is an excellent place to have some clarifying back-and-forth if needed.
These are some relatively low-effort practices that can make work life easier for people that struggle with social interactions.
It seems that up to now you have identified what went wrong (correctly taking in requirements) but it seems you have let it crash and burn and then told the employee that that was not good.
That is the first step I always take with apprentices, too. Instead of vague abstract lessons on why they should do something, let them do it without and let them see the catastrophe that follows. If you have the time to spare, this is a good teaching method because it removes the abstract book learning and gives them a hands-on example of why they need to learn the thing you are teaching.
However, then you have to follow up with a method to avoid the mess they just made. So in your case give them a lecture on how to take notes. Then, after every meeting, go through their notes with them and make sure they did it the way they are supposed to. After a few times of success, you can let them do it alone and only check the results. If they stay good, great, lesson learned. If the results start to suffer again, go back to checking their first steps of taking notes. You never mentioned you did this, so I assume you did not. It does take this step though. It's not optional. That is how people learn. It's never too late for it, you could start with it as early as tomorrow morning.
That said, that is what I do for apprentices. People out of high school. People that make a salary so low that it mostly forces them to live with their parents or share rent with other students and apprentices. If you hired a college educated worker on a full salary, it is up to you whether you "have the time" to do that. For me, personally, 7 months at full salary is certainly a complete waste to teach someone to take proper notes and at least know what I want them to do.
Sometimes, letting people go and taking the chances with a new hire is the better way to go. I cannot decide that for you, but just because you hired someone does not mean you have to keep them, especially not if they don't produce value worth their salary.
We've gone through something similar. 9 months was our line, but only because that was the contracting period of the temporary agency we were hiring through. At the end of the 9 months we simply did not extend the contract (whereas with other juniors, we converted them into full employees).
In our case, we accepted someone with weak technical skills (but did have an appropriate degree) because we did have a lot of weak technical work that needed to get done at the time. Efforts were made to ramp him up on the technical aspects but it just wasn't getting better so when the time came for the contract to end, we let it end. Temp agencies are pretty expensive but that is one real advantage to them: not renewing a contract is easier than terminating a full employee. Kind of a try-before-you-buy.
It sounds like you're at the point where either you find something else for this person to do or you start looking for the replacement. You've done due diligence in trying to steer them but if the feedback is falling on deaf ears and improvements are not happening then there's not much more to be done.
There are many reasons why someone can be forgetful and disorganized. Some reasons may include a willful lack of care or diligence, but other reasons may be of a personal and/or temporary nature. It's really hard to find the root cause when you can't cross personal boundaries (and I'm by no means implying that you should cross them).
You've tried to work with them; but it seems to not take effect. I cannot judge whether you helped them in the right way, or whether they can even be helped, since I'm seeing this problem through your eyes.
At the end of the day, why someone isn't meeting their targets isn't your concern (barring them being blocked by issues in your company). You have to judge this based on their actual effort.
Look at the total amount of effort/time that goes into completing a task. Whether they are a slow worker, or they work fast and often have to redo things, it boils down to the total amount of time, effort, and impact on others.
If you suspect this person can be helped, then it'd be better to help them than it is to replace them. However, if you do not want to do this, regardless of whether they do not improve sufficiently or you simply don't want to have to coach them through their daily jobs; then you should consider letting them go and replacing them.
Where you draw that line is highly subjective and I cannot answer this for you.
The Problem
What you may have here is someone who may be utterly lost in the details and is not abstracting away from them well enough to keep in mind the primary goals. A example of this kind of problem would be someone who when driving, instead of looking far ahead, looks down at the road immediately in front of the vehicle in an attempt to stay between the lane lines. This will work well when the road is straight but not so well when the road curves, and of course if they're that focused on the lane lines they're almost certain to miss the cross street at which they're supposed to turn.
High-level Goal Summaries
One thing you can try is to ask the developer to first write a high-level summary of the task to be accomplished. This should be no more than a few sentences; if the task is large enough that it requires even a couple of paragraphs, break it down into several different tasks. (If it's complex enough that it can't easily be broken down into independent tasks, you should probably assign it to someone else for the moment.)
Review and discuss this summary with the developer before they start in on doing the work itself. While in the long run you should not be writing the summary for the developer (the point of the exercise is to have them practice extracting high-level goals from the full set of high- and low-level information they're encountering), at first you may need to walk them through the process by showing them how you would write it so that they can see examples of how good summaries should look.
Once the task is "done" (in the developer's opinion), they should compare the result with the summary they've written and decide whether the goal has been achieved. Only then should they come to you where you can make the same evaluation and, if your evaluation of "doneness" doesn't agree with the developer's, you can have a discussion about that.
Writing these summaries is likely to be quite difficult, and the junior developer may not have the skills to do it. As Edsger Dijkstra said, "Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer." Unfortunately I have little advice to give in developing the language skills necessary to do this except "compare your attempts with a lot of good examples and practice a lot."
Further Development
Once this basic concept is working, there are two things you can add to these little "stories" to help continue the training and improve results.
The first is a checklist of further requirements that need to be met that are not part of the high-level goal. This is where you work on issues with forgetting details and being sloppy. Some of these would be specific to individual tasks and should be kept with the summary for that task, such as "ensure buttons are properly aligned and centred" when the task involves adding a new button to something. Others will be general items that apply to everything that you introduce step by step, such as "ensure there are no misspellings" or "ensure indentation is consistent." All of these things should be in a a form that can be walked through like a checklist; the developer should check each item before declaring the task complete and you should go through each item with the developer and, if any of those requirements are not met, discuss with the developer why they felt those requirements were met. You'll want to add general items very gradually; ideally after concentrating on a new general requirement for a few weeks it will become automatic and can then be removed from the list.
Eventually, as the developer gains the ability to understand these details, you can introduce the higher-level goals that motivate these details. For example, code formatting is not important in and of itself: it's something you do in the service of the goal to better communicate with other developers. (This is essentially moving along the Dreyfus model levels of skill acquistion, described by Benner as novice, advanced beginner, competent, proficient, and expert.)
The second is a brief analysis of the business goal of the task. This is essentially a higher-level version of "looking at the road far in front of you"; developers will do a better job of implementing things if they understand the business goals (which are often, in the end, the only reason the developer is implementing anything at all). I suspect that this is something your junior developer will not be ready for for some time, but keep this in mind as one of your long-term goals and if you happen to find that introducing it earlier works (perhaps the developer really does pick up understanding of business stuff easily and knowing business goals would better motivate them), do so.
Senior Developers
The techniques I've described above are not something just for junior developers; good senior developers do the same thing, though often in less formal ways. My internalisation of the "communicate clearly to other developers" goal makes things like ensuring my code is well formatted an automatic action. The summaries I described above may be just in my head, but there are plenty of programming situations where my serious work didn't really get started until I stopped writing code and instead started writing up a header comment in the file explaining the overall goals and how the code structure helped to achieve those. And there are plenty of commits that got a good rewrite (or even just got deleted) after I'd "finished" them and attempted to write a comment message explaining to the other developers what I was doing and why.
Summary
Just as writing code forces you to confront misunderstandings that you didn't see or glossed over when you were whiteboarding pseudo-code, writing down a summary of a goal for someone else to read does the same. So train your junior developer to write these out, ensure that they make sense to someone else, and compare what they've done to the summary after they're done.
When they achieve some compentence in this, gradually add to this other points that will help them remember to address details that they forget and learn about the larger scope of what they're trying to do.
Metaphorically, teach them to drive by looking at the horizon ahead of them, rather than the bit of road immediately in front of them.
In the end, this may or may not work. You may not do this well enough yourself that you can teach others, or they may be unable or unwilling to learn. In that case, the best solution might be to move them to a job other than software development (or engineering in general) where managing technical details and getting them all to correctly serve high-level goal isn't a central component of the job.
You are failing, not your new hire.
You indicate that they are performing well enough in a technical knowledge sense, but that they are forgetful and their work product has mistakes in it.
It's your job as a manager to understand how many touch points each member of your team will need to keep them on task. A "forgetfulness" problem is not that major a problem unless you allow too much time to pass before you realize that your staffer is not on task. Are you letting weeks go by before you ask them, "How are you coming on X?" If so, that's your error.
If their work has errors in it, what's your QA process? What's your code review process? An iterative development process is not necessarily a huge negative, unless you as a manager have grown accustomed to just sitting back and letting your staff produce perfect work without your intervention or management. Your project timeline should allow time for development, time for QA, and time for corrections. If the staff meets that timeline, then the project is successful, and it is petty to turn to the developer and say, "Hey, I'm really angry that QA found mistakes - even though that's what we pay QA to do. And I'm also really angry that you corrected those mistakes, even though having time to do that was already planned for."
[EDIT]: the question looked very different when the following answer was written; the context and details I address are no longer present at the time of this edit. Even the first sentence no longer matches as 7 months was changed to 10.
If they had the right tools for the job, 6-7 months is not overly long to give a new software hire a chance.
The question then becomes: did they have the right tools for the job? A few things stood out to me.
First, it sounds like there are more paper notes being taken for a software job than I would have expected. Is there not a software-based issue tracker or task management system being used that could take the place of some of that paper? In addition to being easier to search for that information later, that has the added benefit that the information would already be written down and saved in case some other developer had to take it over, which seems like an overall win for the team.
Is general information -- instructions to set up the development environment, information on relevant network infrastructure, general engineering procedures, the software style guide, etc -- saved somewhere for new hires to look up as needed, or does every new hire write notes about all this, and if so, why is that information being duplicated, potentially poorly? While I've definitely had to tell junior developers "I'm not your darn secretary" before, and that may well be the same thing that is going on with you, there is something to be said for trying to make on-boarding less of a hassle for everyone in the future.
Secondly, I'm surprised so many typos and formatting errors are getting into their work in the first place. Is this developer pushing code that doesn't compile or run, and if so, is there a way to set up your version control system / repository to identify or reject failing builds automatically, so they know quickly that they need to fix it? I know gitlab supports continuous integration, for example, as does github.
Can your development tools not automate enforcement or correction based on style rules? Even a free IDE can; it is not the only one, but it is free, so there's not much of an excuse for not having automatic formatting. Unless a lot of their responsibilities involve something other than code, this sounds to me like a problem that has already been comprehensively solved by and for software development, so I'm a little surprised it seems to be such a sticking point. Using existing tools can make it easier for any and all new hires--and maybe even existing ones--to get it right.
For the third problem, it's possible what you're calling a "smaller project" is similar in scope to what I would call a "task", but it does strike me as unusual that a junior developer would be responsible for an entire project and its requirements by themselves. It's been a while since I've used the IEEE software engineering level descriptions (unfortunately behind the IEEE login), but my recollection is that they were similar to those the ASCE uses, which is currently publicly viewable. The first two levels--where I'd expect to find a new hire without prior experience, or generally a "junior developer"--are not wholly responsible for projects (ASCE starts that at level 4 of 8), and still involve a great deal of supervision. Four out of eight is more middle than beginning, so it sounds from that like the kind of developer who could be expected to have the right tools for managing an entire project and its requirements would be, if not a staff developer, at least a (non-junior) developer.
There's no point in trying to fit people into molds because every one is different and this becomes especially evident when talking about highly skilled/educated/intelligent/creative people.
Here's what I suggest:
Stop mentoring/micromanaging/coaching them. Just give them the task and the date it's due. "Your task is to create Module X and it's due in two weeks." "Your task is to create Library Y and it's due in a month." Try that a few times and see if they are able to complete it on their own.
If Module X is mostly good but it doesn't quite talk to Module A the way it should, simply tell them "here's module A, make Module X work with it, without modifying module A." Let them run with it. Don't follow up, don't do anything until the due date arrives.
Try it for a few times. If they fail miserably the first task, give them a second and third chance.
If they fail three tasks miserably, then find another spot for them in the company where their abilities and their working style would be an asset.
Another thing to mention is that as a manager, you need to be flexible with employees. Not every employee is the same, so you shouldn't treat them the same. Some people work better/shine under Condition Y, other people work better/shine under Condition Z. Your job is to figure out which is which.
The primary function of a manager is to allocate resources - of which people are one - which means you have to figure out the best fit for each resource.
It looks like to me that you're having to undo the work of 16 years of education in the current educational system. At least in the US, many schools still operate under the "factory" model of schooling, which is learning rote facts, not thinking creatively, and having information, expectations, and assignments spoon-fed to students.
This obviously clashes with what we expect from white-collar workers, who are supposed to be creative problem solvers who can chart a course and figure out the best plans of action given pretty basic requirements. You mention they struggle to translate requirements from stakeholders into concrete results, but a large reason for that is that is backward from normal schooling. In school, they're given very clear expectations (3-page paper, 12-point font, double space on x historical event) and just have to execute. Instead, you're asking them to hear "We need an overview of x historical event" and translate those requirements into an end product (I need to write about 3 pages to cover all of the details of this event).
What this means for you, is if someone is taking 7 months and still hasn't come around, they're actively fighting 16 years' worth of schooling. The reason all juniors don't behave the same way is that some have outside experiences that have taught them these skills already like leading a club, scouting, etc. If someone like that hears "make x happen", they can think through the steps and figure out how to make it work. But if someone who doesn't have those experiences hears "make x happen" they think "but I don't even know where to start".
This disconnect between school and work is evident in their note-taking as well. In school, your time is separated between discrete classes, so all your notes on course A will be in one binder, and course B will be in another. But your junior is not separating out their work based on the subject, they're viewing all work as "work" instead of "work on x ticket".
I write all this to give background, so hopefully, you might be able to understand where you need to come from in helping them. Think about the disconnect between how they were taught to behave in school and how they're expected to behave in the workplace, and teach them about those differences. For notes, they need to separate out their topics based on JIRA tickets instead of courses. For getting started designing, they need to think about synthesizing requirements from various parties, putting together a "rubric" or what needs to get done, confirming that rubric with stakeholders, and then start work.
Adding some sources:
A recent Cengage survey (publication forthcoming) of Americans who graduated from a two-year/community or four-year college in the past five years found that nearly one in five (19%) reported that their college education experience did not provide them with the skills needed to perform their first post-degree job. Additionally, more than half (53%) of these college graduates have not applied to an entry-level job in their field because they felt unqualified, and nearly half (42%) felt unqualified because they did not have all the skills listed in the job description. https://hbr.org/2021/05/the-u-s-education-system-isnt-giving-students-what-employers-need
While 42% of employers believe newly educated workers are ready for work, 72% of educational institutions do. This is an enormous mismatch. Primary and secondary educational institutions are not keeping in touch with corporate recruiters and the needs of the business. https://www.forbes.com/sites/joshbersin/2012/12/10/growing-gap-between-what-business-needs-and-what-education-provides/
The top 5 skills employers look for include: Critical thinking and problem solving, Teamwork and collaboration, Professionalism and strong work ethic, Oral and written communications skills, Leadership https://newmanu.edu/top-5-skills-employers-look-for
^How many of these skills are students expected to demonstrate in order to graduate high school and college? How many show up on an end-of-the-year final exam?
