Sometimes non-technical superiors (matrix managers) from other departments spot something that didn't work as expected or are annoyed that we cannot deliver a project by a certain deadline; or cannot push harder.

This may be due to a technical limitation, a bug or similar.

Instead of accepting the revised feedback or new proposed timelines, they insist that they want to know "everything" about the process so that they can try and see how they can help make things faster or ensure we don't repeat the "mistake".

But in most cases it is indeed a technical reason, often something we still need to explore, or other times, something that never happened before and will rarely happen again. I have witnessed how this kind of managers just nod when we try to explain them the technical details. After explaining, they ask something like "So can't we get this done faster?"

In reality, I feel like it is just a technique to put pressure on us rather than try to understand, and often just ends up taking away more time from actually addressing the issue - but I might be wrong.

Anyway, what should I do when a non-technical manager asks that they want to know and understand "everything" about why something went wrong or cannot be delivered by deadline?

CLARIFICATIONS - just wanted to make sure it is clear to all that I want to help and cooperate as much as possible; I would like to be more effective in what exact information I share.

However, the main point is that as I am given projects and deadlines by multiple superiors (matrix managers again!) I need to decide and prioritize what is more important for the day: e.g. work towards meeting deadline of manager A or discuss with manager B, when I could instead both fix B and meet the deadline of A if I skip the discussion. I cannot meet deadline of manager A and discuss B and fix B. In such a case, what would you chose?

The other point is that sometimes I myself don't know and require action from other technical experts to help clarify the situation.


4 Answers 4


Like most topics dealing with issues between managers and technical folks, it takes a small change of perspective to understand what the manager is up to.

First and foremost, no, they are not wasting your time. Yes, they are putting pressure on you.

When a schedule has slipped, depending on the size and visibility of your project, a number of levels of management may be called to the carpet to answer why. When these managers ask you to explain "everything", what they are likely trying to do is understand the problems enough to create a simplified explanation to their bosses. The better the explanation they give to their boss, the better the chances that the slip will be accepted as opposed to everyone getting canned.

So, the next time one of those tie-wearing windbags stops by and asks you to tell them everything, be kind and understand they're just trying to protect you.

  • +1 for the sentiment that the people applying the "pressure" aren't trying to interfere or cover their own butts but attempting to be the buffer between the work and the upper levels. The don't really want to know "everything", but if they don't understand the real problem then they certainly can explain it properly to the people above them. Commented Aug 20, 2014 at 17:37
  • 1
    Perhaps I'm cynical, but this seems overly optimistic. Matrix managers especially often want to be "involved" so that they don't seem weaker or less relevant than their peers (other managers in the matrix). And then there's the control freak managers who want to institute process to prevent the issue in the future (at unreasonably high cost). Though I suppose there are the rare times when the manager actually wants to know so they can deflect potential issues.
    – Telastyn
    Commented Aug 20, 2014 at 17:51
  • 1
    @Telastyn those less wholesome people do exist. I think more often than not though the manager is trying to do the right thing. (Make you make the company money) because that makes them look good. What doesn't make them look good is stuff not getting done and not being able to explain why. Process is a tricky bag though. I personally institute a lot of processes that seem extremely wasteful to many of the people manning the floor, many of these processes become extremely useful though when you take a step back and look at the bigger picture. (even if they cost some time to maintain) Commented Aug 20, 2014 at 20:54

If something did not work as expected, you need to log it as an issue and decide if it was not communicated to you how it was supposed to work, a bug, etc. and go from there

If you cannot deliver a project by a certain deadline, you better have a good timeline and be able to back up why each step takes X amount of time, and offer alternatives by adding Y more people or Z amount of overtime. Allow them to offer suggestions and figure out something that works.

Being non-technical, they may not care about the particular technical nuances, but they do want to know if it was a bug or not, and if so, where does the bug lie - so they can remove it from future projects - that is their job as a manager, to remove obstacles and allow future development to continue, bug-free. This may involve calling vendor support or establishing more rigid internal testing guidelines - you need to be able to help them come up with preventative measures. If it was a technical limitation, then they may need to create more specific proof-of-concepts or adjust those - again, that is their job, and you need to be willing to help them.

The fact that it is indeed a technical reason does not excuse you from needing to explain it - you just need to explain it in such a way that they can understand what it means for them and the implications - "Our current servers do not have enough RAM to handle X customers, we need Y amount more which costs Z and can be installed by the server group by next *Day.

