As I was writing Programmers really need open floor plans I found myself thinking about a story that I had been confidently telling for years as an example of A Bad Thing, but only recently realized that I'd been completely wrong.
I once interviewed at a product company. It was a long-winded interview process, with many different sessions; at one point I sat with eight senior engineers at once. One thing that I heard was there had been a recent change to sit the Product Managers with the Engineering teams - and many hated the idea. Constant interruptions, scope creep and churn was expected.
This was quite some years ago, and coming from a recent consulting background, I'd heard this before - "keep the Product Owners away from the Engineers so they don't derail the process".
In one product company they'd gone so far as banning them to the far side of the building, and never the twain shall meet.
So at the interview I sympathized and sided with the Engineers, and in the last interview with the VP (who had made the decision to merge product into the dev teams) I repeated that commonly held opinion.
Obviously I didn't get a callback - and quite rightly!
This was an example of too little data leading to the wrong decision. Listening more would have helped, as would have some humility.
What made me remember this story? It was when I deliberately rearranged our Engineering area to sit the Product Managers with the Engineers to help us iterate quicker, collaborate better and get the right products to market faster.
The lesson is obvious - even when you're confident enough to argue your opinion as fact, you may still be wrong.
Contrary to the "get off my lawn" stereotype of the grey haired execs, I find it much easier to listen to (and defer to) other opinions the older I get.
As Albert Einstein said: "the more you learn, the more you realize how much you don't know".
I've never believed more strongly that you must focus on hiring better people than yourself.
Encourage a no-blame culture
Going hand-in-hand with allowing anyone to admit they're wrong, is never assigning blame.
It's ok to experiment and fail, and even better when it's done quickly. Continuous improvement means trying new processes or tools and keeping those that have a net positive impact. Rinse, repeat.
It's not ok to blame people for failing tasks. Assign blame and others will start covering their asses, procrastinating and reporting success-until-failure (that art of everything going perfectly and on-schedule for weeks until the day before the deadline).
- Allow vulnerability - let the team know they can fail and it's ok
- Let anyone admit a mistake, ask for help, say they screwed up or could have done better
- Encourage people to offer help too, without fear of crossing a line, or being seen as critical
- Allow the team to respond to failure, find a solution and move forward
For what it's worth, I believe failing projects are a communication (hence culture) failure more than a technical or person failure.
If you see something that went wrong, take a look in the mirror..