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

131–140 of 212 posts

Re: The Startup CTO's Handbook

#131

Post by DanielHB »

neumann wrote: post #87
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…

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

That is actually usually not that bad (if there is, you know, revenue). What is really bad is when those teams start to roll out a lot of custom code that other teams need to use. If they are just configuring standard tools for everyone else it is usually fine (as long as they are not going to crazy with it).

Re: The Startup CTO's Handbook

#132

Post by film42 »

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

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…

IMO the architect-leader role is an attempt at scratching the itch of not being able to code. I've worked with leaders that would spend any extra time they had building projects in new frontier tech to understand the nuances behind the marketing, and I'm sure we've all worked with folks that blindly parrot the marketing speak in design meetings.

You don't have to always be building things to be a great leader, but I place more trust in a company with a technical CTO.

Re: The Startup CTO's Handbook

#133

Post by codingdave »

> Synchronous Chat

I just want to put the idea out there that there is no such thing.

If you need it to be synchronous, it should not be in a chat window. Or at least, not without agreeing "Hey, we are going to dedicate a few minutes to real-time chat on this."

If remote, call them. If on-site, face each other and talk. Don't throw messages into a chat and expect immediate response.

Re: The Startup CTO's Handbook

#134

Post by randerson »

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.

Re: The Startup CTO's Handbook

#135

Post by fatnoah »

Aurornis wrote: post #121
fatnoah wrote: post #112

Earlier quoted context omitted.

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

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

Absolutely, and I've been on both sides. We go much more with a carrot approach than a stick approach, and have no ability to "block" any product team from doing things. Our goal is to ship things that are useful and lower the effort required for product teams to ship their products, which is handling basically everything except product-specific features. However, product teams don't have to use the platform, but then they own the operational burden of whatever custom stuff they're using. When that happens, we still work with them to minimize that or bake that capability into the platform and eventually take it over if it's useful to the wider org.

"Success" of the platform team really depends on serving the product teams, so blocking or being a barrier goes very much against that. We try to provide opinionated golden paths, but also try to build a properly abstracted stack of capabilities so teams can also extend/consume at a lower level if that better suits their needs.

Re: The Startup CTO's Handbook

#136

Post by bluefirebrand »

DanielHB wrote: post #131
neumann wrote: post #87

Earlier quoted context omitted.

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

That is actually usually not that bad (if there is, you know, revenue). What is really bad is when those teams start to roll out a lot of custom code that other teams need to use. If they are just configuring standard tools for everyone else it is usually fine (as long as they are not going to crazy with it).

The "platform" team at my company has rolled out a completely custom query language that we have had to learn and write so they don't have to make new endpoints to access different combinations of data

And they haven't documented anything

"There are integration tests, those are documentation go read those"

Good times

Re: The Startup CTO's Handbook

#137

Post by [deleted] »

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…

[deleted]

Re: The Startup CTO's Handbook

#138

Post by chasd00 »

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…

i think this is where a large portion of the tech consulting market comes from. Someone in business gets absolutely fed up dealing with IT and trying to get something they need in production. Next, they go find a budget, call a couple firms, get some proposals, pick one, and do it themselves.

Re: The Startup CTO's Handbook

#139

Post by scarface_74 »

film42 wrote: post #132
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…

IMO the architect-leader role is an attempt at scratching the itch of not being able to code. I've worked with leaders that would spend any extra time they had building projects in new frontier tech to understand the nuances behind the marketing, and I'm sure we've all worked with folks that blindly parrot the marketing speak in design meetings. You don't have to always be building things to be a great leader, but I…

I can build POCs, or I can just come up with high level ideas and ask my most senior architects to do the research and build the POC to see if my ideas are feasible.

And I avoid “frontier tech” as often as possible. I want to base my implementation on proven technology with a healthy ecosystem. I don’t want to use “frontier tech” just to read a blog post six months later about “our amazing journey”.

(I’m not a CTO. I am a tech/implementation lead).

Re: The Startup CTO's Handbook

#140

Post by x0x0 »

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.

And take the calls.

Don't like being paged at 3am? Write robust software and test.

Post reply on HN