I would love to see more of these posts on Hacker News instead of failed startup post-mortems. Thanks for sharing!
At the same, because of survivorship fallacy, I think the best way to get insight into what makes stuff tick is to get a balanced mix of both success and failure stories.
From a failure story you can look at what they did, but if they did X that doesn't mean X leads to failure, as others could do X and succeed. It's possible they succeeded in spite of doing X, but it's usually apparent when that's the case. Maybe X only worked because of a perfect storm of conditions/timing.
I would also say a vast majority of people who fail go on to fail a second time, making their whole reflections write up from the first failure kind of weakened by the fact the lessons they learned from their previous failure were not enough to avoid it the next time. Paying too much attention to what not to do just leads you down a totally different road to failure. Common pitfalls are worth knowing, but it would seem there are 10 ways to fail for every 1 way to succeed. Often big successes do the exact opposite of all the "don't do this" advice.
But that's just my perspective working in games, where creativity and rule breaking is a lot more substantial to the success, I think. However, I feel it all applies to a broader scope of business and software.
That's really cynical. For a long time, people were complaining about the opposite on HN: you never heard about the failures, which leads to a massive selection bias.
I've always felt that you can learn far more from failure than success. Successful people often have little actionable insight into why they succeeded (e.g. "we worked hard and made something people wanted"), but most people can write volumes about what they've done wrong in life.
That said, there are PLENTY of successful people who used to be a failure. In fact 99% of the successful people have been a failure at some point in their life. THESE are the people you listen to.
The things you read in the media about a genius who got it right on their first attempt are very exceptional cases, which means they were not only talented but also very lucky. And you're right that there's a selection bias when it comes to these people and they may be totally out of touch because they don't understand why they succeeded.
But like I said, the vast majority of accomplished people in the world were once failures. They just kept trying and made it happen. Which is why these people are worth listening to. They are the ones who actually learned from their past failures, applied it to their life, and finally succeeded.
But you don't deserve to tell others what you think is the right thing when only thing you've achieved in life is failure. You gotta earn it by taking the lessons you learned and applying it to come to a true success. These people are worth listening to.
From what I see, there are too many people who've never tasted success but just use their failures as an opportunity to get more attention for the sake of getting attention. Most of the times when you read their posts, they're full of "failure biases", which is much worse than success bias. And I think most of the "lessons" they learned are shit, and most of the times demonstrates exactly why they failed--because they were out of touch (which is why they think they understand why they failed)
So my point is, you should listen to people who have failed AND succeeded. There are many people like this.
edit: this is a star trek reference
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.
Interestingly after the failure most of those people got new jobs doing what they should have been doing at the original workplace.
As you noted yourself, blogging is a form of marketing.
Aren’t you kind of the one lowering 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).
I'll have to second your "yikes," that looks like a really distracting and very echoy place to work. I'd never get anything substantial done with any reasonable speed.
Edit: That said, that one definitely doesn't look like the most efficient use of space.
Headphones aren't the answer.
> 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".
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).
There is nothing more irritating than a CTO that continues to code. For one it will seriously disturb the team dynamic because you are going to set the standard for everything, whether you like it or not and if you've hired smartly (better at the job than you would be) you've now dragged down the whole team with you.
Also, you are going to be there part-time as a coder, and whoever ends up drawing the short straw to review your code will be very much aware that they are reviewing the work done by a c-level exec. That review will be less than a similar review done on the work done by a peer.
So if your company is dear to you leave your coding for some hobby project and allow the people you have hired to do their very best under your guidance.
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.
- 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/
- 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!
you might face some ingrained cultural barriers with this as the higher-status the job the more infrequent/delayed the payday... day-laborers are paid at the end of the day, many blue-collar jobs are paid weekly or bi-weekly, and white-collar jobs are typically paid monthly
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.
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.
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.
In many organizations I have seen the deep technical skills one gains through their career are not valued in the same way "Mgmt. Skills" are. "Mgmt. skills" are or at least appear to be much easier for an organization to see and reward. This is a great story!
I've seen a lot of fantastic coders get promoted to management and be bad-to-mediocre at it, and a lot of meh coders who can take over a room passed over for managerial jobs they'd probably be better at than their purely-technical ones.
How does it work at your size now?
But this could apply to any Function in the business.
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.
- 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?
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.
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
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.
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!
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...)
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.
"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?
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.
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!
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?
> 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?
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.
Thank you for taking questions.
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?
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.
