We have a release cycle about three to four weeks for a new release then a bug fix sprint to make the product stable, then new features sprint to kick off another round of release cycle.

What should I, as their developer manager, do during the bug fix sprint when my team members are busy in fixing bugs ?

I have tried several things but I am not sure which one(s) is the best.

  1. Joining bug fix with my team, but mainly pick the toughest ones.
  2. Mostly doing code reviews and only do bug fix when necessary, e.g. bugs with the same (or similar) root cause keeps surfacing so I decide maybe I should step in.
  3. Not fixing bug directly but focus on analyzing and summarizing bugs and their causes
  4. Investigate new technology/methodology, see if we can introduce them in the next release cycle.
  5. Combining

Note: although I use the term "sprint" I hope that won't sidetrack my question to another discussion about scrum/agile (we have many questions about them already). The way we do scrum/agile is small release and continuous improvement (new feature and bug fix both as improvement)

About my duties as their dev manager, in a nutshell, they report to me and I am responsible for our deliveries as if anything (seriously) wrong with our product I am the first to be called.

I am not in anyway suggesting I am not clear about my job responsibilities as one comment suggested. As a small company we can't afford to have two totally separated roles , people manager and tech architect. From what I know it is not that uncommon.

  • Can you outline what your duties as a developer manager are? You call yourself a developer manager, but the work options you mention in the question are not things I would associate with a manager. Jan 30 at 7:50
  • In a nutshell, they report to me and I am responsible for our deliveries (mainly in codes we write) Jan 30 at 7:53
  • I think this will be entirely up to you and your team. Note that the names for roles and duties also vary widely. It is somewhat common to split technology oriented roles, like 'lead programmer' or 'architect', from management oriented roles that focus more on business decisions and administration. In any case, it will be very difficult for anyone else to tell you what the best option is for your specific situation.
    – JonasH
    Jan 30 at 8:33
  • @JonasH I agree but on the other hand I don't believe I will be the only one who face this situation. Jan 30 at 8:50
  • 1
    If you are not clear on your job responsibilities you should ask your boss. As a developer myself, I would hope you would avoid programming and instead focus on managing things, such as clearing roadblocks, identifying risks and heading them off, and getting us the resources we need.
    – John Wu
    Jan 30 at 10:26

4 Answers 4


What the developers are doing has little impact on what you, as a manager and a leader, should be doing. It doesn't matter if the developers are fixing bugs, building new features, or something else. Although they are originally geared for manufacturing and formed the basis for lean, they are generally consistent with Lean Software Development and Agile Software Development, so I would turn to W. Edwards Deming's 14 principles for suggestions on a manager's responsibility in an organization:

  • Create a safe environment. Google's Project Aristotle reaffirmed this need. One of the most important factors for a successful team is the ability to take risks and fail without reprisal. A team needs to be able to, within reason, make mistakes and learn from them.
  • Create an environment where quality is built into the product. Make sure that quality is owned by all members of the team and they have the time and knowledge to avoid reckless technical debt.
  • When you do identify low quality work, whether that's defects or technical debt, advocate for making it a priority to resolve. If you control the work prioritization and order, prioritize it. If a product manager or someone else is ultimately responsible for ordering the work, make sure they understand the impact of low quality on the teams responsible for building and maintaining the product.
  • Tear down silos that exist between parts of the organization. If the developers have trouble talking to support, sales, marketing, legal, or any other department that they need to finish work, figure out how to develop a collaborative relationship between your developers and the people with knowledge and insight that can help them make better decisions and build a better product.
  • Make sure that the team has time and space for retrospectives. When the team identifies changes, help the team enact those changes. I'd recommend Esther Derby and Diana Larsen's Agile Retrospectives: Making Good Teams Great (and a second edition is coming out in March 2024). This is the only practice explicitly called out in the Manifesto for Agile Software Development and can be a useful source of feedback for management. However, teams need to see the value of performing a retrospective, so it's crucial to show progress being made to resolve problems brought up by the team.
  • Observe the work yourself. Or manage by walking around. The team may not be aware of the existence of better practices or practices that they are using that are less than optimal. You may not be involved in the day-to-day work, but you should be aware of it and ready to offer your knowledge, experience, and assistance.
  • Make training available to your employees. If you don't have a training budget, try to get one. Even if you don't have a training budget now, set aside time for skills development. If people on the team want to take relevant courses or training, try to support them with time off during the workday. Work with the team to build this into their scheduling and planning activities and see the importance of learning and self-improvement.

