I have worked at a dozen startups, some failed, some grew and still exist, some were acquired and people made a shit load of money.
I have never been at a startup that failed for technical/technology reasons. All failures I've seen were due to issue with delivering what customers were interested in paying money for. Most often, product owners and developers were not able to establish good communication, which led to developers basically creating a product that didn't match what customers wanted. Period.
I would be interested in your definition of technical debt though. What some people call "technical debt" or "hack", I often call "the best/fastest way to address the current business concern and deliver immediate value". In a startup environment I think these is a critical workflow.
> " Most often, product owners and developers were not able to establish good communication, which led to developers basically creating a product that didn't match what customers wanted. Period."
Thanks a bunch for pointing this out! It's important for me to hear this here :).
Regarding my definition of technical debt is this:
* Lack for proper documentation where on boarding devs is becoming a burden.
* Lack of written tests to a point writing new features is almost inevitable from breaking the product.
* Delayed refactoring which has led to serious performance issues.
* Lack of alignment to standards where the engineers have written everything in Javascript like a 5 years old painting all the wall with same color, rather than using a different language for some specific purposes.
Some other Technical Debts that I meant were:
* How engineers go on a trajectory of writing code where no one knows something new have been added.
* Lack of clarity who have done what, regardless Code commits, this one is about knowing who lead a milestone or a feature to production.
At one startup I worked at, most of the developers were very young and had their first job, nevermind first job with stock options as part of compensation.
When it came time for a round of financing, I was leading a team meeting when the subject of dilution came up: "Are we being screwed?" And I had to explain that a smaller percentage of a company with a higher valuation isn't "being screwed." and attendant to that we discussed cost of capital, classes of shares, preferences, ratchets, etc. You could see the light bulbs coming on as I explained.
Engineers are smart. If you explain to them that "good enough with the money we've got" will make them more money later, they are usually OK with deferring both money and correctness gratification.
Think of it as building empathy for "product owners" who might otherwise be dismissed as beancounters.
If you explain to them that "good enough with the money we've got" will make them more money later, they are usually OK
That's true. Some engineers won't take the "just make it good enough" approach, but I believe most will - otherwise they don't belong in a startup.
I wasn't mentioning the broken communication between PO and devs in this regard though. I have seen teams where the PO were not able to describe what they wanted, what business value they wanted to add to the product, devs had to come up with their own description of feature and sure enough the market didn't care of that.
PO is such a critical position, and such a difficult one to fill. I can count on one hand the companies where I worked who understood that. A PO is not just moving tickets around in JIRA, they are in charge of describing in actionable terms the business value the team is trying to produce.
Comments
I have worked at a dozen startups, some failed, some grew and still exist, some were acquired and people made a shit load of money.
I have never been at a startup that failed for technical/technology reasons. All failures I've seen were due to issue with delivering what customers were interested in paying money for. Most often, product owners and developers were not able to establish good communication, which led to developers basically creating a product that didn't match what customers wanted. Period.
I would be interested in your definition of technical debt though. What some people call "technical debt" or "hack", I often call "the best/fastest way to address the current business concern and deliver immediate value". In a startup environment I think these is a critical workflow.
Thanks a bunch for pointing this out! It's important for me to hear this here :).
Regarding my definition of technical debt is this:
* Lack for proper documentation where on boarding devs is becoming a burden.
* Lack of written tests to a point writing new features is almost inevitable from breaking the product.
* Delayed refactoring which has led to serious performance issues.
* Lack of alignment to standards where the engineers have written everything in Javascript like a 5 years old painting all the wall with same color, rather than using a different language for some specific purposes.
Some other Technical Debts that I meant were:
* How engineers go on a trajectory of writing code where no one knows something new have been added.
* Lack of clarity who have done what, regardless Code commits, this one is about knowing who lead a milestone or a feature to production.
At one startup I worked at, most of the developers were very young and had their first job, nevermind first job with stock options as part of compensation.
When it came time for a round of financing, I was leading a team meeting when the subject of dilution came up: "Are we being screwed?" And I had to explain that a smaller percentage of a company with a higher valuation isn't "being screwed." and attendant to that we discussed cost of capital, classes of shares, preferences, ratchets, etc. You could see the light bulbs coming on as I explained.
Engineers are smart. If you explain to them that "good enough with the money we've got" will make them more money later, they are usually OK with deferring both money and correctness gratification.
Think of it as building empathy for "product owners" who might otherwise be dismissed as beancounters.
That's true. Some engineers won't take the "just make it good enough" approach, but I believe most will - otherwise they don't belong in a startup.
I wasn't mentioning the broken communication between PO and devs in this regard though. I have seen teams where the PO were not able to describe what they wanted, what business value they wanted to add to the product, devs had to come up with their own description of feature and sure enough the market didn't care of that.
PO is such a critical position, and such a difficult one to fill. I can count on one hand the companies where I worked who understood that. A PO is not just moving tickets around in JIRA, they are in charge of describing in actionable terms the business value the team is trying to produce.
Agneed: Weak PO or weak product management will sink you.
@Zigurd, this is some Dev- fron-tline deep wisdom right here!