Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How my role as CTO has changed as we've grown from 1 to 100 engineers

engineering.gusto.com

Post reply on HN
Print view View original

121–130 of 142 posts

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#121

Post by edawerd »

awad wrote: post #85
cabaalis wrote: post #56

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.

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 the…

+1.This is a great summary of my experience

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#122

Post by nine_k »

legohead wrote: post #64

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 technic…

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

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#123

Post by alexchamberlain »

bla2 wrote: post #63

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".

Not sure it needs to mean firing people as much as giving any constructive feedback to an experienced engineer can be difficult, even if done perfectly.

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#124

Post by lancefisher »

nine_k wrote: post #122
legohead wrote: post #64

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 technic…

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

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.

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#126

Post by tonyedgecombe »

taytus wrote: post #53
volaski wrote: post #28

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. T…

>they don't know why they failed, and that's why they failed. You can very well know why you failed. Post-mortems (most of the times) try to answer that question Knowing something doesn't make it inevitable.

I've worked in a failing company where everybody knew what was wrong but still couldn't stop it.

Interestingly after the failure most of those people got new jobs doing what they should have been doing at the original workplace.

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#127

Post by tyteen4a03 »

bla2 wrote: post #63

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".

It might just be my British shining through but I had no problem understanding that bit.

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#128

Post by benaadams »

edawerd wrote: post #10
ngokevin wrote: post #8

- 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?

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.

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

Re: How my role as CTO has changed as we've grown from 1 to 100 engineers

#130

Post by Fradow »

plinkplonk wrote: post #113

"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…

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.

Post reply on HN