With the exception of helping directly with bug fixes and picking the toughest one, it seems like you are doing a lot of the right stuff. If you do help with bug fixes, I'd encourage the opposite approach: take the boring, menial work that may not be on the critical path or necessary for success and let the team focus on the challenging technical work or the work that cannot slip. When managers take on work in the critical path, they are in a position where they may need to neglect their managerial duties at the detriment of the team.

  • Those are good advices in general. In my specific question, I need some advice for the bug fix sprint, e.g. you said "take the boring, menial work that may not be on the critical path". Jan 31 at 2:03
  • @Qiulang邱朗 See my very first sentence: What the developers are doing has little impact on what you, as a manager and a leader, should be doing. Just because the developers are focusing on bugs at the moment should not inherently change what you are doing. Although, perhaps looking at ways to build quality in and avoid those bugs in the first place would be good. Maybe you wouldn't need to invest a big chunk of time in fixing bugs if you focused on preventing them in the first place.
    – Thomas Owens
    Jan 31 at 3:39
  • For people manager this is true, for tech lead it really depends. Jan 31 at 10:36
  • @Qiulang邱朗 If you believe that to be true, why bother asking the question? You may believe that to be true, but I don't. It also seems like Bart van Ingen Schenau's answer agrees that what you do doesn't depend on the work that the people on your team are doing, and I'm even seeing a lot of common threads between our two answers. It seems like you have two people telling you that your assumption that the work is going to be different is wrong.
    – Thomas Owens
    Jan 31 at 11:06
  • That is one of reasons I like to ask questions to total strangers even though they can't possibly to know more than I do for my own job. Feb 1 at 1:53

What should I, as their developer manager, do during the bug fix sprint when my team members are busy in fixing bugs ?

Taken literally, you ask here what you should do differently, in your role of people manager, when your subordinates are fixing bugs versus developing new things. That is a wholly uninteresting question, because what you do as people manager is completely independent of what your subordinates do.

Later on in the question, you mention that you are also the tech architect for the team. From the perspective of that role, the question is way more interesting.

One thing an architect should do is oversee that their architectural vision and direction are being followed by the team. That activity would be the same for feature sprints and bug-fix sprints.

Next to that, you should be working a little bit ahead of the team, so that you can be prepared for the questions that will come. During a bug-fix sprint, you can already look into the features of the new release cycle to understand how they would affect your architecture and what questions you could expect from the team.

Another thing to do during the bug-fix sprint it to check the bugs that have been analyzed for commonalities in what caused those bugs. That can help you uncover weaknesses in the architecture and/or work processes that you might want to address before (or during) the next release cycle.

If, after doing the above, there is still time left, and if hands-on development is part of your duties, you can think about helping the team by picking up some bugs. As your other duties might cause interruptions, it would be better to pick the boring ones.

  • If I did not get that comment "If you are not clear on your job responsibilities you should ask your boss." I would not add that final explanation "As a small company we can't afford to have two totally separated roles ..." because even the definition of "dev manager" varies, the role exists in many software companies I know of. So I would like to what other "dev managers" do during the bug fix sprint. Jan 30 at 15:30
  • @Qiulang邱朗, for me, the dev manager side is people management. A people manager does not touch the code or the ticketing system, so it doesn't matter what kind of sprint the developers are in. Besides that, I fully understand that in a smaller company, someone with the job title "dev manager" can have other roles besides people management, such as an architect role. Jan 30 at 16:35
  • I have to say during my time in big company the "pure" people manager seem to have quite some time left for unproductive activities (me included). So how to spend their time wisely is another interesting question (so I disagree with your word "That is a wholly uninteresting question"), but probably not for SE. Jan 31 at 2:14

If you are a dev manager and you find down-time to even have this conversation, then well done, take a breath and relax for a moment.

