When a new engineer is not working out: the 30-day decision

Most problems with a new engineering engagement become visible within the first 30 days. You can often spot them by looking at how long small tasks take, how often the engineer needs help, and whether their reported progress matches what actually gets merged. Identifying these signals early gives you time to address the problem before it becomes more costly.

By day 14, put the concern in writing and clearly identify what is not working. By day 21, make sure you have addressed any issues on your own side, such as unclear requirements or poor communication. By day 30, decide whether the engagement is working. Leaving the situation unresolved can cost more than making a clear decision.

Key facts

In this article

• The three signals that an engineer is not working out
• Whether it is the engineer, or the brief
• What the data says about how long a turnaround takes
• What to do in the first 30 days
• How to have the conversation
• When to end it, and how
• Where RocketDevs fits
• Conclusion
• Frequently asked questions

What are the three signals that an engineer is not working out?

Three signals can indicate that a new engineer is struggling:

• Slow cycle times on small tasks
• Very few questions
• A growing gap between reported progress and merged work

These signals can be tracked through your repository and team communication. The goal is to look at measurable patterns rather than relying on a general impression that something is wrong.

This is especially important for remote teams. In the 2025 Stack Overflow Developer Survey, 32.4% of 33,686 respondents said they worked fully remotely, compared with 17.9% who worked fully in person. On a remote team, you cannot always see when someone is struggling. Instead, the signs often appear in the work itself and in how the engineer communicates.

These thresholds are decision rules rather than established benchmarks. There is no published standard that defines exactly how many days, questions, or merged changes should indicate a problem on a small remote team.

The gap between reported and merged work can be particularly easy to miss. Daily standups are useful for understanding what someone is working on, but reported effort does not always translate into completed work. The repository provides a more concrete record. If an engineer repeatedly reports that work is nearly complete but little or nothing is being merged, it is worth discussing what is blocking progress.

Question rate needs to be considered carefully too. Asking very few questions during the first weeks is not necessarily a sign of confidence. A new engineer may instead be making assumptions about requirements and implementing the wrong solution. Research into newcomers contributing to open-source projects has identified numerous barriers to making a first contribution, including social barriers that can make it harder to ask for help.

The responsibility is not entirely on the new engineer. Clear requirements, accessible teammates, and an environment where questions are welcomed can make it easier for someone to identify problems before they turn into failed work.

Is it the engineer, or is it the brief?

Think of it like a driving test. If someone is driving badly, you wouldn't immediately conclude that they're a terrible driver. You'd first check if the brakes are working. The same principle applies here. The company needs to check:

• Did we give the developer clear instructions?
• Can they actually get the software running?
• Can they get answers when they're stuck?
• Do they know who to ask for help?
• Did we explain what "done" means?

If the answer is no, the company must fix those things first.

Test the brief before deciding that the engineer is the problem. Research consistently shows that unclear requirements, changing goals, and communication problems are common sources of difficulty in software projects.

The Naming the Pain in Requirements Engineering survey looked at 228 companies across 10 countries. Incomplete or hidden requirements were the most frequently reported problem, identified by 48% of companies. Communication problems between the project team and customer were reported by 41%. Among small agile companies, incomplete or hidden requirements were ranked as the top problem by 60% of respondents, per the full text.

This is not a new finding. Earlier research has also found that many requirements problems are organisational rather than technical. Other studies have identified unclear or changing requirements, limited knowledge of the application domain, and communication problems as major factors affecting software productivity and quality.

This matters when onboarding a new engineer because they have less knowledge of your company, systems, customers, and processes than the people already inside the organisation. If important information only exists in someone's head, the new engineer is working with a disadvantage from the start.

When work is moving slowly, test both sides before deciding where the problem lies.

Research on onboarding also points to the importance of support. A study of 102 software professionals found that support for new hires played an important role in onboarding success, while formal training was less important. Another study of 267 developers who joined Microsoft software teams remotely found that building a strong social connection with the team was one of the biggest challenges for new hires.

Both factors are partly within the operator's control. If a new engineer cannot get answers, does not know who to approach, or has little opportunity to connect with the team, their performance is being affected by the onboarding environment.

Remote work itself should not automatically be treated as the cause. Research involving thousands of software developers found that remote work can create very different experiences depending on the circumstances. The important question is not simply whether the engineer is remote. It is whether the systems, communication, support, and expectations around remote work are working effectively.

Before deciding that an engineer is failing, check the conditions they were given to succeed.

