

Suggesting Technical Improvements - throughnothing
https://www.tildedave.com/2015/07/22/suggesting-technical-improvements.html

======
actionscripted
> _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.

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

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

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

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

