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 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 My name is Scott Porad and this is my co-host.

0:43 Brad: Brad Hefta-Gaub.

0:45 Scott: Brad,

0:45 how are you doing?

0:46 Brad: I'm doing pretty good. Yeah.

0:48 Scott: Good.

0:49 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 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 I have, I have, it's been fun.

1:27 Scott: Well,

1:28 it's very interesting you say that because I used chat GPT codecs for the first time myself yesterday,

1:34 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 I just thought this is not fun.

1:45 I asked it to do something and I just sat there and waited for it to do it.

1:48 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 And I thought to myself,

1:52 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 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 And I've gotten to the habit of like.

2:11 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 It has to be very asynchronous, right?

2:30 I was actually actively trying to do something and being engaged in it. And then it led me to think.

2:35 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 I'm going to set this off, but I'm not going to come back to it till later.

2:48 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 And then I was kind of going and finding some secondary things to work on.

3:03 Brad: Well,

3:04 and then the other thing I've started doing is being completely not precious about whatever it comes back with.

3:10 So if I look at it and it missed the mark,

3:14 I just delete the pull request and say,

3:17 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 I asked it to start writing a React Native app for me and I've done some like Hello World apps,

3:32 little,

3:32 you know, make a duck fart kind of React Native type apps, but I've never really done anything with it.

3:38 And so it came back and I started looking at it was came back with 60 files and I thought to myself,

3:45 I don't know if this is right.

3:48 And I don't actually know how to know if this is right.

3:51 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 is this right?

3:59 Brad: What do you think of this?

4:00 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 now this isn't right, you'll appreciate this part.

4:09 Then when I said, OK,

4:10 well, here's how I'm going to know if it's right,

4:11 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 I happen to have a new computer.

4:21 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 That's coming,

4:45 I'm sure.

4:46 Scott: Oh, yeah.

4:47 So actually, that's what stopped me is I didn't have homebrew and I was like,

4:50 oh, brother.

4:51 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 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 that's like

5:34 Scott: That's bush league, my friend.

5:36 Going back a few. So several companies ago, we started doing this. I did it at two companies.

5:42 So for a total of 13 years,

5:45 engineers zipped code to production on their first day.

5:51 Brad: Oh, well,

5:52 there you go.

5:52 Scott: To make that happen,

5:54 took a ton of work. Because when we first started.

5:59 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 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 We had to do some work with our people team,

6:41 right?

6:41 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 And there was this study I saw actually John Helm, who was on this podcast previously,

6:51 is the one that tipped me off to this decades ago.

6:54 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 bureaucracy,

7:13 red tape, paperwork,

7:14 all that nonsense.

7:15 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 competency,

7:24 you know, those kinds of things. Right.

7:26 And then right in the middle, neither.

7:29 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 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 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 And that was a real key,

8:32 right?

8:33 And what we found was people loved the experience.

8:39 They didn't remember all of it. I mean, like, you know,

8:41 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 Like you just had to have the machine there on the first day.

8:57 Brad: And are you, yeah,

8:58 are you, so that sounds like a utopia. I love the sound of that.

9:03 Scott: Yeah,

9:03 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 And so it's been, it was, it was those two, and then I've been at three places since,

9:21 and I haven't done it at three places since.

9:26 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 So it's just not the biggest problem to solve.

9:39 Brad: Yeah.

9:40 Fair enough.

9:41 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 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 I got an article forwarded to me today about engineering management and how to organize an engineering team.

10:11 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 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 look,

10:23 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 They deliver stuff.

10:37 And so the engineering manager is responsible for both the personnel management of their team and.

10:46 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 that, you know,

11:14 consist of engineers from a variety of teams,

11:16 consist of perhaps designers, product managers,

11:19 whatever skills you need for that thing,

11:21 for that objective.

11:25 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 And it was thought provoking.

11:36 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 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 okay, or alternatively, what conditions

12:16 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 thanks for having me on the podcast,

12:39 Scott.

12:40 I've been a longtime listener,

12:41 first time caller.

12:44 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 There were a few things that the that the.

12:56 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 expose some of the challenges.

13:23 Scott: Okay.

13:24 Brad: So the why that he,

13:26 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 some appropriate level of autonomy,

13:43 and team accountability for results.

13:48 Like that,

13:49 if you can get a team to feel a strong sense of ownership about their results,

13:55 a sense of accountability to each other,

13:58 and all of the psychological safety that's necessary to make that happen,

14:06 right,

14:07 then that's...

14:08 That's goodness,

14:09 and that's going to get great results in software engineering,

14:12 right?

14:13 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 this has been a big theme,

14:20 right?

14:21 Scott: Yep.

