3 ms·
Self-sabotage is remarkably common. Peter Drucker wrote about this in his book "Innovation And Entrepreneurship". His book is full of anecdotes similar to this
by lkrubner 9y ago
Self-sabotage is remarkably common. Peter Drucker wrote about this in his book "Innovation And Entrepreneurship". His book is full of anecdotes similar to this article. It is surprising how many managers do things that clearly hurt the business they work for.
Drucker told a story from 1956, about an executive at Macy's who was angry that so many customers were coming in to buy washing and drying machines for clothing. Drucker was confused, and asked if the machines had a lower margin than other products. No, said the manager, they had a higher margin. Then why, asked Drucker, was it bad that customers wanted to buy the machines? The executive explained that Macys was all about selling clothes, not machines, and the customers were going to damage Macys reputation. The executive had previously worked in the clothing department, for decades, and he felt the clothing department was the "real Macys" and everything else was a sideshow.
Drucker has more stories like that. It is very common that managers have some initial bias, that establishes some odd habits in a company, and which over time become normalized. I recently wrote about a similar incident, at a startup where things were a bit odd from the beginning. Despite economic theory, managers are rarely rational.
I consult with many clients in New York City, and I can not begin to tell you how often this is true:
"Anyone who comes into one of these companies from Google, Amazon, or another place with solid ops practices is shocked. Often, they try to fix things, and then leave when they can’t make a dent."
In the last several years, I was at two companies that got rid of all their previous code, and did radical re-writes of everything:
http://shermanstravel.com/ http://shermanstravel.com/
https://openroadmedia.com/ https://openroadmedia.com/
but I worked at a dozen other companies where people knew that fundamental systems were broken, and there was no effort to fix things.
About the politics of fixing broken companies, this is exactly true:
"Google didn’t go from adding z to the end of names to having the world’s best security because someone gave a rousing speech or wrote a convincing essay. They did it after getting embarrassed a few times, which gave people who wanted to do things “right” the leverage to fix fundamental process issues. It’s the same story at almost every company I know of that has good practices."
- barrkel 9y agoIn the last several years, I was at two companies that got rid of all their previous code, and did radical re-writes of everything This is almost always the wrong thing to do, mind, especially if you're fresh to the situation and don't know the full product functionality. It can pay off, but it usually doesn't; and when it does, the results are often mixed - things might be neater, faster, more maintainable etc., but usually they're less featureful or buggy in some other dimension.
- reificator 9y ago> In the last several years, I was at two companies that got rid of all their previous code, and did radical re-writes of everything: Over the last few years the best work I've done has been to take what existed and slowly refactor it into something better. Well, I say slowly, but the refactors themselves were often quick. I try to identify the most common pain points - for both users and developers - and eliminate those as quickly as possible. The overall codebase might not get better at a crazy rate that way, but the developer experience goes up, meaning fewer bugs, meaning quicker iteration times and more confidence making changes that should be easy but so often are not. And the end result of that two or three years on is a significant improvement in the quality of the code, the number of bugs - breaking or otherwise - that users encounter, and often times a manyfold decrease in the total LOC that need to be maintained. I've tried rewriting some things as well: but even when it's a literal requirement in order to switch underlying platforms, it still causes a lot more friction than refactoring does. I've got three projects right now where the deadlines have massively slipped, and I'm now at the point where I'm looking to try to take some of the rewrites and backport them to the original platform just so that migration goes a little easier when the rest of the pieces fall into place.