Coding in Leadership

When you start coding, you start the adventure. It feels like unlocking a new world of logic and creativity. From programming classes where we tried to solve pyramid programs to professional work, I used to have fun with coding each day. I chased small wins and learned to debug my own thinking. Each day brought new challenges and opportunities to solve problems through authoring code. The feedback loop was immediate, the learning compounding. Those early years were about craft, curiosity, and fast feedback.

Over time, the role changes. But as my career advanced, my role evolved, steering me towards leadership. Teams grew, systems scaled, and the problems became more about people than syntax. This shift meant a gradual departure from hands-on coding to management, and with it, the risk of getting rusty. Itʼs a known transition familiar to many in the tech industry. The question is not whether to stop coding, but how to stay technically credible while leading.

Adjusting To New Reality

When Java 8 was released, I was already navigating the waters of leadership — my calendar was filled with one-on-ones, planning sessions, and hiring loops. Funny enough I still use the same sort of language syntax when I code, mostly out of habit rather than necessity. I use lambdas and streams, but my default is still imperative. I gradually shifted my focus from coding to the broader perspective of project and team management. Be it roadmaps, architecture reviews, and cross-team alignment. It was a bit unusual at first but then it felt alright; the identity shift took time, moving from a maker schedule to a communicator schedule. To avoid drift, I set clear guardrails: time-box leadership work, protect small maker blocks, and keep a live view of the code through reviews and incident write-ups.

What stuck and worked for a while before managing multiple teams was two 60-minute maker blocks on the calendar every week. One for substantive code review per day, pairing on the riskiest change, a monthly deep-dive where I read code paths end-to-end and summarize back to the team.

Focusing On What Matters

As a leader, my days are now filled with project management, hiring, planning, and guiding teams towards success. That means roadmaps, capacity planning, incident reviews, and cross-team alignment on a weekly cadence. My shift has been rewarding in new ways, it brought its own set of challenges. Decision load went up, cognitive overload increased, and feedback cycles got longer.

The tangible impact is technical drift unless it’s actively countered. One significant change is stepping away from hands-on coding, leading to what many call “rustiness” in coding skills. Muscle memory fades: I still sketch designs quickly, but my editor shortcuts and library choices need refreshing. Iʼm still able to read code without any problem or ask interview questions but writing code professionally is different. It requires up-to-date tooling fluency, current idioms, and production-grade instincts. Those are standards I hold myself to before touching the mainline.

Respecting the Craft of Coding

My reduced engagement in day-to-day coding has reinforced a vital understanding: coding is a serious endeavor that demands current context, reproducible workflows, and disciplined review habits. It’s a discipline with rapidly shifting norms, libraries, and operational expectations. The landscape doesn’t pause for leadership duties; tools, idioms, and reliability bars keep moving.

For those of us in leadership positions who have moved away from active coding, itʼs imperative to acknowledge that diving back into coding without the necessary up-to-date skills and environment parity (tooling, frameworks, testing, deployment practices, observability basics) can be a business risk with production-grade consequences, from subtle regressions to incident load. Itʼs not just about losing touch with specific programming languages or tools (syntax, build systems, performance profiles, dependency hygiene); itʼs about respecting the craft and its current demands by meeting today’s standards: explicit code quality bars, reliability SLOs, security baselines, and team conventions that have evolved while we led from the balcony.

Finding Balance

I believe the key challenge for tech leaders is finding a balance. That means staying close enough to the work to make good calls, without crowding the people doing it. You want to stay informed and knowledgeable about the technologies my teams use, even if Iʼm not actively coding. Practically, that looks like one substantive code review per day, a monthly end-to-end code reading if you are a line manager. You need to appreciate the nuances of development to make informed decisions and lead effectively. Your role is to understand and support your teams, leveraging your experience to guide projects and strategies. The outcome you should optimize for is better team decision quality, not personal commit counts.

Now, coding has become a nostalgic and enjoyable part of my life. It’s also a calibration tool that keeps my technical judgment honest. Though my main focus is leadership, I keep the joy of coding alive through fun side projects. These are deliberately low-stakes and time-boxed, with readme notes on what I learned. I occasionally contribute to my GitHub repositories, engaging in these activities for the sheer pleasure of it. That lightweight practice keeps my instincts, editor fluency, and test-first habits from drifting. My fun side projects help me stay connected to my coding roots while embracing my role as a leader in the tech industry. And they make me a clearer, faster partner to the engineers I support.