
Why are large companies so difficult to rescue (regarding internal technology) - lkrubner
http://www.smashcompany.com/business/why-are-large-companies-so-difficult-to-rescue-regarding-bad-internal-technology
======
JoeAltmaier
Ah, my sister endured all this sort of thing during 20 years as a VP in
corporate America. She successfully deployed new data systems to 120 plants in
50 regions in one year. Didn't cost $25M.

Her method? Ruthlessly purge the region of the old data system and install the
new (web-based API to a central, new data system). Investigate every regional
difference and consolidate into one model.

Before deployment day, get all the regional Directors in one room and tell
them it was going to happen. Tell them there was no going back, no push-back
would be permitted, and have the CEO in the room to confirm this.

It all went well, with her team of a dozen professionals that did a surgical
strike to each region. IT equipment installers, trainers. Even one lady who's
job was to ferret out the hidden PC somebody was squirrelling away in a closet
(there was always that person) and rip it out, take it to her car and lock it
in the trunk.

All went well, except for one region. That regional Director had missed the
big day, and tried (vainly) to push-back for all the familiar reasons: special
circumstance, retraining was going to keep them down for too long, and on and
on. 100 years of data systems gone in a year (including paper systems) and
replaced with a web API.

~~~
crazygringo
But what about _training_ and _processes_?

The tech part is easy, relatively speaking.

The hard part is each plant can have hundreds of workers whose entire jobs
depend on the way things are set up. It can be hugely expensive, time-
consuming and disrupting for _months_ to try to replace processes with new
ones, particularly if you expect things to _continue running_ without
interruption. It's one of those rebuild-the-airplane-while-flying-it
situations.

Maybe this was a uniquely lucky situation, because it doesn't sound like a
generalizable magic-bullet to me.

~~~
treis
It would definitely be interesting to hear the other side of this anecdote. My
guess is that there's a lot of workarounds happening at the plant level that
are being hidden.

~~~
JoeAltmaier
The plant now tracks each individual product, line, customer, contract in
realtime with complete transparency to the parent company. They swipe barcodes
and use online tools. Their processes were streamlined and paper removed.

It wasn't painless for everybody. In each region some good ol boy would resign
the week before changeover. When they'd come in to do inventory some room or
shed would be locked and nobody would have the key. They'd break the lock and
whattaya know, the room would be empty. Supposed to be full of inventory.

~~~
treis
>The plant now tracks each individual product, line, customer, contract in
realtime with complete transparency to the parent company.

I'm sure that's what the parent company thinks is happening. Whether that's
what actually is happening at the plant level is another question. So is
whether the improvement came with a hit to productivity or any other hidden
cost. Obviously I know nothing specific about the company but speaking
generally I've seen a lot of work arounds and inefficiencies in my day.

~~~
JoeAltmaier
Yes, every single item on every single line is tracked. Nothing (can) get sold
without being in the system.

Doubters abound. Even now a decade later, folks meet this story with disbelief
and doubt.

~~~
treis
>Yes, every single item on every single line is tracked. Nothing (can) get
sold without being in the system.

Worker: "Steve from Acme Co. needs a doohickey with a widget today but we
don't have a SKU for that"

Boss: "Corporate takes 2 days to issue SKUs so just mark it as a doohickey and
charge him 10% more for the widget"

Or maybe the customer has to go somewhere else because their turn around time
can't be met.

>Doubters abound. Even now a decade later, folks meet this story with
disbelief and doubt.

Because it's not our first time at the rodeo. If massive IT projects were this
easy we'd all be doing it like that. They're generally not. Steam rolling the
end user may have worked this time but other times it's ground the business to
a halt because those individual plant level differences were there for a
reason.

~~~
JoeAltmaier
They're massive because they're made to be that way. Technology transition
takes will and backbone. If that's missing, there's where $25M gets spent down
the drain.

I agree they generally don't go well. Because they're run by weak Directors
and VPs who are 2nd-guessing IT and getting in the way.

Plant differences are all well and good. But so is "IT not collapsing under 20
years of cruft". It costs something to bring all the plants in line. But it
also profits e.g. they're still in business after 10 years.

Here's how the money part went. Once the tracking went online, they realized
(region by region) they were losing $1M per month. 2nd month: losing $0.5M.
Third month: break even. 4th month: 1M in the green.

