The organisation and not the individual

I usually recommend books face to face. But here I’d like to do it here in public. Perhaps the everlasting focus on the individuum is also bothering you at the moment. The following book offers a mirror and hence a centre of thought. Warning, this book is currently available in German language only. Maybe you auto-translate a eBook-Version.

The individual as the father of successful projects, as the rotten egg in the basket, as the upcoming hero or as the personified failure are nothing but stories. Why certain people have been able to achieve success has many roots. Current market events, a bit of luck, and certainly the people involved themselves, no doubt about it. What is discussed far too seldom for me is the organisation. Organisation can make the greatest things possible, or it can also be the guarantor that the simplest transformations always end in nothing.

“Die Humanisierung der Organisation” translated “The Humanisation of the Organisation” by Kai Matthiesen, Judith Muster and Peter Laudenbach looks at organisations as observers in the spirit of and with reference to Niklas Luhmann. In some sections, this creates a very harsh picture of organisations. But that is fine, because it creates a touchstone for one’s own preconceptions of organisations.

The book is born out of consultant practice and is full of wonderful quotes. “There is a belief amongst people that working well together as a team means that everyone in the team must always agree with each other and have identical opinions. This is a misconception. Working well together means rendering the different opinions and interests productive.” p. 161f (translated by me for the Original quote switch to German).

“Visiting this parallel universe, one understands that the possibility of insolvency is one of the greatest assets of the market economy. It enforces a certain rationality in the interest of survival.” p. 239 (translated).

After 240 pages of showing organisations the mirror down to the last bone, the book ends with a wonderful call to action: humanisation as the effect of good organisation that is enlightened about itself. S. 248.

Well written, I can only recommend this fresh look in a book form.

Book "Die Humanisierung der Organisation"
Book “Die Humanisierung der Organisation”

Just ask how you can improve

Following the principles of lean management, we have discussed with many customers over the last few weeks. By asking them what they personally feel about the work we do. Their opinion of how we work as a presales team, not about the company’s performance as a whole or the level of customer satisfaction at the present time. And who could answer this question better than any line manager? Our customers!

Fortunately, we’ve had quite a bit of practice at this now. Doing this for the first time takes some arm-twisting and it feels daft on both sides. Customer surveys on products or services are familiar to us.  Consultants asking to be criticised feels rather strange.

After some initial irritation, customers realise that we as a team are concerned with improving. This understanding is enhanced by a method based on Lean. Time again, all the conversations were great. There was compliments, but also some insights that are hurting, which is precisely why we are doing this.

This year, I have to say, I’ve been amazed at how rapidly our business is changing. We started an agile presales approach “Agile Business Accelerator” in 2018 with the expectation that about 25% of the market would demand iterative approaches. However, during the customer interviews, we discovered that all the customers we interviewed required an iterative, business-generating approach.

Customers presented this in their style and the culture of the companies rather differently. Oftentimes, they don’t even use the word “agile”. I consider this to be very valuable, business values are needed, and we find a suitable methodology together.

Thank you for your commitment and openness!

Generative

About transparency

Some years ago, I attended an inaugural lecture by a division head in which she analysed current figures from her reports, identified discrepancies and resumed. She concluded that these discrepancies indicated deliberate cover-ups. A circumstance that she will change. Because only a transparent system is able to provide people with the opportunity to act in a purposeful way.

I endorse the last sentence with all the knowledge and experience I have. Cheating, estimated figures or sloppiness combined with an 80s “management by objective” apparatus are the best possible nursery ground for mismanagement. At the very best, they cause frustration in individual areas, when everything fits according to the specifications, but the overall result is poor.

My own example above, by the way, did not end well; a new system was created that was consistent above all. This could be observed closely in the defects that were subsequently closed. I cannot say whether the original intransparent system was created intentionally. But I am very sure that the new system which was created aimed at concealment.

Now, there are certain areas where transparency is not permitted. Reasons for designated restrictions on transparency are, in my experience, Almost always fabricated. “We can’t give you the current figures, as you know one of our parts of the company is listed on the stock exchange.” When systems strive for transparency, it usually has a very different ring to it: “We want to better understand how our services are viewed by customers, so we compare x-and-y. The listed part of the group can only be included in the analysis in such-and-such way. But we are continuing to work on possibilities here as well.”

It’s about what you want to measure and what you can measure. People who understand Lean or Agile know that it’s a journey. Establish metrics which really move you forward, and in the best case these are lead-measures. Not forgetting to use the existing possibilities of “what you can measure” creatively and to create better chances.

In my experience, real good transparency is always a journey, not something you can finally achieve or even set by decree.

Transparaenz

Why I like visions

Often, visions come with a bad name. Some even see them as irrelevant decoration. This is true for many visions. You can find global-galactic versions, all-encompassing more-beautiful-further-faster editions to preposterous visions that are essentially meant as a kind of misleading advertising.

In my experience, managers who don’t think much of vision can very rarely say in a nutshell what direction they want to take. When asked about the direction, they typically say something about making money in the industry in which they work. But customers don’t buy from me so that I can make money. Money is the compensation for something that is worthwhile.

Having visions can be a particularly good North Star. In programmes or projects, a half-day vision workshop is definitely rewarding, especially if the project is under time pressure. The people involved then know where they stand and have fewer wrinkles on their foreheads. They decide more often in a concerted direction. When problems arise, the alternative options for solving them are usually properly pre-sorted.

Visions are directional for every kind of team. Newly formed teams find themselves together more quickly. Teamwork has fewer friction points. Especially when the business is in transformation, people find anchor points.
Even visions that are too specific and too near prove to be helpful. Especially because dealing with the destination together contributes to team-building. With some guidance and time, dealing with vision, mission, company purpose, values, etc. becomes more and more professional.

