
Ask HN: CTO with no experience, how do I make my first technical hire? - questifer
A year ago I co-founded a company with a classmate (both non-CS students). I knew the basics of building rails web applications from teaching myself during the evenings and weekends and could somewhat navigate myself around a basic stack (AWS, Rails, SASS, Salesforce etc.).<p>We&#x27;re launching our beta in several weeks and are about to close our seed round. I&#x27;ve relied heavily on SO, tutorials and  gems to get our application to where it is today. I&#x27;ve never had anyone review my code. I&#x27;ve taught myself how to use a continuous deployment flow, write tests, design and integrate REST APIs like Salesforce and Docusign.<p>With our funding, I need to begin building a technical team. One thing I&#x27;m concerned with is bringing on a developer (senior, full stack, or backend) that won&#x27;t respect me as a programmer. The work I&#x27;ve done to this point has had the aim of reducing the time to goto market and cost- quality has taken a hit to meet those two goals.<p>As a CTO with no computer science background and no previous experience programming at another company, what role should I hire for first? And when I do, how do I &quot;manage&quot; that individual if they don&#x27;t respect the work I&#x27;ve done as a programmer?
======
kashif
In my opinion you shouldn't be a CTO but a founder. I don't think any serious
tech team can respect a technically inexperienced or poor CTO for long and
this will cause problems later.

It might be a better idea for you to go for a Chief Product Officer or just
Founder and hire someone experienced to do the CTO role.

If you think you can lead from the front without being competent in a subject
- you have another thing coming.

~~~
suyash
+1 hire an experienced CTO/Sr. Tech Leader first and then all your problems
will be solved.

------
albrtpro
Hire a Lead Dev before you hire engineers/programmers. You'll save SO much
time and headaches.

I summarize here what I expect from Lead Devs:

\- A lead knows how to architect solutions. Not just code them.

\- A lead talks higher level than programmers/engineers. You don't want to
hear code, you want to hear solutions/implications + pros/cons.

\- A lead is interested in the interconnections with other systems, and
doesn't overlook them.

\- A lead has experienced a range of advanced problems (optimization, weirdest
bugs, scale)

\- A lead is able to recognise and be interested in the problems he hasn't
come across yet, and has the will to tackle them asap if they are a priority
for business.

\- A lead has a quite deep understanding about the full range of solutions
available to solve a problem on his platform. And he spends time on this
daily, ideally because he's passionate about it (never seen it other way)

\- When you ask a lead how to solve a fairly open engineering problem he'll
come up with 1) A good range of approaches 2) Pros/Cons for each of them 3)
For each pro/con advise based on his experience.

\- A lead has confidence when taking a decision on architecture, he
investigates the impacts beforehand. If he's wrong he recognises it.

\- Ultimately a lead should be able to come up with a plan to help you
refactor any mess with the lowest impact possible in the product. Ideally
building the new on new refactored structure, and re-factoring the old by bits
when maintenance is needed on those sections (low-budget approach..)

A lead will help you spot other good devs, including other platforms leads.
From there, hire engineers who follow the Lead!

~~~
codeonfire
These are all things any engineer should be able to/ does do. The title "lead
dev" sounds like marketing.

~~~
albrtpro
Based in London, where Lead Dev corresponds to those attitudes/skills.
Personally: I'm afraid in a world with current growth of almost-free online
programming courses/degrees, high demand, high rates and low competition,
we're going to have to accept raising the "Engineer" skills to "Lead Developer
/ Architect" title.

If you compare with companies with big budget, yes those attitudes are what
you find on the average engineer. In the London start-up world where budget is
tight and VC's think short term that's normally not the case. It's hard to
find solid architectural thinkers with experience who don't call themselves
Leads, Architects and so on.

Are these skills and attitudes found in your area as just "engineers"?

~~~
codeonfire
Self taught people with low/no experience should be called 'programmers' at
best. In almost all industries, people who specialize in one or two things
would be called a technician or programmer, i.e. Angular programmer or web
tech. Software Engineer implies someone with a degree that does far more and
involves all aspects including project management and financial work. Lead
developer is a title for managers to use when they want to designate someone
as a developer that gets final say in decisions. The startup world is
ridiculous and half the people in startups should not even be called
programmers. Startups are just hiring people to look like they have lots of
talent for investors.

