Coding is a bad habit

I still think of myself as an engineer, though I haven't written code in anger since the very early days of Sunlight Payments. I have learned not to dive into code or drive too hard on specific engineering topics. As a leader, my primary responsibility and focus is on the organization that produces the product and the product performance, not the engineering that goes into that product. I will keep the teams from hurting themselves, but when someone makes a poor engineering decision, it's my job to help them learn how to make better decisions. It's not to make the decisions for them.
I have learned that lesson the hard way.

The Lessons

The Nero

Many years ago, we hired a new Director for an organization we built. That Director interviewed well and had a good background. However, he still needed to develop the fundamental leadership skills to direct a product-facing organization. Leaders from an engineering background often fall back on their strengths in times of challenge. Unfortunately, thier engineering strengths are no longer effective forms of leadership. They can't write code to solve the organization's problems. Without the tools and the mentors they need to understand what to change, these leaders can't find their way through organizational challenges. Without those tools, they fall back into what they know. In this case, he would write code in areas of the codebase that he found problematic or just interesting.  The engineering team would come into a code review request on many Mondays. We called those review requests code bombs. They were always a surprise and blew up our day. As a Senior Engineer, I was on the receiving end of many of those bombs. The Director was a good engineer, but he didn't have the context needed to function at that level. He didn't know what we were trying to accomplish and rarely aligned his code with the team's goals. Working through the code review process with him was also sow because he didn't have the time to focus on the review. After a while, we started just accepting his code and then immediately reverting it so we could get on with the business at hand.
For that Director, writing code made him feel in control. He knew what to do in that situation. However, the organization was burning down around him. As the engineers in the trenches, we felt the pain of that burning organization every single day and looked at those code reviews as evidence that this Director was playing his fiddle while Rome burned. With every code bomb, we lost further respect for him.

The Tactician

Later, I worked for a CTO who had gotten in on the ground floor of one of the major early successes in the industry. He walked out of that job as a comfortably wealthy individual. For many years, he invested in startups and dabbled in interesting tech. He was a good investor and a great engineer. Unfortunately, he was not a good leader. At some point, he took over as the CTO of one of his investments. As a CTO, he needed to figure out what to do to solve the problems in the organization, but he didn't have the skills he needed to be effective in the role. Falling back on what he knew, he felt that the problems all stemmed from the quality of the code in the primary product. So he created a Tiger Team of trusted people. He kicked off a ground-up rewrite of the most problematic codebases. That failed, as rewrites almost always do. He created a duplicate product that served some customers while all the other customers continued to use the original product. That new product started accumulating cruft, and the organization ended up worse off. He didn't solve any fundamental problems, and now there were two problematic codebases rather than one.
Your primary focus as a leader in the organization that produces the product and the performance of that product. Not the engineering that goes into the product. When someone on the team makes poor engineering decisions, it's your job to help them learn how to make better decisions. Your job is not to make the decisions for them, no matter how much simpler it feels in the moment.

Next Steps

All of that said, you must retain your skills as an engineer. Otherwise, you will not maintain the respect of your organization. You can not do that in the context of your organization. You must do that out of band. I still love writing software. In the small amount of free time I have between family and work, I explore interesting areas of tech. I recently realized that I end up digging into and solving many problems in areas with little or no documentation. Instead of just learning that and moving on, I want to make finding the solution much less arduous for the next person to come along. To that end, you will see some posts on specific technical topics.