Edu: Startup Planning — Follow the Ten Commandments w/ Oliver Heckmann

Yaniv: The concept of a tool is, it's an external to you that helps you in achieving something. And so a tool is something you use at the moment. The tool uses you, you are the tool. So don't do that. The Startup Podcast is excited to partner with Until Now, an incredible product and brand studio with proven experience in developing successful businesses and brands, including the Iconic, Airtasker, Karma, Spriggy, and Path Zero. We are putting our money where our mouths are on this one. Until Now even redesigned our brand. We think it looks fantastic and we're beyond impressed with the process and people. Whether you're a startup scale up or corporate venture, Until Now runs a cross-functional approach to solving your product, brand and go-to-market challenges. Head to their website for more examples and to get in touch.

Chris: Hey, I'm Chris.

Yaniv: And I'm Yaniv.

Oliver: And I'm Oliver.

Yaniv: And today we're discussing good planning with Oliver Heckman, VP of Engineering at Coda. Before Coda, Oliver had a stellar career at Google that culminated with his being vice president in charge of Google shopping. Oliver was my manager back when we were both at YouTube, and he remains the best manager I've ever had the pleasure of working with.

He's a fantastic leader of people, a deep strategic and organizational thinker, and relevant to this episode. A master planner, Oliver, it's such a pleasure to be reconnected and have you on the podcast. Please tell our audience just a little bit more about yourself and what you do.

Oliver: Thanks Yaniv for the great introduction. I'm, Oliver Heckman. I'm from Germany originally. and at Google I'm sometimes known as Oliver from Zurich because I've spent good chunk of my Google career in the Swiss Zurich office. that's where I worked with Yaniv. but I've moved to Silicon, Silicon Valley eight years ago.

Like, and you've mentioned, I've, uh, worked on YouTube originally and ran Google, shopping and Google Travel, for many years. Left Google bit over two years ago to join Koda, a Silicon Valley startup.

Yaniv: Now planning is something that everyone has to do, but it's so rarely done well. I think it's also very rarely enjoyed. It's something that people just kind of feel have to take their medicine. and so I think this is a really important topic and something that doesn't. Well, I guess it gets discussed a lot, but not in the right ways a lot of the time.

So you've actually made this episode really easy for us by writing 10 Commandments of Good Planning. So what I thought we would do is we'll go through them one by one, but first, maybe just by way of introduction, tell us a bit about why you felt you had to come up with this list and your process of putting it together.

Oliver: There were multiple, actually reasons that led to the list. One was when I joined Koda, I took over the planning process and planning was something I was always fascinated by, so I happily volunteered to run that for Koda. But also our product itself is used by many of our customers for their planning process.

So I also have the opportunity to just learn from our customers how they're doing, their planning. and that led to many ideas and insights that I would've not come up with by myself, but also to many people sharing their problems and their, concerns. and all of that again, culminated in me running a series of events over the last.

Months around planning. And then I got the idea why I could take all the lessons learned from the different events that I run together and cut it down to 10 pieces and call them the 10 Commandments.

Chris: It's funny how, summarizing something in like a buzzfeed list really captures people's imagination. Would probably use the 10 Commandments line in the show name it's really click baby to do it that way.

Yaniv: But they're great. let's just jump in from the top, I love all of them. the first one really talks to me, which is thou shunt plan, both top down and bottom up. So what do you mean by that?

Oliver: So let me start with the bottom up and why that's important. Bottom-up planning is when you involve basically all the employees. Intercompany and planning, that is, especially in a startup, absolutely critical. why would you pay so much money and put so much investment in recruiting only the best people if then you are ignoring.

Their opinions and all their brain power as you're drafting up the plans. that is why bottom up planning is crucially important. at the same time, if you have great people that come up with a lot of ideas of what could be done, and it will be way too much for even well-resourced companies to do all of those bottom up.

So there's a strong strategic element needed in. Giving very clear direction. And making sure that all these bottom-up plans are drafted in the right direction. Nobody's too, massively overcom committed That's why good planning process, involves the top-down motion and the bottom-up motion.

And most good processes need to go top down, then bottom up again, and then top down to further refine and then bottom up again to check that everything is fine. So it's not that you go once. Top down and one bottom up. You tend to go through those motions at least twice and plan.

Chris: We've actually discussed this kind of process maybe twice before on the podcast, particularly, in the episode around managing. Your scale up planning and alignment. and that's absolutely the process we used at Uber and the process I've used at a number of scale-ups I've advised where, the leadership team sets the high level context.

What are the, global business OKRs, if you will, what are the thing we're all trying to achieve? then each squad responds with their squad level OKRs that might contribute to that. And then there is alignment. Review that helps review the squad level OKRs and goals, not just for alignment with the goal, but also for ambition and for collision and for redundancy that kind of top down, bottom up, top-down review little dance, is just so powerful.

Oliver: Yeah, I typically call it what you call alignment phase. The integration phase that's basically when you put all the pieces together and check for overlap and check for the missing pieces help teams not try to do too much.

Chris: And lot of dysfunction you see from companies is just this one bullet, right? They're either doing too much top down with no bottom up or too much bottom up with no context from the leadership, or even they do both the first two, but then nobody in leadership calibrates and aligns.

And so yeah, a lot of dysfunction just comes down to this very simple little mechanic. I love it.

Oliver: Eight second.

