As a manager, what options do I have when somebody is totally stuck?

Question

I'm managing a software development team, and I'm somewhat new in managing technical teams. I know some of the technologies we are working with very well, some quite a bit. The team is currently around 15 team members. We can't divide it into additional teams, a topic which I wouldn't like to dive into.

It happens quite a bit that a software developer tells me: "I'm stuck, I don't know how to progress" (technically, not in terms of understanding requirements, etc.).

I tell them to consult our development lead or/and some other person that I know could know the solution if documentation, Stack Exchange and googling didn't help. They came back saying: it didn't help, and I'm still stuck.

So I ask them to define the problem: what's the context and what's the problem and possible solutions. They do it, but they do it in a way that's absolutely impossible to understand without deep-diving, and the issue normally isn't clear at all.

I would love to help more, but honestly, I'm spending 7 hours a day in meetings and I absolutely don't have time to deep-dive into the context, organize several meetings with them to understand the problem and read the code.

We cover a lot of scope and the questions are normally of the type, where you need a lot of context. I would need to spend several hours to days to get the understanding of the context and the problem, and then I would be able to help. I don't have that time.

What's the way ahead here?

Answer 1

What can a developer do, when they are stuck?

• Try something
• Google it
• Ask a peer for help (this means you have to build enough structure in your head to explain it to someone else and often that already helps, in debugging also called rubber duck debugging).
• Ask a senior for help
• Ask a question on Stack Overflow
• Ask for external help, probably by asking the manager for outside contractors

What can a peer or senior do to help?

• Listen. And then suggest further actions.

However, this does not seem to work in your team. People are still stuck. And people come to you, their manager, who by definition should be their point of last hope. They should be collaborating, but they don't.

This is not a matter of team size. I have seen it work and not work in teams from 3 to 30 people.

This is your job as a manager. Not as a technical person. You have 15 technical people. You don't need a 16th person to solve technical problems. What you really need is the first 15 people being comfortable to collaborate. To ask for help and to give help. To not only look at their own task, but consider any task in their team "their task" to productively advance. By either doing it directly, or indirectly by helping someone else.

What is keeping people from collaborating and working together is giving everybody a task they have to solve alone and then holding them to their deadline. Because if they need their own thing to be done by Friday, they will be very reluctant to help anybody else. "Teamwork" becomes a distraction from their own work and something to avoid and push away. Who cares if Alice is stuck, as long as my ticket is done on Friday.

But teamwork is essential. You can do so much more if everybody cares about every ticket, and not only each for their own. So you as a manager have to set a frame where collaboration is part of the daily work schedule. Where people do not get punished for helping each other. Where when someone says "I could really use some help here" they get more offers than you can take people up on.

How to do that is up to you and your current context, but some obvious obstacles are deadlines set with no collaboration planned. And it doesn't matter if that are external deadlines ("Boss said I must be done by Monday") or estimates based on work to be done ("Alice told me she would be done by Monday"). If your developer thinks it takes three days and the deadline is in three days, then they will not collaborate with anybody. The will duck into their task and try to get it done on time.

So if whoever does the estimate think it takes three days, make it four. Or five. Because it's not just the developer alone in a dark room typing code into the machine. They have other job duties besides that ticket. Helping their colleagues, collaborating on projects, transferring knowledge. Make sure they have the capacity for that and they will.

That is your job as a manager. Enable your team to produce good work. Not through working on it yourself, but through setting a good frame for them to work as a team and solve their problems as a team. That might mean to reduce the planned workload on your team, but you will find that a team with a lighter load that actually completes all its objectives through teamwork will still be light years ahead of a team with a nominally higher work load that doesn't complete all its objectives, because people get stuck.

Answer 2

If 4 people out of a team of 15 are the ones getting stuck, you should simply get someone who is stuck to work with one of the more competent team members. I say "work with", not "ask for help".

You should ask the second team member to ensure they work with the first member until the situation is resolved.

I cannot believe for one second that you have more brainpower and knowledge than 15 other people in the team, so you should encourage them to reach out and solicit opinions and ideas from the whole team.

