Transcript

00:00:00 - Speaker 1: A theme that runs through all of this, whether it’s a big company or a small team, is it’s really about building our collective knowledge. We can extract all the most relevant pieces of information from everyone’s domain and bring them together. From that comes a plan that we all feel ownership for, and then when we go off to do our heads down work, we’re working off that shared plan where we for a brief moment, brief beautiful moment in time, we understood the problem in a totality that no single human could.

Hello and welcome to Meta Muse.

Muse is a tool for deep work on iPad and Mac, but this podcast isn’t about Muse product, it’s about the small team and the big ideas behind it. I’m Adam Wiggins here with Mark McGranaghan. Hey, Adam. And Mark, I don’t know if I told you, but my Christmas gift was a used guitar, acoustic guitar, and I’ve been blinking around on that, maybe not quite at the same level as devotion as your piano studies, but I’m quite enjoying it and I found myself reflecting on the tacit knowledge revolution of YouTube theme that you’ve brought up multiple times on this podcast because the last time I tried to play guitar, I don’t know if it was in high school or something. And you would seek out these COVID nuggets of knowledge from just people you would meet or whatever and lessons were expensive and time consuming, but now you just go on YouTube and there’s just tons of people who will just show you exactly what you want to know at whatever pace you want in great detail. You can watch it in slow motion if you want, you can rewind. That’s a really incredible way to do self-learning, particularly if you’re not that devoted to it. It’s just kind of a little side hobby when you have a few spare minutes.

00:01:47 - Speaker 2: Yeah, it’s amazing what you can find on YouTube these days. It’s so helpful. Now, for you, is YouTube the primary source, or do you also do an app or do you do Zoom lessons?

00:01:56 - Speaker 1: There is a guitar tab app, you know, essentially a tab is like the sheet music effectively for guitar. We can look up a folk song or a popular song and find out how to play it.

Actually, our colleague Yulia, who plays the ukulele a bit, pointed me towards that.

So that’s nice for learning a specific song, but it’s more about technique, which is, OK, you know, I’d always got to figure it out with like plucking with my fingers, but maybe, you know, playing with a pick could be a good technique to learn, but when I try to do it, it sounds terrible.

How do I do that? And again, there’s probably a conventional method of, you know, you sign up for lessons or whatever, but I just don’t have time, interest, whatever for that. But this very self-directed method of I can just type into the YouTube search bar, acoustic guitar, beginner strumming technique or beginner picking technique, and inevitably there’s dozens of really high quality choices.

Well, I’ve got exciting news to share.

Muse for Teams is now in beta, so it’s open sign up. Anyone can go to the Museapp.com/teams/signup page and you can pick a team and try it out. And essentially this takes the thinking tool of Muse that we’ve been working on for a few years, but adds these collaboration features, what you would think of from like a Google Docs or a Figma with the avatars and the cursors moving around the board. But we’ve had this in kind of an alpha test with a small number of teams. The last 5 months or so, and we’ve done quite a lot. I’ll link out to the announcement there, everything from a new NavA and board Zoom and connection tool, as well as all these collaboration features you expect like comments and following and copying board URLs. So yeah, we’re really excited to share that with the world and it was quite a lot of hard work by everyone on the team, including both of us. So give ourselves a little back pat for that and we’re looking forward to hearing what everyone thinks.

00:03:48 - Speaker 2: Yeah, I’m really excited. This is one of the big pieces in our long term puzzle collaboration, so excited to see it finally land.

00:03:57 - Speaker 1: Indeed, yeah, I think we’ve often spoken about that long term roadmap as the do the individual thinking tool on the iPad first, then we go to the multi-device with kind of Mac and iPad and the local first sync between them, and this is that next step, is being able to collaborate with others when that’s appropriate.

And yeah, I’ll link out to the announcement post that has all the goodies and screenshots and videos and everything like that.

But what I’ll direct your attention to for the purpose of this podcast episode is there’s a whole sample workspace that’s included with the new onboarding, and there’s also a templates button in the toolbar that basically lets you add some templates, and if you were to click on that, you would notice that all the entries are things that are around this theme of planning.

And so, we’ve decided that based on how people were using the alpha, that kind of narrowing the use case to or kind of a set of use cases around the theme of planning or planning together with your team, is a great place for us to focus.

It’s a place that Muse can. Be kind of best to breed even though it’s a very general purpose app that can be used for a lot of things in the collaborative space. We think that this planning realm is where we can really excel, so we’re excited about that, but it naturally leads into our topic today, which is planning. So, let me first pose the question, as we always do, Mark, what first comes to mind when you hear the word planning or planning your work?

00:05:27 - Speaker 2: Well, I certainly get a lot of emotional connotations, as I’m sure everyone who’s worked in product development does, but simply I would just say it’s the team discussing and deciding what to work on in the future. What about you?

00:05:40 - Speaker 1: Yeah, so I think there is almost a knee jerk or an immediate thing that comes to mind, which is basically long meetings, listening to laundry lists of details about other people’s work that isn’t really relevant to you and is kind of boring, and yeah, just this really kind of nuts and bolts, just let me get back to work. Why do I have to sit through this doesn’t feel like work, something like that.

Indeed, when we were first discussing on the team, whether planning is something that we really wanted to focus and use collaborative product around, there was some level of, I’m not sure what you call it, groaning or yeah, folks have that same, I think visceral reaction that I do in some ways, which is planning’s boring, and we don’t want to make a boring app for a boring thing. Why in the world would we want to make that be our big focus? And indeed I ended up writing a memo based on reflecting on this called Against Boring Planning, again I’ll link that in the show notes here, but when I stopped to think about it, it comes down to the kind of good versus bad planning. If I can go for such a direct value judgment there, which is planning your work as an individual or together with a group, when it has these bad vibes, I think it is because, so you’re not doing it right, and I have been on a lot of teams and have had a lot of experience. that are like that and reflecting back now, I think, OK, that wasn’t a good way to organize a team’s work.

But when I think of the positive vibes and the good kind, let’s call it good planning, you know, I think, OK, I’m getting together with a group of people that I like, or at least I work really well with, to think about what’s the next step in achieving a mission that I really deeply care about, and we need to get into the difficult questions and the trade-offs and think about what capabilities our team. Has to bring to bear against the opportunities that are in front of us, which you know might for a product team be as simple as, you know, feature requests and bug fixes and things like that, and going into it and really hashing it out and coming out of it with a sense not only of specifics like, hey, we’re gonna work on this first and the second, but also who I’m going to work with, what’s exciting about the projects and Just a sense of being inspired because it makes concrete that next major iteration of work again against a mission that I’ve signed up for in my career or whatever team I’m on currently. And yeah, a great planning meeting is honestly a really enjoyable and inspiring experience and I come out of it thinking, OK, now I’m really excited for the work that’s ahead.

00:08:15 - Speaker 2: Yeah, one of the things I’ve learned, having experienced a wide array of planning processes and outcomes is that it’s a very a chemical process by which I mean in subtle ways it can go very well or very poorly, and a lot of it has to do with inspiration and motivation and interpersonal relationships and stuff. So it’s kind of a subtle process. It’s very easy to wear a lens in which you only see the mechanical stuff, you know, these tasks in this order and this assignments and so on. But I think the key to good planning is getting that alchemy right, and like you were saying, getting everyone motivated and aligned behind the vision.

