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

The Startup CTO's Handbook

github.com

Post reply on HN
Print view View original

151–160 of 212 posts

Re: The Startup CTO's Handbook

#151

Post by tristor »

hnthrow90348765 wrote: post #130
pc86 wrote: post #124

Earlier quoted context omitted.

I think you're conflating "doing two jobs" with "not being allowed to just type JavaScript into a computer all day in isolation and being expected to actually communicate and think about things other than data structures and algorithms." If you're a true senior software engineer as most of us claim to be coding is a small part of your job, not your entire job. You should be learning the product through the PM for sur…

Let's flip this around and see if it still fits: "the PM can't be expected to sit in meetings all day, they need to learn the coding side of it too so they know the potential limitations of the features they want to suggest" But if a PM does have a technical question, they don't need to go google stuff and figure it out - they ask a developer. Likewise, when a developer has a product question, why can't they rely on…

Yes, it still fits when you flip it around, speaking as an engineer turned technical PM. PMs should absolutely be technical and have enough depth of understanding about the product they can figure things out for themselves, as well as write code.

That's not going to prevent the PM from asking questions to the developers though. I ask questions all the time, because I want to validate my mental model with others and verify my understanding. Asking questions is a /good/ thing.

The part where you are missing the boat is acting like customers are a distraction or an enemy. Customers are /the point/, the /only/ point, really at the end of the day. Every role in every business is customer-facing to some degree.

Re: The Startup CTO's Handbook

#152

Post by SketchySeaBeast »

bluefirebrand wrote: post #136
DanielHB wrote: post #131

Earlier quoted context omitted.

That is actually usually not that bad (if there is, you know, revenue). What is really bad is when those teams start to roll out a lot of custom code that other teams need to use. If they are just configuring standard tools for everyone else it is usually fine (as long as they are not going to crazy with it).

The "platform" team at my company has rolled out a completely custom query language that we have had to learn and write so they don't have to make new endpoints to access different combinations of data And they haven't documented anything "There are integration tests, those are documentation go read those" Good times

That's really the best, when not even intellisense can help you.

Re: The Startup CTO's Handbook

#153

Post by moi2388 »

randerson wrote: post #134
moi2388 wrote: post #76

My rules: 1. Keep nonsense away from your developers. They don’t need to be in meetings. If they do, they’ll ask for it. 2. Have coding standards. What is your definition of done? How far do we go with clean code? Hacky solutions are tech debt and will come back to bite you. Standardisation is much more important than the actual rule. 3. Have retrospectives. Why did something not work out as you think it would? What…

In my experience, trying to shield developers from customer/business/product decisions will doom the business to broken telephone syndrome. Developers are also generally more motivated when they feel some connection to the business.

Did you read the first or third sentence in point 1?

Re: The Startup CTO's Handbook

#154

Post by pphysch »

guappa wrote: post #64
bob1029 wrote: post #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…

You've ever done support calls? You waste hours because the customer couldn't be bothered to read the manual. They'll ask you to be their IT staff if you let them.

If you have to constantly tell customers to RTFM, you have a poor product. Or at least poor documentation. But no amount of documentation can paper over fundamentally poor product design, because docs are also technical debt.

Even if devs aren't taking calls directly, there should be a product manager communicating this feedback to developers.

Re: The Startup CTO's Handbook

#155

Post by osigurdson »

dowager_dan99 wrote: post #148
osigurdson wrote: post #93

Earlier quoted context omitted.

Also, many start-ups seem to do fine without formal management structure up to 50 or more employees. The CEO / CTO is still coding, talking to customers, hiring, and making the product better. Getting "all managery" in early stages seems like a huge misstep to me. The skills needed to successfully create a start-up are far more rare than those needed to be a good manager.

I really dislike almost everything Oracle and Larry Ellison, but he had an early-days adage "There are 2 jobs at Oracle: you're either building software or selling it". At a early-stage startup most people should be doing both.

Yes, totally agree. Don't hire people to work on "corporate culture" until you have money to burn.

Re: The Startup CTO's Handbook

#156

Post by cyberax »

femiagbabiaka wrote: post #5
tptacek wrote: post #3

One way I try to get my head around things like this is to skip to a section I understand deeply and see what they said. Here, the claim is made: Don't try to get a compliance certificate at the last minute. Preparing for and conducting an audit such as for PCI DSS or SOC 2 from start to finish is a lengthy process, ranging from six to twelve months for most startups. Starting early and maintaining compliance is chea…

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

Ugh. That sounds good on paper, but in practice it can become a problem. You're making your _database_ schema a part of the public API. It's an example Hyrum's Law, people will, sooner rather than later, start depending on internal details of the data representation.

And your development velocity will crater, as you'll now need to update all the reports (that are not necessarily even tracked in version control!).

Investing some time early to add code to pull out the data relevant for analytics can be worthwhile.

There's also a question of the personal information.

Re: The Startup CTO's Handbook

#157

Post by cyberax »

scarface_74 wrote: post #56
film42 wrote: 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”…

> The job of a CTO is strategy. The last thing you want is a manager that codes.

For a large company the size of Google? Yes. For a startup? No.

Re: The Startup CTO's Handbook

#158

Post by marcinzm »

regularjack wrote: post #149
marcinzm wrote: post #99

Earlier quoted context omitted.

What you're describing is exactly the opposite of every actually successful team I've seen, and describes every mediocre team I've seen. Silos are death and not just in a code base. Good developers understand the product. Mediocre ones churn out tickets mindlessly.

In my experience, both are needed. Product owners and developers who understand the product. It's possible to have both, they're not mutually exclusive.

You're right, I didn't mean there shouldn't be PMs but rather that the PMs shouldn't be the sole people concerned with product.

Re: The Startup CTO's Handbook

#159

Post by marcinzm »

hnthrow90348765 wrote: post #122
marcinzm wrote: post #99

Earlier quoted context omitted.

What you're describing is exactly the opposite of every actually successful team I've seen, and describes every mediocre team I've seen. Silos are death and not just in a code base. Good developers understand the product. Mediocre ones churn out tickets mindlessly.

I'm okay with that knowing those developers are doing two jobs for the pay of one. And most products turn into that once the original developers leave. It's not like you can't learn the product through the PM either.

Unless you're working 80 hours a week you're not doing two jobs. You're doing one job.

Re: The Startup CTO's Handbook

#160

Post by marcinzm »

hnthrow90348765 wrote: post #130
pc86 wrote: post #124

Earlier quoted context omitted.

I think you're conflating "doing two jobs" with "not being allowed to just type JavaScript into a computer all day in isolation and being expected to actually communicate and think about things other than data structures and algorithms." If you're a true senior software engineer as most of us claim to be coding is a small part of your job, not your entire job. You should be learning the product through the PM for sur…

Let's flip this around and see if it still fits: "the PM can't be expected to sit in meetings all day, they need to learn the coding side of it too so they know the potential limitations of the features they want to suggest" But if a PM does have a technical question, they don't need to go google stuff and figure it out - they ask a developer. Likewise, when a developer has a product question, why can't they rely on…

> But if a PM does have a technical question, they don't need to go google stuff and figure it out - they ask a developer.

In a good organization they first try to figure it out themselves versus distracting a developer (thus costing possibly hours of productivity due to breaking someone's flow). The same way a developer would first try to answer their own question before they start badgering another developer.

Post reply on HN