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

141–150 of 212 posts

Re: The Startup CTO's Handbook

#141

Post by dowager_dan99 »

quacksilver wrote: post #107
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…

Would putting some percentage of the team on 'support' for a week or two help with reducing task switching and help to allow deep work? Maybe everyone in the team would spend 2 weeks per quarter or something like that doing support. I (n=1) would prefer to be answering support tickets for 2 week blocks, and know when the blocks are in my calendar, so that I can plan work around them, rather than trying to debug somet…

hand-off needs to be really carefully defined and managed efficiently. Client tickets rarely respect arbitrary calendars, and the context switching alone can be really expensive. The best I've seen is a primary/secondary setup where you move from copilot to pilot, so you're not coming into everything cold

Re: The Startup CTO's Handbook

#142

Post by dowager_dan99 »

BossingAround wrote: post #126
pc86 wrote: post #115

Earlier quoted context omitted.

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

I believe you're referencing the Engineering Management principle of "share shit work evenly".

Re: The Startup CTO's Handbook

#143

Post by dowager_dan99 »

madeofpalk wrote: post #60
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…

Developers must run and maintain the software they build. It's as simple as that.

The best development teams WANT this.

They will readily take on the responsibility to get the autonomy. The problem is many companies give the former without the latter...

Re: The Startup CTO's Handbook

#144

Post by dowager_dan99 »

plomme wrote: post #81
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…

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…

This just sounds like having a point developer. The challenge is too many companies expect this without giving up a feature-dev headcount. Any work the get done aside from point is a bonus and unplanned.

Re: The Startup CTO's Handbook

#145

Post by chasd00 »

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.

yeah i've always felt it was a good idea for new software devs out of college to spend a few years at a small eat-what-you-kill consultancy. You really get a sense of where you're paycheck comes from and why it exists. Going straight to a giant corporation distorts your view because no matter how detached and abstract you become the direct deposit still shows up. You lose all connection to why you're paid.

Re: The Startup CTO's Handbook

#146

Post by dowager_dan99 »

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…

I'm a first-time Director at a SW company with a total org under me of ~30 people in 5 different subject areas. I struggle with what you highlight, but it's impossible for me to go deep in all these areas. MY boss is the CTO and he talks about "T-shaped" or broadly across and narrowly deep. I really don't like this, but the reality is I view myself as senior-dev level in one area, int in another, junior in 2, and barely familiar with the third - and I'm by far the most technical of all the Director/VPs

Re: The Startup CTO's Handbook

#147

Post by dowager_dan99 »

upcoming-sesame wrote: post #103
Aurornis wrote: post #100

Earlier quoted context omitted.

At VP/CTO level you don’t have time to contribute and maintain code. If you do, the VP or CTO title is probably symbolic, like when someone is a “CTO” in a team of 3 at a startup. The real problem is when people take early career roles that leave no time to code: They take architect roles where they just draw boxes on whiteboards and hop from meeting to meeting, or they accept a role labeled “tech lead” that is actua…

I tend to agree but also think AI is changing this narrative. Now some of the coding can be done by LLM and the "architect" skills are more important

This is how auto executives designed the Pontiac Aztek. How can you possibly become or develop new "architects" with this approach?

Re: The Startup CTO's Handbook

#148

Post by dowager_dan99 »

osigurdson wrote: post #93
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…

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.

Re: The Startup CTO's Handbook

#149

Post by regularjack »

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.

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.

Re: The Startup CTO's Handbook

#150

Post by djeastm »

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…

Maybe when you know you're due to start support the next week, you stop feature work sometime the previous week and do small maintenance/backlog tasks and or documentation. Like a cooldown period before task switching
Post reply on HN