"Building a great culture" sounds like one of those HR webinars that you are compelled to watch, usually like this:
But as much as I like to make fun of Corporate Valuespeak, I have observed that if you want to like where you work, you either take conscious steps to create that environment, or "culture happens", and not always in a good way.
I've had the chance to work for 4 person startups in a garage to 100,000+ people enterprises. The places I've enjoyed the most are the ones where the leaders made a conscious, sustained effort to establish a set of shared values.
When they did this, they spent a lot of time outlining the value in specific terms, but left how that value was expressed up to us. They repeated the value and it's specifics until we could see how the values manifested in what we did. Once that happened, we started to own that value, and we carried it forward.
Recently I had the chance to make my own conscious effort to set up the values I wanted to see in the organization I was a part of. I was giving a presentation to the engineering team. Lunch was served, so I had a captive audience. I called this presentation
Because as the new guy, I had the freedom to question assumptions and make assertions that I wont be able to as time goes on and I become a fully integrated team member.
I chose the term 'Core Operating Principles' to describe the culture I wanted to be a part of because I wanted to establish a set of guidelines for how we act and what we do in our day to day work.
Principles are about execution, which is where I feel we - like every other engineering team in the world - have room to improve.
I wanted to focus on principles of execution, not precise, detailed execution steps - because principles scale, instructions don't. Principles can be applied as a heuristic, detailed instructions cannot.
I also put a version number on these Core Operating Principles. I love version numbers because they indicate that what is versioned is really a work in progress, not a final statement. I'm 100% sure that these will get refined over time.
Here they are, v0.1:
- Strive for Simple - the simplest possible solution wins, at all times. Simple scales, clever doesn't. Simple != Hacked together. Work still needs to meet the Definition of Done.
- Don't Solve Solved Problems - we have so much work to do here, what should we focus on, and what should we leverage other solutions for? We should strive to build what is our core competency, and where possible, outsource non core functionality that is commonly available.
- The Best Idea Wins - no matter where or who it comes from. Assert your idea, and defend it, and let the best idea emerge.
- Disagree But Commit - if you've been unable to convince everyone that the idea they want to do is flawed, disagree but commit to implementing it. That way it will either fail or succeed much faster than it would if you were passively resisting it. I've learned the most from disagreeing but committing. Mostly I've learned that I can be wrong in many different ways....
- Why Not Who - when things go wrong, focus on why they went wrong, not who made a mistake. Ask 'why' until the root cause is discovered, then make necessary changes.
Now comes the hard part - putting these principles to work, refining them, and most importantly, owning them as a team.
In order for the team to buy off on those principles, they need to pick them up, try them on, apply them to specific situations, and see the value.
We've had some initial successes, which is really nice to see. But in order for these to stick, or more importantly, evolve to better principles, we need keep being intentional about them - invoking them as a compass, to guide the decisions we make and the work we do.