If your backlog is up to date, and there are no outstanding reports, assessments or reviews to complete, and the backlog has a lot of future items that are well documented or defined to choose from for the next few sprints... Then I would take this moment either to prepare a proper retrospective of the last quarter or last few major release cycles or alternatively look to the future and prepare a business case for the next big hairy audacious goal.

Investigate new technology/methodology, see if we can introduce them in the next release cycle.

This might be the only time that you get to prepare for what is next, but your investigation only needs to go as far as describing the potential viability of V-Next. It is not your place to boldly go there and come back with results, that is a dev job.

A Dev Manager needs to understand code and the code process, but not get involved with it. You are now a facilitator of developers, there to assist them make decisions, to be the catalyst that keeps the sprint moving forward without getting your hands dirty. It is not your job to have all the answers, you are there to help your developers find the answers.

Do not feel tempted to get involved with the bug fixes!!! Even though you have the skills and capacity today, your role specifically is one where you need to be prepared to be interrupted.

Probably the worst thing you can do is take on a really hard bug. By all means analyse issues that are outstanding and help break them down into manageable tasks but if you get involved in the code work, now the rhythm of sprint is tied to your ability to fix what no one else has so far been able to. If you get distracted in the middle of a large refactor effort, and leave the job half done, you may find that other devs will fix some related issues instead of waiting for you, the merge effort at the end, if you get there could be more significant than had you simply tasked someone to re-code the affected feature from scratch in the first place.

The Dev Manager role is where agile is employed in it's rawest form, do not take on commitments outside of your direct responsibility. You cannot manage the team and be a part of it, we are not the kings of old riding at the front of the army leading the charge, we are however the scouts, leagues ahead of the front, scoping out the next offensive and plotting the course.

  • When you said "If you are a dev manager and you find down-time to even have this conversation ..." I am not sure if you were sarcastic or ... But I did these at my spare time, not in my office time, e.g. now is 9 pm Beijing time. And about agile as I said I hope it won't sidetrack my question into another discussion of agile. I also raised a question specifically about scrum softwareengineering.stackexchange.com/questions/410482/… Jan 31 at 13:16
  • So I said "The way we do scrum/agile is small release and continuous improvement", which implies it is not specially about those scrum stuff. Jan 31 at 13:20
  • No I was serious, we should be continually defining the path forward, or reviewing what has been done. The only time that you have nothing to do is when we have already fully defined our way to the destination. And you should not be doing work at all in your spare time, that it your time either to improve yourself or to spend with others. When we leave, the desk and chair often remain, therefore the desk and role is more important than the person doing the work. Don't burn out, if you seek to be 100% busy then you will not be available when you are needed. Jan 31 at 13:23

So from your comments on other answers I think maybe your job title is causing confusion. From your description of responsibilities I would call it a Senior/Lead Dev/Architect role, rather than use the word "manager"

In this role yes I think I would expect you to be "helping out" with actual work instead of just having lunch "meetings" with the other managers. ;)

You say :

"I am responsible for our deliveries as if anything (seriously) wrong with our product I am the first to be called."

If you are doing a bug fix sprint I think your number 1 task is to figure out why you have that many bugs and how to make sure you don't get any more going forward.

If you just accept that "we will always have bugs" you will always have bugs, so while the devs fix the bugs, you have to figure out why you got those bugs, how they managed to get through testing, how you could have caught them earlier, how you can verify they have been fixed etc etc.

I expect this to manifest as specifying extra stuff to do over and above the simplest and quickest bug fix, add more tests! Add more logging! Make sure that works for the general case! Load test that fix! Make a report on uptime for that service! etc etc

Of course you probably have a whole other bunch of stuff to do which might take priority depending on your workload, but, Yeah a whole sprint just to do bugs? sounds like you are not on top of that. Make a report on how many bugs are found over time and set goals to get that number down. Convince other managers to see the benefit of putting effort into getting "zero defect" releases. Slow is smooth and smooth is fast!

  • But I am indeed their dev manager and that is not because I like this title so much that I have to brag it. I did not list my people manager duty as it is irrelevant to this question. Feb 1 at 1:48
  • I am only going off what you said in the question.
    – Ewan
    Feb 1 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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