Andrew Holz - Oops I'm A Manager - Finding your Minimal Viable Process
In today's fast-paced, data-driven landscape, transitioning to a leadership role can be daunting. This talk is designed for emerging data team leaders, offering insights into striking the right balance between a clear effective process and the flexibility required for team members to do their best work. It emphasizes the importance of iterative process design, establishing effective feedback loops, and empowering team members with autonomy. These key strategies are put into action as team habits provide a blueprint for an adaptable workflow relevant to a range of different organizations. The talk aims to create a framework where both efficiency and creativity can thrive together. Talk by Andrew Holz Slides: https://icarusz.github.io/OopsImAManager-MVP/ GitHub Repo: https://github.com/icarusz/OopsImAManager-MVP
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Hello, good morning. My name is Andrew Holz, as Daniel said, and I'm here to talk to you. The title of my talk is Oops I'm A Manager on Minimum Viable Process. In the startup world, a lot of times MVP meant minimum viable product, so I'm kind of stealing that to talk about minimum viable process.
So before I kind of get into the topic, I'd like to just introduce myself just a little bit and say, hey, why oops? Why, what is that oops in your title? That's a little odd, right? So currently I am a head of engineering for open source. I have the privilege of working with some amazing teams, the Shiny team, the Quarto team, MLverse team, newly emerging tiny tools team, and it's been great.
But if we scroll the calendar back 25, a little more than that years, I was at Bell Labs, second job out of school. I was working with GIS data in the loop surveillance department, having a good time doing that. But things change at big companies, situations change, and they decided to spin out several of the products in that department. A bunch of senior devs were taking over that stuff, starting a company to do it, and they recruited me to join along.
So I was excited, joined them, about a dozen engineers, as I said, like some grizzled, experienced folks, five, 10, 15, 20 years more experience than I had. And then they started organizing things, and I was kind of continuing on my data stuff and playing around with Oracle, good times.
And there was like, oh, well, we need to get a little more organized, and we need to do a little bit of this management function. And pretty much all the other engineers that were there took a big step back, like, oh, management, no, not for me, no thank you. And I was like, well, I have a psych major that went with my CS degree. Hey, maybe I could do that stuff. So I stepped into that. We built the company up. I got to do a whole tons of crazy stuff, maybe earlier than I should have, but it was a great experience. We sold the company, $20 million.
I've been doing various technical leadership roles at small companies, my own startups, other people's, bigger companies, all on the way. And it's been a great journey. One of the big things I learned during that journey is I love, absolutely love, helping other people level up and find those people that are looking to be a force multiplier, that are part of the team, that understand the context, and want to help the team do its best work, be a multiplier for other people on the team.
I'm here to talk to you today with that in mind, and to talk a little bit about ways you might get into that. Thinking back to some of the other folks that had spoken earlier, essentially, this is about exploring, is that niche of leadership and helping the team do their best work, a niche that's good for you? Maybe you're already on it. Oops, I oopsed my way into management and have really enjoyed it. Maybe you're considering it. Maybe you've already been oopsed. Hopefully this is a little way to help kind of get that all started.
So in my personal experience and things I've observed, a lot of leadership, you started doing it, you were interested, you were helping out, and then it becomes your role over time. You actually do the job partially before you get the job. So battlefield promotions, it's not so planned. You can kind of back into it, but very few organizations give people much support. So this is just a little taste of that and some of the other things here.
And then frankly, a lot of leadership training can be really dry and takes itself so seriously. So Dr. Seuss, a little bit cheeky. That's what I'm going for here.
Minimum viable process
Okay, let's get onto the topic at hand. Minimum viable process. Let's take those in the reverse order and talk a little bit about each of those words. So process is just how shit gets done. That's like the overall, we have to be effective. We have some needs, we do some stuff, we deliver out some results. Hopefully the organization's happy with it.
It also needs to be viable, right? Big word there. Obviously it means effective in those steps that we're taking to get stuff done. But I think it also implies really importantly sustainable. If you don't have a sustainable process in that minimum process, you're gonna burn people out. You're gonna frustrate a lot of people. Your stakeholders aren't gonna be very happy. So we gotta just make sure it's not just viable effective, but also viable sustainable.
So something to keep in mind as we're talking about our high level process. And then really the biggest word here I think is minimal. As someone that's been in process for a long time, I actually find that too much process actually chokes things and you're actually looking for that sweet spot where it's enough process to keep people organized, coordinating well, whether that's outside teams or within your team, but not so much that it's actually like a lot of waste happening, a lot of friction, and a lot of the meetings feel bad and all that kind of stuff.
So we're looking to do a minimal process to give the team the room to do their best work. And the more we weigh them down, the harder time that's gonna be to do. So we're looking for minimal, but still viable for our process.
So we're looking to do a minimal process to give the team the room to do their best work.
Okay, everybody's process is gonna be a little bit different. I'm gonna use a lot of agile terminology. Hopefully folks are familiar. It's kind of the most standard one. There's a big question about little A agile and being flexible and big A agile, which turns into scrum and safe and all these big ones. I really mean the little A agile, but let's distill down a hypothetical, very high level process.
And one that kind of applies to everything and is really focused on handoff points. My experience, we're just coming off the Olympics. It's handoffs between people and groups where friction and pain and mistakes happen a lot. So we're gonna talk about our high level process, mostly focused on those handoff points.
The gathering step
So first step is just gathering, right? What do we actually need to do? Then we're doing the shit. We're getting the stuff done. All that details, building things, testing things, delivering things. Well, and then delivering things and deliver profit for South Park fans out there. You know, the underpants known had it, right? You know, you deliver, you get your profit. Everybody's happy.
So we're gonna break down each of these steps just a little bit, thinking about the friction part, what can go wrong? When does it feel bad? And like saying, hey, is there ways to make that more minimal, to give the team room to breathe, do their best work?
Okay, so we're in the gathering step, right? We have stakeholders. Some of them are maybe obvious and noisy and close and demanding, but some of them may be really important and further away. So, you know, management may have some ideas, probably usually do. They're funding a group. They want certain things to happen, but maybe it's users. Maybe it's a different analyst group. There can be a lot of different stakeholders and it's really important to think about who those stakeholders are. How are you getting input from that particular stakeholder? And are you getting it at the right level of granularity, right?
So if someone's further away, you really wanna ask them for missions. You don't want them detailing exactly what they want, but rather what are they trying to accomplish? And then the closer they are to your process and your team and your results, the more involved they can be in the details. So again, sometimes friction is a misunderstanding about what needs to get delivered, changing the order of what's the most important things. Most teams have too much going on. And so it's important to kind of order those things properly.
But if you're looking at stakeholders, the level of detail, how close they are, and you're pushing up the mission, right? You're making it a little more abstract and giving the team room to decide how to do it, you're gonna get your best results. So again, you wanna get the detail to match where it's coming from and give the team room to figure it out. The people closest to the problem, as much room as you can afford to give them to make good decisions, be effective about it, make the hard trade-offs in the trenches that really promote effectiveness.
So along the way, I have a bunch of QR codes here. For me, leadership is like lots of little lessons and then you practice and then you get a few more. So this will be up on GitHub, you can find these. But along the way, I put up a ton of QR codes. Maybe if you get a few of them along the way, a nibble here and there will serve you well.
So a quick story, I'm working with the Shiny team. I joined a little over two years ago and we actually had a problem in this area. We were practicing, and it was really Joe Chang. Joe Chang was practicing a guilt-driven development. He had his process reflect what he thought he was supposed to do. And what a very traditional QA person was telling him what he was supposed to do. So it was stories of a certain type and lots of steps on the Kanban process and lots of acceptance things having to happen. And frankly, it was frustrating the team. It really wasn't working well. They were feeling like it was a lot of time wasting.
The Shiny team is blessed with a lot of really senior folks that are serving themselves. They kind of know what needs to happen. So the best thing to give them was a high-level feature. Let them figure out how to deliberate what it is, interact with others on the team to refine it, and then own the QA process, the quality process, and then pull in some help when they need it. So a little non-traditional. And as we switched to that and Karan joined the team, he's been an amazing QA person. He gets pulled in. It's flexible. We'll figure it out with them. Not asking for a ton of documentation up front. The team has really sped up, been happier, and it's been working out really, really well.
The doing step
The next step, the doing. I don't want to get into the details of the doing. You all know what the doing looks like on your team in the actual activities, but we can think about how do we organize it in a way that helps the team do their best work. And I think one of the ways to do that is to make as much space as you can get away with in your context. So what is that? That's for the who. You don't want the same person doing the work again and again and again and being stuck in a niche because they're going to feel stifled and you're not going to have redundancy. If they're not available, what happens to that?
So even if it's not the most efficient in the moment in the big picture, by giving space for who, you're going to actually help the team. Your process is going to help the team be healthier, deliver better, be happier. And happy teams get three, five, 10 times more done than ones that are frustrated.
And happy teams get three, five, 10 times more done than ones that are frustrated.
We also want to make room in the what and the how. We don't want to dictate. I'm a huge fan of pairing on stuff. A lot of data says more gets done, higher quality, people learn, but not everybody wants to do that. So again, we want to give the team as much room as we can and not dictate how they're going to do. And I already talked about that idea of features at the right level where they have room to make decisions and do the best results.
The other kind of a friction that I commonly see is meeting dread. Where you have that meeting on your schedule, you see it tomorrow and you're like, oh gosh, I have to survive another one of those. Okay, that's a pretty good sign that there's friction, that there's bad things happening. So if you're in charge of that, or even if you're not, and you're just kind of interested in helping the team get better, it's really important to think about the meeting's purpose, the frequency it happens, and really who needs to be there. Sometimes new meetings start, lots of people feel left out, they want to join. The bigger the meeting, the less likely it is to be effective.
So one other little shiny story on this one. We were doing our guilt-driven development. We had dailies every day. It was eight people on the team at that point. It's gone up and down a little bit. It was too much. Everybody was bored. Eight people is too much to know what's going on with that many people. So everybody's just waiting their turn, spewing out what they tried to do yesterday. They would start to feel similar day after day, doing bigger tasks. So it really was not working. There was a lot of friction on it.
We started by first separating into two sub-teams so you can kind of track what's going on with four people. It's a little more reasonable. You can get some context, understand what's up. But now we've even kind of pushed past that, and we've decided to try and do it with context pairs. So a senior dev, a Carson, a Barry grabs, like, hey, this is the feature for the next release. I'm the lead on it. And we add a second person as the context partner on it. So they are there for code reviews, for brainstorming, for working together on it. So you want two people. You don't want just one person responsible, but you don't need four people all pretending they understand all the nuances and what's going on and why all the trade-offs were made. So that's been working pretty well, but that's something that we're in progress on.
Delivery and storytelling
So delivery. Not going to say too much about this. Obviously, you need to ship whatever ship means for you into that pipeline, that R package, that report. But there's other aspects, and Alan had kind of referred to some of those, of beyond just what did I ship is actually thinking back to the stakeholders and involving them and doing a little bit of storytelling. And this is an area really often neglected. And by spending a little time saying, this is what we delivered, this is why. And if there was a problem and this was the problem, you can really pull those stakeholders in. They can see the value. The team can feel really good about what they're accomplishing, not just ship, ship, ship, and then dot, think about it from there.
So it's something, it's also really interesting to me because this is an area that's exciting because one person, like a lot of those other steps I'm talking about involve a lot of coordination, a lot of changes. It can be challenging to do, but in this idea of delivering and then doing a little work around the delivery to make sure stakeholders are with you and they understand what's up spoken in their language and at the right level of granularity for them, that's really powerful. You can do that. And you don't have to be the formal manager.
I don't know of any manager. I certainly wouldn't be one of them. If someone on the team was like, hey, I think a little bit of a summary of what we shipped in that last one, but that's set well for this exec team or this outside user group would go a long way, that's gonna be embraced. So a little effort, you can improve the process. And I think that's a great way to explore if this whole leadership organizational kind of thing calls to you.
Iterating on your process
Okay, I need to hurry up. So again, we have our process. You have more details in it, but I talked about the abstract one. You have to accept that there is no right process. The people, the situation, what you try to do, it's a moving target. And we wanna play along with that moving target and try things. We're gonna do that as a group activity. We're gonna decide together where the pain and the friction is and what we might wanna be able to do about it. And then we're gonna formulate experiments. We don't know what will work better. We're gonna theorize something, try something, and then repeat that over and over and over and slowly, continuous improvement get better over time.
So just to kind of put this in a little bit agile terms, maybe this is something people know about, but hopefully you're doing retrospectives, right? So you're looking back kind of what worked in this release, what happened, what went well, what didn't go well, what could we do better, bad, sad, glad, some of those retros that are kind of standard ones, standard retrospectives could get a little stale. So I'm gonna say, be cheeky, do one that's very directed. We wanna make the process work for the team. So you're gonna come out and ask them, which part of our process kills your soul the most? And if you get those answers, you know where the friction is and you have something that, okay, let's talk about that.
What possibly dumb ass way could it be a little bit less crappy, right? We're not gonna fix it all at once. We're gonna do a little experiment. So how can we do that? And then, hey, let's take that vague idea of like, oh, it'd be better if, and say, here's an experiment. Here's something to try. Let's give that a shot. Let's see how that goes. So we're gonna do a couple of little experiments. We're not gonna have too many going on at once and we're gonna find our way towards a better process over time.
If you need a little more structure than that, you can try the popcorn method. Claudio Peroni kind of came up with it. It's a big Kanban board. There's seven lanes that you go through. The first three, we really talked about, problems and observations, what are options to fix it? What are possible experiments you could try and do? And then the corn really just takes you to the commit and ongoing and reviewing and kind of keeping that train going.
Overcoming excuses
Great, more work. We have to work on our process too. It's not enough that we have too much to deliver. There's so many excuses for reasons not to do this. I'm gonna run through a few and then we can wrap up here.
The biggest one I always hear is, it's not us. It's not us that are causing the problem, it's them. It kind of doesn't matter who the them is, but it's them, it's their problem. Well, guess what then? Time to work together, collaborate, and you're gonna do your pop. What's killing your soul? What could we do better? What experiments with them in the room? They're part of your process, pull in the right key people, and you can really make progress on that. Not them, make it about us and get the us in the room.
We don't have time for this, we're overloaded. Well, if you stick to a process and you don't give more visibility into what's going on to the people that need it, you're gonna just get worse over time. You're gonna burn people out, you're not gonna make progress.
Hey, we already tried fixing this. We tried these other things. We had process improvement before, get over it. Well, the fact of the matter is, failing, you may have failed. You may have tried it, but you need to learn from it. Was it a bad idea? Was it too ambitious? Was it a lack of follow-through? You gotta learn from those things and improve. So just the fact that something didn't work out once before doesn't mean you give up.
And then, oh, management won't let us. They make us follow some elaborate scheme, they bring in experts and consultants and they dictate it. Well, don't disempower you and your team. If you're doing some experimenting, if you're trying to make things better, there's no management team that's gonna say, don't do that. You start within the strictures they set and you make progress. And by the way, just don't ask for permission. Just try it, tweak things, it'll get better. The results will pay for itself. It'll be good.
Okay, this is the Agile process, the Agile manifesto specifically. If you look through it, I think you'll see a lot of the kind of themes I'm hitting on, individuals and interactions. Working software, we can say a working process. Customer collaboration, I really think in this case, it's stakeholder collaboration and then responding to change, right? So this is really Agile, this is the heart of it and apply it to your process can be great.
So again, channeling my Dr. Seuss, repeating that same idea that I'm asking you all to try. In a lively hub where ideas fly in dart, the team map their processes, each playing their part. Keep it all light, let's empower and grow, getting sure that our output has value to show. They tweaked and they tested and with agility played, finding new ways for their efforts could sway. From shadows of old, they emerged step-by-step, their process now streamlined, efficient and light.
So thank you all so much. Please reach out if you're on this journey or even thinking about it. And here's some resources that I just love and have used, gone back to over and over. Thank you very much.
I just wanted to remind everyone that there is a Discord server where if you want to continue the conversation, you can. Before Andrew steps away, there was one question from Discord and everyone wants to know, where did you get the pictures from?
Oh, just playing with Mid Journey. It turns out it's pretty good at doing that. A little bit of Dr. Seuss and you have to use Mid Journey, by the way, because Dali will say, oh, you can't say Dr. Seuss, that's like protected. So Mid Journey, but it was fun and I probably spent too much time on that, but.