Hacker News Reader

Comment by dberg | Hacker News Reader

"If the team wants to do TDD, or pair programming, or staging servers - they get it all approved by the CTO. It’s up to him to consider the bigger impact of those changes."

As a CTO, my team knows I do not need to approve what the team wants in regards to TDD or how many environments they feel they need. We operate in a mode of "do whats best" and engineers smarter than me sure as shit dont need me to rubber stamp approval of writing unit tests. I absolutely create an environment that encourages high quality products and a robust testing process. How they accomplish that is up to them.

View on HN

I think the more abstract point the author was trying to make with that statement was that teams should be allowed to define what they want to do, but the CTO is the one who should be keeping an eye on the impacts of those decisions with respect to the rest of the organization.

A good CTO is a bullshit deflector. And sometimes that bullshit is in the form of "Why should an engineer have to consider decades-long maintenance timelines including projects he or she isn't even associated with?" Sometimes the CTO needs to say "No" to a proposal, but the benefit to the engineer is the rest of the time they're isolated from having to think about impacts they don't want to.*

*All of this is only applicable to orgs past a certain size

Fair point. I initially interpreted it as overly draconian, perhaps incorrectly.

The trick is, IMO, when the team does not accomplish things to your satisfaction, you need to be capable of stepping in and changing things, even if your developers don't like it.

To me these sound more like VP Eng. decisions than CTO decisions anyway. I suppose if you're so small you don't have both positions, they would rise to the CTO.

This sounds like micromanagement, even from a VP of engineering. The CTO should be setting long term vision and roadmaps, VP checking things are progressing & handling the majority of the business side (hire/fire, sexual harassment + behavioural issue), then directors down deciding how to do things.

  > Sometime down the road legacy applications become expensive to manage,
  > but rewrites almost always deliver zero value to the customer.

What a weird thing for a CTO to say. Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance that against the time for the project & make a call that in 6/12/X months, we will have recovered the cost of the rewrite & be saving the company month money (which then can be used to develop more user-facing features, improve performance, etc.)

>Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance....

It's not all that weird for a startup CTO / technical cofounder to say, because in those companies velocity is king, queen and the jack of diamonds; rewriting code is a waste because you're only worried about the next milestone, which is no more than six to nine months out.

Mature orgs operate at a different cadence, where your analysis is spot on. (Unfortunately, it often doesn't hold for them either; I've had contracts where I ended up scoping in IT project valuation methodologies so CTOs and/or IT managers could learn how to translate savings into defensible balance-sheet numbers, since the business would only accept "real" savings or revenue enhancement as justification.)

There are of course different rules at different scales for a company. But in general if you were engineer #1 becoming a CTO and your team can't function and govern autonomously once its reached a size where you step away from daily commits, you have failed to grow a competent tech lead for the role.

It sounds like you basically said you don't do shit and you're not good enough to approve their decisions.

What do you do better than other people that justifies your title?

Reply on news.ycombinator.com