Inheriting an Inexperienced Team

This post is all about the dramatic impact that low levels of experience in your software development teams have on the business, and how to fix this while still keeping delivery on track.

Imagine you’re new to an organisation or department, in a management position, and have inherited an existing team – so far so normal. You’ve seen pretty quickly that the members of that team are predominantly fresh, enthusiastic but lacking in experience, and there are a few big fires that need to be extinguished - and you also need to plan for the long term. That’s a big ask!

Generally, inexperienced but smart individuals will have focussed on the “fun” stuff and built products with the latest technologies that look good, but are loaded with naive implementation choices, a lot of bugs which some feel are almost a badge of honour, and a lack of scalability. This last one especially is a killer and because inexperienced developers don’t know what to look for, they won’t even be able to flag it to you. If you’re unlucky, the department may also have unintentionally isolated itself from the rest of the business due to their quality-last approach, and not considered aspects such as maintainability, resilience, performance, customer service, or cost.

So, what do you do?

Firstly, identify your strong and weak performers through a rapid series of 1-2-1s and cross-checks – use your apparent naivety as a newcomer to ask interview-style questions to give you a picture of their aptitude. Once you’ve identified your strong performers, check for issues with their working style and identify training or coaching needs. Stay close to them, as they’ll be unsettled by the changes going on. The weak performers need to either to be moved to a role where they can be more effective – external factors are often the cause of poor performance - or exited if there is no hope. Be fair but be firm.

Next, once you’ve teased out a specific area where change is needed, you should consider engaging an experienced consultant. Choose somebody who believes in treating the team with diplomacy – after all they worked as best they could under the circumstances and are just learning. The consultant needs to not only recommend solutions but also be responsible for kicking off the efforts to fix them. Any good consultant should want to use the existing team to perform the bulk of the work, so that they feel a sense of ownership and so you don’t silo knowledge with the consultant.

Don’t be afraid of losing people along the way who are resisting the changes despite your best coaching efforts – if you know you’ve tried your best then there’s no need to feel like you’ve failed. If a strong performer is wobbling then identify what floats their boat (not always money) and see if you can enact change in that area – but don’t over-promise or you’ll lose trust. Most of all, communicate your intentions transparently, logically, and show that you appreciate the hard work done so far, the fact that they’ve got the company to where it is today, and explain clearly to each person how they’re part of the future. Do ask them if they know what the future product vision is.

Also, it’s important to educate the team on the value of the customer experience and remind them why the company exists (to serve customers!). Use key stakeholders from other departments to help enforce this message, and find champions in your teams to reconnect their colleagues with the other departments. Sit in on meetings that you might not necessarily think of attending, to see how people interact across departments, and facilitate if necessary. Ask your developers if they can name everybody in the other teams and vice-versa - I bet they all can’t.

The conclusion of this post is that there are gems in every chaotic situation, and you can apply a methodology to work through it and keep your team’s output on track as you do so. As a new manager you have a honeymoon period to make change, so use it wisely.