Code as Crutch
From programmer to manager to mentor — this CTO learned the hard way that code isn’t the answer to every problem.
“Addiction is the continued repetition of a behavior despite adverse consequences” — Wikipedia. Although some engineers put on a bit of weight and lose a bit of muscle, coding won’t exactly turn your eyes yellow and make your teeth fall out. While coding can most ceratinly be addictive, it’s a different type of addiction. If you’re not a coder, let me try to pull back the curtains.
I was 10 or 11 when I wrote my first lines of code. I copied some BASIC directly from the pages of the excellent magazine “3 2 1 Contact”. Then I hit F5, the keystroke to execute your program in MS-DOS QBasic. Running that program was a serious rush. The computer was doing what I programmed it do. I could go back to my code, make a little change, and the machine responded. The power of creation, in my hands. So rapid and so rewarding. (I wish I had a picture of how goofy-excited I must have looked)
I’m not a stereotypical computer prodigy; it wasn’t until college that I really got into coding. But once I was hooked, holy shit was I hooked.
Ten years later I’m running my own venture backed startup (which I co-founded with my good college buddy @reece) and completely addicted. Write a little code, run it, feel the rush when you see your new creation take shape. That was my routine. But just like any other drug, it never feels quite the same as it did the first time. So I wrote increasing amounts of code which drove me to write even more code. This was great, because we had a ton to build. And unlike a drug, I thought everybody around wanted me to write more code. I thought it was expected.
crutch /krəCH/ noun. “a thing used for support or reassurance.”
Indeed, writing code was required. We had a lot to build, and we built it. We executed. We launched. And like most startups, we needed to iterate. So we went to the whiteboards and brainstormed. Then we walked away, put the headphones right back on, and started coding the ideas we dreamed up. I was working hard, but I was only working in the company. What I didn’t yet appreciate is that a cofounder/ CTO needs to be working on the company as much as they work in it.
maker :: manager — an evolution
We’re a smart and creative group of individuals; we get shit done. It didn’t occur to me that we might need more direction and structure to continue executing at the same level. As the product and team grew, it was no longer eficient for me to simply hold the entire plan in my head. I couldn’t expect our team (engineers or otherwise) to get by on the occasional ad hoc conversations.
I didn’t realize this because, while I was coding away and indulging my addiction, my team needed me. In one-on-one reviews with myself and Reece, they made it clear that we needed more structure and guidance. Realizing there was a leadership vacuum, I committed to evolve from “maker only” to a balance of “maker/manager.” After all, I owned product, it seemed natural that I needed to be the project manager that helps us get things done.
But, as the story often goes, there were false starts. We were a dynamic and highly effective team that didn’t need a full time project manager. Accordingly, that role didn’t fully occupy my time. The rest of my time was spent coding. And the coding time quickly ate into the management time… which I was fine with. :-]
I don’t like management (from either side of the table). And I’m not particularly good at it (very little practice). Coding, on the other hand; I like it and I’m good at it. Whenever I encountered some non-coding shit I didn’t want to do, it was easy to substitute a bit of engineering: bug fixing instead of organizing Trello; refactoring instead of reviewing deadlines; system planning instead of project planning; code was still my crutch. I had not become our project manager. Hashtag fail.
Not being one to give up, I searched for another way to lead the team (other than traditional management). We were working on our iOS product and it was the one git repo I hadn’t pushed to. So I jumped on the iOS team, trying to lead from the front. It should have been obvious at the time that I was just leaning on the same old crutch. But I was able to frame it internally as a leadership opportunity.
We built a great product (which I’m excited to be launching very soon) but this didn’t solve my “maker/manager” balance. It only exacerbated my use of code as crutch. The company didn’t need incremental product features, but that was the path I was on. Critically, I had to change course without a clear new heading.
what’s my problem?
Accepting that you have a problem is never easy. It was even more difficult in my case because nobody — myself included — identified my problem. Self reflection revealed that something was wrong, but I honestly had no idea what. I accepted that I had a problem without knowing was it was, and set off in search of it.
Identifying my problem — using code as a crutch — was much like a bug hunt. There was no eureka moment. I systematically explored options, eliminated the weakest theories, and cast a net as wide as I could. During one of my many conversations, Reece mentioned the idea of a crutch. Something in my brain connected that to the idea of code and I ran with it.
not exactly cold turkey
It’s been several weeks since I’ve gone heads-down in the code for more than half a day at a time. In fact, I’ve completely flipped my code to non-code ratio. It feels good. I’ve been reflecting on my role at Shelby and focusing more on the company. Compare that to the prior six months where my focus was nearly 100% in the code. It was the right thing to do; I built something great with my team. But while my head was down it was almost impossible for me to see anything else that was going on. That’s dangerous for a founder.
I still think I do an exceptional job of deleting email, turning off all notifications, and focusing on my work. The difference is, my work no longer consists of pure code. I spend a more appropriate amount of time thinking at a high level about the big picture, writing, and discussing these important ideas. Ironically, by not isolating myself coding on a focused area of the product, I’m able to stay more involved with the rest of team and what they’re building.
maker :: mentor — a work in progress
It’s an ongoing process. I’m working to become more of a teacher, which is incredibly rewarding. I’m allocating more of my time to design review, code review, pair programming, whiteboard sessions, and collaborative deep dives into bugs and/or curious technical events. For a while I was trying to find the proper “maker/manager” balance. That’s been replaced with a drive to find the “maker/mentor” balance (still has a nice ring to it).
I always start my days by attacking the highest value task. Although I’m most proficient with technical problems, they’re not always the highest value targets (and it’s easy for them to suck in the rest of my day). Some high value tasks lie outside of my engineering domain. So I work to eliminate tunnel vision and find a higher energy state beyond my local maxima.
Code still is my crutch, and probably always will be. I can live with that. Hopefully, by discussing it openly and remaining vigilant, I can prevent the next relapse.
