Generally speaking if you are capable of leading a startup as a CTO, you should just found your own, with the legal CEO designation, so that you can control what happens to the equity. CTOs in general are very naive about how all of this works once PMF/traction is hit, and how little power they have over the platform they built
I kind of enjoy working with partners, especially when everyone "knows their lanes" and agreements are properly defined. It just tends to blow up at some point it seems like... :)
The main goal is to keep a pulse on finances.
In any case, "start my own" is still on my todo, it's just... not that easy to pull of :))
From 2024. Sorry, should have added that to the title when I submitted it.
I personally loved the takeaways. They resonated with my startup experience, esp: "Not all business problems require technical solutions". I think as devs/engineers, we're in love with technical solutions, but they are not always the right choice. Other options include:
* customer support
* duct tape solutions with platforms like Zapier
* saying "we are not going to solve that problem" and letting folks that need that solution go somewhere else
We are still going, but it's a bumpy road. One of main products got delayed by partnering financial institution, which sent us into money crunch mode.
At the moment our engineering is ahead of our sales - which gave me some capacity to lift my head up and test my skills relevance against the market on the fractional/advisory capacity potentially turning into revenue stream with more control from my side.
You know how it works for us with engineering minds - you always consider worst case scenarios and try to mitigate them before they become real problems.
Based on my experience it typically works in cycles, where you need some sort of fresh blood every five or so years to re-kindle the spark and keep going.
I don't look at this like that, not any more at least.
It's been great five years for me and my family, exactly what I was looking for before the transition from stable corporate world.
I guess it depends a lot of personality and the type of work you enjoy. I thrive at early stages, where most things a built on common sense and you have enough power to shape things into something meaningful.
These days I try to appreciate "the process" (day-to-day) over "results" (exits).
You don't really have too much control of how things unfold in your life really, be blessed you are alive and kicking.
Do I say money is not important? Of course not - it's very important, but in a challenging times you have to test your limits and re-assess your priorities (whether you like it or not...)
It's easy to look at things in hindsight - the question is what is the alternative? 5 years of what?
While I thought this was a pretty good read, I didn't really feel like it answered the question in the title: "was it worth it"?
First, this post was from 2024, and as another commenter mentioned, it doesn't look like Helios Companies (www.helioscompanies.com) is a going concern anymore. That's not that surprising - the change in the interest rate and VC funding environment killed off lots of unprofitable fintechs that were originally funded in 2021 or earlier.
I'm not saying money is the end all and be all, and this guy certainly got a lot out of it. But assuming this company is now defunct and he didn't get any substantial payday out of it, would he do it again knowing what he knows now? When you think about it, we all have relatively very limited time in our careers - while VCs can fund 100 different companies with the expectation that 95% will fail, workers don't have that luxury. Putting in 5+ years of lots of late nights and blood, sweat and tears can be tough if the outcome isn't a winner.
So I'm left wondering if the author feels like it was still worth it.
I'm curious about the simple, lightweight change management process listed in the article. Anyone have any tips on doing this well? I kind of hate the part of having to convince everyone of something "obviously better" :)
- Jira Epics (describe the why from the business standpoint)
- HQ meets two times a week to re-asses priority (drag up Epics up or down, or change priority) and monitor status
- Two week sprints where engineering leads along go through epics
- New sub-tickets created by engineering (including design) and assigned to specific people.
- Once thing are getting done, they are move to QA test status. After testing it either goes back to engineering or to Release Approved status.
- Engineer initiates and monitors the the release via CI/CD Jenkins pipeline.
That's pretty much it on the high level, unless I'm forgetting something.
One important note here - some time ago we made a decision to ignore "good ideas"/backog. We don't keep them in Jira until business is sure that we really need this particular functionality and ready to start building it right now.
That was somewhat radical and took some time to get used to, but it allowed everyone to focus on what's important now vs nice to haves to keep people busy with things noone really needs.
Overall there is no "generic" advice, everything is very org and stage specific. Common sense is the main guiding principle.
One could do worse than asking for major decisions to come with a (ultralight, readme like) platform/product enhancement proposal (PEP).
Then, in a group, probing together for 12 factor app or AWS well architected type principles as well as something like BSA security principles, gets you a very long way.
The framework doesn't matter, just something to cause a beat of design, ops, and threat modeling and "rugged manifesto" thinking.
All sorts of questions - "What's the best way to do X?", "How would it impact security?", "Why we need this?", "What happens if this fails?", "Remind me how this works?", "Am I thinking in the right direction?"
Even more questions to the business / CEO ( Why this, why now )
"why", "how", "can we", "who can"?
Just try to be humble in the world where nobody knows anything (including yourself)... :)
> When I was younger I thought QA was the thing from the good “old days” that should be replaced with the automated tests suit. After accidentally hiring one great QA engineer I quickly changed my mind. Today I would say it’s one of the most important departments on my list. The amount of my time saved by QA team is insane.
If the author is reading - can you elaborate on this?
At the end of the day someone needs to answer a simple question - "Is the product functional right now / after the last release?".
If you don't have QA team you either rely on your product person to "give it a spin" or your engineering who are generally not very excited about clicking through the product multiple times (more often than not, they'll just leave it at the unit test phase and move on).
In small orgs that product person could be your CEO or CTO, meaning this will give them an easy false-escape into "micro-management" mode (aka feeling productive by doing low priority tasks) vs forcing them to make strategic decisions or worse, they'll just block the entire pipeline.
QA creates a natural quality gate looking at the product from the user's perspective, putting pressure at the engineering to deliver quality work and gathering leadership feedback at critical points only.
20 comments
[ 3.7 ms ] story [ 37.8 ms ] threadI kind of enjoy working with partners, especially when everyone "knows their lanes" and agreements are properly defined. It just tends to blow up at some point it seems like... :)
The main goal is to keep a pulse on finances.
In any case, "start my own" is still on my todo, it's just... not that easy to pull of :))
I personally loved the takeaways. They resonated with my startup experience, esp: "Not all business problems require technical solutions". I think as devs/engineers, we're in love with technical solutions, but they are not always the right choice. Other options include:
* customer support
* duct tape solutions with platforms like Zapier
* saying "we are not going to solve that problem" and letting folks that need that solution go somewhere else
At the moment our engineering is ahead of our sales - which gave me some capacity to lift my head up and test my skills relevance against the market on the fractional/advisory capacity potentially turning into revenue stream with more control from my side.
You know how it works for us with engineering minds - you always consider worst case scenarios and try to mitigate them before they become real problems.
Based on my experience it typically works in cycles, where you need some sort of fresh blood every five or so years to re-kindle the spark and keep going.
It's been great five years for me and my family, exactly what I was looking for before the transition from stable corporate world.
I guess it depends a lot of personality and the type of work you enjoy. I thrive at early stages, where most things a built on common sense and you have enough power to shape things into something meaningful.
These days I try to appreciate "the process" (day-to-day) over "results" (exits).
You don't really have too much control of how things unfold in your life really, be blessed you are alive and kicking.
Do I say money is not important? Of course not - it's very important, but in a challenging times you have to test your limits and re-assess your priorities (whether you like it or not...)
It's easy to look at things in hindsight - the question is what is the alternative? 5 years of what?
First, this post was from 2024, and as another commenter mentioned, it doesn't look like Helios Companies (www.helioscompanies.com) is a going concern anymore. That's not that surprising - the change in the interest rate and VC funding environment killed off lots of unprofitable fintechs that were originally funded in 2021 or earlier.
I'm not saying money is the end all and be all, and this guy certainly got a lot out of it. But assuming this company is now defunct and he didn't get any substantial payday out of it, would he do it again knowing what he knows now? When you think about it, we all have relatively very limited time in our careers - while VCs can fund 100 different companies with the expectation that 95% will fail, workers don't have that luxury. Putting in 5+ years of lots of late nights and blood, sweat and tears can be tough if the outcome isn't a winner.
So I'm left wondering if the author feels like it was still worth it.
- Jira Epics (describe the why from the business standpoint)
- HQ meets two times a week to re-asses priority (drag up Epics up or down, or change priority) and monitor status
- Two week sprints where engineering leads along go through epics
- New sub-tickets created by engineering (including design) and assigned to specific people.
- Once thing are getting done, they are move to QA test status. After testing it either goes back to engineering or to Release Approved status.
- Engineer initiates and monitors the the release via CI/CD Jenkins pipeline.
That's pretty much it on the high level, unless I'm forgetting something.
One important note here - some time ago we made a decision to ignore "good ideas"/backog. We don't keep them in Jira until business is sure that we really need this particular functionality and ready to start building it right now.
That was somewhat radical and took some time to get used to, but it allowed everyone to focus on what's important now vs nice to haves to keep people busy with things noone really needs.
Overall there is no "generic" advice, everything is very org and stage specific. Common sense is the main guiding principle.
Then, in a group, probing together for 12 factor app or AWS well architected type principles as well as something like BSA security principles, gets you a very long way.
The framework doesn't matter, just something to cause a beat of design, ops, and threat modeling and "rugged manifesto" thinking.
https://ruggedsoftware.org
Even more questions to the business / CEO ( Why this, why now )
"why", "how", "can we", "who can"?
Just try to be humble in the world where nobody knows anything (including yourself)... :)
If the author is reading - can you elaborate on this?
At the end of the day someone needs to answer a simple question - "Is the product functional right now / after the last release?".
If you don't have QA team you either rely on your product person to "give it a spin" or your engineering who are generally not very excited about clicking through the product multiple times (more often than not, they'll just leave it at the unit test phase and move on).
In small orgs that product person could be your CEO or CTO, meaning this will give them an easy false-escape into "micro-management" mode (aka feeling productive by doing low priority tasks) vs forcing them to make strategic decisions or worse, they'll just block the entire pipeline.
QA creates a natural quality gate looking at the product from the user's perspective, putting pressure at the engineering to deliver quality work and gathering leadership feedback at critical points only.