Hey everyone, and welcome to today's episode of Developer Tea.
My name is Jonathan Cottrell and my goal on the show is to help driven developers like you find clarity, perspective and purpose in their careers.
In today's episode, I want to discuss something that makes the greatest of the great, that sets them apart, something that you'll find consistent in every top-level athlete, in every top-level thinker writer.
And you'll find, in kind of a backwards way, that the most kind of talented engineers that you've encountered probably do this as well.
And the simple idea is deliberate practice.
You've heard about deliberate practice before, probably either on this show or in a book or in a blog post.
And a lot of the time we imagine deliberate practice to just be the same thing as practice.
In other words, repetition.
We're missing the boat if all we're imagining deliberate practice to be is practice and we're proxying that to repetition, to experience, to something as simple as doing the thing over and over.
And while doing the thing over and over certainly will give you more intuitive understanding of how things respond.
It's not the same as deliberate practice.
So first I'm going to talk about what the differentiation is, and then I want to kind of help you connect the dots for how you can think about deliberate practice, which is actually kind of the harder part.
How do you incorporate deliberate practice into your career as an engineer or as an engineering manager?
That can be the hard part.
All right, so let's differentiate.
Deliberate practice is indeed partially repetition, right?
That's part of it.
You will get your repetitions as a part of your practice.
But deliberate practice is specifically talking about doing a very narrow set of activities or participating in a narrow you know a narrow specific thing, right?
So if you let's say, for example, we're talking about basketball, deliberate practice might be free throws, right.
And you're doing that narrow activity that you want to improve at.
And, very importantly, you get very quick feedback, very close to the repetition, so that you can incorporate it and then get more feedback again.
Right?
And so ideally, the cycle time between these repetitions is low.
The feedback is either automated or The feedback could come from some system measurement.
For example, free throws, one piece of feedback is whether or not the ball went in.
But you could also have feedback coming from another person, someone else who has experience or who has enough training, enough understanding of the subject matter to be able to point out areas where you can improve.
The deliberate aspect of this is that you're intentionally engaging in this activity specifically to practice.
You're not getting practice by way of the activity.
You are engaging in the activity, at least with the understanding that you're doing it in part, to practice.
That is the deliberate aspect of deliberate practice.
So that's the difference between that and just the average practice, going and doing the thing.
Deliberate practice is stepping into a specific environment, an environment that you create maybe.
You can imagine, this is a mental environment and intentionally engaging in some activity in order to improve at it.
Or at least that is a priority they're engaging in.
And the reason why there's an important difference here is because deliberate practice is much more effective at rapid improvement than just practice, just repetition.
Okay, so how do we actually do this in engineering?
How can you engage in deliberate practice as an engineer, as a tech lead, as a manager, as a product manager?
There are some obvious ways, right?
Of course, you can engage in deliberate practice through things like leak code.
Whether that is valuable or not kind of depends on your personal career aspirations and who you're talking to, what kind of job you want, what kind of interviewing process you're going to have to go through.
Possibly the kind of work that you're doing may benefit from certain kinds of algorithmic thinking, for example.
The vast majority of people listening to the show right now are not going to benefit from LeetCode.
So adopting that as deliberate practice might be more trouble than it's worth.
So what should you adopt?
What are other things that you can practice deliberately at?
There's a lot of options here.
I want to talk specifically about aspects of your engineering career that will move you towards a leadership mindset or a leadership role, right.
You can be a leader and be an engineer at the same time.
You can be a leader and be, you know, an IC simultaneously.
You can be a manager and do these same things, right?
So I'm going to give you some ideas for deliberate practice as a leader, because I think these are the harder ones.
And you can kind of fill in the blanks for some of the more hard science or directly engineering-related tasks that you may engage in deliberate practice.
As an engineering manager or as a tech lead, engaging in deliberate practice is a little bit harder.
It's harder to understand how to do that.
What kinds of activities would you engage in?
And how do you do it in a repetition type manner?
One important shift mindset shift that you can undertake, that you can make, is to begin looking at your opportunities differently in your job, as opportunities for practice.
Now I know this kind of blurs the line a little bit from the definition we just talked about, right?
We just said the delivery practice, you're intentionally doing the thing in order to practice.
I believe that you can.
This is a little bit of a gradient or it's kind of a both situation where, for example, you can practice improving at one-on-ones Every week in your one-on-ones.
You can improve your feedback style in your one-on-ones.
You can improve your communication style in your one-on-ones.
How do you do that?
You engage in a specific aspect that you want to improve in.
You want to improve at providing feedback, provide more feedback in your one-on-ones and then ask the person that you just provided feedback to about that specific aspect.
Maybe you're trying to increase the clarity of constructive criticism.
I imagine I'm ringing a lot of bells here.
If you're a manager that struggles with providing constructive criticism in a way that it can be heard, this might be a good area for you to engage in deliberate practice.
Provide constructive criticism three or four weeks in a row to the same person.
Now, of course hopefully, you're listening to this and your intuition is triggering you to say well, doesn't this change the environment?
Are you just practicing on your reports?
The answer is kind of yes.
But if you're not practicing at all, then the alternative here is that report doesn't get constructive feedback at all.
Or they're getting constructive feedback that you're not necessarily trying to improve on.
So there are some important things to keep in mind when you are engaging this kind of practice.
A couple of them include how you get that feedback, right?
Who you are choosing to provide this feedback to.
And this goes beyond just providing constructive criticism.
There may be a communication of technical concepts to non-technical people, for example.
This might be an area that you want to improve in is a very important thing for senior engineers and managers to be able to do.
How do you communicate a complicated technical problem to a non-technical contributor, non-technical manager, right?
You have an opportunity to do this.
You have an opportunity to do this through writing.
You could record a video.
Here's the reality.
You may be saying, well, why would I do that?
What is useful about that?
And you're going to record a video about how, let's say, you run a backend service and you wanna record a video to communicate what does this service do and how do you interact with it.
So you might go over authorization and authentication.
You might talk about what kinds of data are in the endpoints.
What environments does this thing run in?
There's a bunch of things you could go over, sure.
So you say, okay, well, why would I do that?
What is the usefulness of a video like that?
The first and foremost useful aspect of this is that it is practice.
Remember, the goal of deliberate practice starts with practice.
But I'll add on to this that you may find you almost certainly will find that if you engage in these deliberate practice activities, that you're going to create more value than you realize by just engaging in those activities.
If you go and create documentation that didn't exist before, if you begin to communicate feedback to your team in ways that they haven't received before, you are now generating novel value.
Now, you may say, well, I don't really know if I'm good enough at that.
What if I'm not generating value?
What if I'm actually hurting something?
The vast majority of the time when managers engage in these behaviors, if they aren't generating value, it's usually a net neutral.
In other words, you create the video and it doesn't catch on.
Nobody really cares.
And so it goes by the wayside.
It gets forgotten.
It gets archived.
Nobody ever looks at it. but you got the practice in.
So the goal of the video still was met.
It is very rare for you to create something like this.
Create documentation or video and it have a net negative effect, right?
In other words, it's gonna hurt something.
So at the very least, you've accomplished your deliberate practice and you've probably added value in your role.
And this is probably novel value.
My guess is, if you were to poll the other managers, your peer managers, about whether or not they've done something like this, if they are deliberately practicing by creating these things or by engaging with their team in these particular ways, I would venture to say the vast majority have not.
Because this isn't an intuitive thing to do, to practice in this manner.
It's not necessarily intuitive.
The kind of novelty of this is that you are applying this behavior of deliberate practice to a field that is difficult to get practice in.
As a manager or as a tech lead.
The vast majority of very senior managers and tech leads got there through time repetitions, right through, in other words, they've just been doing it for a long time and so they've had a lot of opportunities kind of handed to them.
The real change here is that you're going to go and find opportunities.
You're going to go and create opportunities to practice these skills, to get better at communication, to get better at, you know, distilling complex ideas, to get better at understanding strategy.
There's one other way that you could engage in this, because there's another category here of work that doesn't really function in the same way.
And that is the kind of the strategy or the kind of decision making category.
How do you practice that?
You can't really just make up opportunities to make decisions.
What you can do is go back and look at previous decisions that have been made.
You can either look at previous decisions made by you and your team and create rationale for those decisions.
You can go look at decisions made by other teams in your org.
Especially if there are decision briefs.
You could even cut off just the intro and only read the intro and the context and then go and practice by making your own decision and then comparing it to the decision that that team made.
So really what you're doing is kind of backwards training.
You're looking at what has happened in the past.
You can do the same thing with things like forecasting timelines.
You could look at the scope of work and, instead of figuring out, instead of starting with the knowledge of how long it took, try to forecast, try to estimate how long that work actually took.
Over time, you'll begin to calibrate against reality.
This is particularly useful within the context of a team, especially if that team has been kind of formed for a long time.
What is the capacity of that team?
You could start to get an intuition for that.
You could get deliberate practice by looking at past work that they've delivered.
Hopefully this concept of deliberate practice has you thinking about ways that you can engage in deliberate practice.
There's other things that I've done myself.
For example, I've engaged in deliberate practice by having conversations with LLMs about, let's say, sensitive topics, and I'll prime the LLM.
To model really sensitive or difficult topics.
I've engaged in deliberate practice of receiving really harsh feedback and trying to figure out a way to parse through that feedback.
There's a lot of opportunity.
Because a lot of our jobs as engineers and as engineering leaders hinges on language and it hinges on how we interact and communicate.
There are a lot of opportunities to engage in deliberate practice through or with the assistance of an LLM.
So I'd encourage you to do some thinking around this about how that might apply to you.
Thank you so much for listening to today's episode of Developer Tea.
If you enjoyed this episode, then subscribe in whatever podcasting app you use right now.
Or you can subscribe on YouTube.
This episode and the last, I don't know.
Something like 10 episodes are on the Developer Tea YouTube channel.
And you can join the Developer Tea Discord community at developertea.com slash discord.
Thanks so much for listening.
And until next time, enjoy your tea.
