A Recurring Theme
Sometimes you read books that are so good that you re-read them multiple times.
“Peopleware” by Tom DeMarco and Tim Lister is such a book.
The theme of the book is that most problems are people problems - not tech problems. And this is true today - as it was true in 1987 when the book was first published.
Often inexperienced leaders in tech try to solve everything with technological solutions. And fail miserably. Let’s check out some real world examples where people are more important than tech.
The Aristotle Study
Google has many teams. But why are some teams performing better than others? What do highly performing teams have in common? The researchers at Google ran a large study called “Aristotle” to find that out.
According to them it is about five areas:
- Psychological Safety
- Dependability
- Structure and Clarity
- Meaning
- Impact
Close to none of these areas has to do with technology. It was not about “go” is better than “C++”. It’s really about people and teams.
Takeaway from Aristotle: Neglect the people side of things and you’ll fail.
Collaboration Within the Company
In one of my projects we had problems with Customer Support and Engineering working together. Customer Support was always complaining and frustrated by Engineering. Engineering was frustrated by the constant nagging of Customer Support. Engineers and Customer Support folks escalated each and every ticket and people even quit over these quarrels. Nothing really got done.
Long rounds of meetings and discussions erupted. A new ticketing system was introduced. New processes introduced. But nothing helped. It was a pain for everyone involved.
We then set out to create a one-day workshop with everyone from Engineering and Customer Support. All employees were on-site. We had great presentations. Engineers outlined what they were doing. Also why there were bugs from time to time. Customer Support also presented interactions with Clients and what bugs meant for them. Everyone was listening.
After the workshop both departments went to a bar and continued their discussions there. It was a great day and the feedback was very positive.
But even more importantly: All problems between the two departments were all but gone after that workshop. There was mutual understanding for the other side. It was a people problem after all.
Don’t fix with tech what you can fix with a night at a bar!
The Fearful Department
A while ago I was dealing with a tech-department that did not release. Engineers were very conservative and absolutely did not want to break production. Release cycles were painfully slow and nothing got delivered. After a QA round came yet another QA round.
It was really strange that nobody wanted to deliver.
After talks with the engineers it became clear what the real issue was: The former VP Engineering punished engineers for their mistakes. She even shouted at engineers and people quit over that. The engineers that stayed did everything to not cause any trouble and not do any mistakes. They learned their lesson.
The downside is: Nothing is being delivered.
We were able to change that by announcing that “Mistakes are absolutely ok - as long as we do not repeat the same mistake over and over again”. We also introduced Post-Mortems to follow-up on potential incidents.
This unleashed the productivity of the engineers and the amount of newly released features went up sharply. Everyone was happy. And nobody shouted. No superior testing or CI framework could have fixed what we fixed with our announcement and Post-Mortems. Look for people problems first - and tech problems second.
Conclusion
Don’t overestimate what you can fix with technology - and never underestimate how important the social glue is in your department. And of course read “Peopleware” by DeMarco and Lister.
More
- Awesome photo on top by Jacek Dylag
