5 Skills You Need To Develop To Be A Better CTO

The other day I was interviewing a candidate for one of our open Ruby positions. It was mostly uneventful but at the end of the interview he asked me something I’ve never been asked before in an interview.

What advice can you give a junior developer like me to progress in my career and maybe eventually become a CTO like you?

It caught me off guard and in retrospect it might have been an attempt to stroke my ego but that’s not how it felt to me at the time. I’m used to questions about the team, the company’s structure and funding, the role, etc. The questions tended to be about the business and our process but this one seemed personal. I felt unsure and embarrassed to give an answer — oh hi there imposter syndrome, good to see you again.

It’s also a pretty smart question from a candidates perspective! I mean you’re going through this annoying process anyways and things more often than not don’t work out — why not squeeze some extra value out of it along the way?

Whenever I get questions like this I try to reflect on my career and I frame the response as what worked for me and where I should have done better. That’s what made it feel personal. It’s the advice I’d give to my younger self if time travel were a thing yet. After some stumbling and rambling on probably longer than the candidate wanted me to I realized two things:

1. I actually do have some advice to give in response to this question — cool!
2. I should probably organize my thoughts a bit and write this down so I ramble less next time I’m asked. Better yet I can just point them here.

That said, on to the list…

Never Stop Learning

This one was easy for me. I’ve always somewhat lived and breathed technology in general, not just software engineering. I read tech news, blogs, and opinion pieces pretty much every night before I go to sleep. Strangely it’s what helps me unwind. I find it hard to go to sleep without doing this ritual. Maybe it’s an addiction…

I’m not saying YOU have to do that or do it that way but you should certainly have an appetite for knowledge and always be striving to grow. The best engineers I know are always learning, tweaking, and asking questions.

No, I’m not saying you have to do this all the time like I do or even use any of your free time for it. Carve out some time each day at work if you can’t outside. I would never knock my employees for that, ever. On the contrary I’d encourage it. If your manager views this as slacking off, maybe find a new manager?

Also try learning other things besides just technical and programming concepts. Being well-rounded will be hugely important later on in your career. Try to shore up any areas you’re weak in. If you don’t think you have any it’s time to do some reflection — you almost certainly do!

Get Involved (Early)

Pick a technology community and get involved. The earlier the better. Ideally you can use what you’re learning to make a prediction about a technology or a project you feel is at an inflection point and about to take off. 🚀 It’s the same thing you’d try to do when picking a company to work for. Nobody wants to hitch their wagon to a sinking ship…

For me, this was Ruby on Rails. I did OK getting involved in the community over the years but I certainly could’ve done more. You should do more.

Assuming we’re talking about OSS, see where they need help and start contributing. Even if it’s just documentation — that’s some of the most important work a community can do for a new project. Pick up issues from their issue tracker and fix bugs. This can be daunting at first but assuming you picked a non-toxic community, they will appreciate the help.

Start hanging out wherever the rest of that community is online — Slack, IRC, Gitter, whatever it is. Try to be helpful to other members as much as possible. If there’s a #help channel, then jump in and #help. Contribute your enthusiasm and positivity back to the community.

Assuming you got in early, you will be helping to shape this new community. Don’t be an asshole. Don’t berate newbies for asking newbie questions. Don’t tolerate intolerance. Don’t be that person.

Newbies gonna newbie. Let them!

This helps build and grow your network and lets people know who you are.

Hit the Conference Circuit

The next level of involvement! As this community begins to take off there will be conferences about it — there are always conferences. Go to them! Especially early on before things get cliquey!

This can be hard for software folks. Many of us, myself included, are natural introverts and attending a conference can be scary and feel like work. The fact is, it is work. You’re working to set yourself up for future success and networking is essential to that success.

I suck at this. You need to not suck at this. Getting in early helps because it’s less likely everyone will already know each other so they’ll be more open and eager to meet people. Some conferences do a better job than others at facilitating networking. If you aren’t early there’s still hope — some established conferences have special assistance via guides or mentors specifically for new attendees. Try out the smaller, regional tech conferences too. Many times they’re better than the main national conference!

Public Speaking — It’s a Thing…

A sad fact that I wish someone had drilled into my head early on is that eventually you will need to get comfortable with public speaking. #shock and #horror I know. Trust me, I feel you on this one and I’m still terrible at it…

Whether it’s giving an update to your growing team or presenting new features to your growing company or doing a quarterly review with your board, you won’t be able to escape public speaking forever. Not if you truly want your career to progress.

But guess what, the sooner you start practicing the better you’ll be later in your career! Don’t push this off.

The only advice I have is know your shit better than anyone else and don’t memorize it. The only thing that’s ever helped me is to feel confident that nobody in the audience knows more about Subject X than I do at that time. Even then it’s still fucking hard.

Start small and work at it. Do tech talks at your company to your peers — these are people you know so this should feel more comfortable. Give short presentations at local tech meetups. Parlay these into longer, more in depth presentations. This will transfer nicely to the other types of public speaking you will eventually have to do in your career.

As you get more and more comfortable and confident, or if you’re just a natural at public speaking (#envy), submit your budding presentation to a CFP at that larger conference you’ve been attending. This will have a disproportionately large impact on your career if you can pull it off. I never could…

Don’t Neglect your “Soft” Skills

Public speaking is just one of many “soft” skills you will need to nurture and develop as your career progresses. Your technical skills are obviously important but eventually they start to become of secondary importance to these other skills.

You’ll need to be an effective written and verbal communicator (public speaking can help with both of these). You will need to understand people and how to effectively lead a team. How to persuade co-workers in other departments when needed. How these interpersonal relationships work. Navigating those murky waters is one of the biggest challenges for many engineers.

You will need to understand general business and accounting concepts, how your business operates, what marketing is, how it’s different from advertising, how to sell, venture funding, fund raising, and the list goes on and on.

I don’t know why these are called “soft” skills since these non-technical areas always felt more challenging to me. They’re not as natural for me. My love of learning has helped me since it applies to more than just technology. I personally enjoy reading about a fairly wide variety of topics.

Don’t wait until you’re trying to transition. It will be far too late by then. Hopefully that hunger for knowledge you developed will help you branch out and master these other areas effectively too.

Whew! This is certainly not an exhaustive list. There are many other important skills that an engineering leader or CTO must master. But that’s more or less the advice I gave the candidate that day— minus some of my stumbling and rambling. I hope it helps him and maybe, just maybe it can help you too.

At least I know it would have helped me!