Operating Handbook — A Quick Summary

Recently I spoke to a large audience at Disruptive Innovation Summit in Schengen, China on topics of product, technology and running the team from prospective of an engineering executive. I may have surprised an audience with an assertion that the execution (and the engineering function) is (A) is not nearly as important to the overall success of the company as the product function and (B) is not particularly difficult to get right. Let me perhaps rehabilitate myself by pointing out that: Execution does matter. While a poor execution would rarely kill a company if the idea was great — it could certainly mean the difference between a 10B or a 20B company and a 300B company. Imagine you have to stop and re-engineer your systems just as your product takes off? It is a lot simpler said then done — in part because of the culture of the organization and our natural human biases. Over the years I have adopted an operating framework that has worked for me so far. In brief it is about: Outcomes Bottlenecks Transparency Flexibility Culture Outcomes As the old saying goes — if you don’t know where you are going — any road will do. It is particularly true within large, complex organizations where goals, successes and failures may look differently depending on a vantage point. It is therefore even more important to spend some quality time with your staff to develop and refine the strategy for your function and your team. Surprisingly it is nearly always about just one project or one particular outcome — as long as catastrophic lapses are avoided everywhere else. Stack rank your projects linearly without cheating and staff them in that order with your best people. Learn to live with inefficiencies. The last one is particularly hard to do. Bottlenecks The #1 book I recommend to all my reports to read is a business novel by Eliayahu Goldratt “The Goal”. It was first recommended to me by a boss of mine some years ago. Read it tonight if you haven’t! Focus on your bottlenecks, ignore everything else. Those could be yourself, your direct reports, a specific engineer or specific organizational function or inefficiency. A tip: Scaling the organization There’s no difference between a first line manager passionate about his or her teammates and a VP passionate about his or her reports. Treat your executive team as a good first line manager would treat his or her team. Transparency I’ve found over the years that it is important to tell people what your priorities are honestly and frequently, at least once a week. Don’t be afraid to tell people (and especially your direct staff) what you think is important to you right now and what you expect — as directly as possible and as often as possible. Don’t be shy! A tip: Ruslan’s Top 5 In full disclosure I learned it from Dick Costolo (then CEO of Twitter) who had his Dick’s Top 10 list. Obviously that was in addition to quarterly OKRs :-) These were 10 things important to Dick and those could be as big as a priority project (i.e. around growth) or a bug that Marc Andreessen emailed him about. I have shortened my list to 5 to be able to practically discuss it at every staff meeting and like Dick’s — those were 5 top things important to me. A tip: How do I run my staff meeting? I have sat in many executive meetings — I am sure you have to. Think back and see what you liked and didn’t like about them? Flexibility Organizational structure is not US Constitution. It is simply a tool for the job and there is no perfect org structure — but there’s an appropriate one for the timeframe and the objective. Evaluate yours often. Is it still working for you? Do a retrospective on it once you change it. A tip: how do you decide whether to go vertical or horizontal? Culture Everyone loves self-running organizations — isn’t it nice to be able to go on a vacation and not worry about stuff? But how do you get there? Understanding who would replace you in case you were hit by a bus is one. Building a learning organization is the second part of the puzzle. Embed retrospectives (also called post-mortems when bad stuff happens) into everything you do: Site outages 2. Unexpected growth or other good things 3. Re-organizations 4. Termination decisions (I would do that one with myself everytime I had to part ways with an employee) 5. Process changes 6. Milestones 7. End of period Run them exactly as you would run a post-mortem — objectively focusing on the timeline (draw it on a whiteboard), the impact (good or bad), the root cause (of good or bad) and the next steps (corrective or enhancing). A tip: a role of chance Why some people succeed at one job and fail at another? Surely all of us either experienced it or have seen it frequently enough. Natural human biases tend to attribute successes to our genius and failures to circumstances beyond our control. Is this always truly the case? Is your star employee really a star employee or just experienced a fortuitous sequence of events? Is your “underperforming” employee is truly underperforming — or was it just an impossibly bad setup? Should you worry about it at all? I found the basic idea of retrospectives to be particularly applicable to above scenarios, especially when evaluating performance and when considering organizational changes. Fail to do so and a chain of poor decisions will follow — usually accompanied by a hit to moral of your staff. There is always more to cover — hiring, managing remote teams, working with different functions across the company — product, sales, marketing and more. I hope however that you have found some connection or a way to relate to the prospectives in this note — and if you did — I would love to hear your thoughts!