Yaniv: It's fascinating. because I think first of all it's often presented as a dichotomy, which is why I, like this commandment, right? It's like, here you have a choice. You either do top down or bottom up. and that's not true. And then, you know, also, once you do that, traditional companies tend to be more top down and disempower the employees, and so I guess more, startup-y sort of companies that looking for a more modern.

Management methodology are often about, oh, we want to empower our people, so we're going to have a bottom-up process. but then what you find is you get that lack of alignment, which we talk about a lot. We've had an episode on alignment that we keep referencing back to, and you just don't have an overall strategy and overall direction that you're going to.

I guess that missing piece, like you said, is, structure. Because if you say, oh, if we have both top down and bottom up, you don't want 'em to sort of crash in the middle in a messy way. you need that structured process. And it's actually, Lenny Rachitsky, our podcast, big Brother, Lenny's podcast, wrote a great article a few years ago.

he called pretty much what you're talking about, the w process. And that's because the way you resolve it is with this sequential structure where you have. Top-down setting of context, bottom up ideation and planning. Then top-down integration and validation, and then bottom up buy-in.

And I think that is really important. So for anyone listening here, this doesn't have to be a heavyweight process. And this is not about leading by consensus everyone has an equal voice, but it's making sure that all the voices are heard and that all of those smart people are able to have input.

Oliver: Exactly. There's one more thing to point out very explicitly, and the, W model expresses that clearly because it's what do you start at top down or bottom up? There can sometimes be the inclination from the executive team to, well, let's do the bottom up first, because then we have all the ideas on the table and then we pick from them.

But that's a very wasteful thing because you have to typically say no to most of them. and also beats typically not well received to plan completely without guidance. much better to give guidance first. So do start with top down. Then do bottom up and then refine the top down again.

Chris: That's so interesting cuz that does happen a lot, a lot, a lot. And what I like to say is that's an act of classification rather than an act of strategy definition. Right. So take all the ideas and they start to classify them into things.

Where strategy is about the elimination of ideas and it's about choosing a very specific set of things to go do. And so you're right, you either end up discarding all the ideas anyway, or you end up just classifying everything and having too much on the table and you haven't actually, that's not planning at all.

Oliver: Exactly.

Yaniv: Okay, let's go on to the next commandment. Commandment two thou shalt not plan for the future without reflecting on the past.

Oliver: Yeah, and that's actually why I will argue, it's actually not a w like we just discussed, but it's actually an m you're typically not starting at zero when you're planning. You just had a previous planning period previous quarter, if you do quarterly planning so it is important to first reflect on what went well previously, and what didn't go well, and have that influence the top down guidance you're not learning from past things, then either you the assumption that you're perfect or that you're not able to adapt and both are dangerous.

Yaniv: So one of the things we've talked about a lot on the podcast is that fundamentally, when you are running a startup, a startup is a learning machine. And what we mean by that is we start off with a hypothesis about the world and we want to de-risk that hypothesis iteratively until we're at the point where we've actually been able to raise capital and build a big significant business in the world.

And when you're planning it can be really tempting every. Planning period, whether you plan quarterly or whatever it is, to start with a blank slate to say, okay, we're done with the last quarter. Let's have a think about what we wanna do this quarter. And not worry about the past and all the mistakes that we made, which we always do, and all the things that went wrong.

We have a blank slate and it's really exciting, but that's, always a mistake when you think about it in the context of a learning machine. Every planning period should be built on a basis of the new learnings that you got from the previous period and the period before that, and the period before that.

It's really important to reflect, to digest what has happened in the previous quarter, to learn from that, to add to your. Base of learning to your base of de-risking so that when you plan for this quarter, you have actually learned more, you know more, and therefore you hopefully going to be able to make a better plan, a less risky plan because of that new knowledge that you've gained.

Oliver: Also, the other thing is typically in that reflection, can quickly come up with a lot of things to improve. like always when you're trying to improve something, pick one or two and double down on them and don't try to improve a hundred things in parallel. I think it's much higher chance of success to really double down, which is also why like the process you're using, the tooling you're using should be constantly refined.

Yaniv: So I think this would be a great time to move on to commandment three, which is thou shall not blindly copy someone else's tool or process. I love this one.

Oliver: Yeah, so every company Has specific strengths, has specific challenges, and that will also constantly change over time from maybe early ideation to the different stages of a startup. The challenges will be very different and therefore, basically how you run planning.

Have to evolve inevitably. and I think it's a huge danger to just say, oh, whatever Google was successful with using this OKR framework. So we'll just copy, that framework and apply exactly the same to our company, because then we'll become as successful as Google. That's just a big policy.

Yaniv: we've been talking quite a lot about OKRs, but of course this episode isn't just about OKRs specifically, but about planning in general. And a lot of this discussion reminds me of the whole Scrum industrial complex, or, you know, all of these sort of industries that have come up around the Agile principles and the Scrum methodology.

And so often what you see here is that. the process has been elevated, where you go, okay, this is how Scrum is done, or these is how OKRs are done. But the underlying principles, you know, whether it's the agile manifesto the lean startup, the underlying principles behind those processes.

Are not digested, not understood. And so what you're doing is you're copying a process without understanding why that process is the way it is. And when you do that, you get all of the burden of the process, but very little of the benefit. And it becomes nearly a, pastiche of how the process should actually be because you don't understand why you're doing, you're just blindly mimicking what someone else told you to do.

