Growth advice - All advice is about context.

01 Nov 2015

I worked in multiple companies in my live. I saw reasonable high evaluations of eight digits and more. I’ve had ample opportunity to examine organisational voodoo, and surely you have seen incomprehensible things happen in companies, too. Great design decisions, good management styles, innovative IT architecture, and all their negative counterparts. Growth advice will be my section to talk about the trapdoors of growing a business, and how to avoid them.

Listen to others

Founders read life changing books, managers receive invaluable advice from god knows who, blog posts are read and ideas are being had. It’s a good thing. In the scope of startups founders and likely also managers have little to no experience in what they’re doing. Imagine you would have never read a single instruction manual or piece of advice - a surreal thought. Luckily, startup culture is not just inward facing and exclusive. It’s about sharing your experiences as an organisation with the world and collaboration.

Some of the greatest startup success stories of our generation are renowned for their willingness and commitment to share their internals with the world. Google greatly contributed to the worlds understanding of OKRs and large scale operations. Spotify spilled their guts on how they use tribes and guilds and other means to foster collaborations between departments. The list goes on, but you get the picture. This is all valuable input and worth a read.

Some of these thoughts can be applied in all organisations with little adjustment. However, just like the instructions and manuals you’ve read in your life, not everything is actionable advice - Zappos’ highly controversial Holicracy comes to mind.

Understand what they say

The common denominator is context. Situational context as well as the context of a shared vocabulary. Assembly of your Ikea Pax becomes easier if the guy who wrote the instructions understood your predicament and used words you can understand. Similarly, books about Python just become so much more interesting when you’ve coded in Python before and understand computational concepts.

This translates to any advice you’ll ever get. Understand the context it’s given in. Understand the caveats. Relate it to your situation. Apply or discard.

Let’s look at some examples and their risks - I’ll boldly assume you’re familiar with the concepts.

Google’s OKRs

Being a new spin on traditional goals and targets for departments and employees OKRs can go wrong quickly. Pushing employees to strive for 50% more than what’s reasonable to achieve can trigger fight or flight reactions. Picture it - you’re in gym class again, barely finishing your tenth push-up, and the coach yells at you to do it again, but 15 instead this time.

This is context. Trying to do more might not work out (there’s a pun in there somewhere), but you’ll gain strength for next time. De-couple OKRs from performance evaluation. Thoroughly explain that they’re about possibility for individual growth, collaboration on interdisciplinary projects and failure won’t be punished. Guide people to a common understanding on how to derive meaningful objectives and key results. Take away concerns and fears so everyone can focus on what it’s all about.

Google’s SRE team

In one of the largest and most complex engineering departments in the world the concept of Site Reliability Engineering works well. SRE’s shall spend 50% of their time on code, microservice all the things, downtime budgets. It won’t work for your garage startup. It probably won’t even work for your startup on its first round of investment, as this is purely about scale. When Google introduces a new service in its ecosystem its hit by millions of requests per second. It needs to work regardless of location or surrounding infrastructure, and hundreds, if not thousands, of engineers might depend on it. Unless you reach that scale, abstract the lesson that it’s a good idea to foster collaboration between Devs and Ops.

Spotify’s organisational setup

You’re handed a task: “Please make sure all our teams, everyone of our 1600+ employees, in all 20 offices worldwide to feel connected”. Spotify found an approach to do so. A sole frontend development department from New York can’t wait until the sole UX department in Stockholm had the time to do user testing on a new feature - that’d be wasteful. Bundle a designer, two web devs and whatever else you need in a squad to gain speed. Bundle a set of squads in a tribe to keep control. Make sure designers stay aligned by dividing disciplines in chapters. Allow everyone to contribute to topics they’re interested in by sponsoring guilds. See which step solved which problem? Apply it to your organisation, but not blindly, as not every discipline needs help to stay aligned.

tl;dr

Whenever you read how company X solved problem Y in a unprecedented way apply the following guide:

• What’s the context the problem was solved in?
• What could go wrong outside this context?
• How does the context relate to your situation?
• Profit!