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.
[Edit: apologies for the wall of text. A lot of pent up emotion around Creo.]
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.
I'm not sure what "empowered" means relative to the parent article.
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.
I had a similar experience thought not quite as outstanding.
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 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.
> 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.
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.
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.
The problem is finding people that have those traits, it is far from common even when you try to empower people to take decisions. It is also good to take into account the different cultures regarding this.
A way to not be extreme is to do that with x% of people (beyond their hierarchical level in the organization).
How did the consensus bit work? Like, how much consensus would you need from people before making a decision? How much time did everyone spend voting on consensus?
Trouble is most middle/upper-management is so technically incompetent, that not only can they not do technical work that their moronic decisions entail, but they can't even distinguish b/w arguments for how something is to be accomplished.
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.
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.
No reason to go that deep. Spending in large bureaucracies (public or private) often works similarly: there’s a lot of hair on fire and throwing money frantically around at the end of a reporting period, because you know if you don’t spend it you’ll get a smaller budget next time. (It was that way at all levels in late Soviet Union, it’s still that way in at least one F100 IT giant.)
Why does it happen? My CI launches separate kubernetes pod for every incoming task. If there are not enough servers, autoscaler will spin up new and remove it after some time. So there are not much expenses, we're paying for what we using. I feel that fast CI iterations are very important for developers.
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.
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.
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.
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.
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.
> 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!).
This might be a bit of an isolated example. Numerous battles against the Mongols and Turks in the middle ages start with a haphazard charge, followed by the cavalry getting out of position and completely crushed.
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.
The US Marines tend to greatly value delegation. In one instance, a Colonel boarded a helicopter to direct a rescue operation. It ended his career as it was clear he either did not have the ability to delegate or had not sufficiently prepared his troops.
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.
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.
> Whatever objective you are expected to achieve, a bigger budget makes it easier.
This should be true but I've seen bloated projects that would have had better outcomes had the team been more constrained.
And to quote Fred Brooks:
> There are many examples from other arts and crafts that lead
one to believe that discipline is good for art. Indeed, an artist's
aphorism asserts,'Form is liberating' The worst buildings are those whose budget was too great for the purposes to be served.
Bach's creative output hardly seems to have been squelched by the
necessity of producing a limited-form cantata each week. I am sure
that the Stretch computer would have had a better architecture
had it been more tightly constrained; the constraints imposed by
the System/360 Model 30's budget were in my opinion entirely
beneficial for the Model 75's architecture.
The comments on resource utilization are one of those things that is only true now that there is a 1:1 correlation between $ and available CPU/Memory, and the pool of available CPU/Memory resources is effectively unlimited.
Embedded is maybe the last refuge of where there are hard resource constraints that cannot be violated. If you only have 64K of RAM, you had better make it work!
IMHO this is why you can end up with embedded code that is easily 10x to 100x more optimized than code running in other environments. It is also, why IMHO, the user experience on Smart Phones doesn't improve linearly with the hardware improvements - see https://en.wikipedia.org/wiki/Wirth%27s_law
This train of thought, along with basically flatlined GPU performance / $, explains also why we are seeing real algorithmic improvements in the ML/AI space. If we were still operating under Moore's law and GPUs and VRAM were 2xing every couple of years, I doubt we'd see all the research efforts going into optimizing training, fine tuning, context windows, inference, and so forth.
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
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.
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.
I have worked for a company where the ethos among the workers was very high, but management was exceptionally incompetent at managing. Zero people skills, and deeply skeptical that people skills were even necessary. (Many companies founded by hackers are like this.) So the CEO and CTO asked people to do things, but did no process management at all and just waited for them to be done.
This worked a lot better than you would think. We had hired people who believed in our mission, and mostly people do want to do what's asked of them. Our codebase was pretty lean, even boring, because there was no incentive to do any promo packet type spectacular development.
Projects sometimes took a long time, but they did get done.
But this stops working when you have projects that require coordination between people with differing incentives. Teams grow tired of waiting for the other team to do their half, so mistrust begins to become endemic. In the vacuum, all your hacker ICs grow fatigued and start doing more "interesting" things just to amuse themselves, because, who's really watching them?
TLDR benign neglect, even under ideal conditions, will eventually be a problem. The company's progress becomes slower and slower, and may even start sliding backwards according to some metrics.
The author 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.
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.
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.
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.
> 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.
This article shows, in many examples, Goodheart’s law and Pournelle’s iron law of bureaucracy. You can’t make a hierarchical organization achieve outcomes people outside of the organization see as valuable through incentives because they cause side effects that will be counter-productive as soon as they move your organization out of its current state.
The article says it’s impossible to solve this problem. But I think the real problem is hierarchical organizations. They act as extractive institutions, removing value from people until those people realize what has become of them and then become parasites on the organizations.
The way out was provided by the framers of agile. I’m not talking about modern, consultant driven agile that uses the language of scrum to give organizations renewed extractive power. I’m talking the agile that provides value through close customer collaboration. That provides people inside the organization and outside the ability to influence each other. Closing the feedback loop eliminates disconnects and maps problems to solutions.
I'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 ?
> “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.
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.
> 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!
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.
[+] [-] YZF|1 year ago|reply
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.
[+] [-] LeFantome|1 year ago|reply
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.
[+] [-] joe_the_user|1 year ago|reply
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.
[+] [-] refurb|1 year ago|reply
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.
[+] [-] sroussey|1 year ago|reply
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.
[+] [-] marcinzm|1 year ago|reply
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.
[+] [-] highfrequency|1 year ago|reply
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.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] wslh|1 year ago|reply
A way to not be extreme is to do that with x% of people (beyond their hierarchical level in the organization).
[+] [-] polishdude20|1 year ago|reply
[+] [-] electrodank|1 year ago|reply
And compensated at a president’s salary for the new insurmountable levels of responsibilities right?
[+] [-] th324j234llkdf|1 year ago|reply
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.
[+] [-] yummypaint|1 year ago|reply
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.
[+] [-] mananaysiempre|1 year ago|reply
[+] [-] darkhorn|1 year ago|reply
Another one is to keep communication satalite slotes. If you loose a slot another country can claim your orbit.
[+] [-] vbezhenar|1 year ago|reply
[+] [-] apantel|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] GlenTheMachine|1 year ago|reply
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.
[+] [-] lelandbatey|1 year ago|reply
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.
[+] [-] samus|1 year ago|reply
[+] [-] iknowSFR|1 year ago|reply
[+] [-] iamleppert|1 year ago|reply
Nothing to see here folks except a government contractor wasting more of the American tax dollars.
[+] [-] jjmarr|1 year ago|reply
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.
[+] [-] chii|1 year ago|reply
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!).
[+] [-] malingo|1 year ago|reply
Sounds a lot like the Chevron Deference doctrine https://news.ycombinator.com/item?id=40820949
[+] [-] LarsDu88|1 year ago|reply
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.
[+] [-] tomohawk|1 year ago|reply
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.
[+] [-] sheepscreek|1 year ago|reply
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.
[+] [-] beachy|1 year ago|reply
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.
[+] [-] com2kid|1 year ago|reply
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.
[+] [-] advael|1 year ago|reply
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
[+] [-] jiggawatts|1 year ago|reply
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.
[+] [-] steveBK123|1 year ago|reply
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.
[+] [-] neilk|1 year ago|reply
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.
[+] [-] pictureofabear|1 year ago|reply
There is no "healthy laziness." This is a cynical term that does a disservice to leaders who skillfully practice with a light touch.
[+] [-] mvc|1 year ago|reply
Say what you will about Russia but I do love their proverbs.
[+] [-] lexicality|1 year ago|reply
> “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|1 year ago|reply
[+] [-] bjornsing|1 year ago|reply
[+] [-] yosefk|1 year ago|reply
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.
[+] [-] klooney|1 year ago|reply
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|1 year ago|reply
[+] [-] vegetablepotpie|1 year ago|reply
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.
[+] [-] agumonkey|1 year ago|reply
- 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 ?
[+] [-] aranchelk|1 year ago|reply
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|1 year ago|reply
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.
[+] [-] lexicality|1 year ago|reply
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|1 year ago|reply
[+] [-] wdh505|1 year ago|reply
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.