Why I Stay Hands-On in the Code
Founders of consulting firms usually stop writing code. I did not, and it makes a difference.
Most founders of technology consulting companies reach a point where they stop doing the technical work. They transition into sales, strategy, and management. I understand why — the demands on a founder's time are relentless, and delegation is necessary. But I chose to stay hands-on in the code, and I believe it is one of the most important decisions I have made for Infraxio.
Credibility With the Team
When I review an architecture decision or a configuration choice, I can evaluate it on technical merit because I work in the same codebase. The team knows that my feedback comes from understanding, not from a high-level overview. That credibility affects the quality of every conversation.
Credibility With Clients
When I tell a client what a system can or cannot do, I am not relaying information from someone else. I know because I have built it, configured it, or tested it myself. That directness saves time and builds trust.
Staying Current
Technology changes fast. A founder who stopped coding five years ago has a mental model that is five years out of date. Staying in the code forces me to stay current with tools, frameworks, APIs, and best practices. That currency flows into every strategic decision I make for the company.
The Trade-Off
The trade-off is real. Hours spent coding are hours not spent on sales, partnerships, or business development. I manage that by being disciplined about when I code — focused blocks on specific projects — and by having a team that handles the full implementation lifecycle. My role in the code is selective, not all-encompassing.