How to Keep Your Tech Skills Sharp in a Leadership Role

When I became a senior engineering manager three years ago and had multiple teams reporting to me, I was no longer building things on the job myself. This was the first day of the decay of my pure technical skills, and with it came the question of what I was going to do about it.

Fast-forward to March 2020, I’m sprinting through the Sao Paulo airport, hugging my carry-on luggage close to my chest and dodging other travelers as best I can. I was visiting South America when COVID-19 hit Europe and air traffic started shutting down. I was heading back home to Amsterdam and my connecting flight from Buenos Aires had landed an hour late. So I made a run for it. If I didn’t catch this flight, I was going to be stranded 10,000 kilometers away from home.

Fifteen minutes, 40 gates, and a wobbly knee later, I finally reached the boarding area completely out of breath and managed to catch my flight home.

When I got back to work in the following days, most of my colleagues had been working from home via video calls for about a week already. I had missed the early days of the quarantine, but luckily the local supermarkets hadn’t been raided too badly, and I was able to get my hands on toilet paper.

As I started setting up my quarantine routine, I made the decision to tackle the hitch that had been annoying me for a long time, and by this I mean I was determined to catch up with the cutting edge in tech.

My plan was simple: I was going to build a web app as a pretext to learn an entire tech stack end to end. I actually tracked the time I spent on it weekly to hold myself accountable, and it worked!

After more than 100 hours of coding and learning between April and November 2020, I launched the MVP for Sidenote.me, a web app to take time-stamped notes on videos. In the process I learned in-depth about TypeScript, Node.js, and MongoDB, and I performed a high-level refresher on the state of the industry in other tech ecosystems, such as containerized infrastructure, micro frontends, and serverless computing.

Why should you care?

You’re probably ready to ask me, “Hey Emmanuel, thanks for letting us know about toilet paper and all, but why should we care about your story?”

You should care because it applies to you too. Having a broad understanding of tech tools, platforms, techniques, and how they fit together is going to be instrumental for you to make the best decisions on the job, and it will be critical to your career progression. This applies whether you work directly or indirectly in tech, and whether you’re a product manager, engineering manager, or an engineer.

You want to have deep enough knowledge about your own branch that you can be relevant for the projects you work on, and at the same time you want to have a broad knowledge of the overall tech landscape so that you don’t end up overspecialized and trapped in a corner.

Another problem is that there are a lot of fads in tech, and some things that are in use one day might go out of fashion the next.

But that’s not all. Everybody knows how to type keywords into Google, and there is an overabundance of free resources about any topic. Access to information is not the problem, the problem is what to do with all this information. In order to figure this out, you would have to:

1. Explore blogs, articles, and videos so you can discover new concepts, tools, and skills that you don’t already know.
2. Find resources to learn those things.
3. Filter resources to keep only the best-quality ones.
4. Put those resources in the right learning sequence.
5. Find a way to integrate all this into your already busy life.

Considering the level of distraction all of us are juggling on a daily basis, achieving what I listed above is far from simple.

I’m on a mission to help engineers, managers, and other tech leaders to keep up with all the ever-evolving tech ecosystems. Because I’ve been through this journey recently, I want to summarize and share what I’ve learned and what has worked for me. And I promise, you won’t have to sprint through an airport to get there.

What I’m going to cover

Most concepts in this article will sound familiar to you. My contribution is that I’m packaging them together into a framework that will help you more systematically keep up with tech ecosystems.

If you’re already working a day job and have other responsibilities at home, starting something like this can be daunting, and the mere thought of it can destroy your motivation.

This is why I’ve taken the time to break things down into smaller parts so you can take them one by one. I’m going to talk about setting up your objective and motivation, managing your time, prioritizing what to learn, and at the end of the article I’ll help you build your own plan. Let’s get started!

Get your motivation in line

Your motivation is where it all starts. You need to be clear with yourself about why you want to embark on this journey and why it’s important to you.

For example, it could be because you’re planning to transition to another job, because you want to switch industries, or simply because you’re curious and you want to learn more about tech in general.

So the first step is to book in your calendar 30 to 60 minutes with yourself and go over this. Don’t overthink it; go for a walk or a bike ride, or sit on a bench under a tree somewhere with no phone or distractions. Seriously, do it. Then when you come back from that self-reflective moment, write yourself an email with the key points of why you want to do this.

