Transcript: Autonomous Engineering Teams: What Works, What Breaks
0:00 Brad Somebody who's going to create that sense of empowerment and autonomy and psychological safety and being cohesive dynamic.
0:10 Brad I'm not so sure that the org structure is really the high order bit to how to get there.
0:34 Scott Welcome to this week's edition of How Many CTOs Does It Take?
0:41 Scott My name is Scott Porad and this is my co-host.
0:43 Brad Brad Hefta-Gaub.
0:45 Scott Brad,
0:45 Scott how are you doing?
0:46 Brad I'm doing pretty good. Yeah.
0:48 Scott Good.
0:49 Scott I'm glad to hear it.
0:50 Brad Yeah.
0:51 Scott What's going well for you these days? We typically just talk about things that aren't going well.
0:55 Scott What is going well?
0:57 Brad uh you know um we can talk more about this in a in a maybe in a whole episode we could talk about this but i have been having a lot of fun playing around with um some of the latest um generative ai tools that are out there so one of the things i've started doing is using the chat gpt codex and i literally just tell it things and then let it go off and come back and do it for me and
1:25 Brad I have, I have, it's been fun.
1:27 Scott Well,
1:28 Scott it's very interesting you say that because I used chat GPT codecs for the first time myself yesterday,
1:34 Scott and
1:35 Brad Yeah,
1:35 Scott I had a different experience than you.
1:38 Brad it's definitely hit or miss.
1:41 Scott Well,
1:41 Scott I just thought this is not fun.
1:45 Scott I asked it to do something and I just sat there and waited for it to do it.
1:48 Scott I didn't know how long it was going to take. Was it going to take a minute? Was it going to take 10 minutes?
1:51 Scott And I thought to myself,
1:52 Scott this is kind of boring.
1:55 Brad So I've been using it. I've been using it for super simple tasks.
1:58 Brad We're almost doing the other podcast episode. Hold on. But I use it for simple tasks like updating the How Many CTOs podcast website or updating my own personal website.
2:09 Brad And I've gotten to the habit of like.
2:11 Brad like literally I'll just open it up on my phone I'll give it a command and then I'll just go on about my day and then I come back like you know 20 minutes later and check on it and it has a pull request and then I look at it and I test it
2:25 Scott Yeah, so that's the right interaction model.
2:27 Scott It has to be very asynchronous, right?
2:30 Scott I was actually actively trying to do something and being engaged in it. And then it led me to think.
2:35 Scott Well, this is going to lead to a lot of switching costs because I'm going to go start doing something else and I'm going to stop that and come back. And I think you've got it exactly right saying,
2:44 Scott I'm going to set this off, but I'm not going to come back to it till later.
2:48 Scott Right.
2:49 Brad Yeah.
2:49 Scott So it's almost like good for sort of almost secondary activities. But like if your prime thing you're working on and then you sort of kick some stuff off, well, this was my prime thing I was working on.
3:00 Scott And then I was kind of going and finding some secondary things to work on.
3:03 Brad Well,
3:04 Brad and then the other thing I've started doing is being completely not precious about whatever it comes back with.
3:10 Brad So if I look at it and it missed the mark,
3:14 Brad I just delete the pull request and say,
3:17 Brad you failed.
3:19 Scott Well, that's interesting you say that because I asked it to do something that I don't have a lot of expertise with.
3:24 Scott I asked it to start writing a React Native app for me and I've done some like Hello World apps,
3:32 Scott little,
3:32 Scott you know, make a duck fart kind of React Native type apps, but I've never really done anything with it.
3:38 Scott And so it came back and I started looking at it was came back with 60 files and I thought to myself,
3:45 Scott I don't know if this is right.
3:48 Scott And I don't actually know how to know if this is right.
3:51 Scott I guess what I could do is I could have somehow taken that poor request and fed it to some other AI bot and said,
3:58 Scott is this right?
3:59 Brad What do you think of this?
4:00 Brad Yeah.
4:01 Scott And so I found myself a little bit stumped after that happened. And then what I went to go do,
4:06 Scott now this isn't right, you'll appreciate this part.
4:09 Scott Then when I said, OK,
4:10 Scott well, here's how I'm going to know if it's right,
4:11 Scott I'm going to go take this poll request. I'm going to pull down this branch to my local computer and I'm going to run it.
4:18 Scott I happen to have a new computer.
4:21 Scott no home I don't even have homebrew on this computer and then I was just like oh my god here we go now we're going down a three-hour rabbit hole of getting the computer set up and I'm going to be back here and it's like wait what was I doing in the first place I
4:36 Brad Totally.
4:37 Scott need an AI bot where I can just say get the computer set up for me please
4:42 Brad Yeah.
4:44 Brad That's coming,
4:45 Brad I'm sure.
4:46 Scott Oh, yeah.
4:47 Scott So actually, that's what stopped me is I didn't have homebrew and I was like,
4:50 Scott oh, brother.
4:51 Scott What do I do now?
4:52 Brad yeah but that's not ai specific right that's like
4:55 Scott No.
4:55 Brad the classic like i'm just going to use i'm going to use some open source project or i'm going to use a recipe that i found on you know stack overflow like we've been people have been running into developers have been running into those types of issues
5:07 Scott Yes.
5:07 Brad like getting the machine set up getting the environment like it's like the number one thing that happens when you hire a new developer into the organization is you got to go like you know drop the
5:17 Brad you know the docs on them about how to set up the environment i used to think that was like a good metric of like how how dialed an engineering team was as if is you know time from like employees first day to they have the code running like Oh, are you kidding?
5:33 Brad that's like
5:34 Scott That's bush league, my friend.
5:36 Scott Going back a few. So several companies ago, we started doing this. I did it at two companies.
5:42 Scott So for a total of 13 years,
5:45 Scott engineers zipped code to production on their first day.
5:51 Brad Oh, well,
5:52 Brad there you go.
5:52 Scott To make that happen,
5:54 Scott took a ton of work. Because when we first started.
5:59 Scott it was taking an engineer days just to get their workstation set up and their local environment set up and all that stuff and so we set a goal like okay you need to be able to ship on your first day and then there had to be a bunch of other stuff that had to get in place you get a lot of stuff in place and we didn't want them to show up that we told this was a big part of our recruiting of our all that stuff and
6:21 Scott we said look we don't want we're not asking you to show off your coding skills here we have picked something for you a small bug where like the coding is no big deal here but the fact is value is created when your work gets to production and we want to show you value on your first how to create value on your first day and
6:39 Scott We had to do some work with our people team,
6:41 Scott right?
6:41 Scott They wanted to have the whole morning where you're filling out forms and all that stuff,
6:44 Brad Right.
6:44 Scott right?
6:45 Scott And there was this study I saw actually John Helm, who was on this podcast previously,
6:51 Scott is the one that tipped me off to this decades ago.
6:54 Scott It was a study of factors that contribute to extreme work dissatisfaction.
7:03 Brad Okay.
7:04 Scott And I think it had extreme satisfaction to I think it was both of them. But it's all the HR stuff that you do on your first day,
7:12 Scott bureaucracy,
7:13 Scott red tape, paperwork,
7:14 Scott all that nonsense.
7:15 Scott Those were all the extreme dissatisfaction.
7:18 Brad Right.
7:19 Scott And then the extreme satisfaction stuff was stuff like, you know, achievement,
7:23 Scott competency,
7:24 Scott you know, those kinds of things. Right.
7:26 Scott And then right in the middle, neither.
7:29 Scott It's neither beneficial or not beneficial was compensation.
7:34 Brad Yeah.
7:35 Scott So that was an inspiration for it as well. So we did this where we got people.
7:39 Scott and then shipping on their first day and then it became a contest then it became engineering managers like how fast can i get this guy to ship then it's like hey our guys ship before lunch hey our guys ship me our guys ship before 10 30 right like um and so it became a whole thing like how you know and there was here's this is the last thing i'll say to anybody who's listening the key to making this whole thing work
8:04 Scott is we have someone start it's not like there's the Doc's going to make it happen it's like hey I'd like to introduce you to Brad Brad is your mentor for the day and his job is to help you ship something to production Brad has been relieved from all of his tickets and stuff that he's supposed to be doing today that's this is not just like if you have a question ask Brad this is Brad is going to sit with you and help you make this happen
8:29 Scott And that was a real key,
8:32 Scott right?
8:33 Scott And what we found was people loved the experience.
8:39 Scott They didn't remember all of it. I mean, like, you know,
8:41 Scott there was lots of you on the second. It wasn't like they were just off and running on the second day, but they'd ultimately seen all the steps in the process and it was a function. It forced us to get our ducks in a row so that there's a one click dev environment.
8:54 Scott Like you just had to have the machine there on the first day.
8:57 Brad And are you, yeah,
8:58 Brad are you, so that sounds like a utopia. I love the sound of that.
9:03 Scott Yeah,
9:03 Scott it was great.
9:03 Brad And how many of the ventures that you've worked for accomplished that percentage-wise, let's say?
9:10 Scott Well, let's percentage, I've probably worked at 12 places, so it was two, there's only two, but we've done that.
9:17 Scott And so it's been, it was, it was those two, and then I've been at three places since,
9:21 Scott and I haven't done it at three places since.
9:26 Scott In part because if those two places we were rapidly hiring and rapidly growing and
9:31 Brad Totally.
9:31 Scott we're not at these places, I mean, but there's hiring happening, but it's just not the hyper growth kind of thing.
9:36 Scott So it's just not the biggest problem to solve.
9:39 Brad Yeah.
9:40 Brad Fair enough.
9:41 Brad Well, you
9:41 Scott Okay.
9:42 Brad said somewhere in that thread that the engineering managers liked to compete with each other about how quickly they could get their new engineers checking in code to production.
9:55 Brad And that dovetails nicely into the text message you sent me earlier today about
10:00 Scott Right.
10:01 Brad the role of engineering managers.
10:03 Scott Yeah, so everyone just who's listening,
10:05 Scott I got an article forwarded to me today about engineering management and how to organize an engineering team.
10:11 Scott And, and I sent it to Brad and I said, What do you think about this? I'd love to discuss this with you.
10:16 Scott And let me just summarize as I read it. I don't
10:20 Brad Yeah.
10:20 Scott have the article in front of me, but
10:21 Brad Yeah.
10:21 Scott Basically, the article said,
10:23 Scott look,
10:23 Scott most organizations are organized very hierarchically where you've got an engineering manager and maybe there's directors and stuff, but the engineering manager and their direct reports are the unit of delivery.
10:35 Scott They deliver stuff.
10:37 Scott And so the engineering manager is responsible for both the personnel management of their team and.
10:46 Scott the project management of their team and this author was making the case that building having an organizational structure where you have managers and reports but the managers are only responsible for the personnel management so performance management and mentoring and coaching and all that stuff and separate from that are cross-functional teams that are not at all connected to the organizational structure
11:12 Scott that, you know,
11:14 Scott consist of engineers from a variety of teams,
11:16 Scott consist of perhaps designers, product managers,
11:19 Scott whatever skills you need for that thing,
11:21 Scott for that objective.
11:25 Scott And that is the way that this person's adopted and there's pros and cons to both, but he thinks that this is the best to do it this way.
11:33 Scott And it was thought provoking.
11:36 Scott and I sent it to Brad I said I'd love to discuss this with you and then Brad texted me back a little bit later and he said I have a lot to say about this to which I responded I have no doubts and what I but what I said to Brad I said and it's funny that I'm talking to you about this in third person but I am relaying it to our audience I said I'm interested in hearing what you think about this the pros and cons but I'm also interested in this question
12:03 Scott what are the conditions that must be true for this to be successful?
12:08 Brad Yeah.
12:09 Scott That's the question that's on my mind. It's like,
12:11 Scott okay, or alternatively, what conditions
12:16 Scott make it such that this couldn't be successful it would be harder to be successful because it sounds great in theory but
12:22 Brad Yep.
12:22 Scott when the theory meets the reality what is it that makes it actually work or not work so with that i'm also good i'm practically going to interview you brad welcome today brad we have a special guest on today his name is brad have to go and uh what do you think
12:37 Brad Well,
12:37 Brad thanks for having me on the podcast,
12:39 Brad Scott.
12:40 Brad I've been a longtime listener,
12:41 Brad first time caller.
12:44 Brad So first of all, I want to say I think you did a great job of kind of summarizing the themes of the article.
12:52 Brad There were a few things that the that the.
12:56 Brad original author made as a point and we can link this article in the show notes um i am looking at it now and it's interesting because it doesn't actually say the name of the author it's like a medium and so it's like the author's name is not on the article so okay whatever um the other points that he makes about the why behind this i think
13:21 Brad expose some of the challenges.
13:23 Scott Okay.
13:24 Brad So the why that he,
13:26 Brad the main why that he is giving, which 100% resonates with me and I think is a really, really good point, is basically that you want engineering teams to feel really a strong sense of ownership,
13:40 Brad some appropriate level of autonomy,
13:43 Brad and team accountability for results.
13:48 Brad Like that,
13:49 Brad if you can get a team to feel a strong sense of ownership about their results,
13:55 Brad a sense of accountability to each other,
13:58 Brad and all of the psychological safety that's necessary to make that happen,
14:06 Brad right,
14:07 Brad then that's...
14:08 Brad That's goodness,
14:09 Brad and that's going to get great results in software engineering,
14:12 Brad right?
14:13 Brad We've talked about that in many of our episodes in the past, and a lot of the leaders that we've had on,
14:19 Brad this has been a big theme,
14:20 Brad right?
14:21 Scott Yep.
14:23 Brad I think that the straw man that the article makes, which I reject,
14:29 Brad that's why I'm calling it a straw man, is that...
14:33 Brad Definitionally, if you have a leader who is both a people manager and the buck stops here accountable for delivery,
14:45 Brad that somehow that breaks psychological safety or somehow tamps down on autonomy and shared ownership within the team.
14:56 Brad I think that's a straw man that's completely false.
14:59 Scott Mm-hmm.
14:59 Brad In fact, I would say that that's what makes a good leader and that's what I look for in a good engineering manager is somebody who's going to create that sense of empowerment and autonomy and psychological safety and, you know, being cohesive dynamic.
15:21 Brad Um,
15:22 Brad so that's like thing one that I am like,
15:25 Brad okay, I like the idea that we want to get to this place.
15:28 Brad I'm not so sure that the org structure is really the high order bit to how to get there.
15:37 Brad Um, that makes sense what I'm saying there?
15:40 Scott Yeah,
15:40 Scott makes perfect sense.
15:41 Scott Did you think there was another element there as well about?
15:46 Scott There was an implication that these teams could somehow like get better results,
15:51 Scott go faster,
15:52 Scott write better code,
15:53 Scott build better solutions to
15:54 Brad Yeah,
15:54 Scott the problem.
15:54 Brad but that's just like that's a straw man. That's that's that the only way that you can first of all, he presents no evidence of that at all.
16:03 Brad And instead only kind of uses the straw man of if you ever have any kind of.
16:12 Brad of, like...
16:15 Brad engineering manager who's both the people manager and a technical leader that somehow that eliminates autonomy that's not true or that that somehow eliminates um free thinking um you know growth mindset i mean that's not true that but that's a total straw man to say that those two things are mutually exclusive
16:35 Scott So setting that aside,
16:37 Scott do you think this kind of matrix style of team does get better results or do you think that's just a
16:43 Brad I think it's 100% about can you get the psychological safety?
16:48 Scott Okay.
16:48 Brad Can you get the true sort of like engagement at the individual level?
16:54 Brad And I think that that is,
16:58 Brad in my experience,
17:00 Brad I have seen that that is more likely to occur when you have a high quality engineering manager.
17:09 Brad than when you don't.
17:11 Scott What?
17:11 Brad And you actually,
17:13 Brad and I'm happy to answer the question that you started to ask, which is, what would be the signs and symptoms to indicate to you that an engineering management in a kind of hierarchical command and control thing is undermining the progress of the team?
17:26 Brad And what would be the sort of attributes that would be necessary for a team to have to be able to be successful at this sort of like non-hierarchical approach? Because I think there's clean answers there.
17:37 Brad And both could work in the org, but it depends on the org and the culture and the individuals in the org. Okay, let's get there in one second. I have one other question,
17:45 Brad which is, in theory, in these sort of matrix teams,
17:49 Brad you can get a diversity of skills,
17:52 Brad right?
17:52 Brad You can have a team which has one data engineer on it and one...
17:57 Scott front-end engineer on it and one you know you get kind of have that little mix of the sort of I think you know kind of back in the scrum days like well scrum still here but like that idea of the true scrum team which is its cape has all the resources it needs to get the thing done and
18:12 Scott I mean, I think is an advantage of it,
18:13 Scott right,
18:14 Scott which is theoretically you get as opposed to saying,
18:16 Scott well,
18:17 Scott we're doing this, but we need support from this other from the data team. We need support from the design team and we need support from, you know, whatever the analysts, we've got them all here on the project team.
18:28 Brad I don't see any reason why just,
18:30 Brad again,
18:31 Brad the hierarchical engineering manager structured approach doesn't mean that you can only have.
18:38 Brad you know, react native engineers on the team, right?
18:41 Scott That's
18:42 Brad Like
18:42 Scott true.
18:42 Brad if the project, if the project has, you know, ML data, you know, data analysis responsibilities and you've got those experts in your team or, you know, they can both be on the team.
18:54 Scott Yeah,
18:54 Brad That's
18:55 Scott it's true.
18:55 Brad not.
18:55 Scott We have teams where I'm working at now. We've got mobile engineers and front end engineers and back end engineers like all on the same team.
19:02 Scott I guess here's an interesting thing.
19:05 Scott You know, perhaps this approach of separating out the reporting structure from the team structure gives.
19:12 Scott an organization a little bit more fluidity of hey we put together this team build this project do it we're done but as an individual like my reporting manager isn't like that's a very kind of a disruptive thing when your manager changes right if you think about in a bigger company that has performance reviews and stuff like that it's weird when you switch managers mid cycles and stuff like that that
19:35 Brad Yeah,
19:35 Scott maybe gives a little bit flexibility there
19:37 Brad Sure.
19:38 Brad And I've used that sort of approach of like splitting,
19:41 Brad you know, kind of keeping a people. I've used this technique before in past lives and it's been in these situations where there were several sort of like, you know, kind of like tiger teams that needed to spin up to go do specific things and then they weren't going to.
19:59 Brad last that long and we did that type of approach and i think that that's a good example of when you might want to use it
20:06 Scott But that's not what this guy was saying. He was saying using it everywhere.
20:10 Scott He wasn't saying
20:10 Brad yeah and
20:11 Scott Tiger
20:11 Brad i think
20:11 Scott teams.
20:11 Brad that yeah exactly and i think that um you know again i think that
20:21 Brad there's a strong like bias in the article that kind of talks about um
20:26 Brad The hierarchical being legacy,
20:29 Brad the hierarchical being command and control,
20:31 Brad the desire to keep the hierarchy being sort of like fear of loss of control.
20:39 Brad Like there's a lot of that language in
20:41 Scott Mm
20:42 Brad that article,
20:42 Scott -hmm.
20:43 Brad right? And look,
20:45 Brad I would say that like.
20:47 Brad That may be a leading indicator that if you do have leaders in the organization and you are getting these reactions within the organization of like,
20:56 Brad these are my people,
20:58 Brad don't
20:58 Scott Yep.
20:59 Brad tell me what I do with my people, right? Like that would be a symptom that probably you do have a problem with your hierarchy and you might want to try to do something to disrupt it and affect it, right?
21:14 Brad But.
21:15 Brad That's that doesn't have that there's plenty of hierarchical organizations where there's team leaders who are both accountable for people management and results of the team who create create really strong levels of of trust and psychological safety and team ownership and,
21:36 Brad you know, servant leadership.
21:38 Brad That's what servant leadership is about.
21:40 Brad Right.
21:41 Brad And so, you know, I think that that's one of the kind of the flaws in this article,
21:48 Brad it just kind of speaks to this mistaken idea that somehow hierarchical work structures definitionally mean that you aren't also collaborative,
21:59 Scott Yeah.
21:59 Brad right?
22:00 Scott Let's swivel this around for a second to that other question.
22:03 Scott Which is, let's say you do think there's some benefit to this, right?
22:07 Scott Setting aside the critique that you've got there,
22:10 Scott you decide you want to do this with the organization.
22:15 Scott But there are conditions under which it would do better or worse,
22:18 Scott right?
22:19 Scott And I'm curious to know.
22:22 Scott I have
22:23 Brad Well,
22:23 Scott a few in mind that would make it do better or worse. I'm curious to know it. And I could see the conversation with those if you want. I could give you a blank slate. It's up to you.
22:32 Brad well, okay.
22:32 Brad I have, let me, before I share my ideas on signs and symptoms on this, let me tell you an anecdote from my career early in my career.
22:41 Scott Okay.
22:43 Brad The first time I became a manager,
22:45 Brad I had been a high performance.
22:49 Brad individual contributor.
22:51 Brad I was working on a team.
22:53 Brad I am very much a,
22:55 Brad I love the autonomy. I love managers who say, this is our goal,
22:59 Brad go figure it out, right?
23:00 Brad So I am exactly from an IC perspective, I'm the kind of IC that works fantastically in one of these kind of like non-top-down orgs. And when I first became a manager,
23:15 Brad I naively assumed that all the engineers on my team wanted to be managed by me the way I want to be managed.
23:24 Scott Yeah.
23:25 Brad And so I just kind of would walk in the room and I'd be like,
23:28 Brad hey,
23:28 Brad we're stoked.
23:29 Brad We got something to do.
23:30 Brad This is what we're going to do.
23:31 Brad This is our goal.
23:33 Brad This is where we're going.
23:34 Brad All right, everybody,
23:35 Brad go make a difference.
23:37 Brad Right.
23:38 Brad And I did that for a couple weeks.
23:41 Brad like literally the first couple weeks of being a manager and finally one of the engineers who was you know 10 years my senior um you know dragged me out you know kind of dragged me aside and he was like brad like you need to go in there and you need to go tell them what to do they want you to tell them exactly what you want them to do and you're you're you're they're they're stuck until you go do that
24:09 Brad And.
24:11 Brad I mean, that was a real eye opener for me because I was like,
24:14 Brad what?
24:14 Brad How can that be?
24:16 Brad Like, how could they want that,
24:17 Scott Mm
24:17 Brad you know?
24:18 Scott -hmm.
24:19 Brad And I'm not saying that every engineer wants to be told what to do,
24:22 Brad but I think there are a lot of engineers that actually prefer.
24:27 Brad And it's so this is why I think it's a it depends.
24:30 Brad Right.
24:31 Brad I think there's engineers who really do prefer like,
24:33 Brad hey, just give me a really well or well written ticket that's shovel ready and I'll go do it.
24:37 Brad And I like that.
24:38 Brad I feel that's that's what I like. I like to be given it and I like to be given that day to day guidance.
24:44 Brad I don't want to I don't not all engineers want to be given the burden of figure it out.
24:52 Brad So that's one of my first prerequisites to this being successful.
24:57 Scott Mm-hmm.
24:58 Brad Or maybe it's an anti-pattern. If you see this anti-pattern, you're not ready.
25:04 Brad And that is if the team heavily relies on day-to-day guidance or as a team they're struggling to break down work or they defer decisions to...
25:19 Brad They're managers.
25:19 Scott Mm
25:20 Brad You
25:20 Scott hmm.
25:20 Brad have to ask yourself,
25:21 Brad well,
25:21 Brad wait,
25:21 Brad is that because that's what the manager is because the manager is kind of forcing that on them or is that because that's the natural way that team works?
25:29 Scott Well,
25:30 Scott and I would even flip that around and say there's a certain type of.
25:34 Scott I'm just going to call it personality. I'm not sure that's quite the right word,
25:37 Scott but a person who would thrive in this environment?
25:40 Scott And do you have those people or do you not?
25:43 Scott And then I'm going to add on to that,
25:45 Scott it's not just the person.
25:46 Scott I use the word environment.
25:48 Scott You also have to have an environment where people,
25:51 Scott you've used this word many times, psychological safety is not a word, it's a phrase, but where people feel
25:59 Scott when you're making a proposal for how to solve a problem you are being vulnerable right you're you're and
26:04 Brad A hundred percent.
26:05 Scott so you have to have an environment where people feel safe doing that and part of that this is this is one of the risks i think of the of this approach but it can be fantastic it actually the the authors to say there's no leader of this team right this it's a it's an it's a it's a it's
26:25 Scott a
26:25 Scott not equilateral that's not the right word but an equal group right group of peers let's say but
26:30 Brad Yeah.
26:30 Scott the truth is there is a product manager who has come with a request and to some degree that implicitly puts them in the position of authority because they're they determine whether the request is being satisfied or not and so
26:51 Scott You almost a prerequisite is like,
26:54 Scott what is the disposition of your product managers,
26:57 Scott right?
26:57 Scott If they're bringing
26:58 Brad Well,
26:58 Scott a very collaborative mindset to the table, then it's going to work a lot better.
27:07 Scott Now
27:07 Brad another
27:07 Scott here, yeah.
27:08 Brad way to say that, another way to say that, Scott, is that.
27:12 Brad look at these kind of areas of gravity in
27:15 Scott Mm-hmm.
27:16 Brad the project and one of them is obviously the product manager another one is going to be like
27:21 Brad design another one's going to be engineering right
27:24 Scott Yeah, hmm
27:24 Brad you got to look at those sort of centers of gravity and ask yourself are they generally balanced are they generally fluid in their working style and if they're not if there's if there is existing you know tension between those groups then
27:46 Brad Taking out an actual assigned accountable leader is definitely going to be a recipe for stalling.
27:54 Scott Well,
27:54 Scott you brought up gravity. This brings up another piece. You talked about the engineers.
27:59 Scott Well, it's really actually there's one particular engineer that's critical to have this system working.
28:07 Scott I'm just going to refer to that person as the tech lead.
28:10 Brad Yep.
28:10 Scott That's a very broadly used term, but ultimately someone has to get the engineers on the same page in regard to the technical design.
28:21 Brad Yep.
28:22 Brad And in the article,
28:23 Brad that's kind of one of the roles that
28:26 Scott Yeah,
28:27 Brad you described
28:27 Scott that's right.
28:27 Brad in this cross-functional team.
28:28 Scott OK,
28:29 Scott so here's two things that I thought would be necessary for this to be successful.
28:37 Scott a fat platform because the alternative is you might end up with a bunch of silos right we've talked about silos before among this
28:46 Brad Oh, you mean, let me just make sure I'm understanding what you're saying. What you're saying is that.
28:53 Brad If you, well, gosh,
28:55 Brad the episode that recently came out about with Greg Conklin, where he kind of talked about Groupon versus Dropbox, Dropbox had a fat platform layer,
29:06 Brad Groupon had a bunch of tiny little two pizza teams that had all of their own code.
29:12 Brad And so you're saying that.
29:15 Brad What are you saying about that?
29:16 Scott I'm saying that this, well, these are two pizza teams they're talking about, this author's talking about, and I'm saying you run a big risk of ending up with a ball of mud in this kind of situation because as a team, we're focused on delivering the thing that we're delivering and we don't really have an incentive other than altruism.
29:40 Scott to do
29:43 Scott anything more than what we need to do to get our thing done because we're being held accountable to delivering our thing and that can work really well if you've got a very robust platform that you're essentially building on top of but if it comes to pass that
30:02 Scott Well,
30:02 Scott I don't know.
30:03 Scott My team needed a key value store for something and your team needed a key value store for something.
30:11 Scott That's very generic, but let's even go further.
30:13 Scott Like my team needed a tagging system for we're running an e-commerce site and I wanted to label things and you wanted to label things and we don't collaborate on that to build one labeling system. We end up with two labeling systems,
30:26 Scott right?
30:26 Brad I think that's another.
30:27 Brad I 100% agree that that's a very likely thing to happen in this kind of a configuration.
30:32 Brad And so then you just have to ask yourself, like, was that wrong or is that appropriate for the org and the business goals,
30:39 Brad right?
30:40 Brad So if your business is of the nature that having a lot of like silos that are potentially redundant and potentially conflicting with each other is,
30:53 Brad you know, existential.
30:55 Brad Right. Well, then that don't do that if your business can tolerate that,
31:01 Brad because for whatever reason,
31:03 Brad like strategically,
31:05 Brad you're in hyper growth mode, you know, like in the in the Groupon story,
31:09 Brad it was like they were different regions. And so it was kind of OK that they had slightly different features and functionality, you know, and I could picture a whole bunch of other scenarios where that challenge that you're highlighting,
31:18 Brad which is for sure going to happen in this model.
31:22 Brad If it doesn't have the right setup,
31:25 Brad that
31:26 Scott Yeah,
31:26 Brad might not be a problem
31:28 Scott it
31:28 Brad necessarily.
31:28 Scott might not be a problem.
31:29 Scott I'll flip it around. If you find yourself in a situation, and I have found myself in this situation before,
31:35 Scott where an engineering team,
31:38 Scott the velocity or quality was not what the organization wanted because of previous siloing.
31:46 Brad Right?
31:46 Scott this is going to make it potentially make it worse unless you have a fat you invest a bunch in your platform team right you say okay that's cool we're going to make a bunch of these you know teams running around doing crazy stuff but we got a foundation underneath them so that there's going to be one labeling system right and
32:04 Brad Yeah,
32:04 Scott that
32:05 Brad 100%. I
32:05 Scott that's a condition i think you'd have to have to make it successful
32:10 Brad agree.
32:11 Brad I thought you were going to say something slightly different about tech leads.
32:14 Scott Okay.
32:14 Brad And so let me share this idea.
32:20 Brad When I think about,
32:21 Brad well,
32:23 Brad so I'm going to contrast a tech lead as articulated in this article to what I consider what I'm looking for in an engineering manager.
32:32 Scott Okay.
32:34 Brad I think this article is speaking to the idea of like have the strongest technical person that you can get be the technical lead on the team.
32:44 Scott Yeah.
32:45 Brad And there's a sort of second there's another straw man that he kind of makes that it's it's a you're asking for too much if you want your strongest technical person to also be a good people manager.
32:57 Brad That's a unicorn and you can't find that.
33:00 Brad Okay.
33:01 Brad All right. So let's just say that we've said,
33:03 Brad you know what, what we really want is the strongest technical person that we can get and they're going to be this person on this team.
33:10 Brad If that person has no EQ and is not good at advocating with for or with the other engineers.
33:26 Brad collaborating with your product owner then you're equally up a creek without a paddle and so this model assumes that somebody somebody in this this this constellation has to be fluent enough technically
33:51 Brad and fluent enough from an EQ team persuasion collaboration.
33:59 Brad Like somebody has to have both those skills for this constellation to work.
34:05 Scott Yeah, you're saying I agree with you and I would.
34:09 Scott pretty much slightly differently which is i actually think strongest technical tech lead is its own skill and so strongest technical person and tech lead are not the same thing i'm not trying to toot my own i was a very good tech lead i was never the strongest technical person and
34:25 Brad Yeah.
34:25 Scott i was a good tech lead because i could talk to the product manager understand what they want i could i was good enough engineer that i could talk to engineers and figure how to build it and i could write down
34:35 Scott I could write it down. I had the communication skills,
34:37 Scott right?
34:38 Scott Draw a picture of it, write a document, whatever it was.
34:40 Scott And so...
34:42 Scott I,
34:42 Brad And and you weren't a jackass.
34:45 Scott wasn't that.
34:46 Brad So you
34:46 Scott Well,
34:47 Scott I think a weren't lot of
34:47 Brad a jackass.
34:48 Scott people would say
34:48 Brad And so.
34:48 Scott I was a jackass actually, but besides
34:50 Brad Well,
34:50 Scott the point.
34:50 Brad I mean, we're all we all grow and mature over our lifetime.
34:55 Brad But the point is that in it, I yes,
34:59 Brad everything that you just said is exactly what I'm talking about. And I think that that's, again,
35:06 Brad kind of like.
35:07 Brad This misunderstanding of kind of this constellation,
35:10 Brad right,
35:10 Brad where it's like you can't not have,
35:14 Brad you need to have a person that's capable of doing those things that you just described.
35:23 Brad being good at keeping everybody on track.
35:27 Brad And I don't mean the sort of like agile scrum master project manager stuff of keeping everybody on track, but I mean the growing of consensus.
35:37 Scott Yeah, that's right.
35:38 Scott Yeah,
35:39 Scott that is a very specific tech. The growing of consensus is that tech lead skill.
35:46 Scott Yeah, that was one of the conditions I thought as I was thinking about this. You have to have enough people who have that in order
35:52 Brad And
35:52 Scott to.
35:52 Brad typically, typically that's what I look for in an engineering manager,
35:56 Brad right?
35:57 Brad So what I look for in an engineering manager is somebody who has all those skills that you just described.
36:02 Brad They don't have to be the strongest technical person,
36:05 Brad but they definitely have to be fluent in whatever the team is doing.
36:12 Brad And also,
36:14 Brad they need to be fluent enough and practiced enough in the technology that they are able to differentiate between good ideas and bad ideas.
36:26 Brad And if they're really going to be good at keeping this constellation together,
36:31 Brad they also have to be able to hear the idea from the junior engineer.
36:37 Scott Mm-hmm.
36:38 Brad That is a better idea than the engineer, the idea from the engineer that's got 10 years experience and they need to be able to manage that and a small and manage that subtlety and that nuance.
36:53 Scott Yeah, for sure.
36:55 Brad And I there's I mean, it's not that that's.
37:03 Brad You don't have to have a title to be good at that.
37:06 Scott No,
37:07 Brad And so if you have those types of people and you can sprinkle them in these little constellation teams,
37:12 Brad fantastic.
37:13 Brad But those people actually would be really good people managers and are really good engineering managers.
37:21 Scott often,
37:22 Scott you know, there's a lot of books I want to write or a lot of chapters in one book I want to write and one of them is
37:28 Scott the subject which is the maybe I've said it at some point on the pod but like career guidance I frequently give to like senior engineers or mid-level engineers who are crying early any engineer who's asking me about how do I advance my career I said look you want to get to the point where you're good at those tech lead skills because at that point you're at a fork in the road
37:52 Scott Now you can say, I want to go down this management route,
37:56 Scott or I want to continue on an engineer route.
37:58 Scott But in either case, what you've got is the skill of, I know how to get a bunch of engineers to coalesce.
38:08 Scott We have general consensus around a plan such that we can then all go off and take tickets off the board and do it.
38:15 Brad Yep.
38:16 Scott And to me, that is actually the most important or actually I don't know if it's important is the right word.
38:21 Scott I'll say the most valuable.
38:24 Scott skill right essentially it's the person who can talk to someone who's got an idea and talk to people who know how to turn ideas into software and bring them together and make a plan you are the Rosetta Stone right almost and I don't know if you're really a Rosetta Stone but you're kind of a Rosetta Stone but to me that is the skill where value gets created and if you can get yourself there as an engineer then you can say what do I want to do next with my career
38:49 Scott Do I like building the stuff? Then I'm going to go this IC principal engineer kind of route.
38:53 Scott Or do I like the people part of it? And then I'm going to go this manager route.
38:57 Scott We digress.
38:58 Scott Okay, so.
38:59 Brad Well, but I think that, yes,
39:01 Brad we had digressed a little bit, but to me, if we're going to enumerate like what are the prerequisites to make the.
39:08 Brad What are the prerequisites to
39:10 Scott Yeah
39:10 Brad make this kind of like cross-functional team successful?
39:12 Brad And one of the answers I think is a prerequisite is you've got to have somebody on the team,
39:19 Brad probably the tech lead is the best person, but you've got to have that person that is good at that.
39:28 Brad that everybody else on the team respects enough Yep. to listen to them.
39:32 Scott So if you're going to embark on this, you have to have some of those people in your organization to start.
39:36 Brad Have to.
39:37 Scott OK,
39:37 Brad You
39:37 Scott I want have to go
39:38 Brad to have at least one of those people for every one of these teams you're going to create.
39:42 Scott back and add on to my comment about the thick platform,
39:45 Scott the fat platform.
39:47 Scott This might be a compliment to that comment or it might be a substitute for that comment. I'm not sure.
39:52 Scott Which is.
39:54 Scott If your organization has a well understood.
39:59 Brad If it's solid shared understanding of the overall design and architecture of the system,
40:04 Brad it will work well.
40:06 Brad If you don't.
40:08 Brad it will struggle.
40:10 Brad And I don't know if that's a substitute for the platform or if it's a complement to it, but I think it's key that if you have that, if generally speaking, everyone in your organization can sort of articulate this is how it works. And if you say,
40:22 Brad hey, we need you to add a flex capacitor in here,
40:25 Brad they can say, well,
40:26 Brad great, we know exactly where this should go in the system. And largely people agree that that's the right solution.
40:32 Brad Then you'll, then it'll go.
40:34 Brad Well, or it's just either way around. It still might not go well, but if the opposite is true, it's not going to go well.
40:40 Scott Yeah.
40:41 Scott And if we like.
40:44 Scott Compare and contrast that to what we would say the alternative is where we have an engineering manager.
40:51 Scott And if we have an engineering manager who is really fluid in the conversation, in the technical conversation,
40:58 Scott they're really fluid in the people management piece of it,
41:01 Scott the building of consensus,
41:02 Scott the understanding the needs of the project,
41:05 Scott understanding the business needs,
41:06 Scott the understanding of the needs of the individual members of the team.
41:10 Scott of the team their strengths and weaknesses right then that can make you get through the hard problems that don't have you know obvious technical
41:22 Brad Mm
41:22 Scott answer right
41:22 Brad -hmm.
41:23 Scott because then you at least have somebody who's kind of like okay yes this is hard this is going to be hard i we're going to have to we're going to have to do something special on this one let's not give it to bob
41:36 Scott Because Bob doesn't know that part of the code at all.
41:40 Brad Yeah,
41:41 Brad that's
41:41 Scott Let's give it to Valerie because she's worked on that code for the last five years.
41:50 Brad true.
41:50 Brad Okay,
41:51 Brad Brad,
41:51 Brad one last question for you.
41:53 Brad You said you've done this before.
41:56 Brad And I guess my question is, would you do it again?
42:04 Scott It takes a very,
42:05 Scott it's a lot harder to pull off than the EM model.
42:09 Scott I think it
42:11 Brad interesting
42:12 Scott is.
42:12 Brad is is it equal so it's much harder to pull off and under the umbrella of you you get what you pay for so you have to pay more for it and work it harder is it equally better or bet or even more you get value for that effort
42:29 Brad Or is it not worth it?
42:31 Scott I think that if you have the type of team that can thrive in this cross-functional team model,
42:37 Scott if the individuals in your organization are going to thrive in that model,
42:44 Scott they're already thriving in the EM model.
42:48 Brad Yeah,
42:48 Brad that's right.
42:50 Brad So if you think
42:51 Scott I
42:51 Brad it's, if
42:51 Scott mean, if this
42:51 Brad it has interesting,
42:52 Scott if someone's if someone's looking at this and saying, I want to go do this because we're not thriving right now and I think this is going to make us thrive.
43:00 Brad not the answer.
43:02 Scott I don't think so.
43:03 Brad Yeah,
43:03 Scott I've
43:03 Brad it's fascinating.
43:03 Scott never seen that. I've never seen that be the answer.
43:06 Brad Yeah.
43:07 Scott Let's think let's think about some other things, right?
43:10 Scott Go be a fly on the wall.
43:12 Scott Go get behind the mirrored window and watch.
43:16 Scott Do the team members, when they're interacting with each other, do they give each other feedback?
43:21 Scott Are they are they direct and open with each other about what they think the good ideas are or the hard ideas are? Are they willing to say I'm struggling with this?
43:29 Scott Are they able to are when when the when the engineer says,
43:33 Scott hey,
43:34 Scott you know, product designer like that's cool looking, but it's going to take me this much hard work to do it that way.
43:40 Scott What do you think about this idea over here?
43:43 Scott Right. If that's the kind of conversation they're having,
43:45 Scott that's fantastic.
43:46 Scott If it's like, oh,
43:47 Scott I got to do it exactly the way the designer said,
43:49 Scott and that means I'm spending the next three months on this and I don't bother to say, did you know there's a three day version of this that I could also do?
43:56 Scott Right.
43:57 Scott So like.
43:58 Scott Which what which what does the team dynamic already look like?
44:02 Brad Right,
44:02 Brad right.
44:03 Scott Right.
44:04 Scott And.
44:06 Scott If the team dynamic is already that people work that way and are collaborative and have great psychological safety and are autonomous and open-minded, then I bet you the engineering manager is the one that made that happen.
44:20 Brad Well,
44:21 Brad and I bet you something else, which is that organization probably already is kind of informally working this way anyhow.
44:28 Scott Of course.
44:29 Brad What that's what's happened is there's a project and some engineers and designer and whoever they've gotten together and they've started working as a very collaborative unit naturally without any
44:40 Scott Naturally.
44:41 Brad structure to it.
44:43 Scott Yeah.
44:43 Brad Yeah.
44:43 Scott And,
44:44 Scott and this again,
44:45 Scott like this is where I'd say like, that might that probably happened because there was a really good engineering manager.
44:51 Scott Right.
44:52 Scott And the engineering manager was like.
44:55 Scott Hey,
44:55 Scott Valerie,
44:56 Scott Bob,
44:57 Scott I want you to meet Rajesh. Rajesh is the new designer that just started.
45:02 Scott Rajesh is going to be 100% on this project.
45:05 Scott He reports to Bill over there,
45:07 Scott but you guys are going to be collaborating together.
45:10 Brad Mm
45:10 Scott And Bill and the engineering manager,
45:13 Scott they understand that this collaboration happens.
45:15 Scott And so they're not territorial about it,
45:17 Scott and they both facilitate it.
45:22 Brad There's another thing I think of as a flaw.
45:24 Brad Here is one place where I will be critical of this approach.
45:28 Brad So then what do your engineering managers do?
45:31 Brad Yeah.
45:31 Scott You mean in the version where you just have these clusters and the engineering managers are people managers?
45:35 Brad Yeah.
45:36 Scott Oh, yeah,
45:37 Scott totally.
45:38 Scott I don't want to be an engineering manager in that company.
45:41 Scott They're party planners.
45:44 Scott They're just throwing birthday parties and like organizing like virtual,
45:48 Scott you know, mixers.
45:52 Brad Yeah, unless to some degree they're capable of also sometimes playing a role in one of these teams as an engineer or a tech lead or whatever.
46:03 Scott Okay, sure.
46:05 Scott Agreed.
46:06 Brad Okay,
46:07 Brad so I think we've decided we don't like this idea.
46:11 Scott I could have told you that as soon as you sent me the article.
46:14 Brad Yeah, I think it's interesting.
46:16 Brad I think what you're really getting at, what it really tells us is.
46:19 Brad The org structure doesn't make a difference.
46:22 Brad That's your key point.
46:23 Brad It is the interactions,
46:24 Brad the EQ,
46:25 Brad the interactions,
46:26 Brad the psychological safety. It's all those kinds of things that make the difference.
46:29 Brad And if you get that stuff right, people are organized doesn't make any difference.
46:33 Brad And if what you're trying to do is say, hey, my team is not being as effective,
46:36 Brad my team or my organization is not being as effective as I want it to be.
46:41 Brad So I'm going to try some new org structure or some new way of doing it.
46:46 Brad That's you're treating a symptom.
46:48 Brad You're not getting to the root of the issue.
46:51 Scott Yeah, I
46:51 Brad And the root of the issue, frankly, is really,
46:53 Brad really hard,
46:54 Brad right?
46:55 Brad It's people skills.
46:57 Brad It's that we've talked about many times. It's the psychological safety. It's EQ.
47:00 Brad That stuff is just crazy, crazy hard to get right.
47:06 Brad Actually,
47:06 Scott 100%
47:06 Brad I shouldn't
47:07 Scott agree with
47:07 Brad say it's
47:07 Scott that.
47:07 Brad crazy hard to get right.
47:10 Brad It's hard to correct when an organization is, I'll use a strong word,
47:17 Brad it might be just wrong, being poisoned,
47:18 Brad right?
47:19 Brad It's hard to unwind or hard, it's a hard antidote to that because it's, you know, it's people's emotions and feelings and things like that is very, very difficult to change.
47:32 Scott I 100% agree with that.
47:35 Scott I think that, you know, there was something in the article that I thought kind of tried to speak to this, which is this idea that somehow the way you organize your team actually speaks to your core beliefs.
47:53 Scott And this notion of like, if you're a hierarchical team that you clearly are, you believe in.
47:59 Scott top-down command and control.
48:00 Brad Mm-hmm.
48:03 Scott And I reject that premise.
48:06 Scott I think your core beliefs override everything.
48:11 Scott And if you have core beliefs that we are a team together,
48:17 Scott that we hold each other accountable,
48:19 Scott that we create psychological safety,
48:21 Scott that we are growth mindset.
48:24 Scott Then those core beliefs transcend
48:28 Scott project organization.
48:33 Brad Yeah,
48:34 Brad I don't think that's incompatible with what the author said,
48:36 Brad which is if you have command and control beliefs, you're going to do the hierarchical approach and you're going to reject the matrix approach.
48:43 Brad And what you're saying is if you don't have if you have other core beliefs like you just enumerated.
48:47 Brad You're going to have a, you're going to choose either because the structures are relevant to you.
48:52 Scott Exactly.
48:54 Brad Well,
48:54 Brad Brad, this has been a fun conversation today.
48:58 Scott I really enjoyed it.
48:59 Brad I really enjoyed this one too.
49:01 Brad What do we want to tell everybody?
49:03 Scott Um, smash
49:04 Brad I thought you were just going to say smash rate and subscribe.
49:06 Brad I know you're trying to come up with.
49:07 Scott rate,
49:07 Scott subscribe.
49:09 Scott Oh,
49:09 Scott support us on Patreon.
49:11 Scott Support
49:11 Brad We have
49:12 Scott us on Patreon.
49:12 Brad we have our first Patreon supporter,
49:14 Brad don't we? Isn't that true?
49:16 Scott Paid a paid Patreon supporter.
49:17 Scott It's true.
49:17 Brad Out of our hundreds and hundreds of listeners,
49:20 Brad we have now have one paid Patreon supporter.
49:24 Scott Yeah.
49:24 Brad We got to go make that Patreon page look better.
49:26 Brad I set that whole thing up on my phone, by the way.
49:28 Brad I need to tell,
49:30 Brad I need to, can I tell ChatGPT codex, go make our Patreon page look better?
49:36 Scott I haven't tried that, but you definitely should try
49:38 Brad Can
49:38 Scott that.
49:38 Brad I just paste my credentials into ChatGPT and it'll make it work?
49:41 Scott What could go wrong?
49:44 Scott What could go wrong?
49:44 Brad All right, Brad,
49:45 Brad thanks for your time today.
49:47 Brad This has been fun.
49:47 Brad I can't wait to do this again with you next week.
49:50 Brad And
49:50 Scott Yeah,
49:51 Brad we'll talk to you soon.
49:52 Scott talk to you soon.
49:55 Scott This episode of How Many CTOs Does It Take podcast was edited by Saffron Heptagap.
50:00 Scott Our theme song was AI Generated by Brad.
50:03 Scott Please follow us on all the social media platforms at at HowManyCTOsPod.
50:08 Scott You can find us on YouTube,
50:10 Scott LinkedIn,
50:11 Scott Instagram,
50:11 Scott Facebook,
50:12 Scott Threads, X,
50:13 Scott TikTok,
50:14 Scott and Patreon,
50:15 Scott or at our website at HowManyCTOsPod.com.
50:19 Scott And remember to rate, review,
50:21 Scott and subscribe on the podcast platform of your choice.