------
richliss
The best mix I've ever seen in practice had a non technical CTO who hired an
uber bright coder as Technical Authority. The Technical Authority had a
written mandate, signed off by the CTO and CEO, that his technical suggestions
were to be given the same authority as a board level member of staff.

The reason why it was successful is that the CTO is no longer a developer, but
a board director, and as such should focus on enabling the business through
its use of technology, and enabling the techology department by cheerleading
its needs to the business - you'll need to learn enough of the other business
functions so that you can do that job properly, and you'll need to be able to
give business cases of why you need those extra servers etc.

In addition, the Technical Authority wasn't disrupted by board level meetings
and politics, and could spend more time evaluating technologies, practices,
processes, setting standards etc. and they were not really suited to dealing
with the non technical stuff a CTO has to.

Another big benefit was that it enabled the Technical Authority to keep coding
because they loved doing it, and they were very good at it too. The team liked
this.

The team had a lot of respect for the CTO because they realised that he was
pragmatic and knew when to hire to cover his weakness, and when to take a step
back and accept that the Technical Authority and the team had collectively
made a decision, and that they were in a better position than him to do so.

As a general rule though, if you hire someone who disrespects you then you get
rid of them. There are very few domains where you'd have to put up with
assholery like that because there are no alternatives. Chances are that if
they've got the balls to disrespect the CTO then they're likely to be
unbearable to the people below and to the side of them.

------
cjbprime
It sounds like you don't actually think that someone ought to respect the work
you did as a programmer; you had little training, little time, and weren't
following good coding practices.

I think it would be healthy to approach it from an attitude of communicating
that you did what you needed to to get traction, but now you're ready to learn
about how to write code that scales while meeting deadlines, and you need
their help and experience to do that. It is possible.

Respecting you as a person is a prerequisite, and that'll come from your
sincerity to improve as a programmer and build a team that trusts each other
and keeps getting better. Respecting your code isn't a prerequisite. Your code
is bad. It's okay. It would happen to anyone in your situation. Rewriting a
startup's codebase from scratch after a seed round is not uncommon!

Hope that helps and isn't condescending; I'm writing this comment quickly.

------
joeld42
This is actually a good thing. You've got something working, it doesn't matter
if it's pretty. I've seen a lot of successful things that started out as ugly
code. The ones that start out pretty and "architected" always collapse under
their own weight before they ship.

We've all written crufty legacy code, at least if anyone is any good they've
written bales of it. I would respect that ugly code, because it shipped. What
I don't respect is someone who claims code is great and doesn't need fixing.

Now you need someone who can come in and turn it into something beautiful and
scalable and whatever. So when you interview them, just lay out the situation.
"How would you turn a terrible codebase into something great?" "Give me some
examples of legacy code that you cleaned up 'in-flight', without starting over
or disrupting operations or putting things on hold for six months". "What are
some difficult bugs you had to deal with in a messy pipeline, and how did you
fix them"? Ask about how they would improve real pain points in your current
pipeline.

If their answers are broad, ask them to be specific. You don't have to know
what they are talking about, but if they can talk about specific steps and
strategies, it will be clear they've done this kind of work before. If they
are hand-waving about best practices and generalizations, and can't drill down
any further, move on. Make sure they can actually write code, too, there's
plenty of people out there who can talk about code but don't sit down and
write it every day. If it's going well, take them out to lunch, tell them
about this post. You need someone who you can trust and be honest with,
someone who will give you honest feedback on technical decisions. You don't
want someone who resents that you have less technical experience and are in a
more senior role.

------
brudgers
Hire someone way more talented than yourself. Be upfront, that you want them
to write good code where that is consistent with the goals of the business and
that they will have to live with the pain of the existing code base until
there is a good business case for radically changing the code base. The hope
is that the good business case will be such strong growth that it all has to
be thrown away to make room for the wheel barrows full of money coming through
the front door.

Be an example for your hire. Don't own the code. Emphasize that the hire
should not own the code either. Emphasize the business goals are the goals and
code is only a means of pursuing those goals. The code is not an end in
itself.

It will be tough to hire. It will be tough to deal with the existing code for
the person who is hired. The goal is that the right person will get it and the
wrong candidates will filter themselves out.

