4 ms·

>It is the job of the CTO to steer excitable juniors away from the new hotness, and what might look best on their resumes, towards what is tried, true, and ulti

>It is the job of the CTO to steer excitable juniors away from the new hotness, and what might look best on their resumes, towards what is tried, true, and ultimately best for the business. Then they might simply join another startup or a big tech company as competition for good engineers is fierce. Startups also famously underpay versus larger companies so you need to entice engineers with something.

encoderer 7y ago
It’s ok to let them go.
- marcinzm 7y ago
  That depends on the situation and is the CTO's decision to make. Given the difficulty and time frames of hiring letting go could mean another 6 months of too few engineers. Acting like there is a single universal answer is the wrong world view I'd say.
  - wpietri 7y ago
    If you have a nominally full compliment of people who are over-building or playing around with shiny toys instead of delivering value, then you still have too few actual engineers, but are paying a lot more money for the privilege. You're also setting up a bill that will come due eventually. I've made some really good money going into companies and ripping out the hot-three-years-ago garbage that some long-gone goof put in. Last time this happened I looked up the responsible party. Turned out he was doing the work so he could give a conference talk on shiny tech. Not long after the talk was done, he took a job somewhere else, leaving his buzzword-compliant half-baked system to rot.
ragebol 7y ago
Maybe you need less engineers trained in the new hotness but just experience with, uh, older hotness. Which may be easier to find.
- marcinzm 7y ago
  Engineers want what is best for them and not what is best for the company. That is the right choice for them. New hotness is one way to entice them. Far, far from the only one but it is a tool in the CTO's tool belt.
  - eeZah7Ux 7y ago
    > New hotness is one way to entice them. Only the bad ones.
  - TeMPOraL 7y ago
    Then consider this: a startup in its job ad is probably simultaneously talking about the hottest new tech and passion for building a reliable product. But the intersection between these two is vanishingly small. So what kind of hires do you want to optimize for? CV-driven developers, or people who know how to build reliable and efficient software fast?
  - kabdib 7y ago
    This is why you need to be interviewing for things like "customer focus" as well as the technical side of things. I've rejected candidates who have been great on their technical skills . . . who I would never want to be making ANY decisions about customers, or the technical direction of the company.
  - karatestomp 7y ago
    Developers will stop caring about having experience in the latest hot thing when that stops being very important in interviews. I hope, but doubt, that will happen before I'm retired or have been ageism'd into something else.
  - alexbanks 7y ago
    I feel like for any company, there should probably be a balance between old a new. If all of the technology from 10 years ago was inarguably "the best", I don't think we'd be in the situation we're in now. Everything is pros and cons. My team right now, for example, had a mantra of "No JS frameworks, just Rails" which was absolutely dreadful. Rails UI is absolutely dreadful. I can't say enough, it is absolutely dreadful. So we recently made the move to use React for more "dynamic" UIs, which has brought up somewhat of a happy medium? React will be here in 5 years, Rails will be here in 5 years, everyone wins.
