It’s Always a People Problem

At first I wanted to write about something else today, but then I came across three interlinked blog posts, that I couldn’t resist sharing. And the title is fittingly lifted from the famous quote:

The Second Law of Consulting: No matter how it looks at first, it’s always a people problem.

Gerald Weinberg – The Secrets of Consulting
People captured from behind standing side by side, looking at the sun setting in front of them

The first article rediscovers this truth about technical problems becoming people problems:


Perhaps you’ve heard of the OSI model of networking, where you have seven layers as a way to talk about what’s going on in the “stack”. I’ve seen some brilliantly snarky T-shirts that talk about “layer eight” and sometimes beyond as things like “corporate politics” and “management” and all of that good stuff.

It turns out that when you start doing this root-cause analysis and really keep after it, the “squishy human realm” is actually the no-longer-hypothetical “layer eight” from those T-shirts.


More than five whys and “layer eight” problems –

It doesn’t really give any “solutions” to the problem, but links another great article, on how the people working under you, can easily read your mind, sometimes even better, than mangers can understand themselves. The author presents three ways to tackle part of the people problem:


Who can, and sometimes does, un-rot the fish from the bottom? An insane employee. […]

When does the fish un-rot from the top? When a manager is taught by experience that (1) neglecting this thing is harmful and (2) it’s actually hard to get it right (that is, the manager himself, or someone he considers smart, tried and failed.) […]

Managers who can’t make themselves value all important work should at least realize this: their goals do not automatically become their employees’ goals. […]


People can read their manager’s mind –

At the end, the post quotes another, quite a bit longer, and very brilliant post. I highly recommend to read it in full, as there’s quite a few absurd scenarios, that I can totally see happening at companies, which made me laugh and sad at the same time. The post also goes into more details on how to approach organizational (i.e. people) issues.


The data are clear that humans are really bad at taking the time to do things that are well understood to incontrovertibly reduce the risk of rare but catastrophic events. We will rationalize that taking shortcuts is the right, reasonable thing to do. There’s a term for this: the normalization of deviance. It’s well studied in a number of other contexts including healthcare, aviation, mechanical engineering, aerospace engineering, and civil engineering, but we don’t see it discussed in the context of software. In fact, I’ve never seen the term used in the context of software.


Normalization of deviance –

I often say, that the hardest problem is communication, and I don’t just mean, that it can be very difficult to package something, so the other side actually receives the meaning and intend of it, but I also mean, that it’s really hard to know, what to communicate and at which point in time. You don’t want to bother your team with problems, that you as a manager should be solving, but you should be signaling, that there might potentially be an on going issues. Or on the flip side, your boss is probably not exactly interested in the technical details of all the roadblocks you’ve run into, but they do want to know, that there’s a potential larger delay coming up. When do you say what?

Having and putting trust for and in either side requires truthful communication. As a manager, explain your reasoning for pushing a certain topic. Remember, people will read your mind anyways, if you try to deceive them. As engineer, invest the time to understand the process and reasoning, before jumping to conclusions and taking on a defensive position.

Leave a Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.