Why? Because they now knew (for the first time) what the hell they were
selling, how much to whom, and for what price. The VPs quickly became totally
addicting to this instant-knowledge web API and used it to turn the business
around.

------
JamesBarney
I have spent more time than I'm comfortable with over the last couple of years
railing against microservices. But this seems like a classic case where
microservices are needed. Each team can handle their own writing/validation
and expose them to themselves and other services(including the global
service). Of course you run into issues with transaction occurring across
multiple databases but these problems are hard but solvable.

> All incoming writes need to go into a centralized log, such as Kafka, and
> then from there the various databases can pull what they need, with each
> team making its own decisions about what it needs from that central log.

This sounds crazy. I don't know any large companies that have successfully
implemented it. This is basically arguing for a giant central database across
the entire company. Good luck getting the 300 people necessary into a room and
agreeing on a schema.

P.S. I don't know if he's using database as a shorthand for a service. If he
is then you can ignore everything I've written.

~~~
inimino
I'm not sure I'd call it microservices, since they could be monolithic inside
each organization, but I had the same thought. Just spend the time to agree on
a standardized API that everyone can support, and then the central API just
proxies to the appropriate subsidiary. I wonder why they haven't done it that
way.

~~~
ThePadawan
Personal experience from a past job:

Coming from a clunky, overused but underdesigned monolithic structure, the
work to standardize inter-team/inter-department communication is really hard.

In general, the easiest thing is to overspecify those APIs and fight anyone
who wants to simplify them. Complicated work looks good on a CV, after all.

So now you have hard-to-implement, full-of-cruft API designs. At that point,
teams realize that the easiest thing is to work around them.

And off you go into splintered components which ignore the standard APIs as
much as possible. Turns out that's much easier, and you deliver results with
higher velocity!

From far enough away, you can just see "more standard APIs => higher
velocity", so obviously you keep doing that, right?

~~~
huffmsa
Developers and product people have a hard time apply the idea of only building
the simplest, most minimal "thing" the consumer needs first and gradually
iterating it when the developers and other internal personnel are the
consumer.

An internal API is just as much a revenue driving product as an external one.

------
kfk
I think his paragraph on outsourcing and "core competencies" is spot on. I
would take it a bit further, however, since another consequence of this is IT
trying to buy every solution from an external software vendor (Oracle, SAP,
MuleSoft, etc.). The word "custom" becomes a "bad word" and IT uses it
whenever there is an effort to build software internally. Unfortunately very
often external vendor solutions are not apt to the task in big corporations.
There is also the issue that each vendor implements its own database and very
quickly in IT you spend most of your time "integrating" solutions with each
other, especially writes as the article author points out.

The issue of trust is also real, but I noticed that if you build a strong team
with a strong "internal brand" you can drive a lot of the execution and
technical decision making from there (the world used for these teams in
enterprise is "CoE's" but I mean something a bit more substantial by that than
what you usually read around). The thing is that in reality your CEO doesn't
care about your technical implementation details. This is a blessing and a
curse. The blessing part is that if you offer a team with a brand and a vision
that has collected some internal trust from multiple parties over a couple of
years, you might be able to take your own technical decisions independently
from IT or other departments around the world.

As for the technical part of this, I am not an expert, but security, RBAC and
friends are hard problems, I'd be surprised if you find a vendor that can do
this for all your edge cases. I'd be for a fully internally built solution.
But again, no expert.

~~~
PaulAJ
"Core competencies" is a widely misunderstood term. Lots of people equate it
to "business model", as in "we sell widgets so therefore selling widgets is
our core competence".

A thing is a core competence if, and only if:

* It makes a difference to your customers.

* It is difficult for your competitors to replicate.

* It provides access to a wide range of markets.