The fact that it may rarely happen again is something that you can mention, but allow them to make the call on if you code defensively against it happening again or not, and an estimate for that. Try to give them numbers such as Y% of our customers fall into this category if you can, otherwise suggest what sort of statistics you would need to produce numbers, and the time necessary.

Managers have every reason to pressure you to get stuff done faster, and you need to accept that, and then be able to explain why each step takes X amount of time, and why Y is important and can't be cut out, because their job is to find the Y which does not provide business value, and cut it out - and unless you can say Y does provide business value, they will end up decommissioning the source control servers. There is certainly an art to this communication, and it takes time to improve upon, but right now it seems like there is a high amount of friction in addition to everything else.

If something cannot be delivered by the deadline, that is a huge problem for the Manager, and you need to treat is as such, and be willing to work with the Manger to not only resolve it, but prevent the problem from occurring again. You may suggest postponing non-critical meetings as to "what went wrong" until after it's fixed/delivered, but do not imagine that you can skip past them - they are critical, arguably more critical than whatever you just delivered, but perhaps not as urgent.

You seem to have the mindset that these discussions are a chore and you are trying to avoid them - you need to get past that and put yourself in the Mangers shoes and work with them - only once you do that can things start to work smoother, and hopefully there won't be any more missed deadlines.


Why on earth would they accept what you say without questioning? Having seen both sides of this particular fence, I know that many times people have claimed technical difficulties to avoid work they did not want to do. They have claimed limitations of the tool when the real reason was incompetence or a bug they would prefer to hide.

Further, managers have responsibilities too. They a have a fiduciary responsibility to deliver the project at least cost. They are rewarded or punished for on-time completion. They are expected to explain any deadlines that are not met or features that are not implemented, often to people outside the organization such as the clients paying the bills.

These meetings can get quite antagonistic as the people who are paying for the work are often unhappy when it is not going to meet their business deadline. They have to be able to soothe the people who are ultimately paying for the project and they must be able to explain in enough detail that they don't look like an idiot to the client. And clients sometimes have technical people representing them at these meetings. So of he goes in and tells them that such and such can't be done and the tech guy doesn't believe that, he is going to be closely cross-examined.

So how do you know what to tell them when they ask? This is fairly individualized and it is something that is best asked of the manager who is asking for information. Just this week for instance I have basically told one manager that we messed up and broke something, it was complicated to fix and even more complicated to QA and on a different problem with a different project manager and sales team, I had to give all the gory details of exactly what the problem was, why it was a problem and how we needed to mitigate the problem for the client until the ultimate fix was put into place.

My default when I don't know the person well is to err on the side of too much information and let them tell me what they didn't need. Being able to speak knowledgeably and off the cuff on detailed technical issues tends to give you credibility even when the person doesn't understand exactly what you are saying. If I feel it necessary, I can even point to some documentation of the problem.

I also then tend to turn my explanation around to what this all actually means from a business perspective and how it impacts them. So now the person who doesn't know me well can tell that I understand their business needs as well as being clearly technically knowledgeable. By doing this early in a business relationship, you can get to the point where they trust you when you say, 'We messed up and broke something, it was complicated to fix and even more complicated to QA.'

The one thing you don't want to do is appear to be avoiding answering their questions or hiding something. That only leads to much more detailed questioning. This is especially true if you give them the impression that you are annoyed at them for daring to question you. You have to think of senior managers sort of like IRS auditors. Yes it is annoying, but they have the right to the information and they need it to do their own jobs, so you have to put up with it as graciously as you can.

  • "They are rewared or punished for on-time completion." And the workers aren't. Hence (in some cases) the pressure. Do note that unskillful planning, wishful thinking and "crunch mode" are all too common in certain companies. To some degree, it is part of the job but you can't expect technical personnel to cover up for what is simply often unrealistic planning.
    – Rob Jens
    Commented Mar 18, 2017 at 18:44

I think none of the answers so far actually explained how much information needs to be disclosed exactly.

I would say a good compromise is to elaborate the steps broadly and explain the consequences of each technical limitation or bug to the business if they are not solved.

For example, if the supervisor asks:"Why can't we get this done earlier? I want to know each step involved in this and how we can get it done faster."

You could list the steps taken so far and which exact steps among those caused created the technical issues. If they ask what exactly was the technical issue, and if you don't know it yet, you can say that you are still investigating.

Often it is truly an unknown issue and you need to draw the line when they try to interfere with silly questions.


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