14:23 Brad: I think that the straw man that the article makes, which I reject,

14:29 that's why I'm calling it a straw man, is that...

14:33 Definitionally, if you have a leader who is both a people manager and the buck stops here accountable for delivery,

14:45 that somehow that breaks psychological safety or somehow tamps down on autonomy and shared ownership within the team.

14:56 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 Um,

15:22 so that's like thing one that I am like,

15:25 okay, I like the idea that we want to get to this place.

15:28 I'm not so sure that the org structure is really the high order bit to how to get there.

15:37 Um, that makes sense what I'm saying there?

15:40 Scott: Yeah,

15:40 makes perfect sense.

15:41 Did you think there was another element there as well about?

15:46 There was an implication that these teams could somehow like get better results,

15:51 go faster,

15:52 write better code,

15:53 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 And instead only kind of uses the straw man of if you ever have any kind of.

16:12 of, like...

16:15 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 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 And I think that that is,

16:58 in my experience,

17:00 I have seen that that is more likely to occur when you have a high quality engineering manager.

17:09 than when you don't.

17:11 Scott: What?

17:11 Brad: And you actually,

17:13 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 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 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 which is, in theory, in these sort of matrix teams,

17:49 you can get a diversity of skills,

17:52 right?

17:52 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 I mean, I think is an advantage of it,

18:13 right,

18:14 which is theoretically you get as opposed to saying,

18:16 well,

18:17 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 again,

18:31 the hierarchical engineering manager structured approach doesn't mean that you can only have.

18:38 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 I guess here's an interesting thing.

19:05 You know, perhaps this approach of separating out the reporting structure from the team structure gives.

19:12 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 And I've used that sort of approach of like splitting,

19:41 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 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 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 there's a strong like bias in the article that kind of talks about um

20:26 The hierarchical being legacy,

20:29 the hierarchical being command and control,

20:31 the desire to keep the hierarchy being sort of like fear of loss of control.

20:39 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 I would say that like.

20:47 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 these are my people,

20:58 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 But.

21:15 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 you know, servant leadership.

21:38 That's what servant leadership is about.

21:40 Right.

21:41 And so, you know, I think that that's one of the kind of the flaws in this article,

21:48 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 Which is, let's say you do think there's some benefit to this, right?

22:07 Setting aside the critique that you've got there,

22:10 you decide you want to do this with the organization.

22:15 But there are conditions under which it would do better or worse,

22:18 right?

22:19 And I'm curious to know.

22:22 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 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 I had been a high performance.

22:49 individual contributor.

22:51 I was working on a team.

22:53 I am very much a,

22:55 I love the autonomy. I love managers who say, this is our goal,

22:59 go figure it out, right?

23:00 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 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 hey,

23:28 we're stoked.

23:29 We got something to do.

23:30 This is what we're going to do.

23:31 This is our goal.

23:33 This is where we're going.

23:34 All right, everybody,

23:35 go make a difference.

23:37 Right.

23:38 And I did that for a couple weeks.

23:41 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 And.

24:11 I mean, that was a real eye opener for me because I was like,

24:14 what?

24:14 How can that be?

24:16 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 but I think there are a lot of engineers that actually prefer.

24:27 And it's so this is why I think it's a it depends.

24:30 Right.

24:31 I think there's engineers who really do prefer like,

24:33 hey, just give me a really well or well written ticket that's shovel ready and I'll go do it.

24:37 And I like that.

24:38 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 I don't want to I don't not all engineers want to be given the burden of figure it out.

24:52 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 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 They're managers.

25:19 Scott: Mm

25:20 Brad: You

25:20 Scott: hmm.

25:20 Brad: have to ask yourself,

25:21 well,

25:21 wait,

25:21 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 and I would even flip that around and say there's a certain type of.

25:34 I'm just going to call it personality. I'm not sure that's quite the right word,

25:37 but a person who would thrive in this environment?

25:40 And do you have those people or do you not?

25:43 And then I'm going to add on to that,

25:45 it's not just the person.

25:46 I use the word environment.

25:48 You also have to have an environment where people,

25:51 you've used this word many times, psychological safety is not a word, it's a phrase, but where people feel

25:59 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 a

26:25 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 You almost a prerequisite is like,

26:54 what is the disposition of your product managers,

26:57 right?

26:57 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 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 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 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 Taking out an actual assigned accountable leader is definitely going to be a recipe for stalling.

27:54 Scott: Well,

27:54 you brought up gravity. This brings up another piece. You talked about the engineers.

27:59 Well, it's really actually there's one particular engineer that's critical to have this system working.

28:07 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 And in the article,