Good luck.

------
rosspanda
As a CTO you will hopefully ALWAYS have better developers than you working for
you, that's the point, the CTO role is not to be the best tech guy in the
room. Its the guy that sets the vision, talks to investors, sets high level
tech strategy (with a lot of team involvement), hires, fires, keep sales guys
away from dev's etc

Eg. sort out everything that would distract your developers from building.

~~~
rosspanda
I'd Hire the full stack guys first, but spend a lot of time talking with them,
the first hire is always the hardest but the most important. Its also hard not
to hire people like yourself so take it slow, some of the best guys I have
ever worked with are mid 30 with wife and kids that just know how to get stuff
done.

~~~
cjbprime
The programmers-are-male assumptions in your comments are disturbing.

~~~
gamechangr
That's absurd.

Most programers are male? You can actually make that assumption factually.

How do you feel about the phrase "MIDWIFE's are in demand"? Is it appropriate
or do you feel that people should have to say "Midwifes, both the females that
practice midwifery and the males in in this profession, are in demand"? Can we
just assume that the majority of midwifes are women and the majority of
programmers are men without that being offensive?

~~~
dragonwriter
> How do you feel about the phrase "MIDWIFE's are in demand"?

Well, for me, bad, but mostly for reasons unrelated to the main issue in the
discussion -- because it uses an apostrophe improperly for "look out, here
comes an 's'", and because the plural of "midwife" is "midwives". ("midwifes",
without the gratuitous apostrophe, is a word, but its the third person present
of the verb "midwife", not the plural of the noun "midwife".)

~~~
gamechangr
Funny

------
marcocampana
What you achieved is actually pretty impressive. Teaching yourself programming
and build a product with traction and worth of investment. Use this at your
advantage, the kind of developer that you want to hire first will respect
that.

Hire a Senior full-stack developer and communicate very well that the state of
the platform (and the code) is at "junior" level. Use this argument to
motivate him, many developers like the challenge to set standards and lead
technical decisions early on in a project.

------
quotedmycode
Well, I'd ask for a portfolio, and if you do have some programmer friends that
do have the experience, I'd ask them if they can sit in an interview with you.
If a portfolio is not possible, I'd ask for some technologies that they've
worked with, and try to find a project which uses those technologies. I'd ask
for a work sample using whatever they are comfortable with, such as the
'TodoMVC' implementation, something small that can be finished in 4 hours that
shows their skill. This isn't like you are hiring just a programmer, this is
going to be one of the first programmers you hire, the one likely to set the
standards. Yes, he may not respect your programming skill, but that's to be
expected, programmers are prideful of their work. However they can be
respectful of you while giving you the rundown of why what you wrote was
wrong. You want to hire someone who is better than you at programming. At the
same time you don't want someone who is an ass, that should be pretty easy to
figure out.

------
TheM00se
Get out of the business of being a CTO if you don't know technology. A CTO
knows what the tech does and how to code, they are super technical. You could
be a CEO or a CMO instead without being technical. CTO with no technical
experience is a train wreck in progress.

------
danielbnelson
I would hire the absolute best most experienced developer you can. Hire
someone with startup experience that can do the hands on work needed now, but
also manage and scale the development quickly.

I would say use the title VP of Engineering for the new hire. IF they are a
rockstar, then you can promote them to CTO. If not, you could hire a CTO.

I would move yourself into another C-level title such as Chief Product
Officer. CTO really means deep experience with tech which you don't
have.....and that's ok because you are a founder that kicked ass on the
initial version. Now you can bring in the talent to really scale the tech side
of the company.

------
simook
It can be hard to let go of the work you have done to let someone else pick up
the torch.

And It will be tough because this is your first experience being a programmer
and your code confidence will be easily shattered. But the best thing you can
do to improve your product, code, and knowledge is to hire someone with more
experience than you. A good CTO hires knowledgeable programmers and listens to
their opinions so he can make informed decisions. If you try to protect the
code you have written by hiring less experienced programmers, your product
will ultimately suffer and you will eventually be let go.

------
forgottenpass
You're not the CTO of your company, so give yourself a different title.

 _how do I "manage" that individual if they don't respect the work I've done
as a programmer?_

By giving yourself a position that you can live up to.

