Ask HN: Is it expected of a new CTO to redefine the development stack?

2 points by zeeone ↗ HN
The company hired a new CTO. He's taken it upon himself to set the development stack for both back and front end development. Our application is migrating to micro services. Is it normal for a CTO to set a single technology to be used in all services?

3 comments

[ 3.4 ms ] story [ 14.5 ms ] thread
It's an example of a larger pattern, which is that new execs like to shake things up. There are charitable and uncharitable explanations of why, but really it varies by individual.
It depends.

A CTO is responsible for ensuring that the company is able to deliver what’s needed, and if the current stack has issues, including ok-now-but-won’t-scale issues, then they should switch it out for one that positions the company for success.

OTOH, it could be motivated by a range of unjustifiable things: personal familiarity, resume building, blind trend following, asserting of authority, etc.

In most cases, the engineering staff can tell whether the motivation is good or not.

Rewrites are dangerous for companies. They cost time and their benefit is small at best, often they leave the system in a worse state, see "Things You Should Never Do, Part I" [1]. As a CEO I would be very suspicious if a CTO rewrites the stack.

That said I did come into companies as CTO where I should have started a rewrite. The code plainly was not able to scale the way it was written. We had lots of trouble with scaling and I struggled balacing feature pressure and technical rewrites of parts of the code base in order to scale. Getting in and start with rewriting the code base for 6 months so it would scale would have made things much easier for all developers.

As a CTO coach this is also what I tell my coachees now :-)

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...