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

71–80 of 212 posts

Re: The Startup CTO's Handbook

#71

Post by petesergeant »

yard2010 wrote: post #67
petesergeant wrote: post #44

Earlier quoted context omitted.

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

I would love to know how and why you made that decision and how it's going for you (good I bet), can you please elaborate?

If “that decision” you mean going back to IC, it’s going well I think? I work remotely from outside the US, get a decent salary, and have a lot less stress than I used to! I’m currently working on AI projects I find really interesting and I’m getting a decent US developer salary in a tax-free company. Plan to retire in 15 years.

Re: The Startup CTO's Handbook

#72

Post by actionfromafar »

DanielHB wrote: post #54
m104 wrote: 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…

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 a whole framework on the rest of your codebase, it's more self-contained and can't spill its abstractions all over the place.

Re: The Startup CTO's Handbook

#73

Post by n4r9 »

pyrale wrote: post #57
m104 wrote: 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 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.

Re: The Startup CTO's Handbook

#74

Post by underdeserver »

adamors wrote: post #55
underdeserver wrote: post #53

I don't agree with everything, but man, reading up on all the best practices here makes me want to work at a place that implements them.

Probably no place implements all of them, but with all best practices, they should be asymptotic.

Probably not, but if the basic mindset is one that agrees with these principles and makes at least a minimal effort to try and follow them, it feels different.

Re: The Startup CTO's Handbook

#75

Post by Earw0rm »

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're every shade of the rainbow on this ship, but even our Klingon thinks Klingons are evil."

Re: The Startup CTO's Handbook

#76

Post by moi2388 »

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 needs to change?

4. Plan tech debt cleanup sprints, or incorporate some stories in every sprint. Tech debt immediately leads to slow down, and very quickly to stagnation.

5. Encourage training and knowledge sharing. Code reviews are a good place to start.

6. Write good tests. This alone will show you if your structure and code practices makes sense.

7. Management deals with “why”, a product owner with “what”, and a developer with “how”. Try not to mix these, it doesn’t end well.

Re: The Startup CTO's Handbook

#77

Post by normie3000 »

ozim wrote: post #48
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…

I think that is what author meant actually. Downside is there is a lot of startup founders that will need help getting the basics in place. I worked in place where 2 business guys hired 4-5 freelancers and as freelancers took high salaries not even one of them had any clue about setting up infra or SDLC let alone secure SDLC. They would write the code and not give a damn about anything besides that. Business guys tho…

SDLC?

Re: The Startup CTO's Handbook

#78

Post by maccard »

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.

> where people didn't want to naturally migrate to the "future crew".

I think the book captures a solution to this with:

> Engineers rotate between the crews on a regular basis. The Microsoft blog post referenced above recommends swapping some team members between the two crews every week.

> Define the customer crew as a temporary team. This can mean either that the customer crew itself doesn't exist full-time (perhaps for only one week per month), or that team members are constantly rotating between the customer and feature crews.

> Has anyone worked in a "two crews" system where there wasn't resentment?

yes. I've worked for a few places where the teams are fully distinct and it works well. In games think Engine team vs Game team. Even on the Game team at one of my previous roles the way it worked was you'd get put on a feature which might take 6-12 weeks to ship, and then there'd be some maintenance work/updates/tech debt after that. Your primary focus was the thing you just shipped but you'd also have the time to go back to some of the previous stuff and work on that too. During that time, the other team would be on the same rota, and after 6-8 weeks you'd on-ramp to a new feature and repeat.

Re: The Startup CTO's Handbook

#79

Post by maccard »

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.

Not OP, but I have.

What you've said here is exactly why the CTO should be on the support calls with the most problematic customers. They need to be the ones who shield the rest of hte company from letting this happen, and the only way to do that is to experience it first hand to see just how disruptive some clients are.

Re: The Startup CTO's Handbook

#80

Post by robjan »

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.

Ideally there should be some first line who deals with BAU customer support but completely separating value delivery from support bakes moral hazard into the org design.
Post reply on HN