I completely understand what you've said about having 15 people in the team, but I think it's a distraction to focus on that. There is no reason why you can't have senior people in the team assisting the juniors. And actually no reason why you can't have juniors help seniors. The junior may know something the senior does not.

A manager does not need to be the only technical escalation point (and in many cases this would be unusual).

Answer 3

I've been in a similar position. First red flag:

The team is currently around 15 team members. We can't divide it into additional teams, a topic which I wouldn't like to dive into.

Being a leader of 5 people is very different than 15. With 3-6ish people, you can still "save" people by putting in extra hours of IC work. Sometimes on a night or a weekend. I didn't realize this at the time, but when I was leading five people I was doing this. Engineer "stuck"? No problem, I'd go help them. Oh, now I'm running a tad late on my task? No problem, I'll stay an extra hour or two after work to wrap up. Or maybe finish it on a Sunday morning.

When I got to 12, 15, and 22 people, I could no longer do this. Trust me, I tried. I came to the same conclusion you have, and everyone else who's been in your position has:

I would love to help more, but honestly, I'm spending 7h a day in meetings and I absolutely don't have time to deep-dive into the context, organize several meetings with them to understand the problem and read the code.

The teams have to be split up into smaller teams. It's your job to figure out how to structure those smaller teams, get buy-in from your boss and delegate out responsibilities instead of just tasks now. If you already have a couple of people on the team who you trust and want to take on more leadership responsibilities they can be good candidates. Don't make the same mistake I did and push people into leadership responsibilities who don't want to be or don't have the competencies to do so. It'll just cause more headaches in the future, and you may accidentally set them up for failure. Don't be afraid to ask for an open headcount for a tech leader. It's your job to manage "up" and help convince your boss to do what's best for the company just as much as it is to manage "down" to convince your team to do what's best for the company and manage "sideways" to convince other departments to do what's best for the company.

When you have 2-3 reports instead of 15, it's now up to your report to be responsible for the task to get done. If she wants to code it herself, that's fine. If she wants to use her best judgment to get a more junior person on her team to finish it, that's great too. But make it clear that if it doesn't get delivered, you're coming to her first, not the person on her team.

In your weekly 1/1's with your 2-3 reports, coach them to hold their reports responsible for not delivering. You may come to the conclusion that a team member either needs more training (if they have a great attitude but poor technical performance) or if they need to be let go and find an opportunity that better matches them (if they have a poor attitude and poor performance).

All in all, welcome to management. It's harder than it looks. The downs are bad (having to lay off multiple people, having an A player quit), but the ups are very rewarding (seeing a junior developer with a heart of gold crush their first big project on their own, having a decision you made 6 months ago finally come to light).

Don't be afraid to seek out multiple "mentors", both unpaid (e.g. peers of yours at other companies) and paid. When I was newer I went to my CEO and flat out told him I was completely lost, and he let me hire a management coach an hour a week to push through it. As long as you go to your boss with solutions, you'll be set.

Answer 4