00:08:48 - Speaker 1: Yeah, there does seem almost like a, I use the term working chemistry often, maybe we’ve talked about that in the context of team building and recruiting and so forth, but yeah, there is a special magic when you get the right people together, working on the right problem and you have a good plan.

But it’s more art than science, that’s for sure.

Yeah, when I reflect back on my own career, for sure, I certainly didn’t think that hard about it in the early days, but I think it was at Hiroku where I really started to think in terms of management as more of a first class concern, and the team was growing maybe more quickly there than other teams I’ve been on in the past, and I did end up going a little bit down the rabbit hole of say like agile methodology, which I found interesting or codified a lot of things that I thought were good about ways to work.

But I also got really into say like project management software. So back then, yeah, you had probably Jira, there’s all kinds of different kinds of ticket trackers, open source and commercial that often had like the ability to do different kind of like timeline road mapping things and Gantt charts and you could do burn down charts and you could do all these things that seem to bring a kind of systemization to the work a group of people was doing.

One that I remember liking was Pivotal Tracker, which was by a kind of a consulting shop in the Ruby Agile world we were part of and was really well made and encoded a lot of their processes, but using that product actually was an eye opener to me because it really encoded their team’s process and their teams. Way of doing things, which I think was good for them, but maybe was a questionable fit for us and indeed even through the course of Hiokku as the team scaled and as our needs changed and as the business was more mature, we just needed very different things all the time and so there was no one.

Kind of single process and certainly no one single tool, and especially the more the tool encoded a lot of process and was really rigid and structured like a lot of these project management software tend to be, the more you’re forcing your work and your team’s shape into the software that encodes this process.

Actually it was probably around that time I discovered Trello, which is still, I think, a great piece of software for its incredible simplicity, although I think to some extent the conbo boards built into GitHub issues and notion end up competing with it, but at least that had a certain simplicity, the swim lanes and the cards, and there’s a lot of different ways you can use that. It’s more like building blocks that you can use to develop your own team’s way of planning things.

So I think it was the whole Hirogu experience that really took me into first of all, caring about this. As opposed to coming at it from the crafts person perspective, which is like, I don’t want to think about planning. I just want a process. I just want to get back to doing my work and I saw what a big difference it made to, you know, if you’re really all on the same page about what you’re doing, you just do a way better job and you go faster and you make fewer mistakes and you waste less work. And I started to care about it there, including the tools and the processes. What were some of your early experiences with planning, I guess, in the form that may have shaped how you think about it?

00:11:51 - Speaker 2: Well, at Rokku, I saw quite a range of both company scales and teams, so I sort of bounced around within the company, so I got a little sampling across both of those dimensions, and I feel like that taught me a lot, and we can talk about some specific examples if you’re interested. And then later at Stripe, that was a larger company, so I got more experienced with more involved and necessarily complicated planning processes, both because of the size and because of the complexity of a regulated financial services business. So I feel like I have quite the array of experiences to draw from for better horse.

00:12:27 - Speaker 1: Yeah, for sure. Well, and if you want to consider the low end of the scale there, you know, we started Muse, it was just me, you and Julia. So, you know, we just kind of sat in a room and said, hmm, what are we going to do? Well, how about this? I actually remember that at my very first business, even long before Hiroku, we just wrote everything we were working on on a whiteboard, the end, because it was me and one other person, right? And that really worked great for quite a while.

But I haven’t experienced that bigger scale. I think for me the biggest, well, even company I’ve been a part of is around 100 people and you know, you can debate. It’s probably more about when you say team, does that mean the whole company? Probably not. You’re talking more about the people you work with kind of directly day to day, but you’re much more scaled up experience with Stripe, particularly I assume by the time you left there and they were getting a big company. I’d love to hear some more stories from that because that’s way outside my realm of experience.

00:13:22 - Speaker 2: Yeah, probably my most memorable planning experience at Stripe was, it was towards the end of my, my time there, and the company was getting bigger, solidly several 100 people plus, and we were just starting to grapple with company-wide systematic planning because the more informal and ad hoc processes that we had done were sort of breaking down, especially with respect to visibility throughout the company and dependencies, which are a big deal in a financial services firm.

And so I ended up actually helping with this process whereby we did a company-wide planning and there was a there was sort of a template. I forget the exact form, but the basic idea is that a company had a vision and metrics and proposed projects for the quarter or the half, I think it was. And those were reviewed in several ways. Obviously the team worked on a draft plan. They were also reviewed upwards, so like the head of engineering or whatever would review engineering plans, but there was also a pretty elaborate dependency management exercise where I made a big spreadsheet. I think it had like 25 rows and 25 columns where each row and column was a team, and if you created a dependency on another team, so for example, if I was standing up a new payment method we needed to work with the risk team to ensure that risk was appropriately managed and the compliance team and the legal team and the infrastructure team and and the country team and so on. And so you would like fill in each of those cells in the spreadsheet and then the team that was kind of receiving that dependency would have to review it and basically sign off on it. It was sort of a forcing function because the problem we were having was Basically, product teams and other teams were quote unquote planning to launch a product and then like not telling people who are impacted about it, and then be like surprised and payment method or whatever.

Not only was that a surprise, but often these products will get stuck halfway cause they didn’t have the full array of teams and support needed to actually fully launch them, so it’s kind of worse than doing nothing.

Yeah, and so we had this huge spreadsheet and teams would go by and review and initially it was really bad because In accordance with kind of the original problem statement here, a lot of the receiving teams were like not aware of the dependency or didn’t believe they could support it or thought it was too much to handle or was out of scope or whatever, and so we had to iterate across the entire company on this huge like 25 by 25 spreadsheet over the course of a few rounds, but it eventually got much closer, like there’s a lot more green on the spreadsheet, you know, people were aware of the dependencies and could accept them and After that, we did some work and I hope that they have continued to do some work to kind of remove the need to have so much dependency management because the idea is, of course, that you don’t have so much dependencies. But that one really stuck out at me as one of our first big company-wide systematic planning exercises.

00:16:13 - Speaker 1: Wow, yeah. Also, I like you’re doing that on a type of a canvas, which might hint a little bit of why we think Muse is a good or canvas tools in general are potentially good approach for this kind of work.

Yeah, well, the stripe example certainly reminds me of what I was exposed to just a little bit, kind of, let’s say indirectly through at Salesforce, and they had this kind of cascading top to bottom thing called V2 mom. Which was similar in some ways to OKRs, the details are different, but part of the idea is that, yeah, you need this cascade where things can go, we tend to use the up and down spatial orientation for, you know, senior management versus people doing the work directly, but you need this thing where the top level people are away from the day to day, but they also have maybe some of the longer term views on where the market is going and what the business needs, and so you need to kind of propagate information in both directions, and yeah, it is this whole giant exercise of dependency creation.

And one thing that stuck with me from that time was, I was really trying to design the Hiroku organization and now we were getting into this like I don’t know, 75 100 people range where individual teams to kind of have their own autonomy and dependencies could be kind of expressed through APIs, but as much as possible, we try to just not create dependencies because, you know, we all know from software development systems that you want to keep your dependencies to a minimum.

