TBM 435: 20 Unfiltered Operating Takes

I had a friend reach out recently for advice. He said something funny/telling. “Half the time I don’t know what you really think. I have to figure out how my team works. What is your actual, opinionated advice?” So here it is: advice for a friend on how to operate. Raw. Not “polished John”.

I wanted to send a huge thank you to my paid subscribers. They don’t get anything in return but still support the newsletter. Until recently I didn’t have a way to do a one-off tip. But now I do. I you like the newsletter, consider…

North Star Framework

“Should I try to implement the North Star Framework with my team?”

(Note, I wrote the North Star Playbook while at Amplitude, with Jason Scherschligt)

North Star Framework is an interesting idea, but it is probably most valuable as a teaching tool, not as a practical practice. That isn’t to say that some companies don’t “do it”, because they do, but that it is more valuable when it comes to teaching things like leading/lagging metrics, actionable inputs, building (and testing) causal models, avoiding vanity metrics, and the “art” of crystallizing a unique strategy for your company vs. playing a standard game.

When I check back with companies/individuals who attended workshops, it is very common to hear something like, “I learned a lot, and we sort of adapted many of the ideas. We have multiple KPIs, leading and lagging, and some things aren’t as worked out.” The people who didn’t get value out of it tried to install it as a framework and eventually hit resistance with the inevitable edge cases, exception handling, etc.

This is all to say that what follows will work in some of these ideas, but will not be about the North Star Framework.

(Here is a Miro activity library for NSF)

Trees/Pyramids

“Should we build out one of those vision-to-tactics pyramids to get everyone aligned?”

Next, this might sound heretical, but I don’t recommend “pyramids” that build a tree starting with vision, strategy, tactics, etc. I know they are super common, but I find that they often end up distracting people. If someone owns something, and if people are working on it / working towards it, then by all means make it clear. But most companies end up with a bunch of buckets and maps that seem wholly designed to “simplify” things for leaders, and to abstract the idea that lots of real work is happening.

There’s nothing wrong with label taxonomies, but people start to imagine that those labels are real things. Most of the time they aren’t—they are roll-up mechanisms, and seem mostly designed for 1) deckware, 2) and a false sense of organizational symmetry or “clear” roles and responsibilities. Sure, make a pyramid slide if you need that kind of thing to leave leaders feeling aligned, but then put it to the side to start generating impact.

Put another way, there’s only one place that “the work” is happening, and that is at the front-line team level. It may have gotten there through layers of the org, but the work—the problem solving, creativity, hands on keyboards, interactions with customers (hopefully), etc.—is happening on the front line. Real strategy is messy, non-hierarchical, might span days or years, and doesn’t fit into neat boxes, so don’t waste time trying to do that (or at least don’t waste too much time).

Stable Teams?

“Everyone says we need stable, durable product teams. Is there a downside?”

There has been a lot of talk about “stable” product teams, but I wanted to dig into the dark side of this. A lot of companies are struggling because they build internal kingdoms around “stable” teams. They rationalized these highly durable capabilities that would exist until eternity, based on sort of irrefutable logic (we’ll “always need that”). Or, they wanted to build something, a short-term project, and everyone was busy, so when money was plentiful they just spun up a “new team” to build it. And then a director. Then a GM. Before you know it you have three layers of hierarchy built around “products” that didn’t really exist.

And then…the only way to unwind this is layoffs that really impact people’s lives. Not because you couldn’t, in theory, re-assign those folks to different areas—because you could—but because the physics of the org chart, and how layoffs work, necessitate you to blindly unravel your prior org chart decisions.

Which is all to say that “stable” teams and “durable” ideas are only useful until they aren’t useful, and sometimes knowing the difference is hard. Of course, leaders will not say this outright (or at least the CEO’s who speak publicly about layoffs). They might make vague mention of bureaucracy, the “work around the work”, etc. But the reality is they scaled too quickly when money was more plentiful, and now need to rationalize how to unwind all of that.

Shipping Smaller/Faster

“How do I get my team to ship smaller and faster?”

In my experience, it is way easier to teach a team that can work small to think big, than a team that thinks big, to work small. Both are possible, but they require different approaches. A team that can deliver continuously, regularly, get frequent feedback, and generally keep the tempo of changes, assumptions tested, and risk reduced HIGH, is a godsend. It is a gift. If you have fostered an environment AND the skill/experience landscape to make this possible, you should always cherish it.

