[Note: please be advised that this transcript contains strong language]
Transcript
Cutler: Heidi and I do go way back, I started working at a company in Southern California, and Heidi was just picking away at me. She'd said, "Hey, do you want to chat?" and we would go, and there's this long road behind the office where everyone would do their one-to-ones and walk. Over time, I was noticing Heidi was seeding a lot of these ideas really early on. She's, "Oh, you might want to talk at a conference one time, or maybe you should try to do these things." I have to thank Heidi for pushing me into stepping out of my comfort zone and doing these talks and writing more on medium and doing a bunch of things. I'm really grateful for that.
These are the ways to get in touch. I work at a company called Amplitude, I'm not here to talk about Amplitude, Amplitude is product analytics, product intelligence. The important part to know is that as part of my role at Amplitude, I don't evangelize the product, I just coach teams pretty much all day. Most of the time I coach teams generally for free, so, that changes the dynamic a little bit, but it's allowed me to talk to hundreds of teams, and it's been really a special gig to do that.
I write a fair amount on Medium. There's a lot there, 400-500 posts at the moment about product development, and I definitely have a writing habit or problem. I also use the Twitter a fair amount, so you can contact me there. Now I have a 14-month-old, I've realized I can't handle all the streams of communication, so, Twitter is a good way to bug me at the moment, so, reach out if you want.
What Is This For?
I want to frame who this talk is for, this talk is generally for engineering leaders and engineering managers or team leads who are passionate change agents, but they're trying to figure out how to navigate their organization. They're trying to figure out the limits between nudges that kickback on them and nudges that work, and they're generally trying to also help their teams just see more impact in their work, that's what they're really passionate about.
A lot of the people I'm speaking to, this is targeted at folks who are curious about the product side of things, or maybe just great product leaders in themselves, and know that there's other things out there and they want to figure out how to hack a little bit the product approach as well to be more engineering-friendly. They're really looking to create nudges in their organization.
Anatomy of a Failed Change Agent
To start, I want to tell you about the anatomy of a failed change agent, and that's me. I've made the mistakes, so you don't need to. When I would be involved at companies or in organizations where I would take a full-time job, usually this cycle went like this. If anyone can relate, great, if not, that's good, you don't have this thing.
The first thing is, I would go in there, and then some people working there, usually frontline folks and engineers, say, "Wow, that John guy sounds interesting." Yes, that sounds interesting. Then my manager would every time be, "It is. I'm so happy to have you on board, JC. That's great." Then the team started saying, "I think we should try this. Let's try this." Then the managers or whatever would go back, "Actually, wait, hold on one sec, what is John saying? I'm not sure actually what he's saying. What does he want here?" Then the teams would say, "Hey, we need more of that. How do we do it, John?" Then, there would be a little bit like riling the troops, "John, I think he's causing this mass agitation. People don't know what to do. They believe there's something better out there. It feels scary to us." Then the front lines would say, "Oh, look at those leaders. It's politics as usual. They're not really doing anything about it." Then the full on red alert, from leaders in the company, this “Danger!”, then it reached this boiling point, and I was really ineffective. I'm going to be honest, I was really ineffective.
You could say that I'd become a professional canary in the coal mine, people liked having me around, they're, "He's talking interesting stuff. I think he sees it." But, I tweet - that's funny - I tweet in the Twitter thing, would sound the alarm, "Hey, guys. It's all going to explode," and then nothing would really happen about it. My track record is actually really good, whenever I said it would explode, it has exploded. As you do the change agent thing, you realize that there's no solace in that other than just patting your own back. It doesn't really help to be able to say that.
What I noticed is that there were three things that I was confusing perpetually. Those three things were confusing my own personal needs in the setting, I have a need to be in an environment that feels rigorous, and disciplined, and I like flexibility, I like to pursue my own solutions, I like all those particular things. I was confusing that with feeling very strongly. There's probably folks of you who believe in this and those who don't and that's ok too, but I'm a very big advocate for participatory continuous improvement and for the idea that the citizens of the company can participate in what we try to improve, not the solutions, not what we try, but how we try it.
Then the third thing that I would confuse - and not only I was confusing myself internally, but other people in the organization were confusing what my real agenda was - is, I was confusing specific ideas. For those of you who are managers, this probably fits the profile of a couple of people that you work with, what do they really want? “We should do OKRs, or should we..." Do they really care about OKRs, or is it them who cares about it? Do they care about it for their team?
Change Agent V2 (Or 10)
Hopefully, this rings true. I'm just painting this to set up the talk because I've been there, and I've been really ineffective in change agency. You might even work with people who fit this profile. I'd say, first, just give them a shot and try to nudge them, but there is a second version of this, which is really change agent version 2, or probably more like version 10, or 15, or 20 at the moment.
I've gotten a little better at this. For example, in my particular role at the moment, I talk to three, four, or five teams a day, I do these hour-coaching sessions, I do internal workshops at Amplitude, I do external workshops, and so the muscle has been built over and over talking to these particular teams and seeing how it could be a more effective change agent.
The interesting thing when you talk to this many teams - originally I was a consultant, and I would talk to maybe like five teams in a year, or I was full time, and so I was talking to teams within a particular company - is, not only do you see all these incredible patterns and things start to feel all the same, but you see all these very unique, interesting things about companies. You really begin to honor what makes companies great. It’s often not so easy as saying X, this often is complex set of things that make companies really successful. It wasn't until I talked to all these teams that really occurred to me that I used to go into an environment and say, "I think I've figured this out. I see this pattern and this pattern," and I would be right, but I wouldn't have deeply understood what was going on in that environment.
Some Are Healthier than Others
How many of you picked up a blog post and read about something a company was doing and just said, "It looks great over there. I wish our company could operate like that, that looks amazing."? We've all been there.
Often, as somebody who writes a lot of these blog posts, people contact me and say, "My company sucks. What you wrote about there was amazing." When you talk to all these particular companies, you realize an important thing, it's incredibly hard for everyone. This is really hard for everyone.
In the last year, I've spoken to teams at Amazon, spoken to teams at Microsoft, teams at Intercom, a bunch of teams everywhere, and they all have their own struggles, and they all have their things that they're working on when they're doing it. You do realize that some are healthier than others, they're able to work out their shit a little bit faster. An example question I ask in my sessions is, how long does it take to remove the most toxic person in your organization? The range is 7 months to never - 12 years to do those things. You can see there's a range in the immune systems of companies, but it's hard, and that's an important thing.
One thing that you also realize in doing these calls is that most of the time people come to me first and they say, "Ok, you need to tell us about OKRs. You need to tell us about this Canvas that you're working on, Canvas X, Canvas Y. How about Research Sprints? Google does these sprints, we want to do these things too. Have you heard these Tribes and squads things? We've got to do that in our company. What should we use to measure? Should we use HEART? Should we use AARRR? Pirate metrics? Can you give me templates for one-pagers? Can you give me all these things?" People are desperate for something like some tools or some frameworks to figure this thing out. The funny thing is it's very consistent. On most of these calls, people start thinking that it's just a magic tool or a magic framework they haven't really figured out in their organization, but what you learn very quickly as you dig deeper that often it isn't nearly as simple as that.
My - I guess - Twitter friend, I've met him once, Josh Arnold has this great idea of the reverse Anna Karenina principle. In Anna Karenina, they say that all happy families are the same and all dysfunctional families are different. His concept, and I would back this up now as I've seen it, is that the anti-patterns are all very similar, you do these particular calls, within four minutes, I can pattern match these 20 anti-patterns very easily. It's actually the healthy companies that you have a really hard time figuring out. You'll see five companies doing very different frameworks and very different methods for things from up here, and what you'll realize is that you can't really pin it down. You can't just say there's this exact thing that they're doing, so something else is going on.
People often ask me, "No, wait. Tell me about all the anti-patterns." Well, here they are. It's pretty easy, I used to pattern every call. I used to group these over, and over again, but you can imagine what they are. They're structural cultural issues, silos, command and control, fear of risk, fear of failure, trust and safety issues, team autonomy. Those are structural cultural issues.
Then there's alignment strategy and decision making. I'm presenting this because we're going to talk a little bit about the alignment part today, but I'm trying to present the universe of things. Connecting high-level goals to what you're doing, shifting priorities, difficulty aligning teams, etc. Then, every company has revenue pressures and short-term pressures. Any time you think that's just your company, it's not. There's this tension between short-termism, and midterm, and long-term results that pervade lots of particular companies. Then, in general, there's a lot of busyness and high utilization. These are the patterns, if you do 50 of these calls and you group the pains that they're having, you very rarely find one that falls out of these particular categories.
I was really tired, and I have the 14-month-old, and I was trying to figure out the speed that I should do the looping [on the slide], I think it worked. You figure out that the companies that seem to have this figured out just generally seem to sense and respond a fair amount faster than the other ones. That's the only pattern that you can really just nail down with all these differences between companies is that the companies that are healthier seem to just work through their stuff faster.
The Big Ideas
What this has taught me, and what we're going to talk to you about today, is that there is this whole universe. I've learned, doing these calls, that there's no shortage of safe to fail hacks, they're everywhere. They've piled up, consultants are piling them up, coaches are piling them up, but what I've really focused on in these calls is trying to figure out the operating system for just trying these things in general. When you do that and you use the right hacks, you let teams build coherence, make sense of their work more. Occasionally, I'll jump in with a particular idea, but that's really been my strategy that the evolved change agent that I've become in this is focusing a lot less on creating a lot of noise and just, “Can I get the operating system for change working in that particular company?”
The big ideas for this particular talk. The first is, that product development is, I'd say, a beautiful mess. It's fractal, it's networked, it's not a factory line, it's a mess. That's what makes it great, that's why there's a lot of opportunity in product development. The next big idea is that efforts to try to simplify that, to try to cram it into an assembly line, metaphor, or anything you're doing, usually fail, and it often backfires for your particular change effort.
The big idea for this talk is that if you can reflect that mess back. If you can reflect on what's actually happening in your organization, that creates a catalyst for change and that starts creating a catalyst to tell meaningful stories that creates impact that people are looking for.
That's the big idea, we're going to dig into eight hacks that you can do right now in your organization to try to turn this mirror back, because mirrors are very powerful. What I noticed in a lot of these calls is that people were talking about OKRs, or canvases, or this and that, and no one was able to truly shine the mirror back on what was going on in the organization to understand if things were working and what they should try.
Quickly, I wrote this post about feature factories, and this sets up a lot of the particular bits of the talk. The whole idea of the feature factory is, you just feel like you're a cog in the wheel, you're just churning out features, you don't know if any of them work, there's a lot of success theatre, product never reviews what it's doing, it just feels like this never-ending conveyor belt for what you're doing.
The feature factory thing taught me a couple of key points. First of all, as a writer, Angst is extremely easy to trigger in product development. It's very easy to get people angsty about the work they're doing. The next thing is, I understood that they really crave certainty, and the reason why I'm mentioning all these is these will pervade all of the eight points. Just look for these themes, about trying to deal with uncertainty more effectively, trying to create a sense of impact for the work, trying to build coherence.
Coherence is different than agreement. Coherence is that we all understand what was going on, agreement is forcing everyone to agree on the exact same thing. In a coherent environment, if you didn't know what was going on, you'd actually openly say that you didn't know what was going on, that's a super, super important thing. Then, finally, you're going to see what I do as creating a flow of impactful stories.
One of the big reasons it's important to think about this in the talk is that a lot of companies read that feature factory post, and then I realized that actually some companies are doing really well as functional feature factories. The companies are doing well, they're surviving, they're doing these things, so part of what we're trying to do in this talk is to help the company move down to the third level there, which is trying to jump out of that particular feature factory setting.
Bets
Some hacks. This is the easiest one you can do tomorrow. An executive comes and says, "Well, we're going to do this," and all you really need to say is, "Oh, that's an interesting bet." It seems like a tiny, trivial thing that you would say, but often the slightest changes in how you use language and how people are talking about things can mean all the difference. Here's how the conversation goes, "Hey, so we're going to do this." "That's an interesting bet. Tell me more about that bet." "What do you mean a bet? We're going to do this?" “Yes, I know we're going to do that, so you're betting we do exactly that, right?" "Yes, I'm betting we'll do exactly that." "Well, tell me more about that bet, is it risky? Is it safe? Is it a long-term bet? Is it anything like that?" and before you know it, you've taken a prescriptive request to go and build X. You can do this for product, let's say I'm your product manager. You can turn around and say the exact same thing to me, "That's an interesting bet."
What you're doing there is you're nudging people to think about uncertainty, but making it safe for uncertainty. The interesting thing about bets is they can be big, they can be small, they can be safe, they can be risky, they can be descriptive, they can be a big batch bet. There are games that you can bet on after the game has started. There's some people who gamble on everything, so they would probably tell me there's a lot more types of bet.
Let's say I go and say, "This is your project." What is conveyed in that word? There's a beginning, middle, and end, you're going to get it done at that point, this is the thing, this is the scope, this is the budget. Nowhere in the word project do you capture all the rich tapestry that is actually product development. Product is more like a game and less like an experiment I would say. Just that one hack can help you nudge the person you're talking to - the product manager, the leader - to talk about uncertainty.
I actually built a little tool for this called You Betcha, I made it really that easy. "We're betting that the cost..." This is great for technical debt. "Wait, tell me more about that." Operationally, we know we've been de-prioritizing something. We realize this causes pain and frustration to our people because we observe all this pain. The important bet that we hope will offset this short-term pain is that we are some larger or more valuable thing.
You see what I did there, the hack here is you're not going to someone and saying, "You're wrong, or you're crazy." You're going, "Hey, talk about it." Flesh this out, "You're making that bet. That's interesting." The action item there is you could write some BetLibs or just the next time some product person comes and says, "We're going to build this." Just say, "Interesting bet. Talk to me about it."
The Work Takes on Different Shapes
The next thing that is super valuable, and I do this in almost all the coaching sessions I do now, I don't have a good word for it, but I'm calling it Map the Shape of the Work. What you'll notice here is a range. Important, this is not a hierarchy of work, it's not higher is better. If we start out at A, you'll see something that says, “Build exactly this thing to spec, exactly this way, make this mockup look exactly like this.” As you start to go down through A, B, C, by C you build something that lets a segment of customers do this, and D you're solving this, E, you're exploring the challenges, the experience of this, F, you're improving some known metric, G, you are much more exploratory, you're exploring the nature of a particular problem, and H and I are short-term business outcomes and long-term business outcomes.
What's really powerful about this particular framing, especially if you don't attach any value judgment to it, is this is the beautiful mess. At any given time in your organization, work of these various shapes is happening at the same time. It's highly networked, it's highly connected to each other. Just by working with your team and saying, "Do we have an E level thing going on right now, or is this an H level thing?" Even better in your company, develop your own taxonomy. This is just a sample spread of work, but you might have different elements of work. I've done this with teams all over the world, and you start to get shapes, it's super interesting.
The stickies there [in the picture] are different colors. Pink, I could let you guess, but I'm going to give you the graph right here. Here's a particular company, and this is the shape of the work that's happening at the moment and who is involved in it. Pink, you have PM, orange, you have UX, and blue, you have developers. There's a lot going on here if you think about it, PMs have this spike further up to the right. Design follows, but there's a double dip with design, they're heavy in one area, and then they're trying to solve C level things because they have to figure out a customer problem, and then developers taper off there to the left.
Part of this is shining the mirror back. If you have a culture where developers are fighting back at the prescriptiveness of the work that they're doing, one way to solve it is to raise the flags and say, "You give us problems, we solve them, fight the power," and then the other way is to say, "Let's just map what's going on right now and get a shape of what autonomy looks like for the particular work items we have, and then we can see how that shifts over time." You might find that you have a group in your company that's actually further along than you think.
You notice, as you do this, for example, what org structures look like. The left is a more hierarchical organization, you have a team, you have a PM, you have a VP of product, and you have a GM. On the right-most example is an example where you have the teams and there's much more overlap between these particular teams. The team and PM overlap, there's a hard cutoff between the GM and the PM, but they own different areas of doing it. Even this alone, if you're trying to untangle your organization, just this type of mapping can help you. Categorize a sample of your work and make it visual, that's the next hack you could do.
The Messy Middle
The next hack has to do with time, and all of us, "Are we going to get this done in one week?" One thing I've noticed is that - this is very simple to remember, just remember one and three, that's all you need to remember - if you think about all the work going on in your organization at the moment and you think of horizons, there's work happening in the one to three-hour range, day range, week range, month range, quarter range, year range, and decade range with ones and threes.
The hack here is to think about the nesting of the work that you're working on and try to make that more visible to your team, because what you get, the problem is, what I would call the messy middle, which we're probably all familiar with, which is where anything that can fit on a single PowerPoint slide, a.k.a. one to three year bets, one to three decade bets is in the PowerPoint slide, so everyone sees that. Everything that's in one to three hours to one to three months is in the JIRA system, and then, which leaves this nebulous one to three quarter goal. Is it a goal? Isn't it a goal? What are we doing about it? Are we trying to shoot towards it?
One very useful hack, the third hack is, take some segment of the work that you have in progress, and try to see if every developer can go from their one to three hour work to a one to three decade work in under 120 seconds. I'm making this button more performance so that this workflow is more performance, so that our enterprise customers can get through this workflow, so that they can explore different parts of the product, so that then they can become more successful, so that we can upsell them, so we can achieve our enterprise strategy, so that we can break out of our current growth trajectory, which is too shallow, by going into enterprise. That level of understanding.
Hack the Language
The fourth thing is to hack the language. What I mean by that is that any time you can shift words even slightly can have a massive benefit. For example, instead of problems and solutions, sometimes when I work with people, we use opportunities and interventions, you could see how those words are actually slightly different. Problems are solved, solutions solve problems, we know, 100%. Opportunities and interventions give that sense of they're more ephemeral, like you've either solved it, you understand opportunities will change and interventions may or may not work. Sometimes experiments aren't really experiments, so you might as well just call them bets. Sometimes done should be called a decision point. What if you could call a definition of done and change that to a definition of when we'll make another decision about this? All these debt is a great one, debt sounds like people's fault. Damn them for creating that debt. Another way to put it is just drag, what is this doing? The debt's creating drag in our system right now. That's more descriptive for what it is. Even though I like the metaphor of debt, drag might be more actionable for people.
I was going to go deep into this diagram, but I want to make sure we get to the end. This is the triple diamond, you could take a picture of it because it's funny, but the whole point here is that what's often missing is that we're not really dealing on these three levels at once. We're not talking about opportunities, and interventions, and things. We're just talking about projects, and that's pretty damaging.
This hack is, catalog the language you use and try some subtle changes in the language that you have. If you think that project isn't working, just start calling them missions. "Are you done with that project yet? We're done with that mission?" "What do you mean mission?" "We're just going to call them mission. I get that you're talking about project, but missions work better for us, are you cool with that? Can we just use a different word?" "Yes, ok. I'm cool with that." "Ok," and then you keep working on them.
Designing the Work Taxonomy
The next thing that you can do, like I said about shining the mirror back, I've done this exercise a bunch of times, it's probably easiest if I show you a picture of it. I was at a company the other day, and I said, "Talk to me about the work you have in progress right now," and they said, "Well, everyone knows about tags V1." "Oh, what's tags V1?" "Well, it's the thing. It's the tags project." "Well, tell me more about it." There are designers, there are other people in the room, everyone, it's like redesign V1, everyone has a tags V1.
What was really interesting, this is how the exercise went, they started with one or two things. I asked the designer, "What do you need to know about tags v1?" They're, "It's about tags. That's what I know about it." By the end of the exercise, what we did is, I actually asked them to list all the things they needed to know about tags V1 to make decisions effectively, and that was the list on the left.
One important thing that you can do as a team is to design, and I can just tell you how briefly to do it is to - I'm not into real big, heavy documentation, but even just a checklist of things or reminders that you want to have for a particular team before you jump into something, it can be super effective. The natural response to this, of course, is, "Got it. I understand your exercise, John. We now have our 72-point mandatory product requirements document, it's 12 pages long. Everyone will fill out all of those questions by they get to the end of it." That's not the point at all. Not knowing something can be certainly fine with some types of bets. You're doing this correctly if you have a flexible format for the work that you're doing. The thing you can try right away is, what I would call design a one-pager, do a design activity with your team and say, "If we were to design a one-pager that we could put on the wall, that everyone would be able to understand and make decisions off of, what would it look like? What items would be on it?" Then treat that as a design exercise, and then you can fill that out.
Letter to the Future
The next thing is super easy. I would just call it “A letter to the future.” Let me just ask this question. Let's say one of the teams comes to you and says, "We want to do a retrospective in front of the whole company about what worked and didn't work about this effort, whether we got the outcomes we wanted, and we want to do it for 30 minutes." Raise your hand if, in your company, if a team offered to do that retrospective in front of everyone, that everyone will be, "Great, awesome. Please go and do that retrospective?" Ok, we got a couple of hands.
Obviously, it depends. In some organizations, people wouldn't want that. One thing that you can do that's very effective, and this happens a lot in the feature factory discussion, someone says, "John, we're just told to build exactly this," and I say, "Well, do you guys review the decision?" Do you get up in front of everyone and say, "Look, you made a prescriptive bet. You told us to build exactly this, and these are the outcomes that we saw from building exactly that?" They said, "Well, no. We're already on to the next project. That's long gone. We don't know yet, we've already moved to the next thing to see if it works."
One hack you can do that's very easy is to create a safe decision review in your company, where even if you're doing extremely prescriptive work, once a month, have a handful of teams go up and say, "You know what? We did this effort, it was this type of bet, we thought it would move these particular metrics. Now it's three months later, we're reviewing on it, and this is what worked, this is what didn't work, this is what the metrics are to do those things."
The hack there is that everyone gets so up in arms about outcomes over outputs, or problems versus solution. That's very difficult to hack the system that way, but if you have a team that gets up there, and is vulnerable, and talks about placing the bet, and it not quite working out the way that you thought it would and what they did about it, that's what the company needs to see to rethink maybe how prescriptive the work is, or what they're doing to the teams. The thing that you can do right away is to set up those decision reviews.
Big Maps of Systems
The next bet, this one's really simple, and it's mostly because I wanted to talk about this diagram. If you're having a problem, you think that there's high work in progress, for example, just get your team together and make a map like this. What this map shows is, if work in progress goes up, throughput goes down, time to learning goes up, time to deliver goes up, time to realize benefits goes up, outcomes go down, so you need silver bullets, there's pressure for short-term results, and then morale goes down, opacity goes up, lack of confidence in the teams doing the best goes up, distrust goes up, outcomes go down, morale goes down, you lose key players, you hire new players rapidly, throughput goes down, outcomes go down, pressure is short term, use back channels to get work done, hire human load balancers, higher project managers, etc. It's all very familiar.
One thing I've started to do with teams that are talking about some system like this is, instead of, "I understand you think this is really terrible, but could we just map it out so someone else could see your thought process?" they're talking about, this often happens with technical debt, someone's, "We've got this gnarly thing. It's just terrible," and I said, "Well, let's talk about why it's terrible, can you map out all the impacts that you think it's creating across the system and why it's important? They start doing these types of activities - this is an example of one - but before you know it, no one's going to go to the team and say, "Bad job for mapping that out." It's actually an artifact that the team can use to talk about its anxiety in a safer way. It's super helpful, just do it. Start with one thing, and you can do it.
Flattening the Model
The final thing is something set in three parts, but I think it's super effective. As part of the company I work at, I got wrangled into doing these North Star workshops. I was pretty skeptical because most frameworks, I'm, "Oh, I don't know." In this North Star framework, what you're doing is, you're creating a mental model for how value is created at your company. I'll give you an example from our company because it's better. You create this model, and you use that to communicate to other people what your strategy is.
This has a lot of very interesting effects. For example, where I work, Amplitude, we have a North Star called weekly learning users. We believe our product helps people learn faster. We have three inputs, we need to activate accounts, we need to broadcast our learnings, and we need a consumption of learning. We need people to actually consume those things. The important part about this, if you're an engineering leader or something, is that you could say, "Can we just model how we think value is created? I'm not going to try to change how you're doing your product or your project, but the people on my team just don't know how it all fits together. We don't know what our hypothesis is for how value is created."
By doing one of these particular workshops, there’s something you can do and it's safe because product could be, "That makes sense. Maybe we'll just model that." What that allows you to do is it starts you to do interesting things because now what you can do is that when it comes time to do the particular work you're doing, you can say, "Is our work targeted at that input or that input?" Just that subtle difference when you're talking to your team about saying, how does your work fit into the bigger picture, can be huge.
Suddenly OKRs become easier because they only take 10 minutes, because you're forecasting the impact of the work you're working on one of those particular inputs. It's not super easy, but, in a string of engagements with engineering teams, we've managed to get the product team to bubble up a North Star, "This is cool. This is interesting." Suddenly they laid out their inputs, and then suddenly they were able to start tagging the work they were doing and relating it to the inputs, suddenly the OKRs became a lot easier, and then the engineers working on the front lines were able to say they know how things fit in. If you take it to the natural extension, you start to get a big visual board like this.
This brings together everything we've been talking about today. You have your value creation model, which is your North Star stuff, you have a sequence of bets along the top, you have your one to three-year bets, your three to nine-month bets, your three-month bets, your one to three-month bets, your one to three-week level three bets, you have a hybrid board so you're able to see the work that you're trying and link it to these particular interventions or opportunities.
When people see this, they say, "John, there's no way, no one can work like that. That's all theory," but it's not all just theory. This is a company's couple of hundred engineers, maybe 200 by now. It has all the parts, it has the North Star and one to three year bets right up there. It has the inputs, just remember I showed you the North Star had three inputs going into it, those are your inputs. It has the focusing part of that Kanban board. You notice here, instead of to-do, doing, and done, I have focus-on-next, focusing, and review. Subtle shifts in the language we're using. Focusing means a lot different than doing X, it means that you're focusing on that, which is a big difference.
Then, by the time you get there, you have the focusing area, and then you have the trying. They've got stuff that's working in progress, and then, most importantly, they have a review, all the way over there on the right, which frames that particular board. The action item is just get out the tape and get the magnets and do it. I know some of you are on distributed teams, I guess you could use real-time board. I've seen people do awesome just by taking pictures of their board. A physical board has a lot of salience that virtual boards often don't have.
Hacks Summary
Those are the eight hacks, I will review them really fast. Number one, start using the word bet when some executive is just, "Do this." "Cool bet. Nice. Talk to me about it. It sounds risky, sounds like the whole company is based on that, sounds like you're assuming data engineering will be a commodity in two years." Remember, bets could be anything, it's just your version of the future. "It sounds like our decision to home roll Kafka wasn't the best decision."
Two was, the work takes different shapes and thinking about these like descriptors of work so you can create a common vocabulary in your company about the shape of how work happens, and do these exercises.
The third is to really explore the messy middle. What I learned in the feature factory post - I'll always tell this story, I went to an engineer and I said, "Is it that you really want to own the solution?" "If I came up with the perfect solution, would you be willing to work on it?" They said, "That's the problem. You don't come to us with the perfect solution. You're not good at solutions." That was someone finally saying it really. The problem isn't problem versus solution, it's that they think that solutions suck and they don't see the impact of the solutions. That's the problem, it's not the problem of who does the product owns problems and people and solutions. The messy middle is all about trying to like map this messy middle thing to what are those bets that sit in the one to three quarter range that don't get discussed every quarter, that don't get discussed every half, that just float out there, and is the bastion of middle management, and then it's the cross they have to bear.
The next one is hacking the language, just catalog the language and see if there's anything you can subtly shift. "Are you done with that project?" "Yes, we're done with that mission?" "Is that a problem?" "No, it's more of an opportunity. We'll figure it out as we go along."
The fifth one is, design the work taxonomy. This maybe was the least clear of the things that I was talking about. The whole idea there is that, if I ask you - and I've done this - lay the 1,600 JIRA tickets on the floor, Avery labels, Avery does the card printer so you can print them on cards, if you do that on the floor, could you categorize all your missions and all the messy work that you're doing into this scheme? Those of you who like data modeling, or taxonomies, or heuristics will love this exercise, but just keep going until you can fit all the work into it and don't compromise, don't oversimplify your model because, that once-a-week, kick the machine, make it restart thing is not categorized. Categorize it.
The next thing is, do this letter to the future thing. The whole idea there is, when you do a kickoff, create a letter to your future self when the project or mission is done, and promise that you'll reflect. Create the baselines that you think will happen. You create a letter to the future, and then pick it up and do a decision review back to your company. You don't need to ask for permission for that. I really don't think that if one of the teams in your company said, "Hey, we'd like 40 minutes of people's time. We're going to give you a play-by-play of this effort." I don't think people would stop you. I think you think it's really scary, but I think people will be more open to it than you think, until you do one and then maybe they're going to be scared.
Do these big maps of the system, whether it's tech debt, or high work in progress, or do whatever. Make your angst visual, because then you can actually talk through the impact of the business versus just a generic, we-think-it's-the-wrong-thing-to-do. Then go through this process of flattening the North Star until you can get something like a big hybrid board like this to work. The hybrid boards and North Star have been one of the most transformational things I've done with product teams. It seems so trivial, but the problem with management by objectives, if you've ever dealt in this is that, by the time you get to the work the team does, it's so prescriptive and no one can really map it up to the higher-level work. When you use a flatter system, the North Star is pretty flat, it's just a North Star and some inputs, and you try to plug the work in on that level, it means that you can keep the coherence a lot easier, and then using a hybrid board lets you delineate that you're bringing things in and you're trying them versus just delivering. That's huge.
Questions and Answers
Participant 1: For that last one with the North Star, I'm skeptical that my business can fit in something like that, can you convince me that I'm wrong?
Cutler: Your business can, the question is, what rocks you're going to turn over when you try to do the exercise. Typically, what happens is, they've hired a lot of people with ideas, and they're optimizing to have those people with ideas have their work done. When they bubble up a North Star, you realize that 80% of the things you're doing are one-tenth the value of the most important things that you're working on. That's the challenge that you have.
The thing I would do to persuade you, sometimes you can even carve off one little product, could we create a North Star? The other day I did a North Star, it was just an ingestion pipeline. The senior leader said, "We fundamentally believe that our ability to do that is linked to the highest level value." They just created that one connection. They didn't rock the boat across the whole company, they just said, "Can we give that ingestion team a North Star? Because we believe that that's linked to this higher level goal." That would be an example where you might want to start smaller on one particular part of the overall portfolio of products and see if you could get some leeway into doing it.
Participant 2: Can you give some good examples of inputs?
Cutler: Sure. I'll go back and just use the ones that I can talk to without telling you about another company. In this example, weekly learning users are people in our product who exhibit these learning, sharing behaviors. There are three inputs, so we have to activate the accounts. What's nice about this, is that any product manager joining the company who saw this could actually start on the ground running. We believe we have to activate accounts, some people would call that onboarding, or activating if you're in B2B. You got to get the company going. Most of us can understand the B2B.
BL is the simple act of broadcasting a learning. You go, you create a dashboard, or a notebook, or data science notebook and you share it with your team in Slack. That's a broadcasted learning. Then, consumption of learnings is the long-tail social graph of that particular thing. One person creates that one notebook, and then, I don't want to get into my product, but our whole thing is that frontline teams use it day-to-day to make decisions for their product. We don't want an analyst poking in there and having a five-week turnaround to give you one answer to a question.
If the consumption of learning is weak, or if it's just a one person, that's not the activity that we want to see. That would be a particular example, but we can meet afterwards, and we could just brainstorm inputs. It should be representative of your product strategy. Anyone in this room can look at them and be like, "I know that person's product strategy, what they're doing." Before, our North Star was weekly querying users, and you could see how that might be detrimental to us. Someone sitting there and querying 500 times a day is actually not all that beneficial because we want them to get back to work. We don't want them to be active in the product like that.
Participant 3: When I've done stuff like this, just the current request really, just to talk about the back and forth required to produce something like that, because there's a lot of social dynamics there just to commitment...
Cutler: Super good point about that. This is to the “It wouldn't work in our company.” That's usually the first 5 or 10 minutes. I’m doing these workshops often remote, but sometimes in person. The first 5 or 10 minutes people think they will be measured by this, and they think that they will be pass-fail based on this, and they're much more concerned with not getting the most learning-friendly North Star. They're actually more interested in getting the one that advances their particular goal the most. That's this heavy, social pressure you get in the beginning.
The test that I use sounds weak, but I start with other companies too to get them really warmed up. I'll do a whole series of North Stars from different companies. Your company actually comes up a fair amount, Instacart, others that I have been somewhat familiar with their North Stars. Usually, that gets people thinking about what makes a good North Star, and they start understanding that a lot of it is about learning, and especially with startups, sometimes they're freaked out because they say, "We're not really sure that that's connected to that," and I'll say, "Do you believe it or not?" "We do." "Ok, then it's implicit belief anyway. If that's where you're starting, why don't we start with that?"
The large physical board is a really important part of this. From this particular company, it’s down here, the "non-customer facing" part, which I think is a crock, had "deliver enterprise-grade software," and they found their ability to lock into that. I helped that particular team tease out that particular thing that fit in, and so that was effective to them. I think I lost the thread, but we'll let it pass hopefully.
Participant 4: Can you explain how did the different levels of the organization map into this framework? Is this very team-focused? How does the team go up to larger...?
Cutler: I think that there is a danger to get endlessly fractal with the work and then also a little bit of Conway's Law spills over into your work visualizations. In my experience, and I'm sure there's much more experienced Kanban practitioners or folks out there, the more the visualization can actually reflect the value stream and reflect how value gets out to customers, the more effective it can be.
My first instinct with your question was, make sure you don't conflate the two things. If the org happens to be structured around its North Star, great, but if not, don't necessarily redo all this structuring to reflect how the teams are doing that. For example, in our company, we're experimenting with something now where we have pitch day every quarter, so PMs just pitch opportunities and engineers self-assign to whatever they want to assign themselves to. Whichever PM can make a persuasive case for the data, that's who will get the work, will go on to it, and then the pods align themselves with one of those particular North Stars. From a structure standpoint, we try to keep it very flat and then teams latch on. You'll notice that this board is really flat too, there's not more than three levels or four levels deep with this.
See more presentations with transcripts
