8

I'm the newly hired team lead for a project which is four years old. I'm two weeks into the job remotely, so I haven't had as many casual chats with new co-workers as I might have hoped, but one of them revealed some pretty problematic information.

He told me that with our 6 engineers and 2 QAs, that I can expect to need to replace one every two months. The team lead I replaced lasted just 6 months and was considered an underperformer because of the slow pace( due to never having a full set of devs according to this dev). A senior developer lasted 7 months and left three weeks ago. Nobody else has been around for more than 14 months, with an average closer to 7 and that is still with two dev jobs to fill.

One of the problems is that an astonishing amount is not known about any part of the system. The product owner asked if some feature was already built and nobody on the team knew. With the auth system, all they know is which table to put new admin accounts in and which variable to change. None of them even know the URL for it as it was built before they were there. The team doesnt seem to know much more than what is required to get through the next sprint.

There are also some frustrating attitude problems even though the devs are seemingly very good. I overheard one dev telling the QA he didn't want to know how one section worked as then he would have twice as many bugs to solve and would never get his sprint done.

Its my first time being team lead and Ive never been on a team with culture problems before so I am not sure how to proceed. There is the additional issue of my performance being graded on point velocity so new features need to be built rapidly meaning that there is not time for a reset.

Improve this question
0

4 Answers 4

Reset to default
12

Situations like these are often negative feedback loops.

  • Bad practice and (unreasonable) technical challenges lead to significant development issues and obstacles.
  • Significant development issues and obstacles lead to (good practice) developers leaving the project
  • High turnover rates means the work is mostly done by developers who are new to the codebase. Because of the development issues and obstacles, these developers make mistakes and cannot handle the already flawed codebase, leading to more issues.

Note that I'm not digging into the specific issues themselves as you didn't really elaborate on the technical side of things here - you mostly describe the social/HR challenges as opposed to technical ones. But it's my educated guess that there are significant technical challenges that are at the base of this social/HR issue.

Your question suggests that the project in question contains these issues and obstacles:

  • "an astonishing amount is not known about any part of the system"
  • "The team doesnt seem to know much more than what is required to get through the next sprint."
  • "then he would have twice as many bugs to solve and would never get his sprint done"

It seems like there is not much effort being put into the quality of life for the development cycle (and, by extension, the quality of life of the developers).

First, I want to prepare you for something that you're going to have to deal with: This is going to suck for a while. It will require effort to fix these problems and the payoff will not be immediately visible. If you/the team/the company are liable to balk when there is no immediate payout to effort put in, this issue may not get resolved.

Until it does, your team will be putting in more effort than you currently are, and if people are already at capacity, it's going to be hard to keep morale up when asking for even more effort. It can be beneficial to hire several extra consultant for the short term so your developers can keep up with both the daily workload and the improvement process at the same time.

This feedback loop can be broken, but you need to address several topics: development practices, work attitude and ethics, management and planning.

Development practices

Based on your description, there is an environment of developer fatigue and an unwillingness to deal with "even more" bugs. This goes to show that the current development life cycle is already too riddled with technical challenges, which is making your team unwilling/unable/inflexible to tackle unexpected issues that may arise. That's a really big problem.

You haven't elaborated on the technical challenges, so I can't do more than suggest to brush up on good practice and actually fix things rather than patching them. These are suggestions based on my (anecdotal) experience of what commonly leads to an undesirable codebase.

Work attitude and ethics

You're right that the conversation you overheard shows an attitude problem. However, more often than not, the attitude is a reasonable coping mechanism to deal with an unpleasant situation (see the above development practices section).

If that is the case, you should not approach this as a behavioral issue. Doing so will lead to two possible outcomes: your developers leave, or they simply do not voice their issues anymore and it'll decrease communication in the team.

Instead, you should investigate the voiced unhappiness to find the underlying problems. The unhappy developer might be able to identify or even suggest a fix to the problem that is causing them unhappiness, and it's up to the team lead (or the company) to assist their employees so they can do their work.

Should this be a case of bad developer attitude that is not grounded in development issues, then you may need to take the HR route, but only do so once you a certain that this is the case. If you guess wrong, you're going to make things worse, not better. Any misstep on your (or the company's) part is going to be seen by all employees and will have a massive impact on both employee and team morale.

Management and planning

One of the things that really stood out to me is how developers are thinking about bugs:

he would have twice as many bugs to solve and would never get his sprint done

This suggests to me that bugs are currently being considered as "extra" work on top of the planned sprint. That is a major red flag that you are overloading your sprints, which is driving your developers to fatigue and is causing them to make bad decisions along the way.

Bugs are part of development, and they should be estimated and planned as well. I'm aware that it's not always possible to reasonably estimate how long it takes to resolve a bug (could be 5 minutes, could be 5 days), but in either case time must be allocated specifically to resolve bugs.

If a developer knows that when a bug is found, it falls on them to take it on in their own time, then you're going to create an atmosphere that incentivizes developers to avoid bugs until they can't avoid them anymore. This creates a huge technical debt, which contributes to or is the predominant source of the technical challenges in the codebase.

Since you do point out a lack of bigger picture knowledge, documentation goes a long way here. Similar to bugfixing, if you want your developers to not cut corners when writing documentation, then there should be explicit time allotments for writing documentation.

