
Becoming a CTO - djug
https://juokaz.com/blog/becoming-a-cto
======
jgrahamc
I'm going to sound like an old fart, but it might be better to wait to write a
blog post like that after you've spent some time experiencing engineering
management in depth. It's very easy when capital is flowing freely and you've
managed a team of 5 engineers to think that it's always going to be like that.

Ever been through an acquisition where 50% of the team was to be let go and
you had to decide who and then tell them? Kill off a product after the team
had almost completed it? Perform a lay off when times got bad? Give a serious,
reasoned, estimated answer to the question (from the CEO): "How fast could we
rewrite our entire code base from $FOO to Java?" Fire someone 20 years older
than you and wonder quietly to yourself if he'd find another job? Manage more
than a handful of engineers? Figure out how to outsource part of your
development to India for financial reasons? Deal with a rapidly expanding
customer base with creaking code? Manage a multi-million dollar budget when
VCs _aren 't_ throwing money at you? Handle alleged sexual harassment? Spend
hours and hours flying from customer to customer to explain your technology?

The 'pick which technology' to use part is easy and fun. Now go make that work
in a real environment with real constraints.

My advice on becoming a CTO: learn how to write. You'll be spending a very
large amount of time communicating your ideas.

~~~
rootusrootus
As an old fart myself, and meaning absolutely no disrespect to anyone, I don't
generally think of small startup CTOs when I hear the term CTO. I think of
medium+ corporations where the CTO is at the top of significantly larger
personnel structure than a company with 10-50 people. In my experience a CTO
position at a small company is much more comparable to a mid-level manager or
director slot at a larger organization.

Again, not intending to disrepect anyone, but that was my impression when
reading this article -- I didn't feel like I was really listening to what my
idea of a CTO is.

~~~
jgrahamc
Yes, that's very true. Perhaps a good place to start is by not calling
yourself CTO.

~~~
AndrewKemendo
In that case there are no C level offices for startups because the CEO for a 5
person startup doesn't have the same responsibilities as the CEO for Leidos.

I think it's tempting for people to just say, well yes that's true, but there
is no great line that is crossed that makes the distinction obvious.

~~~
rhizome
It would be revolutionary for startups to start their org chart at the bottom,
rather than the top. Programmer and BizDev, who get promoted as the company
grows.

~~~
brianwawok
So you could get a job as Software dev 3 at Google for 250k, or as Programmer1
as a startup for 75k at a new startup.. why would you do the startup?

Let's face it.. title is one of the currencies of a startup. You want me to
work for below market wage? Sure. I want equity to profit if we succeed, and I
want a title that keeps me from having people hired over my head as we grow.

~~~
greenyoda
_" and I want a title that keeps me from having people hired over my head as
we grow"_

I don't think that just a title will protect you. If you can handle managing 5
people but don't have the skills to manage 50 people, it's not going to be in
the company's best interests to keep you on as the CTO. So you'll be offered
the following options:

\- Accept a demotion and report to the new CTO

\- Be fired from your job and get replaced by the new CTO

If the company wants to avoid this unpleasantness, they can call your role
something other than CTO, e.g., "Director of Development". Then, if the
company grows, they can either promote you to CTO or hire a CTO to be your
boss, depending on how promising you are.

~~~
esrauch
I don't understand what the advantage is to have a lower title in your
examples though: if you were CTO and someone gets inserted above you then your
choices for your resume in your two scenarios are (CTO, then Director) or
(only CTO, left company), which are both better than the two scenarios if you
didn't have the CTO title (where it would say Director only).

If your title is Director someone might reasonably even assume there was a CTO
above you at the tiny company, and you were a "director" or "vp" by being
actually the absolute lowest man on the totem pole.

~~~
rhizome
Title inflation is a thing making "CTO" almost meaningless, as documented
elsewhere. Technical cofounder skills are not the same as CTO skills, so
either they can be promoted into the gig when the company grows big enough to
need CxOs or they can hire someone with the experience, desire, or greater
aptitude.

~~~
esrauch
My latter point was that widespread title inflation has the property that if
you "defect" and don't have title inflation it has an actual negative effect
on your future employment since it is nearly impossible for a random observer
to know whether or not there was title inflation at your company.

As meaningless as "CTO" is, having a title worse than that could be seen as
non-meaningless as a _negative_ signal.

~~~
rhizome
I think "founding programmer" or similar would counteract negative signals. It
would certainly be more accurate.

------
dberg
"If the team wants to do TDD, or pair programming, or staging servers - they
get it all approved by the CTO. It’s up to him to consider the bigger impact
of those changes."

As a CTO, my team knows I do not need to approve what the team wants in
regards to TDD or how many environments they feel they need. We operate in a
mode of "do whats best" and engineers smarter than me sure as shit dont need
me to rubber stamp approval of writing unit tests. I absolutely create an
environment that encourages high quality products and a robust testing
process. How they accomplish that is up to them.

