Welcome to today's episode.
My name is Jonathan Cottrell.
You're listening to Developer Tea.
My goal on the show is to help driven developers like you find clarity, perspective and purpose in their careers.
And in today's episode, I'm going to give you what may feel like hard truths about your career growth.
So many engineers that I've talked to have fallen into these traps of overthinking and of trying to find optimizations, trying to find pathways of becoming slightly more 5, 10 more productive, trying to play various games of politics and networking.
And in this episode I don't want to say that those things are useless or unimportant, but instead I want to help you focus on the things that will really make the big differences in your career.
These are the big engines.
These are the lead dominoes, the primaries, right?
The primary considerations, the principal components of your career building strategy, right?
This is a departure from nuance.
And the people that this is really targeted at are the people who have had performance conversations with your manager, where you try to convince your manager that the work that you do is valuable.
Where you try to kind of connect the dots and explain why, for example, your throughput is lower than your peers, but that actually the value you produce is equal or better.
These arguments that you have probably had at this point in your career, or maybe you're around the corner from them.
They are arguments based on nuance.
And so often they're based on this idea that you can create a story that makes sense as to why your work is, Why you're a high-performing engineer.
And while you may not necessarily be wrong, your career is going to suffer if you're in this position.
Your career is not going to grow as easily.
It's not a good strategy.
If I was coaching you directly, if you were my report, I would focus on strategies that I know work.
There's a lot of things that you could go and do that might work.
There's a lot of things that you may be able to implement that could work.
A good example of this that I've experienced in my own life is in the medical industry.
Sometimes somebody might receive a diagnosis.
For example, at my age, you know, men like me may receive a diagnosis of like a low testosterone score.
This is a good example, right?
And there are a variety of factors that might help improve your testosterone.
And in fact, the doctor may come to you and say, you need to try these things first, right?
They may say, Well, we need to make sure your sleep quality is good.
And that's a contributing factor, major contributing factor.
We need to make sure that you're active, that you're getting exercise, major contributing factor.
Especially for this, you need to lift weights.
Okay, great.
Major contributing factor, right?
We need to make sure your nutrition is solid.
We need to make sure that your body composition is good, right?
Now, let's imagine that All of these kind of fundamental things are handled.
Now, you have a variety of treatment pathways that could help improve your testosterone.
And there's a bunch of kind of, you know, fiddling and experimenting that you could do.
There's a lot of nuance in all of these treatment pathways.
And then there's the kind of gold standard primary path, the principal path.
For someone who actually has low testosterone, the principal path of treatment tends to be DRT testosterone replacement therapy.
Now, why am I talking about testosterone on this show?
This is not a fitness show.
This is not something that necessarily has a direct correlation.
Well, it's a good allegory for what may be wrong in your career.
Not that you have low testosterone, but instead that you're trying to fix this fundamental mainline problem with a sideline solution.
That you're not going to the mainline solutions.
So what are the symptoms of this kind of problem?
If you are focused on nuance, we already mentioned some of them.
You're having conversations with your manager.
Your manager is trying to figure out.
Why does it look like you're doing something less work, for example, than your peers?
And we try to explain that you do, for example, the glue work, right?
Okay.
So that's one example of somebody who fits in this category.
Other examples include trying to acquire too many skills.
It's very common in this industry, because what got us to where we are?
We imagine that learning more, learning more frameworks, learning more techniques, learning about more providers and APIs, and all this stuff widening our skill set is going to provide the same level of a benefit as it did in the early days of our career, when we first started learning.
And as you progress in your career really anything past kind of a junior level what you'll find is that adding to your skill set, broadening your skill set, is far less valuable than focusing on fewer problems and focusing deep on those problems.
So the advice I would give you is set down the new languages, set down the new skill sets and really become a craftsman of a limited set of tools.
And not just the tools, but Fully understand the problems, the business problems that your company is solving.
Fully understand the domain.
Understand how information flows through the organization.
Try to connect with the real value that the business provides and how that flows through the products that you work on, whether that's an API or front end or whatever.
It doesn't really even matter, right?
At a core level.
Your growth as an engineer is going to come from your ability to solve a lot of problems.
There's very few things that can substitute for a sheer volume of problems encountered and solved.
If you turn no other knob in your career, if you focus on no other outcome in your career, solving problems over and over and over.
This is the deliberate practice that you can engage in as an engineer okay.
So I have some notes here on a few other kind of symptoms, right?
We talked a little bit about the skill collection fallacy.
We also can end up in a comfort zone.
What does this look like?
It looks like an engineer who tends to you know kind of solve the same problems, same types of problems, same level of problems, over and over.
There's a little bit of a context here, because you may have just heard me say solve problems over and over, right?
It's very important.
But as you continue progressing in your career, you want those problems to progress with you, right?
So each problem that you're solving, maybe you solve two or three that are about the same size or the same complexity, same level of mental effort for you.
But if you solve 20 or 30 of those, then your potential for growth is going to become limited.
So as you begin to solve more problems, you also want to change the characterization of those problems.
In other words, if you were solving something that was at the limit of your cognitive ability before you're going to adapt, right?
So if you stay at that level, then your relative ability adaptation potential goes down.
What does that actually mean?
It means your growth goes down.
You're not able to adapt and become a better engineer.
You're going to stall out at whatever that spot is.
And eventually it's going to become harder to adopt new patterns of solution, right?
So, and again, we're not talking about adopting new skills.
We're talking about growing through problem solving, right?
So bigger problems, more responsibility, whatever those changes are that expand your growth potential.
That might be scope.
It might be complexity.
It might be responsibility level.
It might be just the sheer volume of work, maybe figuring out how to just ship more.
That's another growth potential.
There's a lot of axes that you can grow on.
But the important thing is to avoid stagnation on all of those axes, avoiding stagnation on all of those axes together.
So if you were my report, if I was coaching you through this, I would tell you to focus on okay, what specifically am I trying to improve with this next problem?
What could I take on?
What part of this is actually challenging me?
Where do I feel a level of discomfort?
Is that discomfort actually pushing me?
Is it too much?
These are the kinds of questions that you should be asking.
If you're not asking these questions, if you feel no discomfort ever, you may think that that's a good fit, right?
Initially, we imagine that, oh, we're kind of in our zone.
We're able to do this work.
Actually, that's going to burn you out, okay?
And the reason for that is you're not going to be able to get into any kind of flow state.
The important aspects of our work is that we feel challenged, but we also feel able to meet that challenge.
That's the balance that we're trying to strike.
And so if you're adapting constantly, then your level of challenge for the same problem is going to go down.
Hopefully this makes sense.
Our brains adapt to the problems that we try to solve.
And so if you are adapting, then your level of challenge is going to go down and eventually you're going to burn out.
That sounds kind of crazy, right?
Because we associate burnout with working too much.
But actually what happens with this kind of burnout is you keep solving and doing the same thing over and over and there's not enough challenge in your work and then eventually you get bored or you disengage.
If you found yourself disengaging in work, this could be a very likely reason for that disengagement.
So looking for new ways to challenge yourself is an important imperative.
I guarantee you, if you go into your next one-on-one with your manager and you say look, I'm trying to find a new challenge,
I want you to challenge me.
Let's figure out something a little bit harder for me to do, right?
Let's figure out something that is a problem that needs solving.
And you want me to push a little bit harder.
If you're a manager listening to this, please hear me very clearly.
Do not make the only thing you challenge your people on be the go faster button.
Do not just look at velocity as the only metric.
We want to look at complexity.
We want to look at quality.
There's all of these different ways that we can challenge people and help them grow.
The scope of work that they're doing technical challenges, moving from one tech to an adjacent technology, not just for the sake of growing the skillset, but in order to challenge and grow depth right.
That's what we're looking for as a good manager.
Okay.
So what we're really trying to get out here is, if you're focused on the right things, if you're focused on taking on hard problems over and over, continuing to increase the difficulty of those problems right?
Or continuing to increase your scope, Focusing on that core part of your job.
Because the fallacy is that we become very good at all of the things around our core responsibilities.
We become good at networking, at managing relationships.
We become good at looking like we're doing a lot, right?
Pumping up our JIRA numbers.
We become very good at writing resumes right but we didn't do the fundamental thing of becoming good at our jobs.
Become great at your job and everything else becomes easier, right?
That is the fundamental thing.
The primary course of treatment for a failing career is to become incredibly good at your core set of responsibilities.
It seems simple, but so many people miss it.
And I hope that you resonate with this, with this idea that there are a limited set of things that you could focus much harder on and become much better at.
Thank you so much for listening to today's episode of Developer Tea.
If you enjoyed this episode, then you can leave a review in iTunes is the best way to help us out.
Follow and subscribe on YouTube now that we're on YouTube.
And, of course, you can join the Developer Tea Discord community.
There are other engineers there who are going through very similar things to you in their careers.
I'm also in there.
You can message me directly in the Discord community.
So come and join us there.
That's at developertea.com slash Discord.
Thanks so much for listening.
Until next time, enjoy your tea.
