Transcript: The Power of Drafting Implementation Plans: Insights and Strategies
0:00 Scott Well, the benefits of having a written implantation plan up front.
0:02 Scott 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?
0:27 Brad 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,
0:36 Scott we would just hop on the phone and record our conversations.
0:40 Scott Today's episode is one of those conversations,
0:43 Scott all the way back from the summer of 2024.
0:46 Scott Enjoy!
0:48 Scott There's this one part of this kind of job, meaning the job of building software,
0:54 Scott which
0:54 Brad Mm-hmm.
0:54 Scott is I need to take a
1:01 Scott 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.
1:16 Brad 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
1:26 Scott So I need to go change these places in this way.
1:31 Scott And I've always thought the people who are actually good at that little part,
1:36 Scott that little translation part,
1:39 Scott that that was like the core soft talent for something,
1:47 Scott for being able to kind of lead groups of people. There are people who are.
1:51 Scott 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
2:17 Scott 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
2:36 Scott 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
2:55 Scott Good question.
2:57 Scott I have a phrase, I say, look,
2:59 Scott it starts with what I call an implementation plan.
3:02 Scott Some people call it a design doc,
3:04 Scott a technical design doc,
3:06 Scott a tech spec.
3:06 Scott I like the phrase implementation plan because I say, look,
3:10 Scott every engineer has an implementation plan when they start at minimum.
3:17 Scott 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,
3:24 Scott which is I'm going to open this thing up and start typing.
3:28 Scott But to me, I say like, if you can write down your plan of like, this is the plan for turning,
3:36 Scott you know, so and so wants it so that.
3:40 Scott 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
4:06 Scott It starts, I think there's two very coarse skills that I advise.
4:11 Scott One is just write it down at the bullet point level.
4:15 Scott 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.
4:22 Scott And when you catch it, then that's bullet point one. And then bullet point two is once you catch it,
4:26 Scott then...
4:27 Scott 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
4:48 Scott 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
5:14 Brad I draw a picture of this.
5:15 Brad 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,
5:21 Brad right?
5:21 Scott Right.
5:22 Scott 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,
5:31 Brad totally.
5:32 Scott Like at the high level,
5:33 Scott it's like I need to change the cancellation control.
5:36 Scott I need to change the user.
5:37 Scott Okay.
5:37 Scott I need to do two things. I need to change the user interface. I need to change the cancellation.
5:40 Scott 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
5:48 Scott 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,
5:58 Brad 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,
6:10 Brad we're seeing this thing where we're not really evaluating people's solutions.
6:15 Brad 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
6:39 Brad And so I, I love your, I love your coaching,
6:42 Brad right?
6:44 Brad 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,
6:53 Brad I want, I want permission to go.
6:56 Brad And I think, I think those people that react to the,
7:00 Brad I don't yet have a plan.
7:02 Brad I need to go.
7:04 Brad type something.
7:04 Brad I need to go do a proof of concept.
7:06 Brad I need to.
7:08 Brad Those are your kinesthetics.
7:10 Scott Sure. That makes sense.
7:11 Scott And I would say to that person,
7:13 Scott well,
7:14 Scott that yet you do that investigation and that's the outcome of the plan.
7:18 Scott In fact, I would say most times.
7:21 Scott I would say most, yeah, most, I was going to repeat what I said.
7:25 Scott Most times people do have to do some investigation.
7:27 Scott They might be able to say at a top level, like I just said,
7:30 Scott well,
7:30 Scott we probably have to change the UI and we'd probably have to change the.
7:34 Scott 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,
7:45 Brad 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.
7:55 Brad You have some idea.
7:57 Brad It's not fair to say you have no idea like.
8:00 Brad Hey,
8:01 Brad it's a full stack application.
8:02 Brad 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.
8:09 Brad Okay,
8:09 Brad right,
8:09 Brad right. And do you think this is in, you know, the networking layer or do you think it's in the user interface?
8:17 Brad Oh,
8:18 Brad yeah,
8:18 Brad it's actually not in either of those.
8:20 Brad It's in the business model portion.
8:22 Brad Okay,
8:22 Brad whatever.
8:23 Scott and and it's like some AI thing so like
8:27 Scott 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
8:50 Scott 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.
9:17 Brad 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
9:42 Brad Yes, you're totally on the right track. And I remember Janet worked on that, a feature in that like last quarter.
9:52 Brad So maybe go chat with her. She might have some insights into this.
9:56 Scott Yeah,
9:57 Scott so now you're pivoting a little bit, but the benefits of having a written implantation plan up front,
10:02 Scott which is, yeah, it's a tool for collaboration.
10:08 Scott 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.
10:14 Scott And then maybe someone can pick that up and get other people involved with me.
10:17 Scott I wrote it, but now five of us are going to work on it together and there's something there.
10:23 Scott And yeah,
10:23 Scott it avoids that problem you were talking about of the code review being the worst place to talk about, oh,
10:28 Scott did you know Janet already did this?
10:30 Brad Right.
10:32 Scott Boy,
10:33 Scott 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.
10:40 Brad health company,
10:40 Brad 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.
10:56 Brad 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,
11:06 Brad an engineer and a senior engineer,
11:08 Brad it described the idea that senior engineers are able to write implementation plans,
11:15 Brad design documents,
11:16 Brad whatever you want to call them, with no critical feedback in them.
11:21 Scott Ooh.
11:25 Scott So that's
11:27 Brad nice.
11:28 Brad Right.
11:28 Scott Not bell-worthy.
11:29 Brad Right.
11:29 Scott Not bell-worthy.
11:30 Brad It's not Bellworthy.
11:31 Brad 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,
11:39 Brad 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,
11:55 Scott terrible thing.
11:55 Scott No,
11:56 Scott 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,
12:05 Scott here's some different ways we could do this.
12:08 Scott I'd like your feedback on this,
12:11 Scott right?
12:12 Scott 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.
12:18 Scott 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,
12:32 Brad but if I start to circulate my ideas early,
12:36 Brad then everyone's going to have an opinion.
12:41 Brad And I'm going to have too many cooks in my kitchen or, you know, whatever the other,
12:46 Brad 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,
12:56 Scott I mean, this is an interesting,
12:58 Scott 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,
13:04 Brad there you go.
13:06 Brad I
13:06 Scott I
13:06 Brad think that
13:06 Scott guess the
13:06 Brad if
13:06 Scott problem,
13:07 Scott 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,
13:13 Scott if it's not clear who has the decision rights on that,
13:16 Scott like I've, I've, I've heard all your feedback.
13:20 Scott And this is what I and I, we have a racy or daisy or rapid or whatever matrix we've got.
13:26 Scott And I'm the I'm the decider and I've heard it and I've decided and
13:33 Scott 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.
13:53 Brad That could be. I also think that there's a natural there there are, you know.
13:59 Brad What I tend to notice in that scenario is it
14:06 Brad tends to be the person that is reluctant to share ideas,
14:10 Brad 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.
14:23 Brad 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.
15:14 Scott Right.
15:17 Scott My abilities which should be rough so I can understand that the other side of the coin is,
15:22 Scott you know, there's maybe coaching we have to do on how do you give feedback saying.
15:29 Scott 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
15:46 Scott 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
15:58 Scott 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
16:25 Scott 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?
16:33 Scott 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.
16:41 Scott 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.
16:51 Brad All cultures like this is you just got to like create a we mentality
16:56 Brad You got you got to have like a shared ownership sense of it, you know, like, yeah, we're we're in this together,
17:01 Brad right?
17:02 Brad Like if I'm if I'm giving you feedback here,
17:05 Brad it's not because I'm judging you.
17:07 Brad 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.
17:20 Scott Every action we do is a team.
17:22 Scott 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.
17:36 Brad I'm a big fan of it.
17:37 Brad And I think that it is so interesting to me.
17:39 Brad 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.
17:47 Brad 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.
18:02 Brad an implementation plan.
18:03 Scott Yeah, so let me, you know, we have a document here, I'm bringing it up.
18:08 Scott Where did it go?
18:10 Scott I started, this is like several companies ago,
18:13 Scott I started saying,
18:14 Scott hey,
18:15 Scott everyone must have a peer reviewed implementation plan,
18:19 Scott not a manager reviewed,
18:20 Scott a peer reviewed.
18:22 Scott 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
18:47 Scott 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.
19:01 Brad 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,
19:11 Brad which happens to be Trello again,
19:12 Brad we're small team working on working on small stuff.
19:15 Brad So we use Trello, I'm just like,
19:19 Brad 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,
19:25 Brad that's great.
19:27 Brad 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.
19:33 Scott 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.
19:36 Brad It's simple.
19:37 Scott Yeah,
19:38 Scott 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.
19:44 Scott And I'll tell you what was on the list. There are 15 items.
19:46 Scott I don't, I guess I can go through all of them. We've got time here.
19:50 Scott 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,
19:59 Scott it's...
19:59 Scott 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
20:24 Scott Are you touching a tricky use case,
20:27 Scott 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.
20:30 Scott That can be really tricky sometimes.
20:33 Scott This is my favorite one.
20:35 Scott 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,
20:47 Scott right?
20:49 Scott Is it a big change, either lots of code or many parts of the system?
20:53 Scott Is it a change that involves a schema change or a data migration?
20:59 Scott Does it expand our technology footprint by introducing new technologies or infrastructure or third-party integrations?
21:05 Scott Does it require cross-team coordination to deliver?
21:10 Scott Number nine is one of my favorite.
21:12 Scott 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.
21:23 Scott Oh, this is a good one.
21:24 Scott This is another good one.
21:25 Scott Is it a change that seems easy because it's, quote,
21:27 Scott dusting off some old code?
21:31 Scott It was never committed,
21:32 Scott but it's just been sitting in a branch.
21:35 Scott Is it a change that might create hard to see errors?
21:37 Scott Are there many people dependent on the system or data being changed such that...
21:43 Scott The requirements could have come to you by telephone game,
21:46 Scott the classic tire swing thing,
21:48 Brad Yeah.
21:48 Scott which is like,
21:49 Scott you know, Brad told me that Janet wanted that Eric told Janet that Jill told Eric that we need to change this thing.
21:59 Scott Let's see, that's number 12.
22:01 Scott Are there another this actually is a really good one.
22:04 Scott Are there multiple stakeholders with competing requirements for a single change?
22:10 Scott 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.
22:17 Scott Is it a change where you don't know what to do with like peer input?
22:22 Scott 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.
22:31 Scott 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.
22:48 Brad Totally.
22:49 Brad 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
22:58 Scott Um,
22:58 Scott 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
23:22 Scott And leave the most overflowing,
23:24 Scott 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.
23:38 Brad Our theme song was AI Generated by Brad.
23:41 Brad Please follow us on all the social media platforms at HowManyCTOsPod. You can find us on YouTube,
23:49 Brad LinkedIn,
23:49 Brad Instagram,
23:50 Brad Facebook,
23:50 Brad Threads, X,
23:51 Brad TikTok,
23:52 Brad and Patreon,
23:53 Brad or at our website at HowManyCTOsPod.com.
23:57 Brad And remember to rate, review,
24:00 Brad and subscribe on the podcast platform of your choice. Thanks for listening.