We’re Setting Up Developers to Fail

This is an appeal to Development Managers, Technical Team Leads, and Technical Project Managers. New developers to your team will be anxious. They will fear failure, and by doing nothing, you are realizing their fears.

It’s your responsibility to ensure that developers succeed.

As with any discussion that promotes a healthy software development culture, you must start by acknowledging and prioritizing the long-term success of your projects and your people. You must necessarily de-prioritize the short-term success of your project.

My Developer Experiences

I have been a Software Development Manager for almost six years now and I definitely don’t have it all figured out, but I have been onboarded as a developer to several teams and have been in charge of onboarding many developers to my teams.

So, I have some thoughts.

Setup for Failure

I’ve posted about this before, but working at Ericsson, my onboarding went poorly. I was working on a build and release system and could not get support from the previous owner of it, despite asking several times. I was set up to fail, and I did exactly that, eventually deploying the wrong code to production, getting me in the crosshairs of our department head.

Setup for Success

In contrast, at my first job out of school I worked at EMC and was fortunate to have a good onboarding experience as that’s when I needed it most. I remember my manager telling me how long it usually took for new developers to become productive. I remember frequently receiving guidance from senior developers and if I think back on it, my manager was directing me to those people when I needed help. These things helped. I quickly got up to speed, became productive, and I stuck around for years.

---

What went right at EMC and what went wrong at Ericsson? I would argue the difference was intentionality.

A new developer joins your team and is assigned some training and maybe some work. What happens then? If you’re lucky, that developer figures out how things work and becomes productive. Otherwise, they fail.

Don’t leave it to luck. Be intentional about their success. Have a plan. The details of the plan matter, but just having one at all matters more. You can always check in to see how it’s going and adjust if needed.

Plan For Success

I recommend these components are part of your plan when a new Software Developer is joining your team.

There’s one more item for day 1. You have to present the new developer with an onboarding document, and it must include the following:

• All access that is required for their job and steps one takes to request that access
• Where to get the code
• Which development tools are required or recommended
• This one is critical and often missed – How to locally debug all applications the developer is expected to work on

The Benefits of a Good Onboarding

You trade the short-term efficiency of your existing team members for the long-term efficiency of your whole team.

You have more interested and engaged team members which among other effects, increases retention.

You have a culture of support and team ownership.

And if you’re stuck constantly handling emergencies and generally being reactive, clearly communicating that you are going to prioritize the success of a new team member and following through on it, is a great way to get out of that cycle.

You have made the members of your team aware of your expectations and the team’s priorities. This implicitly gives the team ownership over those priorities. It means those priorities will actually be met.

I believe these steps can work for you. There are no guarantees, but you can give your new developer and your team the best odds for success.

But What if We Fail Anyways?

You cannot control everything. You were deliberate in having a plan that prioritized the success of a new developer and you followed through. You gave your best. But what if, even then, it’s not working out?

Sidebar – Defining Success

First, I’ll acknowledge that the definitions of success and failure are complex, contentious, and generally uncertain. What I do is ask myself if an individual is meeting their potential. I start there, because potential matters and I believe it’s an indicator of long-term contributions. If the answer is no, they’re not meeting their potential, I’ll then assess the individual’s ability to contribute and start noting down specifics, comparing the planned or expected work against what has been accomplished.

I won’t dwell here on measuring success. That’s for another time, but if you do find yourself making that assessment that an individual is not being successful, you have to act on that.

Consider letting the developer go. Of course, you want to consider other options, but here’s the situation:

• The developer is new to the team and their probationary period is made for this kind of measure
• It is to the detriment of your team to continue as is and while it’s not a given, there’s a good chance it’s a detriment to the new developer as well
• A plan was in place to give the individual a good chance for success

Once you’ve considered those points, if that didn’t convince you and you don’t feel ready to let the employee go, listen to that feeling. There’s probably a reason for it. Consider:

• Did your plan actually go that well? If not, try again. Set expectations and a schedule. You need to be good at effectively adding new members to your team as much as the new developer needs to be good at their job. It’s in your best interest to figure out how to get this right.
• Is it a technical hurdle that could be overcome through a training course? If so, invest in your employee. It’s good for the employee, helps with retention, and is certainly less expensive than re-hiring.
• Maybe the plan is working, but the timelines are too aggressive. Consider a revised schedule of additional help and check-ins.

Conclusion

I admit to struggling with doing this right. To some extent, I have felt my way through it and the perspective I have shared here comes from retrospect. Reflecting back on when onboarding went well and when it did not, it’s clear the failures were for a lack of trying. And it’s equally clear that the successes produce engaged, productive developers. Make this happen for the next new developer joining your team.

Plan for success. Be intentional.

---

Indellient is a Software Development Company that specializes in Data Analytics, Cloud Services, and DevOps Services.

We’re dedicated to creating a fruitful, inclusive, and memorable work environment for all of our team members. Check out open opportunities on our Careers page.

---