
Organizational debt is like technical debt, but worse - webhat
http://steveblank.com/2015/05/19/organizational-debt-is-like-technical-debt-but-worse/
======
overgard
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.

~~~
tallerholler
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!

~~~
gaius
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.

~~~
hanlec
> 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.

~~~
gaius
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.

~~~
jsalit
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.

------
pckspcks
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.

~~~
achille2
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...](http://www.inc.com/magazine/20090401/how-hard-could-it-be-employees-
negotiate-pay-raises.html)

~~~
cpks
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.

~~~
blindhippo
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.

------
jawns
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.

------
hliyan
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.

~~~
girvo
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.

~~~
keithpeter
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.

~~~
monk_e_boy
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.

------
fsloth
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?

~~~
arielm
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.

------
drawkbox
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.

~~~
pan69
> 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.

~~~
wFU8oB6RUUSL
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.

------
ChuckMcM
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.

------
brobdingnagian
Where is the evidence that technical debt, let alone organizational debt, is
actually related to the economic indicators of success?

~~~
mikekchar
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".

~~~
brobdingnagian
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.

~~~
wpietri
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.

~~~
brobdingnagian
This is hand-waving.

~~~
wpietri
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.