What does the data say about how long a struggling engineer takes to turn around?

There is no published study that establishes how long a struggling engineer should take to improve. That means the 30-day time frame used in this article is a practical decision rule and not a research-backed benchmark.

Research can tell us more about what helps new engineers succeed and how to measure whether delivery is improving. The onboarding literature consistently points to factors such as clear roles, support from colleagues, and a sense of connection with the team.

A large meta-analysis covering 70 samples of new employees found that role clarity, confidence in their ability to perform the job, and social acceptance were important parts of successful onboarding. In practical terms, role clarity starts with a clear brief. Social acceptance comes from helping the new engineer become part of the team. Confidence can grow when they successfully complete and merge their first pieces of work.

Support from colleagues is particularly important. Research involving 102 software professionals found a stronger relationship between support and onboarding success than between training and onboarding success. The researchers also highlighted the importance of giving new employees a safe environment where they can ask questions and seek help.

This makes support an ongoing responsibility rather than something that happens only during the first few days. A new engineer needs someone they can approach when they are unsure about a requirement, stuck on the codebase, or trying to understand an unfamiliar process.

To measure whether delivery is improving, DORA's delivery metrics provide a useful framework. Change lead time measures how long it takes for a change to move from being committed to version control to being deployed in production. Change failure rate measures the proportion of deployments that require immediate intervention.

These are team-level metrics and should generally remain that way. For onboarding, however, the same principle can be applied privately to smaller tasks. Track how long an engineer's work takes to move from starting to being merged. If that cycle time begins to improve between day 14 and day 30, it provides evidence that the intervention is working.

The wider DORA research also shows why the environment around an engineer matters. Research covering more than 36,000 professionals found that high-quality documentation was associated with higher team performance. The research also linked generative team cultures with stronger organisational performance.

This matters when evaluating a new engineer. Someone working in an undocumented codebase, with unclear requirements and limited opportunities to ask questions, is not operating under the same conditions as someone with clear documentation and accessible support.

The data cannot tell you exactly what a struggling engineer's recovery curve should look like. There is no established 30-day benchmark for small remote engineering teams. The most defensible approach is therefore to treat 30 days as a decision rule that you set in advance, rather than presenting it as a research finding.

What should you do in the first 30 days?

Start recording concerns by day 7, discuss them with the engineer by day 14, fix any problems on your side by day 21, and make a decision by day 30. The purpose of this schedule is to make the decision based on evidence rather than frustration.

Start counting early. Day 7 is not when you raise the issue with the engineer. It is when you begin collecting evidence so that the day 14 conversation can focus on specific examples rather than a general feeling that things are not working.

When giving feedback, focus on the work rather than making it about the person. Specific tasks make it easier to explain what was expected, what actually happened, and what needs to change. They also give the engineer something concrete to respond to and improve.

Day 14 is also the point to assign a named person who can answer questions. A document or onboarding guide is useful, but it does not replace having someone available when the engineer gets stuck. Research on onboarding consistently points to support from colleagues as an important factor in helping new employees adjust.

By day 21, fix the conditions that could be contributing to the problem. Make sure tasks are properly documented. Check that the engineer can run the project locally. Ensure they have someone they can contact during their working hours.

The final test should be fair. Between days 21 and 30, give the engineer two clearly defined tasks that are similar in size to the work that previously slipped. Give them a clear brief, a functioning development environment, and access to support. Then measure what happens.

If cycle time improves and the work is being merged, you have evidence that the situation is improving. If delivery remains unchanged after the brief, environment, and support have been addressed, you have stronger evidence that the problem lies with the engineer's execution rather than the conditions around them.

How do you have the conversation?

Have the conversation directly, preferably on a call, and use two specific examples. Ask what happened rather than starting with a conclusion. The day 14 conversation is about understanding what is getting in the way. The day 30 conversation is about communicating the decision.

For the day 14 conversation, start with what you observed rather than your interpretation of it. For example:

“I want to talk about the last two weeks. The export task took four days and the API change is still open. I would have expected both to be done in a day or two each. That might be the tasks, it might be how we briefed them, or it might be something else. What got in the way?”

Then give the engineer space to answer. The problem may be an unclear brief, an issue with the working environment, or a problem they were stuck on but did not communicate. Each of these can potentially be addressed.

Pay attention if the engineer does not recognise any gap between the expected and actual delivery. If they believe the work took an appropriate amount of time and cannot identify anything that caused the delay, you may need a more direct conversation about expectations and performance.

