This is why if you're joining a startup as an employee you should ask for either a competitive market salary or real equity (not the insultingly low amount that normally gets offered as equity -- an actual stake).
I think a lot of people join startups and take a bad deal because they think the company will take care of them when the company makes it. Or they think they'll have more opportunity for promotions in the startup because of its small size and their early stake. The problem is usually executive roles are filled from outside the company rather than from internal promotions, and as this article illustrates, the founders don't necessarily care about the people at the bottom until it's bluntly pointed out to them how mass departures could fuck up the business.
I'm curious for you to expand on what you mean by real equity? I was hired as the first backend developer at an enterprise startup last August. they told me they were securing next round of funding (all family money so far) by end sept/oct and at that point id get market salary (Ive been at ~40% less since hire). in november when it was clear we wouldn't have the funding or revenue to raise salaries, I negotiated another point in equity and higher six figure salary when we do get funding/or revenue. we agreed (me and CEO) that we would reevaluate things in April. now it's almost June and I still held off on having our next talk bc even though we launched a month ago, were still another 1-2 months away from realistically getting revenue. I am at 2% equity which he says is more than any other employer but I'm not sure what my next move is. I'm senior level full stack and do much more than I was hired for from client to backend to devops and helping lead. if I stay longer, how much equity should I go for? again I was told my salary would go to market by sept/oct last year prior to me starting... thanks!
I'm at a startup where I found out a junior hire -- worse in every way than myself and several steps down in title -- is making at least 30% more than I am. It's a strange position. I've started polishing my resume as a result.
Another reason why organizational debt can be worse than technical debt is that often in the case of technical debt, the engineers know what the proper solution is, but given time constrains, they opt for a solution that merely meets their current needs. But with organizational debt, often the immature company does not even know what the proper solution would be.
And then, of course, there are cases of both technical debt and organizational debt where the people in charge don't even realize that they've incurred debt. They think they do have the optimal solution.
Just like with technical debt, there is a risk of refactoring organizational debt wrong, or over-refactoring. I believe it happened where I once worked. It worked beautifully as a small company, but when the workforce started exceeding 100, the need for better HRM, more formal performance evaluation, better defined reporting hierarchies and career paths became evident. A lot of processes were introduced, but the way it was done induced culture shock in people who had been in the company a long time. I think we lost a few good brains as a result.
There's an argument to be made that those good brains that the company lost were necessary to lose; I know myself that a business can hit this point, I've been there myself as an employee when it happened. I'm one of those developers that isn't a fan of big formal-ish companies, so I leave when that happens -- that's not a bad thing, as keeping me there will frustrate me and the business long term. Those processes can be super necessary however, so I don't begrudge places the institute them, unless they do it far too soon of course.
What areas of organizational technical debt are there? I counted the piece raised three: unmanaged compensation schemes, lack of systematic onboarding, lack of keeping tally on the most promising employèes and making them know they are valued.
I think there is also a typical pattern that perhaps is too trivial yet not that all too uncommon - lack of organizational restructuring as a company grows (the startup style where some people do everything can create bottlenecks and very high risk bus factors).
I think a very important aspect of scaling is separating responsibilities. In most startups it's often the case that a single person takes on multiple tasks. Those make sense in the early stages, but as the company grows they become a limiting factor.
The problem is that some people get comfortable doing multiple roles. That however means that they can only invest a fraction of their time. This means that early on the company gets something, which is better than nothing, but as it grows it's only getting something and that's not enough.
This is applicable to most potosi on, but becomes org debt when the founder(s) don't "replace" themselves.
Organizational debt can create technical debt and may be the single biggest cause.
Even if you make it with technical debt, somewhere in your org, someone's life is worse because of that technical debt, but the cause was probably organizational debt. The good employees see it sooner and suffer it longer or leave before others see it. A downward spiral in other words with entropy increasing.
> Organizational debt can create technical debt and may be the single biggest cause.
I agree with this. E.g. an organisation without a clear and concrete vision (but with a lot of fantasy) is inherently creating technical debt since it's unclear to the developers what exactly needs to build and what the important parts are. It's usually that within these organisations every other week a new feature is dreamt up by management that HAS to be included asap or the company might miss out to the competition.
Usually management in these type of organisations also LOVE Agile which to them pretty much means; just make shit up as you go along.
This sound's like an application of Conway's law. Sometimes you make a bad technical decision because the "right" way involves to many political fights
This is a great read and I recommend it to anyone in the 'build' phase of their company. The thing that always amazes me is how the organization of a company can enhance or limit what they can build in technology.
because debt, in the broader sense (financially), is related to economic success. a basic finance course will tell you that there is an optimal level of (financial) debt for a firm.
this should actually be more intuitive outside of finance such as in a technical or organizational setting. for example, the instant a software engineers detects that they have information which suggests they re-architect their software, should they? of course not, because likely even more information will then being to surface which could completely change their architectural strategy.
I will describe my understanding of "technical debt". It may well be different than your understanding of technical debt, but I think if you look at it this way you will be able to answer the question.
The idea behind a company acquiring debt is to increase the number of possible options now at the expense of increased constraints later. So, for example, you borrow $X today which means that you have the option to buy things that would have been impossible without the loan. Later you must repay the loan which means that you will be able to buy less things.
The hope is that you will be able to leverage the extra money to put yourself into a more advantageous position in the future. Having done so, you can handle the constraint of paying back the debt much more easily. For example, let's say that you borrow $100. You buy a lawnmower with the $100 and use it to mow lawns for $10 an hour. After 2 weeks (80 hours), you have made $800 mowing lawns which would have been impossible without the loan. Paying back the $100 is easy because you have $800 to play with.
As a side note, in early stages of a company growth is often constrained by capital, so it is considered irresponsible not to borrow money by many analysts. You should borrow as much as you can get, up to the level of the constraint because that will maximize your growth.
Enter "technical debt". When doing development, there are often many choices to make. Some choices will result in opportunities now at the cost of constraints later on. For example, imagine that you have a meeting with a VC company. You need a demo that shows the vision of your software. You know that you can not build anything functional in the amount of time you have, so you simply write a throw away demo. None of the code can be used in the final product, but it is good enough to show what you mean and it can win the VC money.
In this case, we have the future constraint that we must completely rewrite all of the demo code after the VC meeting. But we were able to raise capital, and continue building the company due to our efforts.
That's a pretty extreme example, but another example might be something like this. We could do a usability study for your new UI to make sure that it works well for the user right from the beginning. Or we could just code up the simplest UI that we can think of. The second choice will cost less and allow use to get it into the hands of the user early. Possibly this is important because we need to beat our competitor to market with a feature. We will still have to do the usability study at some point, and refactor all of our code, but hopefully we will be in a better position to afford that extra work later on.
Just like real debt, there can be problems. For example, imagine that we borrow $100 and instead of buying a lawnmower, we buy beer and drink it. We've had a good time drinking the beer, but now we owe $100, have no way to pay it back and have a hangover to boot.
The technical equivalent happens far more often to companies than the money thing (although, I often wonder what happened to all those Aeron chairs that the dotcom companies bought up in the late 90s). You often get a naive CEO who thinks, "We should take on as much debt as people will give us because we can leverage it to build growth!". So they say, "Don't worry about the future, just give me code as fast as you possibly can". He isn't sitting there thinking, "I am taking on future constraints, but can I actually use this to leverage my growth?".
You get in a situation where the coders are just hacking their fingers off, but to no actual benefit. You end up with no way of mitigating the bad code (repaying the debt) and you have the headache of dealing with all the grumpy programmers who leave to find a company where they can "do it right".
You asked, "Where is the evidence that technical debt, let alone organizational debt, is actually related to the economic indicators of success?" The answer is that it is not necessarily related. It depends on what you have done with that debt. If you have simply had an orgy of coding madness without leveraging the opportunities to increase growth (as many startups do), then there will be no relation.
My own personal view of this is: programmers should be in charge of the "technical debt bank". They should do their best not to incur debt, but if they are asked to do so they should ask a question of their own, "How are we going to spend this debt?" It is important that the programmers understand the business issues so that they can "loan" an appropriate amount of debt. If the business is basically saying, "Keep giving me debt. I don't care how much. And we're going to spend it on beer and Aeron chairs", then the responsible programmer/banker should perhaps have a serious chat with the business.
If you are with a good organization, though, the answer will usually be of the form, "We need to get features X,Y,Z done by this date so that we can bring in W revenue. Once we have accomplished that we will be in a better place to repay the debt".
[+] [-] overgard|10 years ago|reply
I think a lot of people join startups and take a bad deal because they think the company will take care of them when the company makes it. Or they think they'll have more opportunity for promotions in the startup because of its small size and their early stake. The problem is usually executive roles are filled from outside the company rather than from internal promotions, and as this article illustrates, the founders don't necessarily care about the people at the bottom until it's bluntly pointed out to them how mass departures could fuck up the business.
[+] [-] tallerholler|10 years ago|reply
[+] [-] pckspcks|10 years ago|reply
[+] [-] achille2|10 years ago|reply
This is why Spolksy has his tiered plans where everyone gets paid the same (hiring someone at a higher payrate means raising everyones pay)
http://www.inc.com/magazine/20090401/how-hard-could-it-be-em...
[+] [-] pmccall777|10 years ago|reply
[+] [-] drawkbox|10 years ago|reply
[+] [-] jawns|10 years ago|reply
And then, of course, there are cases of both technical debt and organizational debt where the people in charge don't even realize that they've incurred debt. They think they do have the optimal solution.
[+] [-] hliyan|10 years ago|reply
[+] [-] girvo|10 years ago|reply
[+] [-] fsloth|10 years ago|reply
I think there is also a typical pattern that perhaps is too trivial yet not that all too uncommon - lack of organizational restructuring as a company grows (the startup style where some people do everything can create bottlenecks and very high risk bus factors).
Are there any others?
[+] [-] arielm|10 years ago|reply
The problem is that some people get comfortable doing multiple roles. That however means that they can only invest a fraction of their time. This means that early on the company gets something, which is better than nothing, but as it grows it's only getting something and that's not enough.
This is applicable to most potosi on, but becomes org debt when the founder(s) don't "replace" themselves.
[+] [-] drawkbox|10 years ago|reply
Even if you make it with technical debt, somewhere in your org, someone's life is worse because of that technical debt, but the cause was probably organizational debt. The good employees see it sooner and suffer it longer or leave before others see it. A downward spiral in other words with entropy increasing.
[+] [-] pan69|10 years ago|reply
I agree with this. E.g. an organisation without a clear and concrete vision (but with a lot of fantasy) is inherently creating technical debt since it's unclear to the developers what exactly needs to build and what the important parts are. It's usually that within these organisations every other week a new feature is dreamt up by management that HAS to be included asap or the company might miss out to the competition.
Usually management in these type of organisations also LOVE Agile which to them pretty much means; just make shit up as you go along.
[+] [-] arthurjj|10 years ago|reply
http://en.wikipedia.org/wiki/Conway%27s_law
[+] [-] ChuckMcM|10 years ago|reply
[+] [-] brobdingnagian|10 years ago|reply
[+] [-] spectrum1234|10 years ago|reply
this should actually be more intuitive outside of finance such as in a technical or organizational setting. for example, the instant a software engineers detects that they have information which suggests they re-architect their software, should they? of course not, because likely even more information will then being to surface which could completely change their architectural strategy.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] mikekchar|10 years ago|reply
The idea behind a company acquiring debt is to increase the number of possible options now at the expense of increased constraints later. So, for example, you borrow $X today which means that you have the option to buy things that would have been impossible without the loan. Later you must repay the loan which means that you will be able to buy less things.
The hope is that you will be able to leverage the extra money to put yourself into a more advantageous position in the future. Having done so, you can handle the constraint of paying back the debt much more easily. For example, let's say that you borrow $100. You buy a lawnmower with the $100 and use it to mow lawns for $10 an hour. After 2 weeks (80 hours), you have made $800 mowing lawns which would have been impossible without the loan. Paying back the $100 is easy because you have $800 to play with.
As a side note, in early stages of a company growth is often constrained by capital, so it is considered irresponsible not to borrow money by many analysts. You should borrow as much as you can get, up to the level of the constraint because that will maximize your growth.
Enter "technical debt". When doing development, there are often many choices to make. Some choices will result in opportunities now at the cost of constraints later on. For example, imagine that you have a meeting with a VC company. You need a demo that shows the vision of your software. You know that you can not build anything functional in the amount of time you have, so you simply write a throw away demo. None of the code can be used in the final product, but it is good enough to show what you mean and it can win the VC money.
In this case, we have the future constraint that we must completely rewrite all of the demo code after the VC meeting. But we were able to raise capital, and continue building the company due to our efforts.
That's a pretty extreme example, but another example might be something like this. We could do a usability study for your new UI to make sure that it works well for the user right from the beginning. Or we could just code up the simplest UI that we can think of. The second choice will cost less and allow use to get it into the hands of the user early. Possibly this is important because we need to beat our competitor to market with a feature. We will still have to do the usability study at some point, and refactor all of our code, but hopefully we will be in a better position to afford that extra work later on.
Just like real debt, there can be problems. For example, imagine that we borrow $100 and instead of buying a lawnmower, we buy beer and drink it. We've had a good time drinking the beer, but now we owe $100, have no way to pay it back and have a hangover to boot.
The technical equivalent happens far more often to companies than the money thing (although, I often wonder what happened to all those Aeron chairs that the dotcom companies bought up in the late 90s). You often get a naive CEO who thinks, "We should take on as much debt as people will give us because we can leverage it to build growth!". So they say, "Don't worry about the future, just give me code as fast as you possibly can". He isn't sitting there thinking, "I am taking on future constraints, but can I actually use this to leverage my growth?".
You get in a situation where the coders are just hacking their fingers off, but to no actual benefit. You end up with no way of mitigating the bad code (repaying the debt) and you have the headache of dealing with all the grumpy programmers who leave to find a company where they can "do it right".
You asked, "Where is the evidence that technical debt, let alone organizational debt, is actually related to the economic indicators of success?" The answer is that it is not necessarily related. It depends on what you have done with that debt. If you have simply had an orgy of coding madness without leveraging the opportunities to increase growth (as many startups do), then there will be no relation.
My own personal view of this is: programmers should be in charge of the "technical debt bank". They should do their best not to incur debt, but if they are asked to do so they should ask a question of their own, "How are we going to spend this debt?" It is important that the programmers understand the business issues so that they can "loan" an appropriate amount of debt. If the business is basically saying, "Keep giving me debt. I don't care how much. And we're going to spend it on beer and Aeron chairs", then the responsible programmer/banker should perhaps have a serious chat with the business.
If you are with a good organization, though, the answer will usually be of the form, "We need to get features X,Y,Z done by this date so that we can bring in W revenue. Once we have accomplished that we will be in a better place to repay the debt".
[+] [-] unknown|10 years ago|reply
[deleted]