But I have a very distinct memory of spending time with a fellow named Jasper Jorgensen, who had come over from the salesforce side and had a lot more experience working in larger companies, and I was kind of articulating this to him and he said something that really stuck with me, which is basically why did you join a company if you just want to work independently on something. You wanna work independently, you know, you could be a freelancer or a really small team. The reason to sign up for a company or a major, you know, department and a company working on a single product is you can do more with that larger group, but then by definition you need those dependencies. The fact that Stripe, for example, has to launch a payment means you need to also think about Fraud, and you need to think about legal implications and you need to think about all these different things across the business. That’s sort of a feature. They can be big and do big things in the world and have this global impact because of that, but the cost of that is call it just coordination.

00:18:40 - Speaker 2: Yeah, and people like to, you know, dunk a little bit on V2 mom or make fun of it because it’s a five letter acronym comes from Salesforce, whatever.

But in fact, I think it’s actually pretty close to the archetypal planning process. Like, regardless of how you do it, we’re going to talk a lot about a lot of different techniques and kind of methods that you can actually run the process with. I think most planning processes need the following, the team needs a vision or a destination, call whatever you want, but it’s where is the team ultimately trying to get.

They need something like a strategy or values that is how are you getting there? They need to determine what they’re gonna do. They need some way to manage dependencies or obstacles, and they need some way of measuring if they’re being successful.

And if you happen to read out B2 mom, I think it stands for vision, values. Methods, obstacles, and measures, something like that, you know, it basically maps correctly and even companies that don’t adopt such a formalized and rigid process, they end up more or less there.

Uh, one thing I forgot to mention is you need the cross team dependency management, you also need the up and down review and harmonization, and that’s also part of the BTO process because they’re meant to roll up. So you can kind of call whatever you want, you can make up your own acronyms or keep it less explicit, but I do think that’s the basic core of a planning process.

00:20:00 - Speaker 1: Yeah, now I guess to contrast it, we’ve been talking about these very big company, heavy-handed, lots of uh cascades, vertical and horizontal.

In contrast, on a smaller team, like on the Muse team we’re 7 right now, and It’s still just as important to plan our work to understand where we’re going, to know how we measure success, to know how we’re dividing things up, who’s working on what, who’s working with who, how we can all help each other best, how our work depends on each other either kind of in a technical sense, but maybe also just in a sequencing sense it makes sense to do this thing first and this thing second.

And so, of course, it’s a much easier, and the easy is quite the right word for it. You just don’t need to be so heavy handed. So if you take the very far low end is the example I gave before my first business was me and one of the person we sat in a one room office together and we had a whiteboard and we just wrote stuff on it and that was kind of the end. You know, a step or two up from that would be something like what the news team does, where we basically have a weekly planning, what we call a chapter planning, which is roughly 1 quarter where we look at bigger picture things. We like to pair that up often with team summits where we can either meet in person or really just like set aside a lot of time to step away a bit from our day to day work. But it also includes, to me, that kind of umbrella of planning includes something like strategy, right? How are you tackling the technical challenges of, for example, we chose to start with building device to device syncing because that was a subset of the bigger problem of the multiplayer that we eventually wanted to go to, that’s the strategy, right? And it also includes something like retrospectives, which I think of as an end cap to a project and I think are really important and again similar to the planning upfront, whereas it is much about the energy and the inspiration and the teamwork, a retrospective is not just about, hey, did we achieve what we set out to do or some accounting of that, but also a discussion of what worked for us, how did we feel and how can we Do more of the stuff that feels good and works well and allows us to be productive in the future and less of the other stuff. And so there’s some combination of those things, right, planning and project proposals, a strategy, kind of the big picture, quarter planning, the weekly planning, the retrospectives on some regular cadence, um, that all of that is. I guess it sounds like a lot of stuff, but you can do most of that in a pretty straightforward way for a team as small of ours. It’s not a huge amount of time, but it’s incredibly valuable time and also time, I think I certainly and hope I speak for others, you know, enjoy this time. We get to come up from our work, you know, the heads down work, take a breather, look out at the larger vista, think about where we’ve been, what we’ve accomplished, and where we want to go, and, you know, get excited for what we might do next.

00:22:53 - Speaker 2: Yeah, and you’ve identified something that I think is really important, which is a nested periodicity to planning.

So the most common period that teams will have is 1 week, some teams do 2 weeks. So that’s like one phase. Most teams also have something like we have our chapters, which is once every 2 months or so.

Some teams have quarterly, big companies might have once every half. Some teams have every day with stand up, and sometimes you have like every year planning, especially around financials and then.

Typically every 34 or 5 years you have kind of a phase change where you do a big reset and you talk about a new strategy and stuff, and I think it’s important to have a variety of periods, and it’s important to have a notion of cycling and change, cause if you just kind of go at one speed forever, you never look back, it just doesn’t work well, you get kind of stuck.

And even if you cycle weekly forever, you get stuck in your weekly mindset. And so I think it’s important to have these different phases where you’re accomplishing different things, your daily is very tactical, it’s unblocking, whereas your big quarterly plan is stepping back, it’s strategizing, it’s thinking about if you need to make big changes. So I’m a big believer in having those periods, having them be different, and having a sense of beginning and end, and resetting with things like planning versus retrospective at the end.

00:24:09 - Speaker 1: Yeah, I really like your idea of like a rhythm or a cycle. It almost sounds musical to me, which is something where there’s a, or maybe even like the fact that we have cycles and rhythms built into our lives through the rise and set of the sun and the week versus the weekend and then something like the seasons or something like the holidays and the year’s end. It sort of builds in these different overlapping cycle sizes that are somehow it seems necessary or important to human experience, something like that.

00:24:42 - Speaker 2: Yeah. So typically with kind of the core planning around tasks, you need to understand what the possibilities are, what you’re gonna work on, and who’s gonna work on them.

And so a lot of the mechanics stuff that we’ll be talking about is basically how do you do that. So with the effort to impact Matrix, basically anyone could suggest a project to work on, upgrade the postre version or convert to the new backup system or whatever. And once that was submitted to the team, the team would discuss where it goes on this.

Two dimensional graph, how impactful is it to customers or if it was internal facing to the team, and how much effort is it? And this is very rough. It’s kind of like a 3x3 type thing, and having more precision than that is probably false, and it seems very basic, but a, in the process of Choosing where to place it, the team has to really chew on the item.

Like, you gotta understand what you’re actually talking about, what the benefits actually are, a little bit of what’s entailed, so that helps concretize it for the team.

And my experience was that often it was kind of surprising where stuff ended up like. There’s been this project you’ve been talking about forever, and everyone’s really wanting to do it, and then you place it on the Matrix and it’s like high impact low effort. Well, there you go, that’s why I never did it because it’s just not really worth it.

00:25:54 - Speaker 1: I’m guessing you meant the opposite of that.

00:25:56 - Speaker 2: Oh yeah, yeah, right.

00:25:58 - Speaker 1: High effort, low impact, yeah. Yeah, yeah.

One thing I like about the effort versus impact scale is another good example of we’re using some visual thinking to lay something out is a nice way to have a concrete discussion about it.

