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

111–120 of 212 posts

Re: The Startup CTO's Handbook

#111

Post by ajmurmann »

ajmurmann wrote: post #39
snide wrote: post #7

Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew". I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.

At my last job we had a version of our on-prem product where the company sold a super extension for a version that was supposed to go out of support. We had a small team (I think three people) whose only responsibility it was to ensure that version was supported, pipelines worked and we're ready to ship a big fix at needed. That was their responsibility but as long as that was covered they were allowed to work in the…

"support extension" not "super extension"

Re: The Startup CTO's Handbook

#112

Post by fatnoah »

Aurornis wrote: post #98
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…

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 expected to focus on how to get things done. That means being flexible, working side-by-side with other teams, etc. to make sure that a) they're able to deliver what they need and b) we help them build it in such a way that it can eventually be aligned with our utopian long-term vision.

Re: The Startup CTO's Handbook

#113

Post by incognito124 »

Aurornis wrote: post #98
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…

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…

That's actually the "premise" of Google's SRE book

Re: The Startup CTO's Handbook

#114

Post by pc86 »

n4r9 wrote: post #73
pyrale wrote: post #57

Earlier quoted context omitted.

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

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 different role come Monday.

Re: The Startup CTO's Handbook

#115

Post by pc86 »

SkyPuncher wrote: post #95
pyrale wrote: post #57

Earlier quoted context omitted.

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

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 for the aggressive prima donna who thinks their code is golden and everyone else's is dogshit.

I feel strongly that your front-line support should be full-time (not rotating) front-line customer support. That should be their job. If I reach out to a company for support I don't want my first contact to be with someone who writes code 95% of the time and this is their one week answering Zendesk tickets. I want it to be someone whose entire job is fielding customer issues and resolving them quickly and efficiently.

Re: The Startup CTO's Handbook

#118

Post by MichaelMoser123 »

Earw0rm wrote: post #75
MichaelMoser123 wrote: post #49

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…

All employment processes discriminate, the question is for and against what traits, and to the exclusion of what else? "Culture fit" is pretty much trading off communication efficiency and high trust against diversity of thought. You don't have to set so many guidelines as people already know how to behave, and what's expected of one another, but you're more vulnerable to groupthink and related cognitive biases. "We'…

> "Culture fit" is pretty much trading off communication efficiency and high trust against diversity of thought.

I think I understand now: if the structure of your company is strictly top down, then you will have to value "communication efficiency" and "high trust" criteria higher than "diversity of thought".

However, you might not be able to pivot efficiently, if your core assumptions are disproved. That's the situation where you might need "diversity of thought" - and the ability to incorporate different kinds of feedback.

Though I don't quite think that you will find this insight in this frigging book.

Re: The Startup CTO's Handbook

#119

Post by erispoe »

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 should be doing anyway.

Re: The Startup CTO's Handbook

#120

Post by maayank »

petesergeant wrote: post #44
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…

> You can be a technical CTO from start to finish My last CTO role (team of 40) had me absolutely over capacity from day one, and I am _good_ at time management. I would rather have been programming 50% of the time, but there just was no time, and no support structure in place I could hand stuff off to; I had to painstakingly build that, which was yet another reason I had no time. I like the idea of continuing to cod…

What were good time management resources for you?
Post reply on HN