For practice, it’s best to think about yourself: What do you want to achieve? How do you want to succeed? Why do you want exactly that? Just like above, the first answer to such questions will be a solid “Um, uh”. And that’s a start!

Spitzer Bleistift

A matter of blame

In my professional experience, I had the chance to work for a while as an escalation project manager involved in several projects that suffered from substantial imbalances. I was usually called in, at very short notice and had to get a clear picture of the project and the current situation in just a handful of days. It often disturbed my work when my time was wasted in initial meetings with mutual finger pointing. The topic of “blame” never got me any further, because it is more likely to cause losses for the projects – and yes, I am talking about blame eats real money.

The most remarkable instance was a project in which three providers had to implement a long overdue migration for a customer. One of the providers was our company. Several milestones had been missed, we had to pay contractual penalties and the go-live date seemed hopeless because almost nothing was done.

The project was managed by an external project manager who explained to me in great detail that the three providers were not working together and told me many stories. After the third or fourth anecdote, I asked him what he had done to remedy the situation, but he did not give me a clear explanation. Which was not a good omen.

Together with the representatives of my own team and the other two providers, there were massive finger-pointing disputes. Within the team as well as outside of it. These discussions went on and on. I hardly managed to find a way to discuss the most important next steps with the parties involved or even to draw up a battle plan for the next few weeks. Again and again it was a matter of blame. At some point the idea crossed my mind, which I actually said out loud, “OK, I’ll make myself available as a scapegoat, I’ll take all the blame!”.

The next 4-5 accusations – which of course came up – I accepted and said, “Stop, I’m the one to blame, that’s what we agreed” and such discussions came to an end. I did the same with colleagues from the other providers who were typically our competitors in other bids. This enabled a bit more focus to the large project group. So we had enough material and discussed the most important issues in a smaller group on the next day.

Apparently, a crucial obstacle had not been addressed in the project, the customer’s contribution was lacking everywhere. That’s why even the teams that could have worked independently were stuck. It also seemed strange to me that contractual penalties were paid even though there were almost no contact persons named on the client side.

The project manager told me that he was not responsible for this, he explained to me in many words why this was not covered in his mandate. I was already fed up at this point, so I met with the other two providers and went to the client. With the help of sales we had high ranking contacts who were shocked and provided (slightly) better support as well as stopping the penalty claims immediately. This was actually due to a bit of luck, a moment of surprise and, above all, the well-connected sales department.

The next day, the project manager entered the office with a bunch of papers – which turned out to be his contract – and wanted to explain to me in writing that he was not responsible. I was sure he was in for a bad surprise already. I asked him if he really wanted to explain, that he was not responsible for a monthly saving of a lower 5-digit amount on behalf of his clients.

All three of us providers were able to reasonably save the project together. Somehow a good esprit de corps evolved quickly in the project. We dismissed the project manager in unison from his contracts and – each in his own organisation – replaced some team members to the best of our ability or filled them in with freelancers. After that, we worked jointly, took care of each other’s tasks, provided test systems and managed to get the project done almost on time. The necessary approvals were obtained just in time, mostly on beta releases, version 1.0 could only do the most essential tasks and the final version was 6 weeks late.

An initially very upset head of department from the customer eventually helped to ensure that the 6-week delay was probably only noticed by a few end customers. Everyone was proud of the work and competitors thought it was sad to wave valuable colleagues good bye at the end of the project.

However, I wanted to write about blame. The blame game didn’t help us at all. And when I think about it, the people who fighted on blame the loudest were those whom we had to exchange. Not being guilty and blaming others often translates in not willing to take responsibility.

I have used this line “OK, I’ll take all the blame!” many more times. Because I never experienced in any of these problematic projects that there was really that one person or department to be blamed. The closest thing to “blame” I have experienced is incompetence. When companies send people into projects who don’t have the necessary professional competence, that make massive mistakes, then again we’re not talking about blame, but a lack of professionalism.

Blame almost always leads to unaccountability, which is often combined with financial harm. There is actually a type of employees who don’t care that their company is losing money. The problem is not their fault, after all, but someone else’s. End of story for the mindset of such persons.

Projects and organisations that cultivate blame as part of their culture are in fact zero maturity in most maturity models. There is a good reason for this, not only because it sucks to work there, but also because blaming is like an anaesthetic for progress. Striving for efficiency or even innovation is not wanted in those organisations because exploration always brings risk, errors and failure.

You do indeed find this kind of culture in projects more often than you think. Usually as a kind of senseless scapegoat principle, the blamed parties don’t actually have to fear any serious consequences, in the next project they sit on the other side of the table and then they nominate the scapegoat.

If people need a scapegoat, that is perfectly understandable, but it is simply a lack of culture.

What did I take away from that time?

  • Blame is neither productive nor does resolve problems.
  • A scapegoat culture encourages non-responsible behaviour, which always costs money. Lack of efficiency is also expensive.
  • Unfair blaming is a gigantic demotivator for project workers
  • A history of ignoring or killing the messengers is a huge burden for projects. Problems never disappear, but messengers get quiet. Late phase problems cost a lot of money. Try to get their trust back.
  • In complex projects or in projects that progress empirically, mistakes are inevitable and must be used as a driving force. Blame has no part in this.
  • If you succeed in looking at the big picture, many a “not responsible” party will turn into a quite capable project worker.
  • Winning trust can even motivate an employee who has been beaten and kicked by his management as a scapegoat. I succeeded once, this good man was 15 months short of retirement, which made me very happy.