The Startup CTO's Handbook • Hacker News Board

Re: The Startup CTO's Handbook

#121

Post by Aurornis » Wed, Mar 12, 2025, 2:54 PM UTC

fatnoah wrote: post #112

Aurornis wrote: post #98

Earlier quoted context omitted.

That has been the fate of every platform team I’ve worked with in recent years. Then they become gatekeepers, refusing to allow anything on their platform unless it conforms to their ideal vision. The catch is that their vision won’t be ready to use for 6-12 months, so you can’t deploy. Now your biggest problems aren’t engineering, it’s constant politicking to get around the platform team. Add to this the concept of…

> Then they become gatekeepers, refusing to allow anything on their platform unless it conforms to their ideal vision As the owner of a platform team, this very common attitude of platform teams kills me. Yes, we have a long-term vision that we're working towards, but our main goals are two accelerate developers AND produce more robust systems. Outside of totally egregious violations of company standards, my team is…

That’s exactly how every platform team starts. There is inherent tension between accelerating developers and building their own systems, though.

In my experience, the platform teams developed an idea that their conceptualized system would accelerate everything once it was done, but working with product teams was a distraction from getting it done. They also didn’t like the idea of deploying something now and then having to rework it later when their ideal system was ready. So they defaulted to gate keeping, delaying, and prioritizing internal work over requests from the product teams.

The only way to get things done was to leverage management chains to put pressure on the platform team to prioritize getting your thing deployed. This was constant no matter how much headcount the platform team received because with every new hire they developed new ideas and goals to add to their internal roadmap.

It’s not supposed to work like this, but it plays out this way in many companies.

Re: The Startup CTO's Handbook

#122

Post by hnthrow90348765 » Wed, Mar 12, 2025, 2:55 PM UTC

marcinzm wrote: post #99

hnthrow90348765 wrote: post #91

Earlier quoted context omitted.

>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 crew can't get enough resources to fully fix anything. This is the PM's job - one or a few people who are deciding the vision of how all of the fea…

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.

Re: The Startup CTO's Handbook

#123

Post by SOLAR_FIELDS » Wed, Mar 12, 2025, 2:59 PM UTC

xp84 wrote: post #22

SOLAR_FIELDS wrote: post #10

Earlier quoted context omitted.

I was just commenting to a colleague recently about the significant improvements RDBMS have gotten for json support over the last decade. For instance, keys below the first level in Postgres jsonb fields were not indexable around a decade ago. Now you can do GIN index and other options that are rather sophisticated.

Agreed. I can't think of anything that would convince me today to use a document store over Postgres as the primary (or likely only) database. Most of the time JSON fields augmenting the RDBMS seems like the way to go.

My default position nowadays is “Postgres” and engineering should have to justify why it is insufficient if engineering wants to use something else. It’s worked pretty well

Re: The Startup CTO's Handbook

#124

Post by pc86 » Wed, Mar 12, 2025, 3:05 PM UTC

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.

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 sure, and I don't think a senior engineer should be doing first-level support, but especially in small companies talking to customers is good and should be expected from basically everyone who is working on the product.

Re: The Startup CTO's Handbook

#125

Post by BossingAround » Wed, Mar 12, 2025, 3:13 PM UTC

pc86 wrote: post #114

n4r9 wrote: post #73

Earlier quoted context omitted.

Further down the article: > The Microsoft blog post referenced above recommends swapping some team members between the two crews every week. This would hopefully mitigate the worst of the effect you describe, since everyone eventually gets exposed to the consequences of poor feature development.

I don't know about you but it's rare that I've neatly wrapped up my tasks at the end of any given week. Single-day tasks are rare, there is always carry-over work including over the weekends. The only thing worse than a feature that got rushed out the door Friday afternoon because you had a completely different role come Monday is one that was 80% done then passed off to someone else because you had a completely diff…

In my company, we rotate every 5 months. So every 6th month, I get put into the customer-facing team for 1 month. Every other month, a different team member is on the customer-facing team.

This is still annoying, but gives you enough time to work on features, and enough time to try and crack some customer cases (though I could even see being in the customer-facing team for more than 1 month, as sometimes, this is not enough to debug the issue and provide a fix).