Oliver: And I think the keyboard here is blindly. Is not saying do not copy. You should completely copy there's many good things can take and you should copy, but do it basically with conscious thinking about it, not blindly. I think the frameworks is a fantastic planning tool.

No doubt, it was one of the key rituals we had at Gga and have zeroed doubt that it was a key element of why Gga achieved so many, so ambitious goals. Especially early on in their years just goes hand in hand with the way that we did OKR best planning at Google. but taking that and blindly applying the same thing and hoping for the same outcome is just not the same thing.

I typically at what's the very concrete challenge That you wanna address in planning maybe it's idea generation because we talked about that earlier. In that case, you wanna really strengthen and build out. The bottom up planning aspect maybe dedicate more time to it, put my emphasis on it, run that longer, and pay more attention to it.

Or very often it's an alignment issue, which depends on where exactly is the alignment problem. Is it a high level alignment, then that first top down guidance that you're doing. That's basically the key phase before that phase. Kind of runs where you fix that or is it alignment that gets in the way of execution between the teams in which ca because they're depending on each other and they're getting blocked by each other.

It's a different alignment problem and something you can fix, ideally in that second top down phase.

Yaniv: So, like you Oliver, I, came out of Google, with a great love for and appreciation of OKRs, and I've been using them and trying to implement them at every company I've worked at since. and one of the things that I've really learned that has been a, valuable but quite a painful learning is that, OKRs as an artifact or even as a planning process, are like the tip of this very big iceberg where most of it lies under the surface.

And what I mean by that is that effective OKRs are built on a cultural understanding and a set of principles for how the startup is run or how the organization is run. It's about being comfortable with uncertainty. It's about. Prioritizing outcomes over outputs. It's about having a really clear understanding of a company's priorities and. And setting those objectives so that you actually know what's important to the company and organization. Now, what tends to happen when OKRs are blindly, again, that word transplanted to an organization that doesn't have that.

Cultural understanding and that set of priorities and way of thinking and way of doing things is just like I said before, you get all of the burden with none of the benefit, and instead thinking clearly about your objectives and what a good outcome looks like, what you'll take is the existing roadmaps, the existing laundry list of tasks, and you'll kind of aggregate them.

As key results into a set of OKRs and you, kind of have something that looks like OKRs but offers none of the benefits of OKRs because you're just basically putting these things together into an OKR format after the fact without applying the principles and the thinking behind what makes OKRs powerful at some of the most successful Valley companies.

Chris: I mean, to put it in a very stark terms, it's like putting lipstick on a pig, right? they don't understand the sponsoring thoughts, the underlying principles, and all of the cultural changes that need to happen for OKRs to be the right tool to execute planning.

Oliver: Yeah. There's a big part of the OKR process. you said that correctly. It's the, you start with the objective, so where do you want to go? I often feel like it's a bit like when you're learning mountain biking. Like they'll tell you, well, you have to look where you want to go and not where you're currently steering to.

So it's that basically that objective comes first. first you look at where you want to be, but in the end, the outcome of planning, like after planning comes execution and execution is basically when you have like a list of tasks and people work down those tasks. and how the high level objective gets broken down into all the actual tasks that people will then spend hours, days, weeks, on actually executing, like how that happens and what's the capability of the team to do that? That very, very much depends. if you set to abstract of an objective and then you say, oh no, our planning is done. Yeah. We set an ambitious objective and the, team isn't set up or hasn't learned how to break that down into actionable tasks and then take action on it, then you've just wasted a whole bunch of time.

Yaniv: So one of the themes here is really around processes that become, it's like the tail wagging the dog. And with OKRs, I've really felt this, I used to be a lot more dogmatic about the format, right? You have your objectives, and then a set of key results that need to be measurable, outputs and and whatnot.

I've often found it to be a lot more painful than I would like it to be. Right? Setting OKRs can end up being like a real. wrestling match, you're like wrestling a pig in mud and you come out the other end and you, feel grubby and exhausted. and I've reflected on, the reasons for this, right?

And so OKRs actually consist of three components, right? The first is the objectives. And the objectives are the thing that need to come first, right? You need to say, okay, what is important for us to be prioritizing? To be working on at this time. If you don't know what your objectives are, then everything else is kind of meaningless, You don't know what your. Devoting your resources and your attention to, and then you've got your key results. And your key results can again be broken down into two parts. the first part is choosing what the metric is, from the world of potential measurements that you might be able to use to measure your progress towards the objective.

What you want with your key results is metrics that, have the best fidelity, that are able to. Most accurately capture the spirit of the objective where you say, if we hit these key results, that means we've met our objective. But of course the key result is a metric, but it's also a target, right?

It's also saying we want this metric to hit this value, right? We want our customer onboarding time to go down from 14 days to five days, so the target is five days in this case. Now, what I found, especially at earlier stage startups, is setting the objectives is really valuable, but setting the key results is actually.

Quite a lot less valuable and quite a lot more work than you would think. And there are a bunch of reasons for that. One is, it's one thing to say, this is the metric we'd like to use. It's another thing to actually be able to measure it meaningfully. And quite often what I found is you set a key result, but then you realize you can't measure it properly.

And that's really frustrating. And then you either basically it or you end up in a situation where you have to put a lot of. Work into measurement, more work than is justified, by the value that care result is bringing. and the other thing is the target. especially at an early stage where you don't have any kind of repeatable motion, where you don't have any track record.