Over the next few months, you’ll have moments of demotivation or stress, and you’ll ask yourself why you started. You’ll tell yourself it’s not useful and that you should abandon it. In those moments, go back to that email you sent to yourself and you’ll get an instant motivational talk from your past self to help you through that rough patch.

If you’re doing this because someone is making you and you’re actually dreading it, please do yourself a favor and stop right here.

Another way to motivate yourself is to create an emotional connection with what you plan to do, so that you can use any passion you already have to fuel your momentum into your project.

For example, if you like playing music, then combine that with tech by building a basic guitar or piano simulator in TypeScript. If you enjoy playing sports, then build a mobile app using Kotlin or Swift to keep track of your progress at the gym or map out the terrain you run weekly.

I could go on with loads of other ideas, but I think you get the gist of it: your passion for whatever hobby you have will serve as a booster to keep you going.

Define your success criteria

A classic trap I see people falling into with their side projects is that they keep changing the requirements for themselves while they’re in the middle of it, without even realizing that they’re doing so. This is because they never defined their success criteria.

Before you start, you need to define what success looks like for you. You could even add it to that email you sent to yourself about the reasons behind your motivation.

For example, when I decided I was going to do a full refresh of my knowledge of the entire tech landscape, being successful with this project wasn’t about making money, reaching a certain number of users, or any other form of external validation.

My goal was to unrust my tech knowledge and skills, and for this I was going to measure my success in terms of (1) spending time learning tech topics broadly on a weekly basis, which I was going to measure, and (2) building a basic web app from end to end.

Manage your time

Let’s be honest; enough has been written about time management to cover multiple human lifespans. So I’m not going to bore you with a long essay of concepts you’ve already read someplace else—I’ll just cover the basics.

The most important thing is to book time in your calendar for this project so that nothing else comes into conflict with it. What is scheduled gets done. It’s best to always work at the same location, preferably a place with little chance of interruptions so you can really dive deep into what you want to learn or build.

When I did my project, I decided I was going to spend five hours on tech per week, with one block of about two hours right after work on Tuesdays for reading and exploring, and another block of three hours for coding on Saturday mornings. I also booked those time slots in my calendar as recurring meetings.

Having those days and times be always the same really helped me, because no matter what was happening during my week, I knew that my project time was protected and I’d be able to make progress. Of course, some weeks things didn’t go as expected, and I ended up spending one hour instead of the five I had planned. But I made sure this never happened two weeks in a row, so I would get back on track quickly.

Finally, if you are in a relationship with someone or live with someone who depends on you, and you’re in an established habit of spending your time together in a certain way, then it’s going to be super important that you keep that person in the loop and tell them about your personal project and plans.

If it’s your life partner, then you’re going to have to negotiate which days and how much time you spend on this based on whatever makes sense for your relationship.

This is an incredibly important step if you don’t want your personal project to create problems in other parts of your life. On the other hand, you want your loved ones to support you and to understand that, if possible, they shouldn’t interrupt you when you’re doing your project, so you can make the best out of the time you have.

Exploring vs. planning vs. doing

Exploring, planning, and doing are very different mental modes. They require different mental settings, and if you start in one mode at the beginning of a session, chances are your brain will stay in that mode even if you’re trying to do something else.

It happened a few times that I walked into a three-hour coding session with a lot of energy, but without clear idea of which tasks from my backlog I’d be working on. So I would start the session prioritizing tasks for 15 minutes.

However, when I’d be done prioritizing I often could no longer find it in myself to execute on any tasks, as if going into “planning mode” for a mere 15 minutes had impacted the type of activities my brain was able to subsequently perform.

In the worst instances it took me up to 45 minutes to fully reset my brain into “doing mode” again, which felt like an excruciating waste of time.

The time you have with yourself to make progress on your project is precious, so you don’t want to end up procrastinating on the internet or feeling paralyzed because you’re mixing mental modes too much.

If you find yourself falling into the same patterns as I did, then you should try dedicating separate time slots for activities that require different mental settings. For planning, you could book a 15- to 30-minute session with yourself every one or two weeks, during which you organize your backlog of tasks, including things to do and content to go over, and make sure they’re prioritized.

