13 ms·

Advantages of incompetent management

• advael 2y ago
  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
  • stoperaticless 2y ago
    > It leaves the structures it touches barren and brittle If overdone - definitely. But there are plenty of cases where people forgot to add an index or used linked lists for search heavy stuff or issued rpc for every keystroke.
    • advael 2y ago
      Yes, and solving actual problems is a great way to frame a goal. People often equivocate between "optimization" and "improving things", so I don't blame you for it in particular. Optimization, by definition, requires that something be "overdone", that an objective function is maximized or minimized. Organizations with human decisionmakers aren't incapable of assessing other factors, what priorities not captured by the optimization objective might be relevant, but by framing decisions as optimization, especially throughout an organization or an economy, the pressure against that kind of sanity check is implied and grows the more "competent" an organization is
      • stoperaticless 2y ago
        > Optimization, by definition, requires that something be "overdone" I would disagree. I guess word meanings differ slightly between your and my social circles. E.g. “optimised for read load”.
• fsndz 2y ago
  competent management should add flexibility to rigid goal setting.
• beachy 2y ago
  > 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.
  • yosefk 2y ago
    Had Mr Brooks proven this belief in a revealed preference sense, by voluntarily shrinking his budget, it would add a lot of weight to what is otherwise a nicely sounding but not very believable passage. But I doubt that anyone could be so insane as to not trust themselves with making a good use of a larger budget. One's underlings - quite possibly!
    • advael 2y ago
      Also it's just so much easier to get the benefits of constraint without the downsides if one is in charge of the decisions. Like if you can do something with $10k and have $30k to work with, many adults manage to constrain themselves by merely moving $20k to a savings account, and those who lack the requisite executive function for this simple "out of sight out of mind" organizational schema can often function with slightly stronger artificial constraints, sometimes aided by a collaborator. People do NaNoWriMo or whatever, and while many fail, the benefit of the artificial time constraint motivates a lot of people, despite being self-imposed. In either case, this informal method of constraint is more responsive to situational changes or emergencies than an optimization valve that always wants to bring costs down and doesn't understand any of the functional constraints, as is the case for most finance and management arms of "efficiency"-driven orgs. The game theory of budget inflation is really obvious when you consider it in terms of locus of agency
• com2kid 2y ago
  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 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.
  • yosefk 2y ago
    TFA author - I have worked on low-cost embedded systems. (Tens/hundreds of megs of RAM, not KBs.) The only case where you don't hoard resources is if the system is so small that it's programmed by a small team since the functionality is severely limited by resource scarcity, so there's no reason to grow the team to deploy more functionality. Above a certain not-so-large size, people will hoard resources in an embedded system - they can't ask for more capacity like they would if it was server-side software, but they sure can avoid giving up whatever resources their code is already using. Researchers actually have a limited and smallish hardware budget, so academia is likely to come up with cost-saving ideas even when hardware performance grows very quickly. In the industry you can throw more hardware at the problem even if it's not improving (outside embedded/client devices)
    • causal 2y ago
      As someone who works in embedded systems- I agree. Teams will deploy whole desktops to an embedded system if permitted to expand enough. Architectures will evolve to require hardware that can support the bloated stack. Even on power constrained robots operating in the deep sea it's a pretty safe bet that some of them are running whole Windows VMs.
• yummypaint 2y ago
  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.
  • darkhorn 2y ago
    During Covid European planes were flying to keep their slots https://www.theguardian.com/environment/2022/jan/26/airlines-flying-near-empty-ghost-flights-to-retain-eu-airport-slots https://www.theguardian.com/environment/2022/jan/26/airlines... Another one is to keep communication satalite slotes. If you loose a slot another country can claim your orbit.
  • apantel 2y ago
    Coordination between more than one developer is the root of all evil.
    • throwup238 2y ago
      This is what Knuth actually said: > We should forget about our coworkers, say about 97% of the time: premature coordination is the root of all evil. Yet we should not pass up our opportunities in that critical 3% to take credit for their work.
      • taneq 2y ago
        Remember that he's only proven this statement correct, he hasn't actually tested it. ;)