Setting a target for these values is often. Just an absolute shot in the dark. And because different people have different priorities around, how you use this target, it can end up being a bit of a food fight as to how you set it. And ultimately, the value of having a clear target turns out not to be that high for an organization that is simply trying to align around where it should be investing its efforts, what experiments it should run.

Just going into the great unknown, and making sure that you are focusing on the right things. And so what I've found is at the early stage, It is the objectives that are by far the most valuable. And I recommend trying this just set the objectives and the key results.

If you've got the capability to set and measure key results, fantastic. But often just having that clear, of these are our objectives at the moment. These are the things that we're focusing on, and therefore, All the other things that we could be doing, we're not focusing on them.

That's enough to drive the alignment. That is really the value of OKRs.

Chris: Yeah. A lot of startups either don't have the, tooling instrumentation in place to measure a KR or they don't have statistically significant results anyway, so there's nothing to measure or they're starting from a blank piece of paper. They haven't built anything yet, so they're not trying to incrementally move a kr a key result.

They're trying to. Invent some new capability, whole cloth. And so yeah, I like that very much. And I think the KR part of OKRs for very, very early stage companies is probably overcooking the process.

Oliver: Exactly. That's actually great. We're gonna get back to that when we talk about number seven. but could not agree more the one thing I would add, is like the earlier stage you are, the more decrease of freedom you have. So the tougher part of planning is figuring out the objective.

Until later, you become, you have existing customers and there's an existing revenue stream that needs to continue to grow, and there's critically expectation on how that needs to grow and so on. Well, then the objectives are still hard, not quite as hard anymore. But now it comes to the key results. if you just think about how planning typically happens, there's a whole bunch of information that is needed, for someone to really understand the full plan.

Yaniv: So now let's move on to commandment number four. Thou Shelton not spread planning information across different places.

I'm feeling a bit of shame right now, but Oliver, tell me why this is so important that it makes it as a commandment.

Oliver: First, if we think about what's. planning information, there's a whole bunch of information. Typically it's probably emails, From leadership to give like the guidance or maybe it's a presentation or it's document, somewhere. Then there's some helping material, customer insights or, feature requests from customers, top issues and so on.

Then there's the actual OKRs given, that almost everybody is doing OKR based planning, which is typically a table or multiple tables. Filled with many, many rows of objectives and key results, there's likely a final presentation of that. what very often gets presented as the plan is then that OKR table or a few of that OKR table in the end, but that's missing a whole bunch of information that for someone to really understand the plan is pretty critical.

You can imagine, I don't know, you're coming in as a new leader or you're coming in as a new employee and you're trying to figure that out. By just reading through the OKR table, You'll probably understand a bit of what they're doing. But you'll not understand why, because missing that information and you're not understanding well, what are they not doing? What would be the next thing they would do that they decided against all that information is very insightful, especially for leaders. to be aware of. It's not gonna be in that final, okay. Our presentation and also the problem with that is that email, that has a top-down guidance. You're not gonna find that three months later, you're probably not gonna find that the next week. Yeah. or that presentation link to that, you'll be looking through it and it says Q1 presentation, but it's whatever the Q1 presentation from two years ago and so on.

That's why the commandment is basically, Keep all of that in one place, put it all in a single place so that it's all together and you don't go hunting for it.

Yaniv: So this is really about putting the final artifact, the OKRs or whatever they are, along with all the context that led into those OKRs. and the bit that really stood out to me when you mentioned it, and it resonated as you talked about, you know, the decisions about what not to do, because ultimately The hard part of prioritization is not deciding what to do. It's deciding what not to do. and as you say, unless you explicitly make it a part of the process and the documentation of the process, it's not an artifact. And, don't have those explicit boundaries saying, we're not doing this.

We know it's cool. We know it's valuable, we know it's important. We know our customers want it, but we made an explicit decision. This other thing is more important. So we're not doing it. course, you could say that's implied. If it's not one of your objectives, it's not one of your objectives. But I think there's a lot of power in saying, we considered this and we made a choice to say no to it for now.

Oliver: Exactly.

Chris: The way we solve for this at Uber was to, not present just the KR table, but rather present what we call the narratives. the narratives were often a, deck of some kind. Or a doc, but it would include, you know, what is the strategy? What is our view of the world? What is our principles or pillars or, what have you, what are the possible pathways?

All the context you need to explain what is probably the last slide or one of the last slides, which is what are the OKRs of the team in the context of all of that? And then maybe some last, next steps or blockers or, yellow flags or something. And so that artifact. Ends up being the thing you present in the alignment meeting and the thing that you refer to throughout the quarter, as you're kind of holding the team accountable?

Oliver: That's fantastic. We do it quite similarly. and then store that together with the OKRs.

Chris: Well, I would actually say that the OKRs, were in the deck and so,

Oliver: It's perfect. Yeah. Then you've started in one place.

Chris: Yeah. Yeah. and you mentioned many, many rows of OKRs. We also talked about on this show a few times, really there should be three or four, OS and two or three or four OKRs. Like it shouldn't be lots and lots and lots of rows, right?