Now, that sometimes means the team will be short-sighted, and may iterate to nowhere. You run the risk of having a “functional” feature factory with broadly usable things that don’t really move the needle, but if you can do this you’re well on your way. As mentioned, this is part environmental. You can absolutely have people who are good at this at their last company, completely flounder if you’re constantly interrupting them, changing the strategy, loading them up with WIP, and always asking them to prematurely converge on estimates, etc. Environment matters.

But creating that environment AND working small are skills you have to hire for, and nurture internally. Put another way: you can’t make shots you don’t take. The team has to be able to get changes out into the world and HAS to be able to measure impact. They also need chops at rapidly considering options, and figuring out how to slice up those options to get the most leverage possible.

Cycles

“What’s the right planning cadence? Quarters? Sprints? Shape Up cycles?”

Quarters are too long to help you work small, and too short for the bigger, meaningful things you want to do. 2w sprints are too long to help you work small, but too short for the big meaningful things you want to do. 6w is actually a decent forcing function, because you can fit some pretty darn meaningful things into 6w, but if you are operating a company at any sort of scale, you might feel a bit of whiplash thinking only in 6w bets. It is doable, but you’ll find yourself 1) tackling things that are actually bigger than 6w on occasion, 2) losing a sense of the more durable “lanes” in the 1-3 quarter range, or longer.

This is all to say that time is WEIRD. It always feels too long, and too short. There are always opportunities to work smaller, and there are always situations where working small misses the “bigger picture”. But here’s a bit of philosophy: life is only happening NOW. We are navigating a landscape shaped by past decisions, and we are forging ahead into a partially knowable future, but at the end of the day what really matters is what is happening right now.

Why is any of this important? First, don’t get beholden to any one cycle as “the” cycle. You are almost certainly missing something. Second, don’t let your selection of cycle get in the way of working small (or thinking big). The number of teams I see chasing their tails because of some arbitrary quarter cycle AND magically making all their bets take one quarter is insane. SHIP! LEARN! Don’t wait around for a quarter.

If quarters are causing some sort of wholesale rebalancing of effort, that is a sign you 1) probably need to be working smaller AND 2) probably have some tough prioritization questions to make in the longer timeframe. Instead, people treat these cycles at any duration as “boxes to fill”, and it is incredibly damaging. A quarter is not a big sprint. It never was. And any effort to scale up “sprints” to “quarters” to make them somehow more corporate-compatible is a perversion of the idea.

Lanes

“What does it actually look like when a team is really humming?”

All the best and most productive/effective times in my career have followed a pattern. A handful of somewhat stable “lanes” with a couple metrics and directional sense of the opportunity, and then a team just cranking it out week after week. What happened last week? What’s happening this week? What’s working? What isn’t? You’ve probably felt the same thing at some point.

The puzzle here is that despite how salient this all feels, it can be devilishly hard to recreate these conditions. People look at all sorts of frameworks, devices, tools, tricks, etc. yet the actual “feeling” is way simpler. It feels like: a tension between the more stable, and the more rapidly changing. It feels like: a strong bias for action and movement (even if that action is discovery/learning). It feels like: talking about things you DID and what you learned, and less about talking about all the things you plan to DO, and all the things you hope to LEARN. 80% of the energy is on the here and now.

This doesn’t mean that everything is short-term and myopic or “purely tactical”, because you’re like a mountaineering group navigating a mountain where you are always scanning at multiple resolutions AND choosing your next step wisely.

Why is any of this important? Teams will go to the ends of the earth to avoid this motion because it is scary. They’ll invent all kinds of work to get in the way of the sheer, raw, unfiltered act of getting stuff done, and holding each other accountable. And course correcting based on what they’ve learned. They’ll spend weeks and months “going back to the drawing board and building alignment” because they are scared about the sheer act of doing, and potentially marching off in the wrong direction.

So it is like this elusive “vibe” that you know when it is happening, but can be hard to get into for various reasons—with all sorts of excuses we make to ourselves and to each other about why it isn’t possible. I don’t think this is laziness. It is very human fear. It is the fear of forward momentum under conditions of uncertainty. It is the fear of “picking the wrong things”. It is the fear of showing up at the meeting and saying “oh yeah, a million things came up last week, we need to have the uncomfortable discussion about whether I should have said NO to those things.”

Humans doing normal human things in the context of the team creates these conditions. So the burden is that we’re ALWAYS trying to converge on this vibe, and always slipping out of it. That is the work—of ICs, non-ICs, everyone.

Deciding On How You Work

“I’ve got a bunch of senior people who can’t seem to agree on how to work together. What do I do?”

