Searching for geek heaven

We’d love to love our jobs. To the point where we can’t stand how long a weekend is, before we may go back to work on Monday. Utopia? Not at all. I know people who genuinely love their jobs, who found their geek and non-geek heavens. And I have my own criteria for evaluating companies I would consider joining.

There are three qualities that combined would make a company a Geek Heaven:

  1. IT is central to business,
  2. everybody has someone else to learn from, and
  3. there’s a non-monetary reason for the company to do what it does.

IT is central to business

Has your department ever been called a “cost center”? That’s another way of saying “we will outsource your work to <insert cheap labor country> as soon as you start asking too much money.” You are disposable. A cog in the machine. But the ramifications here are so much broader, because if IT isn’t the driver of business, then all IT decisions will be monetary decisions.

  • there’s no point replacing a stone-age era technology, as long as it works,
  • there’s no point speaking at a conference, because that’s a cost that doesn’t contribute to business,
  • there’s no point contributing to open-source projects, because again it’s a cost with no return (oh, but we’re happy to use free, open-source software),
  • and so on.

On the other hand, we can easily name companies that heavily rely on their IT for business success. Google, GitHub, Etsy, Netflix, Spotify… We know them, because they’re very active members of our community. They speak, share, collaborate, contribute, while internally, each one of them is pushing the boundaries of their technology.

You want to be at one of those places, where each and every day IT people ask themselves “how can we make this better?“, and the business people answer by asking “how can we help you?

Everybody has someone else to learn from

I was never the smartest guy in the room. From the first person I hired, I was never the smartest guy in the room. And that’s a big deal. And if you’re going to be a leader – if you’re a leader and you’re the smartest guy in the world – in the room, you’ve got real problems.

Jack Welch, interview at Piers Morgan Tonight, CNN, June 2011

Jack’s right, and his words apply to everyone – not only “leaders”. You always want to be around people who are better than you. If you dig through the stories of most successful people, they always reference somebody who inspired them, who they learned tons from.

You want to work for a company that has a diverse set of top-notch specialists. People passionate about their work, who continuously pursue mastery. People who’s contributions will inspire and motivate you to develop your own skills. People who will be happy to share their knowledge.

Non-monetary reason for the company to do what it does

The “why are we doing this?” is perhaps the single most important question that is barely ever asked in a work environment. And when the answer mentions “shareholder value” or “sales increase”, it’s a dead end. Money is very uninspiring. Sure, it’s motivating, but for all the wrong reasons:

The goal is not just to hire people who need a job; it’s to hire people who believe what you believe. I always say that, you know, if you hire people just because they can do a job, they’ll work for your money, but if you hire people who believe what you believe, they’ll work for you with blood and sweat and tears. [emphasis mine]

Simon Sinek, TED Talk: How great leaders inspire action

Simon’s talk is well worth watching to understand how much the “why” we do things matters. You should also grab his book “Start with Why” to dive deeper into the matter.

Too many times important initiatives are explained in monetary terms, which don’t mean anything to most people working on them. If the company makes an extra million, are we actually going to receive any of it? Not likely.

What you want instead is a business pursuit you can believe in – big or small, like getting the world rid of malaria, or making awesome tools for developers. You want to be part of something good being done for others, where money comes back almost as a side effect.


If you look at Maslow’s pyramid of needs, the three qualities above align precisely with the top two layers of Esteem and Self-actualization:

Maslow's hierarchy of needs

It goes without saying, that in order for a company to become a Geek Heaven, the bottom layers need already to be catered for. You certainly won’t feel any good working at a place, where you may get fired any minute, you’re getting peanuts for your work or which is physically unsafe.

A lot of companies these days do very good on the bottom layers of the pyramid, but very few succeed in the upper ones.

Why does it all matter?

Our work as geeks relies on creativity – finding novel ways of tackling problems in a world that’s impossible to describe in ones and zeros. Every single day we’re fitting square pegs into round holes. Creativity is a shy creature though, that only shows up when we’re comfortable and content, at what psychology calls “cognitive ease”:

[G]ood mood, intuition, creativity, gullibility, and increased reliance on System 1 [intuitive, automated thinking] form a cluster. At the other pole, sadness, vigilance, suspicion, an analytic approach, and increased effort also go together. A happy mood loosens the control of System 2 [analytic, logical thinking] over performance: when in a good mood, people become more intuitive and more creative but also less vigilant and more prone to logical errors. (…) A good mood is a signal that things are generally going well, the environment is safe, and it is all right to let one’s guard down. A bad mood indicates that things are not going very well, there may be a threat, and vigilance is required. Cognitive ease is both a cause and a consequence of a pleasant feeling. [emphasis, explanations mine]

Daniel Kahneman, Thinking Fast and Slow

There’s a clear business case for building companies, where geeks are happy.

You’re a geek. You’re doing a job that’s highly in demand these days and will remain so for the nearest future. Use that to your advantage and “vote with your feet” for companies that you truly feel great working for. Find the criteria for what makes your very own Geek Heaven, and if you haven’t found it yet, move on.

(Maslov’s pyramid image by J. Finkelstein on Wikipedia)

Developers are from Mars, QA are from Venus

Designed, developed, handed over to QA for testing. Then all hell breaks loose. “How do I test it?” “Where’s the documentation?” “This is broken; not it’s not, it’s not our component.” “I’m not signing this off!” Or my personal favorite: “I’ve other priorities to test now. I’ll get to your stuff tomorrow.” for three days in a row. Keeping QA separate from development teams is a recipe for trouble, friction and lots of missed opportunities. It has to stop.

Once you put a QA Engineer in the same team with developers, sharing the same manager, several things happen:

  • QA shares the same goal with developers – to deliver an excellent product on schedule & budget. No more bouncing tickets back and forth “this isn’t working!“, “it’s not a bug, it’s a feature!” “this isn’t a blocker!” Shared goal, shared ownership, shared responsibility.
  • QA knows product first-hand by spending time with developers as they work, talking over each feature and scenario. Ever tried asking a developer to write a test script for QA? Good luck with that. Sit the QA next to a developer and they can write the scripts perfectly themselves.
  • Testing gets done early and often because QA doesn’t have any other priorities or anyone else shouting louder at them to get their work done faster. User story finished? Alright, let’s see how it works. Right now. And iron out all the bugs right there, on the spot.
  • Testing gets automated when QA sets up Selenium (or any other) scripts together with developers, that they can later re-run as frequently as needed to check whether they’ve not broken something.
  • Developers spend more time coding because they don’t need to setup their own testing data and other environment pieces. QA can do it in parallel and whenever needed.

Sounds obvious if you’re an Agile zealot, right? Notice how I never used the “A” word? I didn’t have to, because the above ideas have nothing to do with the movement. Even Microsoft knew the value [PDF] of pairing developers and testers way before Agile was even manifested.

Testing is not separate from developing. It never has been, but today, when software requirements and markets change all the time, and so does source code, it’s more expensive than ever to keep a QA team separated from development. For the sake of your company’s success, stop doing that now.