jerf 7y ago
Well, when you pay your engineers 6-12 months of extra salary before you ship anything because they had to use Kubernetes-on-Highways to host this clever NoNoNoPleaseNoSQL DB hosted that some guy on Github wrote last week, hosted on ZeroNinesAsAService.com and with a new UI built in ThreeReact (the hot new React-based framework that implements an OpenGL interface that works on approximately 3% of devices in the wild right now, and approximately 0% of your target user base's devices), don't forget to account for that in the investor pitch and salary offers. I mean, seriously, this is a startup killer. Our host wrote an essay a long time ago about beating standard companies stuck in boring old Java or C++ with your fast, agile Python code, but in 2020 it seems to me it's almost more important now to try to convince new startups to be a little more boring. Whatever your special sauce that you're bringing to market is, it isn't (with no disrespect to the relevant communities) that you're bringing in Rust or Nim or whatever for the first time ever, for Maximum Velocity. Just use Python, cloud technologies, and established databases. Win on solving your customer needs. While by no means is everyone in the world using effective tech stacks well-chosen to meet the needs and without over-privileging "what everyone else is doing and what has always been done", enough people are now that it's probably not a competitive advantage anymore. Honestly, you can beat most companies in just getting stuff out the door quickly. (Excuse me, off to file incorporation papers for ZeroNines LLC. Why wonder whether your provider will be up when you can know? Nobody else in the business can make that promise!)
- marcinzm 7y ago
  >when you pay your engineers 6-12 months of extra salary before you ship Money may not be the limiting factor for a startup and time is a counter-factual as you don't know the alternative. Had they not been able to hire any engineers they may have taken an extra 2 years to ship the same thing. Or maybe not. Hiring at startups is time consuming and difficult with heavy competition for good engineers. Salaries lag behind large tech companies and equity may be worth nothing. Scale isn't there so the problems are less interesting than at a larger company. And good engineers can 5x better than average in an early stage startup because there is no process and technical debt is fine (in a larger organization the 10x ones leave havoc in their wake). That may not be the right decision for a startup to make but there is a logical basis for making it.
wpietri 7y ago
If they are more focused on playing with toys or polishing their resumes for their next job, then I'd want them to leave. Their goal should be understanding what users need and building it as simply and effectively as possible.
rurp 7y ago
On the flip side, a lot of developers are more motivated by what they can actually build and release with their tools, rather than learning new and complicated tools for the heck of it. If I were running a company I'd much rather court devs in this group.
nostrademons 7y ago
This is a really good argument for why startups should build the initial product with only the founding team, and hire only once you have more demand than you can possibly handle. You get mission-alignment from your technical team (because they only get paid if they ship and customers appear), and then finding and retaining engineers is a lot easier once you're clearly a rocket-ship, their stock options double in value every 6 months, and they become a manager after 6 months in the company.

encoderer 7y ago

It’s ok to let them go.

marcinzm 7y ago
That depends on the situation and is the CTO's decision to make. Given the difficulty and time frames of hiring letting go could mean another 6 months of too few engineers. Acting like there is a single universal answer is the wrong world view I'd say.
- wpietri 7y ago
  If you have a nominally full compliment of people who are over-building or playing around with shiny toys instead of delivering value, then you still have too few actual engineers, but are paying a lot more money for the privilege. You're also setting up a bill that will come due eventually. I've made some really good money going into companies and ripping out the hot-three-years-ago garbage that some long-gone goof put in. Last time this happened I looked up the responsible party. Turned out he was doing the work so he could give a conference talk on shiny tech. Not long after the talk was done, he took a job somewhere else, leaving his buzzword-compliant half-baked system to rot.

ragebol 7y ago

Maybe you need less engineers trained in the new hotness but just experience with, uh, older hotness. Which may be easier to find.

marcinzm 7y ago
Engineers want what is best for them and not what is best for the company. That is the right choice for them. New hotness is one way to entice them. Far, far from the only one but it is a tool in the CTO's tool belt.
- eeZah7Ux 7y ago
  > New hotness is one way to entice them. Only the bad ones.
- TeMPOraL 7y ago
  Then consider this: a startup in its job ad is probably simultaneously talking about the hottest new tech and passion for building a reliable product. But the intersection between these two is vanishingly small. So what kind of hires do you want to optimize for? CV-driven developers, or people who know how to build reliable and efficient software fast?
- kabdib 7y ago
  This is why you need to be interviewing for things like "customer focus" as well as the technical side of things. I've rejected candidates who have been great on their technical skills . . . who I would never want to be making ANY decisions about customers, or the technical direction of the company.
- karatestomp 7y ago
  Developers will stop caring about having experience in the latest hot thing when that stops being very important in interviews. I hope, but doubt, that will happen before I'm retired or have been ageism'd into something else.
- alexbanks 7y ago
  I feel like for any company, there should probably be a balance between old a new. If all of the technology from 10 years ago was inarguably "the best", I don't think we'd be in the situation we're in now. Everything is pros and cons. My team right now, for example, had a mantra of "No JS frameworks, just Rails" which was absolutely dreadful. Rails UI is absolutely dreadful. I can't say enough, it is absolutely dreadful. So we recently made the move to use React for more "dynamic" UIs, which has brought up somewhat of a happy medium? React will be here in 5 years, Rails will be here in 5 years, everyone wins.

jerf 7y ago

Well, when you pay your engineers 6-12 months of extra salary before you ship anything because they had to use Kubernetes-on-Highways to host this clever NoNoNoPleaseNoSQL DB hosted that some guy on Github wrote last week, hosted on ZeroNinesAsAService.com and with a new UI built in ThreeReact (the hot new React-based framework that implements an OpenGL interface that works on approximately 3% of devices in the wild right now, and approximately 0% of your target user base's devices), don't forget to account for that in the investor pitch and salary offers. I mean, seriously, this is a startup killer. Our host wrote an essay a long time ago about beating standard companies stuck in boring old Java or C++ with your fast, agile Python code, but in 2020 it seems to me it's almost more important now to try to convince new startups to be a little more boring. Whatever your special sauce that you're bringing to market is, it isn't (with no disrespect to the relevant communities) that you're bringing in Rust or Nim or whatever for the first time ever, for Maximum Velocity. Just use Python, cloud technologies, and established databases. Win on solving your customer needs. While by no means is everyone in the world using effective tech stacks well-chosen to meet the needs and without over-privileging "what everyone else is doing and what has always been done", enough people are now that it's probably not a competitive advantage anymore. Honestly, you can beat most companies in just getting stuff out the door quickly. (Excuse me, off to file incorporation papers for ZeroNines LLC. Why wonder whether your provider will be up when you can know? Nobody else in the business can make that promise!)

marcinzm 7y ago
>when you pay your engineers 6-12 months of extra salary before you ship Money may not be the limiting factor for a startup and time is a counter-factual as you don't know the alternative. Had they not been able to hire any engineers they may have taken an extra 2 years to ship the same thing. Or maybe not. Hiring at startups is time consuming and difficult with heavy competition for good engineers. Salaries lag behind large tech companies and equity may be worth nothing. Scale isn't there so the problems are less interesting than at a larger company. And good engineers can 5x better than average in an early stage startup because there is no process and technical debt is fine (in a larger organization the 10x ones leave havoc in their wake). That may not be the right decision for a startup to make but there is a logical basis for making it.

wpietri 7y ago

If they are more focused on playing with toys or polishing their resumes for their next job, then I'd want them to leave. Their goal should be understanding what users need and building it as simply and effectively as possible.

rurp 7y ago

On the flip side, a lot of developers are more motivated by what they can actually build and release with their tools, rather than learning new and complicated tools for the heck of it. If I were running a company I'd much rather court devs in this group.

nostrademons 7y ago

This is a really good argument for why startups should build the initial product with only the founding team, and hire only once you have more demand than you can possibly handle. You get mission-alignment from your technical team (because they only get paid if they ship and customers appear), and then finding and retaining engineers is a lot easier once you're clearly a rocket-ship, their stock options double in value every 6 months, and they become a manager after 6 months in the company.