0:00 Scott Well, the benefits of having a written implantation plan up front. I think it's a tool for two things. It's a tool for collaboration and it's a tool for scaling.
0:23 Brad Welcome to another episode of How Many CTOs Does It Take podcast? My name is Brad Hefta-Gaub, and this is my co-host Scott Porad.
0:31 Scott When Brad and I were first toying around with the idea of recording a podcast, we would just hop on the phone and record our conversations. Today's episode is one of those conversations, all the way back from the summer of 2024. Enjoy! There's this one part of this kind of job, meaning the job of building software, which
0:54 Brad Mm-hmm.
0:54 Scott is I need to take a business thing that somebody wants and when I say business I use that word really fuzzy I need to take an experience or capability or functionality that someone that someone wants from me and I need to turn that into code and
1:15 Brad Yeah, totally. This is like that's like job one. That's the hardest thing, right?
1:19 Scott and well I've always thought the people who are good at and usually that means okay they're saying they want this So I need to go change these places in this way. And I've always thought the people who are actually good at that little part, that little translation part, that that was like the core soft talent for something, for being able to kind of lead groups of people. There are people who are. better at understanding the technology and what it can do and how it works and how we could leverage it and things like that and there are people maybe who are better at understanding well what does you know what is really the right solution to this problem but the being able to plug those two together and say here's how we could make that happen is
2:11 Brad Mm-hmm, mm-hmm,
2:12 Scott like this funny soft skill which
2:14 Brad mm-hmm.
2:14 Scott I've always thought nobody ever teaches this in any school that not MBA school not engineering school not anywhere I
2:20 Brad Right.
2:20 Scott mean but yet it's like it's the Rosetta Stone it's like the thing it's
2:26 Brad Yeah.
2:26 Scott like the thing we need in order to make it happen and I've often coached you know engineers I was like look that's what you want to get really good at because once you're at that point then like you've got all sorts of choices in your career right
2:40 Brad Totally.
2:41 Scott you want you want to go be a manager you want to be an architect you want to be a product manager like you can go all different directions once you figure out
2:47 Brad how How
2:48 Scott to get good at that do I
2:48 Brad you coach people into getting good at that?
2:54 Scott say this Good question. I have a phrase, I say, look, it starts with what I call an implementation plan. Some people call it a design doc, a technical design doc, a tech spec. I like the phrase implementation plan because I say, look, every engineer has an implementation plan when they start at minimum. They have decided what file to open in their editor.
3:21 Brad Yep.
3:22 Scott That might be the only plan they have, which is I'm going to open this thing up and start typing. But to me, I say like, if you can write down your plan of like, this is the plan for turning, you know, so and so wants it so that. cancellations can be automated so
3:42 Brad Yeah.
3:43 Scott we don't have to have a right now a human and our customer service team has to approve every cancellation and we want it to just be automatic if it meets certain criteria we want it to be automatic the ability to do that is one thing what i think that the piece i coach is can you write down for somebody else how to do that and It starts, I think there's two very coarse skills that I advise. One is just write it down at the bullet point level. You don't have to write down lines of code. Okay, you're going to have to go into the cancellation controller and like catch this event. And when you catch it, then that's bullet point one. And then bullet point two is once you catch it, then... put a message on the queue or Right, I don't know what the things
4:29 Brad right,
4:29 Scott are
4:29 Brad right,
4:30 Scott but
4:30 Brad right, it's
4:30 Scott can you just in sort of like plain English write down the things that someone will have to do and then a companion to that is there is a flow of the system right now there's a flow chart can you can you draw the flow chart of how it is now imagine just doing this in the whiteboard here's the flow chart of how it is now in one color imagine on the whiteboard and then use a different color pen to draw how you want it to be right this comes back to the visual versus different types of learners there
5:03 Brad yeah
5:03 Scott and
5:04 Brad absolutely
5:04 Scott like for some people it's better to write it I'm a bullet point guy for some people for some people it's better to draw
5:10 Brad and there's some people like you you can ask them to draw a picture of it and they'll be like i cannot draw I draw a picture of this. I can write it in words, but I can't
5:16 Scott Yeah.
5:16 Brad draw a picture and you can give me a picture and I will and I won't understand your picture, right?
5:21 Scott Right. I do think the bullet points is important because it allows for increasing or decreasing, however you want to say it, levels of abstraction.
5:31 Brad Totally, totally.
5:32 Scott Like at the high level, it's like I need to change the cancellation control. I need to change the user. Okay. I need to do two things. I need to change the user interface. I need to change the cancellation. inflation controller okay then what are the next
5:43 Brad What
5:43 Scott level you're
5:43 Brad are the next two levels?
5:44 Scott and you're basically drilling all the way down to at the bottom of there is i need to write this function it needs to have these characters on these lines of semicolons in these places right i mean you get all the
5:53 Brad Okay,
5:53 Scott way to bark so
5:54 Brad so
5:54 Scott to me that's the coaching i do right there it's like you need write the plan down
5:57 Brad I love it. Okay, now, it's so funny that you just described this and you even called it an invitation plan because literally this week at Stealth Startup, we had a meeting where as an engineering team, we're like, you know, we're seeing this thing where we're not really evaluating people's solutions. solutions until it gets to the coder viewpoint and we should try to front end that a little bit
6:19 Scott Mm
6:19 Brad so let's
6:19 Scott -hmm.
6:19 Brad start doing these implementation plans okay number one yeah but right like every engineer all every time you give them an idea process a culture change it's like yeah but yeah but what about what about this and the what about is but what if i need to investigate it first And so I, I love your, I love your coaching, right? And how do you get people past the, but I don't, I actually don't have an implementation plan or they say that, and I want to go, I want, I want permission to go. And I think, I think those people that react to the, I don't yet have a plan. I need to go. type something.
7:04 Brad I need to go do a proof of concept. I need to. Those are your kinesthetics.
7:10 Scott Sure. That makes sense. And I would say to that person, well, that yet you do that investigation and that's the outcome of the plan. In fact, I would say most times. I would say most, yeah, most, I was going to repeat what I said. Most times people do have to do some investigation. They might be able to say at a top level, like I just said, well, we probably have to change the UI and we'd probably have to change the. cancellation controller but beyond that I need to go spend some time looking through the code to figure out how to do this right so but sometimes it's like I have no idea how we do that
7:45 Brad Well, and I think it could be it could be that like it could be that maybe that's the and essentially what I said to them was the following. You have some idea. It's not fair to say you have no idea like. Hey, it's a full stack application. Do you think this is going to happen in the client part of the code or in the server part of the code,
8:06 Scott right
8:06 Brad right?
8:06 Scott right
8:07 Brad Oh,
8:07 Scott right
8:07 Brad this is in the client part of the code. Okay, right, right. And do you think this is in, you know, the networking layer or do you think it's in the user interface? Oh, yeah, it's actually not in either of those. It's in the business model portion. Okay, whatever.
8:23 Scott and and it's like some AI thing so like you're going to have to go find some AI package to use like
8:31 Brad Yeah,
8:31 Scott because
8:31 Brad right.
8:31 Scott you're not going to write that on your own unless that's what Salesforce is doing but like you're not going to write that on your own so that's like a bullet point which is when there's going to be an AI part and like we don't know what that is yet but you're sort of like starting I think I refer to as you're blocking it out right and then the whole process of how a bill becomes a law how an idea turns into code is you're just refining it more and more and more and that initial part that you just talked about hey it's in the it's in the full stack app and it's in the business layer like that's very very coarse but it gives you you can be a rough idea like well how
9:10 Brad Right. And I
9:11 Scott much time that'll take or whatever
9:13 Brad also think that. there's versions of that that you can then go have the conversation with other experts like Oh, even the
9:24 Scott yeah.
9:24 Brad simplest version of that you're able to start the conversation and the other experts might go and they might say to you no no no no that that piece of business logic that you're talking about that's actually in a microservice that's running back here i can point you to that you know or they might be like Yes, you're totally on the right track. And I remember Janet worked on that, a feature in that like last quarter. So maybe go chat with her. She might have some insights into this.
9:56 Scott Yeah, so now you're pivoting a little bit, but the benefits of having a written implantation plan up front, which is, yeah, it's a tool for collaboration. I think it's a tool for two things. It's a tool for collaboration and it's a tool for scaling because I can write it. And then maybe someone can pick that up and get other people involved with me. I wrote it, but now five of us are going to work on it together and there's something there. And yeah, it avoids that problem you were talking about of the code review being the worst place to talk about, oh, did you know Janet already did this?
10:30 Brad Right.
10:32 Scott Boy, that's
10:33 Brad Well,
10:33 Scott uncomfortable.
10:33 Brad so do you remember, by the way, do you remember this when you and I worked together most recently at. health company, there was a weird unintended consequence of a leveling document that really disrupted this very natural thing that we're saying we want to optimize for. And
10:56 Scott I
10:57 Brad what
10:57 Scott do not recall.
10:57 Brad it so what it was was that in a leveling document that talked about the difference between a junior engineer, an engineer and a senior engineer, it described the idea that senior engineers are able to write implementation plans, design documents, whatever you want to call them, with no critical feedback in them.
11:21 Scott Ooh. So that's
11:27 Brad nice. Right.
11:28 Scott Not bell-worthy.
11:29 Brad Right.
11:29 Scott Not bell-worthy.
11:30 Brad It's not Bellworthy. It's the exact opposite of Bellworthy. And in fact, that created this culture where that meant that folks that wanted to be perceived as senior, they were more cloistered and they would they would scroll themselves away in and try to create and write the perfect implementation before showing it to anybody.
11:54 Scott Yeah, that's a terrible, terrible thing. No, I think a very common pattern I've seen is quite the opposite, where someone puts together an implementation plan that actually has multiple options in it and starts circulating amongst the team saying like, here's some different ways we could do this. I'd like your feedback on this, right? And here's pros and cons I see of each way and I don't quite know what to do, which I think is a much. healthier pattern and frankly shows more seniority than the opposite.
12:23 Brad Totally. I agree with that. But then let's pull on this thread a little bit more, right? The other thing that you hear is, but if I start to circulate my ideas early, then everyone's going to have an opinion. And I'm going to have too many cooks in my kitchen or, you know, whatever the other, you know, you know, everyone's everyone's got opinions and assholes and they all stink, you know, you know, something like that.
12:55 Scott Well, I mean, this is an interesting, now this is, everyone is going to have an opinion.
13:01 Brad Right.
13:01 Scott What's the problem with that?
13:03 Brad Exactly. Well, there you go. I
13:06 Scott I
13:06 Brad think that
13:06 Scott guess the
13:06 Brad if
13:06 Scott problem, the problem is, right,
13:08 Brad you allow decision paralysis to kick in, that's a problem, right?
13:12 Scott where I would say, yeah, if it's not clear who has the decision rights on that, like I've, I've, I've heard all your feedback. And this is what I and I, we have a racy or daisy or rapid or whatever matrix we've got. And I'm the I'm the decider and I've heard it and I've decided and If you don't like it, I guess go talk to my boss or fire me or I don't know what but like to me that would be more of a sign of we don't have a different kind of organizational dysfunction that we don't have clear ownership over those decisions.
13:52 Brad Yeah, that could be. That could be. I also think that there's a natural there there are, you know. What I tend to notice in that scenario is it tends to be the person that is reluctant to share ideas, and then they have any number of excuses for why they're reluctant to share their ideas early. It almost always tends to be a insecurity. on the part of the person that's reluctant to share and that's the that tends to be the root cause and then we have to as leaders we have to understand like where's that you know is that uh is that a justified insecurity you know is there an area that we can uh you know actually help you with your skills so that you can become more confident is it something where you know there's been some sort of other
14:49 Brad thing happen in the culture where you know you were shut out you know or you know like there's you know or or are you just you know possessive and insecure you know
15:02 Scott Well, you can understand in our field because, you know, the idea has come out of your brain and having them criticized can feel like a criticism of my intelligence and my skills. Right. My abilities which should be rough so I can understand that the other side of the coin is, you know, there's maybe coaching we have to do on how do you give feedback saying. hey you're an idiot because you didn't know that janet already built this thing you should have done more research before you put this out there is very different than oh brad i really don't you know i'm pretty sure you don't want to duplicate somebody else's work you would think that isn't a good idea so you must have not known about janet's thing so
15:50 Brad Right.
15:50 Scott i'm trying to help you not make a mistake that's
15:52 Brad Right. Right. Right.
15:53 Scott a that's a cultural thing i there is one thing i've talked about with implementation plans i don't think it addresses this point directly but I do talk about how let's fight with the document not with let's argue with the document not with each other so
16:07 Brad Mm-hmm.
16:08 Scott as opposed to like you have an idea and I have an idea and you tell me your idea and then we argue back and forth over whether it's good or bad I do think sometimes just the fact that it's a piece of paper that I'm giving feedback to a piece I'm not saying to your face well Brad this is a bad idea I'm just I'm put I'm putting it on this piece of paper that
16:27 Brad That helps
16:27 Scott I
16:27 Brad soften it?
16:28 Scott think sometimes a little bit, right? Because, I mean, I'm not a person who feels insecure about those things, but I would think a little bit, it's like, hey, we are here together working on making this piece of paper as good as possible. It's not me here telling you you're a bad person
16:44 Brad Well, and I think
16:45 Scott at this job.
16:45 Brad that, by the way, I think the thing that you just hit on is super important in. All cultures like this is you just got to like create a we mentality You got you got to have like a shared ownership sense of it, you know, like, yeah, we're we're in this together, right? Like if I'm if I'm giving you feedback here, it's not because I'm judging you. It's because we're all in this together and I care about your I care about all of this.
17:12 Scott I try to use the word uplift a lot. I'm trying to help you. I'm trying to uplift what you're doing.
17:17 Brad Right.
17:17 Scott I talk about uplift our team, our technology, our community. Every action we do is a team. should be trying to lift things up
17:24 Brad and Yeah,
17:25 Scott hopefully that helps so I don't know how we got in this implementation plan topic it's one of my favorite topics I
17:32 Brad I think it's
17:33 Scott could write I want to write a book on it
17:35 Brad huge. I'm a big fan of it. And I think that it is so interesting to me. I actually hadn't thought about what should we talk about this week, but of the things that were on my mind, one of them was this notion of. You know, I've seen this in every single team I've ever been a part of where there's some part of the team that just is kind of has a hard time putting down. an implementation plan.
18:03 Scott Yeah, so let me, you know, we have a document here, I'm bringing it up. Where did it go? I started, this is like several companies ago, I started saying, hey, everyone must have a peer reviewed implementation plan, not a manager reviewed, a peer reviewed. and we set some guidelines i'm going to bring up here for whether it needed to be written down or not because
18:28 Brad Right.
18:28 Scott sometimes it could just be turning your neighbor and saying hey brad i'm planning on making cancellations automated and what i'm going to do is just get this event and stick it on the bus and then the cancellation thing will pick it up and is that how does that sound to you and you would be like well that's cool sounds good to me so like that's a that's a review of a verbal and we wrote a checklist i'm trying to find it four we wrote a checklist for whether you should write it down or not and of course I can't find it but um
18:58 Brad But
18:58 Scott What?
18:58 Brad why not write, like, here's what I think is interesting. So where we where where this group just landed this week, and we're just starting it this week, so we'll see how it goes is, you know, in our project tracking software, which happens to be Trello again, we're small team working on working on small stuff. So we use Trello, I'm just like, Just write your, if it's as simple as what you just said, hey, I'm going to hook the cancellation event and add it to the bus, that's great. Write that in the Trello card when you move the Trello card from to do into doing.
19:31 Scott Yeah,
19:31 Brad Just write
19:32 Scott that's
19:32 Brad it down.
19:32 Scott fine. That's
19:33 Brad It's
19:34 Scott totally
19:34 Brad like less
19:34 Scott fine.
19:34 Brad than two sentences. It's simple.
19:37 Scott Yeah, I guess what I would say is we, the checklist was for how formal does the plan need to be? Maybe not when, but how formal. And I'll tell you what was on the list. There are 15 items. I don't, I guess I can go through all of them. We've got time here. Number one, is it a situation where the requirements are unclear or are in flux?
19:56 Brad If so, then write it down.
19:58 Scott You know, it's... you're like you know if you start to check off two or three of these maybe you should write it down right
20:04 Brad Yeah, right.
20:05 Scott um does it touch an area with many use cases or does it touch or change tricky use is i'm sorry is it a change that is across many use cases so like maybe i am changing the message bus for the whole system or is it you know a simple Are you touching a tricky use case, even if there's not
20:28 Brad Only
20:28 Scott much
20:28 Brad one.
20:29 Scott like we were just talking about? I use this cancellation example. That can be really tricky sometimes. This is my favorite one. Is it a user story where reasonable people frequently use the same words to mean different things?
20:44 Brad That never happens.
20:46 Scott No, it never happens, right? Is it a big change, either lots of code or many parts of the system? Is it a change that involves a schema change or a data migration? Does it expand our technology footprint by introducing new technologies or infrastructure or third-party integrations? Does it require cross-team coordination to deliver? Number nine is one of my favorite. Is it a change that is being rushed through urgently?
21:17 Brad Yeah.
21:17 Scott That's almost always you should write it down just because it slows things down. Oh, this is a good one. This is another good one. Is it a change that seems easy because it's, quote, dusting off some old code? It was never committed, but it's just been sitting in a branch. Is it a change that might create hard to see errors? Are there many people dependent on the system or data being changed such that... The requirements could have come to you by telephone game, the classic tire swing thing,
21:48 Brad Yeah.
21:48 Scott which is like, you know, Brad told me that Janet wanted that Eric told Janet that Jill told Eric that we need to change this thing. Let's see, that's number 12. Are there another this actually is a really good one. Are there multiple stakeholders with competing requirements for a single change? The
22:10 Brad Yeah.
22:10 Scott classic, we're going to kill two birds with one stone with this thing.
22:13 Brad Yep.
22:14 Scott Yes, sure you are. Is it a change where you don't know what to do with like peer input? And is it a change that requires clarification in order to be communicated outside the engineering team? I actually don't know what that means. requires clarification in order to be communicated outside of the engineering team i don't know what that means anyway that was the checklist you notice none of those were really about code right
22:43 Brad Yeah.
22:43 Scott they were about kind of what's the risk of this thing do
22:47 Brad Yeah, totally. Totally. Totally.
22:49 Scott we need to collaborate on it i think if i was this is an old document it's got to be 15 years old i think if i was to add anything to that Um, it would have to do with like architecture and patterns like are you introducing a new pattern are you suggesting a change to a pattern um that kind of thing thanks everybody for listening today we hope you got something out of this we sure did please remember to subscribe rate and review smash that subscribe button pound those five stars And leave the most overflowing, positive and glorious review that you have ever left for any podcast ever in the history of time.
23:33 Brad This episode of How Many CTOs Does It Take Podcasts was edited by Saffron Epigal. Our theme song was AI Generated by Brad. Please follow us on all the social media platforms at HowManyCTOsPod. You can find us on YouTube, LinkedIn, Instagram, Facebook, Threads, X, TikTok, and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review, and subscribe on the podcast platform of your choice. Thanks for listening.
