It took a while for snipe to convince me to come on as Chief Technology Officer (CTO) here at Grokability. One of the biggest hurdles was the fact that she and I are married. I was convinced that, not only would that be a challenge, but that might spell the end of my career – I didn’t want to be the guy who could “only get hired by his own wife.”
It took her a few years to be able to convince me. I told her my concerns and she responded, “Why don’t you work with me to build a place where that type of thing doesn’t even matter?” I told her – “that’s a great line,” to which she immediately responded, “it’s not a line.”
So that was what put things over the edge for me, and allowed me to make the decision. I mean, the chance to work with a brilliant CEO and with a great team at a place where they were treating people ethically, kindly, and well-compensated – that was part of the decision as well (and something I was eagerly looking forwards to). But that one “line” was the one thing that made me make the decision.
But I’ve been at this gig for two years or so. Why write about it now? Well, it’s taken me some time to figure out what my role entails – I mean, we can pretty easily Google “what is a CTO” and see what it entails, talking about setting technical direction, blah blah. But what does it actually mean?
Early on, I reached out to Charity Majors, who has written a lot about the natural manager/individual contributer (IC) swing – and it’s very important reading to any kind of senior technical person. She says it’s good to flip back and forth from IC to manager – experienced managers make good IC’s, and experienced IC’s make good managers. I figured she might know a little bit about the executive version of those types of swings, especially with her having just recently switched from CEO to CTO over at Honeycomb at the time (which is great tech, and we use it.) She confessed she didn’t have a good answer for me. So, thus another reason for this post.
One of the reasons jerm (who works with us now, but I used to work for him at Nylas) was excited to get a manager role at our old job was that he wanted to be “in the room where it happens.”
(And btw, he can sing just about every role in Hamilton, in fact, infuriatingly so.)
I was lucky there in that as a relatively senior level Site Reliability Engineer (SRE), I did have quite a few great seats at various tables, and was able to give input. And that input was taken very seriously, and was listened to. That’s exactly what Charity was alluding to, in fact.
But I started to feel like that wasn’t enough for me. Having a seat at the table was great! It was! And there was no lack of respect or anything like that. But in the end, I wasn’t the one making the decisions. And while some of those decisions were ones I wanted us to do, some other times other choices were made. Not bad ones, mind you! Just different ones. Typically pushing through bigger ideas was harder than smaller ones, but that’s pretty standard in any organization.
Having those final decisions to make has been the hardest job, where I’ve made the most mistakes ever. That’s because every time you choose to do one thing, you’re explicitly not-choosing to do a bunch of others. I’m still kicking myself in the head over some calls I made here early on that I’m still dealing with, in fact. But decisions do need to be made and I made them – and not every call is going to be perfect. That’s life.
I know one I’m kicking myself over is that, right after I finished our “env-var override” system, which allows our support technicians to override the environment variables on a hosted instance, I knew that the next system I should build was something similar – almost identical – but for cron job settings. But I didn’t.
Not only did I not do it, I didn’t do it for the worst reasons: I was just lazy. I didn’t feel like it. I just did a big push to get my env-var override system pushed up (and instrumented). And now I just had to repeat the same, exact process, but for scheduled tasks. But I didn’t. Just because I didn’t “feel like it.” Big mistake, and it’s one that continues to pay dividends – or, in more difficult (but true) terms, costs us more, over time. That one comes to mind immediately, but I’m sure I could come up with another few handfuls of other poor choices if I had the courage to look. And that speaks next to “what should we be looking at?”
I’ve long known about the idea about a simple two-dimensional matrix that you can use to think about decisions you can make – one axis, you have “Urgent/Non-Urgent” and on the next axis you have “Important/Non-Important.” (I only recently found out that this was called the “Eisenhower Decision Matrix” shown above. Thanks, Ike!) My take on this is that the urgent stuff tends to solve itself – your engineers can tell what’s urgent or not and can tend to get it fixed or built or whatever. “Important and not-urgent” is where a lot of real thorny issues go to die, and that can build up technical debt.
But I think there are actually two more dimensions, so now our matrix is actually…some kind of hypercube or something? Because the new dimensions I propose are “is it interesting or not?” And “is it hard or easy?” And much of where technological leadership and execution falls down is on the wrong side of those additional axes.
Still, just like before, stuff that’s not important and not urgent is probably a good candidate for things you should just simply not do, whether interesting or not, or hard or not. But what about important, non-urgent, hard, and uninteresting? That stuff can end up being really pivotal for your company’s success, but might have a hard time getting your people to volunteer to get those things done.
And that’s a lot of the job! Getting those important things done that hit some of the harder parts of the hypercube (uninteresting, and/or hard). And sometimes, getting your people to not do unimportant but still interesting work – Engineers usually like interesting work 😊
And at a small company – especially one like Grokability where our management philosophy is “shit rolls uphill”, it means that sometimes that it’s me who has to do some important stuff that isn’t interesting. All jobs have that! I’d much rather do job myself until our team can figure out how to automate me out of it. A lot of times the automation part is actually interesting (but sometimes also hard)! So you’d be surprised how quickly your folks will jump out of the woodwork to help automate you out of some drudgerous task.
So that’s my take. All of that standard CTO stuff that people say is certainly true. Knowing when you have jobs that need to be done and getting the right resources to do them, that’s important. Technical tone and direction, that’s good too. But being there for your teammates and making sure important stuff gets done is the main bit, whether it’s urgent/non-urgent, interesting/boring, or hard/easy.
