Being the CTO

From time to time I’m asked what being the CTO at Enova entails. These questions take the form of everything from a very polite, “What’s it’s like to be in your role?” to (my personal favorite) the very direct, “What the heck do you do, anyway?”

It’s a very good question and actually one I ask myself from time to time — anchoring myself to see if I’m spending time on the right things.

After much thinking on the question during a walkabout on Michigan Avenue, I’ve come to the realization that what I do — and what’s important for Enova and the team — is distilled down to four things:

Recruitment

I decided a number of years ago that part of my job, no matter what was going on, would be to talk to everyone who came through the door for a job on the Tech team. From interns to a new director, I spend 20-30 minutes talking to everyone as a wrap-up chat. The format is simple: I want to talk about some things in their history that I think are interesting and relevant to how they would interact with the team. And then I leave time at the end for them to ask any question they have about the company or the Tech team.

My goal in this is not to suss out some deep technical skill or gap, or to find something the rest of the interviewing lineup missed. Rather it’s to get to know them and understand how they will or won’t fit as well as to share my perspective on our mission.

This works out to be more than 200 discussions per year — a sizable investment to be sure. So why do I do it? Because deciding who joins the team is the most impactful decision we make as leaders. In the end, what we do is a collaborative, creative act. It is art dispassionately rendered through stories, tickets, and project plans. It’s far more important than the choice of programming language, type of infrastructure gear, or database technologies.

Architecture

As a grizzled veteran of the early days of the World Wide Web, I can remember fondly the days when we dealt with increased traffic by simply building a bigger box. Distributed systems, reusability, and components were a kind of Middle Earth language only spoken by disheveled people coding in Smalltalk muttering, “It’s the only real OO language, plebs,” under their breath. But then this newly-connected world got big. Really, really %$@#% big. And with that connection grew a need to scale your own software and environment — and to leverage the best services around the ‘net. (I just typed “‘net” while mentally wearing my Alice in Chains t-shirt.)

This is why some of the earliest ideas about architecture talked about by only the crazy Smalltalk guys — sorry, Neil, if you’re reading this — have become mainstream practices on how we build technology today. Like many companies, Enova has also experienced changes in Architecture that follow the growth and maturity of the organization and its products. Like going from monolithic applications to service. No tech startup talks about the finer points of technical design — tech startups are just trying to survive. But as this startup goes from zero to one to n, how that transition is handled is vital.

A former colleague used to joke that “if you’re doing it by the book, you’re most certainly doing it wrong,” which is the best summary of my view on most technical concepts. It’s about taking those ideas and adapting them to the unique needs of your business. It’s why I view this evolution as a team sport and not a solo act. We all participate in the discussion of where our technology is headed.

Culture

Culture as applied to technology companies is a tough-to-describe-but-easy-to-identify concept at which Justice Potter Stewart would have nodded sagely in approval. We likely all have a pretty good idea of what our culture is at work. Like families, every company has its own traditions, values, and ways of interacting. And, like families, companies have good and bad aspects to their interactions.

Part of my job is to support the culture of the Tech team and the company. To feed the “good” aspects of it, and to change it to weed out the “bad.” For example, to help ensure things like debates are truly debates and not the product of who has the loudest voice. Note that my role is not to set that culture top-down, as that would be as effective as sending a three-page email commanding a Mandatory Fun Hour. The culture is shaped by people (hmmm…see above), by ideas and by leadership throughout the team.

My role in culture beyond the people aspect is to provide the environment that helps it grow in a positive direction. Some of that is acting as an exemplar of Enova’s core values. Some is how I conduct myself — how I deal with conflicts in the team, how I communicate. Some is how I coach our Tech leadership. And culture is really, really important. As management philosopher Peter Drucker puts it, “culture eats strategy for breakfast.”

Star Trektm Technology (aka Management)

Like most people my age who wound up slinging bits for a living, I have a deep love of science fiction. Therefore, I offer this last section on management in homage to what is to me the ur-TV show for geeks.

What happens when an object moving quickly through space encounters another object? Newton tells us that (among other possibly bad things) the forward momentum of that first object is slowed. The same with teams that face obstacles — progress slows. In Star Trek, the device that keeps the Enterprise from hitting things is the Deflector Shield; in tech teams, that role is played by leadership.

Obstacles in tech teams take many forms. For instance, maybe the team needs a piece of equipment or software. Perhaps the team is stuck on a problem and needs help thinking through a solution. Maybe there’s something external to the team that is slowing them down. Part of my job is to look across the team and the company and help surface those obstacles and remove them. Part of my job is also to explain why something the team may perceive as an obstacle (“Why can’t I have root access to all the things?”) is necessary.

The other key management element of my role is facilitating communication between groups that have different vocabularies. In Star Trek, that function is handled by the Universal Translator. You can think of me as a kind of human version, helping to ensure the different groups inside and outside of the Tech team are in sync. Enova has a very large and sophisticated technology and analytics platform. Ensuring coordination and understanding among all the people working on that is a critical part of my role. I also focus on bridging any communication gaps between the technical and non-technical parts of the company. That means helping my team understand what drives the business and helping the organization understand the “why” of technical concepts.

And that’s the role of being a CTO at the coolest company in Chicago in four easy lessons.

John