I stumbled upon this bit of wisdom in Team Geek: A Software Developers Guide to Working Well with Others, and it resonated. It comes from Google engineer Chade-Meng Tan:
Do the right thing, wait to get fired.
New Google employees (we call “Nooglers”) often ask me what makes me effective at what I do. I tell them only half-jokingly that it’s very simple: I do the Right Thing for Google and the world, and then I sit back and wait to get fired. If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win. That is my career strategy.
This requires you to have confidence in your judgement, to assume authority and responsibility, to make decisions, to take risks – in other words to do what you have been hired to do!
You’ve got to recognize that companies are schizophrenic. They build process, and rules, and structure and they ask you to follow them:
- “Employee evaluation is done this way…”
- “The rules on conferences attendance are as follows…”
- “Products are to be QA’d and deployed in this manner…”
- “New projects require the approval of the following people…”
In general these rules are better than the alternative – no guideposts or structure. They help new managers and teams to function effectively. They push employees to do things in a good way.
But greatness rarely happens by following rules, process and structure. That is why companies also want to find employees ready to take risks, make decisions, try new things, move fast and even break things.
This means recognizing when the process is too heavyweight – and a simpler alternative is better in this case. It means making the call to assume some technical debt or operational risk because getting this new product/feature out to some real customers for feedback now is most important. It means approving an over-budget trip for a particular employee to a conference they’re passionate to attend. It means setting aside some time to work on your idea for a new tool that will help the support team to diagnose customer problems. It also means slowing down to refactor something – even if it means hurting your reputation for getting things done quickly. You do this because it’s the right thing for your team, your company, and/or your customers.
When you break rules, and do what you think is the right thing you are taking a risk. Sometimes this will pay off, sometimes it wont. It’s ok to fail – but try hard not to fail repeatedly at the same thing or for the same reasons. Know when you’re taking a risk, and learn from the outcomes. The best engineers and managers I’ve known have all been willing to break rules and take risks. You should too.
Update:
Follow the discussion of this article on Hacker News or the discussion of this article on Reddit.
Leave a Reply