My team is close to a release and deadlines are getting tighter. This is wreaking all sorts of havoc on the team members. One of our developers is late on his deliverables.

I believe the problem arose in the first place because of lack of proper co-ordination, monitoring and feedback. These are the functions of the manager. However, now, since the deadlines are near, this particular developer is beginning to report that he won't be able to meet the deadlines (that he had himself set earlier on in the development activity) in time, and hence there might be a delay. Delay from this particular developer is going to hit us bad since the other modules that we worked on were not designed independently and have huge dependencies on this particular person's work. And since our customers are already waiting for the release on the committed date, delay is really not an option. The way we will go forward now is that the developers after finishing their work will have to take up some of the load from the QA guys to compensate the slip in the deadlines.

The company considers this a serious issue. Upper management has scheduled one-on-one interviews with all of us to know what is going wrong. I am one of the developers on the team. What should my response be to such an interview be?

  • 5
    Why 'blame' either? Lay out the facts, as you see them. Lay out the solution as well, since THAT is whats important. Look back, learn and move forward. – WernerCD Oct 11 '12 at 2:10
  • if you want to blame anyone, blame yourself for not identifying the situation earlier and getting everyone working together to prevent it getting to become as serious as it is today. – jwenting Oct 11 '12 at 6:15
  • @jwenting: I'm not sure I follow: You want me to blame myself? I completed the work assigned to me well before the time I outlined for myself. – Arpith Oct 11 '12 at 16:01
  • 1
    @jwenting: As romantic as you are trying to be, my job is to do my part, and do it well. If my part slips, I will be the one in trouble. It is NOT my job to identify problems that might escalate. I understand and acknowledge that in a perfect world, maybe I could have made time and tried to identify how things could have been done better even before landing up in a sticky situation; but that is not the case. I was busy making sure I stuck to my schedule and not cause a rescope. – Arpith Oct 12 '12 at 6:30
  • 1
    @Arpith your job is to be a member of the team, to complete the project as a team, and to do the best to ensure the team succeeds. Trying to turn another team member into a black sheep is not the way to do that. It destroys the team. You SHOULD have alerted people earlier as to problems you noticed developing. The fact that you didn't was your failure and yours alone (and the same for other team members). – jwenting Oct 12 '12 at 6:43

My experience has been that finding someone to blame in this sort of situation is rarely a productive way to address the problem. A really big issue like this is usually more than 1 person, in fact it's typically more than even the 2 people who have miscommunicated. In addition, picking sides usually ends in a battle, rather than a solution - so I'd try at all costs to stay away from a single sided focus on this.

Things I'd look for when trying to explain this to senior management:

  • Contributing factors - what are all the contributing factors that lead to this estimate being incorrect? Did the guy who is running late have the deliverable needed for testing on time? Did he have the time and computing resources and other tools in the time frame required? Was he distracted by anything else? Was the product more complex than originall forcasted (for example, the estimate was prepared for 3 main features of moderate complexity, and now there are 7 of high complexity)? Usually this highlights that it takes more than one guy to make a project run terribly, critically late.

  • Patterns - What has been the pattern of both individuals? Is this manager particularly faulty in other cases? Does the QA guy typically underestimate? Does he show negligent behavior (arrives late/leaves early/chats alot)? Have other people had trouble with this manager's communication style? Hearsay is not something I would repeat to management, or the whole process becomes fingerpointing festival... but for you own insight, you might ask yourself what of any of these behaviors you've seen first hand.

  • Feedback - this is something to stay completely away from if you are not in the management chain - it's not your job to give a peer feedback, unless you are asked to be part of a peer review process. And then, it's typically about the quality of technical work, not the softer stuff. But... if it's you that is involved as either the manager or the employee - what feedback has been given? To both the employee and the manager. You can't really expect someone to do something right the first time, and offices work very differently in terms of status and progress reporting, so you can't say that a given communication mechanism is necessarily "standard". Has this guy been told that he's got problems and given feedback on the expectations?

  • Feedback addendum - Also, right now, what is the guy whose work is late doing now that your team is in crisis? Is he pounding away and working closely with others to delegate and keep the work going along as efficiently as possible? Is he making extra time to make sure it's a success? These are signs of diligence - knowledge work is tough, you can make a bad call and end up doing massive extra work - the trick to judging people is how do they react in times of crisis? Same goes for the manager and any team mates who are pitching in and/or really slacking off. In the end, the goal ought to be that "we get our product out the door", not that "you were late, so I'll see you later".

  • Process, checks & balances - in a fairly mature software development process, there are usually checks and balances to make sure that work will complete on time. Usually this allows the manager to have feedback separate from his own judgement that give him an indication that there are big problems. Did your company have such a process? This is a nice way to come at the solution in a productive way - it's a "what can we do better?" type of approach instead of a "who should be fired?" approach.