And I guess you can do something like story points or you can estimate the number of days something is going to take or estimate the I don’t know, percentage increase in active users or revenue you think something’s going to make, but this all seems just way too specific.

Like that’s not the level of the discussion you’re having, but you need to be more concrete than just like, I think this project is important and will be hard or not hard, so that lets you take it a little better and put a whole bunch of things together and kind of compare, you can see where just things are grouped spatially in that sweet quadrant.

And maybe there’s things in quadrants that are still high impact, high effort that you actually have to do for your strategy or for other reasons, but laying that out just creates a high level understanding and a conversation on the team that I think you wouldn’t be able to have just a like, I don’t know, a plain text list or something.

00:26:58 - Speaker 2: Yeah, and this question of to what extent one can estimate a project is certainly a matter of debate.

I have a somewhat contrary opinion, which I think it’s actually pretty possible to estimate engineering projects. It’s hard and it’s a skill, but it can be done to a reasonable level of precision.

But yeah, even the low medium high is not bad.

One variant that I’ve used that does lean a little bit more on estimation is basically having the team work together to draw up a sequence, prioritized list of projects, and then as a separate exercise, draw the line.

Now you can just eyeball the line and say, I think this is how much we can do in a quarter, or you can actually go in there and estimate how many weeks you think this will take and then add up until you get to 13 or whatever.

I’ve had pretty good luck with that.

Now the most character version of that is, don’t do this, is you have the product manager write the sequence list, and you have the engineering team write the estimates and draw the line. I say it’s character because there’s some truth to that, like there’s some truth to the engineering team as the best sense of how long stuff it’s gonna take, and people who are spending more time with customers have a good idea about what’s most valuable. But as I think we’ve been applying throughout this podcast, a good planning process is collaborative and energizing, and it’s not people telling other people what to do.

00:28:10 - Speaker 1: Exactly a theme that runs through all of this, whether it’s a big company or a small team, is it’s really about building our collective knowledge.

And if it’s something where the boss is just telling you what you’re going to work on and you basically say, OK, or add a little detail, first of all, that doesn’t sound like a great environment to work in, not one that’s very inspiring, and I think for creative work, it’s important to be sort of invested and feel ownership in that.

But secondly, it really is about the fact that there is knowledge in all these pockets or in everyone’s domain.

So whether you talk about the vertical dimension of you’ve got company leadership who has big picture strategy and markets and you know, what do we need to do to raise financing or These kinds of things in their mind, you’ve got something like product managers who are maybe or support people who are close to customers and know their pain in a deep way that others on the team can’t, engineers who know what’s possible with the technology, not just how difficult something is in the sense of like how long is this project going to take, but also just in the sense of Yeah, what the technology can do, and you need to put all of those things and others together to get this like shared brain, shared understanding of all the elements of the business.

And that can be very hard to do because yeah, we all even in some ways speak different languages or have different subsets of jargon for our different areas.

We’re at different levels of zoom on the business, but bringing it all together and to me a good planning session, and again, I’m using that kind of as a theme that cuts across all these things we’ve talked about like weekly or quarterly. A big part of it is for a moment trying to see if we can extract all the most relevant pieces of information from everyone’s domain and bring them together, so no one’s telling anyone else what to do. We’re creating a shared understanding from that comes a plan of what to do that we all feel ownership for and then when we go off to You know, do our heads down work or go into our craft, we’re working off that shared plan where if we for a brief moment, brief beautiful moment in time, we understood the problem in a totality that no single human could do.

00:30:20 - Speaker 2: Another technique I’ve seen that leans into this is embracing individual excitement about projects, so you might start by having Any candidate projects be pitched, and a pitch is like a new board or a one-page Google Doc, something like that, you know, it’s a little bit more than just a project name, but it’s not meant to be heavyweight, and that’s meant to be.

Exciting and energizing to the team. So you write out this document, perhaps you review it beforehand with the team. Perhaps you even do some one on one discussions to get some initial feedback, and then you basically pitch it during the planning process, and then you can complement that by using people’s excitement about a project to determine what to work on.

So the most pure form of this would be basically, you put a bunch of these pitches on a new board and people put like emojis for their avatar.

Next to 3 of them that they’re really excited about, and that could be their excites they want to work on it, they’re excited, they think it would be good for the company or, you know, some amorphous combination, and I don’t think you want to use that as like the only mechanism, but I like you were saying, there is information there, whereas certainly if no one’s even willing to write a pitch for something, but also if someone is excited about it, but they don’t want to work on it, you know, and no one’s excited to work on it, that’s also a data point. Mm. And you can kind of mix and match these techniques, so you could do the effort versus impact to get some candidates and then have people self selecting what they’re excited about, and then you might have some that are empty, even though they’re high impact low effort, you might have some there people are so excited about, so you kind of dig into that and combine the methods like that way.

00:31:56 - Speaker 1: I’m just such a huge fan of driving projects on what people on the team who have the right contexts, right? If you’re brand new on the team, you basically just need to be handed something because you don’t necessarily know what to be excited about. But once you do have the context, the thing that you are driven to do, you’re going to be able to do that at both a level of quality and motivation and instigation energy that is just different from something that’s sort of assigned to you.

One little anecdote I have on that actually does come back to the Hiroku Department of Data, which is that was essentially formed when Peter Van Hardenberg, who now runs Ian Switch, he’s been a podcast guest in the past. He was an engineer working on some elements of the Roku system, and he kept coming to me to complain. I think our database needs a complete overhaul. Our database product is absolutely critical. People care about their data so much, it’s key to the scaling of the app.

The product we have is not very visible and you know hard to work with and not very scalable, and he just sort of kept complaining about this and I kept basically saying, OK, you know, pitch me on a proposal for what, how this could be different, and eventually that kind of man on fire energy in him, he just couldn’t take it anymore and basically kind of in an entrepreneurial way.

Came up with a proposal for what this could look like to have a separate team that’s dedicated to this, a product that is even sort of branded separately, has kind of an identity that’s almost a little separate from the Haruku core platform, and he went on to lead and grow that team and build what is honestly one of the best parts of the product.

I know lots of folks who use just the database and even the rest of it in some cases, and obviously we use the whole Hiroku platform as well as the Hirou postgras database for quite a lot of our muse work and yeah, it’s really something special, but they don’t always go that way.

But in my experience, the best things come from, yeah, the people who are going to work on it are also the ones who are really driven. To do so, rather than the boss identifies this as a business need, they identify this person over here has the right skills, they say, I think you should work on this, and then that tends to be a little bit more work a day.

00:34:12 - Speaker 2: Yep, this reminds me of another tool for the toolkit, if you will, which is trying to convince one other person or to get a lieutenant.

What I often see is, especially managers, they want the team to do something, and then they tell or try to convince the team. Well, teams don’t decide things, individual people do.

So advice I often give is if you want to do something or you want something to change, try to convince one other human being that that’s a good idea.

And often people really struggle with this, and it’s a sign that they haven’t, you know, fully contemplated their situation, and that can be used by manager, but it can also be used by an individual.

