Untitled

Discuss this episode in the Muse community

Follow @MuseAppHQ on Twitter

---

Show notes

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 pro