Disclaimer: This post if full of stereotypes and simplifications. You have been warned.
Devs, for some historical reasons, are still assumed to be anti-social nerd creatures, that we need to teach so-called soft-skills so we can have a chance for civilized cooperation. From my experience it is often the other way around. We leaders (managers, HR business partners, work organizers, decisions makers) could learn a lot from developers, who managed to build an amazing work culture. Here are 3 things that I believe would bring the most ROI if adopted outside the IT teams.
Feedback FTW!
Devs could teach you and me how to give & receive feedback on the quality of our job. They might lack the subtlety of NVC, but the fact is, that feedback is ubiquitous in the devs world. In fact, by the process called code review (or, even better – pair/mob programming) they get feedback on every line of code they produce. Let it sink in: every single line, no matter how seemingly unimportant.
Now, imagine doing the same things you currently do every day, but the “devs way”:
From now on everything you do is being checked and commented on by your peers before it sees the light of day.
Imagine this, really imagine how would it be to receive feedback on everything you do. Every email you write, every report you prepare, every decision you take. Imagine it is being checked thoroughly, commented on, and the corrections are required before you are allowed to go live with it.
And now, read few emails and documents that we, the oh-so-smart leaders, produce. Do you think that they would improve if we put them through a similar review process? I bet so! We would end up with much more concise & precise & comprehensive sources of information.
Real life situations to illustrate the gap between “the best and the rest” when it comes to feedback culture:
- I once observed the work of a team of truly creative graphic designers. Hm… when it comes to feedback… well… hm… that felt… different. Let me say that the last thing they expected and appreciated was feedback on their work!
- I’ve heard HR talking about “feedback culture” a lot, but I’ve never seen them getting any close to what devs are doing everyday.
No, I’m not saying that devs are the best feedback-givers/receivers in the world. In fact, there are some areas which they struggle to feedback.
Surprisingly, most devs I discussed this topic with, seems to be pretty unaware of the fact, that code reviews are feedback. What can I say? Well, fish can’t see water. 🙂
Redundancy is Evil
Another thing that we should borrow from developers is the idea that each piece of information should be in one place, and one place only. This guarantees that when we change it (and things change, that’s a fact) we won’t end up with several versions scattered all around the place.
Devs are pretty crazy about this, and for good reasons. For example, you wouldn’t like your finance software to keep VAT rates in many places so that after VAT changed some calculations would still use the previous values, right? By keeping such information in exactly one place, you make such mistakes almost improbable.
And now, compare this to all the information channels that organizations use. Think about all the places where vital information could show up. Intranets, and wikis, and gazillion of slack channels, and comments in online docs, and comments in issue trackers, and emails, and message boards, and whatnot. How often are the supplementing and even contradicting each other? How much time and effort is needed to find the latest, coherent & comprehensive description of some important process that was recently updated a few times?
Following the “one place” information policy would save all of us – who try to be up-to-date with the changing requirements – a lot of time and frustration.
Continuous Improvement & Learning on Mistakes
Developers are crazy about learning and improving their way of work – both on personal and on team level. I already mentioned code reviews, but they have many more tools in their toolbox – e.g. pair & mob programming, communities of practice, and team retrospectives after each finished sprint (usually every 1-2 weeks). They analyze what they did and how they did it, they look for better ways, they gather experience and learn from their mistakes. And they aren’t shy even about the grave mistakes! Take “post-mortems” which are published after every production f***-up incident so that others can learn from their mistakes.
And now, compare this with what the outside world:
- Are mistakes discussed publicly or rather swept under the rug?
- Retrospectives? Err, no, no time for this. And if any, then at the very end of a (failed) project, so there are pretty meaningless.
- Gathering feedback after a failed organizational change? Err, no, not really, thank you, why should we?
Summary
Be like devs.