Organizational debt is like technical debt, but worse(steveblank.com)
steveblank.com
Organizational debt is like technical debt, but worse
http://steveblank.com/2015/05/19/organizational-debt-is-like-technical-debt-but-worse/
77 comments
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!
Yeah... all those promises were what are technically known in the industry as "lies". You will never see a market level salary or even a raise, and once that 2% equity has been through dilution it will be more like 0.2% at most. Sorry, but there's no way this situation will play out well for you. Another thing you probably don't want to hear is that you are not "senior level" if you lack the experience to have figured this out for yourself. Not even close.
You can learn from this and never be played like a sucker again, but many people it takes 2 or 3 goes around to realize. But it's fine for the CEO, there'll be another 22-year-old around to take this deal in a year.
You can learn from this and never be played like a sucker again, but many people it takes 2 or 3 goes around to realize. But it's fine for the CEO, there'll be another 22-year-old around to take this deal in a year.
> Another thing you probably don't want to hear is that you are not "senior level" if you lack the experience to have figured this out for yourself.
There are many examples where I don't think there's a strong connection between the level of professional experience with the familiarity with the startup environment/lingo/negotiation.
There are many examples where I don't think there's a strong connection between the level of professional experience with the familiarity with the startup environment/lingo/negotiation.
There is nothing really startup-specific in the scenario. There are exploitative bosses in all industries and all sizes of company. Someone who's played knifey-spooney before would know this.
I know this post/comment is aging but I feel I have to add my disagreement. Depending on skill and perhaps more than a little luck, navigating your way up to a senior position in the "old school" corporate world can actually be relatively conflict-free. Certainly, exploitative bosses are as widespread as you suggest, but that doesn't mean that every boss is exploitative.
I definitely agree about seeing the raise to market level... When I was hired they were supposedly going after 2-5M funding (so far its been ~1M in family money put into it), they said once either the additional funding or 50k mrr was hit that my salary (and the others) would go up. A few months ago the CEO's position shifted to wanting to "grow organically". Now it's pretty clear it could be 6months - 1 year before either funding or the mrr are hit (if the company survives that long) and I don't plan to wait, BUT, the main reason I hadn't made a move yet is because it's buying me time to work on a side project while still having some income stream. The thing is I don't want to get played like that and if the company suddenly sees growth (possible), I don't want to be stuck with low equity for all the work I'm contributing. I also only meant senior level in terms of development work, I'm sure I have more to learn in the startup realm.
Let me understand this better and don't take this negatively cause I can't figure out a way to make the point better...
You already had 2 broken promises and you are still wondering if you should give the other person the benefit of doubt..
What's that they say about, "fool me once, shame on you.. fool me twice, shame on me"... not sure if they have something for "fool me thrice.. "
You already had 2 broken promises and you are still wondering if you should give the other person the benefit of doubt..
What's that they say about, "fool me once, shame on you.. fool me twice, shame on me"... not sure if they have something for "fool me thrice.. "
yes very true! although the main reason I haven't made a move is it's buying me time to work on a side project while still having income... as my gf's dad said, "prostitution goes two ways"
If you have already demonstrated you are willing to work below market salary, why should they ever pay you market rates.
How does your lost income so far stack up against the capital provided by the larger shareholders?
And how does your stake compare to theirs?
And are some of those larger shareholders also paid from the company on a monthly basis or do they work for free?
And how does your stake compare to theirs?
And are some of those larger shareholders also paid from the company on a monthly basis or do they work for free?
The marginal utility of money makes this argument pretty bogus, none of the investors are depending on this investment to "turn out" or they won't have money for rent or groceries.
10K in the hands of an employee is a hell of a lot more valuable to them than another 10k is valuable to a millionaire/billionaire
10K in the hands of an employee is a hell of a lot more valuable to them than another 10k is valuable to a millionaire/billionaire
I worked at minor start-up once. They actually had not very much money* and I needed work badly. The contract was explicit that I was being paid a percentage of my hourly rate with a hard promise to pay the rest in monthly installments the second year. The advantage of this is once the 'teaser rate' expires you aren't 'negotiating a raise' to get you back to market rates.
* As opposed to no money, aka the types of companies where the real profit is in the difference between what they pay their employees and the market rate.
* As opposed to no money, aka the types of companies where the real profit is in the difference between what they pay their employees and the market rate.
Thats a really good question that I'm unfortunately not qualified to answer. When I said "real stake", to an extent I mostly just meant being a founder or an executive, where you have a seat at the table and if your shares are going to be diluted, at least you're trading it for something.
As an employee, for some of these equity packages you'd almost need an MBA to decipher if they're any good with all the things that can happen, so I usually don't even bother and just go to places that pay fairly or have interesting work.
Maybe a simple way to think about it: if your market salary is 100k, and they offer you 60k/yr and 2% of the company, is that 2% of the company worth 40k? (And how far can they dilute it?) To me that generally sounds like a bad deal, but your milage might vary depending on the circumstances.
As an employee, for some of these equity packages you'd almost need an MBA to decipher if they're any good with all the things that can happen, so I usually don't even bother and just go to places that pay fairly or have interesting work.
Maybe a simple way to think about it: if your market salary is 100k, and they offer you 60k/yr and 2% of the company, is that 2% of the company worth 40k? (And how far can they dilute it?) To me that generally sounds like a bad deal, but your milage might vary depending on the circumstances.
yeah also I forgot to mention that there are no benefits yet and I'm having to pay health insurance on my own... the only reason I've not left is its buying me time to work on a side project while having some income stream
You mean is .5% (assuming a four year vest) worth 40k/yr.
Get another offer from another firm ASAP, and then ask them to match it (unless you like the other job better).
Don't be a sucker, man
Don't be a sucker, man
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.
"Worse in every way than myself." Well, I mean, obviously not in every way.
I saw a sheet of salaries for a random subset of employees. Pre-funding engineering hires were universally paid substantially less than post-funding hires. The way we're structured, there isn't an equity upside which would cover the difference. If this was a one-off, you could chalk it up to hiring error, negotiations, Dunning-Kruger with regards to estimate of my own skills, etc. However, even myself excluded, a few of our best engineers are being paid substantially less than people much worse than people hired later on. It was pretty universal.
We knew what he meant, which was the point of the communication. He is making a general observation about data, not a formal proof.
I think pmccall is alluding to skills such as better negotiating skills, ability to sell one's self, and similar.
Often it's simply dependent on when you were hired. Employers have to stay competitive but won't give you a raise if you don't express discontent. When wages trend upward new hires can often end up making more money.
Some employers, anyhow. But I think it requires a certain level of negligence or callousness. You might be able to save a little money on payroll. But I think that ignores the hidden costs in reduced goodwill, lowered trust, and higher turnover.
Personally, I favor the Netflix model. It's part of the employer's job to make sure employees are fairly compensated at all times, whether or not they express discontent: http://www.inc.com/francesca-fenzi/management-ideas-to-steal...
Personally, I favor the Netflix model. It's part of the employer's job to make sure employees are fairly compensated at all times, whether or not they express discontent: http://www.inc.com/francesca-fenzi/management-ideas-to-steal...
That's pretty much true, but in the more "responsible" startups an employee who's been around long enough would be compensated with equity (or the equivalent in benefits) to compensate for the difference.
You would be surprised about how few "responsible" startups there are. Most will never be responsible until they're under scrutiny. I've been with a few that actively derided the idea of compensating employees who were underpaid during the initial growth phases. They thought that because they'd agreed to help "build the business" that nothing more was owed in better times.
One of them got a lot of press as a successful startup and landed several new large contracts. Which is why, after a year of executive self-congratulations and bonuses, their lead developer, who had saved several failed projects singlehandedly, left for more realistic pastures. They only brought him up to just below market when he talked about leaving, had no intentions about rewarding him for past underpaid accomplishments (which were obviously investments on his part), and despite their poor compensation packages had an overly strict culture for non-executives. Management compensation was top priority, and retention was assumed - they thought people would just stay despite having better alternatives. Even if he stayed, he'd have to watch other people get screwed. He wasn't the first, and doubtless he won't be the last rat to abandon that ship. I left as well, seeing that they really didn't care about anyone who didn't have ownership and a briefcase.
It's really not that uncommon. Being at the top of a company requires only one of three things: luck, lies ("charisma") or capital. Quite a lot of new business owners get mislead by their own kool-aid. They start believing that their vague "vision" is the most important thing and treat the people who do the real work as replaceable cogs. They give no thought to training costs or productivity and have high turnover rates. Merely treating the staff better could have a huge and positive financial impact. They'd probably know about these management issues if they didn't defensively fire people who voiced dissent. But a fool and his competent staff are soon parted.
One of them got a lot of press as a successful startup and landed several new large contracts. Which is why, after a year of executive self-congratulations and bonuses, their lead developer, who had saved several failed projects singlehandedly, left for more realistic pastures. They only brought him up to just below market when he talked about leaving, had no intentions about rewarding him for past underpaid accomplishments (which were obviously investments on his part), and despite their poor compensation packages had an overly strict culture for non-executives. Management compensation was top priority, and retention was assumed - they thought people would just stay despite having better alternatives. Even if he stayed, he'd have to watch other people get screwed. He wasn't the first, and doubtless he won't be the last rat to abandon that ship. I left as well, seeing that they really didn't care about anyone who didn't have ownership and a briefcase.
It's really not that uncommon. Being at the top of a company requires only one of three things: luck, lies ("charisma") or capital. Quite a lot of new business owners get mislead by their own kool-aid. They start believing that their vague "vision" is the most important thing and treat the people who do the real work as replaceable cogs. They give no thought to training costs or productivity and have high turnover rates. Merely treating the staff better could have a huge and positive financial impact. They'd probably know about these management issues if they didn't defensively fire people who voiced dissent. But a fool and his competent staff are soon parted.
I agree with the overall sentiment of your comment. However, I think psychologists would disagree with the idea that charisma -> dishonesty, and I think holding such a viewpoint is damaging to long-term success.
Psychopaths are usually both extremely charismatic and extremely dishonest though, so there is some merit to the idea.
All good liars are charismatic != all charismatic people are liars
There's some merit to the idea != all charismatic people are psychopaths.
You're right.
That or they literally just started later in the company's lifespan, thus getting a higher salary... c'mon. Occam's razor.
exactly. especially since he alluded to this in the article
Curious to know how you found out, and why you don't bring it up with your manager.
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...
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...
Honestly, I just found out, and I am trying to figure out when and how to bring this up. It feels like there are several good timings for bringing this up:
1. When I've just delivered something of high business value
2. When the company is really needs me to deliver something of high value
3. Annual review
4. Right before quarterly/annual budgets
5. When I have a competing offer
I've asked for a raise, not too long ago, without any information in hand about competing salaries. That conversation did not lead to a pay increase. I found out -- not long after that conversation -- that the post-funding folks make substantially more than the pre-funding folks.
Salary aside, it is an excellent job. I enjoy working there, believe in the mission, and I am relatively unlikely to leave for a more lucrative offer. I think management knows that, which is why they don't feel the need to pay myself (or other early employees) market rates. Management pays the least an employee will work for.
1. When I've just delivered something of high business value
2. When the company is really needs me to deliver something of high value
3. Annual review
4. Right before quarterly/annual budgets
5. When I have a competing offer
I've asked for a raise, not too long ago, without any information in hand about competing salaries. That conversation did not lead to a pay increase. I found out -- not long after that conversation -- that the post-funding folks make substantially more than the pre-funding folks.
Salary aside, it is an excellent job. I enjoy working there, believe in the mission, and I am relatively unlikely to leave for a more lucrative offer. I think management knows that, which is why they don't feel the need to pay myself (or other early employees) market rates. Management pays the least an employee will work for.
Same thing happened to me.
I gave my company a choice: raise my salary/title to reflect the new hierarchy or lose me to a competitive offer. They fed me a line about how the company was making money, but not enough to raise everyone's salary (translation: we don't think you can get a competitive offer).
I took another job 3 weeks later for 25% more money + actual equity (not bullshit stock options).
Startups can be fun, but in terms of compensation, the early employees will get screwed over.
I gave my company a choice: raise my salary/title to reflect the new hierarchy or lose me to a competitive offer. They fed me a line about how the company was making money, but not enough to raise everyone's salary (translation: we don't think you can get a competitive offer).
I took another job 3 weeks later for 25% more money + actual equity (not bullshit stock options).
Startups can be fun, but in terms of compensation, the early employees will get screwed over.
Management is hoping to keep employees happy by maintaining them in a state of ignorance, which never works. That is not a good sign.
Think carefully and explicitly about the decision-making processes that could have plausibly created this situation where people doing the same stuff get paid substantially different amounts. Think about the values reflected by those processes, and the odds that the company does not have some major storms ahead given the people at the helm.
Think carefully and explicitly about the decision-making processes that could have plausibly created this situation where people doing the same stuff get paid substantially different amounts. Think about the values reflected by those processes, and the odds that the company does not have some major storms ahead given the people at the helm.
I've worked at a few places where it was against the rules to talk about your salary. I asked the owner why (quoting what Spolksy had said) and I was told that if the employees know what each other earned, half of them would leave. I asked why some people were being paid more than others for the same job, and the owner told me, "Some people are better at negotiating than others." And I knew for a fact that I am terrible at asking for more, so it was time to look for another job. Shame really. It was a good job, but I'd always feel like someone had negotiated better than me and was earning an extra 20%
It is illegal to prevent your employees from talking about their salaries. http://www.npr.org/2014/04/13/301989789/pay-secrecy-policies...
I'm not from the USA, although I don't think it's illegal here either.
oops, sorry about the assumption
[deleted]
This is the lesson that proves loyalty has negative value these days.
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.
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.
I'm one of those developers that isn't a fan of
big formal-ish companies
Quote from OA "Some employees don’t scale from “Search” to this new phase of “Build”."
Perhaps a 'film crew' mentality (and reward structure) is needed? The crew comes in, does the project, has the wrap party and goes onto the next project. The 'day staff' take over afterwards.
Perhaps a 'film crew' mentality (and reward structure) is needed? The crew comes in, does the project, has the wrap party and goes onto the next project. The 'day staff' take over afterwards.
Sure, some people are attracted to the chaos of a startup who are just get on and build something. These are different people who are custodians and cherish the business and strengthen it.
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).
Are there any others?
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?
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.
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.
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.
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.
Exactly on the vision and fantasy.
Worse on the consequence: lots of "new" features are TOP 1, and the last unfinished top 1 just been cancelled in its first week.
Agile though, those sprints are never called failed, but move on like nothing changed.
Worse on the consequence: lots of "new" features are TOP 1, and the last unfinished top 1 just been cancelled in its first week.
Agile though, those sprints are never called failed, but move on like nothing changed.
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
http://en.wikipedia.org/wiki/Conway%27s_law
http://en.wikipedia.org/wiki/Conway%27s_law
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.
Where is the evidence that technical debt, let alone organizational debt, is actually related to the economic indicators of success?
[deleted](1)
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.
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".
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".
I enjoyed this thought piece on technical debt vs technical rsik: http://pl.atyp.us/2015-01-technical-risk.html
Thanks for that. Yes, there are definitely some circumstances where thinking in terms of risk is a plus.
As a bit of a dovetail, I had another random thought after typing the previous message. Technical debt is a little bit different than monetary debt because if I borrow money to leverage the business, the business (hopefully) grows in the same currency that I borrowed. I make more money and can pay it back.
Technical debt is different because even if I make a lot of money by taking a technical short cut, it doesn't mean I will have the capability of repaying the "loan". The people who made that short cut may not be capable of refactoring the code. Hiring people who can do the work seems like it would help, but then you have all the problems discussed in the original article.
Looking at it from the risk perspective, it can be a lot clearer that you might want to avoid the situation right from the off. Although the person who prompted me to write my response has unfortunately been entirely unhelpful, I suspect that's what they were ultimately thinking. "Will you actually be able to pay off this technical debt even if you grow the business?" Sometimes you can look at your staff and say that the risk of failure is nearly 100% ;-)
As a bit of a dovetail, I had another random thought after typing the previous message. Technical debt is a little bit different than monetary debt because if I borrow money to leverage the business, the business (hopefully) grows in the same currency that I borrowed. I make more money and can pay it back.
Technical debt is different because even if I make a lot of money by taking a technical short cut, it doesn't mean I will have the capability of repaying the "loan". The people who made that short cut may not be capable of refactoring the code. Hiring people who can do the work seems like it would help, but then you have all the problems discussed in the original article.
Looking at it from the risk perspective, it can be a lot clearer that you might want to avoid the situation right from the off. Although the person who prompted me to write my response has unfortunately been entirely unhelpful, I suspect that's what they were ultimately thinking. "Will you actually be able to pay off this technical debt even if you grow the business?" Sometimes you can look at your staff and say that the risk of failure is nearly 100% ;-)
We can theorize all day. Where is the data? The truth is we don't know how to guarantee business success, except via shotgun techniques (funding lots of random attempts). This strongly suggests that technical debt is not that important of a construct.
How is your position distinct from, "I don't understand X, ergo X can't be very important"? Because it looks pretty much the same to me.
If you think each business is a "random attempt", I hope you're never a founder. Modern businesses are highly non-random. It's true that investing in startups is in some sense gambling, but it's gambling on a highly filtered subset of all existing businesses, which is in turn a tiny fraction of all possible businesses.
The "where is the data" line is especially misleading here because no data just means no data. There are no high-n, double-blind studies validating the concept of technical debt. But there are also no studies demonstrating it's not a useful concept. And that's most of life: the decisions we have to make rarely can be solved by looking up journal studies. When that's the case, we have to apply other tools.
If you think each business is a "random attempt", I hope you're never a founder. Modern businesses are highly non-random. It's true that investing in startups is in some sense gambling, but it's gambling on a highly filtered subset of all existing businesses, which is in turn a tiny fraction of all possible businesses.
The "where is the data" line is especially misleading here because no data just means no data. There are no high-n, double-blind studies validating the concept of technical debt. But there are also no studies demonstrating it's not a useful concept. And that's most of life: the decisions we have to make rarely can be solved by looking up journal studies. When that's the case, we have to apply other tools.
[deleted]
This is hand-waving.
Again, I see this as you mistaking "I don't understand" for "there is nothing there". I obviously don't think it's handwaving, and it has been a long time since I took unsupported accusations from Internet randoms very seriously.
Sure, you could be a very special snowflake, so smart that the world really does always break down into "obvious to brobdignagian" and "dumb/meaningless". But if you're that smart then I'd suggest that either a) you should use your smarts to make your Olympian view comprehensible to us mortals, or b) you're wasting your time talking with the likes of us.
Sure, you could be a very special snowflake, so smart that the world really does always break down into "obvious to brobdignagian" and "dumb/meaningless". But if you're that smart then I'd suggest that either a) you should use your smarts to make your Olympian view comprehensible to us mortals, or b) you're wasting your time talking with the likes of us.
Technical debt isn't just a startup thing. It's ever-present in tech organizations. Technical debt is probably a leading factor in the irrelevance and ultimate death (typically sale / merger) of most software companies. The product gets increasingly buggy over time as developers pile on more and more hacks to get features out the door without writing down the debt, and customers move on to competitors that have fewer bugs. This is what happened to Netscape, for example.
For startups, technical debt can show up as unreliability (remember Twitter's fail whale?), or it can sink a product before it ever becomes famous enough for you personally to remember.
For startups, technical debt can show up as unreliability (remember Twitter's fail whale?), or it can sink a product before it ever becomes famous enough for you personally to remember.
You got the arrow of causation a bit off there: organizational debt causes business failure, the lack of it does not equal success.
If you have evidence that there are successful company growing with massive organizational debt, I'd be interested in hearing some examples.
If you have evidence that there are successful company growing with massive organizational debt, I'd be interested in hearing some examples.
[deleted]
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.