In a field like engineering, to have a truly unique 30,000-feet view of the profession, you need someone with 30 years of experience in adapting, innovating and creating in the space.
That’s why we were so excited to talk to Drew McManus, CEO and Cofounder of 33 Teams.
An engineer who’s helped shape the formative years of Apple, Adobe and so many more companies you have on your phone right now, Drew McManus is now advising rapidly growing dev orgs across the world at 33 Teams.
Drew is an oracle (no pun intended) on how to see dev orgs as living organisms, identifying the structural, psychological and technological maladies keeping teams from becoming who they aspire to be.
In our conversation, we touch upon everything from tech debt, to unlocking creativity to the all-too-common danger of shipping at all costs.
If ever there was a way to download 30 years of engineering leadership in one hour, this is it.
Episode Highlights Include:
- (2:20) What is 33 Teams all about?
- (7:45) 2 simple questions all teams need to be asking
- (20:22) The importance of curiosity
- (27:21) Fictional rivalries between teams
- (34:02) Common pitfalls startups can avoid
- (39:09) Dangers of shipping at all cost
Transcript:
(Disclaimer: may contain unintentionally confusing, inaccurate and/or amusing transcription errors)
Drew McManus: 0:00
Everybody has probably worked at a company at some point where you had a leader or a founder or somebody who was one of those people who showed up every Monday and said, you know, I was thinking about it over the weekend. And I think what we need to do is. Insert giant left turn here, burnout factory. Like you have, you have to be able to have a set of goals that have been prioritized and agreed on and maintain that focus. Have you ever wondered how your dev team ranks in terms of productivity speed and business impact? With linear B's new engineering benchmarks report. You can find out the product of comprehensively analyzing the work of almost 2000 dev teams to close to 1 million branches. The 2022 engineering benchmarks report. It's the first ever look at what performance metrics make engineering org elite average or underperforming Best of all. If you want your dev teams number to go from average to elite on any of the benchmarks, the report also provides concrete guidance on the behaviors, tools, and a process as a, you need to get there. To explore the report and full visit LinearB dot IO slash. Or click the link in the show notes of this episode.
Dan Lines: 1:04
Hey, what's up, everyone. Welcome to Dev Interrupted. I'm your host Dan Lines. And today I'm joined by drew McManus CEO and co-founder of 33 teams drew. Welcome to the show.
Drew McManus: 1:18
Thanks. Dan's great to be here.
Dan Lines: 1:20
Awesome to have you now for everyone listening. There's a good chance. Drew has worked on some of the apps on the device you're using to listen to the podcast today. He said a really successful career, you know, over 30 years in that time he's worked at places like apple, Adobe pivotal labs at pivotal. You were the vice president of product.
Drew McManus: 1:47
That's right. Yeah. I was part of the team that actually ran pivotal labs.
Dan Lines: 1:51
Okay. Very, very cool. I think most people know, about that company and the software there. And then with, you know, your decades of experience, I wanna open the show up with a discussion. Um, what makes. Company successful. You've pinpointed curiosity as an invaluable component of great teams, which we're gonna get to in one second. But before we go there, you're one of the co-founders at 33 teams. What is 33 teams all about?
Drew McManus: 2:23
Well, so we are a consultancy. We help customers everything from startups to big companies build software. But almost as importantly, while we're doing that, we help you get better at building software. So we help you learn about agile, but we also help you figure out what's gonna work best for you and your team and your culture.
Dan Lines: 2:44
Very, very cool. I love anyone. That's helping software teams improve, always a very, very difficult thing to do, especially when you're under the gun to deliver it. Getting better while you're actually have like deadlines and stuff, super difficult. Do you see it the same way? Yeah. And,
Drew McManus: 3:04
and it's actually really important that you do it while you're delivering, in my opinion, you know, there's never the luxury to stop and like send everybody off for training or, or go to a, a course or something like the way we do it is by dropping in. And there's no better way to have empathy with your team than to work on what you're trying to work on and work on what you're trying to deliver. And face the challenges that you're facing, but with like a wealth of experience of having worked with so many teams in the past, we often can see ways forward that might be harder for people to see who are inside of it.
Dan Lines: 3:39
Yeah. I agree with you. I mean, when I. Was a developer or even a team leader. Mm-hmm I always felt a pressure from the organization to hit my deadline. Yeah. Usually it was like a sprint, but sometimes there's a huge, you know, release or you have sales coming to you. Like, Hey, we have like a 500 K deal. Mm-hmm they'll sign. If by Friday we can prove that we have X, Y, and Z feature. It always feels like, okay, I'm in the weeds., I'm not always thinking about improvement. Do you have any, tips on while you're under that pressure as a team leader? How to also say, wait, there's an opportunity to improve?
Drew McManus: 4:23
Well, so. All teams go through periods like that, right? Yeah. Like there's there's deadline pressure or there is a big fix or there's a big patch or there's, there's all kinds of different pressure that come along and even healthy teams run into tough times. Like that's just part of, of the business that we're in. What's important is that it's not always like that. You know, a lot of people in the industry talk about sustainable pace and sometimes people think that means, you know, everything's chill all the time. It doesn't mean that, you know, there are, there are times that you've gotta kind of burn that midnight oil, but the key is that it's, that you're able to recover from those things, because otherwise what happens is you end up building up this mountain of technical debt that never gets paid down. Right? Like. Tech tech debt serves a purpose just like debt in the real world, right? Like sometimes you have to borrow to do what you need to do. But part of the plan has to be that you're gonna pay it back, right? Like the bank doesn't loan you money to buy a house without a plan whereby you're gonna pay it back. And so the same thing is true. Technical debt. Like you may actually take some shortcuts and make some decisions to borrow some time in one of those pressure scenarios to make a deadline or meet a milestone. Which is fine. As long as you have a plan to recover from, it
Dan Lines: 5:41
actually love the way that you described it. I've never heard anyone describe it in that way of kind of like taking out a loan or a mortgage And I think for, you know, team leaders or, or anyone listening to this pod, Most of the time you recognize when you're doing a shortcut or something that you say, okay, I'm doing this thing and not the perfect way to meet a business deadline. Right. Then when you get that feeling, I think after listening to you, you can always right then go back to the business and say, Hey, we took out a little loan here. Mm-hmm , we're gonna hit the deadline on Friday. We're gonna ship, but we gotta pay it back. very, very cool,
Drew McManus: 6:20
I've seen it over and over and over again. You know, these things don't get paid back. And what you end up with is, teams where there's a great big. Piece of the, of the application or a giant monolith that everyone's now afraid to touch because there've been so many shortcuts made or there's been, or, or, or the people who worked on it are all burnt out and have left the company years ago or like, there's always a reason why there's this scary thing that slows everybody down all the time. And, and, and that's just a symptom of not having gone back to pay those debts.
Dan Lines: 6:56
Yeah. I mean that, that's the other thing about it. If you let it build up too much, and that's why I wanted to make the point of speaking up when you feel that that technical debt mm-hmm is hitting you. Cuz again, I think everyone feels that when you're doing the thing, that is the shortcut. If you let it build up too long, it's very difficult to go back to the business and say, Hey, we screwed up for the last six months or the last one. Yeah, we've taken on so much debt that I don't feel like we can deliver any new features. For example, this quarter mm-hmm, , that's a very difficult conversation to have as opposed to right on the spot saying, Hey, no problem. We can hit the deadline, but we are gonna take the next iteration to pay back the loan or recover as, as you put it. now the first topic, That we're gonna get into it is around, curiosity. But you said that teams need to be asking two simple questions, have them written here, the two questions are, what's your name and what are you working on? Yeah. Um, what does that, they seem very, very simple. What does that, what does that mean to you? Or why is that
Drew McManus: 8:02
important? You know, that's one of the, one of the tricks that my team uses to help make sure that the communication flows properly. Right. So. A lot of time, what happens when people decide they need more process around delivering software is process gets designed in the form of handoffs. And so when you ask somebody like, okay, we're gonna check in some code, like, how does this work? Right? It's like, well, I do a PR and then somebody in QA tests run some tests on it. And then someone in, in infrastructure puts it into production. I always say. What's that person's name and it's amazing how often the person doesn't know, like, okay, so you send it to somebody in QA who is that? And then the next question is let's go talk to that person and see what they're working on. Like, hi Dan, it's nice to meet you. Like, uh, I just checked in some code. I'd love to see what it is that you do when you get this. Maybe there are things I can do to make it easier in the future. Right? Like breaking down these like artificial. Barriers or these artificial, um, you know, throwing things over the fence to the next milestone kind of things is what tends to smooth out the rough parts of process because you humanize the person on the other side of the fence. You maybe find a way you find some common ground. Like I can make your job easier by doing this. And actually that's makes my job easier too. Like so many times those things aren't discovered because we don't even know what that person's name is.
Dan Lines: 9:31
That totally resonates with me. Mm-hmm um, especially cuz you brought up the like a poll request, a PR process mm-hmm or maybe, you know, like, uh, you know, merge into Maine and then maybe some other, you know, testing happens anytime that you're passing code or, or in the process that you need someone else to do something for you. Yeah. Mm-hmm , there's kind of that natural. We call it at, at LinearB B we call it idle time or like a natural barrier where you're gonna see slowdowns. Yeah. And one of the things that I I've seen in my career so far, and you call it, you know, knowing, uh, someone's name, which is perfect. Now it totally, totally makes sense to me. Mm-hmm it's like, what information could I put on this poll request for you? That would make your review easier, your job E like what, what's the first thing you do when you open up my PR for a review, could I like add a piece of information there that would be helpful for you? and oftentimes what, you know, when you do talk to someone like that, they'll say something like, yeah, I would love to know what ticket is associated to this. Mm-hmm what's the priority from your perspective? How long do you think it will take me to review? What is the complexity of the code? Where are you worried about? And it's like, oh, I didn't know for the last year that you like, those are the things you wanted to know.
Drew McManus: 10:53
Yeah. Right. Yeah. And, you know, having that be more of a conversation than, than a handoff. It just smooths, things out. Like even if you put into the PR something like, Dan looked at the earlier iteration of this and you know, here's a link to a slack conversation we had about it, like, boom. Oh my gosh. Right? Yeah, because you know, you're humanizing the process. You're wanting your team member who maybe their name, you didn't even know last week. You're wanting them to be successful because like, there's a, there's a name attached.
Dan Lines: 11:24
Do you see that happen for most of the software teams you're working with? Or is it like a big company problem?
Drew McManus: 11:34
I mean, it's definitely in big companies, but it's not exclusive to big companies. I think, you know, teams that Institute process without understanding the why behind process tends to make things that are very. Handoff like, yeah, you, you check this in and then you submit this and you fill out this form and you click go you know, because that's what you think of when you think of process, whereas really. Process is team interaction and teams are made of people. And so anything you can do to tighten the feedback loops or, or you referred earlier to that idle time, like yeah. You know, I submit a PR and then I have to figure out something else to work on until I hear back about that. There's like a context switch there's turbulence in the process there. Right? Some of that is unavoidable. To the extent that you can, um, smooth that out by saying, Hey, I'm gonna check this in then I'm, I'm just gonna like ping Dan and see if we could have a quick conversation about it. Like, you know, that there's the, it, it smooths out some of those rough points in between tasks.
Dan Lines: 12:41
And I could see teams moving faster, improving quality. And then, like the other thing that came to mind to me is just, you know, the remote world that we're in or at least a hybrid remote situation. you know, you, you go to the extreme with the question of, do you know the person's name? There was a time, when I was like very hands on, coding. Yeah. We knew everybody's name. Cuz we sat, we went to lunch together. We sat right now. You know, now it's kind of a situation I could open up a PR and. I don't necessarily have to know the person's name or who they are or what they need. You know, it feels even more normal to maybe just say in slack, hey, can you look at this PR, but again, I'm not actually meeting with this person. Have you seen any dynamic changes with remote work? Okay.
Drew McManus: 13:29
Yeah. You know, The, the, some of the benefits we got from offices or, and especially open offices as you're describing where we ran into each other at the snack wall or whatever, like a lot of that has evaporated, but it, you know, having interacted with a lot of teams over the last couple of years, you can see new norms that are, that are, uh, emerging. Where people, they might submit a PR and then they might post to the slack channel. Like, Hey, you know, I'm in this zoom room for the next hour. If anybody wants to talk about this thing that I just checked in, otherwise I'm gonna be working on X and, and like these like organic little conversations can still happen. Yeah, it's not for everybody. And there are some people who struggle with these kinds of interactions. Like it, it, it requires a different, uh, a different interpersonal dynamic in some ways. And so I, I, I won't say that it's replacing or, or, or smoothly, taking the place of the other interactions we used to have, but there are new norms that are, that are establishing themselves.
Dan Lines: 14:30
Yeah. You know, the other area that I see this a lot in, we brought up the, the PR cuz I think that's, you know, kind of a natural handoff type thing. Mm-hmm, , it's actually between, uh, support and engineering, something that we're actually diving in. And my company now at LinearB B is we have more customers. There are, you know, support cases. And if you just ask for example, Engineering can go to the support person and say, uh, or, or vice versa, actually support person could go to engineering and say, what could I put into this ticket that would make your life easier? Cuz I don't really know what you do when you debug this thing. Mm-hmm oh, the then they'll like open up like a world of things. I would love to know what browser they were using. I'd love to know time of day that this happened., you can get into a 20 minute conversation that can actually improve the whole thing.
Drew McManus: 15:26
Yeah. And one client in particular that's coming to mind for me is, is when we worked with last year that had a lot of these communication issues. And one of the things that we, one of the terms we ended up using a lot was. Giving giving people a seat at the table, which of course is completely metaphorical cuz everyone was working remote. Yeah. But you know, they would have these conversations where let's say they were starting working on a new service to extract some functionality from the model F and they would talk about the architecture and they would talk about how they were gonna do it. They'd talk about how to design the API, but you know what, why weren't the infrastructure, people in these conversations? Like wouldn't it be great for them to be in on the ground floor of that? Like let's open up a seat at the table. And just give an option for somebody from the infrastructure team to come listen in and maybe say, you know what we saw with this other team when they got to, to deploying, like they ran into X, Y, and Z, like there's benefit that can come from getting people in those conversations, even though they might not obviously have a seat at the table. Mm-hmm . And so, having team meetings that were a little bit more inclusive of, of various people around the organization was key. Another thing that we saw was that because they, because they didn't really have this kind of inclusive, culture in terms of these meetings, there were a lot of informal communication channels that. Got put in place which have pros and cons. Like for example, there were a couple of sales people who were very gregarious and very good at establishing relationships with individuals on teams and therefore getting the things their customers wanted prioritized, which may or may not have been the right prioritization framework. Overall,
Dan Lines: 17:07
this is what sales people do. They're natural. They have natural skills to get what they need.
Drew McManus: 17:12
And so not having a table where the right people were seated and saying, well, yes, that sounds important. But there's also this other thing, right? Like there's having, uh, conversations that were more out in the open and more inclusive of all the voices that needed to be included really solved a lot of like kind of background dealing that was going on.
Dan Lines: 17:33
Well, here's a question that comes to mind. Who job is it to either like, uh, connect people or make sure that some of these simple questions are being asked? Who, whose job is that on the engineering team?
Drew McManus: 17:50
Well, it's everybody's job in a way, but I, I realize that sounds like a cop out. I think it depends on the team. It's often the product manager. To the extent that you have one, it sometimes is the engineering manager, but you know, one of the things that I see on teams is that leaders emerge from all over the place. And it's not always the person who appears to be the leader on the org chart or on the roles and responsibilities matrix, or whatever you're using to decide who's who gets to decide why. You know, there are people on teams who have knowledge or experience or relationships either internally or externally that make them the best person to do some of these things. And the trick is recognizing it and giving them the authority and the permission to do those things. And so, you know, the gregarious salesperson who's out there like, you know, working the organization to get stuff for their customer has energy and has their heart in the right place. Why not have that person take on some more responsibility in terms of prioritizing across customers. Like let's, let's harness that leadership capital,
Dan Lines: 19:01
right? Well then the way that you describe it, it sounds like a combination because the people that are really hands on, even if we go to like a, let's go back to the PR process, who's gonna know this first. That something could be improved in the PR process. Probably the person that's putting up, the PR and then waiting a really, really long time to get their code yeah. Reviewed or whatever it is. So it's probably like an individual contributor developer feeling the pain first mm-hmm. But then it also sounds like from a leadership perspective, a team leader, there's gotta be some type of encouragement. Hey developer, like you're totally empowered to change this process. Yeah. Let's go and talk to your reviewer and let's like, make a change immediately go
Drew McManus: 19:50
for it. And what if that conversation ends up being high? You know, what's your name? It's nice to meet you. So tell me what you do when you get your PR. It's like, oh, you run this test suite. Can I get that test suite? Is there a way for me to run that before I, yeah, I'll just
Dan Lines: 20:03
do it myself, like you, and I can tell you if it passed or failed on the PR.
Drew McManus: 20:07
Great. And so like, you know, those kinds of things, like nobody you're, you're not gonna get in trouble for improving how, how the process works. And so having those conversations, you can, you can make small improvements that catch on like crazy.
Dan Lines: 20:23
We have a topic around. Curiosity. So let's define how you think about Curiosity. for the audience. Yeah.
Drew McManus: 20:33
And this is really where the what's your name mechanism came from because it gets you asking questions and it gets you interested in what your team members are doing and what they like about it and what they don't like about it. And then you can ask what makes things easier and what, you know, why don't you do it this way? Or have you ever seen this or. You know, it, it, it, um, curiosity gets people energized about solving something or learning something or making something better. And I think, especially in tech, I mean, this is probably true in just about every industry, but especially in tech. Many of us got into it because of curiosity. And so it tends to be a pretty common trait amongst people who are in tech. And so if you are curious about something someone else is doing, they're probably gonna be curious about what you're doing and that's where the collaboration gets better.
Dan Lines: 21:28
Yeah, actually, that, that really makes sense. I mean, the DNA of people, software developers, engineering type people, Usually you're trying to do something that is an unknown. Yeah. So, Hey, go create this thing for me that no one's ever created before or with me. Mm-hmm okay. I'll figure that out. yeah. Yeah. Um, so I think what you're saying there is. There is kind of that DNA to be curious, which is a good thing for, for all of us. Yes. Yes. That came to mind to me when you're, when I saw, you know, interested in the topic of curiosity, sometimes I do get stressed or, or I did get stressed. again, there's, you know, pressure to deliver on time. There is pressure to, uncover unknowns and come with, uh, a solution I felt like. When I was in that situation of stress or anxiety, or maybe I'm stressed because Hey, I put up a PR and I don't know when it's gonna get merged. I, or I don't know what's going on on the other side, when I switch my mindset to, Hey, just be curious. Mm-hmm and so, you know, just when you go and talk to that person, you're not trying to actually solve anything. You're just curious to uncover an unknown. I felt like my stress level went down. I got better results. Yeah. I got a better. Conversation back from the other person. Cause they didn't feel like I was like pressuring them. It was just, yeah, I'm interested.
Drew McManus: 22:56
You know, another project we did recently was one of those ones where there's, you know, the, the big core piece of the app that no one wants to touch, cuz it's scary. Right. And we relied very heavily on curiosity to, to help teams build some confidence to get in there. It's like, okay, let's just agree. We're gonna write some code today that we are gonna throw away at the end of the day. And. Hmm. I wonder what will happen if we do this or let's write a test to see what this thing does. If you do this or like, it, it becomes like experimentation and, you know, and, and you've freed yourself of some of that pressure that you're describing by saying, we're gonna throw this code away. So it doesn't matter. And pretty soon you've learned some things that when you come back the next day and say, okay, today we're actually gonna write some code. That's like for reals. You can say, oh, well yesterday, remember when it did that weird thing, like I was thinking about it overnight and I, and I have an idea of how this is gonna work now, like curiosity, right? Like exploration, those, those are all parts of what make us productive and, and, and better software people.
Dan Lines: 24:02
I mean, when I, I think of doing like a, a good job it's, delivering on time, high quality, high efficiency, mm-hmm solving problems. Have you seen that? That curiosity mindset improves performance. Oh yes. For
Drew McManus: 24:19
teams. Definitely. It, it, it improves performance. It improves confidence and it improves communication because when you're asking questions, you're actually talking to each other and you're learning things that you more quickly than you might have otherwise, cuz you don't have to learn every single thing yourself. You're learning as a team.
Dan Lines: 24:40
Do you have any other, uh, you gave a good tip for, I think a, software engineering manager leader. You said like, Hey, whatever we're doing right now, we're gonna throw this code away. Yeah. Which kind of like, lets everyone's guard down. Do you have any other tips to try to set the tone for a software team to get into that? I think it's like also the create creative mindset.
Drew McManus: 25:02
There are a couple of tricks around,, collaboration that I think are really important. You know, I, I'm a big believer in, in pair programming when done properly and mobbing when done properly. And, you know, not every problem is appropriate for a pair or a mob, but a lot are. but it's also one of those things. That's tough for a lot of people to do, especially if you haven't done it before. And so that's another trick, uh, you know, kind of like the, Hey, we're gonna throw this code away. Thing is like, Hey, I'm gonna try to do this thing. That seems kind of hard. Like anyone wanna hop onto a call with me and let's just walk through it together. You'll notice. I didn't say let's pair on this. And I didn't say like, you know, I, I need help. You know, all I said. I'm gonna be trying something weird. Like, is anyone interested in trying weird things and, and inevitably somebody will jump on. Yeah, because of that curiosity. And so, um, that is a trick that I find works really well to kind of jumpstart the team operating together rather than working in a, in a siloed fashion.
Dan Lines: 26:06
That's pretty cool. And probably the person that jumps on is the right person. Well, yeah, in that situation, cause they're the ones saying like, okay, I'm just like interested too. I, I probably has the right mindset.
Drew McManus: 26:18
Yeah. It's exactly. And so you jump on, you've got that same mindset and it's like, oh, well, hold on. What if we tried it this way? Or, you know, this reminds me of a thing I worked on before and here's how that worked. again, you're just, you're short cutting the process because you don't have to learn stuff that this other person already knows. They're gonna just teach it to you.
Dan Lines: 26:36
Is there a set of characteristics when you see pairing work? Well,
Drew McManus: 26:44
yeah, so, It's hard for some people, especially at first. And the thing that is really important is that you're prepared to talk and, and that you're prepared to think out loud. And there are things exercises you could do to help, kickstart that. But, you know, the most important thing is that you just kind of say, okay, well, I guess I'm gonna set this up this way and, you're just talking out loud and, and, that gives the other person the opportunity to jump in and help you, or speed things up or say, Hey, can I try something? Let me take over for a second. So the most important things to start talking.
Dan Lines: 27:20
very. I have a note here around the concept of a fictional rivalry. Mm-hmm what is
Drew McManus: 27:29
that all about that's what builds up when you have teams that aren't connected and, and aren't talking to each other and you know, you get, you get these, you get teams that are like, oh, well, you know, those people over in infrastructure, they don't understand what we're doing. And again, if you say, oh, really? Who is that? Like, what's their name? Like the answer is, oh, I don't actually know those people. Like they've built this like Phantom of the people on the other side of the fence that tell them, no, this can't go to production because they don't understand. They haven't taken the time to connect and build empathy and to understand like, Oh, I didn't realize that you wanted things done this particular way. That's just a different way to configure my IDE. Like that's no problem. I can take care of that. Right. Things, things always seem, darker when you can't see past the fence. Right? Yeah.
Dan Lines: 28:22
I can totally relate to that. it even happens to me sometimes where. I'm building up and it's usually because like you're saying there's not enough connection or communication. Mm-hmm even when, like I I'm waking up in the morning. If I'm nervous about something at work, or I think, Hey, you know, these people don't want me to succeed or they're gonna be against me. I'm gonna put, you know, I'll put up my PR, they're gonna hate me. They're gonna give me like bad comments and it's really building up something. That's not, it. It is fictitious. Yeah. And then as soon as I connect with the people or the person that I built up this worry about, typically goes the exact opposite way. Oh, I like built up this story and really, I, it was, it's not so bad why can't together. Remember that next time.
Drew McManus: 29:13
So true. I mean, people call it othering, right? Like anytime you're taking a group of people and thinking of them as others or rivals in some way, you gotta stop yourself and kind of say, We all came to work here at this company. We must be interested in what we're trying to do. Like wouldn't it be better if we just went and found out like, Hey, it seems like you always reject my PRS and, and I'm wondering why, like, can we talk for a few minutes and yeah. Almost without fail, you're gonna find that they're not bad people. like, you know, let's figure out a way to work together. And, and that's why, you know, a lot of what we do at 33 teams. Is not, you know, we're technology consultants and we, and we're technologists. And we come in and we help you write software, but it's almost more about sociology and anthropology than about anything else, because software is made by teams and teams are made of people. And so understanding how we interact with each other and how we got to be the way that we are as a team or as a company or as a culture. Is a big part of getting better at, at building software. I mean, it's, it's so much of it is about these interactions. And so much of it is about the way we talk to each other or the way that we treat one another or, or our understanding of what, uh, of how we, how we should work together. That's the stuff that more often needs to be fixed than necessarily. Getting better at a particular framework or language.
Dan Lines: 30:43
I assume maybe like, uh, I don't know, an engineering leader might call you or maybe it's the head of an organization. Maybe it's a people person. I'm not, I'm not sure. But when you come into software organization or a particular team, what are the questions that you start
Drew McManus: 31:00
asking? So generally we will show up and, and it's often, as you're saying it might be an engineering manager, it might be the CTO. And there's generally some sense of, we need to get better at this or things seem to go so slowly or quality is a problem. There's generally some root thing that needs to get improved and that's why they call us. And so we come in and generally what we will do is first I'll take several members of my team and just embed. In your team. And so we'll say, look, just pretend we're like new arrivals, like onboard us, invite us to the meetings. Like we're gonna come to stand up and we're gonna come to your planning meeting and whatever. And for the first few weeks we're mostly observing like, okay. And some of it is process stuff like, oh, they have a planning meeting and it, here's how they run it. And you know, this could be better or whatever, but. There's process, but then there's also the people stuff like who does all the talking in these meetings or who only speaks up occasionally, but actually has great value when they do or who seems to have the best relationship with that other group that everybody's always pointing the finger at. identifying those people who, like I said before may, might not be the actual leaders on the org chart, but are leaders in terms. Either a particular piece of the product or a particular expertise or a certain set of relationships. Like we identify those people too. But the most important thing that comes outta those first few weeks is we try to identify a handful of things. So let's say four or five things that we can help you change. That will have the biggest impact on what you're trying to do and your business. So we don't show up with like the one true agile, set of stone tablets that say, you must do these things and you must do them this way. Cuz that's disruptive. What we do is we show up and go, based on what we're seeing, the number one thing is, and I'm making this up. But the number one thing is the role of product management needs to be much more clear. And below that B, C, D E, and number two, you really need to increase your focus on test driven development. And so here's what we're gonna do about that. B, C, D E, and no, like, so there'll be five very clear things. That's like, this is what we're gonna do. You know, your, your planning meeting is a little weird the way you run it, but it's not the end of the world. So we're not gonna like spend a lot of time, like trying to reinvent the way you do planning meetings. It's okay. It's fine. As long as we do these other five things, this is where you're actually gonna see the, see the improvement. And so that's part of what comes out of this. sociology, anthropology thing is here are the things you're gonna do. And here are the people that we're gonna really leverage to help make it stick.
Dan Lines: 33:43
Yeah. I mean, with your, with your company, 33 teams, I think that there'll be an endless amount of demand uh, because I've been in this industry long enough to know that, but we do have a lot of startup companies that listen to this pod. Team leaders that maybe cannot afford to bring in a 33 teams, yet. Yeah. What advice do you have? Is there common pitfalls that you could point out that maybe they could do a self assessment and have a take away
Drew McManus: 34:16
here? one of the, , great things about being at a startup is that you're laying all these foundations, whether you realize it or not, And so, you know, one thing I tell founders often is let's start with a culture of quality. Like let's start by really caring about test driven development. It's really easy to throw it overboard when you're feeling tons of urgency and deadline pressure. But without a plan to pay it down, you're taking out a really scary mortgage at that point. And so, that's a decision you can make early. Like when we estimate how thing, how long it's gonna take to do things, it we're including the fact that we're gonna test drive everything. Another thing is around infrastructure choices and, , I've got one person on my team in particular. Who's , has a lot of passion around. Decisions you make early about how you're gonna run your app and how you're gonna host your app. And, and that. Our decisions that you can end up stuck with for a really long time. And so making some smart decisions early is really important. So, we're actually working on some blog posts and stuff around that. That'll, that'll be coming out later this summer because that's a thing that we see from, from startups and growth companies that we sometimes wish we could turn back time there. But I think the most important thing is just exactly what we've been talking about, Dan, which is fostering a culture where we all work together. Where we collaborate on everything, even if it's a little bit coloring outside the lines that I have on my particular page. Like we are all in this together as a team. And, let's not set up process. That is, based on handoffs. Let's set up process that's based on collaboration and communication and, you know, getting better.
Dan Lines: 35:57
We discussed the, uh, PR process as a good place to have a reminder on that. Mm-hmm I had brought up cuz I've been seeing it recently, the process between support and engineering. Yeah. Um, is there any other ones that come to mind for you that it's like here? Here's some good, you know, natural areas where pro process and handoffs do exist. Yeah. That we didn't
Drew McManus: 36:21
cover. So I, I, I think that's another good one. So I, I think the, , support is often the last team to find out about stuff. And sometimes they feel like they find out about stuff when it's too late. So again, opening up a seat at the table so that someone's in the room when decisions get made. They may or may not influence the way a decision gets made, but at least they know about it. So that's a good one. Uh, another one is sales. You know, I think that often product teams are very distant from sales, uh, culturally, and sometimes they are people who come from very different backgrounds and they are sometimes people who come from very different communication styles. And so that can be a difficult bridge to build. But, I've seen it work and, and when it does, it can be amazing. And, and you get, input from, uh, from customers in a way that you don't otherwise. and so, again, opening up that seat at the table. and having salespeople involved in your conversations, it also helps them build a lot of empathy for what the team might be going through to meet that milestone or to do the extra thing that that customer needs, or to help support that deal. That's gonna close this quarter if we can deliver X. So, you know, having a, having a window rather than a fence between any team, helps.
Dan Lines: 37:43
Actually that's, that's a really good one. So when I first started my career, I was on the engineering track. I was a VP of engineering company got acquired. I'm one of the founders at, at LinearB B as most people know, they were listening to this pod and I ran, , or was responsible for the organization and the success organization. So change roles mm-hmm and I cannot emphasize enough what drew is saying. If you're on, on the engineering side, find someone from sales. I know sometimes they're a little bit different. They have a different communication style. They might dress different. They might talk a little different, find someone from sales, bring them into some aspect of your iteration, have them talk to your engineering team about how they present a particular feature. What are prospects and customers? It's like invaluable information, I think back to the development team. And then, yeah, like you're saying drew, there are gonna be issues in, in the product that empathy back and forth of, Hey, I found a bug in my, uh, prospect demo. Well, if you have a good relationship with sales, they're gonna actually gonna come to you and give you a lot more information. Here's what was happening. Here's what they did. Here's what they clicked through. Here's what they told me. So really want, wanna double down, On that point. We do have a final topic that I wanna make sure that we get to the topic is titled in our script shipping at all costs, which we've touched on a few times. Yeah. But, uh, what are you seeing out there? What is that what's going on there?
Drew McManus: 39:23
Part of the reason this comes up is that. Back to something we discussed earlier, Dan, you know, there are times when you've gotta pull out the stops, right? Like there can be deadline pressure or competitive pressure or whatever that says, look, you know what? We've gotta, as a team, we're gonna turn up the heat and, and get some stuff done. As long as that doesn't become the culture. That's okay. I actually worked with a company, a little while back at this point where part of their values like written on the document of their values was shipping at all costs. I, I was, I was horrified like. You can't have that be a baseline of how you operate your team or your company, because it just leads to burnout. Like, you know, people are constantly in that mode, you build up this tech debt that makes their jobs just incrementally harder with every day that goes by. They get to the point where, they've got a coffee mug on their desk that says something like shipping at all costs on it, but they feel like they're stuck in quicksand because. It just gets so hard to do stuff. And so you end up with these walking dead teams that, you know, you can just kind of see it in their eyes. And then the next thing that happens is people start to leave and they go work somewhere else. And so then all the, all the knowledge and code ownership of this probably messy code base you've been building is walking out the door. And so you just get into this spiral where it, it becomes very, very hard to recover. And that's because you instilled this culture of burnout. Like you, you be, you created a burnout factory even if it wasn't your intention, and even if it happened by mistake, these are, things that you really have to invest in fixing. And it can be very hard when it's become a part of the team culture.
Dan Lines: 41:16
Okay. How do we fix.
Drew McManus: 41:18
Well, a lot of it has to do with, , slowing down and it, a lot of it has to do with becoming really, really good at prioritization because the way you get into these shipping at all costs, kinds of modes is that everything is the most important thing. And every customer is the most important customer. And every competitive thing has to be met. Head on. You just, you can't, you can't and, and so becoming good at just ruthless prioritization and saying, oh my God, did you see competitor a today said that they're doing X. You have to be able to stop for a second and say, that's actually not the most important thing for us to worry about right now. It might have seemed like it when I read it on Twitter this morning. But now that I slow down for a second and think about it, no. Like we talked about this quarter is all about addressing a, B and C X isn't on that list. So, you know what we're gonna, we're, we're gonna live, I'm gonna write it down to talk about another day, because otherwise, like, and you see this sometimes, you know, everybody has probably worked at a company at some point where you had a leader or a founder or somebody who was one of those people who showed up every Monday and said, you know, I was thinking about it over the weekend. And I think what we need to do is. Insert giant left turn here, burnout factory. Like you have, you have to be able to have a set of goals that have been prioritized and agreed on and maintain that focus. Mm-hmm
Dan Lines: 42:51
the mindset because I, you know, I have been in situations and I've been in situations where, uh, shipping at all cost mentality got a lot of early prices in a startup. Hey, we delivered, or we did it sooner or. So it starts feeling good. Oh, that's what I'm supposed to do. I'm supposed to, but I think, one of the maturity lessons that I went through that I wanna share is you gotta start taking pride in keeping focus for the team. Yes. Hey, I was able to say no to that really smart person. Sometimes a founder who over the weekend actually came in with an incredible. But I was the person in the engineering organization or my team that was able to consume that idea. Yeah. Talk to that person and say, Hey, it's a good idea. Here's where we can get it done in a responsible, you know, timeframe. But this is what we're doing right now. That other amazing thing that you wanted to deliver on, that's still amazing. Yeah. Like that takes a lot of, at least for me, it took a lot of maturity to like navigate how to have that convers.
Drew McManus: 43:59
And, you know, we've talked some today about leaders emerging on the team and, and leaders who aren't necessarily the org chart leaders. For me, the, shining example of that is the person who emerges to, to, to have the confidence to say, okay, what I'm hearing is that competitor a came out today and they've got X, and it's super important that we respond to that. And I think that we can. As long as we can set aside B and C for a while, right? Like in order to fit in this newly prioritized piece of work that we have to do right now, I'm suggesting that we delay or set aside or postpone these other things that we were working on. Like to me, you know, if I, if I were the leader of that organization, that's the kind of behavior that I would really want to reward much more so than the person says, okay, we'll find a way to do.
Dan Lines: 44:55
Totally makes makes sense to me, drew, it's been a really good convo here., if you had to say one thing to summarize that someone could take action on immediately mm-hmm what would it be from our conversation?
Drew McManus: 45:14
I think it's important that you identify what are the things that we can change incrementally that are gonna improve the way we deliver software. And that means having some awareness of what the problem is. So a lot of times, you know, I'll talk to CTOs who are like, I just don't understand it. I don't know why we're not making more progress. You really need to kind of like ask a lot of whys about that to get down to like what's making you feel that way is. Quality problems. Is it, you know, things get stuck in, in, in PR loophole. is it that teams don't have everything that they need? Is it that you're not able to hire the way that you need to hire? Like let's diagnose what the handful of things that need to change is, and let's just change those. So often people want to hit a giant reset button and try to just completely change the way that the organization operates. It almost never works. So it's, it's, it's about focus. It's about, really trying to decide what's the high value thing we can do and just do that.
Dan Lines: 46:19
Perfect. Well, thank you again, drew, really, really awesome information here. I can tell from our talk today that you have a wealth of knowledge and really happy that you're there for the community with 33 teams to be available, to help. How do we get in contact with you? And also what. What type of team is the best type of team to come, you know, work, work with you.
Drew McManus: 46:47
Yeah. So I, you know, the way that we like to work with teams is we like to meet you where you are. So if you feel like, you know, there are things that you, your team could do better. First of all, reach out to me. You can just email me. I'm drew@thirtythreeteams.com and , let's talk about how we can identify just the few things that we could help you get better. Maybe it's TD D maybe it's process or product management, maybe it's, the way that you do infrastructure or deploying, like let's pick something and we can help you get better at that thing, which will make the team better. Overall. Again, we don't show up with some magical playbook that says we have the one true way that teams operate. We understand your team and how your team operates today. And like, what are the knobs that we can turn just a little that are gonna have a big effect.
Dan Lines: 47:42
Okay, perfect. So everyone definitely check out 33 teams, email drew. If you wanna chat with him and start working with 33 teams. We'll also try to get, the links to those blogs that you're working on. Drew. We'll put them in the links below in the description. I also wanna say thank you to more than the 3000 of you who are now subscribed to our weekly interruption newsletter. We bring you articles from the community inside information on weekly pods and the first look at interact 3.0 on October 25th. If you haven't already been to interact, totally recommend it. It's a lot of fun. It's free. It's all online. So you can register today and drew, thank you again for coming on. Dev Interrupted.
Drew McManus: 48:30
Thanks Dan. It's great to be here.