The other three answers (at the time I'm writing this) are great, so I won't rehash what they've already covered. Instead, I'll pick up on something they have only slightly touched on.

I'm spending 7h a day in meetings...

So when are you actually doing the actionable tasks the meetings are supposed to be about? Even if you have people to delegate these tasks to, 1 hour a day isn't enough time to give them that information. It's definitely not enough time to check up on them and make sure they are doing what's expected.

If there aren't actionable items to be done from the meeting, it should probably be an email, instead.

Part of being a manager is to know when meetings aren't productive. Meetings for the sake of meetings are a waste of time and should be avoided at nearly all costs. It needs to be communicated to your superiors when these meetings should instead be an email. Your manager might not think these meetings are a problem, so come back to them with how much it is costing the company with a meeting cost calculator to show just how much those meetings really do cost. Many managers will ignore your assumptions that your participation in the meeting is extraneous, but they will often pay more attention when you can say how little financial benefit you are contributing and how much it's hurting them. This also means that you need to come up with an estimate of how much more productive you could be if you weren't in the meetings. Once you make that comparison, you should be in better position to get yourself and others out of meetings.

Also, if you can communicate to your people the actionable items from these meetings in an email or written brief, then you should be getting the information the same way. With you not having the time to tell your subordinates what you learned in the meeting, you getting that extra information in the meeting is useless, to be blunt. It just doesn't do anyone any good, unfortunately.

Another part of being a manager is being available to manage your people. This includes more than just delegating tasks. Being a manager includes managing how your team works with each other, including when they need to work together, avoid conflicts, and avoid too many water-cooler discussions, among many other people related tasks.

I'm not saying you are doing a bad job or that you need to micromanage people, I'm saying that you need to take a different track to become better and more available to do managerial tasks that benefit your team and the company. Hopefully this will reduce your stress levels, too.

As I mentioned as a comment on another answer, peer/pair programming is designed for problems that need a deep dive into tough problems. When a simple standup conversation at a desk isn't enough, you need to get devs to sit down and work on the problem together. This might just be the stuck dev and 1 other person working at a desk or it might be a group of devs going to a conference room. This avoids people repetitively coming to you when they don't understand a suggested solution. Giving your team lead the authority to set these up will also save you time.

I know you said you didn't want to talk about splitting you team, but I have a brief comment about that.

Since you don't have time to do them yourself, who are you delegating your managerial action items to? Is it one person or several people? If it's multiple people, you already have multiple teams, you just don't realize it. Making that slightly more formal shouldn't take much time and should funnel concerns up to you more efficiently and effectively, leaving you with more time and energy to deal with those issues.

Answer 5

As a developer, I would expect this to escalate first into involving more of the team. If a few devs can't solve it, it would further escalate to a full-team discussion or meeting and having all resources fully dedicated to trying to solve the problem.

"consult our dev lead or/and some other person" is a good start, but obviously, if 2 people can't figure it out, you're going to have to have more of them work on it. I'm a bit confused that asking more people for help wasn't their default. This smells like a lack of collaboration and trust among team members. I shouldn't think they'd be going their manager about it without already having consulted with all their teammates, unless there's a standing order not to assist your teammates, or they're too busy on higher-priority tasks, in which case the business has already decided upon the priority and thus has already agreed that this problem should wait until the higher-priority tasks have been completed.

Eventually, the team will solve it, decide on a workaround, present options to the product owner (who may also be you), or tell the product owner that they simply can't deliver on the request.

I've never been entirely unable to deliver, but we came close, once, on a 2-person team. I expected that the business would then pull in some people from another part of the company to look at the problem, although as you already have 15, that's unlikely to help. The final escalation, if the business is unwilling to back down on the requirement, is that it must hire contractors with greater expertise than the in-house developers. If all 15 have signed off on saying that they are simply incapable of implementing the request, then logically you must look elsewhere.

If it happens frequently for 2 or 3 of the 15, on tasks that the other developers don't have trouble solving, I'd start to question the value of keeping them around (unless they're inexperienced at development or new to the team and still adjusting). Ideally, you wouldn't hear from them every time they have to consult with teammates, because they'd be doing it automatically. But you might learn from their teammates that it's happening with undue frequency in your one-on-one meetings.

Answer 6

In a comment, you say

in the current example the dev lead seemed to have proposed a solution but the dev still can't make it work. I'm chatting with the dev on a communicator trying to understand why he can't make it work but that's virtually impossible. He wants a call with me to explain, otherwise he can't explain. So I will spend an hour trying to understand the context why he can't make it work again.

As a manager, you are supposed to manage resources. You are not a backup dev lead. So what you should do when you get feedback like this, is talk to the dev lead (a human resource that you are managing). The dev lead should be the one helping the dev. The dev should be spending that hour giving the dev lead that context, not you. That's why the position of dev lead exists.

If you are going to have a phone call/meeting to discuss this with the dev, it should also include the dev lead. But it doesn't sound like you're to that point, because that's something you'd do not at the instigation of the dev but of the dev lead. You would do it not to mentor the dev (not your job, at least on technical issues) but to mentor the dev lead.

When you get promoted, it tends to be because you were good at the previous job. So if you were a dev who was promoted to dev lead as a good dev and then promoted to manager as a good dev lead, then it makes sense that you would be a better dev than the dev and a better dev lead than the lead. But you shouldn't be practicing as a dev or lead at this point. You should be helping the lead learn how to mentor. And the lead should be helping the dev.

What I have seen happen, and I suspect it is happening here, is that the dev is finding you a softer touch than the dev lead. I.e. you give more help. So the dev would rather talk to you than the dev lead. Unfortunately, I don't have better advice than to stop doing that. When the devs are asking you for help, you need to push them back towards the dev lead. And then follow up with the dev lead to make sure that the lead is helping the dev (so a five to ten minute phone call with the lead instead of an hour phone call with the dev).

It's possible that the dev lead is feeling too busy to help the devs. If that's the problem, then you need to set priorities (a management responsibility). A dev lead should be spending at least 20% of the time leading. If the lead is instead doing a developer's job, then you need to refocus the lead on helping the other developers. If this leaves you short on developers, then you need to hire. Or set more appropriate expectations about what work your team can do.

Others have noted that pair programming is another alternative. That's certainly true. But I don't know that it helps you now, as you've already started down the dev lead path on this problem. At this point, it's the dev lead who should potentially be pairing with the dev so as to implement the existing proposed solution. For future problems, you might encourage developers to pair with other developers before escalating to the dev lead (or suggest to the dev lead to encourage pairing). And again, discourage developers from escalating technical problems to you. Help them by encouraging the dev lead to take the time to mentor, not by substituting for the dev lead. Or by assigning another developer to help.

Anyway, my point is that you should immediately go talk to the dev lead to find out what the lead sees as the issue. Is it that the lead doesn't have time to work with the dev? (Free up the lead's schedule.) That the dev is too stupid to understand? (This is when you might meet with both and take the hour to get the full context, to find out if the dev is a bad student or the lead is a bad teacher.) That the dev hasn't asked for more help? (The lead should follow up with the dev.)

In fact, IMO, you should have already done this. That that wasn't your first reaction to the situation is a big part of why you are struggling. Because you are trying to act as a dev lead rather than as a manager. And you're right, you don't have time to be a dev lead if you are the manager. As a manager, you mentor the dev lead. Delegate (technical) mentoring of the developers to the lead. You set priorities, allocate resources, arrange help with impediments, and interface with other managers.

It's your responsibility to see that the dev gets mentored. It's not your responsibility to do the actual mentoring. Delegate that. As a manager, delegation is your job.

Answer 7

It sounds as if you have the expertise in the team to solve the problems but the individuals you've tasked with solving the a particular problem are not getting access to that expertise. As nvoigt points out, better collaboration within the team can fix this.

Here are two things that I do to encourage collaboration within a team:

1. When a team member Alice asks team member Bob for help, Bob should in most circumstances happily drop whatever he's doing and give Alice as much help as she needs, right up to pair-programming the entire story together.¹ There will be situations where Bob is needed for something critical and can't do this, but you as a manager should be making these situations rare as possible. Part of what helps to make these rare is to spread expertise from more-expert team members to others, which this kind of helping directly does.

2. The responsibility for not completing a story by the estimated time (ideally, estimated by the team itself) is not on an individual but is collectively with the entire team. If the team has the capability within it to complete all your stories you don't want a story to fail because the capabilities of only part of the team were being used. It's also good in general to have a no-blame culture; this helps avoid people hiding problems and errors; hiding them makes it more difficult to analyse what went wrong and thus more difficult to improve things so that they can be avoided.

I would also suggest that you let team members pick their own stories, rather than assigning them, if you're not already doing that. Beyond that, encourage team members occasionally to pick stories where they're not so familiar with the technology or that part of the system so that they can learn about it. They should be comfortable doing this if they know that they can get as much help as they need with the story (see point 1 above).

In a truly agile environment the team member that "owns" a story in a particular iteration is not necessarily the person best equipped to do the work on it, nor at times even the one who does the majority of the technical work on the story. Owning a story simply means that you're responsible for tracking its progress during the iteration and co-ordinating the resources from the team that are needed to get it done. This is essentially devolving some of the project management from the project manager to the team itself. Given that you're a very busy manager right now, this could probably help you out significantly.

A Note on Team Size

The original question implies that it might be better to split the development team into two or more smaller teams and several answers directly suggest this. From experience, I strongly disagree. (I recently spent more than two years in a team of more than 15 developers.)

Fifteen members is a largish development team, but is certainly small enough that everybody should know each other and have a general understanding of everybody else's expertise and in what areas of the code they generally do their work.² As you reach a dozen or more you have to take some care with all-team meetings such as daily stand-up meetings, but aside from that there should be nothing awkward as long as management is encouraging intra-team communication, rather than having all communication go through the manager(s).

As with my comments on "Agile" above, this too speaks to management style. Push as much of the management as you reasonably can allow down in to the team itself and the team will be able to take care of itself. (Teams with little experience in this may need some coaching, but any team with at least a handful of experienced developers who have a reasonable understanding of the business should have no problems.)

And in cases where someone is having difficulty and needs help, having a larger pool of teammates from whom to request help both gives a larger pool of expertise on which to draw and reduces the individual load on any one member created by those who need a lot of help getting up to speed.

---

^{¹ A typical fear of implementing point 1 is that there will be "free riders" on the team who are constantly demanding help from others and using so much help to get their stories done that they are not actually themselves contributing to the team. This is not something to worry about: it is pretty easily identified, is pretty much the same problem as someone who isn't doing their job in other subtle ways in a non-agile environment (e.g. writing code that looks like it works but isn't thoroughly tested), and is dealt with using the same management techniques whether you're in an agile or non-agile environment.}

^{² It's certainly been shown in other areas that fifteen to twenty members is a very practical team size. Rugby teams have fifteen players per side actively playing at once, and even on teams with fewer people on the pitch at one time, such as soccer (eleven) or baseball (nine), the total team size that plays in any one game is well over that number.}

Answer 8

If it was always the same dev, training or termination and replacement (they might not be for for the job, it happens).

Since you say it is a group of them, group sessions can be very productive. Have a regular meeting where stuck people explain where they are stuck, what research they have come up with so far, and people share ideas. No need to mobilize your 15 members, a rotation to have 5 or so attendants is fine. Stuck people get to show their work, it's less intimidating to ask in a regular meeting than personally bother a senior, while breaking the ice, paving the way for direct help solicitation in the future. 5 heads are also better than 1.

If those meetings dont come up with a solution, you have a lack of necessary technical skills in your team, which is important information you should be glad came up to you. Time to escalate to another, more specialized team or bring in consultants, or plan for training if you have time. Your team as a group does not have th skill, so it's pointless to hope it will appear out of nowhere.

Answer 9

I think it's telling that this happens frequently, and that it's always the same couple of people. Before you try to tackle the current issue, take some time to think through all the times this has happened in the past. Make a list of what the task was, was the blocking issue was, and how it was ultimately solved. Essentially, treat the problem like a bug in the team structure and root-cause it until you can determine what allowed the problem to exist in the first place. I have a suspicion that you'll find there's a single underlying cause that's behind all of these problems, and that is ultimately what you need to address.

I had similar problems on a team once. We tried various things but nothing really worked. After doing a five whys deep dive into past problems, we started seeing patterns below the surface. The problems all involved tasks that tangentially involved a certain subsystem, and the resolution always involved active intervention from one of our two longest-serving team members. It turned out that performance-critical subsystem had been hand-optimized over the years (thus very hard to read) and interacted closely with hardware (thus the source code alone wasn't enough to understand what was happening). These two senior devs understood that code because they learned it when it was simpler and more readable and are generally the ones optimizing it. It's rather intractable to new people and if you ask the seniors to explain it, they'll generally just do the task themselves because it's far faster than trying to bring someone up to speed and their schedule was already swamped. Armed with that understanding, we knew the only way to resolve the problems would be to reserve time in the schedule for those experienced devs to fully document the subsystem in detail and formally train the rest of the team. We also learned that training and knowledge sharing needs to be built into the schedule for every sprint/project, and that we needed to take a more active role in managing our bus factor.

That may not be the specific problem that you have, but it's the process that's important. Dig beyond the visible problem and find the underlying deficiency that enabled the problem. Fixing that deficiency should go a long way to ensuring these sorts of problems stop recurring.