
How my role as CTO has changed as we've grown from 1 to 100 engineers - edawerd
https://engineering.gusto.com/how-my-role-as-cto-has-changed-as-weve-grown-to-100-engineers/
======
legohead
I was an engineer #1 hired by a "CTO" and we grew to 50 engineers. His
story/growth didn't really change much, however. He was a coding machine, a
true "10x engineer", and programmed day and night. He even started up a second
company while working on the first. He built both codebases from scratch, and
even re-wrote the first company's core codebase at one point.

He did attend exec meetings and make all major technical decisions, but I
never really felt he had to grow into anything.

When we got big enough to start worrying about compliance, security, and HR
tools, we did it together and moved on to the next thing.

~~~
nine_k
Pretty sad that it sounds as if security was an afterthought in your design.

~~~
lancefisher
There are a whole host of compliance and security issues that you don’t have
to (and shouldn’t) worry about when you’re small. Employee background checks,
documented disaster recovery plan, 3rd party pen testing, etc. Those are
things you worry about once you have built something. It’s different than just
application security which itself can always be improved over time even if it
wasn’t an afterthought.

~~~
dfsegoat
SarBox, GAMP, GAAP, cGMP, PCI-DSS... The devil hath many names.

------
plinkplonk
"At this point, I believe technical co-founders have a binary choice: Stay on
the technical track and hire a professional manager (usually given the VP of
Engineering title), or give up coding and focus on the management aspects
yourself. It really isn’t possible to do both."

For me this is the key quote.

I have a friend who went the other way from the author of this article. He
started as one of two company founders working out of an apartment doing all
the technical work while the other founder focused on business stuff.

When the company grew to a point where he had to decide between staying
technical and people management, he hired a VP of Engineering, stuck to
coding, and still codes 6-8 hours a day.

The company is now at about 200 people, is _profitable_ , raised a series A
after figuring out the business model, and blowing past the goals set by the
investors. His stake in the company is worth many tens of millions today.

Just an existence proof that 'sticking to coding', _can_ be a viable strategy,
if an unusual one.

He is not interested in blogging/social media etc, or else I'd have persuaded
him to write up his experience.

I have to agree with dang. _Most_ people running successful startups don't
have (or take) the time to write about it.

Which is too bad (imo). We could use more writeups from the successful subset.

~~~
Fradow
I'm another of those technical founders who choosed to stick with the code.
Even though we are still very small, it has been a subject of conversation
since the beginning between my co-founder and me, and after 2 years of trying
to convince me to assume managerial tasks, she finally came to term with that
idea.

It helps that a late-founder joined us and is already assuming the VP of
Engineering tasks. This was done even before our seed round, at only 2
developers. The sooner the divide is made, the sooner you can fully
concentrate on building the product.

I never really liked the "CTO" title, as I don't think of myself as a "Chief"
or "Officer. I'd rather be called Lead Developer.

------
edawerd
Hi all!

I'm the author of this post. Happy to answer any questions here about how my
role as CTO of Gusto has changed over time!

------
bradgessler
Did you have to get up to speed on al the details of fraud, risk, and FinTech?
If so how, what resources did you use to figure it out? If not, did you hire
expertise, bring it in-house, and only have to implement bits of it into
Gusto?

Second question: how did you determine to shift development from SF to Denver?
What criteria went into selecting Denver over other areas? How did you figure
out what to move their and keep in SF?

Third question: how are you doing? I remember in S08 when you were working on
PicWing. We’re still working on Poll Ev!

~~~
edawerd
Hey Brad!

I'd say it was a combination of hiring in-house experts (we did that to learn
about payroll taxes), and lots of reaching out to people and not being afraid
to pepper them with questions (for example, in the case of learning about the
ACH system: [https://engineering.gusto.com/how-ach-works-a-developer-
pers...](https://engineering.gusto.com/how-ach-works-a-developer-perspective-
part-1/))

As for Denver, a ton of factors went into choosing it. Ultimately though, we
just loved the people, talent, and culture in Denver so we went with that!

I'm doing great! It's so great to hear from you again.

------
asafira
I have a few questions!

1) Did others in the org recognize you couldn't spend as much time on code,
and they appreciated your time elsewhere? I can imagine there being some
growing pains as you slowly gave your responsibilities to someone else, and in
the meantime things not getting finished as quickly/productively. (Not to
mention the fact that an average engineer wouldn't like spending 12-14 hours
per day coding)

2) What is your favorite advice from the books you've read? What made the
biggest impact on your actions?

------
smt88
I use Gusto and like it for it's simplicity. It makes a complicated part of
running a company much smoother.

