Suggesting Technical Improvements | Hacker News Reader

Suggesting Technical Improvements

tildedave.com

> You must implement a prototype. This prototype doesn't need to be "ready to merge", but it does need to be a basically complete solution to the problem at hand. You can't have a meeting to propose a big piece of work that you'll only do if the team agrees. You are basically producing a demo. Demos can cut corners on certain things (tests for one), but the main goal is to prove that the idea is a viable one and will work within your codebase. It's not useful to suggest a solution that is done outside of the context of your technology stack.

> Where can you find time to create this demo? You'll want buy-in from your supervisor (if they're a good one hopefully they'll encourage you!) Otherwise (to steal a line from Hunter S. Thompson), I hate to advocate nights and weekends, but they've always worked for me. (I do understand this isn't how it works for everyone...)

Having to work nights and weekends to build a working prototype to get in-house buy-in on new functionality makes little sense to me. If your team cannot work together well enough to agree on new features without them being built first then perhaps the issue isn't feature adoption.

The author first suggests getting supervisor buy-in as a means for allocating resources towards a demo. It doesn't sound like he's mandating that you work nights and weekends to prototype.

So, this actually reminds me of a super sore point, and so a quick Angersock PSA:

Hey! Hey you! New founding CTO!

If somebody on your team comes to you with a technical improvement, support them. Ask what they need, setup dedicated work time (not some after-hours exploitation) to explore the idea, have the present, pay attention, and generally act like you give a damn about the quality of your codebase.

You don't have to promise to roll out the hottest new Reactular ES9 framework immediately, or even that you'll assign other engineering resources to it. You don't have to say "let's refit everything". You certainly don't have to take such suggestions on faith.

But you can do so much damage to your team, especially your early engineers, by being negative and conservative and saying "no" or "not yet" to everything.

Don't fuck this up.

Also, never say no just because you don't understand the new tech or language. Your job, as the chief technology officer, is to be constantly on the bleeding edge--even if you don't use that in production.

If you say no because you're uncomfortable learning or because it might mean the team may have to learn some new things, you are being lazy at your job and your displaying mistrust in your team.

Best PSA in a while. I left a job once largely out of friction with the top decision-maker (not actually the CTO, a director-level, but functionally the same thing) where there was tons of fear around well-established technologies that the decision-maker had never gotten around to learning and pretty obviously didn't trust that we had a handle on it. The visible lack of trust led to defensiveness all around (us because we weren't feeling trusted, him because he thought we thought he was dumb), and nobody who championed those ideas were there six months later and the company's tech-debt hole had only grown deeper.

Your PSA comes from the perspective of a smart employee with good ideas falling on deaf ears with the dumb CTO.

What of the good CTOs who have mediocre teams with a lot of bad ideas that are poorly thought out?

Note: if you answer with something like "CTO should quit", "CTO should fire them", you fail this question.

In the case of a truly bad idea, it is the duty of the CTO/VP Eng/Team lead to give the employee the time to explore the idea/discuss it and realize why it's a bad idea. The employee should grow as a result of the experience, and become more valuable in the future.

On the off chance they don't learn, and the situation repeats itself, it may be prudent to refuse such requests.

That having been said, the worst situation is when the boss agrees that it needs to get done, but can't find where to sneak it into the schedule. It's effectively saying that you don't value the happiness of your employees and can't schedule/push hard enough.

If the CTO doesn't respect the team ("they're mediocre"), that's a problem. CTO needs to accept the materials at hand, and build a framework for growing those employees and protecting them from their own ingenuity--if the "right way" of doing something is so much easier than the alternative, and its practice is explained and documented, then the rest should see to itself.

That conservative policy still leaves room for explaining why a given bad idea is bad, or for exploring that idea for like a workday or two so the employee can figure out why it's bad.

If after all this the CTO is still besieged by idiots, they should leave...either because they have failed their team, or because the team is deadset against succeeding.

Reply on news.ycombinator.com