Janitorial services, as the OP says, do not tick any of these boxes (unless
you are a restaurant or something, in which case it ticks the first). Black
and Decker's core competence is not selling cheap hand tools, it is making
small electric motors. Think about it.
[https://en.wikipedia.org/wiki/Core_competency](https://en.wikipedia.org/wiki/Core_competency)

IT frequently ticks all three: if your IT goes down your customers may know
about it before you do. Your IT is going to be difficult for competitors to
replicate (as long as you haven't outsourced the whole thing), and you can use
that IT in lots of different markets.

However there are too many senior managers who have heard the words "core
competence", not read the article, and assumed that since they are not running
an IT company it follows that IT is not a core competence.

~~~
jarofgreen
Check out Wardley mapping - interesting technique to get teams discussing what
is a commodity part of their business and what is something custom that really
benefits them to do in-house. I agree people often judge this wrong, and it's
an important point to raise.

------
adamzochowski
The made up story sound similar to Hertz losing 32 million while hiring
Accenture to do internal API rewrite in 2 years.

[https://www.theregister.co.uk/2019/04/23/hertz_accenture_law...](https://www.theregister.co.uk/2019/04/23/hertz_accenture_lawsuit/)

~~~
huffmsa
Hertz is what I've landed on.

\-- Female CEO

\-- 100+ years old

\-- rentals

\-- Has quietly bought up it's competition

Only thing which doesn't line up is employee numbers.

And they had Accenture do Angular app development.

~~~
wastedhours
They are listed as a MuleSoft customer too:
[https://www.mulesoft.com/](https://www.mulesoft.com/)

~~~
whatshisface
Wow, I thought that MuleSoft was a made-up anonymized name like
SuperRentalCorp...

~~~
wastedhours
They used to trade on the NYSE as MULE before Salesforce bought them for a few
'bill. Think it was a legit reference to "donkey work".

------
softwaredoug
The article I think misses reasons for keeping the different business units
separate (assuming they are indeed BUs). They can act as the smaller “agile”
companies in their own markets that the author seems to say can get a lot more
done. Who cares if there’s a lot of duplication. There’s a huge human reason
to keep these separate: autonomy. Nothing sucks more than being stuck in org
bureaucracy for years never solving a customer problem, watching the smaller
poorly funded competition do better. You’ll never retain talent doing that,
which frankly is the real issue large companies struggle with. And you’ll
never satisfy customers when reuse and not quickly solving customer problems
is the priority.

Consolidation and “reuse” is often the problem, not the solution.

------
aryehof
The (latest) CEO calls to "unify" (restructure - yet again) the company. That
vague call results in the age-old purchase of a "technology" to solve the
problem from a vendor - MuleSoft.

An "API" is the answer they are told they need - easy. Millions of dollars
later after much time has past, the project is of course in trouble.

The author is asked if he knows anything about APIs. He says sure, they're
easy. Just expose the database through an API. How hard can it be.

My prediction (guarantee) is that a lot more time and money will go down the
drain before this API effort is finally abandoned. The issue is the chain of
naive and poor decisions being made, which are exacerbated by the advice of
the author.

~~~
Angostura
> which are exacerbated by the advice of the author.

Really? what advice is being given here that would exacerbate anything? From
what I see, the author is carefully enumerating the problems which need to be
carefully addressed before this kind of change can be made.

He is deliberately holding up the 'You just need an API, how hard can it be?'
perspective as a naive one and looking at why it _isn 't_ that simple.

I found this an interesting and useful argument, particular the element about
trust and loss of control

~~~
C1sc0cat
From experience working on these sorts of sites - No its not - how you
structure a large world wide care hire site is a known thing now its not
rocket science.

In the past I have worked on one of the Big car hire sites and in my opinion
Accenture and Hertz where just incompetent.

Probably Non Culpable Incompetence for Hertz, Accenture not so much.

------
CharlesW
This is an enlightening article, but I think it's missing an implicit
conclusion to accompany the explicit conclusion that "one is constantly
fighting against history".

History is absolutely one part of it, but the other part is that there must be
a benevolent dictator (person or _small_ group/council) with the authority and
courage to make technology decisions. Without that role, bikeshedding can
often drain valuable inertia — sometimes fatally — from the decision-making
process.

~~~
otterley
My experience is that the actual power wielded by a high level executive is
usually inversely proportional to the size of the organization they manage.
Such executives are typically more effective at guiding strategic direction,
not prescribing tactics.

Large, mature organizations have a lot of inertia, and that inertia is
difficult to overcome except by perhaps the most charismatic individuals. I’ve
rarely seen a leader dictate or bully their way to effective, positive change.
Resistance is extremely likely for various reasons, and it’s not likely to be
in the form of vocal mutiny. Instead, it typically appears in the form of
excuses or lethargy. A waiting game is played, usually with success, until the
musical chairs shift the management once again.

~~~
zaphirplane
My experience is in troubled companies executives move in then bring their
people across

~~~
bjelkeman-again
And that starts another round of changes, which may be going in a different
direction, again, as described as “history” in the OP.

------
Aeolun
I’m starting to be of the opinion that large companies are impossible to
‘rescue’. Unless you count sustained change over 20 years as a rescue.

I swear, there are so many exceptions and special cases embedded in a large
company that it’s impossible to replace any one product without also
overhauling the rest, oh and overhauling customer expectations, because if
they’re used to a static website that takes 10s for each page load, then
whatever replaces it better takes at least 10s to load.

~~~
julienreszka
What do you mean, why would they not want faster reload time?

~~~
Aeolun
My question exactly.

Unfortunately getting the actual requirements after the 10 layers of
indirection in the enterprise means you just hear the Product Owner say that
the requirement is the page load should take 10 seconds.

By that point any justification has been long lost.

------
moreentropy
Welcome to enterprise IT. You'll receive your badge in two weeks eventually
and your login won't work for another month.

~~~
tonyedgecombe
It’s soul destroying work, I’m starting to wonder if there is something wrong
with people who appear to thrive in these companies.

~~~
brixon
Global changes like this are near impossible, but most of the work is for the
local internal customer which is very possible and rewarding. Large projects
are normally won or lost on the strength of the upper management, it is
normally not a technical issue that fails large projects in large companies.

------
motohagiography
This blog post is a better case study than any HBR or consulting firm study
I've read because the author has a grasp of each of the technology,
governance, and economics of the problem. Purely economic or political models
of organizations assume you can just reform one to align with incentives, but
tech is a physical limitation, it's the new inescapable geography.

The companies and institutions I've encountered all essentially say, "We want
success but without change," and then wonder why their initiatives fail. The
point about "Agile" being a euphemism for "trust," is huge. Startups can be
farcically naive (or cynical to the point of evil) about how trust in
organizations works.

C&C enterprise structures don't scale, and they become immensely vulnerable to
challengers as a result. This article reminded me of the opportunity that
large companies create, like stored potential energy in the form of
opportunity costs. It's like a kingdom spread so widely that a small raiding
army can feed itself on what these companies left undefended while planning
campaigns.

How much of this article is true for the rest of the Fortune 500?

------
simongray
Oooh, this is by the same guy that wrote my favourite anti-OOP rant:
[http://www.smashcompany.com/technology/object-oriented-
progr...](http://www.smashcompany.com/technology/object-oriented-programming-
is-an-expensive-disaster-which-must-end)

It's worth reading, although your feelings may get hurt if you're not already
sold on functional programming. He's not very diplomatic.

------
codeflo
In some sense, departments in a large company develop an institutional
resistance to IT centralization efforts as a defense against the inevitable
next reorg. Or rather, departments that _don’t_ have this resistance didn’t
survive the last one.

Though I wonder, if large companies are routinely this inefficient (which
matches my limited experience as well), how do they survive? Naively put, why
isn’t every large company killed by a startup next week?

~~~
cosmie
> if large companies are routinely this inefficient (which matches my limited
> experience as well), how do they survive?

Because every other large company is as equally inefficient. When it's par for
the course, it's not seen as an issue (or even seen at all). Efficiency is
also usually not the metric that gets optimized towards - other dimensions
such as predictability, reliability, longevity, consistency, stability tend to
take precedence. Take the loyalty program vendor mentioned in the article -
sure it's limiting their flexibility for what they want to do now, _but it
still exists_. So depending on your viewpoint, that was a pretty solid choice
in vendor.

Also, large companies have the scale to absorb the costs of their inefficiency
with fairly minimal impact on their unit economics. And if a startup _does_
pop up and gain traction with a much more efficient operational model, BigCo
can write whatever check is necessary to gobble them up before it becomes a
risk.

~~~
jacques_chester
> _Because every other large company is as equally inefficient._

I think there are commonalities in pathologies. After all: humans are humans
and large enough groups of people will exhibit regression to the mean.

But the exact details can vary so much that I am often reminded of Tolstoy's
observation that:

> _Happy families are all alike; every unhappy family is unhappy in its own
> way._

------
geertj
A ‘tech first’ approach (create an API) will not make this company agile. The
question that the CEO of SuperRentalCorp needs to answer is ‘do we want to
become a tech company?’ If yes, then start a multi year transformation
starting with defining tech career ladders, a strategy how to train internals
and hire externals, how to separate with those intervals that are unable to
follow. Be clear and offer an opportunity for those that want to stay and be
generous for those that can’t. If done correctly you will have the necessary
basis for beginning a tech transform in a couple of years.

If the CEO does not want to be a tech company then I’d investigate options for
spinning out a service company to serve the rental market, ideally in
collaboration with some competitors.

------
deboflo
Excellent article. I’ve experienced a few of these issues at two vastly
different companies (one had 60k employees, another only had 200). I implore
developers to avoid working at companies with this class of problems. Work for
a company that is strongly customer focused instead.

~~~
Angostura
But you can have a company that is strongly customer-focussed that still faces
this class of problem, surely? It would seem to me that _solving_ these
problems at a large company where there actually _is_ trust and esprit de
corps to get it solved could be tremendously satisfying.

------
willart4food
It's evolutionary in a Darwinian sense: they need to die so that their parts
(bankruptcy/liquidation/sale) can be used by new and upcoming companies.

There are exceptions like... IBM!

~~~
hnzix
_> There are exceptions like... IBM!_

Good grief, IBM are the Mongols. It all makes sense now.

~~~
pjc50
An extremely slow horde.

~~~
hnzix
Does this make Oracle the Ottoman Empire? I'm suddenly overwhelmed by the
realpolitik similarities. Agile is Che Guevara?

~~~
osullivj
I used to work with an old IBMer from the MQ team. He'd also worked at DEC and
the BBC before joining my team at Chase in the late 90s. He used to joke that
it was no accident that IBM almost collapsed at the same time as the Soviet
Union as they were very similar organisations!

------
otakucode
Interesting article, and it points out real problems that large organizations
face. It made me think of the issues I've seen dealing with government
contracts in the US. Policies can create perverse incentives and have
unintended consequences regardless of their intention, and when dealing with
large organizations those sorts of things have to be considered as they end up
steering the ship.

Near the end of the article the author mentions that 5 people can look each
other in the eye and trust each other, while 11,000 can't. This suggested a
question to me: Where does that stop? How many people do you have to have
before a 'local culture' isn't enough and trust breaks down? I've read things
in the past about Dunbar's Number which suggests this number is around 110.
That seems to be about the number of people that individuals can 'keep in
mind'. I have often wondered whether organizations might benefit from taking
that limit into mind and structuring things so that no level or group would be
permitted to grow beyond that. To grow larger, build a hierarchy where groups
of about 100 choose a representative whose task is to know the concerns of
everyone in the group and represent those concerns when discussing with reps
from other groups, etc.

------
hackerbabz
Isn't the issue with the "primitive" customer loyalty company a classic case
for abstraction? They should build an ORM like internal API to deal with the
loyalty program.

It can send emails or even order a person to make a phone call if necessary.
Whatever "primitive" means the "Invented-here" API can abstract that
functionality, so that the internal API devs can access and update the data
from the external company.

------
whatshisface
> _To a large extent “be agile” is almost synonymous with “trust each other.”
> If you’re wondering why large companies have trouble being agile, it is
> partly because it is impossible for 11,000 people to trust each other the
> way 5 people can._

I wish the author had explained this more. What is it about agile that
requires more trust than anything else? Can't you write lies in any format
equally easy?

~~~
hibbelig
Well, there is agile as described in the Agile Manifesto:
[https://agilemanifesto.org/](https://agilemanifesto.org/)

And then there is Half-Arsed Agile:
[https://www.halfarsedagilemanifesto.org/](https://www.halfarsedagilemanifesto.org/)

The author meant the former. Writing lies seems to point to the latter.
Writing lies is not "valuing individuals and interactions".

------
pacala
One piece caught my eye:

> In terms of the best integration architecture, what seems to me the only
> long-term solution is something like the unified log architecture that Jay
> Kreps wrote about back in 2013. All incoming writes need to go into a
> centralized log, such as Kafka, and then from there the various databases
> can pull what they need, with each team making its own decisions about what
> it needs from that central log.

Then, from the linked Jon Kreps post, 2013 [0]:

> In order to allow horizontal scaling we chop up our log into partitions.
> Each partition is a totally ordered log, but there is no global ordering
> between partitions (other than perhaps some wall-clock time you might
> include in your messages). The assignment of the messages to a particular
> partition is controllable by the writer, with most users choosing to
> partition by some kind of key (e.g. user id). Partitioning allows log
> appends to occur without co-ordination between shards and allows the
> throughput of the system to scale linearly with the Kafka cluster size.

In practice, wouldn't the end "centralized log" be essentially a collection of
the logs from each original/logical database, now managed by a specialized log
team? To read the log, the interested consumer team would have to create the
appropriate read-only replica of the original database, using the respective
database technology / binaries / schemas. As such, isn't the overall system
better described as "database replica as a service", as opposed to the finer
grained implication of the "unified log as a service" of the article / Jon
Kreps post?

I'm trying to figure out if the implication of such decisions are
organizational, "who's responsible for the logs, who's responsible for the
replicas", vs. architectural, "where does data bit X go, how does it maintain
consistency with data bit Y, how do we read its current state?".

[0] [https://engineering.linkedin.com/distributed-systems/log-
wha...](https://engineering.linkedin.com/distributed-systems/log-what-every-
software-engineer-should-know-about-real-time-datas-unifying)

------
aj7
MBAs and other “professional managers.” Persons in a position of power that
have not done any company business or tasks, either never, or for more than 5
years.

------
RocketSyntax
Peter Drucker: the largest drain on corporate productivity is recommunication.

Short term goals. Narrow focuses of executive team. Lack of technical
executives. Brain drain.

------
jacques_chester
I work for Pivotal and I feel I have some relevant experiences (from which the
following _personal opinions_ are derived). I started in Labs, our consulting
division, known for being vociferously about XP, Lean product management and
User-Centred Design. These days I work in R&D. The latter has been very
educational, as we've been involved in building larger and larger systems,
with lots of "oh _that 's_ what our customers meant when they talked about
problem-of-scale XYZ". I know that my own temptation as a Labs Pivot was to
imply that customers just weren't agile-ing _hard enough_ ; R&D has kicked a
bit of that stuffing out of me. As Brooks argued in _No Silver Bullet_ , there
is essential complexity and accidental complexity. Enterprises deal with
amounts of _both_ that are hard to comprehend. You get some fascinating
problems and pathologies at Enterprise scale. As the article implies, nobody
ever really _intends_ to create them, they emerge from the system's evolution.

I think the core logic of outsourcing is sound, but it's like many simple
ideas: simple, but not _easy_. It's actually a restatement of economics 101 --
comparative advantage and gains from trade. Even if you are strictly better at
doing everything yourself, it still makes sense to trade with others. At
Pivotal we often discuss this as "the value line", the point in the stack
where, we argue, it is more effective to delegate your technology problems to
us (or -- this is how I feel personally -- to a comparable vendor, like Red
Hat, over pure DIY) and to turn your own technology efforts towards the things
that add value for your customers. Even if you could do a better job than any
of the vendors, it might not make sense for you to do so.

That value line isn't static, of course, and it's differently located for each
customer. And it remains necessary to retain enough inhouse expertise to
sensibly assess vendor solutions. Enterprise software and software development
is a complex "experience good". This isn't limited to software, it's true of
many complex purchases -- I have a book in my collection called _Industrial
Megaprojects_ which contains a fascinating parade of such examples.

All that said, transformation _is_ possible in my experience. The key is, as
the article describes, that it takes a long time, a lot of work and a lot of
money. It most of all requires enough time for cultural norms to resettle and
for trust to solidify. I've worked with companies operated on a fear basis and
basically, the best we could do was to create insulated bubbles of agility.
We've worked with other companies which have more or less transformed
themselves once we brought a spark. Sometimes we will be the true vanguard of
a revolution, sometimes we will be the fad-of-the-week that the hardened
veterans will shrug and mouth the slogans for while continuing with the
_actual_ way things get done. Sometimes, because many of our customers are so
vast, we will be heroes to one division and villains in another.

The best that I and my peers can do is to help each client as honestly,
empathetically and fully as we can to transform themselves. But, as the
article points out, that is _hard_.

------
soup10
Large old software companies have hilarious deep layers of abstraction and
tooling on top of legacy code from people that have long left the company.
Usually getting anything done requires gathering word of mouth arcana from
multiple people.

~~~
marcoonroad
Yep, some of these people leaving the company are developers who suffered from
burnout crisis inside the 'Big Company'. :p I'm one of these sort of
professional developers leaving 'Big Companies' due burnout.

I think that 'Big Companies' need to deal with Ethics before trying to deal
with Agile/Scrum. xD

------
rossdavidh
Having worked at and for both large and small companies, in several
industries, every word of this rang true.

------
ptah
it sounds like centralisation is the problem, why not build something generic
and then have separate instances for each legal entity

------
rkagerer
Inertia

