Staying technically involved

A constant challenge in senior technology leadership is deciding how much to stay involved in technical work. At the VP or Director+ level, most of your energy goes into strategy, organisational health, and cross-functional influence. But fully stepping away from technology can disconnect you from the very domain you are meant to enable. Finding the balance is the goal.

Over the years, I have tried different approaches. Sometimes I set aside time for in-depth discussions with staff and principal engineers to understand evolving systems. Other times, I reviewed architecture proposals, asked “why,” and acted as the first customer for new platforms. Occasionally, Sometimes I focused on one domain in depth, like scalability, data flows, or customer experience, to gain a sharper view of trade-offs without becoming a bottleneck.

Where I have found the greatest value is in being intentional about where I stay close. I prioritise areas of highest risk or impact: new product launches, changes that could materially affect customer revenue or operations, or core flows where failure would cascade across the business. At Unity, that often meant staying close to game launches. A failed launch would not only damage the reputation of the studio and affect sales but also limit Unity’s own revenue potential. In those moments, my role was to be engaged enough to help uncover blind spots beforehand and, if things did go wrong, to step in alongside the team to resolve issues quickly. The aim was never to be the final decision-maker or second-guess decisions, but to bring an additional perspective and ensure we were ready to respond. Outside those areas, my focus shifted to creating the environment for others to lead.

Staying technically involved has clear benefits. It builds credibility with engineering teams, showing you understand their challenges. It strengthens your partnership with product and business leaders, as you connect strategy back to technical reality. And it keeps you sharp. No leader wants to be unable to grasp a technology shift that could reshape their industry.

But there are pitfalls. The most common one is slipping back into the role of an engineer and inadvertently undermining your actual engineers. If you are the Director, your job is not to win the architecture debate or commit the cleanest code. It is to create the conditions where your engineers can do their best work. Another trap is spreading yourself too thin, chasing every technical topic and ending up with shallow context everywhere but depth nowhere. I have found it far better to go deep selectively and otherwise trust the leaders you have put in place.

The key is to be deliberate. Decide how you want to remain connected technically, and communicate that openly. Some leaders choose to stay hands-on with small side projects, others commit to regular technical reviews, and some embed themselves in one strategic initiative each year. All can work if you are clear on your intent. What does not work is hovering, dropping into code reviews unannounced, or re-challenging decisions that your engineers have already made. That kind of behaviour erodes trust quickly.

At this stage of leadership, your technical involvement is not about control. It is about staying curious, staying relevant, and showing your teams that you value the technical discipline as much as the outcomes.