Do you need a board-level technical person? If you do, you've already said
you're not qualified to be it. Do you NOT need a board-level technical person?
Have the them report to whatever your not-CTO role is.

------
zer00eyz
I'll agree with most folks here that you aren't a CTO.

You don't NEED a CTO, today, and at this point it might even be counter
productive. Your either going to hire what you can afford, or pay a lot of
money for little code return.

Do you need an architect/director/VP/tech-lead? Probably.

What you have already done in "reducing the time to goto market and cost-
quality has taken a hit" is make a sound business decision. Without knowing
what your road map, funding level, growth projections and anything about the
existing codebase we are being asked to give advice in a vacuum.

Your real issue (and why I would say you ARENT a CTO, or VP or any of those
other titles) is that you lack a network. If I need advice, a sounding board,
an outside opinion or a shoulder to cry on, I have a list of folks I can call
24/7 who I trust and have worked with in the past. Sometimes it isn't wise or
possible to get this kind of support within your current company, and as a
manager outsiders who understand may be your ONLY outlet.

Your a founder, you just got some cash, set aside 2-3 hours every day to just
TALK to new people. You want to buy me lunch and pick my brain for 2 hours,
thats a fair deal, and its easier for me to be objective about YOUR issues,
and YOUR drama (its going to happen). If we got along and started to get
together regularly, I'm going to get insight and continuity that you just
can't create in a form post. If I'm willing to listen to you for lunch (and I
have do so for others) I'm sure a lot of other folks are as well. There was a
story a while back that there were folks willing to give up their passwords
for a snickers bar, just imagine what you can get from sandwiches,
cheeseburgers and the occasional beer.

------
osetinsky
I'm in the same position with similar circumstances. You did what you had to
do - instead of going back to school and learning the theory, you decided to
focus on the problem and build practical solutions in the form of
prototypes/mvps. There's no shame in that.

My approach will be to stay humble and eager to learn. I want to hire people
smarter than me so that I can grow by working with them.

------
tixocloud
With regards to your concern, it's important for any leader to know their own
weaknesses. Given that you know you're not a superstar developer so if you'll
be hiring one as part of the technical team, make sure you pay attention to
what he/she says. Listening to others will help you gain respect. The CTO's
role will be enable the technology to fuel the business. It doesn't
necessarily mean that you have to be the best developer but it means that you
have to help your technical team to achieve it. Give them the tools, ask for
their expertise, let them make it happen and communicate the business strategy
to them.

At such an early stage, you'll probably need someone who is a self-starter who
can play multiple roles rather than someone you will have to "manage".
However, given that you don't have a solid technical background, it will be
tough to make a lot of decisions without consulting your technical team. Find
someone who is a technical expert but is also willing to help you, not
overtake you.

------
bsg75
> As a CTO with no computer science background and no previous experience
> programming at another company

Why are you the CTO?

~~~
questifer
I programmed in my spare time because I was curious. After a few months I
started building little applications to make my life easier. My co-founder and
I then had an idea and we wanted to bring it to market. I continued teaching
myself until we got to our beta complete.

I figured we're a two person startup and I'm writing code and building the
beta, I guess that makes me the CTO?

~~~
hga
Note: you can't say you have no experience, because you demonstrably have
some!

One thing to decide is if you want to continue down the technical path. In
that case, you might want to hire a CTO (I agree with those that say you
should move to "founder") who has as one of his explicit missions helping you
to gain more experience. As part of finding such a person, you might ask for
book recommendations in interviews.

But as others have noted, you'll have to check your ego at the door; back in
1971 Jerry Weinberg formulated the concept in his still excellent _The
Psychology of Computer Programming_. If you can't do that, or completely turn
it over to the technical people you hire, your venture is in serious jeopardy.

That said, you do need to find someone who doesn't gratuitously insult you or
your work.

------
petervandijck
Hire a CTO to replace yourself. Be a founder.

------
palidanx
The only other thing I would add other than hire someone more talented than
yourself is to ask a friend you really really trust who has good tech skills
to help vet the candidate. You can do the behavioral questions, but you should
have at least one representative who can ask the right questions.

------
orasis
Do yourself a favor and don't call yourself a CTO. It makes you sound silly in
front of your customers. Call yourself a Founder.

