How to improve the "truck factor" in my development team? [closed]

Question

I'm currently a developer in a team of size 3-4 and I am concerned our team is not at all resilient to me taking days off or saying goodbye.

Two years ago when I arrived at the company I made the choice to take over and learn the work of someone departing. We had also the team downsized due to the start of an other product branch with team built from ours. That with other refactors I carried alone made me the sole expert over parts of the product that are currently undergoing most if not all current feature requests.

The team dynamics in terms of task assignation consists roughly of me developing features, someone else correcting legacy bugs, someone else refactoring legacy code. We sit on a lot of code so it's not without its value as well - but some tasks such as refactoring have been added to sprint as a courtesy, not as providing customer value. The other developers so far seem currently unwilling from learning from my expertise, although I remember being always welcoming for questions and explanations, sometimes perhaps even overwhelmingly so.

I suspect some of the reason they are not coming to me is that a vicious circle kind of started, where I'm busy working and they are afraid to interrupt me to learn from me because I'm busy, but this doesn't actually help at all.

Within the company things are going well but I'm concerned I did not manage to empower them to be more autonomous. We're currently in a state of things where 50% the tickets we have they can't handle without taking a massive delay or risking regressions or both.

I'm aware that if they don't want I may just have to be patient, but how do I prepare best their way to take over things I know, knowing there is a lot to learn, improving thus the truck factor (or bus factor)? Documentation? Pair programming? Tests? How to apply this to focus on the most efficient transfer?

Answer 1

It's funny, because I've been struggling with this exact problem for years. At first I would do big pair programming sessions and give lots of personal attention. All that did was increase my burnout. People simply were not learning, and project management still had enormous expectations of the team. I kept trying to accommodate their expectations.

I stopped coding, and started creating all manners of UML diagrams. Still, nothing got them to see what I saw.

I instituted a strict code review policy, and spent most of my days rejecting pull requests. I would spend an hour writing twice as much code in comments as I was reviewing. I linked to blog posts and articles about programming techniques and architecture. Team programming sessions where I recorded the thing for all to view later. Still, the team seemed incapable of doing work.

Don't be this person.

I thought I was teaching them to fish. All I managed to do was find elaborate ways of holding the fishing pole for them. I never let them cast their line and spend an afternoon cussing while they untangled their line from the weeds.

Then this past month, I took myself off code reviews completely. I spent more time preparing work for the team. I charged them with code reviews. I spent more time communicating the business concepts and working with them to design enhancements before starting work. Sure it meant they spent a week doing a research task that I could have gotten done in an afternoon. But I just let the sprint play out naturally, and did not criticize people.

That sprint sort of sucked. Three people -- including someone who had been programming for 25 years -- approved a pull request that prevented the project from compiling. But they learned.

The team identified some issues, and this sprint is going better. Next sprint will be better than this one.

You absolutely must let them cast their own lines. And let them cuss while they untangle their lines from the weeds.

I'm getting a more independent team by letting go.

If I were to do anything different, three to four years ago I would have pushed back against project management to go through this phase sooner.

Take a step back. Be there in an advisory role before you start fishing, but let them get their lines tangled. Let them make mistakes and learn. Be there to provide guidance after they have problems.

Answer 2

but some tasks such as refactoring have been added to sprint as a courtesy, not as providing customer value.

If refactoring improves the product, it is always a customer value as the customer gets a better product for the same amount of money, even if they cannot actually see that. And even if refactoring just improves the code, it actually does improve the product as with better code, there will be less bugs in the future, features will be easier to implement (or can be implemented at all), and implementing new features or fixing existing bugs will require less time (customers get both of them faster and have to pay less to get them).

So refactoring always has a value for customers, unless it doesn't improve anything at all, like you swap some code for other code but the new code is in no way better than the old code used to be. However, if that was the case, why are you refactoring to begin with? Usually one refactors code to achieve a goal and whatever that goal is, this is already the customer value.