~~~
ethbro
I think the more abstract point the author was trying to make with that
statement was that teams should be allowed to define what they want to do,
_but_ the CTO is the one who should be keeping an eye on the impacts of those
decisions with respect to the rest of the organization.

A good CTO is a bullshit deflector. And sometimes that bullshit is in the form
of "Why should an engineer have to consider decades-long maintenance timelines
including projects he or she isn't even associated with?" Sometimes the CTO
needs to say "No" to a proposal, but the benefit to the engineer is the rest
of the time they're isolated from having to think about impacts they don't
want to.*

*All of this is only applicable to orgs past a certain size

~~~
dberg
Fair point. I initially interpreted it as overly draconian, perhaps
incorrectly.

------
ryandrake
> I hate environments where the technology department is simply implementing
> what was envisioned by others. It might as well be an outsourced development
> team because it becomes independent of the decision making process.

I'd argue that the technology department should be very independent and
empowered when it comes to the _technology_ decision making process. I'm less
convinced that that's true for the product decision making process. I've
worked in places where Product Managers and designers wrote all the
requirements and dictated the look and feel down to the pixel, tossing it over
the wall to developers to implement. I've worked in a place without
independent, dedicated product professionals, where software engineering
decided what the product should be. Both extremes have major weaknesses. You
have to find the right spot on the spectrum between the two that works for the
company and mix of talent you have. It's not all or nothing.

~~~
gxs
As usual, that gray area in the middle is where you find the right answer.

I am a product manager - I spend some days arguing, civilly but intensely with
the architects and engineering teams on what should be done and why.

This conflict - these "battles" so to speak, ultimately lead to the best
results IMO. I push for something, the engineers push for something else, and
in the end we end up building the best possible product for the customer -
it's both what they want and technically sound.

Keep in mind when I say this I don't mean an immature argument calling people
names etc. - it's intense but it's always respectable and all parties know and
recognize that the best idea wins - regardless of who it comes from.

~~~
ethbro
Absolutely this. The best decisions come out of "My gut reaction is X", "Have
you considered Y?", "No, I hadn't because it's outside my area of expertise.
What about X'?", "That takes into account Y; agreed, let's do that."

~~~
ryandrake
Just a nit pick. I think the good IDEAS can come from that process, but the
best DECISIONS come out of: "The data (from market research, A/B testing,
etc.) clearly show that out of X, Y, and Z, X improves our KPI more."

------
tensor
> “The CTO must protect the technology team from becoming a pure execution arm
> for ideas without tending to its own needs and its own ideas.”

As a CTO myself, I strongly disagree with this. Yes, a dev team needs to tend
to it's own ideas, but no, it shouldn't be making product decisions. You
should have product and design teams that tease out user problems and come up
with solutions. In that sense, the dev team does simply implement the ideas of
the company. They still make _technical_ decisions of course, but not product
or UX decisions.

~~~
dberg
As a CTO, I disagree with your disagreement :)

Engineers dont want a "script for implementation". They want to exhibit
autonomy and creativity to the product as much as everyone else, especially
product managers. I am not saying they should be product managers in a vacuum,
but every good CTO knows the value of ownership and autonomy of a product is
extremely rewarding to engineers.

~~~
typingduck
I agree with both of you and tensor :)

Having dedicated people understanding what users want, what competitors are
doing and what are the future directions of the market is probably necessary
and worth dedicating serious time to.

It is just how people organize teams right now that seems a little broken; a
Product Manager and 'their' team. This leads to the Engineers who like to
innovate becoming bored and finding smart ways to get out of the 'typingpool'.
This innovative talent is really necessary to scale product teams though, e.g.
spotting common patterns across code bases. With that loss in innovation
companies suddenly find a comparable feature that took 2 weeks taking 2
months.

Also as technology evolves new features previously impossible become possible.
A Product Manager probably will not see this.

Perhaps there is a more 'ownership' heavy way of organizing Engineers.
Something a bit more democratic like having a pool of ideas coming from
Product Designers and Engineers. Self forming teams can come together to
deliver whatever motivates them.

~~~
ryandrake
1\. There's plenty of room to innovate on the implementation side. PMs don't
tell you what algorithms to use or how to lay out the data in memory.

2\. Not every engineer yearns to be a Product Manager. Sure, many want to make
product decisions but don't want to do the other necessary work that comes
with the role (like market research, metrics and analytics, managing the
schedule and budget, writing PRDs, communicating with customers and partners,
dealing with Legal, making sure the user manual is accurate, coordinating
releases with ops and tech support, etc.) I think some techies think being a
PM means merely sitting in your cube dreaming up a feature and saying "This
Shall Be".

