I've started at a gig that (for the purposes of this question) is an established but struggling company using IT as a business enabler, but not a core function. Around 200 staff with 6 IT staff (desktops, CRM, back office, etc.) and one developer; they're struggling to keep people. This sole developer - let's call him Bob - may be a familiar archetype. He's in his 20's, highly talented, enthusiastic, but also temperamental. He's learnt largely by osmosis, lacks focus, isn't methodical and can be very erratic.

So, Bob is the sort of guy who'll be assigned a month-long critical and exciting project that matches both his skills and what he says he wants to do... yet you'll often find him over by the photocopiers having hour-long "discussions" over which backlit keyboards are best for hacking Powershell with. Or, one day he'll notice his line manager is out, notice the production server is nearly full... and spend the entire day "fixing it", including unscheduled maintenance of the website once everyone else had left the office, and going to bed at 3AM.

Which is indeed what happened this week. As far as I can tell, he decided to do this spontaneously, because it "obviously needed doing". No-one signed off on the unscheduled downtime. I don't know if the issue was important; it certainly wasn't urgent; and of course his critical project is pushed back by another couple of days. I understand this happens regularly; but usually someone has walked up to his desk and asked him to pitch in to some ad hoc thing. This is the first time he's done it "by himself".

I am not Bob's line manager (who is clearly exasperated with Bob's behaviour) but I am involved with trying to add structure and generally try to turn things around. Bob's line manager has tried​ to add process via JIRA and Scrum, but Bob openly ignores issues assigned to him, the sprint board, etc. He seems to like working in an ad hoc manner, even given the problems this causes; and seems to see adding structure to his workday, or have managers run interference for him, as a form of micromanagement, an annoyance to be "worked around".

So, I'd like to have a retrospective / post-mortem on this - but, the small team size, compared with the rather Bob-centric nature of the issue, makes it likely to become a massive blame session at Bob (who is already very touchy on the matter - "I get the blame for everything being crap").

I want this to be constructive. I'll give the standard "this is a space to learn, everyone did the best they could given the situation they had" etc. but I don't think that would work in this situation.

On top of that, I'm not happy in this new role: I'm not able to do the things I've been hired for, there's little structure and I'm bored and frustrated. Seeing if it improves by the three month mark, but already considering leaving. I don't want my issues to​ infect this.

So, how can I hold an effective learning retrospective under these frankly dysfunctional conditions?

EDIT: I don't think it's a co-incidence this happened the day his line manager was out of the office. He knew he could "get away with it". Perhaps he views this as a form of heroics. On reviewing this question, I'm starting to wonder if this is some form of irrational compulsive behaviour, to be honest...

  • 4
    Even with the high turnover, it seems Bob really, really needs a senior developer to work under, or at least a superior who is tech-savvy enough to demand more of a reason than 'it obviously needed doing'. – user34587 May 5 '17 at 13:13
  • 3
    Make it perfectly clear you are trying to hire more people to help him out so the entire IT weight doesn't rest on Bob's shoulder. If that's not true, make sure to buy him a case of beer and pray for the best... – enderland May 5 '17 at 13:27
  • 8
    Retrospectives should never be about blame. They should be solutions and improvements. It doesn't matter who is to blame for a mess; what matters is what happened, how it will be fixed, and how to stop it from happening again. – Erik May 5 '17 at 13:49
  • Find a replacement and let Bob go. As quickly as you can. – Mawg May 12 '17 at 9:42

I come in as a consultant on this stuff some times. I would approach Bob one on one and say

My role is to find a way to make sure you can meet all these competing and often opposing goals: taking care of things that come up without a whole pile of blaming afterwards around downtime and such, getting your long term projects finished on schedule, taking advantage of opportunities to make things better, and not burning out from grinding on the same stuff all the time.

You may not exactly have that role, but I suspect if you go ask someone for it they will give it to you since the line manager is mad right now.

