-1

Background

I just had a few-months stint in a brownfield project which had "hit the fan".

As far as I can tell, the biggest problems were on a middle management level:

  • Intentional or unintentional information hiding.
  • Very bad overall communication.
  • Bad misconceptions about facts which were not communicated (everybody "assumed" something or the other, nobody bothers to check).

This is all about internal communication; there do exist customers, but the problems are clearly inside our company.

The reason why communication was bad were probably...

  • Every manager being very stressed out and having much too high workload.
  • Most managers were quite new to the project; most of them did not have good "intuition" yet of when/where to suspect pitfalls.
  • Most were physically separated (different locations).
  • Often, the roles of the individual managers were not quite clear.

In my case, I was representing two teams; one developer/ops team with a strong DevOps challenge, and another pure development team which had a small greenfield component to work on. I was easily able to work with my teams, with customers, etc. as it was very clear what the technical challenges and solutions were. We used Kanban, weeklies, etc. and were quite happy and successful in our little world. My personal role was not that of a "project lead", but to bring the people together, structure their work, create boards, give broad technical guidelines, support them in case of escalations and so on (similar to a ScrumMaster). I view myself as an "enabler", and was objectively very successful in that regard (judging by the results delivered and the happiness of the people I represented).

The problem

While everything was fine at the bottom of the food chain, on the management level (i.e., upper management, sales, IT, delivery, team leads, ...), we had no structure whatsoever. No Scrum, no Kanban. People were not reading mails, and not sending information per mail. In fact, there was no written information at all. Information flowed when two managers (accidently or because one of them spontaneously needed something) met in person or on the phone. Things were usually ordered up=>down or left=>right, not discussed. Orders usually made little sense, as the guy ordering had little information to go on. There was no perceptable chain for escalations (i.e., due to matrix management, it was in most cases unclear whom to escalate to if things did not work out).

There was one point where one rather high manager actually sent an angry mail, asking everybody to stop discussing things and "just start working" (not that there was an abundance of "discussion" beforehand, and as far as I can tell the project would have needed a lot more discussion amongst the managers!). That was so bad, it was almost amusing.

The question

  • This situation is probably neither new nor occuring seldomly. There are whole comic series about it. In fact I assume that in many companies this may be more or less the daily routine. Other people must have thought about this before. Is this, in the scientific community that concerns itself with management in larger companies, usually considered a solvable/preventable problem at all? Or is this widely accepted in the management community - that's "just how it is"?
  • Are there, simlarly to Scrum or Kanban, well known methods out there how to self-structure middle management to get people to work well together? Or is that basically just up to the boss, by selecting the "right people" for the job (i.e., to pick a choice and hope for the best)?
  • 2
    "I assume that the book "The Phoenix Project" is well known here" - I would not make that assumption. – David K Nov 29 '17 at 13:33
  • 5
    @DavidK It isn't well known. I've never heard of it. – user44108 Nov 29 '17 at 13:34
  • 1
    @DavidK Nor have I – Mister Positive Nov 29 '17 at 13:36
  • 1
    never heard of it – Richard Says Reinstate Monica Nov 29 '17 at 13:44
  • 1
    You're screwed, friend. Either continue to put up with their incompetence, or go work for a company that understand the value of proper methodologies. – AndreiROM Nov 29 '17 at 13:59
4

Agile methodologies typically doesn't work well, if at all, unless the whole organization buys into it, and commits to it from the top down. If this doesn't happen you will constantly continue to struggle.

Short answer: This is not a problem you will be able to solve. The only options I see for you is to deal with the work environment as it is or move on.

1

In my experience there are usually two things that have to go together.

  1. Delegation of Responsibility. I should always be clear who is responsible for what, from the top down. Then it is also clear to whom to escalate.

  2. Delegation of Competence. And with that I mean that the person responsible for something, also has the right do make the necessary decisions to grant success or handle failure.

If this is met with the happy coincidence of selecting the right people to delegate, you are set for success.

When you know "The Phoenix Project", you probably know there are tons of books out there on that topic. Two authors I would specifically point out are Tom de Marco and Pat Lencioni.

But, reading all those book does only help you so far, If your leaders don´t also read them. As they say, a fish always stinks from the head. If management won´t change, that's "just how it is"!

  • Thanks for that answer; both those delegations you mentioned certainly did not take place. I am aware that there are tons of books out there; I find it interesting that we (as humanity) have not progressed past "a fish always stinks from the head", while we on the other hand have managed (sic) to come up with pretty good methods for the low level "grunt" work (not meant disparagingly ;) ). – AnoE Nov 29 '17 at 14:11
  • It´s easy to change the "grunts" if they don´t perform. To change the "head", you have to wait for the money to run out ... welcome to capitalism :) – Daniel Nov 29 '17 at 14:13

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