3\. Good PMs most definitely need to stay on top of technology as it evolves.
They need to know their platforms' capabilities and when new things become
possible.

~~~
dberg
1> Yes there is plenty of room to innovate on implementation, but they still
want input to the scope of what they are implementing.

2> Nobody is saying they should be product managers, I am just suggesting they
want more direct input to the shape of the product itself (not suggesting ALL
engineers either)

3> Agreed, and PMs should continue to be good at this, its a core part of
their role, understanding the ecosystem

------
devy

       Being a CTO doesn’t mean you are the craziest hacker on the team. 
       In actuality, writing code is probably the last thing you will be doing.
    

Not entirely true. This is a typical "You Mileage May Vary" scenario, in
actuality. From all the small startup teams (headcount less than 15) that I've
worked at in the past decade, CTO must be the role who leads in coding - in
almost all the cases the first version of the software product was 100% done
by CTOs because small agile teams don't have the luxury to be managing instead
of doing and EVERYONE (even CEOs) wears a lot of hats.

After bootstrap and rounds of fundings, things will change for sure. But CTOs
at very early startups are definitely more about doing less about managing
IMMO.

~~~
67726e
I don't think this is a YMMV, but rather we're all lacking a proper,
consistent definition of what a CTO is and does. Many in the the comments are
coming from the idea of a C-suite officer of a large company, which I think is
proper. I think a lot of the use of CTO / VP of Engineering / Director at a
lot of startups is just some ego-stroking type behavior. Your claim of being a
CTO at a 10 person startup is not likely to be getting you a job as a CTO of a
mid-market firm because you're not really a CTO, you're some kind of architect
at best.

~~~
devy
The definition of CTO is evolving as the company evolves. The same company at
different stages requires its CTO to be in different role, as you mentioned
CTO in a 10-person startup is a different role than a CTO in Fortune 500
company.

~~~
67726e
For the purposes of discussion, we will not get anywhere fruitful if we say
"Oh, it can be anything you want it to" \- again, I contend that a CTO at a
10-person startup is not an actual CTO but some kind of team lead / architect.
It's a pointless name as it does not convey what it typically does and serves
only to act as some status signal.

Instead of saying "The definition of CTO is evolving" which is rather
contradictory, a definition to make something distinct and clear, it would be
better to frame it as that person's role is evolving, and that their title of
CTO is not indicative of their actual role.

------
oswamano
"If you ever find yourself writing a blog post on why PHP sucks, you are not
ready."

About 4 articles down the article is about why PHP doesn't suck. This amuses
me for some reason.

~~~
KirinDave
It's amusing because it's absurd. CTOs write articles about technology choices
all the time, and sometimes its even tactical.

If I thought slagging PHP in a blog would get us more hires, I'd do it without
hesitation.

~~~
CorvusCrypto
I can't for the life of me think of a reason this kind of blog post would make
me want to join a company. If anything it shows the opposite quality of a CTO
as mentioned in the article. Use what is suited to your needs, don't worry
about appealing to the tech crowd. After all, even if PHP is shit, it's not
your problem. Let us handle implementation of what you need, we will (or our
lead dev will) help you understand pros and cons to certain technologies.
Besides, for every article written about why PHP sucks, there's at least 5 PHP
devs looking for work :P

~~~
KirinDave
So... are you asking me for examples of CTOs of successful companies who have
written tech articles promoting one type of tech because another is bad?

I can do that, if you really couldn't do it yourself. It's not uncommon at
all.

Like I said, I don't do it because I don't think it would help. But in some
cases, it can definitely help. How many startups use their dedication to a
specific (incrementally more modern) tech stack as a perk while hiring? Quite
a few, and these often have subtly disparaging remarks baked in. And I've
absolutely had success hiring and growing my team by explaining why we use
Clojure over stock java whenever possible.

~~~
CorvusCrypto
Nah not at all. But I am saying that it's not gonna sway my decision when you
bash a technology amidst many other companies that have successfully used the
same technology. It just shows a lack of vision imo. My comment wasn't
targeted at yours specifically, but was a follow up on the topic.

and imo explanation of why you use one technology over another is not equal to
just a "PHP sucks!" blog post.

------
codesnik
Being CTO/CIO twice in my carrier, being protector of my small dev-realm
almost fulltime, I completely agree with that article! so, probably it's wrong
somewhere.

------
jconley
Matt Tucker wrote a little blog [0] about being CTO. He went from co-founder
to public company CTO over 15 years...