Experienced teams/people are especially prone to this: you can get a bunch of smart people together and half the time is spent just reconciling different variations of how they like to work, and their quirks. People can be terribly “nice” about this and try to fill in the gaps. But experienced people, especially, often just want SOMEONE to decide how things will work. It isn’t because they can’t figure it out—they can—but all the waffling and gap filling, and back channel influence can be a huge drain. Can someone PLEASE just define the game and the playbook and let’s get moving!

This doesn’t mean everyone needs ultimate certainty or needs all the t’s and i’s dotted (experienced people rarely need that), and with water under the bridge you rarely need things concrete and explicit, but when you get a group of smart people together who haven’t worked together, you should bootstrap the whole thing with “V1” of a way of working that people generally agree with, and get moving. Leave all the theorizing for the future. The team can adapt as it goes along.

Note: I’m not talking a dictatorial motion here. You could collectively decide to get in a meeting, write some initial working agreements, and go. Or you could say “Hey Bob, I hate to do this but can you just hammer out the V1 for how we’ll work”. Either way is fine. My general point is that teams waste so much time and brainpower trying to arrive at a reasonable game, and I think it is better to just start with V1 and go.

The big risk here, of course, is that the person trying to figure out this game is trying to oversimplify it, deck-ify it, or make it palatable for the people who aren’t actually doing work, which ends up meaning you have a starter OS that doesn’t really reflect how people work. It is a showpiece. You don’t want that.

Estimation

“How precise do our estimates need to be?”

You don’t really need to estimate at resolutions more than 1-3d, 1-3w, 1-3mo, 1-3q, 1-3y. That’s it. Anything more is a waste of time. Importantly, be very clear about the “thing” and make sure you’re working at the atomic level. You can have a big messy project that is 1-3q, that while being amenable to “breaking down” is just what it is. It is a 1-3q bet.

It might help you to imagine a bunch of 1-3w and 1-3mo bets that “add up” to this big thing, but the important thing is you have a 1-3q bet, and you’ll have to figure out how to work small, de-risk often, and use your company’s money wisely. You could also have a 1-3q bet that is more open-ended, amenable to experimentation, has a bunch of pivot/proceed points, and can be funded iteratively based on outcomes and progress. OK. In that case it may help to think of it as “housing” a bunch of 1-3w, 1-3mo bets. That makes more sense.

But it is an inherently different relationship between the “things”. You don’t need to finish all the “things” for the big thing to work, whereas with the 1-3q big messy project you probably will need to make significant progress across the things. In the experimentation friendly example, you might only need the first couple. In the big project example, you don’t need all the details, but you do need a strategy for de-risking the thing over time.

With both, you can STILL meet up every week and talk things through, and you will still (hopefully) have inertia every day towards the goal, but it is a different motion. So: don’t tear yourself up with estimates.

Lanes Revisited

“How do we organize ongoing work that isn’t just a list of projects?”

I had a mentor once, a product leader, who just showed up one day and said “Look it is all about the lanes.” He was referring, roughly, to more durable, outcome oriented swimlanes. They might show up on a roadmap, on a slide, etc. This was a deceptively powerful statement when you understood how this played out in practice. We’re not talking kanban lanes (which tend to depict a workflow), and we’re not talking about value streams, though the idea is similar. Sure, you can use a lane for a long project, but that isn’t the basic idea.

But basically: “Hey, for the next couple months or quarters we’re going to keep these couple things stable, revisit them, measure them, and let them guide the way. And when they stop making sense, we’ll change them or pivot.” This seems so basic, but it isn’t. It is far easier to come up with hand wavy strategic pillars, or generic “buckets” that all work falls into. Or to come up with discrete little projects. It is much tougher to find that perfect balance of durability, outcome-oriented, actionability, non-fluff, customer impact, causal model, etc. that a team can ACTUALLY work with.

This was one of my learnings with the North Star Framework. One of the real benefits of the NSF was the idea of the actionable inputs and really tweaking those until you had some that held together and withstood the test of time (but weren’t so open ended, or so “bucket-ish”, that they didn’t really guide any action). The idea is somewhat fractal, although any time you start making trees of things, you have the potential to water things down.

Imagine a company with 150 teams. That is about 450-600 lanes, roughly. With some lanes for the big stuff that has to cross teams. “Oh god,” the leader says, “That is so much. There’s no way I can possibly go into a meeting and discuss 600 things.” To which I would respond this way: your lanes are costing you millions of dollars, or at least in the high six figures (think a team might have a couple that stay stable for a year). Are you really telling me that you can’t bother with understanding your million dollar investments? “Oh, but we will when we roll those up,” … to which I respond, “Oh really, to the extent that you’ll pressure test these very real bets?”