Oliver: The way I'm solving it in our company is we have basically like a hierarchical thing here, and at the lowest level that information is hidden. people outside the team don't need to understand those OKRs. they're just for the team and they can break them down in as much detail as they need it's completely up to them. It feeds into their execution and they have complete freedom to tune it to how they can best execute. But at a higher level, we're limiting the number of rows that need to read because like, people cannot read a hundred rows.

Impossible.

Yaniv: So let's now move on to number five, which is thou shall not plan in a separate place, then you execute. What do you mean by this one?

Oliver: we touched on this a tiny bit before, and that is in the end, you're doing planning, not for planning's sake, but. Planning is there to guide execution, and execution is basically when you tend to get decided whether plan was good or not. so there's this close tie from planning to execution at the same time.

Often it's done somewhat separately early. You have planning, it leads to some OKRs. And then I remember actually it was guilty of that many, many times before planning was finished at Google. Now we did something completely different for six weeks, and then I got a reminder, oh, you actually have to go back to your cars and update them.

And then I go back there and realize I've forgotten about. Like a small percentage of them. Completely. forgotten about them. And then we kind of huddled to get that together. And then you forget about for another six weeks until the dec quarter's finished, and you reactivate that again.

That's clearly not optimal way, for that plan to really do what its job is, which is to guide the execution. So it's much better to then actually store those plans or the outcome of those plans, let's say the, KRS. in the same place that you're actually running your execution from. So if you have, you're running your execution in a weekly meeting on Monday mornings, then that's also where the chaos should end up showing up.

And it should be visible and it should be looked at in that case, every single Monday morning. And any updates in the meeting should in ideally, directly reflected back in the, krs and not after six weeks when you go to a completely different tool

Chris: I'm often, telling the companies that I advise coming up with the plan. Is really hard. that's a really hard part of my job to help you come up with a plan and to think through the strategy. An equally hard part of the job is to operationalize the plan and to mitigate strategic drift, both of those things are really hard and oftentimes you'll find startups.

That are in a loop of planning where they plan, fail to execute, plan, fail to execute plan, and the next new hire, the next new person, the next new whatever is. I've got a plan, boys and girls, and that's not the problem you have. The problem you have is the plan is probably not specific enough, but the operations and execution are not happening off the back of the plane.

Yaniv: The way I think of it is the plan needs to be, Living. I think an even more egregious example of where this takes place, is when you talk about companies that define, company values and things like that, and, you put a lot of thought into it.

You have focus groups, whatever. You write down your values, you print them on a beautiful poster, you stick that poster on the wall and everyone just walks past it every day and completely. Ignores it because you've not operationalized it. And so I think with values that's very stark. But with plans, something similar happens, right?

You're like, ah, our OKRs are done. We've put them on a slide. We've had a company all hands, we've talked through them. We've put them somewhere on their internal coder. See what I did there? Then everybody just ignores them. you get like plan blindness it's nearly like, even if you have them in the same place.

In the same way that people get banner blindness where they're like, oh, okay, here's a, you know, an ad. But I'm just not seeing the ad because I'm focused on the content. Even if you have your plans in the same place as your execution, if the plans don't feed the execution in a meaningful way, if they're not part of the process, they will still fade into the background and fail to come to life.

And I don't have a perfect solution for this, by the way. I'm still a student of how to really do this well.

Oliver: I don't have a perfect solution either, but one thing that's helpful, why not perfect, is like in my weekly kickoff meeting, for example, I visualize the krs. And I have that visualization just rendered as cards but it's sorted by progress with the most complete one at the beginning.

And then towards the bottom. at the least completed ones. And we go through that at the beginning of the meeting. We just look at it. like a leaderboard. We celebrate who's first. But we can actually also then guide discussions about where we are lacking behind and suddenly, not every week, but regularly, it influences actually the agenda of the meeting.

And suddenly, oh, the plan has actually informed, we're

Yaniv: Yeah. One thing we've tried to do is whatever our planning tool is, we tag them. With one of the objectives that's part of defining the ticket. So if you don't know what objective that ticket is working towards, and at the very least you need to pause and have a conversation about whether you're doing it.

And I guess both your example and my example are, beyond having them in the same place, how do you actually bring them into the process?

Today I'm here with Dileep, a principal engineer at Until Now. Speed is super important in the early days of a startup, but of course you also want to make sure that things don't break. How do you make that trade off?

Dileep: Mother of four questions, isn't it? The reality is that things will break. The question is, did you expect it or not? the early stages of any startup are about making the right trade offs and going into things with eyes wide open. When designing a new solution of feature, you actually work on a spectrum.

On one end, you're running the risk of cooperating code and delaying valuable new learnings On the other. You are running the risk of eroding the little trust your earlier adopters have placed in your startup. So I believe the most efficient approach will be a risk driven, just enough architecture solution So you ask questions like, are we shipping to learn something new? What is the level of confidence in the solution? What are the risks involved and where it's gonna break? The answer to all these questions eases more context and helps to make the right trade offs required to build the right

Yaniv: Whether you're a startup scale up or corporate venture, Until Now runs a cross-functional approach to solving your product, brand and go-to-market challenges. Head to their website for more examples and to get in touch.

Shall we move on then to commandment six? We are now round the bend. thou shall not confuse goals with stretch goals.

Oliver: Yes, the number one question I get is oh, should we write our OKRs so that we complete 0.7? Or that we hit a 1.0. And for background, for people who haven't worked at Google. at Google we wrote OKRs, in an ambitious way and achieving only 70%, and they were created on a scale from zero to one.