28:23 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 so here's two things that I thought would be necessary for this to be successful.

28:37 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 If you, well, gosh,

28:55 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 Groupon had a bunch of tiny little two pizza teams that had all of their own code.

29:12 And so you're saying that.

29:15 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 to do

29:43 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 Well,

30:02 I don't know.

30:03 My team needed a key value store for something and your team needed a key value store for something.

30:11 That's very generic, but let's even go further.

30:13 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 right?

30:26 Brad: I think that's another.

30:27 I 100% agree that that's a very likely thing to happen in this kind of a configuration.

30:32 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 right?

30:40 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 you know, existential.

30:55 Right. Well, then that don't do that if your business can tolerate that,

31:01 because for whatever reason,

31:03 like strategically,

31:05 you're in hyper growth mode, you know, like in the in the Groupon story,

31:09 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 which is for sure going to happen in this model.

31:22 If it doesn't have the right setup,

31:25 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 I'll flip it around. If you find yourself in a situation, and I have found myself in this situation before,

31:35 where an engineering team,

31:38 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 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 When I think about,

32:21 well,

32:23 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 That's a unicorn and you can't find that.

33:00 Okay.

33:01 All right. So let's just say that we've said,

33:03 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 If that person has no EQ and is not good at advocating with for or with the other engineers.

33:26 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 and fluent enough from an EQ team persuasion collaboration.

33:59 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 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 I could write it down. I had the communication skills,

34:37 right?

34:38 Draw a picture of it, write a document, whatever it was.

34:40 And so...

34:42 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 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 But the point is that in it, I yes,

34:59 everything that you just said is exactly what I'm talking about. And I think that that's, again,

35:06 kind of like.

35:07 This misunderstanding of kind of this constellation,

35:10 right,

35:10 where it's like you can't not have,

35:14 you need to have a person that's capable of doing those things that you just described.

35:23 being good at keeping everybody on track.

35:27 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 Yeah,

35:39 that is a very specific tech. The growing of consensus is that tech lead skill.

35:46 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 right?

35:57 So what I look for in an engineering manager is somebody who has all those skills that you just described.

36:02 They don't have to be the strongest technical person,

36:05 but they definitely have to be fluent in whatever the team is doing.

36:12 And also,

36:14 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 And if they're really going to be good at keeping this constellation together,

36:31 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 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 fantastic.

37:13 But those people actually would be really good people managers and are really good engineering managers.

37:21 Scott: often,

37:22 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 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 Now you can say, I want to go down this management route,

37:56 or I want to continue on an engineer route.

37:58 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 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 I'll say the most valuable.

38:24 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 Do I like building the stuff? Then I'm going to go this IC principal engineer kind of route.

38:53 Or do I like the people part of it? And then I'm going to go this manager route.

38:57 We digress.

38:58 Okay, so.

38:59 Brad: Well, but I think that, yes,

39:01 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 What are the prerequisites to

39:10 Scott: Yeah

39:10 Brad: make this kind of like cross-functional team successful?

39:12 And one of the answers I think is a prerequisite is you've got to have somebody on the team,

39:19 probably the tech lead is the best person, but you've got to have that person that is good at that.

39:28 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 the fat platform.

39:47 This might be a compliment to that comment or it might be a substitute for that comment. I'm not sure.

39:52 Which is.

39:54 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 it will work well.

40:06 If you don't.

40:08 it will struggle.

40:10 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 hey, we need you to add a flex capacitor in here,

40:25 they can say, well,

40:26 great, we know exactly where this should go in the system. And largely people agree that that's the right solution.

40:32 Then you'll, then it'll go.

40:34 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 And if we like.

40:44 Compare and contrast that to what we would say the alternative is where we have an engineering manager.

40:51 And if we have an engineering manager who is really fluid in the conversation, in the technical conversation,

40:58 they're really fluid in the people management piece of it,

41:01 the building of consensus,

41:02 the understanding the needs of the project,

41:05 understanding the business needs,

41:06 the understanding of the needs of the individual members of the team.

41:10 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 Because Bob doesn't know that part of the code at all.

41:40 Brad: Yeah,

41:41 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 Okay,

41:51 Brad,

41:51 one last question for you.

41:53 You said you've done this before.

41:56 And I guess my question is, would you do it again?

42:04 Scott: It takes a very,

42:05 it's a lot harder to pull off than the EM model.

42:09 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 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 if the individuals in your organization are going to thrive in that model,

42:44 they're already thriving in the EM model.

42:48 Brad: Yeah,

42:48 that's right.

42:50 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 Go be a fly on the wall.

43:12 Go get behind the mirrored window and watch.

43:16 Do the team members, when they're interacting with each other, do they give each other feedback?