An individual wants the team to change in this way, I want the team to take on this project. You just convince one of your teammates it’s a good idea. That’s really going to encourage you to flush it out, to strengthen the idea, and once you’re successful, now you have an advocate who’s working to spread the word on a team. So it seems so simple, but I’ve often seen it work really well.

00:35:08 - Speaker 1: I’m reminded of this little video from years ago, I think it’s called Leadership Lessons from Dancing Guy, which is really all about that exactly what you said, getting that first other person who’s with you, and that that’s the start of all of it, or of doing anything big or anything great. So yeah, I love that approach.

And you also mentioned kind of related to the finding one other person to convince or to work with you on it. You mentioned the project proposals or the pitch and what form does that take? And to me this is a key part of how I think of the muse way, both in the sense of how our team works, but also what potentially the Muse collaborative product, why it is useful for this kind of planning and strategy work, which is You can sit there and say, OK, I’m really driven to work on a database product or do something within our company that I think we should do, but what actually does that mean? And you can describe it in some words, you can, you know, write a few lines in the Slack channel or something like that.

Very often I find, I say, oh man, we should just do this. It’s so obvious it’d be great. And you know, you write three lines about it and the people who I expect might understand what I’m saying are kind of like, huh, I mean, Like I trust you, but what? And that additional level of detail, whether it is, yeah, Google Doc, a notion page, something like that, and of course we think a new board is a really good place to do that, but something where it is fleshed out in more detail in the sense of like, here’s what it could look like, here’s some goals we might have, here’s some things we maybe are not trying to do. Here’s some inspiration we’re taking.

Since at least for me, very often I get inspiration from looking at maybe a product in another domain that solves a problem in an interesting way and I go, oh, you know what, we could do something similar to that in our product, and that would solve this long standing problem we’ve had or customer request we’ve had or whatever. And so putting those things together and it seems so obvious in my mind, but you know, other people don’t have the contexts that I have.

But if you can just put that into a little bit more detail, a couple of pages or a board that explores it a little bit. Now you have something concrete to talk about and indeed this project proposal we have a template built into Muse for that, but I think there’s a lot of different ways to do it. But the key thing is that planning isn’t you show up and say, huh, so what should we work on? Let’s throw out some ideas, you know, it’s actually having some developed ideas that you can look over, contemplate, discuss in smaller groups, and then come together and kind of compare in various ways, including something like the effort versus impact matrix.

00:37:48 - Speaker 2: Yeah, and with these pitches or proposals, I think it’s critical to make concrete what the customer is going to see, whether that’s an external customer or an internal customer. It doesn’t need to be at a very fine level of detail or refinement, but it needs to be concrete and it needs to be through their eyes.

So easy as an engineer to write. Like we’re gonna make a new API or we’re gonna make a new feature. What is feature, you know? Show me like 3 little screen mockups. User clicks here, they see this text box, they press enter, it takes them here, and it could take you like 5 minutes to draw all that, but it’s so much more concrete when you have that. and relatedly, I think it’s critical, assuming you’re doing a project and not like an ongoing program, unless you really know what you’re doing, you should be doing a project, it needs to have an end. How do you know when you’ve finished and how do you know that it’s worked? Ideally with some sort of metrics. Again, I’ve seen so many proposals where it’s basically a direction and not a thing to do. So in order to be done, you need to know what the definition of done is. So if you explain what the customer is going to see, when you know you’re done and how you know it works, you’re basically gold and everything else is gravy. One format that I really like is the Amazon working backwards format where you actually write a blog post of what the customer is gonna see, and I like this because it actually forces you to confront some really important things. What’s it called, what’s the name? How is the customer going to be introduced to it? Like where are they going to find it? What’s the entry point and what does that initial flow look like? And the best of these are done with like concrete examples. So if you’re using the example of AWS introducing a new API, you’re actually show a call request, you know, you can post V7 slash servers and you get an EC2 box or whatever. But then doing that again, it seems so simple, but you’re grappling with, oh wait, what are the parameters here? What are the different scenarios I need to consider, how does it affect pricing, things like that, how does it relate to other products in the suite. Another thing that, especially for internal stuff that I often see is with respect to other internal efforts, does this replace or is in addition to existing stuff? So oftentimes I see these proposals that are proposal to migrate to a new system. Well, critically, does your definition of done include shutting down the old system or not? And you have a reasonable plan for getting there, including a metric that tracks it all the way to zero. But again, the specific format isn’t as critical as I think adapting the customer’s viewpoint, what are you gonna do, how do you know when it’s done.

00:40:14 - Speaker 1: Yeah, the press release driven development, I think I’ve heard the Amazon method called sometimes.

I’ve also heard a variation on that, which is read me driven development, maybe for more developer focused thing, but really if you have to write, not the real documentation or the real blog post or the real press release, but a mockup of it where you’re explaining. Yeah, what it looks like, what it’s called, but especially critically to me there is just what’s the benefit? Why do I care? Right? And it’s very easy and especially if you get into something that’s infrastructure related or optimization related or something like that, but there are almost always is a benefit to the end.

User somewhere or if you can’t find that, then maybe this project isn’t worth doing.

So sure, the project is actually replaced the caching layer with a blah blah blah blah blah, but the benefit to the customer is this thing that you do all the time is now twice as fast as it used to be. And that’s great because XYZ, right, or it’s more reliable in these situations, a lot of people have reported frustrations when in this moment they get these certain errors or it goes slow. That won’t happen anymore because of this change.

00:41:22 - Speaker 2: Now, this talk about pitches and proposals and pre-planning artifacts, it kind of raises the question of who does that and when. So the failure mode that I’ve seen here is if you’re running a team at 100%, everyone is always booked all the time with tasks from Jira or whatever, you come to the planning, people are exhausted and they have nothing prepared. They don’t even have the mental headspace to think about it. So I think you need to create space one way or another for this sort of work to happen now. Listeners of the podcast will know I’m a very big fan of Slack, and this is one of the many reasons why it’s helpful.

00:41:59 - Speaker 1: If the team is running at say 80s, the concept as illustrated by a management book we go both like rather than slack the group chat product.

00:42:04 - Speaker 2: Yes, correct, thank you. So if the team is running at, say, 80%, you might say, oh, we’re wasting 20% of our time. Well, for a lot of reasons that’s not true, one of which is now you have some time to think and write out the stuff, and it might even be worth scheduling a block of time, you know, schedule a week for someone to research, scope out, sketch out, gather feedback on an idea. This is one of those things where it’s go slow to go fast, it’s an investment that really pays off.

00:42:37 - Speaker 1: Yeah, the technique we end up using on the Muse team is something where we have these sort of team summit weeks that are the break between our, again we call them chapters, roughly quarter time period where we typically are still doing work on the app, fixing bugs and There’s always stuff like that to do, but we try to as much as possible, have wrapped most of the big projects, have plenty of space, like explicitly in that week, you’ve got 50 to 70% of your time is slack and your Expected to spend that on project proposals, but also other kinds of just thinking and high level reflection about like what’s really working here, what are the big gaps, what is it that we’re excited to do in the future, what are we worried about and often that manifests in the form of project proposals, but it could also be something like a deep dive into, OK, we have all this technical debt in this area, or let’s do an honest assessment of this whole.