Here’s my take. Just admit you have 450-600 durable lanes, and use AI, routines, and rituals to hold yourself accountable. Use label taxonomies if you really need to roll stuff up. But realize that the work is happening at the lane level.

Shapes Of Work

“Can we treat all our initiatives the same way and use one template?”

Lean into the fact that things have different shapes: different risk profiles, different levels of experimentation friendliness, different “sizes”, etc. I’ve never done a shape exercise with a team and ended up with anything lower than 5-8 key shapes of work. This is not about being overly pedantic and categorizing everything, it is more about never imagining you can see initiatives, epics, bets, or whatever as apples to apples, and resisting efforts to standardize or oversimplify.

I’ll give you an example. Most companies have a launch tier where product marketing describes the nature of the launch from a marketing perspective. But guess what? Some things are going to be incredibly disruptive internally, and require a ton of coordination, but marketing isn’t going to make a peep out of it to customers. In fact it may be critical for customers not to know anything about the launch. The “simple” distinction between internal blast radius and external launch demands has confused so many companies I’ve worked at, or advised….just that tiny distinction. 9/10 someone in marketing would say “yeah, but we need to keep it simple”, and their categorization scheme would pervade with executives and others.

Don’t do that. It doesn’t mean that everything needs to be analyzed to death—but know that the work we do defies simple categorization schemes and labels. To get around this: don’t use templates. Look at the THING. Read it. Write about it. Be explicit. Let people raise the nuances. Surface the differences that really matter. And do anything you can to not flatten everything you do down to someone’s slide deck. Sure… you may eventually need the slide deck, but that isn’t reality.

Routines (Creatures Of Habit)

“How much process does a team actually need?”

Routines: it doesn’t matter if they are explicit or implicit, but have them. Great products are built on routines. They can be very fluid. They can be more strict. But they are there. These collective habits are what makes great work happen.

The key problem is the degree to which routines either 1) get processified to the nth degree, all but eliminating any chance that they are effective, or 2) are so implicit and so loosey goosey that when something changes, it makes it hard for the team to reset quickly. A group of experienced people can go very far with just “meeting when it makes sense”, but even experienced people are vulnerable to the traps. They are vulnerable to the traps of not raising risks because it is uncomfortable. They are vulnerable to the traps of avoiding hard conversations, of getting carried away with status quo bias and not challenging their direction when it makes sense, and putting off the tough call “one more week”, when they really need a coworker to set them straight (or at least try to).

Routines are the heartbeat. And I think to some degree we are creatures of habit. We start enjoying our routines when they help us regularly. You can make the agenda variable, but it pays to get people in a room (virtual or otherwise) to connect.

Everyone has been on that team that starts with best intentions, has a great weekly meeting, stays on the gas, and then as elephants in the room accumulate and priorities fracture, they start to lose it. Leaders spend more time in other rooms planning for something far off, than connecting on what is happening right now. People do 1:1s to plot out what’s next after the impending collapse everyone knows will happen. All to say that if you can push through—push through that thing that happens four weeks in where either 1) it becomes a zombie meeting everyone sleepwalks through, or 2) it stops happening all together—then you’ll be better off.

AI

“How is AI going to change how we work?”

AI? AI will turbocharge your bad habits and turbocharge your good habits. My hunch is that 80% of the world stays exactly the same, all the principles apply, and now you have this tool to do better work in all the ways you know how (hopefully). You could use it to do things you know you should have been doing this whole time, but didn’t have the time in the day. Practices are changing every week. One week it is ____ engineering. One week it is ______ engineering. Back and forth. So yes, you will need to innovate on the practices, but expertise still matters / chops still matter.

Example: say you have an org that was running a feature factory before AI. BETTER feature factory. Say you have a team that was thoughtful about collecting research but was short-staffed, and couldn’t keep up with organizing their research library. Bingo! Better at all that. Amazing. Or you knew you needed to instrument analytics, but never got around to it. Write a skill. Instrument more analytics. Boom!

The real danger is that some people don’t know what good looks like, or have never worked in an environment that did truly high leverage work, and that’s setting the bar for them around what they think AI can help with. Another example: synthetic personas. Before AI I could create a synthetic persona. It took a bit, but it was doable. With AI I can make terribly persuasive synthetic personas. Is it a good idea? For what? For what boundaries? For right now, at least, only skill will give us an answer there. It is going to be a wild ride, and practices a year from now will likely look very different (while we’re potentially digging out from a huge crash and picking up the pieces).