To summarize

  • Developers need to be more proactive about good practice and bugfixing, but the team/company should support them in doing so.
  • The team lead should investigate common issues and experiences and actively work to alleviate them. Happy developers lead to better task handling.
  • The planning should specifically free up time for bug fixing and documentation. This can be done by adding a blanket padding to tickets to account for unforeseen circumstances; but extra time should be allotted for sizable bugs with a wide ranging impact or long expected time to resolve.
  • More generically: any behavior the company wants to incentivize should therefore be given incentives (i.e. planned time to dedicate). Don't expect your employees to pick up extra slack and take on more work without any recognition of that effort required. And no, a pat on the shoulder doesn't cut it.
  • This initiative will cost more effort without paying off in the short term, but it must be endured if the situation is to improve. Though it comes at a cost, hiring additional developers for a short term can alleviate the added pressure, especially when the current developers are already fatigued and on the edge of burning out.
  • If the company is unwilling to put take the time and effort to improve their employees' quality of life, then high turnovers are a logical consequence that cannot be avoided.
Improve this answer
7
  • You've touched on a good number of salient points here in all the right directions. I'm not sure you've hit them directly though. There are several areas where you are able to identify the symptom to hit, and the way I would recommend handling it is from a completely different leadership angle.
    – Joel Etherton
    Commented May 12, 2020 at 13:17
  • Admittedly, though, I don't want to submit a competing answer, I just want to make some changes to this (already good) answer.
    – Joel Etherton
    Commented May 12, 2020 at 13:19
  • @JoelEtherton: The thing is that it's quite hard to hit on specifics, on top of needing to gauge how to avoid pushback from people who can hold things up when they aren't confident about the changes being made (which is why I touch on the company being "unwilling"). That's so very contextual that I can't judge how to approach this unless I'd personally know all the people involved.
    – Flater
    Commented May 12, 2020 at 13:31
  • It's not really about specifics when you get down to it. Some partial thoughts: Development practices - they need to focus on what it means to be predictable and reliable. That means self examination and process review (both difficult). Attitude: Bad attitudes are a symptom of bad leadership. The code base isn't really ever the problem. It's just the thing that gets blamed. Planning for bugs: absolutely right, and go even farther. Carve out a specific amount of time just for that. A big amount. Your final statement is really good and doesn't go far enough IMO - If leadership is unwilling.
    – Joel Etherton
    Commented May 12, 2020 at 14:18
  • All that said, this is a really good answer that I upvoted.
    – Joel Etherton
    Commented May 12, 2020 at 14:23
6

How can a project with high turnover be stabilized even as staff change?

Prioritise documentation as a start, then build from that. With good documentation you can mitigate somewhat against staff turnover. Without it you're digging a bottomless hole.

Improve this answer
4
  • 1
    Just note that having access to source code is NOT documentation! It takes a HUGE amount of work to figure out what code does, and it doesn't tell you what it is SUPPOSE to do! What it is doing may not be what is suppose to happen. You need at least two sets of documentation: The specification (what is supposed to happen), and some type of analysis / automated testing results (what it is doing now).
    – Nelson
    Commented May 12, 2020 at 9:27
  • 1
    @Nelson: I agree, but the general expecation is that automated tests describe "what is supposed to happen", not "what it is doing now", since you specifically want your tests to fail when the reality ("what it is doing now") does not match with the expectation ("what is supposed to happen"). If you write your tests based on what happens, then you're writing pointless tests that confirm whatever the current behavior is. That being said, I do still agree that a spec document helps confirm that the tests are correctly translating the expectations and no mistakes were made.
    – Flater
    Commented May 12, 2020 at 11:13
  • @Flater Ah that's right. Unit tests should follow "suppose". Debugging looks at what it is doing now (incorrectly).
    – Nelson
    Commented May 12, 2020 at 12:55
  • 1
    @Nelson there is a lot more to documentation that just the code.... reference documentation on resources, urls, workflows, protocols, hierarchy, resolution and disaster management strategies and a lot more are part of it. It's a huge part of mitigating against turnover, if staff know they have somewhere to go for answers they feel more secure and confident in doing their part.
    – Kilisi
    Commented May 12, 2020 at 15:14
6

You have a retention problem that you need to fix. But what can you do about it in the meantime...

As other answers indicate, documentation can be handy. However, it sounds like your team is barely keeping its head above the water, so I'm not sure if you'll find the time.

You categorise the team as having a culture problem. I think you're jumping to conclusions.

You need to squirrel some time away and speak to every single person you manage and see what their opinion is regarding what is wrong. You need to use the fact you are new to the team to your advantage. You will get various feedback. Just the very fact you seem to care may increase employee retention.

You need to take everything you have learned, figure out what gives you the most short term gains with the smallest amount of effort to give you enough wiggle room to work on the tougher problem. You then need to figure out what you need to make that happen. You will almost certainly need help from your manager. You could look to:

  • Offload projects to other teams
  • Get help from experienced engineers/QA from outside the team
  • Hire contractors to help
  • Reprioritise work to bring benefit to the team

If you can get some improvements, you will probably improve retention. Which then will allow you to work on some tougher improvements.

Improve this answer
3

I agree with KIlisi, but would like to be more specific:

highlight knowledge transfer and move to use more written communications

Start writing as many things down as possible, including specs, How Tos and such. In stable teams there are some piece of information that are not written down, but the chance of retrieval is higher than in highly fluid team.

Another thing, as a manager, you have to prioritize written specs and as small as possible tasks. That comes from my experience working with students, you can't stress enough how smallest tasks and over-specification makes things move. If you can, mock out solutions, logic flow, designs and such.

On political side: figure out whether there is some "shielding" you need to provide for your team. Do they get too many tasks? Do they go to too many meetings? Figure out what things they like in current situation, and what they think needs improvement. Ask then, what will help them do the work

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .