Like player coaches, tech CTOs should know how to code

They seem as anachronistic as helmetless hockey players, the no-dunking rule and bullpen carts. But the player-coach was once a familiar figure in pro sports. Bill Russell and Lenny Wilkens in the NBA. Curly Lambeau and George Halas in football. The first six World Series were won by guys who filled out the lineup card and also were on it.

This form of multi-tasking fell out of favor decades ago, however. The last NBA player-coach was Dave Cowens of the Boston Celtics during the 1978-79 season. Want to bet who the last one in Major League Baseball was? Pete Rose, in 1986.

In most tech startups, the Chief Technology Officer’s role is as demanding and complex as that of a modern head coach. He or she establishes the company’s technical vision and presides over all aspects of its realization. The CTO leads technological development and drives the organization to strive for and execute innovation. He or she may serve in other important roles as well, from media spokesperson to conference speaker to customer-facing deal-closer and problem-solver.

One hat that today’s CTO seldom wears is hands-on software developer. Similar to the way that the player-coach has disappeared in sports as the head coach’s role has become more multi-faceted and arduous, the thinking regarding CTOs is that they have enough on their plates with strategy. Who has the time or desire to roll up their sleeves and get busy with code?

I would argue that this reasoning is as misguided as leaving Stephen Curry open for an uncontested three.  With enough determination and dedication, it’s possible and necessary for a CTO to be both a visionary and a key in-the-trenches contributor. Which means that the player-coach model, though long gone in pro sports, serves as an excellent template for tech startups.

A CTO engaged at the ground level – let’s call him or her the Coding Chief Technology Officer (CCTO) – can give tech firms, especially young ones, a real leg up. Here’s why:

The devil’s in the details, and a coding CTO knows the details better

Most CTOs are intimately familiar with the “why” (the rationale for building a company or product – the goal line, if you will) and the “what” (the technological features to reach the goal) but not the “how” (the actual code).  A CCTO, however, can be in the rare position of being an expert at both the macro and micro levels.  This eliminates one of the biggest pitfalls in any organization: a strategic leader who is divorced from the details that can make or break the strategy.

When you truly understand the little things, you’re in a better position to make decisions on the big ones. You can see, in an immediate sense, what’s going well and what isn’t. You also tend to look a lot smarter about the technology in a customer meeting. If you know the details, you can, for example, give a better estimation of the level of effort required when a customer requests a new feature. You can give a more educated response, either in the affirmative or negative, with strong backing reasons.

You can share knowledge

The CTO may be the sharpest technological mind in the company. The CCTO puts him or herself in a position to spread knowledge in impactful, day-to-day ways. In the words of the late Peter Naur, “The proper, primary aim of programming is not to produce programs but to have the programmers build theories of the manner in which the problems at hand are solved by program execution.”

A hands-on, coding CTO can share best practices and coach less experienced developers to avoid common mistakes, such as emphasizing speed over quality or thinking too much by lines of code rather than larger patterns. And it’s the best kind of teaching – showing, not telling.

You gain credibility with the team

A so-called visionary always gains trust and admiration when that person is willing to work in the trenches. That’s just human nature. The trust is necessary for a team to execute on the vision successfully.

A CTO who codes is in step with the times

Today, the re-use of open-source code packages is an integral practice in application development. As a CTO, you’re constantly making judgment calls on programming languages, frameworks, libraries and packages to use. Unless you are involved at the ground level, you could make a wrong technology choice that takes the team down the wrong path and waste precious development time having to revisit incorrect choices.

A CCTO is a fun thing to be

I’ve been coding for 25 years. As I often repeat to everyone: “I love coding in any language to solve real business and technical problems.” To me, it’s an art and a science, not work. I plan to still be writing software when I am 70 (hopefully not for a living!).  So by remaining an active coder despite all my other responsibilities as CTO, I’m not just aiming to add value, I’m enjoying myself.

Now, I’m not going to pretend the life of a CCTO is easy. I spend about 20 hours a week coding and another 10 or 20 reviewing code written by others – a lot of that is nights and weekends. You can only do that if you are passionate about technology and software development. That’s why you’ll often find me late at night in my den, banging away on my laptop as I listen to classic rock. I find that I’m more productive if I’m accompanied by music that I like and am familiar with — Jimi Hendrix and The Eagles are two of my go-tos.

Doing double duty wasn’t easy for player-coaches either. But the situation often worked out well.  Russell won NBA championships with the Celtics in 1968 and 1969. Halas guided the 1921 Chicago Staleys (now the Bears) to the NFL title.

While we may never see those kinds of two-headed figures in sports again, the CCTO offers a back-to-the-future approach that more startups might want to consider to maximize the value of their technical leader and improve the organization’s overall performance.