I’m a technologist in a non-technical role. How do I keep my skills sharp?

This is The Lossless Leader, an advice column written by engineering manager Leemay Nassery.

Why call it The Lossless Leader? An engineering leader is someone who inspires their team, communicates well, grows their people to become leaders themselves, removes blockers or painful aspects of their team’s day-to-day, delivers on product requests and so much more. In tech, lossless compression is a technique that does not lose any data in the compression process; it reduces the size of files without losing any information in the file so quality is maintained.

Combining the two: Leaders aren’t perfect. Sometimes they manage to not “lose any data” in the process of leading their organization, and other times it may seem like they’re losing it altogether. We’re naming this column The Lossless Leader because we all admire those leaders who strive to stay true to who they are and the people they serve (their team). They admit fault when necessary, learn from their mistakes, sometimes flourish in difficult situations — all while not losing themself along the way.

Submit your question to The Lossless Leader

---

The question: 

“I keep ending up in roles that are further and further from being technical and now I’m also no longer a people leader.  It is very tough to regain confidence to look externally even though so many friends are begging me to. How do you get that mojo back?”

The answer:

Truth talk: I have a fear of atrophying, losing my technical skills as I sit through status meeting after status meeting, reflecting on what once was. However, this isn’t about me, this about you!

Now, here are a few ideas to get that technical mojo back while in your current position, so you can ultimately gain the confidence to find a gig that better suits your interests.

Do one coding challenge a week

I’m not sure if you’d like to pivot to a role where you could be writing code, but regardless, solving coding problems never hurt anyone. Do a HackerRank or LeetCode once a week.

Sustaining your technical brain muscles can be compared to working out any other muscle in your body. For instance, if you stop running for a year, and then start running just one mile every other day, you’ll soon feel like a runner again. If you’re far from coding, but slowly pick it back up again, you’ll feel a little closer to that technical position you crave.

Even if you’re not intending to pivot to a developer role, being a manager or project manager who can write code isn’t a bad thing; you can at least relate to your engineers more. I once interviewed for a director of engineering role where part of the interview included a simple coding question — emphasis on the “simple.” I suspect they included this as part of the interview to see how I solve a problem on the spot with an engineer leading the exercise … which I respect. It was both a good and humbling experience to attempt to write code during an interview.

Look at data and graphs

If you’re not intending to pivot to a heavier technical role such as a developer, then my next suggestion would be to spend time looking at data and graphs to regain your confidence in the tech realm. What metrics are your team or peer teams looking to increase or optimize on? What data is missing to achieve the metrics of your organization’s dreams? Why is it missing? Data problems are universal, no matter what company you work at.

If anyone talks about data in an interview, they’ve caught my attention. A few years ago, I recall a candidate that we were interviewing for an Engineer 1 position on my team mentioned they didn’t realize the importance of logs that are produced by their application until she had a production issue to triage. She alluded to needing more data to understand the root cause. I instantly had star eyes when she made this statement. Being aware of the importance of data, regardless of what position you are in — whether that’s product management, project manager, engineer, etc. — is valuable. Get to know the data you have, the data you would want, and what decisions you would make if you had that data.

Read technical documents and feature specs

Read documents that are written by engineers or engineering leaders within your current company — for example, a document that’s proposing a migration to a managed kubernetes cluster, or outlines a new feature. While you read the document, specifically take note of the comments. Familiarize yourself with what other (more-technical) individuals are thinking when reading the document, what they’re trying to optimize on when solving a problem, what questions are they asking, etc. Maybe even reach out to the engineer who wrote it and asks questions, or post comments on the document itself.

Make it a habit to set aside two hours to read a document a week; just block your calendar for “focus time” where you can read up on deeper-cut tech topics that you would otherwise not be exposed to. If your team isn’t a document-driven culture, browse discussions on Slack or take advantage of tech focused groups like guilds  or architecture groups. (And try to find the good ones … the groups where folks are so opinionated you’re annoyed but still entertained, while also learning a thing or two.)

Read up on past incidents

A tactic I’ve used myself, when I’ve had a curiosity to feed, is to read up on incidents or post-mortem documents by other teams.

Incidents happen. Learn from them. Simple as that.

If you don’t have incident reports available easily at your company, check out prior incidents by well-sought-out tech companies — for instance, the recent Facebook outage or the Slack outage at the beginning of the year. You’ll find interesting details in these post-mortems that you may not be exposed to in your day-to-day work. Having the desire to stay technical means you’re willing to learn, you have the innate curiosity; I can’t think of a better way of learning than by absorbing other teams’ lessons.

###

The goal with getting back into the technical arena is to do one thing a day that makes a small but notable difference over a long period of time. Take the late, great basketball player, Kobe Bryant: Kobe would do one extra workout a day. After some amount of time, his peers couldn’t catch up to where he was. Doing one extra thing a day will get you back into that more technical mindset.

I must say, the good news is that you have people management experience; this is often a hump that many folks fail to achieve. Update your resume highlighting the soft skills you learned while a people leader. Managing people is not easy; you have to consider their career growth, what motivates them, how to influence them, etc. You have to build trust with them so they feel comfortable expressing concerns in 1:1s, etc. It’s a career milestone that shouldn’t go unnoticed. As a hiring manager myself, if I see that someone has applied for an individual contributor role but has past experience as a people leader, I assume they have the soft skills that will make them an even better individual contributor.

I admire the pursuit of gaining back your technical mojo. Once you get back into it, you’ll find it’s remarkable how you sometimes think you’ve lost a skillset or way of thinking, then realize, you’ve still got it.

Alright, enough encouragement to get back into the technical-saddle. To conclude this, here is not just one, but two songs to listen to as you read those technical documents, look at data, do a coding problem a week and ultimately regain that mojo: “You’re Unbelievable” and “Don’t Stop Me Now.” Because you’re unbelievable, and they can’t stop you now!

(Would you believe me if I said I’ve listened to both these songs before presenting on a Zoom call? …)

Good luck. You can do it, I know you can!

Submit your question to The Lossless Leader