[0] [https://www.linkedin.com/pulse/five-flavors-being-cto-
matt-t...](https://www.linkedin.com/pulse/five-flavors-being-cto-matt-tucker)

------
0xmohit

      Sometime down the road legacy applications become expensive to
      manage, but rewrites almost always deliver zero value to the
      customer. It’s about balancing development efforts.
    

Well said. What is the guarantee that the rewrite would be relatively free
from technical debt? I've seen several 100K lines of code being produced in
rewrites that add absolutely no value -- neither in terms of performance,
reliability, maintenance or even code readability.

~~~
ethbro
I think there is some value in "someone who has spent billable hours deeply
touching the currently running system is still employed at the company." You
can have maintenance updates & docs as numerous as you want, but I'd still be
terrified of running a production system I don't have trusted nuts-and-bolts
expertise in-house for.

------
agounaris
Juozas Kaziukėnas is a good conference speaker. And as a good conference
speaker oversimplifies some things to sell himself.

Being a CTO also means that "age" matters. Not because you are not smart but
because you haven't worked with people enough to become a CTO. A person on his
20s or early 30, maybe has lots of technical experience already but definitely
not the social skills to lead an organisation.

I remember I was interviewed once by a 25 years old "CTO" in a suit and really
it was a nightmare!

> I’ve sat in a few roundtables with fellow CTOs: This is kinda of what I
> don't like. We the "CTOs" gather to say "our" things and write blog posts
> about it.

------
ben_jones
As a CTO of a small start-up my neck is a little strained from nodding so much
at this article. I really agree with... sorry I have an email with our largest
customer to get back to.

------
joshmn
> “Why are you stuck with this old version, why haven’t you rewritten it with
> React.js?” Sorry to burst your bubble, but that’s not a great idea. Sometime
> down the road legacy applications become expensive to manage, but rewrites
> almost always deliver zero value to the customer. It’s about balancing
> development efforts. Building a team of people who only want to touch the
> freshly baked technologies is not sustainable.

I wish more people would realize this.

------
a13n
> but rewrites almost always deliver zero value to the customer.

I disagree. Sure no immediate value, but in the long run? You could argue
certain rewrites would mean faster product development, less bug proneness,
happier developers. All of these deliver value to your customers.

~~~
xtracto
Depends on the size and reasons for the rewrite. I am Director of Eng. at a 85
people startup (funny how that sounds), and last April we released "version 2"
of our platform/website [1]. We basically threw away a huge chunk of the code
that was developed by the technical founder, myself and another dev, and
replaced it with a fully scalable architecture.

When the company I work for was being started, a technical advisor (who had
sold his company months before) told us not to worry a lot about the first
codebase, because we were going to throw that away after some time. I am
deffinitely sure even what we have now, will get obsolete in a couple of years
(two at most)

For this reason, I think having a good planned rewrite (even if it is
underestimated) can be good. I think the important part is understanding _why_
the rewrite is performed, and be sure that it is done for the right reasons.

    
    
      [1] http://nerds.kueski.com/the-path-to-kueski-2-0/

------
CorvusCrypto
So then would the true top "Engineering" role just be lead dev? This is the
role I am more interested in. Having to keep up with the state of the field
_to me_ as an engineer/CS is A: more fun, and B: more rewarding.

If anything this blog post (along with others) just keeps confirming that CTO
is something I never want to be.

Edit: I should also mention that it is practice at my current company that our
leads basically are the ones that consider the balance of implementation
details and whether we do rewrites vs. staged refactoring. Not the CTO. This
definitely seems like more of an engineering call.

~~~
ThrustVectoring
Even if you don't want to be a CTO, you're better off knowing what the CTO
role does. Part of how the World War 2 era German military worked was the idea
that subordinates would understand how to do the job of people two levels
above him, so that he could understand the intent of the orders he received
and carry that out rather than the letter. If you also want to have high
levels of autonomy, you need similar abilities.

~~~
CorvusCrypto
Irrelevant to what I asked. I understand the role. And I can safely say I
don't want it. What is the top engineering role?

~~~
dejv
Lead developer, architect, senior developer, fellow... it depends on company.
It could be also CTO in some cases.

------
tboyd47
If what it takes to become a CTO is understanding all of this, then I'm ready.
The only problem for me is that I'm not one. Oh well, back to refactoring unit
tests.

------
deedubaya
This article hit too close to home. It hits a lot of points which are all-too-
true about many CT positions and how if they're not set up for success, how
can the engineering team (and eventually the rest of the company company) also
possibly be successful?

------
tscosj
I hoped to get some real-life experience from the blogpost, literally blah
what I read. With all respect to the author, though. I have no idea how that
sort of posts are taking higher than 250 points nowadays. That's the question.

------
miles_matthias
Love posts like these. My friend & I started a podcast to help engineers learn
from other CTOs.

Check out StartupCTO.io. Would love any feedback here or on Twitter
@startupctoio

------
nstj
> I’ve sat in a few roundtables with fellow CTOs

"Sorry guys, the event for tonight is cancelled, turns out the tables we were
to sit at are rectangular."

------
scient
This guy gets it.

