The Power of Drafting Implementation Plans: Insights and Strategies
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub discuss the importance of having an implementation plan in software development. They emphasize the role that written plans play in fostering collaboration and scaling projects. Through a candid conversation originally recorded in the summer of 2024, they dive into the nuances of translating business requirements into code, the core competencies required for engineering leaders, and best practices for creating effective implementation plans.
The episode also addresses common challenges engineers face, such as decision paralysis and the reluctance to share early ideas, while offering strategies for overcoming these hurdles. The hosts also share a comprehensive checklist for determining when a written implementation plan is necessary, touching on topics like schema changes, new technologies, and coordination across teams. The importance of a supportive, feedback-rich culture in engineering teams is highlighted as a key factor in successful project execution.
- 00:00 Introduction to the Podcast
- 00:48 The Core Skill in Software Development
- 02:29 Coaching Engineers on Implementation Plans
- 04:06 The Importance of Written Implementation Plans
- 06:02 Challenges and Solutions in Implementation Planning
- 09:57 Creating a Collaborative Culture
- 18:11 Guidelines for Formal Implementation Plans
- 23:09 Conclusion and Call to Action
- 23:34 Outro and Credits
Resources:
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
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.
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.
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
Brad: Mm-hmm.
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
Brad: Yeah, totally.
This is like that's like job one. That's the hardest thing, right?
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
Brad: Mm-hmm, mm-hmm,
Scott: like this funny soft skill which
Brad: mm-hmm.
Scott: I've always thought nobody ever teaches this in any school that
not MBA school not engineering school not anywhere I
Brad: Right.
Scott: mean but yet it's like it's the Rosetta Stone it's like the thing it's
Brad: Yeah.
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
Brad: Totally.
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
Brad: how How
Scott: to get good at that do I
Brad: you coach people into getting good at that?
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.
Brad: Yep.
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
Brad: Yeah.
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
Brad: right,
Scott: are
Brad: right,
Scott: but
Brad: right, it's
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
Brad: yeah
Scott: and
Brad: absolutely
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
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
Scott: Yeah.
Brad: draw a picture and you can give me a picture and I will and I won't understand your picture,
right?
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.
Brad: Totally,
totally.
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
Brad: What
Scott: level you're
Brad: are the next two levels?
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
Brad: Okay,
Scott: way to bark so
Brad: so
Scott: to me that's the coaching i do right there it's like you need write the plan down
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
Scott: Mm
Brad: so let's
Scott: -hmm.
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.
I need to go do a proof of concept.
I need to.
Those are your kinesthetics.
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
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,
Scott: right
Brad: right?
Scott: right
Brad: Oh,
Scott: right
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.
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
Brad: Yeah,
Scott: because
Brad: right.
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
Brad: Right. And I
Scott: much time that'll take or whatever
Brad: also think that.
there's versions of that that you can then go have the conversation with other experts like Oh, even the
Scott: yeah.
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.
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?
Brad: Right.
Scott: Boy,
that's
Brad: Well,
Scott: uncomfortable.
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
Scott: I
Brad: what
Scott: do not recall.
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.
Scott: Ooh.
So that's
Brad: nice.
Right.
Scott: Not bell-worthy.
Brad: Right.
Scott: Not bell-worthy.
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.
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.
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.
Scott: Well,
I mean, this is an interesting,
now this is, everyone is going to have an opinion.
Brad: Right.
Scott: What's the problem with that?
Brad: Exactly. Well,
there you go.
I
Scott: I
Brad: think that
Scott: guess the
Brad: if
Scott: problem,
the problem is, right,
Brad: you allow decision paralysis to kick in, that's a problem, right?
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.
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
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
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
Brad: Right.
Scott: i'm trying to help you not make a mistake that's
Brad: Right. Right. Right.
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
Brad: Mm-hmm.
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
Brad: That helps
Scott: I
Brad: soften it?
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
Brad: Well, and I think
Scott: at this job.
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.
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.
Brad: Right.
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
Brad: and Yeah,
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
Brad: I think it's
Scott: could write I want to write a book on it
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.
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
Brad: Right.
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
Brad: But
Scott: What?
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.
Scott: Yeah,
Brad: Just write
Scott: that's
Brad: it down.
Scott: fine.
That's
Brad: It's
Scott: totally
Brad: like less
Scott: fine.
Brad: than two sentences.
It's simple.
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?
Brad: If so, then write it down.
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
Brad: Yeah, right.
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
Brad: Only
Scott: much
Brad: one.
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?
Brad: That never happens.
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?
Brad: Yeah.
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,
Brad: Yeah.
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
Brad: Yeah.
Scott: classic, we're going to kill two birds with one stone with this thing.
Brad: Yep.
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
Brad: Yeah.
Scott: they were about kind of what's the risk of this thing do
Brad: Yeah, totally.
Totally.
Totally.
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.
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.