Now you can do some management consulting with Bob. You know, "ask 5 why times", "root cause", that sort of thing. You can draw the quadrant chart with Urgent/Can Wait vs Important / Not Important and talk about different procedures for tasks in each quadrant. You can give him the support he needs in the form of process and procedure that he can use for reacting to things he notices or things people come and ask him about. You can even provide some project management tools and advice to help him deal with breaking his project up into manageable pieces and be able to see progress on it, for himself and those around him.

None of this has anything to do with blaming him for downtime. Done right, it will prevent that sort of thing happening again but in a really good way, with no hint of "you shouldn't have done that", more of a "together, Bob and regilejusl worked out a policy on that and from now on that's how Bob does things and we all feel protected and supported" way. You may also make a huge difference in his approach to development projects.

I think these actions count as "trying to add structure and generally try to turn things around" and they are what I would do if I was brought in with that brief. You tell Bob the structure you are building is a framework to make people leave him alone when it's not worth interrupting his development work, but also enable him to fix things that need fixing without a lot of fingerpointing afterwards. (For example if he's supposed to send an email warning about downtime in advance, you don't sell that as "you won't be wrecking things for sales" you sell it as "that way sales can't come back and complain the next day, because they were notified 30 minutes before you took it down."

If you care about Bob and want him to be a great solo developer, building him the support structure he needs is a gift you are giving him, not a leash you are putting on him. Holding a retrospective about what Bob did wrong is not going to get you to that structure. Let the lessons from the immediate past present themselves naturally as the two of you establish what structure will help him the most.

  • Thanks Kate, however, it seems his line manager has already tried this (I've edited the question to reflect this). Bob doesn't seem to see adding structure to his workday as a form of support or process - he seems to see it as an annoyance to be "worked around". – regilejusl May 5 '17 at 14:48
  • 4
    That is the problem to solve. Someone (probably not his manager) needs to sit with him shoulder to shoulder and develop structure that genuinely supports him. Needs to listen to what his problems are with existing or proposed structure, and to what other problems happen, like people blaming him, and patiently work until a solution is found to those problems, or he starts to accept the benefit of some of the suggestions. This requires a lot of listening. It may take a long time for Bob to trust anyone with this. He may never (I've had staff who didn't), but you can try. – Kate Gregory May 5 '17 at 14:57
  • @KateGregory Probably the worst approach, and you've rightly pointed it out, is to come out and say "you did it all wrong before I got here." To say the least, these are people doing work and presumably their best given the coniditons, and all that statement will do is, for them, diminish the value of their contributions. – CKM May 5 '17 at 17:24
  • Genius level answer. – Mister Positive May 5 '17 at 18:51
  • @regilejusl there is no way that just adopting JIRA and scrum, and assigning someone tasks in Jira, will feel like supportive or helpful behavior. It has to start with listening. It has to be at least partly Bob's idea. There has to be something in it for Bob. – Kate Gregory May 5 '17 at 19:29

Why is the problem Bob-centric? Surely even though it is a small team, they should be helping Bob and preventing each other from making big mistakes. How can one guy pull down the production website without following any process? That sounds like a bigger problem than Bob's behavior.

I just recently called a postmortem with 5 people on a hellish project that had plenty of blame to go around if anyone cared to do that, but it was constructive. We focused on (notice the "we" in all of these even though I was the only developer on the project):

  1. What worked and how do we keep doing that in the future?
  2. Where did we fall down, and how can we prevent or mitigate that in the future?
  3. What did we learn? (Here's an example: Never, ever believe a vendor's delivery date if it falls on the last business day of a fiscal quarter. It's totally made up.)

I sent out some food for thought before the meeting (basically a timeline of significant events) and I came prepared with ideas of things to talk about. We had a great meeting with some tangible process improvements we plan on implementing.

I feel for Bob, because I have about three decades of professional experience under my belt and I couldn't pull off being the sole person responsible for that project. It seems to me like he's being set up to fail. Maybe he's erratic and lacking focus because what's expected hasn't been clearly communicated to him, and he doesn't have someone that's showing him the ropes. Sometimes we think we've explained something well, but I've found that folks with less experience tend to be hesitant to admit they didn't really get it (or they think they got it, but they didn't really). Maybe his team could pitch in and help him in some ways even though they aren't developers. Maybe someone wants to learn how to do some small part of Bob's job?

So for your retro I would focus on how JIRA and the sprint board is/isn't working. Bob doesn't use it - why? What safeguards need to be put in place to prevent unscheduled downtime of the production servers? How does necessary maintenance get scheduled and prioritized? What is working well? (find some positive feedback - Bob did notice that the production servers were getting full. That's not nothing.)


Your retrospective should indeed be for issues and improvements that can be addressed by the entire team. If all issues that might come revolve around Bob, his manager should first seek a one-to-one discussion with him first. Maybe hold off a retrospective a little longer until the overwhelming employee-specific concerns are seen to.

Even if Bob's manager is not a developer, he should be reining Bob in a bit. Bob's projects and 'fixes' need to be better tracked and documented. It is possible that Bob, being the only developer, is overworked and is making rash decisions. Even so, someone should have a clear idea of what he is doing and why. From Bob's description, he needs better leadership. A good developer can still be a terrible colleague if they can't follow procedure. Even with your high turnover, I would strongly suggest your company find a senior developer that Bob can report to, someone who has had more experience in the field and will inevitably raise the same concerns you have. If the lack of fellow developers is the a problem, take steps to assure him that you and the company are trying to find more.

You are taking steps yourself to try and turn things around, and those above you should appreciate it. If after a couple more months, your voicing the same concerns, you shouldn't feel bad about going elsewhere.


Bob needs an intervention, either by you or by his manager.

At the moment he's running around like a chicken with it's head cut off. He's trying to solve every problem he sees, and causing issues because of his untrained 'skills'.

The approach I would take with Bob is twofold; firstly, I'd ask him to identify which of his skills are most important, and develop - with his input - a plan to get him some valid and solid industry qualifications in those skills. That will make him specialize more, and will show him areas where he needs to let go. In the future, if he leaves (or is nudged), those qualifications will help him get another position elsewhere.

The second approach is to explain that his actions are not scalable; you can't bring in other developers to work under him or at his side if his working pattern is so unstructured. Show him the carrot that you can only promote a professional who is totally in control, and not someone who is running around sticking his fingers into everything. JIRA etc is a good start, but someone needs to make Bob accountable to it; "You were assigned these tasks. How far did you get? Why?"


Answering my own question...

Asked Bob's line manager (if I'd not done this, IMHO I'd have been hypocritically acting like Bob) about supporting the team as in Kate's good answer. Was clearly told "Bob is not your problem, don't worry about him". There had already been a meeting about this of the "please try not to do this" variety. They seem to view Bob wandering around doing whatever he feels like as an acceptable cost for his other work that meets "the plan".

Got the impression that Bob is "roped off" from any improvement efforts, to not risk him walking and leaving them with no developers at all.

Obviously this is not ideal, but then change management never is - "start with what you have now" etc. For my part, will attempt leading by example and resetting the culture, hoping to pull Bob in rather than pushing him along.

  • I realzie from what you say that you are now out of the Bob lopp, but the correct solution is to find a replaement, then put Bob on a PIP. – Mawg May 12 '17 at 10:37

I think the most immediate impact will be in limiting some of Bob's access to things. This will preclude his ability to add more gasoline to a fire that you're trying to put out, and give you the ability to do some planning without everyone being in reactive, "emergency" mode all the time.

Secondly, put Bob in a position where he has to pair with another staff member for anything that makes changes to your production environment, and this will put your team in a position to cover issues much better than you're in now because Bob will eventually stop being a bottleneck.

Third, the planning I discussed above entails changing processes once you become clear on what the current state is. Who starts projects? Who owns them? How is work funneled from management to subordinates? Are developers making business decisions? You might have to fend off new projects until you clarify, and it might cost you in the short term but the long term benefits are legion.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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