Live data from Hacker News

The Startup CTO's Handbook

github.com

81–90 of 212 posts

Re: The Startup CTO's Handbook

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

The book mentions having a rota:

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

In my experience this works well. With my current and previous client each team had a "hero of the week", whose responsibility was second line support and monitoring. If nothing came up the hero would work on their tasks as usual.

If something does come up the heroes of the week would be tasked with solving it or pulling in someone who knows how to solve it. This leads to engineers both having to accept accountability for writing shoddy code, but it also exposes engineers to the wider codebase when pulling on threads. It also solves the issue where no-one or the same person always takes responsibility for handling bugs.

Re: The Startup CTO's Handbook

#82
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.

Sort of. I've worked with having a rota where engineers would spend a week handling support and bug reports which avoids many of the pitfalls with the entirely separate "two crews". I wrote a bit more about it in https://news.ycombinator.com/item?id=43337703#43339972 .

Re: The Startup CTO's Handbook

#84
post #64

Earlier quoted context omitted.

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.

I agree the devs should not do full-on support - that's of course just waste of money. But, that's different from spending maybe two hours per quarter with the customer support agents, just listening in on the calls - it can be quite revealing and sometimes there are issues one is not even aware. Plus hearing it from an actual human, does something to your sense of priority about such issues.

One company I worked for had very cyclical sales spikes, culminating in Christmas week each year. During that week everyone did operations, we had developers out in delivery vans carrying parts of the extra large orders to customer's houses, and at least one back in the office mostly handling calls from customers and suppliers.

Without fail that week generated a stack of minor improvements that could be implemented in a matter of days in the new year, because we were out there using the software we wrote, and had the necessary knowledge of how it worked to spot places where we could save people cumulative days of work with a 30 minute patch.

Re: The Startup CTO's Handbook

#85

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…

This is supposed to exemplify my point: the attitudes of Mr. Zawinski may be questionable; however his contribution and his output are not questioned by anybody. We would all be worse off without these contributions.

Re: The Startup CTO's Handbook

#86
post #48

Earlier quoted context omitted.

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?

Software Development Life Cycle

Re: The Startup CTO's Handbook

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

argh! PTSD - This was exactly what happened at my last start-up. Two of the engineering team and one from the R&D team started a platform team and it became a pre-PMF product with the slickest pipelines, DevOps, Cloud-cost optimization ready to scale to infinity. But with no customers, a broken front-end, and a under-funded R&D team as all the effort was put into the essential SaaS Platform. Truly put the company back 1 year while burning two.

Re: The Startup CTO's Handbook

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

Every junior has mentors and leaders that help them and that they can follow. As you grow you might become one of them. That's the reason why you then let others do all of the coding. It's not like you unlearn everything, but you let your team grow and become you in the end. It can be really satisfying. If you can't stop getting your hands dirty then maybe it's not for you (yet).

Re: The Startup CTO's Handbook

#90
post #81
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…

The book mentions having a rota: > 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. In my experience this works well. With my current and previous client each team had a "hero of the week", whose responsibility was second line support and monitoring. If nothing came up the hero would work on their ta…

Isn't this just called on-call? That's very different from a separate team.
Post reply on HN