Ask HN: Have you known any devs that become great CTOs with no leadership exp?

[volkk]

Have you known any devs that became CTO at early stage startup and grew to be REALLY good at their roles?

I feel like it's a trend for young inexperienced first dev hires to become CTO as a cool title, and eventually get ousted for a really experienced one once the company got big enough.

Curious to know how to effectively grow as one and really become amazing at the job

[ramtatatam]

Until the point the company you work for makes millions or hires more than 1000 CTO is just hype title (of course some CTO's will argue). It's business role, not tech role. If you think CTO is tech then you are thinking tech leader, not CTO... I have had the privilege to see real CTO at work, he was leading organisation of 100000 tech employees. From the perspective of time I can tell you that at the time I did not understand a thing of what he was doing and in my lack of humbleness I thought I knew better.

As business role you need business skills, but above all experience and connections. You won't learn how to deal with people or make good connections by writing lines of code, you have to manage people to acquire this skill. And on this level you have to deal with politics and I believe this is even more difficult to get right...

[username90 → ramtatatam]

Sounds like you are talking about how to get and keep a CTO position and not how to do well in it. I'd argue that the most important role for a CTO is to shape the engineering culture.

A famous example is Jeff Bezos mandating that teams expose their interfaces via externalizable API's, he was a CEO but this was definitely a CTO move. He wouldn't have been able to make this mandate if he wasn't a good engineer himself, and that mandate lead to AWS which is where most of their current profits comes from.

I think this is why founders are so important and why big corporations will never be able to compete with startups, people who are better at solving problems than playing politics will simply be unable to climb the corporate hierarchies so they will only lead companies as founders.

[ramtatatam → username90]

'Sounds like you are talking about how to get and keep a CTO'

I'm not sure where did you get that conclusion from, care to elaborate?

[davismwfl]

Yes, you can do it, the key is recognizing your weaknesses and that at some point you will cease to primarily be an active engineer (meaning you won't code day to day etc). Great CTO's always remain very technical IMO, but they have to develop a whole new set of skills. Most of the time you will find it is hard to scale yourself fast enough if you are on a rocket ship, so the key way to remain CTO is to hire for your gaps beyond just engineers, hire product people, hire project managers, hire an ex-CTO that wants to mentor and play a role less than the CTO.

I have been a founder prior and I have been a CTO for different companies as well as a Chief Software Architect at GE (essentially a large project's CTO where my staff was over 130 people). Being CTO is hard to do well, and depending on the organization it can be downright the most stressful job. It also can be the most rewarding and fun job, so I definitely love it.

Some things I recommend (you probably already have some just listing things that pop into my mind) and this is by no means comprehensive:

1. Always make yourself redundant in all the positions you move through on the way to CTO (that's how you will be one).

2. Find a good mentor who can help you and will be painfully honest with you. Find this person hopefully before you are the CTO, that way they can help guide you on the way up.

3. Learn to take feedback across the board. Don't ignore the mentors advice and be careful not to ask 10 people for advice as at some point it becomes noise and you won't make a good decision.

4. Learn to make decisions with less than the full picture, and live with the consequences. And accept you need to change the decision or reverse course and that's ok, don't live with a bad decision when the facts show you made a mistake, correct and move forward.

5. Say no often. Learn that the business goals/needs comes first, not fun cool new technology. Of course, if the business is to develop fun new tech that's cool too.

6. Learn how to work with all types of people, this can be hard but it is absolutely required because you need diversity and you need to hire different skillsets other than just engineers as a CTO.

7. Learn to speak business, this is a fun challenge if you don't know already and it is immensely helpful.

8. Learn basic accounting so you understand why things are being asked of you sometimes. This also makes you far more valuable to the organization and in the future.

9. Learn to scale the organization, this is trial and error to some degree if you've never done it before. Hiring and team structure can be hard, experimenting and taking team feedback is how you succeed.

10. Respect your weaknesses and find people to compliment them. We all have weaknesses, respect you have them, acknowledge them and hire people to balance you.

11. Hire people that disagree with you. I don't mean hire assholes, but hire people who challenge your way of thinking, that force you to make better decisions.

12. Learn how to manage products, read some books on new product introductions, processes and find a product mentor. Product is what is important, not whether you used framework A or B, but you need to balance all that, so understanding product is critical to success.

FYI: I am the CTO of a backed healthcare startup.

[jaredsohn → davismwfl]

> Respect your weaknesses and find people to compliment them

Your spelling skills are amazing. :)

[davismwfl → jaredsohn]

That's awesome. I screwed that one up, my bad. :) Complement vs compliment, just a slight difference.

[Mockapapella → davismwfl]

Wow, thank you for such a thought out response.

> 7. Learn to speak business, this is a fun challenge if you don't know already and it is immensely helpful.

Could you please elaborate on this point?

[davismwfl → Mockapapella]

Business has a vocabulary all to itself and understanding it and what things truly means is important, e.g. understanding what EBITDA is and how you can directly affect it this quarter to help meet a goal. But, whether it is around accounting, contract terms, vendor management, people issues or marketing there is a unique language that keeps businesses running. I've been around CTO's in the past that would complain they felt excluded at the executive level but also readily admit they didn't understand what the CEO/CFO or other execs were really saying in meetings.

CTO's/CIO's in the past have had a hard time getting a seat at the "adult" table, being typically seen as just a tech person and not a "real" executive. The importance of CTO's is no longer in doubt but people filling the role do themselves and everyone else a huge disservice if they don't become business intelligent.

Hopefully that helps, if not let me know I'll try to elaborate more or maybe differently.

[croo → davismwfl]

Could you elaborate on why you find it the most rewarding and fun job? What are the rewards and what makes you feel like "fuck yeah this was a good productive day"?

[davismwfl → croo]

There are quite a few for me personally. But a few of the top ones:

1. When I am helping the team or especially an individual succeed at a task and move forward. It is when you see that lightbulb go off in someone when they are learning something new, or have been struggling and you can help them find the path to solving it. What is rewarding here is it is impossible to always know the answer, but the person working the problem usually is the most likely person to solve it and so just through talking it out, working together a little, asking questions and challenging them they find answers most of the time which is rewarding to me. Mentoring to me is probably one of the most fun aspects, and rewarding. This can also be the most frustrating situation when you are dealing with someone that is a negative individual and struggles to see that issues are just opportunities to learn or improve.

2. Finding a win-win solution to a task or issue. Whether that is an engineering challenge that has been raised, or it is a people or client issue where you find a solid win-win. Those are great, cause they don't happen everyday, so they are rewarding when they do.

3. Seeing the product actually making a difference, knowing choices we made, things we did impact people. In the place I am now, that is patients being helped given we are in healthcare, but in the past it has been saving a client a particularly large sum of money through our products or services, or making the client money based on the same. I think a lot of engineers (especially newer engineers) miss this aspect because they get so hung up on the technical details or implementation they don't understand the product itself (yes they can tell you what it does but they don't truly understand it). One of the key things I always strive for is making engineering aligned with the client, because when you can feel the pain the client feels, feel the benefits they feel, you will make better choices and be a better product engineer. Isolating engineering from the client/product is always a mistake IMO.

The theme here is I do love the team building and people side. My viewpoint on leadership is that a leader is the support person for their team, they are in front defending their team, leading the team, take responsibility for the mistakes but passing on the credit to the team and at all times support the team regardless of what that entails. If I need to get people food cause they are tackling a problem, then that's my job, if I need to get them the right tools to get their job done properly or make it easier, that's my job to find a way to get them what they need.

Don't get me wrong, I am a die hard and love solving technical problems and generally prefer to work on product, but as a CTO or similar you have to pull back and do what the organization needs at the stage it is in. You should always drive engineering excellence, but you shouldn't be driving day to day decisions/execution unless the company is very small and you are still having to play architect, coder etc. Once you have team leads and teams, you should be pulling back and setting direction and standards but not dictating implementations etc. That is IMO where most people struggle and fail to grow, which leads to them being replaced by a more experienced CTO.

As with everything, there are exceptions with some CTO roles, but IMO this is the way they should all be.

[CameronBarre → davismwfl]

>You should always drive engineering excellence, but you shouldn't be driving day to day decisions/execution unless the company is very small and you are still having to play architect, coder etc. Once you have team leads and teams, you should be pulling back and setting direction and standards but not dictating implementations etc.

I'm going through this on a smaller scale and have been evolving through my responsibilities for around three years.

I started as the only engineer with total control over a next generation system for a client, then for the last year and a half I have been making the painful transition from solving problems myself to trusting others to solve them.

I've grown a small team from nothing to three highly reliable members by doing much of what you suggest and following similar themes.

My responsibilities have been partitioned among them, group methods and practices have developed between us all, and finally, there is a capable group of people to carry on and evolve my hard work, which is now becoming their hard work. One of the best parts is that they actually produce higher quality work than I do, because I create buffers from business pressure and give them longer runways, so there is more time for attention to detail.

I'm in the process of handing over my duty as team lead to one of them and I'm pushing my way into helping our CTO with product design (and essentially anything else that comes up), where I hope to leverage my understanding of our various teams and business context.

I am evolving my role for the third or forth time by now, and I am doing it out of necessity, because, every hour of my time typically goes toward controlling dozens of hours of other people's time and so without an engaging task like writing code, my days feel endless, because there isn't that much I can do at any given moment. Jumping into my teams code and working on requests directly is actually one of the more self destructive things I can get into lately.

Therefore, I find product design highly engaging, it makes the hours fly (almost as good as writing code) and am sending the message that I'm here to help at a higher level than I ever have previously - apart from growing half of the environment for three years.

I don't even want a career by the way, I'm a remote 1099 freelancer if you can believe it. We have a really interesting team composed entirely of freelancers, but we seem to stick together.

[davismwfl → CameronBarre]

That's awesome, and also IMO one of the hardest transitions to do because it feels like you go from being productive most days to having weeks on end where you aren't sure you can point to one thing you "accomplished". Yet, your accomplishments are the teams accomplishments if you are supporting them etc. So you have accomplished far more than you would've have by yourself but it sure doesn't always feel that way. :)

Congrats on finding a way that works for you. To me 1099 vs employee is a payroll not capabilities or contribution distinction. I am 100% remote from my team right now as well, if you can work with people it is not really any different than sitting in an office for most of what we do. With all the collaboration tools anymore, designs can be shared online, Zoom meetings make things easy and Slack etc give you that real-time quick connect when you need it. IMO hardest thing to manage remote teams over is delivery expectations and timelines given people spread across timezones can cause delays just because of their hours of work if you don't plan well.

*edit - word

[CameronBarre → davismwfl]

So true.

Thanks for the kind works :)