Part of the product has been this way for a long time, but actually I think there’s some problems here. I don’t know what the solution is, but I think we should think about it.

That kind of more open-ended thinking and higher level thinking, you just need the space for it, and we try to explicitly make that in a time when basically the whole team can be in that headspace at the same time. I’m curious how far that would scale, probably not super big, but it certainly works well for a team our size.

00:44:00 - Speaker 2: Yeah, and I think it’s not just wall clock time but like headspace that you need. So I think we’ve even done it where the week before you start to create that space like you’re not taking any big new projects, you’re working on smaller projects, you’re tying off loose ends, you’re doing bug fixes. And maybe you take Friday off, you’re starting to build up some distance and perspective, so you can have reasonable things to say going into the planning and maybe even starting to prepare some of those artifacts. Again, this is embracing the periodicity and every week not being the same.

00:44:31 - Speaker 1: One other principle that I think is embedded in some of what we’ve been talking about is the relationship between planning and a planning meeting.

And I think a version of it that doesn’t make that much sense to me is thinking that the planning meeting is all there is to planning, and that is the thing that probably tends to produce, first of all, very long planning sessions where it takes a lot of time to get on the same page, which can, especially if your remote team can lead to zoom fatigue and all that sort of thing.

But I like to think of planning as a session.

And obviously the what you’re kind of planning for the scope of what you’re thinking about if it’s a you just finished a huge research project, for example, thinking of something like the research work on it and can switch where we have multi-month projects or even longer, and you want a lot of time. To think about what you’ve learned and how you can improve in the future and then what’s going to be next, whereas obviously a weekly plan, you don’t need a ton of time for that. You have the context already, you’re just kind of organizing the tasks for the week ahead.

But regardless, I think the session is a super set of the meeting. And for me, the meeting ends up being, I guess the ideal world is sort of an end cap, and depending on how good you are at Assync and the tools you’re using and how much shared context you have and so forth, the planning meeting can largely be a matter of Reviewing what you’ve already kind of explored through some kind of asynchronous or documentation system and basically say, OK, yeah, I think the plan here is obvious, we all agree, let’s look each other in the eye and commit to what’s ahead and we feel great. Let’s go, and it can actually be pretty short in some cases. Now, not always, sometimes you dig into it together and things come out with a higher bandwidth of, you know, conversation and Especially if through even just emotional resonance, you see that there’s something unresolved and you need to dig a little deeper. So a planning meeting can be very important, but to me, the planning session is the superset of the planning meeting and all the other work you do around it.

00:46:35 - Speaker 2: Yeah, for sure. And remember, at least in a larger organization, you’re gonna have an iteration around reviews and peer team checks and dependency checks, so it’s definitely gonna take some time and remember that some of our best and most important thinking can only be done when we’re asleep.

So if you try to do it all in one shot, you are almost by definition, not gonna be successful.

Now for like a weekly planning. You can do it in one shot, but for things that are like what we call a chapter, which is maybe 2 months, quarterly, certainly longer than that, I think at a bare minimum, you’ve got to separate the time where you initially read on the proposals and when you discuss and decide.

I like what we do at Muse where we have like 3 phases, there’s you’re generating and reviewing the proposals asynchronously as they’re being accumulated in the news board. And then you have a discussion section where you basically chew on the proposals together. People present about them, you ask questions, you know, you poke at them a little bit, talk about the impact and the feasibility, and then go to sleep, wake up, and then you have a decision time, which is a separate third thing, and you know, takes some time for sure, but I think there’s a real benefit to that.

00:47:48 - Speaker 1: You know, I think it’s one of those things where the time spent up front can save you a lot of time from going in the wrong direction, not being on the same page, and just the frustration of working across purposes with your colleagues or having a bunch of your work thrown away because you just literally misunderstood each other or didn’t generate that collective knowledge, that shared understanding correctly or well enough.

So I do think of it as something that is a small investment, and we don’t want to spend our whole lives thinking about planning the work because We need to go and do the work.

Indeed, that should be the bulk of the time that we spend, but the difference between, for example, those three sections you just talked about that we’ll do for the longer range planning, in the end, that’s probably around 3 to 5 hours.

Which maybe could you cram it all into like a 2 hour meeting and just try to make it happen that way, probably, but I think the benefits over the course of the coming months or quarter as you’re able to be on the same page, that consensus about how things are working have previously dug out what some of the risks or potential complications are, is just pays so many dividends.

Now when it comes to these longer term plans, yeah, quarter or half a year or even a year, how do you think about the fact that, you know, plans naturally change over time or can change, or do you think it’s important, especially with a larger group that you really make your plan, you commit to it and you don’t deviate from it unless you really have to. Or do you think of something as a plan, as something that can sort of morph and change throughout the course of the time period it represents?

00:49:28 - Speaker 2: No, I think your plan can and should evolve over the course of the period, but I think that should be a deliberate act, because remember, a big part of the plan is having people aligned, and if you change direction without kind of telling people and agreeing on it, you’re gonna defeat the purpose.

I also think it’s important to note. And like a durable append only way when the plan changes or your actions or metrics don’t meet the plan for some reason, because when you go back and do your retrospective in your next planning session, and you’re definitely doing retrospectives as part of a healthy planning process, you need to take in that data to understand what happened, what was surprising, what went wrong, what changed, so you don’t have the same thing happen again in the next cycle.

This also becomes more involved. We have a larger organization, you’re dealing with dependencies and alignment up and down the staff. They’re a change in plan or a metrics miss or a goal miss that needs to be flowed through, basically a whole many process again where it’s reviewed and it’s flowed out to the relevant teams.

00:50:33 - Speaker 1: Yeah, exactly, because our work all affects each other. I mean, it should. That’s why we’re all here working together on something and you know, you don’t necessarily want to deliver bad news, so it turns out this is harder or impossible than we thought, uh, or it’s going to take longer than we thought or has these additional risks or complications, but you certainly, it’s important to share those things if they’re real and true because they are going to have all those ripple effects.

A phrase I like to kind of have in my mind is, when in doubt, revisit the plan. And I think there’s sort of twofold things. If you get into it, you know, you make your big plan together, everyone’s excited, this is going to be great. You get a little ways into it and just the reality is sometimes. You discover new information that you really couldn’t have only have gotten by trying to do whatever the thing is you’re trying to implement an algorithm or do a design or I think it was something like a home improvement project where you know, classic and like an old building or an old house, you go to open up the wall thinking you’re going to install some new electrical thing and then there’s something completely unexpected in there that’s different from what was in the blueprint or something is rotted out or whatever and yeah, you just discovered something new and very relevant that will have a material impact on what you’re trying to accomplish.

But one of the reasons I like to have that, you know, doubts mean revisit the plan is that you can either one, take that new information and as you said, flow it back through the plan and the people and everything that’s affected and make sure that the updates happen in a way that allows you to avoid wasted work and confusion.

But also sometimes the other thing happens, which is you get in, you’re in the nuts and bolts the day to day of it, you’re not thinking about the higher level thing, finding some doubt or getting lost in there somewhere, looking back at the plan is often like, oh, actually, you know, we thought through all this already when we were in a more zoomed out mode, we actually already anticipated this. We had Basically baked that into the plan and we just lost sight of it a little bit because the day to day. So either way, whether you realize there’s information that needs to be reincorporated into the plan or actually your plan is good, you just sort of forgot some of the higher level details because you were absorbed in the day to day. Either way, coming back to that plan will restore the clarity and help you get back on track.