43:21 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 Are they able to are when when the when the engineer says,

43:33 hey,

43:34 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 What do you think about this idea over here?

43:43 Right. If that's the kind of conversation they're having,

43:45 that's fantastic.

43:46 If it's like, oh,

43:47 I got to do it exactly the way the designer said,

43:49 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 Right.

43:57 So like.

43:58 Which what which what does the team dynamic already look like?

44:02 Brad: Right,

44:02 right.

44:03 Scott: Right.

44:04 And.

44:06 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 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 and this again,

44:45 like this is where I'd say like, that might that probably happened because there was a really good engineering manager.

44:51 Right.

44:52 And the engineering manager was like.

44:55 Hey,

44:55 Valerie,

44:56 Bob,

44:57 I want you to meet Rajesh. Rajesh is the new designer that just started.

45:02 Rajesh is going to be 100% on this project.

45:05 He reports to Bill over there,

45:07 but you guys are going to be collaborating together.

45:10 Brad: Mm

45:10 Scott: And Bill and the engineering manager,

45:13 they understand that this collaboration happens.

45:15 And so they're not territorial about it,

45:17 and they both facilitate it.

45:22 Brad: There's another thing I think of as a flaw.

45:24 Here is one place where I will be critical of this approach.

45:28 So then what do your engineering managers do?

45:31 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 totally.

45:38 I don't want to be an engineering manager in that company.

45:41 They're party planners.

45:44 They're just throwing birthday parties and like organizing like virtual,

45:48 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 Agreed.

46:06 Brad: Okay,

46:07 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 I think what you're really getting at, what it really tells us is.

46:19 The org structure doesn't make a difference.

46:22 That's your key point.

46:23 It is the interactions,

46:24 the EQ,

46:25 the interactions,

46:26 the psychological safety. It's all those kinds of things that make the difference.

46:29 And if you get that stuff right, people are organized doesn't make any difference.

46:33 And if what you're trying to do is say, hey, my team is not being as effective,

46:36 my team or my organization is not being as effective as I want it to be.

46:41 So I'm going to try some new org structure or some new way of doing it.

46:46 That's you're treating a symptom.

46:48 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 really hard,

46:54 right?

46:55 It's people skills.

46:57 It's that we've talked about many times. It's the psychological safety. It's EQ.

47:00 That stuff is just crazy, crazy hard to get right.

47:06 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 It's hard to correct when an organization is, I'll use a strong word,

47:17 it might be just wrong, being poisoned,

47:18 right?

47:19 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 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 And this notion of like, if you're a hierarchical team that you clearly are, you believe in.

47:59 top-down command and control.

48:00 Brad: Mm-hmm.

48:03 Scott: And I reject that premise.

48:06 I think your core beliefs override everything.

48:11 And if you have core beliefs that we are a team together,

48:17 that we hold each other accountable,

48:19 that we create psychological safety,

48:21 that we are growth mindset.

48:24 Then those core beliefs transcend

48:28 project organization.

48:33 Brad: Yeah,

48:34 I don't think that's incompatible with what the author said,

48:36 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 And what you're saying is if you don't have if you have other core beliefs like you just enumerated.

48:47 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, 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 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 I know you're trying to come up with.

49:07 Scott: rate,

49:07 subscribe.

49:09 Oh,

49:09 support us on Patreon.

49:11 Support

49:11 Brad: We have

49:12 Scott: us on Patreon.

49:12 Brad: we have our first Patreon supporter,

49:14 don't we? Isn't that true?

49:16 Scott: Paid a paid Patreon supporter.

49:17 It's true.

49:17 Brad: Out of our hundreds and hundreds of listeners,

49:20 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 I set that whole thing up on my phone, by the way.

49:28 I need to tell,

49:30 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 What could go wrong?

49:44 Brad: All right, Brad,

49:45 thanks for your time today.

49:47 This has been fun.

49:47 I can't wait to do this again with you next week.

49:50 And

49:50 Scott: Yeah,

49:51 Brad: we'll talk to you soon.

49:52 Scott: talk to you soon.

49:55 This episode of How Many CTOs Does It Take podcast was edited by Saffron Heptagap.

50:00 Our theme song was AI Generated by Brad.

50:03 Please follow us on all the social media platforms at at HowManyCTOsPod.

50:08 You can find us on YouTube,

50:10 LinkedIn,

50:11 Instagram,

50:11 Facebook,

50:12 Threads, X,

50:13 TikTok,

50:14 and Patreon,

50:15 or at our website at HowManyCTOsPod.com.

50:19 And remember to rate, review,

50:21 and subscribe on the podcast platform of your choice.