Advantages of incompetent management

Creo (based in Vancouver, BC) used to be a company that tried to address this. The concept that was used was called "unit presidency". Each employee was empowered, expected, and trained, to make decisions as if they are the president of the company. The principles behind making decisions were called "economic thinking" which the CEO used to say was everything he learnt in a Harvard (EDIT: or maybe it was Stanford) MBA distilled into the core principles. Basically looking at the ROI (Return on Investment) of the decision. Decisions were generally made by consensus though depending on the nature of the decision sometimes other methods were used. This extended to decisions that involved spending money, not just should you pick language X or language Y for your next software project.

I think it worked pretty well for quite a few years. It gradually stopped working when the company acquired a large company with a different culture and also hired people (well, managers mostly) who weren't aligned with the culture. Eventually this basically disappeared when the company was acquired by Kodak.

I've seen flavors of this in other places. Famously Andy Grove of Intel also preached that decisions need to be made by those closest to the decision and empowered people to make the right decisions. More generally this can be reflected in a servant-leadership model where leadership sees itself as facilitating the growth of the people underneath them.

Another requirement for this to work well is that management (e.g. the CEO or other leaders) are able to lay down a broad strategy for the people of the company to execute on. If the leadership has no strategy then tactical decisions can not be made properly. They also need to make sure there's coordination and structure.

Things work the same with any resource, not just actual money - it could be team size, or processor cycles and memory bytes. If you free up 200 ms of CPU cycles and 500 megs of RAM, someone else can deploy their functionality using these newly available resources, and then you won’t be able to. In fact, a mature, well-run CI system will measure everyone’s resource footprint after each commit, and will not let you exceed your budget, which was frozen at some point based on how much you were using at the time (hope it was a lot! - always spend like crazy before the baseline is established!) Is it any wonder that people learn to never optimize their code - unless they want to deploy something new themselves, and only after asking for more resources to deploy it and not getting any?

This explains so much. It also sounds like broken water laws in the western US that incentivise farmers to intentionally waste water to preserve their future ability to waste water.

The problem stated by the article is that consistent incentives inevitably results in employees “gaming” of the system.

I suspect but cannot prove that inconsistent metrics and incentives do actually work.

In other words, measure and reward different things each month! Latency this month, resource efficiency the next month, customer satisfaction the next, and so on…

Anyone attempting to cynically game the incentives will lose out on average, but people that naively do a good job overall will tend to be rewarded. Maybe not every month, but most months.

To the author - this is the best/most realistic (and funny) depiction of how things actually work in medium to large organizations. Also nailed the part around how small companies with “lax” technical hiring standards but strong cultural components triumph over their bigger counterparts. Because people working there actually care and they can see the impact of their work. It is real to them vs. some made up KPI metric to sound progressive.

As an aside, I’ve been lucky enough to have sufficient influence at all my employers for removing unnecessary layers of interviews. Anecdotally, most average engineers would be at least half as productive at most jobs out there. A couple of interviews at most would increase the odds significantly in the employers favour. Google scale could be an exception, but for 90% startup and mid sized corporations, the 3-4 technical interview rounds and algorithm problems are an absolute overkill.

The problem is that it’s hard for a well-run place to get people to fix non-showstopper bugs.

This is why mature products work so much better as open source- at some point you just want someone to care about the sharp edges instead of upselling new SKUs.

If you look at the world's must successful military initiatives, many of them practiced "maneuver warfare" in which individuals were given broad goals and the ability to use their initiative to attain them.

https://en.wikipedia.org/wiki/Maneuver_warfare

Decisions should be made by those with the best information. Sometimes that person is not the leader, and opportunities should just be seized by someone at a low-level. When this happens, leadership should back these initiatives. My favourite example of this is the Battle of Arsuf during the Third Crusade.

https://en.wikipedia.org/wiki/Battle_of_Arsuf

Richard the Lionheart of England spent weeks slowly marching down the coast with his heavily armoured cavalry/infantry, getting harassed by Saladin's faster cavalry. His army of 10k men could not attack and break formation, since Saladin's cavalry was faster and could pick off Richard's men.

Richard's goal was to wait until Saladin's horses got tired, and when that opportunity arose, charge and catch him while he was slow.