For exploration, and by this I mean going around the internet looking for things like new topics, concepts, articles and videos, I also recommend doing that in its own time. Preferably, you should conduct exploration after other types of activities, because exploration is going to involve social media and chances are you’ll end up distracted or procrastinating down a rabbit hole.

So, for example, if you want to be in “doing mode” and “exploration mode” within the same uninterrupted two-hour session because it works best for your schedule, then you should start with “doing mode” for the first hour, and only after that go into “exploration mode” for the second hour, and never the other way around.

If you know that the time you can spend on your project is likely to be fragmented, then you can use your backlog-organizing session to break down tasks into 20- to 30-minute work increments. It’s not always possible, of course, but it’s nice when it happens.

Build up to it

Overcommitment is a common trap. I’ve fallen prey to that one a lot, even though I’m aware of it, and I still feel silly every time it happens. Let me ask you this: if your end goal was to deadlift 200 kilograms (or 440 pounds), would you head to the gym and try to lift that much right on your first try? Of course not.

So why is it that so many of us who want to exert a big change in our lives frequently try applying the entire change all at once? It’s because we get excited, and by pride we want to prove it to ourselves that we can do it all, and we end up biting off more than we can chew. This often has the opposite effect than the one planned, and it derails the entire project. A better approach is to build up to your goals.

Whatever commitment you have in mind for your project, you need to habituate yourself to this new mental activity, just like you would habituate your body to a new physical activity. Put simply, it means you should never add a five-hour commitment to your weekly routine when you’re already juggling a ton of other things. That’s the perfect recipe for failure.

Instead, use a building-up approach. For example, do 30-60-100 over three months. Start with 30% of your end commitment for a month, then dial it up to 60% for another month, and finally go for 100% in the third month. By the way, I just made this up; you can pick the percentages or durations that better fit your needs.

In practical terms, if you’ve decided to commit five hours per week to your project, you could start small with perhaps one-and-a-half hours of reading each week for a month. After that, you could crank it up to three hours each week by adding a bit of coding for another month. Only after all that would you go to up to five hours.

Sprinkle in some time for exploring, planning, and organizing your backlog here and there, and you end up with a solid plan for escalating your work and time commitment.

I strongly believe that knowing how to build up to major tasks is an important life skill that should be taught in school. Once you understand the concept and have tested it on a few things, it can be applied to all areas of your life. This almost deserves a dedicated article of its own.

Finally, do not feel guilty or bad if you set a goal of spending six hours per week for your project and end up able to pull off only two hours or less. If you can do 20% of what you planned, it still beats the hell out of 0%. The best routine will always be the one you can keep.

If you put it all together, you get something that looks like the diagram below. The columns represent the days of the week, and the rows represent the 13 weeks of a three-month period. This is an example of how you could spread your activities during each week while ramping up your efforts over several months.

— You: “Hey Emmanuel, isn’t this diagram just a screenshot you made from a spreadsheet?”
— Me: “Yes. Yes it is. And I have no shame about it.”

Prioritize what you learn

Not everything is worth knowing or learning about, and not everything requires the same degree of depth and details.

There’s an eternal dilemma in tech, and it’s whether one should be a generalist or a specialist. If you’re too much of a generalist then you’re an expert at nothing and nobody wants to hire you, and if you’re too much of a specialist, then you’ve siloed yourself into a niche that only a few people want to hire for.

You should be specialized enough that you’re employable, while knowing enough of other domains that you can show a strong grasp on technology and jump into another specialization if needed.

So your personal breadth vs. depth journey should look like the letter T, which is the first level of prioritization. You should know about almost every tech topic from a very high level, and then you should pick one or two silos in which you will specialize.

For example, when I picked up the challenge of refreshing my tech skills, I planned to cover on a very high level the cutting edge of techniques and tools in the fields of infrastructure and cloud computing, and to check out the latest developments in programming languages.

This helped me build a mental model of the current state of tech and how it all fits together. This is the horizontal bar of my T.

Then I decided to dive into a tech stack, so I focused my energy on a single language, a single framework, and a single type of infrastructure because that would give me an idea of the full development cycle, end to end. In my case this was Angular, TypeScript, Node.js, and MongoDB. This is the vertical bar of my T.