• JackSlateur 2y ago
  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.
• metadat 2y ago
  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-or-the-office-according-to-the-office/ https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-... Discussed here 15 (!) years ago: https://news.ycombinator.com/item?id=881296 https://news.ycombinator.com/item?id=881296 @yosefk or anyone else- do you have suggested related reading?
• matrix87 2y ago
  > 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
  • IsopropylMalbec 2y ago
    The post is saying that it is a people problem. The gist is that efficient or beautiful architecture does not mirror efficient or beautiful management.
    • matrix87 2y ago
      > But if there’s a reliable & scalable way for vigorous, systematic management to reward the spontaneous human drive towards efficiency instead of punishing it, I am yet to see it. This is the gist of the article, it has nothing to do with software architecture
• agumonkey 2y ago
  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 ?
  • thedaly 2y ago
    The entire premise is based around the idea that one still has to appear busy or has a desire to demonstrate something that will justify a raise.
    • agumonkey 2y ago
      Not to sound too naive, I think this whole paradigm creates a bad soil overall. Before I joined $big-corp I was working better and growing faster. Now that I'm in it, I gradually morphed into this kind of employee.. it's a relativistic game and if the system is stupid and rewards the bullshitter, you end up like them (at the risk of your mental health quite often). A good group is one where people are motivated to be sharp, creative, fast, efficient, curious, sharing, open minded IMO.
• bwestergard 2y ago
  A very similar thesis was put forward by Galbraith in "The New Industrial State".
  • joeamroo 2y ago
    I don't see the similarity, mind explaining?
• YZF 2y ago
  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.
  • sroussey 2y ago
    > This extended to decisions that involved spending money, not just should you pick language X or language Y for your next software project. Just want to point out, the choice to pick language X or language Y is very much about money. Training, triage, getting into production, scaling, testing, etc. Most bigger picture technical decisions are in fact, economic ones.
    • YZF 2y ago
      For sure. I was just pointing this out because I've worked in organizations where there was no problem with delegating language choice to engineers but the minute any actual money had to be spent it was treated very differently. You are absolutely right that technical decisions are economic ones.
• Spooky23 2y ago
  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.
• deleted 2y ago
  [deleted]
• mr_toad 2y ago
  > 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.
  • electrodank 2y ago
    Can we track this with KPIs for our annual OKRs?
• jiggawatts 2y ago
  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.
  • __loam 2y ago
    This is brilliant and psychotic.
    • pictureofabear 2y ago
      Psychotic indeed. It would feel like working for the mad hatter.
      • jiggawatts 2y ago
        “I expect you to do your job.” “Madness! You’re crazy! I can’t be expected to work under these conditions!”
  • sublinear 2y ago
    If you have management failing to communicate business needs they'll make everyone beneath them look just as bad if not worse. At the end of the day there's nothing naive about doing a good job. If you have any employees focusing too much on metrics, but especially your management, they're incompetent dead weight. Doing a good job is simply less work for everyone, but it starts from the top down.
    • jiggawatts 2y ago
      To clarify: each month measure a real business need. The trick here is that there are many needs, and the selection must be random each month. Take a service like Google search as an example: if the number of searches per month is the consistent KPI for the tech team, then they’re incentivised to sacrifice customer satisfaction by returning junk results so that users are forced to do multiple searches to find what they want. But if they’re only rewarded for the increased search volume the one time, the next month the metric might be customer satisfaction instead and they’ll be penalised for cheating in this manner. The key aspect is not repeating metrics — but the metrics should be valid.
• sirspacey 2y ago
  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.
• napierzaza 2y ago
  [dead]
• f7ebc20c97 2y ago
  The only solution is a market for resources. How would you implement a market for resources within a firm, though?