So 0.7 meant we had achieved 70% of what the goal was. That was considered a success. that's become unpopular. for a number of reasons. So most companies that, I've been involved are not doing it like that. They just write the OKRs in, but they're actually trying to achieve this quarter.

And if they achieve that, it's considered a hundred. Percent and any score below it is considered some failure. and one of the negative side effects of writing Anki in one way, but being fine with only achieving 70% is very hard for other teams that rely on that OKR to be completed building a new storage system, and the old storage system has an okay to be switched off at the end of the quarter, and the new one is, Gonna be ready at the new quarter, but then their successes matter. Well, they didn't quite get there. They got it, 70% completed. suddenly you've turned off the old one and you haven't built a new one yet.

And if that sounds crazy. It sounds crazy, but this has happened many, many times at Google, where we, transition to systems that weren't quite ready yet and already turned the old ones down. that's why most companies aim at a hundred percent, makes tracking those dependencies and relying on them a lot easier but also then you're losing the advantage of being able to set really ambitious. Goals where you're not then held responsible if you can't achieve them, and that's where this commandment basically comes in. I typically give the advice, it depends a bit on situation your company is in and scale.

I normally say most companies should probably write the goals as actual goals they want a hundred percent completion on, but should have the freedom to write stretch goals as well and clearly mark them as stretch goals. Where they say, oh, we'll try to achieve this, but this is a stretch goal.

So we perfectly clear here that we will very likely not achieve it, even though we'll still try hard. Then you get the motivational boost, the ambition, but also the flexibility from writing stretch goals where you don't need to be perfect in predicting

Yaniv: The only thing though, in my experience Oliver, with stretch goals is they never get achieved. Like As soon as things get a little challenging, which they always do, the stretch goals get thrown out. think that's a challenge there. if you don't integrate stretch goals into your actual goals, you're all but guaranteeing that they won't be achieved.

Chris: think the trick here is to make sure that the goals that are being set, the primary OKRs, are in themselves, ambitious, and that comes from that leadership alignment phase of the planning, where to push the squads and really, really get them to set good goals and not goals. As you said that are like, 7.8 is okay.

Like no, we want you to hit this higher goal, stretch goals. of, I'm a bit indifferent whether they're there or they're not there, but what you said reminded me, Oliver, about, good OKRs I think should not be binary. Like we turned it on, we turned it off. Or rather, it should not be about dates and the activation or completion of a service.

They should be more about. Instead of we do a hundred percent of this new service, it should be we've onboarded three customers onto the service. So that suggests not only does it have to be complete, it has to be complete enough that a customer can onboard.

Yaniv: And sometimes the target value is important and sometimes it's not. Sometimes you just wanna say, we really wanna improve customer onboarding. We're gonna measure that.

We're gonna try to make the onboarding period as short as possible and adding a target to it, whether it's a stretch or not a stretch or whatever. It doesn't actually help the teams plan or execute in any meaningful way. And so sometimes it's worth saying, well, you know what, we're just going to bring it down as far as we can.

Chris: I think that's sometimes true Yaniv, but the interesting thing about a specific number is that it helps the team understand what is the order of magnitude. Like, are we open to a step function change? Like let's rewrite the onboarding wizard and rethink this.

Or is it sufficient to squeeze out a one, 2% gain? And oftentimes, teams will be, comfortable with a one or two or 3% gain. When you're like, guys, we should be able to double or triple the throughput through this thing. And why are you aiming so low, and why is your work product so mediocre?

Yaniv: Let's go onto commandment seven then, which is, thou shall not waste time on success metrics when success is obvious, or rush success metrics when success is not obvious.

Chris: I like that.

Oliver: So this, is sometimes a bit by purist OKR fans a bit controversial because I'll tell you, sometimes it's perfectly fine to just set a goal of launching and moving on and not spending any more minutes talking. Talking about the metrics and at other times, that's the biggest mistake you can make.

For example, in a perfect world, a success metric would be something that is an output metric. So that you see that, what you've achieved has really had. the impact the system that you're changing, so you'd ideally measure the output and ideally you would be able to measure it directly, with no feedback, delay, in reality often You're doing something. that helps the marketing team, and that will translate into more visitors and then eventually more sales calls and some of these calls will convert, into free accounts, and then they'll convert into paid accounts and a year and a half later, You'll be able to measure the revenue impact doesn't help you anything to measure the success of that specific launch.

Because there's a feedback delay and an attribution delay. You're never gonna trace that, conversion a year and a half later, back to that launch. so Then you compromise on input metrics that more directly related. you might just track a number of calls, a number of visits the final objective you're going for here is revenue related. it's an input metric. a whole between translating into revenue, but it's easier to track and just a shorter feedback. so that's, what often gets done and my argument here is to basically sharpen that a bit more and says there are certain things where I do not have the capability to measure it or instrumenting the measurement will take you on the same order of magnitude as actually building the thing.

And then you need to make a call. Is it? Really obvious that this will move things in the right direction. And the only question is how much it moves it. Do you need to understand that or you have to double down on execution, get it done, and move on to the next thing? Or is it, if you're tuning a complicated system, do you actually really need to understand it?

Yaniv: This nearly goes back to the commandment about not blindly copying processes. you don't blindly copy them and you don't blindly apply them either, I've been guilty of this I think in the past, with planning and execution tools like OKRs.

