Advantages of incompetent management
yosefk.com
yosefk.com
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.
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.
You are absolutely right that technical decisions are economic ones.
Best place I ever worked.
This was “the Creo Philosophy”:
Our priority is to provide unique and sustainable value to our customers.
1. All decisions must be based on sound economics.
2. Key decisions are made in consensus, with full team agreement to accept and implement the decision.
3. We believe that people are most effective when self-managed.
4. Compensation is based on contribution, gauged largely by an annual peer review.
5. All employees share the wealth created by their hard work and innovation.
Creo was extremely proud of how “flat” the organization was but my primary take-away from there as an ex-employee is actually how important management is.
First and foremost, management created a shared vision of the future. Not silly posters to laugh at but a real shared mission. It was exciting and motivating. Every Creoite knew how the world would be changed when we were successful. Decisions could be distributed because it was obvious which outcomes were aligned with the companies goals. Trying to push outcomes not aligned with the goals was hard ( as it should be ).
Second, there was a strong framework for how decisions were made and how to identify good decisions from bad ones. Economic thinking and consensus were two important principles that you were expected to follow unless you could demonstrate very good reasons not to.
Third, management provided a great deal of mentorship, both through direct education and through calling re-enforcing the primacy of the principles. One of the reason Creo could be so “flat” is because everybody knew how the executives would behave if they were in the room and they could insist that others act accordingly. It was easy to assume executive sponsorship without having to resort to politics. “We do not tolerate politics” was an important mantra through the best parts of the company history.
Most importantly, I got to experience the everyday effectiveness of the organization under three different CEO’s: Ken Spencer, Amos Michelson, and Mark Dance. The “culture” was only as good as the man at the helm.
At Creo, we made the claim all the time that we basically did not have hierarchal management. It was true we did not always have “supervisors” but we had the best management I have ever worked for.
As said above, Creo stopped working when it acquired a rival that had more employees than it had. The politics exploded. The effectiveness disappeared. Financial performance followed. The company was sold to avoid a shareholder revolt. A sad end for a spectacular organization.
The original Creo employees stuck to the principles. Well, except management. Hierarchical authority was suddenly more important. Decisions did not have to make economic sense. What mattered was who was doing the deciding. Consensus stopped being a requirement. Speaking truth to power stopped being a path to better decisions and started becoming a career mistake. Executive sponsorship became real and aligning with people in position became the most important criteria for individual success. Empire building replaced shared vision. The lack of alignment between making the company successful and being successful as an employee completely broke. The company failed.
Managers and employees looked at Creo folks and their “philosophy” like naive children. Sure “the philosophy” worked well enough for Creo to beat them to begin with but, once merged, the acquired were right. Creo was idealistic and naive. But this was not inevitable.
Why did Creo fail? Did “the philosophy” not scale as the final CEO I think believed? I do not think so. I see it purely as a failure of management.
The final CEO provided little vision. Other than a focus on the bottom line, there was no insistence on economic decision making ( eg. instead of breaking up meetings because they had too many people in them - too expensive - he held meetings with dozens of people in them ). Instead of coming down on politics and insisting on consensus, executive authority became sacred. In fact, the term “consensus” became most often used when an executive used it as an excuse for their own lack of leadership by claiming the team should have to solve its own problems.
If strong management had provided the leadership, the mentorship, the vision, and support for the culture ( most importantly the principles of good vs bad decision making ), Creo would still be with us. If I was lucky, I would still be working there.
Creo ruined me in a way. I have never been able to accept why things cannot be as good anywhere else. Such simple ideas. So dramatically effective. Unfortunately, good management ( executive level ) is an absolute requirement. Even hundreds or thousands of well trained employees was not enough to make these principles work without strong management behind them. Management matters.
I got to experience some amazing leadership for a while. All I can do is try to emulate those role models as best I can. And everywhere I go, I try to make economic thinking an important part of how decisions get made.
RIP Creo. You left us too soon.
While I don't have the shared experience, I think I've also landed on economic thinking as part of my primary model of how I think an eng team should function and been trying to push the concept with limited successes (although I've termed it differently). And I've never observed a team that I think has executed on it really well.
Good management is about leading people (i.e. who follow voluntarily), not dragging people along.
It sounds like we agree.
Nobody used the word manager or boss annd anyone could be in a leadership role, it was based on meritocracy.
So thank you very much for sharing and recommendations for further reading will be much appreciated!
i suspect that these failures are a failure for humans to adapt to a larger herd than the traditional tribal size - anything beyond a couple hundred people max.
https://www.nytimes.com/2021/05/11/science/dunbars-number-de...
That much is true and uncontroversial.
What the article takes issue with is the exact number of 150, which can vary from person to person. But really, the criticism entirely misses the point. The number is just a rule of thumb derived from extrapolation. It's not a hard and fast rule like "You can only have 150 friends". Obviously.
Investment bank trading desks in the pre-2008 era, partnership at the big strategy consulting firms and even “multi-strategy hedge funds” now are actually all collections of very incentive aligned businesses. They share the Creo quality of making lots of millionaires and people looking back on their time there as one of great freedom and achievement.
In all these places, employees are paid according to the revenue they generate, with seemingly no ceiling to what you can take home. It is true that the size of any one cell doesn’t scale beyond a small number of people. But all the organisations I mentioned above scale by having units tackling small pieces of vast markets.
The main lesson I took away from reading “Barbarians at the Gate” is that big companies hugely suffer from the principal agent problem, where management is mostly out to enrich themselves at the expense of shareholders and employees (sometimes). This looting is however only possible at a company that was established by a founder with a deep vision and passion for the product and has set up systems and culture that generates sufficient cash for the professional management to leech off.
What I have not read yet is a systematic study of these “cellular organizations” and what the common features are that make them successful. My guess is that the key is that each “unit” or “cell” has measurable economics that makes it possible to share the economic value over a sustained period of time. A bit like why sales people get paid a lot.
The migration of shitheads from Wall Street 80s 90s to Silicon Valley - technobros is for me a solid example of this.
This is a really hard problem, due to its influence on the morale, and the danger of weaponization of these mechanisms by bad actors.
This was a High Frequency Market making company, total employees ~ 250. "Flat" management, nobody had titles, just responsibilities. Everyone understood the mission and goals. Everyone was highly compensated and empowered to make important decisions without explicit approval.
The whole thing fell apart when the company grew and finally failed when merged with another larger competitor.
These great orgs only last when they are kept small.
It’s much harder to maintain a shared vision among 20 people than it is for 10.
It get exponentially harder as you add more people.
Since a shared vision becomes hard to maintain, only those with the vision (read: managers and leadership) can make decisions.
Better and healthier organizations are possible, as Laloux writes about. They are rare though -- and difficult to sustain in our current Western society. As with Creo, you definitely need enlightened management or enlightened major shareholders to "hold the space" as Laloux writes.
At the end of the day, if there was a time critical decision and there was no consensus someone like a project manager would make the call. I haven't actually seen that happen, a well functioning team/project generally is able to make decisions.
I would say though that it wasn't simply the dilution of the culture, there were also some real business challenges that led to external pressures and eventually the sale of the company. A takeaway from that is that business is an important part of, ya know, being a business. A financially successful business has more room to be a great place. Creo did well and grew well but operated in an area where making money isn't easy (the printing industry).
It seems that Creo bought out their competitor, but in fact they got absorbed by them and paid for the privilege.
They are begging people to engage but I have no idea what projects are paying the bills, which ones are drags, and various other missing information.
If you keep all that a secret people have no choice but to tune out and just expect management to handle everything.
I don't think the current CEO wants anyone else loudly expressing concerns over the future of the busieness as we are trying to shift away from contracting to SaaS. This is an 80yr old company, mind you.
Now we are trying to grow and bring in employees (for a contract), promising them stock and supposedly stable employment but in the end most of the dozens of employees who are brought in will be let go before they vest. The long term base employees (there is a cache of 20+ yr employees) will have their stock price increase after these people (they will let go) put in years of work to deliver on record-breaking contracts. None of this is the stated intention but it's going to go down like this. About that time the CEO will retire and cash out.
Would you mind adding something there for posteriority?
https://whattheythink.com/articles/101480-amazing-balance-wa...
https://www.encyclopedia.com/books/politics-and-business-mag...
(https://www.youtube.com/watch?v=mXTWMlRK0LE linked from the above - I remember this video but couldn't find it directly on YouTube :( )
Huh. That'd make sense. From the outside, Creo Scitex looked like an unstoppable dreadnaught.
Creo acquired ScenicSoft in 2002. Alas, I saw no evidence of economic thinking.
Whoever was in charge of software was proud of having never canceling one of their ~dozen products. Me asking if there was a P&L for any of them was among my top 20 most brave/stupid work related selfowns.
They did cancel Color Central in short order. (Payback?) Basically CUPS with features for print manufacturing and a purdy UI. Super boring, but a necessary product. Although no longer affectionately known as Cash Cow (the internal code name Illumious had given it), it still had a huge installed base, had steady revenue (upgrades), and maintenance was on auto-pilot.
About a year later, Creo licensed Color Central's biggest competitor. (Sorry, forget that company and product name. I remember that they were a great team though.)
Rowan's UpFront was part of the ScenicSoft acquisition. Advanced print manufacturing planner. Pretty much unparalleled. A true diamond in the rough.
Further, I had invented a novel imposition engine for bookwork. Specify all the sizes and (crucially) the desired binding -- voilá, out comes a Preps template production plan. (Preps was ScenicSoft's flagship product, the gold standard for print imposition.)
Automating bookwork planning was the holy grail. The long sought replacement for Preps' very complicated, very necessary template editor.
I don't think the Creo people understood what they had. They were so focused on their (awesome) digital plate stuff and adjacent. Like most, they probably treated the bindery as an afterthought.
I forget how Creo managed to let Rowan slip thru their fingers. But don't worry, he did it all again and earned a pretty good exit the second time around.
--
Whatever Creo's shortcomings, the president and owner of ScenicSoft totally failed. After many rounds, he managed to negotiate Creo's initial $70m offer down to $9.5m. So saavy.
Acquisitions are just tough. There were good people with good intentions and teams did try to work together. I spent some of my time trying to bridge the teams, with some success. What was missing is a good idea of how to restructure things to eliminate the duplicate efforts which is super tough when you're also dealing with large install bases. There were a few technical attempts to bridge the architectures and bit and pieces from "Creo" machines found their way into "Scitex" machines.
And compensated at a president’s salary for the new insurmountable levels of responsibilities right?
As it turns out, companies that don't concentrate all of the power and decision-making in one person tend to avoid ending up with "insurmountable levels of responsibilities".
In my experience this isn't a core requirement so much as the ability to discern if a proposed strategy is good or not based on first hand experience. In other words, the ability to spot very well written bullshit yourself without relying on anyone else's perception of it being bullshit or not. If you need to rely on other people's opinions or the way a proposal is written or something else then it will not work. It's very rare for this to be the case at a larger or public company. Even if the CEO has this ability if the board doesn't then it will be the same.
As a metaphor: for problems in NP, verifiability is in P. So you have some super-duper savant alg. that outputs some answer, but even a dumb-system should be able to quickly verify. Our managers are typically dumber than this.
And tust is a two way street. It requires effort from both sides.
Aligning each employee's incentives with ROI seems extremely difficult.
The former Yugoslavia had a system of self-managed enterprises where large firms shared profits equally among employees and employees ran the enterprise democratically (usually electing a manager). The problem is that profitable enterprises would democratically decide not to hire any more people since doing so would dilute their profits.
But, I'm sure the first multicellular organisms were no picnic, either. Eventually humans will learn to work together way better than today and anyone trying already now has my attention and sympathy, especially if there are positive testimonials by employees (there's no shortage of managers who claim to run a different kind of org / culture when it's either false or true in a bad sense, meaning, their org is much worse than the standard system; in fact I like managers who apply zero lipstick to the pig that is their org and do the standard ugly thing in an openly ugly way - teaches you how to operate in this environment more quickly vs trying to get people to remain naive to their detriment)
That said, I think your analysis is a bit weakened by a moral elements (good managers vs bad managers). And even more, it's not necessarily bad for an organization to have locally controlled resources. One can posit an omniscient central controller that would manage resources better than local managers but it's likely that there are limits to both central controllers and local managers. What's "best" depends on the task, the organization and who's judging the result.
which is fine, because if hiring someone would dilute their profits, it means the new hire is decreasing the efficiency of the organization. Normally, you would hire if you find that the existing employees cannot complete all of the work required, as there's too much - aka, leaving business/profits on the table due to lack of room.
1. Could you expand more on the practical details of how decision making by consensus worked? Eg if I want to buy a $1m machine, how many people and which people do I convince that this makes economic sense? Who can actually sign off on the purchase?
2. How did incentive based compensation work for employees whose work could not directly be tied to the bottom line? For example, legal and compliance staff sometimes prevent profit making activity that is deemed as risky - making these functions prime candidates for internal monopolies that drag down the performance of other groups. Or recruiters whose natural incentives revolve around number of people hired rather than efficiency.
3. How is economic decision making enforced? What stops a middle manager from acting out of self-interest and expanding his own headcount or project scope to increase his own importance at the expense of company economics? Even if there is some consensus required, it’s probably not hard to convince a few friends with fanciful projections. Is this mostly a camaraderie / honor system thing?
If you feel like these are the wrong questions and are somehow missing the point - let me know! Sounds like Creo pulled off something special and I’m sure there is lots to learn.
2. I guess it's no different than RSUs, stock options or a bonus plan or any other form of profit sharing. At the end of the day people are trusted to do their job. At least during my time with Creo it didn't seem to create a barrier to experimenting, if anything there were some projects that were maybe were too experimental.
3. Not enforced in any formal way. Peer review and just culture/peer pressure would do the job. I am aware of one case where someone abused the system and someone found out and they were fired. In terms of your example, the power was fundamentally less with the middle manager and more with the engineers in the first place, so there wasn't a lot to gain personally from empire building as in traditional companies. For the most part managers did not manage people, they managed projects. For example, as a software team lead I was under a project manager but I didn't report to him in the traditional sense of the word and they did not control my compensation (which would be mostly the outcome of the peer review process). The project manager's success was also measured by peer review.
I think the interesting thing about Creo, and what made it tick, was that the founders were in it not just to make money. They wanted to create a place they would want to work in, were passionate about this, and tried to hire people that fit into this vision. They have seen the things they didn't like and thought they can do better. It sort of happened in the right time and place where it managed to gain momentum.
EDIT: I managed to re-find this old video of Amos Michelson explaining how this works better than me: https://www.youtube.com/watch?v=mXTWMlRK0LE
A way to not be extreme is to do that with x% of people (beyond their hierarchical level in the organization).
The best manager I had was:
- focused on organizational efficiency. She’d tell you “you three, make a decision” instead of groups of 10+, which seemed to be the default
- wouldn’t sugar coat things, but was never mean (many leaders miss this). If she disagreed you knew it but it was done in a respectful way.
- the best part of her management was goal setting. I was 3 goals, and even 10 years later I still rattle them off. Short, actionable. Her attitude was “if your work doesn’t move towards these goals, stop doing it”
Like you, it’s hard to work in jobs later when management isn’t up to snuff.
It is possible to have efficient, well managed large organizations.
It’s just that the vast majority of managers don’t have the skills and as you said, without someone at the top setting the rules it never works.
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.
Another one is to keep communication satalite slotes. If you loose a slot another country can claim your orbit.
> 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.
Which is absurd. Cloud resources on servers with more CPUs then I have, and yet the difference in timing is measured in tens of minutes.
You can apparently bring it down to 5s by suspending instead of creating instances.
In an ideal world, the policy groups imposing these inefficiencies would get billed for the cost of their policies, but I've only ever seen situations where everyone else pays the cost of their incompetence.
On the plus side, I actually get actionable notifications from the stuff, so it’s not purely bad for me.
Github Actions is pay-per-minute-used, unfortunately, so they may have a negative incentive to speed things up. Unless people become frustrated enough to switch to a non-bundled provider.
https://world.hey.com/dhh/we-re-moving-continuous-integratio...
The server the resources run on may have more CPUs than your dev machine, but are you allocating more CPU to the specific test job than you desktop has?
Spin up new node, congrats, now you have to clone the whole repo from scratch. Oh, "npm install" was not cached, let's download half of the internet again, pull ":latest" of some multi-GB docker images while you are at it. For good measure, "make clean", because...you never know and nobody bothered to architect our build system to use a more sane tool than Makefiles, btw remember to only use make -j3, because rumor has it that the build fails intermittently when using more cores! Finally, run every test that couldn't possibly be affected by the commit in question, preferably the big e2e-suite. As someone else mentioned above, all of this running on some dog-slow cloud network attached disk.
There you have it. Spinning up more compute is not the solution, it's the cause. Keep one machine on and improve on your build tooling. I guarantee it will be magnitudes faster than any ephemeral pipeline.
This is entirely solvable by getting more resources. At least 2x more runners, each at least 2x as beefy. You could go 10x and I doubt it would be anywhere as expensive as the amount of money company wastes on devs waiting for CI. Alas, good luck convincing people managing the infra of this.
Incremental is several orders of magnitude faster and cheaper. Just need to invest in your build tooling.
Only if you have a single job to run. In practice it doesn’t really matter to the dev whether CI takes one or 5 minutes. When it all goes over 5 minutes is when it gets annoying.
For example, using Kubernetes with Docker where each pod is some virtual ECS 4-core whatever instance, assuming scaling the workload over a 1000 instances will be fast. Which in your case will lead to said pods individually spending 90% of their time running 'npm install' , and each pod is way slower than your desktop PC.
Different tests have different needs and bottlenecks. For example, if you're running unit tests, with no external dependencies, you'd want to separate out the build process, and distribute the artifacts to multiple test machines that run tests in parallel.
The choice of using a few big machines or more small ones is usually up to you, and is a wash cost-wise. However I do need to point out AWS sells you 192 core machines, which I'd wager are WAY faster than what you're sitting in front of.
And Amdahl's law is a thing as well. If there's a 10 minute non-parallizable build process, doing a 10 minute test run on a 192 core machine vs doing an ~0 minute test run on infinite machines ends up being only a 2x speedup.
And there's such a thing as setup costs. Spinning up an AWS machine from an image, setting up network interfaces, configuring the instance from scratch has a cost associated with it as well. And managing a cluster of 1000 computers also has its set of unique challenges. And assuming that if you ask Amazon for a 1000 machines at a drop of the hat, and plan to use each for a minute or two, AWS will throttle the fuck out of you.
All I'm trying to say with this incoherent rambling is KISS - know your requirements, and build the simplest infra that can satisfy it. Having a few large stopped instances in a pool might be all the complexity you need, and while it flies in the face of cloud best practices, it's probably going to be the fastest to start up.
All of this should be possible, but the innovation is just not there.
Which ones don't support that? Anything with a Docker cache, for example, can build layers efficiently, reusing previously built layers. Build triggers let you choose when to start a job, so GH actions, for example, can trigger a full test on any PR and a light test on any commit to a branch.
I haven’t scaled that far out, but I thought that was the whole point of cloud platforms like AWS, GCP and Azure
The inside of most corporations resembles the command economies we were told to fear.
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 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.
What if you have really passive team members? So somebody need to digest the big project into smaller pieces and assign people to them, you can't just throw the project and expect it to go smoothly. If you don't it will take extra 2-3 months to start things up. I suspect in your case the team is motivated and experienced and/or there are some engineering leads in the team who can do that instead.
Then you end up with someone with less context making decisions that don't work for the implementers and causing both disengagement and silliness.
Nothing to see here folks except a government contractor wasting more of the American tax dollars.
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.
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!).
Seems like the success in this specific instance relied on trust between Richard and Baldwin that the latter wasn't leading the Crusaders into a classic Turkic trap.
Trust cuts both ways. Senior leadership needs to be trustworthy, so when the time comes to make a decision based on information you can't easily reveal to employees, they follow you.
You need to tell people to take the initiative to charge, and cut them off before they die.
That's a difficult balance to strike. But it's how you pull off a victory against an army twice your size thousands of miles from home.
Companies with monopoly positions have no such outlook on their operations.
However, the US military actually trains leaders - extensively. And it also trains people to work in coordinated units. The more well trained a unit is, the more broadly a commander can give orders and expected a good result. There's a lot of context embedded in the training and the doctrine that informs the training.
Sounds a lot like the Chevron Deference doctrine https://news.ycombinator.com/item?id=40820949
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.
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.
Always because management is some guy that's never been in the hot seat himself and doesn't know how to talk to users/customers. So he needs a pretty dashboard with green lights and KPIs he can shout about.
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.
If I need 4 people for a project, what am I going to do with $20M/year in budget? I can’t pay them 5M a year each. I would not trust myself to do something sensible with that money, no. Nor do I suddenly want to hire 100 instead of 4 people.
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.
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)
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.
I worked with kilobytes, small team, everyone sat together. No one was hoarding resources, because just to ship out the door we had to profile every single function for memory and power usage!
IMHO Hundreds of MB of RAM isn't embedded, it is just "somewhat constrained". :-D Regular tools run just fine, you can use higher level languages and garbage collectors and such, you just have to be a little bit careful about things.
When you drop under a MB, but are still expected to have a fully modern UI, then things get interesting. (I wrote up a blog post about my experiences working in embedded @ https://meanderingthoughts.hashnode.dev/cooperative-multitas...)
> 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.
Agreed, but I also think it is difficult to determine when forward progress is stymied by too many resources VS too few!
This isn't true. Every CPU you use is sitting in a physical server somewhere. Every server is sitting in a rack in a building that's sitting on land that used to be nature. It's using electricity that could be used instead for cooling or heating a person or just not generated at all. It's cooled using fresh water that is needed by every living thing and is in short supply in many places.
The idea that compute is unlimited is a horrible myth that cloud companies have sold which has effects and externalities that will be seen as on par with the myth of unlimited fossil fuels.
Granted, all true, but my point was that for any one given software team at a mid-sized company with a team of a 50 engineers or so, CPU resources are effectively unlimited. Unless they write some N^3 algorithm, the fact is that it is almost always possible to write AWS a bigger check for more CPU to a pretty much inexhaustible extent from any one given customer's persepctive.
GPUs being the very large exception here!
Hah, this brings back fun memories. I worked for a spell at a large company producing smartphone components. One of their primary products was a do-it-all embedded chip that handled many disparate functions, which eventually grew to rather massive proportions; rather than optimizing the resulting bloated software, the company just petitioned their chip supplier for a special part with way more flash memory than a standard part would have. IIRC it had something like 16x the Flash memory compared to the largest public part.
The code quality was awful. People were churning out C++ monstrosities with zero concern for code size. The final product was the result of linking together modules from dozens of teams, none of whom really cared at all about code size; I’m frankly surprised the CPU didn’t fall over from all the excess code it had to run (the RTOS was, at the very least, very good at prioritizing…). But: I’m sure it saved a lot of engineering effort that went into shipping flashy features instead.
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 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.
I would disagree.
I guess word meanings differ slightly between your and my social circles.
E.g. “optimised for read load”.
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.
“Madness! You’re crazy! I can’t be expected to work under these conditions!”
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.
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.
Otherwise, you incentivize poor performance all the time, so that I can show massive improvement on this month's "efficiency push", next months "productivity (lines of code, completed stories) push", the "bug bash", etc.
The problem was that the business changed these metrics on the phone reps all the time, so it was common for some poor bastard to really strive to get his call times down, only to be told "oh sorry we're focusing on quality scores this month" when reviewing his work with the boss. My impression was that the company was doing this to avoid having to actually pay people more, not to keep people from gaming metrics - but I think the results would be pretty similar regardless of motive.
What happened wasn't that people focused on trying to be great generalists. Instead they got demoralized by the games the company was playing, and they would either quit trying to improve at all or they would exclusively focus on one metric (so that they could get the big raise when that metric was being rewarded next).
Based on that experience, I'm somewhat doubtful that what you propose would work. But it might - unfortunately the workers at that call center were very often real fuckups all around, so the idea might work at a business which has better quality employees.
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.
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."
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.
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.
Perhaps you saw some confirmation of "ruthless meritocracy" in my post. You could not be more wrong. Most people in the organization I am describing would have been rejected as undistinguished weirdo losers from flyover towns. Our strength was that we supported each other.
I personally do not think that market discipline or financial incentives have much to do with producing excellence. At best, those systems can notice, after the fact, that something wonderful has occurred, and that it might be worth bringing to a larger group of people.
I used the terms mutual respect and esprit des corps and you use the term supported one another: I think we’re talking about the same thing.
The prevailing wisdom, then as (ostensibly) now, was to judge people by their demonstrated achievements, your assessment of their ability, and what other hackers think in that order.
Today that’s a weird loyalty test (Carmack and Luckey will tell you all about it).
I agree with what I think you’re saying: good hackers are generally highly motivated by money until the point they get to work on cool things they believe in, and pretty bored/unmoved by it beyond that point: excellence is about pride in the craftsmanship and quality of our work.
There is no "healthy laziness." This is a cynical term that does a disservice to leaders who skillfully practice with a light touch.
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.
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.
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.
Say what you will about Russia but I do love their proverbs.
> “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
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.
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.
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”.
I'm not so sure that this is actually true... It certainly seems like a certain flavor/kind of "competency", for a manager to wander into unfamiliar territory, or come across an unfamiliar topic, and to have the wherewithal to then say, "well I don't understand why we have a $10M budget, and I don't understand what will happen if we reduce it to a $6M, gee my rationality is extremely bounded... but I know enough about management in general, to know that making big changes is risky, and all my underlings keep telling me that cutting budget to $6M is a terrible idea --> therefore, despite my too-bounded rationality, I will be competent enough to realize that not changing anything is the safer path (even if I don't fully understand why, and even if I have no crystal ball to predict next year's budget process)"
Maybe you would just call that having "self-awareness of their own bounds"? And if you have self-awareness than maybe that automatically disqualifies you from being "too bounded"? But absent arbitrary semantic rules like that, the ability to make wise choices with imperfect understanding or large gaps in knowledge, is itself a demonstrable and valuable skill that some people have, others can learn, and also some that will utterly fail to ever grok.
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.
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.
- 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 ?
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.
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.
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.
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!
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.
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.
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.
I am interested in the rest of this thought… “suppose you only get a standard raise unless you speak loudly”. Then do what?
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.
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.
A century of “we just need to care about this enough” not solving the problem explained in a blog post. Well done.
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
This is the gist of the article, it has nothing to do with software architecture
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?
This is basically every management fad.
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.
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.
> 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.
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.
This sounds backwards. If someone doing "cloud migration" is around to observe, that means the internal data center people know their heads are on the chopping board, and desperately trying to preserve their jobs. You cannot expect honesty from someone fighting for survival, and it's disingenuous to assume they deserve it because they act that way.