I've got to admit, as much as I dislike being on the customer team, it's certainly less annoying than working on features, and have constant customer issues interruptions though.

Re: The Startup CTO's Handbook

#126

Post by BossingAround » Wed, Mar 12, 2025, 3:22 PM UTC

pc86 wrote: post #115

SkyPuncher wrote: post #95

Earlier quoted context omitted.

Further, I'm not sure what efficiency it provides overall. Is dedicating 20% of your team to support _that_ much different than the entire team spending 20% of their time on support? We've actually found our quality goes up massively when we force our engineers to deal with the problems in the features they ship, directly with customers. We still have dedicated front line support (that rotates weekly), but they run o…

> Is dedicating 20% of your team to support _that_ much different than the entire team spending 20% of their time on support? Yes, it's [much] worse. Because nobody wants to be the support crew, so you end up with the 20% most junior, least outspoken people. Then the other 80% cares less about what support requirements will come out of the code they're writing because it's not their problem. It's the perfect scenario…

That's why you rotate everyone, not just those that "volunteer"... This way, you're spreading knowledge to everyone, e.g. if I'm forced to deal with an issue on code you wrote, I'm forced to learn about it.

Of course, I might have to ping you and get you to help me with it, so it's less efficient. Then again, if you leave the company, I have some knowledge about the feature, so... There's tradeoffs for sure.

Re: The Startup CTO's Handbook

#127

Post by DanielHB » Wed, Mar 12, 2025, 3:23 PM UTC

actionfromafar wrote: post #72

DanielHB wrote: post #54

Earlier quoted context omitted.

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…

I wonder though if there aren't more forces at play. For instance, the business problems some systems try to solve really are so large and complex, you might need some kind of overseeing function in your company. Also I have a hunch a team dedicated to providing helper "libraries" more than than "frameworks" could provide a lot of value without so much downside. If you can call a library function without it imposing…

If your org starts a platform team it is really important to have this concept drilled on early. Buffet, not framework.

I clearly remember having some discussions with platform people in my last job and asking them "why should I use your solution instead of getting an open source one that is likely better tested and used by more people" and the answer was usually "we can help if you run into any problems". Well, the "help" is to be planned and prioritized in the next sprint and probably will only come next quarter. So now the devs in my team need to make PRs to the platform people code and beg for reviews, how is that better than using the open source?

Re: The Startup CTO's Handbook

#128

Post by silasb » Wed, Mar 12, 2025, 3:26 PM UTC

erispoe wrote: post #119

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…

It's a good idea to just not do stupid shit that would make it very painful to actually get compliant. Get vendors who have certs, keep infra minimal (which means not infra team). The more you do in house the more painful compliance will be. Buy, and buy from certified providers, simple. Manage identity centrally, keep all your secrets in a secret manager, use git and do code reviews. You're right all things you shou…

Doesn't "Buy, and buy from certified providers, simple. Manage identity centrally...." contradict each other?

Re: The Startup CTO's Handbook

#129

Post by film42 » Wed, Mar 12, 2025, 3:27 PM UTC

tptacek wrote: post #30

film42 wrote: post #24

Earlier quoted context omitted.

Using something like Vanta or Drata makes life a lot easier. I've done SOC2/PCI audits in fintech where we change tools every year (meaning we reinvented the wheel every year), and I've now done it at my own startup using Drata. Auditors feel more comfortable, you'll feel more comfortable, etc. Even if you're not planning on doing it right away, just sign up and have it start tracking your progress. It's time consumi…

By all means use tools like these, but be very careful, because they (and auditors that use them) will lead you into engineering changes that are not required for SOC2 and may not be what's best for your team. For instance: there is absolutely no need to set up PHI scanning or a WAF to get SOC2.

My startup has to maintain a HIPAA cert, hence PHI scanning. But, you are correct.

Re: The Startup CTO's Handbook

#130

Post by hnthrow90348765 » Wed, Mar 12, 2025, 3:34 PM UTC

pc86 wrote: post #124

hnthrow90348765 wrote: post #122

Earlier quoted context omitted.

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.

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 a PM to answer that for them? Why must we also be expected to be in customer meetings and putting in extra effort, when PMs definitely won't put in effort to learn the technical side?