But this episode isn't all about OKRs. I, think this is just as common with. sprint planning scrum and things like that, right? you see this situation where a process that was designed to support a certain way of working becomes sort of hardened and ossified, and then you end up with a tail wagging the dog where rather than saying, okay, we created this process to support this way of working, The process starts to dominate and you say, we have to do it this way because the process says this is how we have to do it.

And you know, with OKRs it's like we have to have output metrics you can end twisting yourself into a pretzel. To your point, Oliver, it's like, okay, the output metric, we're not gonna see it for a year, so what do we do? and you have meetings and discussions and like all of this stuff, it's like, oh, okay.

You know what? Maybe it's just not that important. either it's too hard to measure or we know what success looks like, or we can think of some input metrics, or we actually just say, this is a delivery goal where we just wanna ship the thing and then see what happens because you know, we're putting conviction behind it really it, comes back to that, piece of like, okay, the concept of a tool is, it's an external to you that helps you in achieving something. And so a tool is something you use at the moment. The tool uses you, you are the tool. So don't do that.

Chris: Yeah, and this is something we speak about a lot, right? It's what I call cognitive inertia or the lack of first principles thinking where people get into this groove, well my manager asked me to do this, or this is a process we always run, I like what you said Yaniv, never, you become the tool It's so, so hard to do this. And I've given this example before on the podcast where, the team I was running at Uber had historically been gold on certain outcomes, certain metrics. Of course, the OKRs for that quarter were rooted in those metrics. And about halfway through the quarter I realized.

These are dumb metrics. These are dumb goals. This is not the most powerful thing the developer platform can be doing for Uber. there was this come to Jesus moment where amongst the whole cross-functional leadership team, I finally said, exasperated, I don't give a shit about the metrics.

Cuz they kept on trying to bring it back to the metrics. And that was Sacri and Uber, right? It was like to not care about the metrics, but I, finally had to blurt out the most, confronting thing I could. Because we kept coming back to the metric, the metric, the metric. And I'm like, this is the wrong metric.

It's the wrong goal. I don't care about the planning cycle. I don't care what we agreed on. We learned this is wrong, so we're gonna throw the process out and we're gonna do something else. From the users you're trying to serve, to the peers you're trying to work with, to the leaders who are ostensibly helping you achieve a goal, there's this inertia that you have to be hyper-vigilant about.

And it's, hardest thing in the world sometimes to push back on, but, push back on it. You must.

Oliver: I sometimes compromise a bit here. In reality, I say, okay, we have still data driven, we're arguing about the metric. For now, we put down as the metric the, you know it when you see it.

Yaniv: I love it.

Chris: I love it

Oliver: And we'll have an argument next week on whether we keep that as metric, or whether we have made more progress and we can start to instrument.

Yaniv: You mentioned being data-driven and actually speaking to my previous point, our head of data back at Airtasker said, we don't want to be data-driven. We want to be data informed, because data-driven means the data's driving you, you wanna stay in control. So the data is there, but if you give up your agency and your accountability to the data, then you're not doing your job.

But anyway, Chris, you had nearly the perfect segue, I think to commandment number eight about, forget the metrics, right, which is commandment number eight is thou shalt not etch your plans in stone.

Oliver: Yes, because whenever you finish writing your the world has changed. it's kind of inevitable that whatever planning horizons, things change and some of the plans no longer make sense.

And now there's like multiple options that you have. Like one thing could be you just follow the plan because it's been written. And not consider changes in the world.

Until the next planning cycle starts. But if that planning cycle is three months, that's an awfully long time to be going down the wrong path. the second option is, you start ignoring the plan because it's no longer valid and you just try to do the right things without a plan. Or the third option is while you change the plan. Just adopt a plan in the end. It's text that's written, somewhere in a table. that you can just change. if you're not adapting to the changing world, that's a problem.

And if you're start adopting, but not adopting the then you just train everybody to ignore the planning? So just it just the plan if needed.

Chris: Can you imagine a world where. Planning was set in stone and then Chat GPT comes out.

Oliver: Yeah.

Chris: Everyone's like, oh yeah, we'll just stick to the plan. It's fine. And it's like, no, Have a think again.

Yaniv: I'm just gonna keep riffing on my point of giving up your agency and your accountability to tools. The plan itself is a kind of tool, right? if you say, okay, I've set the plan and now. I am just gonna do what the plan tells me to do instead of saying, okay, I've got this plan and then I need to work with the plan.

But new input, new data is continuously coming in. there's that, quote. Sometimes it's attributed to John Maynard Cain sometimes to Winston Churchill. when the facts change, I change my mind. What do you do? Right. And there's this idea of like, okay, the facts are always changing.

In startups, the facts are always changing. If they're not, then you're not actually delivering product enough because you're getting new facts in, right? so when the facts change, you change your mind. And if you change your mind, you should change your plan. Now, I have personally one caveat here, which is what's the difference? Between changing a plan, and I think, Chris, you called it strategic drift. It's about the level of intentionality. I think when you change the plan, there's nearly a little ritual you should go through where we say, we are changing the plan.

The plan was X, the plan is now Y. The plan is not something that can just sort of. Evolve in the sort of slippery, organic way. I think plan updates are discreet and thoughtful and intentional things that need to happen and be clearly communicated in that way.