Below is a diagram that represents the tech fields which I decided to cover broadly, and the ones I decided to study in-depth. 

There is a natural specialization happening in tech, and so your situation will likely be different based on which field you want to dive into. For example, you may want to dig deep into infrastructure and cloud computing and cover client-side development only superficially. Or maybe you work in a mobile-only shop and you want to dive deep into the latest mobile frameworks but cover everything else only sparsely.

This is for you to decide based on your need.

There are two traps in learning tech topics. First, a diminishing return on learning, and second, the fact that tech keeps changing at a fast pace and skills can become outdated quickly.

That’s why, if you have some spare time, it’s better to spend it on things that stay relatively unchanged over the years, like computer science fundamentals, programming languages, or frameworks, and you should avoid at all cost spending too much time on things that change or go out of fashion quickly, which generally is the case with tools and libraries.

Within the domains I picked to go more in-depth, there was a second level of prioritization: How do I prioritize which parts of these domains to learn?

The article “The Myth of ‘Keeping Up’” by Kathy Sierra and Dan Russell presents a useful mental model that answers this question. It states that for everything you want to learn, you have to classify its parts into the following categories:

• Need to know.
• Should know.
• Nice to know.
• Edge case, only if it applies to you specifically.
• Useless.

I applied this to the topics I wanted to learn by creating a spreadsheet with all parts as rows, and then in another column I classified the parts according to the categories above. The categories of some parts changed as my understanding became clearer, but they mostly stayed the same. Then I focused my time on the “need to know” category, spent even less time on the “should know” category, and tried to avoid like the plague everything falling into the remaining categories.

Resources to learn about tech

For in-depth learning, there’s a plethora of specialized books and video courses you can pick from for almost any topic, whether you want to learn about a particular language, a specific framework, or anything else.

But to get an idea of technology in breadth, things get a little trickier. The problem comes down to learning about things that you don’t know, while not even knowing that they exist in the first place. You need a sort of discovery and exploration mechanism for that.

A great first stop for that is the ThoughtWorks Tech Radar, which provides a list of various technical topics and a recommendation of whether you should adopt, try, assess, or hold off. It’s a great starting point to know what is out there and worth looking at.

Another great resource is the tech trends reports from major tech players, like the GitHub Octoverse Report, which spans a large array of tech topics as well. In their 2020 edition, it was pretty clear that TypeScript was undergoing major growth. That’s how I directed my decision to pick this programming language as the next one to learn. Also, I had already worked extensively with C++, Python, and PHP in the past, so I didn’t need to learn them.

From there, work your way across those tech topics by finding introductory resources on them. Google is your friend for that, and from experience I can tell that the following queries tend to return good results quickly:

• What is X
• Introduction to X, or
• Beginner tutorial for X.

Finally, one way to learn about new things is to follow the right experts on Twitter or other social media platforms where they hang out, or to connect with experts in your professional network, like former colleagues or people at your current workplace.

Those experts are also a great source of information to help you classify the parts of a topic into need to know, useless, and so on, as I explained in the previous section.

Finally, here are some top resources I’ve used in my exploration and learning that I go back to on a regular basis:

• ThoughtWorks Tech Radar
• GitHub Octoverse Report
• InfoQ Trend Reports
• IBM Cloud Learn Hub
• Martin Fowler’s website
• Google’s Web Development Portal
• Mozilla Developer Network
• FreeCodeCamp
• The Missing Semester (MIT Computer Science)
• The Fireship channel (YouTube)
• Free tech courses on Coursera

Wait, it’s not over. I have an ebook with more resources; read the section below.

Shameless plug: I’m building a learning program, so sign up to stay in the loop!

Keeping up with the constant changes in tech ecosystems means figuring out a way to quickly discover what’s new, filtering the unimportant from the important, and integrating all that into your already super-busy schedule.

I am building a self-directed learning program and also a community around it, but before committing the energy to that, I’d like to make sure there is enough interest. So if you’re interested, sign up for my email list below.

Right away you’ll receive an ebook with links to 80 introductory resources on many tech topics, and I’ll keep you posted as I make progress.

My goal is to get at least 200 sign-ups, and at that stage I’ll start working on the first iteration of the program. If you want to help make this happen, share this article on social media and tell other people to sign up too!