Outcome-centricity (Misunderstood)

“Everyone says be outcome-oriented, but how do you actually do it?”

Outcome-centricity is hard, and I’m tired of people describing it like some kind of mindset, etc. There’s a reason why the cart optimization team at an ecommerce company gets more love/attention, than some team doing design systems. It is closer to money. There’s no free lunch. You will need to build a causal model that starts with near term things you can influence, linking up to the long-term things that will propel your company forward.

Even harder, it isn’t all math, or even mostly math, because you are SHAPING the future as well as measuring the changes you introduce, and how they impact near term things. If it was an easy math formula, everyone would be doing it. It isn’t! It takes conviction, leaps of faith, etc. As I always say, if everything was an A/B test and you knew the lifetime value of every customer, and if every pattern that happens now has happened a bunch of times in the past, then you are a phone company, and you are a commodity.

I mention this because all the talk about projects to products and outputs to outcomes, etc. etc. is way too theoretical. It doesn’t get to how uncertain it is, and the mix of math, conviction, storytelling, and narrative you need to make it all work. So it leaves teams feeling they’re never doing enough, and completely negating the routines and practices—the staring at input metrics, revising, discussing assumptions, checking, monitoring, switching things up—needed to make it all happen.

I worry I’ve been a part of this, though I try to make a big point that you can think of outcomes at various time scales and resolutions, and that it is all a “model” that we keep refining. Or at least I try to.

Better Questions

“Do we need to have all the answers before we start moving?”

Related, what really matters is that you’re always asking better questions, not necessarily that you have all the answers. You can improve your ability to answer questions over time. But some teams do activities where they are GREAT at asking powerful questions—things that really land—but then they seem to go back to ho-hum business as usual. It is like they take off their “good question” hat because they’ve had the “oh you’re the type who doesn’t get anything done and only asks good questions” line.

Not coincidentally, asking better questions is a function, in a sense, of getting answers. Answers let you sharpen new/better questions. This all goes back to routines and tempo. You’re knocking out work on your lanes, you’re asking good questions, you’re getting some decent answers, you’re double-checking your core assumptions, you’re progressively moving the needle….that is far better than having the perfect answer in every meeting.

Good Goals

“How should we be thinking about goal-setting?”

Goals. Set them. But don’t be ruled by them. Goals can be set for anything: learning goals, shipping goals, outcome goals, goals on near-term metrics, goals on lagging metrics, goals on practices, goals on continuous improvement. The big anti-pattern I see is that people just go through the goal motions, and they don’t mean anything. Or they just dream up everything they want to do, and goals are sort of the “success metric” afterthought. Mix up your goals—prescriptive, descriptive, near term, long term, leading, lagging— and lean into the HABIT of goal setting, not the performance of goal setting.

More…

“Anything else top of mind?”

A couple more to make it 20:

1. Lean into anchor artifacts: stuff you write and revisit, vs. always reinventing the latest doc format, the last initiative brief, etc. Revisit. Do they still make sense.

2. Real progress can be sensed daily and weekly. Even if it is “big stuff” or “hard stuff”. It is all about coaching the team in how to break things up without losing the big picture.

3. I get tired of the “leaders are the only people doing long horizon” idea. Anyone at any level can be thinking about multiple horizons. More experienced people can often reason about longer horizons a bit better (or know when reasoning over longer horizons doesn’t make sense), but ideally you have those experienced people on the front-line. If not. Why? There’s gotta be some power ICs who love showing people how to do the thing.

4. I always say this: but powerful ideas imperfectly measured are more important than perfect measures for not so powerful ideas.

Boring Product

“What does good product work actually feel like day to day?”

Boring product. It is in the doing. Every day. Every week. Moving things forward. Thinking across horizons, but not being caught in the past, or dwelling in the future. It is a collection of habits. You can tell a mile away when something isn’t working for a team. Just listen. Do you hear it? Do you hear the motion? The learning? The connecting the small to the big? Or is it always like a movie that never seems to find its footing. Trust your instinct with that.

Hopefully this was interesting. I know my writing doesn’t seem actionable sometimes, but I do my best to get advice out there. My Achilles heel, which is probably evident in this post, is that I know a ton depends, and a ton of this is about nuance and rolling with the changes. Let me know if any of this helps.