• pictureofabear 2y ago
  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.
  • fhd2 2y ago
    I always thought laziness was a good thing, at least in our field. I'm pretty sure I'm lazy. When push comes to shove, I will do boring work very diligently, but if there's a better way, I'll look for it. Contrast this with someone just happily diligently working away no matter what, for the sake of keeping on moving. It's very easy to get stuck on a local maximum if you don't stop and think (i.e. do nothing) on a regular basis. I think the author's point is that the latter can be quite harmful, which is evidently unintuitive for many people. Granted, calling an effective servant leader "lazy" is possibly not great, and the word does have a negative connotation whether I like it or not.
    • Aeolun 2y ago
      > I will do boring work very diligently That’s amazing. I can’t bring myself to. If the work is boring or pointless it just wont happen, or at a glacial pace.
      • nottorp 2y ago
        Somebody has to do the boring work for the whole to be functional, and pointless work may be only pointless to some (ok, not always). Let's just say you're not interested in the thing you work on overall. Because you aren't or because you're disincentivized to think of the whole picture by the system you're in.
• neilk 2y ago
  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.
  • benreesman 2y ago
    This is a great comment! I only hope to add color, not to dispute any of it. In my experience software shops that find product/market fit exceptionally early can not only tolerate benign neglect, but are best served by it while that market is still contended. Capitalism works amazingly well when the referees just Godzilla stomp on cronyism and nepotism and monopoly and other market failures: the sharpest people want to work places that are in the fight and give everyone a stake in the outcome: such people in such settings are largely self-organizing on the basis of mutual respect and esprit des corps. A clear and serious competitor or competitors rapidly weed out ceremony and careerism while strengthening ruthless meritocracy (which is incidentally good for inclusiveness: no shortage of ethnic minorities in pro ball). The tricky thing is keeping the incentives aligned as markets mature and the rot of capture sets in. All of today’s high-profile behemoths lobby extensively and employ former McKinsey people in policy level roles (Google is run by one). Unfortunately it’s not as simple as throwing out the careerist middle managers or domain-soft executives when the scale exceeds “hacker culture”, you need executives that use their organization-fu to hold the rent seekers in check, and that is a rare breed.
• nargella 2y ago
  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?
