Live data from Hacker News

The Startup CTO's Handbook

github.com

51–60 of 212 posts

Re: The Startup CTO's Handbook

#51

There is a lot of talk on culture fit. Most of the talk on "culture fit" is bringing up a hidden layer of discrimination, of one sort of the other - to the detriment of the companies that are applying these rules. Cultural openness is a factor of success, discrimination is leading into the opposite direction - if you ask me. > The best leaders track their success rate, are not afraid of admitting hiring mistakes, and…

I accepted your side quest. The first page of results are all comments on hacker news about Jamie Zawinski and where I gave up.

Do tell…

Re: The Startup CTO's Handbook

#52
post #21

Earlier quoted context omitted.

Great approach. I ctrl-F'd for databases, good info there generally. The only thing that gave me pause: a startup doesn't need to focus on SQL vs. NoSQL in 2025 with such good json support in the most popular SQL databases. Just use PostgreSQL or MySQL -- whichever your engineers have more experience with -- use CloudSQL or RDS which will take care of the hard stuff like backups and replication for you, use read repl…

> use read replicas for BI with a good visualization tool Put up 2 or 3 read replicas, split your queries so writes happen to main and reads come from replicas (supported out of the box by many modern ORMs), and you can scale to millions in daily active users for most startup workloads. Really the hard part of BI is that folks who need the info don’t wanna learn SQL. The ones who can do SQL, will struggle to keep up…

> Really the hard part of BI is that folks who need the info don’t wanna learn SQL.

Data analysts are fine with SQL though. Every "get into data analysis as a career" course will teach you SQL (about 70% of what the querynomicon teaches [1]).

[1] https://github.com/gvwilson/sql-tutorial

Re: The Startup CTO's Handbook

#54
post #35

Oh lordy, the "two crews" bifurcation fully written down. What a fantastic way to ship until it becomes far too expensive to ship anything good. Look, when we break the feedback loop back to the people who wrote the software in the first place, they get happier for a bit, you make some other people sadder for a bit, and then slowly your feature crew never want to be interrupted or bothered again and your customer cre…

Related topic, but every company I worked at that had a platform team (as in a third-crew support team that manages tools/practices/common-code for a discipline) ends up being infested with over-engineering.

They tend to attract that kinda of people who have disdain about delivering features and fixing bugs and like to over-abstract problems. Instead of fixing bugs they try to create increasingly complex abstractions to prevent the bugs from happening in the first place, with obvious results.

Re: The Startup CTO's Handbook

#56
post #28

I read all the time about folks who become a VP/CTO and stop coding. Management skills are not coding skills. I know it. But I can't for the life of me figure out why folks hang up their keyboards and let their first super power go to waste. You can be a technical CTO from start to finish. Treat your team and the company like a service that needs active contribution, maintenance, and on-call support; and also, get yo…

The job of a CTO is strategy. The last thing you want is a manager that codes. They always end up either being shitty managers who don’t do the things that I need from a manager - making sure the team gets the resources we need, prioritization, big picture, etc - or they end up being shitty developers because they can’t keep their commitments because of management responsibilities.

Development is not a “super power”. Developers are a dime a dozen and if you look at the leveling guidelines of every well known tech company, how well you code only makes a difference up to the mid level.

Knowing what to develop, knowing how to deal with business, how to lead an implementation, managing trade offs, “dealing with ambiguity”, etc is the differentiator.

Re: The Startup CTO's Handbook

#57
post #35

Oh lordy, the "two crews" bifurcation fully written down. What a fantastic way to ship until it becomes far too expensive to ship anything good. Look, when we break the feedback loop back to the people who wrote the software in the first place, they get happier for a bit, you make some other people sadder for a bit, and then slowly your feature crew never want to be interrupted or bothered again and your customer cre…

> It allows your feature team to remain 100 percent focused on the future, undistracted by customer support work.

AKA "it allows your feature team to be completely oblivious to the horrors they unleash, and keep at it until the ship is solidly planted in the iceberg"

Not talking about the conflicts it creates for merging between sales-supported feature teams and customer rep-supported maintenance teams. Given that the "customer crew" is described as something you grow out of, there's no question who wins arbitrages.

> It provides another career path for individual engineers, especially junior engineers, to learn and level up on your team.

"Senior staff doesn't want to fix shit so we have juniors do it"

Re: The Startup CTO's Handbook

#58

There is a lot of talk on culture fit. Most of the talk on "culture fit" is bringing up a hidden layer of discrimination, of one sort of the other - to the detriment of the companies that are applying these rules. Cultural openness is a factor of success, discrimination is leading into the opposite direction - if you ask me. > The best leaders track their success rate, are not afraid of admitting hiring mistakes, and…

I accepted your side quest. The first page of results are all comments on hacker news about Jamie Zawinski and where I gave up. Do tell…

[deleted]

Re: The Startup CTO's Handbook

#59
> Left unchecked, the need to handle support tickets can become a major distraction to the team, hurting efficiency, draining morale, and burning out your best people.

This reads like satire to me - "Supporting the customer who is ultimately paying our salaries can become a major distraction to the team". If the need to handle support tickets has become so overwhelming, maybe your "best people" should be right in the middle of it until they figure out a way to get the entire team out of hell.

Protecting the elite engineers from the consequences of their own designs is a death sentence for a technology startup. I watched this happen in real time myself. The moment you let the developers off the hook, nothing feels real anymore.

The CTO should be leading by example. Getting in front of the customer on the calls. Heading up the nastiest implementations of the product. Grabbing the issues that have been rotting for weeks. Generally, throwing themselves directly in front of the bus at every possible opportunity. If you are the most highly-paid technical person, you need to be the backstop. There is no one behind you to catch anything. The CEO doesn't have time for the bullshit you were supposed to be managing.

Everything else follows from putting yourself in harms way as often as possible. After being ran through the rotten issue wringer for 48 hours, how do we feel about playing with clever noSQL/graph databases or web frameworks with no discernable user base? Does AI make sense for our business or customers? Allow the technology choices and policies to be informed by your daily, real world experience with the business. The more deeply you involve yourself, the more accurate your decisions will likely be.

Re: The Startup CTO's Handbook

#60
post #35

Oh lordy, the "two crews" bifurcation fully written down. What a fantastic way to ship until it becomes far too expensive to ship anything good. Look, when we break the feedback loop back to the people who wrote the software in the first place, they get happier for a bit, you make some other people sadder for a bit, and then slowly your feature crew never want to be interrupted or bothered again and your customer cre…

Developers must run and maintain the software they build. It's as simple as that.
Post reply on HN