00:52:50 - Speaker 2: Yeah, and it’s interesting that you mention risk.

I think strong project managers actually really lean into this. I like the information theoretic lens of project management and with respect to risk that means Really the game is to get risk to zero. So if risk is in fact zero, you just turn the crank and you win at the end. And the way you can operationalize that is to identify your, your biggest and most important risks. As early as you can and then systematically eliminate them, you know, confirm that they’re in fact not an issue or surface that they are in fact an issue and why and address it. So often you’ll see in planning templates there’s like a risks section, and if you successfully identified the risk, that’s already half the game because then you can get out in front of it and start tackling them.

00:53:37 - Speaker 1: I agree the risk orientation mindset is a good way to go about doing at least the kind of work I like to do, which tends to be in more innovative products, yeah, startup or startupy type things. The fact that they’re not well known is exactly where the opportunity is. I always was surprised years ago when I learned that venture capital is venture is basically short for adventure or shares the same route.

And it’s the idea that, you know, I think of doing a startup or some kind of innovative product as being a bit like an explorer that’s setting out in an unknown continent and wants to find something, reach the ocean on the other side or whatever. And You can’t know what’s there.

That’s actually the whole point.

That’s the whole reason you’re there is to explore and the opportunities that that presents, but that also means that you can sit there and go, well, you know, maybe there’s snakes, maybe there’s a mountain in our way, maybe we’re gonna run out of food. These are to work in your plan and plan around and that’s just part of the experience.

So risk as kind of a desirable quality in the sense of that is the other side of the coin of opportunity of working in a new space.

And we’ve mentioned retrospective a few times. Do you want to briefly say kind of how we think about those and why we think they’re important?

00:54:59 - Speaker 2: Yeah, well, in terms of why they’re important, we’ve been alluding to it throughout this podcast, but there’s a lot to be learned from the work that we’ve already done, and it takes some effort to actually surface those things and to process them as a team. These things are often stuck in individuals' heads. Often people don’t even realize that they’re there, you know, the individuals don’t even realize that they have these facts or emotions.

So retrospective is a process of getting that out and metabolizing it as a team.

And in terms of how to do it, we could talk about a lot of specific techniques. But as with planning, I think there’s a basic architecture. There’s understanding what happened factually, which sounds like it should be easy, but with big complex teams, often it’s not. How do we feel about it, you know, it’s a good, bad, and so on, and what do we want to do as a team as a result of this information? I can give you an example, concrete retrospective process. So we would do this on a canvas. Actually, I think we did it on like the Google drawing program back in the day, and the first phase would be, you would like draw a timeline. Where the left is the start of the quarter and the right is the end of the quarter, for example, and then people would just like put stuff on a timeline that actually happened. They would like go back and look at their calendars and look at their emails, and look at the blog, and see, OK, this is when we launched this, this is when we got this page of duty alert, and these are other things that happen throughout the quarter. That’s the what actually happened face. It’s quite important to have all that raw material out there.

00:56:28 - Speaker 1: And I think even just visualizing it that way or zooming out and looking back, you might actually realize things just from that, which is you go, you know, this 3 week period here was full of like we had these 3 incidents and this thing happened, it all stacked up at once. Everyone was stressed out and upset around that time, and at the time, maybe I was feeling. Just hypothetically here I’m saying like I was feeling like I wasn’t doing my job well or feeling bad about myself, and I look back at this now and I go, that was a tough time. So actually, you know, there’s a reason we’re feeling that way.

00:57:03 - Speaker 2: And this leads naturally to a phase two, which is like the the reaction phase.

So one way we did this would be make a new Google drawing document, and anyone can put items in the document to represent things that we should start doing, stop doing, or keep doing. So maybe we want to start doing.

Have a more robust on-call cycle with backups and stop doing is deploying on Fridays, and keep doing is using page of duty for learning, you know, but the idea is that anyone can put stuff that they want, and then also people can put like reactions basically, like I really like emojis, but you can also do votes or comments. And you let the emotional state of the team emerge organically, and very often it’s the case that there’s a handful of things that like really resonate with the team, things that they want to do differently based on their experience and what they talked about in the previous phase.

And then in phase three you consolidate that as a team, you discuss the timeline and the start stop, keep doing ideas, and if it’s appropriate, you sort of commit as a team to making those changes going forward.

00:58:11 - Speaker 1: The emotional component of it, I think is really important. Obviously, there’s a pragmatic thing here, we did this thing, it didn’t work, we should do something different.

And in the end, the goal of all of this is to execute better the team and ultimately be a more successful business, but I think that treating it almost as a bit of a group therapy to not only tease out maybe potential conflicts between team members or potential good working synergies between team members, but also how people feel, it’s almost that can surface things that we haven’t yet been able to really rationalize or think about in our.

More intellectual parts of our minds.

And so if you pull out, several people are feeling bad about this area over here, but none of them can really quite say why. Maybe they haven’t even said anything about it because they don’t know how to talk about that, but if it’s just like several frowning emojis, and then you go, OK, there’s something here, assuming as I’m going to, that you have a team of people who are invested in the work, they want to, you know, bring They’re feeling emotions about their work because they’re there to do great work and help achieve the overall mission, then those feelings very often, particularly if there’s some resonance between or some similarity between people on the team that can point to something that maybe you haven’t fully exposed yet through your more rational approach.

Yeah, I’m a fan of the Orin Taich, one of our Haruka colleagues approached retros, which is there’s 3 sections. And maybe the way he phrased it was probably something like what went well, what didn’t go well, and what are some things we can do in the future. And the idea there, of course, is not to assign blame or praise exactly, although it can be a good moment to celebrate wins and things like that. It’s just to observe and to again establish some both facts, but also feelings about what actually happened. And have some shared understanding about that and potentially turn that into action for the future. But even if you don’t have an obvious idea of like what to do about a problem, you know there’s a problem if it keeps coming up in retros again and again, that’s gonna allow people to think about it more directly and indeed may even feed into those project proposals for a future quarter of work, for example.

01:00:30 - Speaker 2: And I like that one shot style that is just go right to what went well, what didn’t, what to change, that sort of thing. I think that’s appropriate for like a weekly cadence, that’s basically what we do at Muse, for example, and then I think a more elaborate process basically like multiple phases of a deliberate information gathering phase, a deliberate team commitment phase is appropriate for the longer cycles.

01:00:54 - Speaker 1: Actually, I can switch, we certainly did more substantial project retrospectives for the whole project, but then when we kind of at the end of my run as the lab director and when I was handing things over to Peter Van Hardenberg and it was going to be just a natural kind of change of the eras, I ran a retrospective process that lasted basically. week where we broke into smaller groups and did small group retros on particular areas and then we found ways to kind of combine those all together and get some overall points of view and because at that point, you know, the team was relatively big and we wanted to kind of capture all that knowledge, but hard to just do it in all one big kind of synchronous session. And that was just incredibly illuminating for me even though I had been there from the beginning, obviously as one of the founders of the lab. I’d been there from the beginning and through most of the projects and felt like I had a lot of visibility and everything, and I probably did, but still the number of interesting learnings that surfaced as a result of that, yeah, it was just such well spent time.