That said, I'm very curious what exactly all those engineers are doing every
day. What's the most meaty part? Payroll? Dealing with govt? Keeping the
servers up?

I think unexpected scaling pains are one of the most interesting and unsolved
issues with being a CTO and would love to hear more about that at Gusto.

~~~
edawerd
I can certainly share some of the meatier areas that engineers at Gusto work
on.

\- Calculating payroll and filing quarterly and annual forms are very
complicated tasks that (a) is different in every state and (b) changes
frequently as federal, state, and local tax laws change. Doing payroll in 50
states is similar to doing payroll in 50 different countries

\- Benefits is similar to Payroll in the sense that it's also very different
in each state. The business logic is complex and a significant amount of
engineering work goes into simplifying it for us customers

\- Because we move billions of dollars per month through the banking system,
we have a lot of the same technical challenges as a Stripe, Square, Paypal,
Venmo, etc. We have a dedicated FinTech, Payments, and Risk teams for this.

\- Security is super important to us, since we have a lot of PII/PHI and
financial informaiton

\- Gusto is about 600 employees today and we invest in lots of internal tools
for non-engineering functions, an enterprise data warehouse, and security.

\- We are also looking into what the future of payroll looks like. A personal
goal of mine is to rid the world of the concept of a "payday". Why shouldn't
employees get paid whenever they want for the work that they did?
[https://techcrunch.com/2018/06/21/gusto-flexible-
pay/](https://techcrunch.com/2018/06/21/gusto-flexible-pay/)

\- Technical debt: When you grow as fast as Gusto does, you inevitably accrue
technical debt and it's important that we carve our engineering resources to
keep that low.

There's a lot more in there, but hopefully it gives you a sense of how 100
engineers can add up pretty quickly!

~~~
lmeyerov
We use gusto across multiple jurisdictions where tax laws change every year
and our bookkeeper our employees put them through funny circumstances. I've
been impressed by how many problems they've made invisible (just notify us) or
we sent over and they handled. Cannot say the same about other folks we use
here (ex: zenefits caused multiple lapses in coverage).

------
sarabande
When you were larger, you state:

"At this point, I believe technical co-founders have a binary choice: Stay on
the technical track and hire a professional manager (usually given the VP of
Engineering title), or give up coding and focus on the management aspects
yourself. It really isn’t possible to do both."

Since you chose the management track, what did you do/who did you hire (in
what levels) to take care of engineering at the level you were previously
doing? Or were you effectively functioning as a standard IC so any developer
could take your role?

~~~
edawerd
It was important to us to be deliberate about hiring senior ICs since I was
more on the management track. We already had some in the company so that
helped as well.

------
cabaalis
We went from 1 engineer (me) to 4 last year. So I'm in the 2-10 stage. I coded
prototype and first X customers, which has become literally 20X in the past
year. I still code most of the time, and the primary problem I am encountering
is being willing to transition technically difficult aspects of the product.
This _has_ to happen, as I am finding myself becoming a huge bottleneck.

~~~
awad
The old cliche to work your way out of a job really resonated with me when I
made this transition. It is natural to want to take on a task for yourself and
to think you're doing your team a favor by shielding them from details you
have a mastery on. But, once you get into the mindset of enabling everyone by
focusing on training and knowledge sharing, you find that people are far more
capable than perhaps you give them credit for and in fact do them a disservice
by not giving them more reign. Worst case, you get a bit of sanity back from
being less of a bottleneck. It may not seem like it, but most of the time the
people applying tight time pressures are ourselves (customers also have more
patience than we give them credit for), and it is generally worth it to invest
in teaching someone to fish, as it were.

~~~
edawerd
+1.This is a great summary of my experience

~~~
awad
Fun fact we took over the lease at 425 right after y'all. That picture on the
blog with the couches does not do justice to how packed the office was when we
did our site tours!

------
wallflower
> To accomplish this, I decided to fly to New York to hole up in a hotel room
> for three days to read a few highly-recommended management books.

> I decided to focus on growing Gusto’s engineering team, and not our code.
> The technical books on my desk starting getting replaced with books like
> Mindset, High Output Management, and The Score Takes Care of Itself — still
> three of my favorites today.

If the three books listed in the latter excerpt were not those three books you
read in the hotel, can you please tell us what books they were?

------
zmitri
How did you maintain compliance and security before you could have someone
full time on it? How did you deal with audits? Did you hire an engineer full-
time dedicated to this, outsource it, or do it yourself? (I ask because I do
this now but at 8 people it's starting to take up too much of my time as CTO)

How does it work at your size now?

~~~
lylo
I think either of your options would work. If you have in-house skills
(yourself and/or another engineer), exploit them. If you have a trusted third
party who can help, spend some time and money on them. If neither of those
work and you feel you need to hire someone, do that (although I’d go with the
other two options first). Also, as you undertake these audits, keep a solid
record of documentation (questions and answers) as most due dil exercises will
be made up of many of the same questions. Stock answers go a long way.

------
vagab0nd
What do people think about the career trajectory as an individual contributor
in an early stage startup? I'm the kind of person who not only enjoys coding,
but hates dealing with management, hiring, meetings, etc. I always fear that I
will be pushed to take on a management role. At the same time though, I really
enjoy working with a group to build something from scratch. In your opinion,
do you think it's better that I don't join an early stage startup?

~~~
ccmonnett
No! I was the only engineer at a startup for 18 months (!) and we're now up to
7. Some of the other 6 will never be expected to take on management roles.

One of the great things about being an IC at an early company is there is so
much to do. You get to put your fingerprints on a lot of things across the
company because there won't be enough people to spread out all those tasks. As
the company grows, those foundations become opportunities for you to grow from
sole contributor to technical lead on each one; so much so that the hardest
part will be choosing what to give up control of, not to what to keep
contributing.

If you find yourself in this situation, I strongly recommend being involved in
the search for your VPE. It could be really frustrating to build the technical
foundations for a company only to be so frustrated by a poor manager being
hired above you without your input that you might even quit. Wouldn't be good
for your equity, either :).

PS this implies that if you don't want to grow into mgmt, you'll need to grow
into being a good lead developer. Early startups have no room for people
unwilling to grow.

------
seibelj
I am a CTO, going from 2 engineers to a total engineering org of approximately
20.

Much of my time is non-coding, but I don't believe you have to totally give it
up. I try to leave a day per week free of meetings to code / review code. I
keep some projects that, while useful for the company, can be worked on
irregularly and slowly, and are not super essential to be accomplished quickly
(which is why they aren't prioritized for the engineering teams).

~~~
yarper
Giving up coding is what you do for your team, so they don't have to deal with
the half finished B grade work you did inbetween doing the serious shit they
can't do

~~~
seibelj
Wow! What an extraordinarily unhelpful and bad attitude you have

~~~
kochthesecond
While crude, I believe he is right.

I have seen it too many times with project managers and now my CTO. Trying to
still code and fix that terrible bug with already too little time. Ends up
slowing down everyone because he never can get anything finished, or breaking
things on a Thursday at 6:49pm because of the half baked solution he thought
was good enough, but exploded in production, which he then has to spend 1 more
hour fixing and 6 more hours cleaning up the aftermath. Spend your time
reviewing and mentoring and try replacing yourself with someone who has time.

You now have important shit to do.

~~~
seibelj
I have determined that I can still code sometimes and not ruin engineering.
Nothing is black and white

~~~
kochthesecond
That is good. You know your situation best

------
bla2
This surprised me at first:

> having difficult conversations with individuals is never fun

But apparently "difficult conversations" is a Valley euphemism for "firing
people" and doesn't mean "discussing difficult engineering problems".

~~~
dayvough
How is this specifically a Valley euphemism?

~~~
sethrin
For most working persons globally, getting fired isn't something that involves
a "difficult conversation". Working stiffs do not get that degree of attention
to their feelings. Suggesting that this phenomenon is common to (or even
characteristic of) the high-income and acutely socially-aware circles of
Silicon Valley should not be construed to exclude its observation elsewhere,
but SV is one of the few places where the behavior is common, and hopefully
the only place that feels the need for a polite euphemism.

------
ngokevin
\- How much do you miss coding? Do you ever do it?

\- How would you and the company be different if you stayed on the technical
track? Was it a legitmate option?

\- You mentioned you had to give up one or the other, what made you decide go
management over technical?

~~~
edawerd
Definitely miss coding! I still do a little during our hackathons but
otherwise don't have that much time to commit to any projects. I would just
slow down the team.

~~~
benaadams
Thought of contributing to open source to keep your hand in; while not
creating bottlenecks, dependencies and project stress in your own company?

------
yelloweyes
This guy flew from San Francisco to New York to read books in a hotel? Like...
what?

~~~
jstandard
I understand where he's coming from. Sometimes to create a big personal change
you need to disrupt your routine in a big way. For me, a change in environment
really helps me think or focus differently.

New York may have been special in some way that could help that change.

I think the anecdote underscores how tough it can be to make that shift from
doing something you love and are good at into new responsibilities you're not
as strong in yet.

------
asdsa5325
Yikes, that open office picture looks like my nightmares.

~~~
easymovet
The justification I hear for ignoring the data against open offices is: "Every
other unicorn has an office like this and they get work done so why can't we"?

~~~
mandelbrotwurst
In a place like SF where office space is as expensive as it is, I wouldn't be
shocked if the savings in rent from this kind of floor plan outweigh any
productivity losses and I'd bet that is a primary reason why there are so many
open offices.

Edit: That said, that one definitely doesn't look like the most efficient use
of space.

~~~
deathanatos
> _In a place like SF where office space is as expensive as it is_

You could always _move_. I for one would love more non-SF companies; it'd open
up more options and opportunities to get off the sinking ship that is SF.

~~~
mandelbrotwurst
I would also love to see that, for a number of reasons.

------
camdenlock
Fantastic article! I’m in a similar position as you, and will have to face the
same decision you did, so this was refreshing and edifying to read. Thank you
for taking the time to write it.

One thing that stuck out to me was your mention of focusing on “diversity and
inclusion”. Why did that become a necessary thing for you to focus on? It
seems political, and entirely unrelated to the actual work of building a good
engineering team. Isn’t it enough to ensure that anyone and everyone has the
same opportunity to get hired? At my company, my goal has been to ensure that
all candidates get judged without focusing on attributes like gender or
ethnicity; to make sure that the doors are open to everyone, no matter who
they are. I then try to trust that the people who want to work in this field,
and this company, are capable on their own to come to us.

Has that been your experience, or has there been good reason to put extra
effort into finding/favoring candidates with certain characteristics?

------
johnrob
Given that you were essentially learning management while in the role, did you
ever end up hiring people with prior management experience to report to you?
What was the mentoring like for these folks - were there cases where your
reports actually had more experience than you?

~~~
edawerd
That certainly did happen. In fact, I would say its quite necessary for
growing startups to continually hire people with more management experience
than anyone else in the company. There isn't a sense of ego associated with
that. Many of them are really just excited to be on this mission together.

------
volaski
it's refreshing to see someone who actually successfully scaled a company
write an article about "here's how we did it", instead of bunch of failed
entrepreneurs who write medium posts about why they think their startups
failed to either feel better about themselves or to capitalize on their
failure with the attention they get from the blog post (answer: they don't
know why they feailed, and that's why they failed. The only way they know what
they think they have learned through failure was actually something meaningful
is to apply the "lesson" in their future endeavors and see if it works out.
Until then, all your interpretations are nothing more than your opinion)

I would love to see more of these posts on Hacker News instead of failed
startup post-mortems. Thanks for sharing!

~~~
dang
That would be great, but there's a structural limit: people running successful
startups don't have time to write about it, while people who have wound down
their companies do. When a company is going strong and HN sees a post like
this, it's usually because they're hiring :)

~~~
enraged_camel
>>people running successful startups don't have time to write about it

This is both offensive and incorrect. Offensive because it implies that if
someone manages to find the time to write about how they are running their
company they probably aren’t successful. Incorrect because the startup world
is in fact full of leaders who do manage to find the time to write about how
they run their companies (kalzameus comes to mind).

~~~
eropple
Patrick works at Stripe.

Before that, he consulted and ran a bingo card creator.

I love the dude and his advice has been invaluable to me--but it has been
invaluable because he is _not_ a guy who has run startups, he's a guy who's
had to make a buck.

~~~
bdcravens
Plus it seems his output (on his blog and here on HN) has decreased quite a
bit since he moved to Stripe, so this validates what happens when you get
busy.

~~~
newbie912
Although a big part of his job is writing about similar topics, so you could
also say he's still doing the same thing, only posting to a different end
point and getting paid. That too is success.

------
beager
Thanks for sharing this. I don't have any specific questions but being at the
tail end of 2-10 myself, it's good to have reference points for when other
people do certain things, like draw down to ~50% code or 0% code, how much
time to spend on recruiting, etc.

I will say that I've been feeling a different type of code guilt. I feel
guilty _when_ I code, because I view supporting, coaching, and mentoring my
team to be my 10x activity. If I'm coding, there could be 8 other people
getting blocked or needing help, and I'm off trying to build 4 hours of
context to solve problems.

------
sinnet11
Do you ever feel "bad" about cutting corners early on to push a product but
now others are working on the the same codebase? I have this feeling
constantly.

------
lylo
If you’re now focusing on the people and management, whose responsibility is
technical strategy and execution?

~~~
spamizbad
Hopefully you've hired solid technical VPs/leads/senior developers who don't
need C-level babysitting

------
balls187
Alt title could be: how I went from CTO/Co-Founder to the CTO and VP of
Engineering.

------
charmides
Which mistakes did you make when you were transitioning from an engineer to a
manager? Were there any incidents with your employees that you wish now you
had handled differently?

Thank you for taking questions.

------
thecupisblue
Interesting read, thanks for that. Besides human management, how have your
tech skills evolved? What directions have you taken/discovered/fell into, what
have you learned?

------
eksemplar
Did you pick up any management education along the way? I spent time getting a
masters in public administration and management when I made the move myself,
and found it invaluable.

~~~
edawerd
It's great to hear that you found the Masters invaluable! I personally didn't
do any formal education myself beyond reading, finding mentors, workshops,
some coaching, and experience along the way.

------
cvaidya1986
Very helpful write up. Do you feel ‘guilt’ for being solely managerial? How do
you manage code and design quality? What criteria do you use to hire now vs
early days?

------
iamwil
Sup Eddie. Besides books, did you go and ask people about how to be a great
CTO? Who did you pick to ask, and how did you find those people?

~~~
edawerd
Hey Wil!

Yeah, I found a few mentors who I would feel comfortable asking questions and
getting advice. I met some though investor introductions, and others through
friends of friends.

~~~
iamwil
Did you find their advice helpful? Could you tell ahead of time who was going
to be more helpful than others?

------
saketj
Great post! What were some of the toughest decisions that you had to make in
your capacity as CTO, as the company became larger?

------
jiveturkey
to offer a counterpoint to the lovefest going on here, TFA is almost
completely uninteresting. the role changed exactly as one would expect and
predict.

the only interesting part is reading about the humble beginnings, the
dedication and belief.

what would actually be useful to read about is failings, where OP failed in
transition to manager and how he overcame those failings. I mean there's a
paragraph in there but it's so boring -- "I read these 3 books". ok there's a
little more meat than that but it's too nonspecific to be interesting.

come on people, let's not just throw love out there for no reason. it has to
be earned. this article doesn't earn it.

OP should read _the hard thing about hard things_. there are many anti-lessons
there, don't treat it as gospel. but read it as a guide as how to write
something that actually delivers a lesson.

i await your downvotes ... :P

~~~
ChuckMcM
The common failure point, which the author mentions, is that people management
is not like coding. And trying to do both at once is a losing proposition. I
always stress to new managers that managing is different than coding in its
execution but similar in its perception. What that means is that when you code
a system and it works well, it operates smoothly and when things happen (like
you lose a disk drive, or a server crashes, etc) it continues to operate and
perhaps degrade gracefully. This is also true of well run organizations. Most
people recognize when the organization is running smoothly, and appreciate it
when the organization responds quickly and without disruption ton changes in
the environment. To me, I see that as the essence of good people management.

Sometimes when you have a piece of code that in spite of rewriting it a couple
of times the system still bottlenecks or whatever, you restructure. Same with
groups, except instead of code being moved around you move people around.
Being able to see people as a team with unique capabilities and putting them
in roles that are successful has been compared to programming.

The next step in the growth of a CTO (or perhaps the one after the next step
for the author) is when the company gets big enough to start making choices
about which problems they are going to focus on. Are they the payroll company
that you can run from your phone, or the one that integrates with Salesforce?
Or the one that blends remote workers from the largest number of areas into a
single payroll. That is when you have to start thinking as both a business
person and a technical person so that you can help steer the priorities to
solve the customer problem as it arrives and before it is solved in dozens of
ways by your other competitors.

------
yarper
At what point do you start calling people direct reports? I find this turn of
phrase really jarring

~~~
stronglikedan
Reporting hierarchy is there for a good reason. If you report to multiple
people, you're the one that's going to have a bad time when they're not
aligned with each other, each trying to give you a different list of
priorities.

~~~
yarper
Why don't they know what's important and what's not?

~~~
jcheng
In a larger organization, "knowing what's important and what's not" at all
times can be practically a full time job in and of itself. A lot of
engineering teams like to protect individual developers from meetings and
conference calls so they can focus on development, but that necessarily means
developers will be missing context.

------
jackconnor
great article, loved it

------
mattdeboard
This comment is hard to word without sounding like I'm grinding an axe with
the author or the blog post or something. I'm not. It's a good post.

Anyway, I was disappointed but unsurprised to find that Ctrl-F "leadership"
yielded 0 results. Anyone can read management books, and I am sure they're
super valuable for learning techniques to maximize the value the company gets
out of its employees.

However based on my experience over the last many years, it's not enough to be
a skilled manager. "Necessary but insufficient."

Leadership is a different skillset. I am sure Mr. Kim has learned a lot about
leadership, he just didn't split out the two in the blog post. Undoing the
semantic smushing of management + leadership so they can be focused on
independently is important, IMO.