End the conversation with a clear plan and a date. For example:

“Here is what I am going to fix on my side by Friday: written tasks and Sam as your first call for questions. Then we will give you two tasks of this size and look at the numbers together on the 30th.”

Follow up the next day rather than waiting for the next formal review. A short check-in can establish whether the engineer understood the feedback and has started acting on it. Their response can also show whether the expectations from the conversation were clear.

The day 30 conversation should be shorter. At this point, you have already discussed the problem, fixed the conditions on your side, and measured the results. If the numbers have improved, explain the plan for the next month. If they have not improved despite clear tasks, a workable environment, and accessible support, explain that the engagement will end and outline the handover process.

The key is to keep both conversations focused on observable work. Avoid turning the discussion into a judgement about the engineer as a person. The aim is to establish what happened, what needs to change, and whether the change actually happened.

Managers often look for formal processes when what they need first is a clear conversation. Performance improvement plans have their place in some organisations, but a small team does not necessarily need to begin with a complex process. A direct discussion with specific examples, clear expectations, and a defined follow-up date can provide a much clearer starting point.

When should you end it, and how?

End the engagement at day 30 if the three signals have not improved after you have fixed the brief, the working environment, and the support available to the engineer. Once you make the decision, set the end date within the same week. Continuing to wait adds cost without addressing the underlying problem.

The US Bureau of Labor Statistics reported a mean hourly wage of $71.20 for software developers in May 2025. At 40 hours per week, that works out to about $2,848 in wages for one week. This does not include the additional time a senior engineer may spend reviewing, correcting, or redoing the work. Contractor rates vary, but the cost of continuing an engagement that is not delivering can quickly become significant.

Ending the engagement should be a clear process rather than a dramatic event. Much of it involves access, communication, and handover tasks that a small engineering team should have documented anyway.

There is also a possibility that the process produces a different conclusion. The numbers may show that the engineer is capable and that the real problem was the brief or onboarding environment. Research involving 102 software professionals found a strong relationship between support and onboarding success. Other onboarding research has also identified role clarity as an important part of successful adjustment.

An engineer who struggled because they lacked clear requirements or access to support may perform very differently once those problems are fixed. That is why the 30-day process should test the conditions around the engineer before making a final decision.

The goal is not to end an engagement quickly. It is to identify the problem early, give the engineer a fair opportunity to improve, and make a clear decision when the evidence is available.

Where RocketDevs fits

A client who lets a struggling engagement continue for three months without raising the problem usually does not renew. That silence is not only the client's responsibility. If we do not help identify and address the problem early, it is our failure too.

At RocketDevs, every engineer on the bench has completed 6–8 hours per developer of structured assessment, and we accept only the top 2% of applicants. So when a placement is not working, the first question is rarely whether the engineer can code. It is more often whether they have a clear brief, a working environment, and enough access to support.

That is why the first two weeks of an engagement matter. They give the client and engineer time to establish how the work is going before a small problem becomes a failed engagement. If you see the warning signs by day 14, raise them with the account team. We can help you work through the same process outlined in this article, including checking the brief, the working environment, and the support available to the engineer.

If the numbers have not improved by day 30 after those factors have been addressed, we can help arrange a replacement through the account team. During the 14-day risk-free trial, this can be handled without requiring the client to start the search process again.

The honest version is that some placements do not work out. No assessment process can remove that possibility entirely. What matters is how quickly the problem is identified and addressed. Raising the issue in week two gives everyone an opportunity to fix it. Waiting until month four usually means the client, the engineer, and the team have already spent far more time on an engagement that was not working.

Related reading: what a bad engineering hire costs a seed-stage startup, why your remote team is not slower, your questions are, how to evaluate a developer when you cannot read the code, and when a startup should hire its first engineering manager.

Conclusion

A struggling engineering engagement rarely becomes easier by waiting. The longer a problem goes unnamed, the more difficult it becomes to separate the original cause from the consequences. By the time a client decides something is wrong, weeks of slow delivery may already have accumulated.

The first 30 days give you a practical window to find out what is actually happening. Start by tracking cycle time on small tasks, how often the engineer asks questions, and whether reported progress matches merged work. Then look at the conditions around the engineer. Make sure the brief is clear. Check that the development environment works. Give the engineer someone they can ask for help.

By day 14, the problem should be a conversation rather than a suspicion. By day 21, you should have fixed the things on your side that could be contributing to it. By day 30, you should have enough evidence to decide whether delivery is improving.