Rarely, in a case like this, do I see a case where either side is truly wrong. I do see a problem if one specific side is showing really horrible work habits such that there is some doubt as to whether they were completing the basic expectations of their job.

But, given that the post is not "how do I deal with a total slacker?" but trying to figure out who's right and who's wrong, I'd posit that it's quite likely that they both are, and if both accept that there were things they could have done better, and if your upper management is willing to consider ways to prevent future issues to mitigate such communication problems - then the truth is that bad stuff happens, but you can count yourself lucky to be in a basically healthy organization.

If upper management isn't willing to consider that sometimes estimates go wrong, and extra work is required, and they persist in looking for a scapegoat - then the real people I'd blame would be upper management, who has the real responsibility to make sure that communication is flowing and that the team members can work together well enough to get a job done.

  • 2
    Excellent answer, I would add that I have often seen the problem is not the developer or the developement manager, but it is poor or changing requirements (especially last minute changes to something that is critical to the basic design), unrealistic deadlines that were not changed when the developer expressed that they were unrealistic (you can't make a 200 hour task fit into a 40 hour window no matter how much you wish for it) and a Project manager unwilling to pass bad news properly to senior management or clients even though it was known for weeks that there would be a delay. – HLGEM Oct 10 '12 at 21:31
  • Agree with most of this but disagree strongly that neither is to blame. A good manager understands that this will happen, if left unchecked, and put in communication processes to highlight the problem early. Also, "making extra time" is rarely a sign of diligence. It's a sign of panic and poor management. Which doesn't mean that I never expect it, just that I think it's all-too-often credited to the employee cause "Well done, Johnny," is easier than "Why have we just burned Johnny out? How do we not do that again?" – pdr Oct 10 '12 at 23:47
  • Nice answer, @bethlakshmi. However, I have something to add. The manager trusted this guy to get the job done since he has been with us for a really long time. The problem was that he overcommmitted, I agree but he also convinced our manager that he needs his space to work since his item was to be the shining beacon of our release. The manager had asked for a weekly stand-up which this guy refused to take part in calling it a waste of his time. In this case, the manager's only fault boils down to this: "He trusted his employee to get his committed share of the job done." – Arpith Oct 11 '12 at 16:08
  • So, it sounds like there was an opportunity, a long time earlier, for this guy to get feedback about communication - had he given status earlier, he'd be in a lot less trouble now. Still a two-to-tango - IMO - the manager could have not allowed that to happen, found a different way to get status, or started disciplinary action a long while back. – bethlakshmi Oct 11 '12 at 21:09

Since this is such a serious issue, upper management has scheduled one-on-one interviews with all of us to know who is to blame. What should my response be to such an interview be? Who do I empathise with?

If I read your question correctly, it appears that properly fixing blame in this instance is more important to your company than completing the project. Am I reading this correctly? If so, blamestorming isn't going to stop this from happening again. Are they sneaking behind the employee's back to bad-mouth him to all the other workers? Will they bad-mouth you next?

If your co-worker is overwhelmed, perhaps a better approach would be to see what you can help them with.

After the project is delivered, a more appropriate solution would be a "post mortem". This is where you sit down as a team and try to document what worked, what didn't work, what you'd do differently if you knew then what you know now. Apportioning blame is not a good way to move forward.

  • Couldn't agree more: fix first, post mortem afterwards. Diverting attention from fixing to blaming will always make the situation even worse. – Carson63000 Oct 11 '12 at 4:45
  • More than a blame-first, fix-later approach it is more about knowing what exactly is happening in the team. We are already overworked just trying to get our deliverables ready and now adding to our load by asking us to share the QA part because of the mistakes of a person (or two) as well is eventually going to lead to less productivity (in their eyes, atleast). – Arpith Oct 11 '12 at 16:14

The engineer may have had his own deadlines but if not required to publish them and make them relative to the rest of the project, then that was just extra on his part for himself, even if he missed them.

The manager should have some sort of periodic status meetings or check-in's.

The engineer could have took initiative as well and checked in with the manager but really shouldn't be on him.

For your own interest, even if some one is clearly to blame, don't.

This is where you can get bit in the a$$ in the future.

Play politics and put the blame on a lack of communication skills and or process. Put the blame on mutual work processes.

See: What does "politics" mean in a corporate environment?

  • So you mean to say that I should go with something like: It wasn't really the fault of one single person. We all screwed up. (?) What if this encourages more such behaviour from other developers (esp. junior developers) in the team? – Arpith Oct 11 '12 at 16:17
  • 2
    @Arpith: First, your ultimate goal is to protect your job. Anything you say will be remembered, long after this specific situation is forgotten. What if one day this developer happens to be your boss? or this manger finds out you were a threat to his position? Your goal is to load this off onto something that is always in constant flux, not tied to any one person and is expected to be improved through lessons learned. You need to flip it around on the interview - i.e. "here is where we can improve this int he future...." – Greg McNulty Oct 11 '12 at 18:09
  • 1
    Hmmm nice point. Upvoted accordingly. – Arpith Oct 11 '12 at 18:41

There are actually a couple of questions here.

The first is "Who do I empathise with?" And honestly the answer is almost always the employee. It doesn't matter how many mistakes they've made, and I'm sure they've made some, it's management's job to spot them early and fix them -- even if "fix" means telling his managers that they have to rescope or move the deadline.

The one exception to this is if an employee has outright lied and covered up his failure. But even then your question has all the classic hallmarks of a company with a blame culture, which only encourages people to hide the truth in the hope that they can fix problems before anyone notices. I still blame the management and culture to some extent.

Another major cultural red-flag in your question is the repeated use of delay not being an option. Delay is always AN option. Just saying that it isn't doesn't fix the problem. There may be better options, such as rescoping or a certain amount of overtime (hiring into a project running late is rarely a good idea), but we cannot ignore that delay is an option.

When you tell us that the developer set his own deadlines, is that really true, or was it a passive-aggressive "we need to release by this date, if you can't do it then we might as well fire you all now cause the project is useless to us"? (I have seen both extremes and a lot in-between, all described as developers setting their own deadlines. Usually, it's the companies that force the estimates they want that say "delay is not an option," when you fail to hit them.)

Even if he did set his own deadlines, did management understand that developers are inherently optimistic and put processes in place to identify any slippage early? Did they put processes in place to make sure that dependencies were prioritised appropriately? Did they prioritise by behaviour/functionality, so that you couldn't run into the situation where less-important functionality was complete but key functionality wasn't?

If not, these are all management failings.

All that said, the real question you're asking is "Who do I point the finger at in my one-on-one interview with upper-management?" And, unless you're very brave, you can't storm in and scream "it's all your fault, you idiots!"

If I was in your position, I would blame the team, as a unit, including the manager, his managers, the employee and yourself. Say that there is clearly something wrong with the way you're working, if one individual is running late and others aren't. You should be working as a unit to deliver a single product; what you are clearly doing is working as a group of individuals, delivering your own modules and hoping it all fits together later.

I might even talk to a few more people who clearly aren't to blame and see if we can all agree a common message that spreads blame around, rather than focussing it.

Suggest that if you were working more as a unit then, if there ARE individuals who slow down the team, that would become apparent to all very early and then upper management may have someone to fire when -- or, better, before -- things go wrong.

But (and this is the most important thing) also suggest that pointing fingers, behind-closed-doors and after-the-fact, like this is counter-productive. You all have a job to do, getting this product out of the door. Losing people, even bad managers, at this point, would only make matters worse. And wasting an hour each (more for the senior managers involved), destroying whatever cohesion the team currently has, is a crazy idea right now.

So the team should have a different meeting now, about damage limitation for this deadline (and yes, that means sacrifice and compromise from everyone), then have another meeting after the deadline about how you don't get into this mess again.

  • As always, nice answer @pdr. Refer to my comments to bethlakshmi's answer. :-) – Arpith Oct 11 '12 at 16:17
  • I see your point and the employee definitely has been screwed by his own hubris. However, I still maintain that closer team cooperation and some level of transparency would have exposed the problem earlier, and it's the manager to blame for not having that. I'm all for trust, but there are limits. And, most importantly, I maintain this is not the time to destroy the individual who has messed up, you're going to need them over the next few weeks. After that, you can talk about how to avoid the same problem recurring next time. And it may or may not mean their removal. – pdr Oct 11 '12 at 16:37

Is the public shaming absolutely necessary? I guess it's typical of office politics and social economics to apportion blame. Where I'm from, in the event of an impending deadline slip, the developer (and/or) his team mates double down and try their damnedest to deliver. The execution may come later. Your role (I'm assuming as manager) is to try to not take sides (unless someone is likely to be fired, in which case some rear-covering maybe necessary for the developer. The manager usually survives such events). You already have the facts and have already adequately apportioned the blame already. Tell it as it is during the interview

  1. There could've been more supervision
  2. The developer probably over-committed himself and thus couldn't meet his goals.

There is no obvious need to take sides (and can only end in resentment if either party finds out you did)

  • The neutral path. Correct me if I'm wrong but this still does not help in not letting an incident like this repeat again, right? – Arpith Oct 11 '12 at 16:20
  • @Arpith You're taking the neutral path with respect to the interview. Behind closed doors, when there's just you and your team left, you may administer the shaming :). That might prevent a reoccurrence too soon – kolossus Oct 12 '12 at 0:02

Not the answer you're looking for? Browse other questions tagged .