Chris: If I wanna put a little plug in for, I think a revelation we had on the podcast, live as we were recording, I think, in one of the early episodes where we discovered that startups are all about agency. You know, your business model should not be dependent on gatekeepers. Your team should not be dependent on sign offs or check-ins.

The squads should be autonomous and individuals should not be attached to plans. When their agency, their intelligence, their experience, their intuition, their new data tells them something has shifted. And I thought that was like, That bent my mind when we figured that out together. Or this idea is like, startups are about recursive agency all the way down.

And I think that's so, so important and so powerful an idea, and I think it applies here as well.

Yaniv: just, one other thing about, this commandment maybe before we move on, which is I think that etching plans in stone is actually. I dunno what you think Oliver, it feels to me like a sign of management insecurity, is this attempt to have control, uncertainty, and uncontrollable and uncertain environment.

And that's actually kind of immature and insecure to try to do that.

Oliver: It's two reasons typically for why people argue that don't like to change the OKRs. One is the plan is used. Too extreme as a performance management tool. So they say, oh, if we just allow people to adjust the plan they'll not achieve the goals because they'll just change them. But that's another dysfunction and you're trying to solve performance management or other problems through planning, and you're making everything worse that way.

The other one is if the organization can't make sticky decisions and then there's a worry dot. all the discussions that were done in planning, kind of keep going after the plan is written. So that's typically a sign of two other dysfunctions That are not solved by etching the plans in stone, but that you actually solved by solving the actual root cause for 

Yaniv: Okay, so let's move on to number nine, which is thou shalt not spend more than 10% of your time planning. Why 10%?

Oliver: let me tell you a story first off, like why I wrote this down. When I joined Coda, there were like a ritual two weeks planning followed then by the rest of quarter execution. these were quite intense two weeks.

But it felt long. and one ex. Pyramid I did after I at Coda for long enough that I had the courage was to basically change it down to a single week the main goal of a plan is the execution. And, if you're planning, you should be basically doing nothing else and we wanna, in the end, maximize the output of the companies, we want good plans and then as execution as possible. The theory was basically if we, have an additional execution week, we can get more done. I wasn't convinced that the second week of planning was adding as much value to the quality we shortened it down into a single week and. Surprisingly, or not surprisingly, the actual plans that got delivered in a week were actually better the shorter planning period led to better planning, higher happiness, and better business outcomes than longer planning. So why is the number 10%? Well, the 10% is made up because it's around number and we have 10 fingers. and because 20 is too much, I get a, regular pushback on this one, right? People say, oh, but we need whatever, two weeks minimum for this. And that reason, it's always worth actually then digging in why that's the case. If a planning process needs, let's say a long time because while you actually start to only gather customer feedback when planning has started, that's a problem.

It's a given, but you should always do that and collect that. You don't have to analyze it every single day perfectly. But that should be a continuous process to listen to customers by the way, if you do that, you also avoid all kind of biases, recency bias and so on But anyhow, like if it's a large company and what, takes two weeks because alignment is hard and there can only be so many meetings that happen in the week. I would argue, well then consider planning for six months instead of three months, instead of spending the team's 20% of the team's time If you can get all the planning done in a day, well, you have the luxury to adjust the plans every month.

Yaniv: It makes lot of sense. And I think what this is, is a reminder that execution is what matters, And planning is so important because if you don't plan properly, you don't have alignment, you don't have thought into what you're executing, but. Until you turn your plans into deliverables, then they are worthless, right?

And so if you spend too much of your time on them, you end up with, not enough time to execute and it slows you down. So it's, actually, it's really nice to have that forcing function. Oliver, let's move on to the final commandment. Thou shall not confuse OKRs with strategy or vision.

Oliver: Yes, we touched a tiny bit on that before. often people have a process like an OKR process and they run through that, and then they're done and happy and so on. there needs to be a strategy that describes how the company wants to move to that, vision factoring and resourcing and so on.

And then there's the other step of breaking this down into concrete objectives and concrete key results that you wanna move towards that, and then afterwards, turning that into your execution mode, to the actual tasks all of that is needed.

if you run a create OKR process, but you like strategy and vision, you'll not be successful. at the same time, we have a fantastic vision, but no way to turn that, into actual actions later. equally likely to fail.

Yaniv: Are you making a distinction between strategy and tactics? In a sense? It's like, Your vision is, your ultimate, ultimate long-term goal. Your strategy is your. Long-term approach to hitting that goal. And the OKR is okay, working backwards from that long-term vision and in alignment with that strategy.

These are the things we're going to focus on now. we've talked in previous episodes about the, critical importance of sequencing. It doesn't get spoken about anywhere near enough, is one of the most important parts of planning is what order you do things in. And OKRs and shorter term plans are really a manifestation of saying, this is the next thing that we think we should do in that ordered set of things that we are doing in pursuit of our strategy.

Oliver: Defines the high level actions, take them in the coming planning period

Yaniv: fantastic Oliver. So thanks so much for talking us through your 10 commandments. I guess I should ask, have you published these anywhere

Oliver: So I'm planning to write this up in an article and

publish it somewhere.

Yaniv: Fantastic. we'll put that in the show notes hopefully this overview, really digging into your, many years of, top quality experience, Oliver planning at different levels of granularity at different size organizations.

This is hard one experience. And so thanks so much for sharing it with everyone.

Chris: Thank you Oliver.

Oliver: Thanks for having me.