As of this Monday, I’m now officially the CTO of the Danish startup IconFinder, a task I’ve been looking forward to taking on me for almost half a year now. This is my first time running all the shots in the technical department of a company of this size and with these expectations, and naturally this brings with it both equal parts excitement and fear. Excitement about the opportunity to “do things right” after having spent two years on the other side of the table, and fear of failing at delivering on exactly that promise — to both the company but, more critically, also myself.

The first step in avoiding failure is to try and learn as much as you can from everyone else; what has and hasn’t worked for them, and what solutions have they wound up with. Five-ten years ago this would have been a very difficult task and the outcome of such research would have probably been a lot closer to general management thinking than what is beneficial for a startup or any company trying to innovate. Somewhere along the line, this started changing, though. A trend that seems to start with Google publicly talking about their experiments with the now infamous “20 % time,” which has cast off successes like Gmail, spurred an increasingly vocal discussion about the importance of being “a great place to work” and “working great.” Companies like 37signals have added more fuel to the fire with their provocative experiments and claims, and more recently GitHub has made popular what will probably be their longest lasting legacy; the “asynchronous workflow.”

These three companies are only the tip of the iceberg. In fact, there’s now such an abundance of descriptions of and recipes for The Best Place To Work™ and The Best Way To Work® that it seems almost too easy. Pick a successful company and mimic what they’re doing. Hell, if four day work weeks and letting people work on what they want works so great, why not make them standard business practise?

The truth is of course, that this will never work. I’m not David Heinemeier Hansson, and Zach Holman won’t be one of my first employees. I’m Nick Bruun and someone else will be at least as awesome an early employee. That doesn’t mean that these ideas won’t have merit for IconFinder, but simply that they will not be directly applicable and that an attempt at trying to fit the company into this “best practise frame” will most likely hamper the company rather than benefit it, no matter how tempting it is. In many ways, I find this to be analogous to the problem Nick Pollard describes with code standards:

Even worse, coding standards are stasis. By locking yourself in to a particular point in time, a particular way of thinking, you get stuck in one exact form. You get left behind. How often have we seen a big company get locked into some ‘best-practice’ only for a startup to run rings around them because they don’t have a ball and chain tied to their leg? Some new technology is invented but not embraced, because it doesn’t fit the one true way?

So, while mimicking and standardising is a tempting solution to a problem — management — that seems like it only takes focus away from doing real work, the truth is that we need to approach this area just like we approach product development. Nick Pollard hits the nail on the head with his code standard, and I think it really isn’t too far from what we should or at least what I will actively be striving for in every aspect of a company:

Simplicity.
Brevity.
Elegance.

The rest is up to you.