Kermitt Davis
Welcome to Talk Tech with Data Dave. My name is Kermit Davis. I’m sitting here with our own Dave Wilkinson, AKA Data Dave. Hey Dave, how are you doing today?
Data Dave
I’m excellent, Kermit, and great to see you. I see Alexis is taking a break. What do we have today?
Kermitt Davis
Well, we have an incredible question submitted by a listener. We don’t want to pronounce their name wrong, so whenever we post the episode, we’ll make sure to tag them.
This listener’s question is this: What is more critical for success? Tactical depth or a strategic mindset?
Data Dave
That’s a really interesting question. I assume we’re talking about a tech situation or a technical situation or in the tech field.
Kermitt Davis
Yes, most definitely. That is the context.
Data Dave
The comment I would make on that is – the simple answer is “it all depends”.
If you are in a position where technical depth is absolutely required, then clearly technical depth is necessary. So, if you’re writing code that is in-depth, you’re writing some Spark code, or you’re writing some complex structures in whatever format, then technical depth is absolutely necessary. I don’t think it necessarily can be used in lieu of knowing why you are doing it. It always pays, even when I was writing code when I was a junior developer, it is always useful to know why you are doing something.
The strategic intent or the strategic side of it is necessary.
And as you move further forwards, as the scope of problem that you’re solving gets bigger and gets more broad, then probably the strategic intent becomes more important.
Kermitt Davis
All right, I have a follow up regarding that point. Dave. Are you saying that whenever a project is smaller, that the technical depth matters more and then as the project expands in size and grows, that the strategic mindset is more important or is it more complicated than that?
Data Dave
I think it’s more complicated than that. It comes back to more to your role in the project, as well. So, from an individual perspective, if I’m running a team of 100 developers and most of them are writing in depth code, then technical depth is absolutely necessary. For those individuals to be successful doesn’t mean they shouldn’t know why they’re doing something or what the objective of the total team is so that they can answer the question more fully or write code in an improved way. Context of code is incredibly important. When you’re writing code, the context of why you’re writing it is incredibly important because that gives you the background to be able to not write some of the bugs that you might naturally write. So, technical depth is absolutely necessary at that depth. If you are the architect on that project or a strategic leader of that project, then it is up to you to provide that context to those individual developers. And while you do need the technical depth to be able to guide them, you can also rely on their technical depth to solve the problem correctly. If you know what you’re doing and why you’re doing it, there’s a blend of the two. On a big team, you probably need more technical depth across the team and less strategic intent? Yes, but they are both incredibly important. And having somebody with strategic intent, it is easier to add that strategic context to people with the technical depth.
So, there’s kind of this pyramid of knowledge, if you like, where you require the strategic intent at the top of the pyramid. But the bottom of the pyramid can be more technical depth. And as you mature in the project team and get more experience and start to lead other people, then you as an individual, move up that pyramid.
Kermitt Davis
I see.
So, regarding the different roles. So, for example, as you said, a developer would be much more focused on technical depth. Let’s say a program manager – they’d be much more focused on strategic mindset, at least in theory. What is more important? For the development team to have a strategic mindset or the program managers to have more technical depth? How do you balance that within a team? Even if the roles in theory are in their separate domains, the best way?
Data Dave
To balance it, I think, is context. Right? So, it becomes the context of the team.
We’ve seen a number of projects go off the rails because there is too much technical depth, and they forgot what they were doing or why they were doing it.
Kermitt Davis
Very common.
Data Dave
And so you solve a problem and you solve it in a way, but you lost sight of the problem as you solved the problem, so you solved the wrong problem. That is probably the most expensive mistake.
Kermitt Davis
Yes.
Data Dave
Right. You solved the wrong problem in a very technically elegant way, but you solved the wrong problem. That’s super expensive. If you get the problem right, but solve it in a more expensive way, that is a less elegant way. That is far more recoverable than solving the wrong problem in a super elegant way.
Kermitt Davis
Yes.
Data Dave
So you could argue that on a project team, having a good, clear, understood set of requirements and not just a set of requirements in terms of, “What are you going to do? What problem are you going to solve?” but also in terms of, “Why are you solving it?” Because context is very important. You want to give your developers and your technical team scope to be creative.
Kermitt Davis
Yes.
Data Dave
So, I don’t want to tell you as a developer that you will do exactly this, and I’m giving you the technical depth. What I want you to do is be able to say to you, “I want you to solve this problem, and here’s the context of why we’re solving it. Go be creative. Go be you. Give me a solution that is unique. Give me a solution that you believe is elegant.” Give you something that gives you scope to be creative and scope to write.
Kermitt Davis
Yes.
Data Dave
That to me is the most important thing. When I was a developer, when I was growing up as a development manager, one of the biggest questions was developers would ask, “What is the requirements, what requirement is this?” And the answer would always be more and more detail.
Until, then the developer got upset. You’re now telling me what I need to write, and we’re forcing the technical depth into the product owner or into the requirements manager, analyst, or whatever. And that caused a tremendous amount of friction. The way we solved that in that situation was, actually, I pushed the analysts and the requirements people to, instead of answering exactly what, answer why?
So, when somebody says, “I need greater requirement,” don’t tell me exactly what you want me to write, tell me why you want me to write something.
Kermitt Davis
Yes.
Data Dave
And then give the developer scope to use their technical depth, use the skills that they have to solve the problem in an interesting and elegant way, and then bring it all back together. And that gives a much better picture of the whole structure than saying exactly what you want me to write Or exactly what problem you want me to solve. Or exactly how you want me to solve this problem. Give the developers that context and give them the scope to be creative.
Kermitt Davis
Definitely. I’ve encountered that a few times where it’s very possible for subcomponents of any project to, I don’t want to say over-determined, but maybe overfitted, where there’s not enough room for developer creativity, like you said.
And so, you’re saying that, as opposed to saying how exactly it needs to be done, it’s much more of a why it needs to be done and what needs to be done. The steps for the subcomponent of the project, it’s not that they don’t matter. It’s just not the critical piece of any project.
Data Dave
Right. It’s more the- If I ask you to do something you’re not going to get, “I want you to write 17 lines of code that do this exactly or it’s not right for me.” I will give you. “This is what we’re trying to accomplish. This is the scope of why we’re trying to accomplish, and this is the component that I want you to write, and I want you to think creatively and come up with something that I haven’t thought of.” Because, yeah, I might solve it one way. You’ve got a totally different decision context to me.
Kermitt Davis
Absolutely.
Data Dave
You might solve it in a very different way, which is actually way better. Another example that I use is – I’m not interested in what I can invent anymore. My inventing days are over. I’m not interested. I’m really interested in what are you going to invent? Because you have a much better decision context or decision framework for the modern world than I do. You’re younger than I am.
Kermitt Davis
Yeah.
Data Dave
I want to see what you’re going to invent. Given that you grew up with iPads and different things, you didn’t grow up with slide rules.
Kermitt Davis
No. I don’t even know what that is, Dave.
Data Dave
So I invent based off of a framework of, “I grew up with a slide rule. What can I do?” And yet you grew up with iPads and iPhones and different things like that. What are you going to invent? That’s a totally different context.
Kermitt Davis
Definitely.
Data Dave
I want to give you scope to invent and scope to be creative within the framework of the problem that we are trying to solve.
Kermitt Davis
Yes, absolutely. And so it seems like a common failure mode for what you’re saying is that members of a team or on a project who are more focused or should be more focused on the overall strategy, the overall strategic mindset, they try to get in the weeds technically, and let’s say over prescribe or over describe how exactly a developer should solve a problem.
Data Dave
Exactly. And what it really comes down to is people on the project need to do the role that needs to be done.
Kermitt Davis
Yes, definitely.
Data Dave
And often, the senior people in the project came from a technical background. So, you find your architects have a technical background. They came from that space. They used to be engineers. So, their comfort zone is technical depth. So, they will go back to their comfort zone when they are a little bit pushed. And what they’ve got to do is remember that they actually want to be outside their comfort zone, and they want to be getting into that why question and how question rather than the exactly how or the exactly what? Leave that for the people that are doing that role, and let those people be creative. Doesn’t mean you can’t help, doesn’t mean you can’t give guidance, doesn’t mean you can’t jump in when you have to. But the point here is, if you’re a leader, then lead with why and what and let the people have creative scope to solve the problem in an interesting way with the technical skills that they have.
Kermitt Davis
Yes, definitely.
Data Dave
The technical landscape is always shifting. And so, if it’s not my job to stay up to date with the exact shifting of the technical landscape, then leave the technical depth to the people that do live there.
I know what should be possible, what can be possible based off of my experience growing up in the field, but I might not know the depth of exactly what is available today versus what was available yesterday. My solution is going to be flawed based off of my decision context. Your solution might be far more creative based off of your technical depth.
Kermitt Davis
Definitely. And so from everything you said, it seems like it’s not so much a question of what’s more critical for success, technical depth or strategic mindset, but that the strategic mindset, it has to be prioritized at the beginning of the project that is in a way the foundation to decide where you and your team are going to go and where you want to go.
Data Dave
I think that’s an excellent point. I would suggest that we finish on exactly that, which is – it isn’t a question of “Is it more important to have technical depth or strategic intent or strategic mindset?” The success is bred from having the right blend of both.
Kermitt Davis
Awesome.
Well, Data Dave, thank you so much for your time. Before we go, I promised Alexis I’d remind our listeners to send up your questions by emailing us at talktech@d3clarity.com. Data Dave loves answering listener questions, even my questions, on the podcast.
This was great, Dave. I’m happy I could join you today.
Data Dave
Thank you very much Kermit, and glad to see you.
Kermitt Davis
Great to see you.