We're currently in a state of things where 50% the tickets we have they can't handle without taking a massive delay or risking regressions or both.

And this sentence tells me where the problem is: You are asking how you can teach people swimming without forcing them into the water. You suggest to give them theoretical swim instruction books, make them watch how you swim, or make tests about swimming theory but you cannot learn swimming without trying to actually swim.

I faced the same problem multiple times in the past and the solution that always worked was: Let them handle any ticket that comes along.

They don't know how to do it? Doesn't matter. They should try it anyway. Maybe they find out on their own.

They don't? Then they shall come along and ask you for help. But don't fix it for them, tell them how you would have fixed it and let them do it for you. Maybe they will succeed.

If not, you will have to clean up their mess afterwards but then do it together with them so they see what they did wrong and how you would have done it better.

The first couple of weeks your team performance will be horrible (prepare the management for it) but it will improve every week and there will be more and more tickets they can handle on their own. And the more tickets they handle without your help, the more you can concentrate on other tasks and the better the overall team performance will soon get.

Answer 3

I don’t want to know everything you do.

My head is full with my own work. But if the big guy upstairs sends you to the Bahamas there are some things I’d like to know before you go.

Where does your territory begin and end? I’m not asking what you touched. Hopefully source control tells us that. Need to know what turf to carve up.

Where is a good place to start? Hopefully you commented and documented but knowing where to start can make eating the elephant easier.

Where are the pitfalls? Many coders do things that seem strange because they are deliberately avoiding doing something obvious that would actually cause a problem. If you follow such hidden rules then lay them out.

If there is a “big idea”, “guiding principle”, or even “pattern” you’ve been following spell that out somewhere.

I don’t need a dump of everything you know. Just enough to get started and enough to keep me from tearing it all down in confused frustration. Do that and I’ll wish you a fun vacation.

Answer 4

I have seen two successful ways to improve knowledge sharing in a team:

1. A strict code review policy, executed with discipline, forces other team members to review your code. They learn it. And you are forced to make it understandable.

2. The PO should define priorities, not the team. (You talk about sprints, so I assume you have a scrum setup.)

Talk to your product owner. If many feature requests are indeed in an area that only you know, then he/she should hold their ground. That should make an interesting next sprint planning meeting:

Team member: “I suggest we take this backlog item in sprint”

Product owner: “there’s other items higher on the backlog”

Team member: “those are all for Arthur. I need some work too”

PO: “those items are really what the business need most. “

Then a good self organizing team will take up the challenge and start brainstorming on how to tackle this.

Progress will be slower. But it will be an investment. That is worth it.

Answer 5

What's the core issue?

There's a nice Affrican quote:

Alone we get faster, toghether we get farther

Unfortunately, your team seems more an aggregation of people working alone on their parts than people working really together as a team. Also there seem to be no shared ownership of the code. This is not a good situation. Neither from an engineering perspective nor from a motivational one.

What can you do?

The very first thing you should do, is to discuss it with the team, in all openness and being aware yourself of your amplifying role in this unfortunate situation, considering that you concentrate most of the new features.

Then it depends on the outcome of the discussion. But you should probably increase peer-work, for example:

• There is no reason that you factor your part and someone else refactor other parts.
• Discuss the work together, including the new ticket picked instead of automatically assigning them by subject. Share work on tickets whenever possible.
• If test coverage is insufficient, after the initial group thinking, you could also split up with one preparing/adapting automated test cases and the other implementing the change. THis requires sufficient teamwork, especially if you go for a TDD or a BDD like approach.
• Organize systematic peer-review to ensure shared knowledge about the newly developped stuff, or the bugs corrected.

Is it realistic?

It will be challenging if you didn't teamwork enough. And of course, in a complex system and for a complex domain, nobody can know everything on everything. But a very realistic goal is to make sure that for every part, there are at least two persons who really master it, and make sure that both have the opportunity to actively maintain their knowledge by developing something. From an engineering point of view, this will ensure resilience in case of a "bus"-event.