Sometimes the answer will be that the engineer was struggling because they were not given what they needed to succeed. Sometimes the conditions will be right and the numbers still will not move. Both outcomes are useful because both give you clarity.

The real mistake is not a placement that fails. The real mistake is allowing a failing placement to continue without testing why it is failing. A clear 30-day process gives the engineer a fair chance, gives the client evidence, and gives everyone a defined point at which to make a decision.

If the engagement is working, you have a stronger foundation for the months ahead. If it is not, you can act before the cost of waiting becomes much larger than the cost of changing course.

Frequently asked questions

How long should you give a new developer before deciding?

Thirty days is a practical rule for a small remote team, provided you identify the concern by day 14 and complete your own fixes by day 21. There is no published research that establishes a specific recovery period for one struggling engineer, so treat 30 days as a decision rule rather than a proven benchmark. Use that time to provide clear requirements, access to support, and a fair opportunity to improve.

Is it normal for a new engineer to be slow in the first month?

Yes. A new engineer may need time to learn an unfamiliar codebase, team, and processes. Slow delivery becomes a concern when small tasks consistently take much longer than expected, the engineer is not asking questions when they are stuck, or reported progress does not match what is actually being merged.

A new engineer who asks questions, responds to feedback, and steadily delivers smaller pieces of work may simply be going through the normal onboarding process. Before treating slow delivery as a performance problem, check whether unclear requirements or a difficult working environment are contributing to the delay.

How do you tell a contractor it is not working out?

Have the conversation on a call and use two specific tasks as examples. Explain what was expected, what happened, and what you changed on your side to remove potential obstacles. Give the contractor an opportunity to explain what got in the way, then confirm the decision and next steps in writing.

If you are ending the engagement, set the end date promptly and begin the handover immediately. Make sure open work, relevant credentials, documentation, and other necessary information are transferred. Revoke access on the agreed end date.

Can you replace a developer during a trial period?

With RocketDevs, yes. If a concern is raised during the 14-day risk-free trial, the account team can arrange a replacement from the vetted developer bench rather than requiring the client to restart the search.

Concerns raised earlier are generally easier to address because there is less time to unwind and less work to hand over. If a problem appears later in the engagement, the account team can also help manage the replacement process.

What if the engineer improves by day 30?

If the numbers are moving in the right direction, there is no reason to end the engagement simply because the first few weeks were difficult. Continue with a clear plan for the next month and keep tracking the same measures.

The purpose of the 30-day process is not to find a reason to replace an engineer. It is to establish whether the problems identified during onboarding are being resolved and whether delivery is becoming more consistent. Improvement is the outcome you want to see.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• Rodeghero, Zimmermann, Houck and Ford, Please Turn Your Cameras On: Remote Onboarding of Software Developers During a Pandemic, ICSE-SEIP 2021
• Sharma and Stol, Exploring onboarding success, organizational fit, and turnover intention of software professionals, Journal of Systems and Software, 2020
• Sharma and Stol, camera-ready PDF
• Mendez Fernandez et al., Naming the Pain in Requirements Engineering, arXiv 1611.10288
• Mendez Fernandez et al., Naming the Pain in Requirements Engineering, full text
• Mendez Fernandez et al., Naming the pain in requirements engineering, Empirical Software Engineering, 2017
• Hall, Beecham and Rainer, Requirements problems in twelve software companies: an empirical analysis, IEE Proceedings Software, 2002
• Curtis, Krasner and Iscoe, A field study of the software design process for large systems, Communications of the ACM, 1988
• Bauer, Bodner, Erdogan, Truxillo and Tucker, Newcomer adjustment during organizational socialization: a meta-analytic review, Journal of Applied Psychology, 2007
• Ford, Storey, Zimmermann, Bird et al., A Tale of Two Cities: Software Developers Working from Home during the COVID-19 Pandemic, ACM TOSEM, 2021
• Steinmacher, Conte, Gerosa and Redmiles, Social Barriers Faced by Newcomers Placing Their First Contribution in Open Source Software Projects, CSCW 2015
• DORA, Guide to DORA metrics: the four keys
• Google Cloud, Announcing the 2023 State of DevOps Report
• US Bureau of Labor Statistics, software developers, hourly mean wage
• Stack Overflow, 2025 Developer Survey, Work
• Luca Dellanna, How to Handle Poor Performers
• Hacker News via Algolia, item 18834492
• Stack Exchange API, management tag, Workplace
• Wikimedia pageviews, Performance improvement plan