01:01:59 - Speaker 2: And this is reminding me that like with planning, it’s not enough that everyone knows. Everyone needs to know that everyone knows. And with these emotional things around retros, that’s often the issue. Everyone kind of knows that something is wrong, but they don’t have words for it, and they don’t realize that everyone else feels the same way and they don’t understand that the team is committing to addressing it. That’s what the retrospective is meant to address.

01:02:21 - Speaker 1: And I think you’re talking about the difference between what’s usually called shared knowledge and common knowledge.

There’s lots of things that quote unquote everyone knows, but if you don’t realize other people know it or think the same thing, that really changes how you interact with the group.

So yeah, again, bringing that all out comes back to this collective knowledge and just shared understanding of what we’re all doing here, how we work together.

Yeah, what the point of all this is, we have to think about, we don’t need to all think in lockstep, but there needs to be some moments where we do form that collective understanding.

That’s what allows us to be really effective as a team.

Well, as a place to end, I’d like to talk about the potential curveball that remote work introduces to everything we’ve been talking about here around planning. And I think a lot of our anecdotes here from Rokku, Stripe, and others are largely office space culture companies. But then of course, Muse is an all remote team and increasingly that has become a sort of a new standard, certainly in the technology world and certainly for smaller teams, but even a larger scale. So, how do you see remote work is changing everything we’ve talked about? Only a little or a lot, not at all.

01:03:36 - Speaker 2: Well, the good news is that several of the things that we’ve been talking about with respect to planning flow very naturally into remote work. So we’ve talked about how a lot of our planning processes and retrospective processes work on a canvas, and this was the case long before Muse, right? And we used to use these canvases even when everyone was in the same room. Everyone will get on the laptop and open up Google drawings, so we have the power of collecting everything in one place or doing a whiteboard together, right? So that’s very natural for remote work.

The other thing that’s very natural is you need these written artifacts, especially as you go beyond one team at a company, because that allows people to process them over time and to get the up and down checks and to get the horizontal checks, right? So that very naturally lends itself to remote work. I think the place where it’s trickier is a, the chewing it over with colleagues, and B, getting inspiration. There’s a lot of when you’re together and when you’re changing locations, you know, you’re at the office, you’re going out to dinner, you know, you’re in different rooms in the office, you know, there’s a natural change in scenery that I think helps and it can be more conducive to informal ad hoc conversations.

So I think with the remote team, you gotta decide how much of that you want to try to reproduce. Now you could go like full remote, never see this other person in person ever, always work out of your same 100 square foot office forever. I think that’s pretty hard. I’m not gonna say it’s impossible not to do it, but that’s probably not what I would recommend. I think you want to embrace these things that are naturally aligned with remote work like canvases and written artifacts, but then try to incorporate some of the benefits of in person occasionally, and again, I like what we do at Muse, which is try to meet once every chapter or two, so it’s once a quarter, or once a half, and use that opportunity to get a change of scenery, and it’s surprising how effective that is in changing how you’re thinking. And spend some time talking ad hoc informally with the whole group, with different subsets of the group, with different individuals, and using that as an opportunity to kind of generate and chew on these ideas.

01:05:33 - Speaker 1: Yeah, I think it’s not a coincidence that this what we call team summits, others call off sites, getting people together in person, even for an all remote team is really kind of a staple, and it quite naturally the big picture planning, the retrospectives, most of what we talked about here really goes well with that.

And I think actually that’s something maybe that’s missing from some of the conversation about remote work here maybe I’m thinking especially a couple of years back when it was less clear that remote work would become so pervasive, but when talking about it, people say, well, but you’re so creative and productive together in an office, how can you give that up? And to me, the type of work which is this planning work, strategy and retrospectives and project proposals and so on.

That benefits so hugely from the in-person experience, the high bandwidth of being able to look someone in the eye, the body language, the spatial benefits like you said, of being able to change locales, and for sure the ad hoc conversations like you said, yeah, you have that session where you discuss all the project proposals and you’re kind of mulling it over, but then you and one other person go to grab lunch someplace nearby and on the walk on the way there, you know, the ideas are turning over in your head and you’re having new ideas. And that just ad hocness of it and changing setting and whatever just cannot be done through video chat.

And even I don’t know, there’s, you know, various attempts at trying to go a little bit beyond just a bunch of boxes of people’s faces on your screen, tools out there that people use for virtual conferences and things, and I think those have their place, but I don’t know, there’s just nothing like that in person.

So to me, when people talk about the productivity, Of in-person office culture, this is what they’re talking about, but you really don’t need to do this.

This isn’t the bulk of how you spend your time when you think of that heads down, creation, execution, work, that is a place where I think the difference between office and kind of work from home, all remote, whatever is not only low, but actually may even be better for people being able to have total control over their own workspaces and be able to create their own environments.

So, this is, I think a huge thing is that in the end, all remote work is for the foreseeable future, I think it’s all remote except for these occasional get-togethers, which will often pair with this big picture planning.

Now that said, I think this is a tooling opportunity and this is a huge part of what we’re doing with Muse for Teams that creating something that has more of a sense of place like an office and more of a kind of whiteboard, but better feeling to the tool, I think is part of where we hope to at least a little bit nibble away at some of the advantage of being in person in front of a whiteboard or a bunch of post-its or what have you. Something like virtual reality or augmented reality, I think the potential of being able to meet in a space that gives you body language, lets you move around, is spatial and has a lot of qualities that we get from an in-person meeting. I think that technology is still pretty far away, but you can see how eventually that might lead us in that direction.

Certainly, I think video chat and audio stuff does continue to get better.

It sounds minor, but only a few years ago, I felt that something like just not constantly saying, are you, can you hear me? Are you breaking up? Wait. This was just a constant impediment to the flow of any kind of synchronous conversation you were going to have, and more and more, there’s still problems from time to time, but it’s just way, way less than it used to be and being able to just reliably jump on a quick call and talk with a colleague is incredibly helpful.

Yeah, and of course there’s all these collaboration features built into design tools, built into engineering tools, built into more and more, built into every tool. So I think it helps a lot as the tools just get better.

Coupled with that will probably also be just teams learning to get better at it. We have hundreds of years or something like that of experience working in offices or maybe more than that if you count just working together in shared spaces generally, working in virtual spaces, the tools are evolving, we’re evolving our practices, we’re finding good ways.

To do things, and I think that it’s possible that the need for those in-person meetings, well, I hope we will never lose that because I just enjoy them, but perhaps it will be less critical than it once was as time goes on.

Well, let’s wrap it there. Thanks everyone for listening. Join us in Discord and discuss this episode with me, Mark, and our community. Links in the show notes. And Mark, it’s really been a joy to be on these teams with you for all these years and go through these different planning processes. Maybe I’m weird for getting excited about the topic of planning, but I just do. It’s a big part of the team experience for me, and it’s been a pleasure doing with you.

01:10:34 - Speaker 2: Yeah, likewise, Adam.