• jjmarr 2y ago
  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 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 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.
  • chii 2y ago
    > When this happens, leadership should back these initiatives. this requires trust in the "low-level" people. It also implies that the "low-level" people have sufficient power at their call to execute those initiatives, without directly involving the leadership. This works if leadership is not under threat from the low-level people (e.g., in a democracy, where your survival is not contingent on kinship with the military's cooperation). > He trusted his subordinates and won. So this is why i suspect this does not work in most modern organizations : the leadership does not (or cannot) trust their subordinates to make the correct choices. In other words, the leadership doesn't want to cop the cost of a wrong decision in the hands of the "low-level" people, and insist on seeing evidence/plan/etc (which basically means they're not really deligating the decision down, but pushing the decisions up!).
• klooney 2y ago
  > 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.
  • ghiculescu 2y ago
    What is an example of this?
    • askafriend 2y ago
      Obviously there is no legitimate example. It's all just fantasy.
      • mhh__ 2y ago
        Is Linux not a valid example? Look at all the shite Microsoft bolt onto windows.
    • MathMonkeyMan 2y ago
      maybe GNU Screen
• TheJoeMan 2y ago
  > 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?
  • ghiculescu 2y ago
    I took his point to be: some people will always get incredible work done no matter what. Enable them to still get paid well. For everyone else just keep them around for when there is stuff that has to be done, and when there isn’t (most of the time?), let them spin around on their chairs/compensate accordingly.
• dboreham 2y ago
  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.
  • xdavidliu 2y ago
    sic?
• scrubs 2y ago
  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.
• vegetablepotpie 2y ago
  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.
  • yosefk 2y ago
    Most (all?) organizations are hierarchical above a certain size. I don't think agile ever addressed the resulting problems; some of it was designed for smaller teams. For an "agile" take on organizations of a medium double digit size and up, see SAFe - there's nothing quite like it
• sheepscreek 2y ago
  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.
  • yosefk 2y ago
    Thanks for your kind words! In terms of what I think & meant to say - I'm pretty sure that incompetent management (or incompetent at least in some key areas) can scale to fairly large org sizes, and that eventually competent management will evolve for the org to survive. I used "competent" and "incompetent" unironically, not as proxies for big & kafkaesque vs small & nicer places, but as in can/can't set and achieve goals, which is something you will need to be able to do to survive eventually.
  • fhd2 2y ago
    From my experience, those extra rounds and puzzles don't improve the quality of hires. But they: 1. Create objective consensus. In a small company, you can hire based on intuition - talking to a candidate once (and ideally seeing any kind of work sample) are mostly sufficient for me right now. In larger organisations, I had to _defend_ hiring decisions, so you need to create evidence of objectivity. 2. Filter a prohibitively long list of candidates. Gotta have _some_ way to do it, even though I'd argue selecting for those most likely to hang in there for a long hiring process isn't the best way. 3. Create a (usually faux) narrative that you rigourously assess candidates and therefore only the best work with you. Now, I won't say there aren't some benefits to more exposure to a candidate and their work, whatever it is. But in my experience, extensive hiring processes are really more about the stuff I listed above, even if nobody involved would think of it that way.
• aranchelk 2y ago
  > “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.
  • yosefk 2y ago
    You say that good engineering is about achieving organizational objectives. I say that competent management is about setting organizational objectives. Therefore, you're saying that good engineering is about satisfying competent management. From this POV you see increasing efficiency beyond the level required by management as the opposite of being effective. This is correct from the angle of the game played in the org. This is not necessarily correct from shareholders/other stakeholders' POV - sometimes it is, sometimes it isn't. But I agree that going against the grain of managerial objectives will make you ineffective in the long term - management will see to it. You need to do less of this or find less competent management if you want to do more of this.
    • aranchelk 2y ago
      I don’t regard efficiency as one obvious thing. Is it single threaded efficiency? Best hardware utilization? If it’s an application that’s guiding external resource utilization, should you even be limiting your efficiency measure to just your code? How often does that code even run? I.e. does its efficiency even make a difference? And once we define what we mean by efficiency and come to a conclusion that for the code we’re writing improving it will be impactful, recognizing that it’s only one of many worthwhile engineering goals including readability, test-ability, correctness, security, flexibility/adaptability, and time/cost effective implementation, and come to the obvious (though slightly sad) conclusion that at least some of these goals are always in opposition. We can’t really write code that optimizes for all of these things. So now we have to prioritize, and if engineers are taking it upon themselves to decide which goals are most important to them, without considering the needs of the organization (that’s paying them to do the work) to me that’s not a good sign. Sometimes managers are ineffective and ask people to do dumb stuff. Sometimes engineers like to ignore the fact that by some metrics their work is always going to suck and avoid the mental overhead of having to pick which metrics to optimize for. Some real examples of these tradeoffs: * Pure functional code is more straightforward to test and IMO easier to prove correct, but it will likely have more GC overhead than imperative code with mutable variables. * Techniques like STM can lead to much higher throughput on multi-core systems (while effectively eliminating entire classes of concurrency-related bugs) so you can do more with fewer servers, but it introduces some overhead on each invocation. * More effective route planning software could be much slower and CPU-intensive to run but that inefficiency may be dwarfed by vehicle fuel savings. * In the language I work in, monomorphic code (all things being equal) is always faster and more efficient than its polymorphic equivalent, but I often use and implement polymorphic functions so I’m able to handle many types of data down the road.
• Manheim 2y ago
  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.
  • yosefk 2y ago
    I don't trust someone claiming to have run a heterodox org as much as someone claiming to have worked in one, like Creo sister comment threads. Any incentive turns perverse, and incentives are not how our zillion cells are prompted to make our bodies work. Incentives work to an extent, but have inevitable adverse effects.
• bjornsing 2y ago
  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.
  • yosefk 2y ago
    An ability to operate reasonably effectively under the constraints of bounded rationality is an ingredient of competence. You seem to define managerial competence as making the right decisions, and thus file bad decisions under incompetence. I believe this definition to be intuitive but useless for practical purposes. Instead, I define managerial competence as an ability to set and achieve goals, and claim that a few undesirable conditions commonly observed in the workplace are a natural consequence of managerial competence according to this fairly uncontroversial definition.
    • Aeolun 2y ago
      While I sort of agree with the premise, isn’t that a fairly low bar? From the organisations perspective it doesn’t matter if the goal is achieved with 5 or 300 people, as long as it is achieved, but it feels wasteful to me. I’d also kind of require the goals that are achieved to be the ‘right’ goals to qualify it as competence. It’s hard to call a general that leads his army orderly into a trap competent.
    • bjornsing 2y ago
      > An ability to operate reasonably effectively under the constraints of bounded rationality is an ingredient of competence. Sure, and that’s a reasonable argument for the claim that the less senior manager with the budget is competent if she refuses to reduce it, because she understands that it will not be increased again after the crisis is over. But it’s not a good reason to call the senior manager who doesn’t understand the situation “competent”. The root cause of problem is that her rationality is too bounded, which I would prefer to call “incompetence”.
• wolfbyte 2y ago
  ``` let’s stick to the definition of managerial competence as the ability to set and achieve objectives ``` Loved this statement from the article
• lexicality 2y ago
  > 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!
  • datavirtue 2y ago
    Given my total experience with code reviews, he was probably spot on.
• mvc 2y ago
  > the hedgehog is too proud a bird to fly without a kick Say what you will about Russia but I do love their proverbs.
  • lexicality 2y ago
    There's a lot of fantastic Russianisms in this post, for example > “What is to be done?” is a pamphlet by Lenin, who proposed some things to be done, and went on to do them and then some, with results most charitably described as mixed. made me snort my drink out of my nose
  • mvc 2y ago
    Apparently not a "real proverb" for those as gullible as me who assumed it was :-)
• GlenTheMachine 2y ago
  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.
  • iknowSFR 2y ago
    NREL?
    • pythonguython 2y ago
      Nope, I checked his post history. As someone who works in a similar lab, what he’s describing certainly isn’t uncommon.
  • lelandbatey 2y ago
    I've really found this to be true; I've had just a small handful of great managers and most of them worked more like "team secretaries", with just two who would also deploy political capital in an expert way to keep things running well. Those were the best. Most of the good managers topped out at acting as personal assistants to the team, helping (not dictating) to keep things organized. The just ok managers barely did anything, which was still not bad. They didn't make things worse but didn't make them much better either. The worst would dictate, randomize and foist cleanup of their own making onto you. Those folks I often wished would just stop showing up to work even if they kept collecting a paycheck; things would have run smoother if they did.
• steveBK123 2y ago
  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.
  • akira2501 2y ago
    They should have put the second order on the books immediately. All companies have a ledger. Failure to understand the use and management of this ledger causes these types of problems. In the articled example, you could put something like a "buy back" on the books, so while your budget is temporarily reduced to benefit the company, the end of year shows the same amount you _would have_ spent, so next year you don't have to fight uphill for "more money."
• spacecadet 2y ago
  "Panglossian optimism", indeed Candide.
• DonsDiscountGas 2y ago
  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.
• tomohawk 2y ago
  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.
  • datavirtue 2y ago
    Low energy state is always the goal.
• egorfine 2y ago
  I have recently started to recognize this pattern of idle development in some very well known software projects. What happens is this. At a certain time the team delivered a perfect version. So perfect that nothing is needed to be refactored or added to it. It's done. Then the team immediately gets bored. In order to protect job security, the team invents new work for themselves, a huge architecture refactoring, that sort of things. Sure, why not, we have time and resource, reduce technical debt, etc. A couple years go by and now the product is a rotten swollen mess with tons of useless verbose documentation, tons of integrations, a mind-boggling number of features and, of course, AI. And the product cannot even perform its original task because that was abstracted away a long ago. Not gonna point fingers, because I'm gonna immediately get downvoted to hell. But we all know examples of that taking place.
• jjk166 2y ago
  > What constitutes managerial competence? As a vague starting point for an answer, we could say that competent management sets achievable objectives and then achieves them, by organizing and incentivizing the necessary work. This is a terrible definition, and the author proceeds to make their entire argument based off of specifically the shortcomings of this definition. Any idiot can set an achievable objective and then achieve it. That's not competence, it is the bare minimum level of functionality to claim something is being managed. Having people dig a ditch and immediately fill it back in, over and over again, would be labelled as competent management under that definition. Competent management identifies critical objectives and prioritizes resources such that they are accomplished adequately and efficiently. If your goal is to get something done, then yes, obviously having more budget to do so would be better. But that's never the actual objective. The real objective is to advance the organization's goals - increase profit, raise capital, gain market share, avoid liability, what have you - which means making optimal use of finite resources. > But wait, seriously though, what’s the math here? What are we maximizing? Revenue minus cost? Revenue divided by cost? I mean, shrinking the cost has got to be helping with these?.. Well, sure it’s helping, but it’s not helping you, because you don’t bring any revenue by yourself, unlike cost, which you very much do incur all by yourself. The math with you is, we tell you to do something if the cost is below a threshold. If you won’t commit to doing it cheaply enough, we’ll find someone who will, and if we can’t, we won’t do the thing, or reconsider the options in some other way. But exactly what the cost below the threshold is changes nothing in any math related to you, except for a lower cost making your job harder, since you have the same objectives to achieve. The firm’s bottom line - sure, lower costs help there. But the impact on the firm’s “revenue - cost” doesn’t trickle down to your “cost < threshold,” because you have no revenue. This entire line of thinking is incompetent management all the way down. At the top level, they have either failed to recognize their critical objective (improving the revenue to cost relationship), or failed to allocate resources to accomplish it adequately and efficiently (setting up an incentive structure where middle managers can successfully deliver). The middle manager in this scenario is not even doing any management - the decision of what would be done and what resources would be allocated was made above them. This isn't a manager, this is a messenger assigned to communicate orders from on high to their peers. Perhaps they will get to make some lower level decisions over how exactly their team accomplishes the goals, which could yet be competent, but given that their goal is advancing their corporate fief it seems unlikely. > What happens in a badly run place? In a badly run place, management is bad at setting objectives, so you have people aimlessly wandering about, lacking clear goals, and just doing stuff because they want to. They see an optimization opportunity and they gladly pursue it - it’s interesting, it’s fun, it’s good for the company, it’s what they’re here for... they don’t mind shrinking their resource footprint, because nobody monitors the resource budget properly, nor presses them to meet any targets very hard. That's not a badly run place. That's just a place where people aren't being micromanaged. Top level leadership is supposed to give broad direction - are we more concerned with growth or cost reduction, for example - and make sure that there are enough people who are sufficiently motivated to make that happen. The specifics of how they can best accomplish those goals ought to be determined at that lower level either by the individual employees or, where collaboration is necessary, the team level. Incentives, targets, budget monitoring, these are all tools that management can use to solve problems, but it's not a failure when they are unnecessary, it is a mark of competence.
• wdh505 2y ago
  Well, I'm 2 days late tk the party, but here I am. I know of several groups that have the best of all worlds for a painful learning cost: apprenticeships. I know that the typical job growth of a apprentice involves doing your tasks, anticipating, then moving to management if you have the propensity toward that. The most intense desk jobs of the accounting world is the "big 4" which have 2 cycles: boom and consolidate/bust. The boom cycle promotes the technical "senior" to the management position and requires the manager to review the work of the guy who just got promoted to senior. The manager becomes more concerned about roi over time and eventually goes into sales/estimating. The consolidating cycle is where the fat is cut because it is "up or out" to maintain a pyramid structure. Those who get the boot often manage well (due to the high exposure) and are confident when starting a apprenticship business of their own (have technical and management and client service skills) This pattern is similar for all apprenticeships I think like plumbers, cement masons, accountants, etc. The work product is well known, the skills are transferable, and correctness are easily observed by others with the skill. The pain is when a manager takes tips from a "competent manager" as defined in the article who then has subordinates prioritize low roi activities like formatting or making it clean from sawdust before closing a wall up. Soon a roi-focused manager will look over the competent-manager's shoulder and say why is your team slow, and the answer is "they are slower than me (because they are being trained to look pretty) and i am telling them to work fast, maybe I need to tell them that they are low performing" and turnover increases until that manager stops training people as the manager isn't the client.