After a few weeks of nothing, suddenly one of his units (the Knights Hospitallier), led by Baldwin le Carron, started to charge on Saladin. Richard the Lionheart had no way of knowing if this was a good idea (to this day we don't know why Baldwin made his decision) but he immediately backed the charge with all 10k of his men and defeated Saladin's army.

This wasn't being lazy or poor management. Richard understood that he did not have the information needed to execute his strategy, so he delegated it to his officers.

When Baldwin le Carron made a decision Richard didn't understand, Richard didn't ask for a Jira ticket or a design doc, so he would have more information to make his decision (as a "good" manager should). He trusted his subordinates and won.

I believe software engineers are getting the wrong idea about a company being in "war mode".

If one reads military strategy, a proven tactic for leaders is outlining strategy and trusting your subordinates to execute it, because feeding information upwards takes too long.

The comments on resource utilization are one of those things that is only true now that there is a 1:1 correlation between $ and available CPU/Memory, and the pool of available CPU/Memory resources is effectively unlimited.

Embedded is maybe the last refuge of where there are hard resource constraints that cannot be violated. If you only have 64K of RAM, you had better make it work!

IMHO this is why you can end up with embedded code that is easily 10x to 100x more optimized than code running in other environments. It is also, why IMHO, the user experience on Smart Phones doesn't improve linearly with the hardware improvements - see https://en.wikipedia.org/wiki/Wirth%27s_law

This train of thought, along with basically flatlined GPU performance / $, explains also why we are seeing real algorithmic improvements in the ML/AI space. If we were still operating under Moore's law and GPUs and VRAM were 2xing every couple of years, I doubt we'd see all the research efforts going into optimizing training, fine tuning, context windows, inference, and so forth.

Whatever objective you are expected to achieve, a bigger budget makes it easier.

This should be true but I've seen bloated projects that would have had better outcomes had the team been more constrained.

And to quote Fred Brooks:

There are many examples from other arts and crafts that lead one to believe that discipline is good for art. Indeed, an artist's aphorism asserts,'Form is liberating' The worst buildings are those whose budget was too great for the purposes to be served. Bach's creative output hardly seems to have been squelched by the necessity of producing a limited-form cantata each week. I am sure that the Stretch computer would have had a better architecture had it been more tightly constrained; the constraints imposed by the System/360 Model 30's budget were in my opinion entirely beneficial for the Model 75's architecture.

The author is describing two cases of poor management. The first are self-interested managers. The second are laissez-faire (in a bad way) leaders who have all but abdicated their position. Both are bad.

There is no "healthy laziness." This is a cynical term that does a disservice to leaders who skillfully practice with a light touch.

All of this is true but... at what cost?

I have worked for a company where the ethos among the workers was very high, but management was exceptionally incompetent at managing. Zero people skills, and deeply skeptical that people skills were even necessary. (Many companies founded by hackers are like this.) So the CEO and CTO asked people to do things, but did no process management at all and just waited for them to be done.

This worked a lot better than you would think. We had hired people who believed in our mission, and mostly people do want to do what's asked of them. Our codebase was pretty lean, even boring, because there was no incentive to do any promo packet type spectacular development.

Projects sometimes took a long time, but they did get done.

But this stops working when you have projects that require coordination between people with differing incentives. Teams grow tired of waiting for the other team to do their half, so mistrust begins to become endemic. In the vacuum, all your hacker ICs grow fatigued and start doing more "interesting" things just to amuse themselves, because, who's really watching them?

TLDR benign neglect, even under ideal conditions, will eventually be a problem. The company's progress becomes slower and slower, and may even start sliding backwards according to some metrics.

The author seems confused about what constitutes competence vs incompetence. In my opinion the budgeting problem can most easily be understood through the lens of bounded rationality: senior management often has no idea what kind of budget is required to meet certain objectives, so can’t really separate the case where a frugal manager truly needs more budget and the one where a self-interested manager just wants a bigger budget to show off. In my book this is due to senior management’s incompetence, not competence.

I work for a government research lab. Our business model is that we don't receive government-budgeted money, we actually sell our services to other parts of the government. So in effect we have a bunch of researchers and engineers who theoretically report to "management", but actually report to a local program manager, who reports to an external sponsor.

We had an official manager, a "branch head", who was worse than incompetent. He couldn't find his butt with both hands, but he also thought he was God's gift to management, and would forcefully and emphatically make bad decision after bad decision.

Eventually, he had screwed up the group's major program so thoroughly it looked like a sure fire failure, and he found another job, and didn't bother to tell anyone; he just stopped showing up for work one day.

The level of management above him had bigger problems to deal with than replacing him, so they made sure we had a competent secretary and left us alone for two and a half years. It turned out to be arguably the most productive period of my professional life. My buddy and I took over business development. THe team turned the big project around and made it a rousing success, and grew the funding from it by two orders of magnitude.

The point being: there's bad management, that acts randomly or not at all; and then there's really bad management, which takes up your days with constantly changing orders, fixing relationships with customers or sponsors that they've screwed up, and levying time-taxes in the form of training, reports, and morale boosting exercises.

If given a choice between bad management and really bad management, pick bad management.

Fifteen years later, my buddy runs the place and I'm the senior scientist.

the hedgehog is too proud a bird to fly without a kick

Say what you will about Russia but I do love their proverbs.

Bug fixes work a lot like efficiency improvements, the main difference being that competent management makes things much worse. You can’t make fixing bugs into a “goal,” same as you can’t make optimization into a goal, because people will just add more bugs up front and then fix some of them.

If competent management makes things worse, then it isn't really competent management. I'm not sure why introducing additional process is considered a sign of competence

Instead of setting arbitrary goals, couldn't they just pay attention to the things that people are actually working on and give out rewards/punishments based off of their own judgement? If you need to create some elaborate resource quota CI/CD system because you can't trust employees to do things decently, then it's a people problem

I'm on the first part and I struggle to not scream.

- the well run place seems too keen on micro managing. Estimating every step to the point of cancelling improvement is not 'well run'. I'm sure every book about advanced company management will tell you that.

- the badly run is hmm.. at least partially (if not totally) naive. What are the odds that people not being asked anything don't just talk all day long ? The most probable equilibrium point will be most employees doing a little bit of the mandatory duties in the morning, a little bit in the afternoon, separated by lengthy bits of smalltalk (not they kay kind). I have yet to see one person trying to fix anything in their environment because they had free time. 99% of them will just have a new topic to vent about in the coming coffee / smalltalk pause.

ps: anybody knows talks or books about people operating like emergency teams ? where the natural spirit is optimize everything until you reach hard limits ?

This article shows, in many examples, Goodheart’s law and Pournelle’s iron law of bureaucracy. You can’t make a hierarchical organization achieve outcomes people outside of the organization see as valuable through incentives because they cause side effects that will be counter-productive as soon as they move your organization out of its current state.

The article says it’s impossible to solve this problem. But I think the real problem is hierarchical organizations. They act as extractive institutions, removing value from people until those people realize what has become of them and then become parasites on the organizations.

The way out was provided by the framers of agile. I’m not talking about modern, consultant driven agile that uses the language of scrum to give organizations renewed extractive power. I’m talking the agile that provides value through close customer collaboration. That provides people inside the organization and outside the ability to influence each other. Closing the feedback loop eliminates disconnects and maps problems to solutions.

I liked this article. It's original in thought, and gave some attention to why things work stupidly, and are even upheld.

Let's now turn to what one does about. I want to pick one issue to discuss here. Consider, this excerpt:

"Great idea - now I can commit some CPU or memory hog, then you can fix it, and we’ll split the reward."

Here and in other places the author implicitly refers to an underlying tolerance, existence, or undertone of lying, BS, and effete manipulation. In my time in corporate America I've not seen code like that, but I have heard, seen, and been at the brunt of similar actions:

- I manage up and down (a boss I once had said this) ... meaning ... I'm selling up and down the chain of command to put the spin on it I want. And if you're not doing this you're a naive moron.

- The same guy orchestrated work in our team that was sub-optimal (details unimportant here) precisely so his team would be involved, and have work in a larger project.

- The same guy, prior to me joining his team and unknown to me, went around the corp getting internal customers to use a particular service. What internal customers did not know, what that his intent was to make it a one way join: once the customer's code was integrated there was no practical way out. Besides job security, the ultimate aim was in his words "take over the floor by taking over the data."

- Internal service groups whose visions for what to do are what they want to do, and not what their ``customers" need. I've beat that into the ground in other posts. I will just say here: internal service groups MUST be customer driven just like they are on the outside. A roofer can tell me his vision, his price, what he wants to do etc.. I can agree or not. But ultimately I tell the roofer if he's value add or not, if his prices are too high or not, if his work is any good or not. And I will pay or not based on what I see. He doesn't tell me any of this. However, in corp america internal customer's don't have that agency because asshole internal supplies know management implicitly or explicitly will make customers use them.

- My better half works in cloud migrations. JFK the BS, games, lying that goes on to protect internal data centers is beyond even what I've been through. But I can say this: a leading reason companies move to the cloud? They are sick and tired of crappy internal servicing from those who run the private data centers. With-holding costs of labor, data floor space, or lying about it was common in her telling.

Where am I going? A good way to improve the climate at a company, which MUST BE DONE STARTING C-suite, then top management, the middle management, then TLs: BS, lying is fireable. As soon as people learn a company does not pay people to be cynical, that's already way better. I say starting at C-suit, because I learned the hard way substantive change will not happen unless it comes from on-high. See Ishikawa's tunnel analogy in "What Is Total Quality Control?: The Japanese Way." which is a focus on management's roles and responsibilities in quality.

Some examples you right read about where that's worked well: Berkshire Hathaway; Renaissance Tech. An old boss (a Chem-E) in Silicon Valley was a guy like this. These people don't like problems or mistakes ... making one is not a crime but not consequence free either ... but lying/BS always makes them worse, harder to find, and harder to correct.

I got the guy I mentioned earlier kicked our of our division. So I mean what I say.

Openness/truthfulness is a an critical intangible to good companies.

Mostly incompetent management which is very bad at setting and achieving goals is perfectly capable and all too likely to cargo-cult effective management by setting up an elaborate bureaucracy for assigning work and tracking its status, thus preventing work from happening spontaneously.

This is basically every management fad.

Reminds me I registered the domain incompetent.mangement a few years back during a tedious meeting when I discovered the joys of word games with gTLDs.

“how much CPU time do I have for running this code?”

When someone asks me something like that, more likely phased like, “how quickly does this need to run”, “how fast does this page need to render”, etc., that’s the engineer I want to work with. Pair that with “how much of a benefit would there be if I get it to run faster” and you’ve got the makings of a superstar.

My experience:

Good engineering is about achieving organizational objectives, while understanding and managing tradeoffs.

People who aren’t asking questions of the above style, either fail to see the real-world purpose of their work, or they fail to accept that when doing even semi-competent work, the decisions they make tend to have both positive and negative consequences.

Without understanding those two things, it’s tough to be effective over the long term.

I like this, and it seems a lot of people are thinking this way lately

A common theme is that optimization usually does mostly bad things, while maybe arguably from someone's perspective doing one thing really well. I particularly like the example of the threshold cost to get something done versus the optimizer trying to lower costs. Both stakeholders in that example in actuality care about not going below the threshold, but the one drunk on optimization is incentivized to be at odds with keeping that cost center above it, let alone providing any cushion

The model many people here likely have for optimization is compile-time optimizations, but that's actually a weird class of special cases where you actually can prove you're not breaking anything by doing so. Most optimization looks more like strip-mining. It leaves the structures it touches barren and brittle

Most extant institutions have a desperate need to build better resistance to optimization-like objectives

If you’re used to such sprawl, you’d be surprised how effective sleepy HR practices are at preventing it. Suppose you always get a standard, shitty raise at the end of the year by default, unless you bargain loudly, which works rarely and only if you’ve really made an impression throughout the year. There is no defined budget for raises; every significant raise is hard to get, and you never get it proactively without bargaining, but there’s no formal system to avoid spending too much on raises except for the reluctant, reactive approach to giving them. There’s also no system for firing low performers, and it’s only very rarely that you see anyone fired - like that crazy fuck who went on and on about how your source control sucked and should be completely different, and then used a single dot character, “.”, as the commit message when he finally committed something.

I am interested in the rest of this thought… “suppose you only get a standard raise unless you speak loudly”. Then do what?

Ricardo Semler experimented with this at Semco Partners and wrote a book about it which I read in the 90ies. It was called "The other way" in it's Norwegian edition. In English I think it is this one "Maverick! The Success Story Behind the World's Most Unusual Workplace". It was a about self run teams in and corporation democracy.

All though the article has an 100 percent correct description on how things can be in an organization, I do believe that what he describes is a badly run corporation, not a well run. I also believe that the way Semler reorganized his organization is an anomaly. It seldom works this way.

People, us all included, does not work well in cooperation when we are in large groups, without some sort of guidance. In corporations the most effecient guidance are incentives. That said, setting the right incentives and be able to adjust as you go is a very hard task. There is no "one solution" to how this is done, but if you succeed you usually reach your targets.

``` let’s stick to the definition of managerial competence as the ability to set and achieve objectives ``` Loved this statement from the article

This is all true if there is a single hierarchy that everything is directed through.

What works better is introducing forms of competition, so that you might have different shops with overlapping, even duplicative responsibilities within the organization. This always appears wasteful to managers, but is the only way I've seen for change to occur in larger orgs.

As Adams noted, people really don't like competition as it forces them to work and innovate. They will go to great lengths to create a situation where they don't have to and can just coast.

My team once walked ourselves right into this trap with management. We had hit the refresh cycle with our existing servers. We also noted that some new vastly improved CPU generation was going to come out mid-cycle and that we could survive til them with just a partial refresh.

So we "negotiated" with management - let's do a half order now, and another half order in 6 months. The head of the department gleefully agreed and said that makes sense. This was spelled out in a deck that we went thru together, we had his buy in.

6 months later .. same guy - "why do you need servers again / you guys need to be more cost conscious / why can't you write more efficient code / you must be using the wrong architecture / etc".

And so we limped along on a partially refreshed estate.

"Panglossian optimism", indeed Candide.

This is a radical reframe that seems to split the atom for organizational theory.

A century of “we just need to care about this enough” not solving the problem explained in a blog post. Well done.

Let’s not forget the 10% layoff rule just to hire another 10% in the next 6-12 months. Good for everyone, am I right /s?

I found TFA highly informative, and thoroughly enjoy how the author's mind works, along with the playful presentation.

This reminded me of "The Gervais Principle: The Sociopaths, The Clueless, and the Losers".

https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-...

Discussed here 15 (!) years ago: https://news.ycombinator.com/item?id=881296

@yosefk or anyone else- do you have suggested related reading?

that crazy fuck who went on and on about how your source control sucked and should be completely different, and then used a single dot character, “.”, as the commit message when he finally committed something.

I've actually worked with this guy and the description is so perfect I wonder if it's literally the same guy.

Only in our case, the company was too incompetent to fire him and he ended up leaving claiming we were "bullying" him by reviewing his code and pointing out his mistakes!

competent management should add flexibility to rigid goal setting.

The only solution is a market for resources. How would you implement a market for resources within a firm, though?

A very similar thesis was put forward by Galbraith in "The New Industrial State".

I think the author missed the point.

Incompetent management is where the leadership sees management as a line of business vs a role. Places that operate that way tend to latch on to micromanage finance and accounting. When organizations operations or development teams are run by the CFO, only bad things can happen because the CFO’s incentives are not aligned.

I ran a large line of business for a big government agency during the pandemic and faced a similar issue. Government bureaucracy is not typically associated with visionary leadership. However, faced with this conundrum, I called the CEO equivalent and said “We need this.” (In so many words), and later that afternoon we were moving along with critical procurements.

Competent management has tight process controls to prevent waste. But the leadership is the head and the process the tail. If a VP (or whatever) is slave to some bean counter in accounting, that VP cannot achieve her mission. Leadership means we follow the process, but have the ability to act.

In smaller orgs, much less formality and lighter process makes more sense. You don’t want to be running romper room, but the processes required to run a global company like Exxon or JPMC is inappropriate for a startup.

On the other hand, money is not free: many poor souls worked their ass off to pay for our toys. Putting their work in good use is the least of respect.

This post is mostly half-truths, I'll just stick to the core errors:

Of course you could say that this is a badly run company, and to avoid arguing what that means, let’s stick to the definition of managerial competence as the ability to set and achieve objectives. Whatever objective you are expected to achieve, a bigger budget makes it easier.

Yes I would say this is a badly run company, and for some reason they just glossed over that. Probably he glosses over the "set" part of objectives and focuses only on achievement, when setting the right objectives is part of good management. Also bigger budgets don't make every objective easier to hit; it's certainly easier to make $1M of revenue with a $2M budget than a $500k budget but it's not necessarily easier to make a 20% profit.

Let's distinguish between two kinds of management and managers. There's high-level strategic stuff (ie should we deploy this proposed product line) and more operational stuff (which vendor should I pick). Likewise there are different kinds of objectives. A bigger budget will make some objectives easier, like a revenue target or a shipping date. But it won't make it easier to hit a certain profit margin or return on capital target [0]. For-profit companies should always be focusing on returns on investment. For government/non-profits the overall principle is to use money effectively; measuring that is harder but it's definitely not making Tom Everyworker feel good about his clean code. It's delivering value to somebody who doesn't work at the org.

If the senior management has set terrible objectives, and middle management achieves them effectively, then yes, bad things will happen. I would call this bad management; even if most of the managers are good the management overall is still bad. Bad middle managers might be better for the org overall in this case, if we assume workers are all angels who dream of nothing more than doing the "right thing", all agree on what that is somehow, and agree with the authors definition.

On the other hand, if senior management knows what they're doing, they'll set good objectives. It will involve profit not just revenue. It will involve delivering products/features customers want, not delivering things they don't care about, and doing so at a low price. If a division doesn't bring in profit directly (eg IT) they'll figure something else out which rewards good behavior and doesn't punish it. And then competent middle management will achive those goals effectively, and achieve the goals of the org. Note that making Tom happy and letting him ship as much code as he wants is at best only a small piece of those goals, so Tom might actually be unhappier in this scenario.

[0] Assuming there are no accounting shenanigans involved, which again, is part of good management.