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?

  • 3
    Did you discuss the matter with your team and asked them for suggestions?
    – Doc Brown
    Jan 9, 2021 at 10:53
  • 2
    No, not yet, I didn't realize the issue until recently. Part of me was happy with the situation being the "hero". Might just open the subject in next retrospective though
    – Diane M
    Jan 9, 2021 at 10:56
  • 2
    The more common term in risk management is "bus factor" (en.wikipedia.org/wiki/Bus_factor).
    – Polygnome
    Jan 9, 2021 at 15:47
  • 1
    It's too easy to mis-diagnose such knowledge transfer problems as being about information - however, most people aren't sponges and only learn what they need for the context they're working with in the present "now" moment. Even if you explain perfectly and show exactly why some information will be important, and even if they know they'll need it at a later point, they'll be lacking a 'current' situational context of having an important reason to convert that information into immediate learning and thus struggle to absorb many of the key points that you want them to know. Jan 10, 2021 at 13:17
  • 1
    So the key really is to avoid treating knowledge transfer as an activity in itself and instead make learning a part of the job of those who are unfamiliar with particular tasks, making those people responsible for those tasks, letting them make their own mistakes, and avoiding trying to be a 'teacher' (As tempting as it can be to try to hurry the process through constant intervention based on your own knowledge and experience, such intervention can easily end up hindering their learning) Jan 10, 2021 at 13:46

5 Answers 5


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.


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.

  • This is a good answer, but I would lead with the second half of your answer. The part about giving them the work and letting them handle it -- win, lose or draw -- is the good bit. Jan 10, 2021 at 0:10

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.

  • Dare to comment on downvotes? Small Readme.md file with above ides committed to version control along with rest of the code will do the job.
    – Fabio
    Jan 9, 2021 at 22:20

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.


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.

  • There are things I think don't really fit what I said or my situation in general, I don't factor and let the other clean my mess. We work usually in different part of the program, they work in the legacy which is not mine, and is mostly maintenance, and I work with the newer part which is mostly features. I don't mean they are demotivated in general, just not willing to switch to "my territory" where most of the work actually is. They are in comfort zone, and so am I. Hope this clarifies, will reword the OP slightly. Some of your suggestions apply though.
    – Diane M
    Jan 9, 2021 at 22:31
  • Also to clarify I completely trust them as developers, but the domain knowledge to absorb is steep, the code base is larger than you could expect for a 3 persons team, the test coverage is suboptimal. It's completely normal to be delayed when you're supposed to implement a new feature in a product part you barely know. Is it your advocated way for them to learn, to take time attempting a task they are unfamiliar with? (we already do peer-reviews)
    – Diane M
    Jan 9, 2021 at 22:39
  • @ArthurHv No offense, I based my observation on your quoted words. I got that you work on different parts, and that’s exactly my point: everybody works on his/her part. There seem to be no shared ownership. Furthermore, “I trust but...” does sound as a mitigated trust. Of course, nobody can absorb all knowledge. I adapted the answer accordingly.
    – Christophe
    Jan 10, 2021 at 0:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.