[adonnjohn → davismwfl]

Any tips on do's and don'ts of #1?

[davismwfl → adonnjohn]

#1 starts with not doing the same thing multiple times needlessly (so automate), then it is about mentoring others to do your job (and in general), plus being 100% transparent about what you are doing. Part of mentoring IMO is also raising your hand to help someone else that needs it, but still making sure you deliver on your commitments.

People that hold onto information to try and keep their position are the exact opposite of this idea, probably everyone has worked with someone like this. The dude that "hides" credentials, or says he'll do it cause no one else can etc.

You want to share everything you know and be transparent. It scares some people because they fear they'll be replaced if they do this, but the reality is you can't move on to the next level unless you've made yourself replaceable.

I don't honestly think it is more complicated than that to be fair.

One other nugget to all of this is you have to trust others to do their job, and when things break you have to take responsibility and help pick up the pieces even if you weren't the reason it broke. I think most good people take responsibility, but I know a lot of very capable and intelligent engineers that will never lead a team or be a CTO because they have the complex that only they can do a job correctly. We can approach a problem 2 different ways with tradeoffs each way, but if I am the CTO/director etc and I give you a project to do, along with some direction of course, I need to trust you (assuming you can defend your solution fairly) to do the job. A leader can't micromanage and succeed long term, it just doesn't work. And that is all part of making yourself redundant in my view.

[bwb → davismwfl]

Utterly fantastic reply!!!! Thank you :)

[raveenb]

Politics first, business next and then tech, and in that order is what you need to master. I have experienced it first hand, I was not ready for the first skill fully, takes a while for techies to warm up to it.