8 ms·
This is the managerialist dream. To replace employees' judgement and competence with a process and management methodology. That way everyone is just a replaceab
by blfr 7y ago
This is the managerialist dream. To replace employees' judgement and competence with a process and management methodology. That way everyone is just a replaceable cog in their beautiful machine.
It never works.
- bitL 7y agoOne could argue that mathematicians tried the same since Bourbaki? A set of mechanical rules in logic to describe everything...
- tacostakohashi 7y agoWhat is it about software development that keeps on attracting these "methodologies"? Why don't doctors or lawyers or commercial pilots have people coming along with a methodologies for doing their jobs? I have a few ideas, but I still feel like there's more to it than I quite understand.
- nullspace 7y agoCan't speak for lawyers or commercial pilots, but doctors absolutely have "methodologies" or processes. And processes that each individual hospital dept sets up last for years. They're usually different across depts and hospitals though.
- tonyarkles 7y agoOh man, our provincial health region recently went through a “Lean” transformation. Talking to people on the inside, it had some positive efficiencies come out of it, but it also resulted in some pretty terrible negative consequences. For example, medication shortages in rural areas, because they figured it would be better to send it to areas that needed it Just In Time. Except... some of those areas only get weekly deliveries, or worse. Similar story with diagnostic medicine. Smaller laboratories shut down because they were redundant, and then lead times for blood work etc go up because of travel time. We used to have a provincial bus/courier system in place, but the govt shut that down because it was losing money, and the health care system suffered for it. Last I heard, rush samples between major centres are currently being shipped by 3-hour taxi cab rides.
- AstralStorm 7y agoActual Lean as opposed to paper tiger version carefully verifies the effects and side effects of any change. This rarely happens in "Lean" implementations in reality. What happens is "change and see" which is not what the process is about.
- roenxi 7y agoYou get into a funny position because management philosophies, Lean included, are basically defined as "Do things that work, don't do things that don't work. Only spend money on things that add value". So basically anything that spectacularly doesn't work is usually not 'actual' [insert method here]. Management failures are rarely obscure even in foresight.
- cameldrv 7y agoCommercial Pilots have Crew Resource Management.
- phkahler 7y agoNot to mention checklists for all sorts of things.
- keithnz 7y agohaving done software for scheduling air crew onto planes, one of the biggest factors for them are the various aviation authorities rules / airport certifications etc. That shapes a lot of their lives, but airlines do have their own methods for trying to get the "best" out of their staff.
- blackflame7000 7y agoBecause that's exactly what software engineering is, coming up with "methodologies" aka algorithms to perform a task more efficiently.
- deleted 7y ago[deleted]
- stone-monkey 7y agoaren't hospitals infamous for their broken processes? It doesn't seem to me like forcing doctors to work 24 hour shifts improves their judgement while on the job, or improves overall health outcomes, anyway.
- blfr 7y agoSupposedly it does improve health outcomes because tiredness is less of a killer than patient handoffs between doctors.
- MegaButts 7y agoPilots especially are heavily trained to use checklists for just about everything. A significant chunk of training to be a pilot is just reinforcing the behavior to always use the checklist. Doctors, based on my limited understanding, are becoming more and more pragmatic about using checklists in surgeries. I am not a doctor, nor am I an expert, I have just read some interesting articles and heard from surgeons that they are trying to improve the process to reduce careless mistakes. No clue about lawyers. So processes can actually be incredibly useful, and oftentimes are designed after the fact. Agile has some neat ideas as well, but in practice I'd say 90% of the time it's pretty fucking terrible and the company would be better off without trying it entirely. Not because agile is bad, but because the people in charge of agile are usually bad. At the end of the day it comes back to something I've learned painfully time and time again throughout my career. No matter how talented you are, you are powerless against a shitty manager.
- deleted 7y ago[deleted]
- reading-at-work 7y ago> Not because agile is bad, but because the people in charge of agile are usually bad. That's the crux of it. Currently working at an org which is "Agile" and has Scrum masters, but management still insists on measuring work in man-hours and defining requirements in huge chunks then delivering them at arbitrary deadlines. So... it's waterfall with Scrum masters who make it look nice on Jira charts.
- tolien 7y ago> Pilots especially are heavily trained to use checklists for just about everything. Yeah, but it didn't appear out of nowhere. NASA et al did a tonne of research [0, 1] that led up to the idea of using checklists. Likewise Cockpit/Crew Resource Management [2] and the psychology of getting people quickly out of aircraft that are on fire [3], all of which were prompted by one disaster or another. Software engineering could use some of that rigour, but I'd anticipate a little resistance to publishing research which shows that the process of building some piece of software was a shitshow because the people running said show were bad at it. 0: https://ti.arc.nasa.gov/m/profile/adegani/Flight-Deck_Checklists.pdf https://ti.arc.nasa.gov/m/profile/adegani/Flight-Deck_Checkl... 1: https://ti.arc.nasa.gov/m/profile/adegani/Cockpit%20Checklists.pdf https://ti.arc.nasa.gov/m/profile/adegani/Cockpit%20Checklis... 2: https://web.archive.org/web/20131026210937/http://yarchive.net/air/airliners/dc10_sioux_city.html https://web.archive.org/web/20131026210937/http://yarchive.n... 3: Lots of which happened after British Airtours 28M, https://en.wikipedia.org/wiki/British_Airtours_Flight_28M https://en.wikipedia.org/wiki/British_Airtours_Flight_28M and https://assets.publishing.service.gov.uk/media/5422efe840f0b61342000277/8-1988_G-BGJL.pdf https://assets.publishing.service.gov.uk/media/5422efe840f0b...
- AmericanChopper 7y agoSoftware development is an incredibly immature professional discipline, which has lead to people mostly making it up as they go. You also have the rate at which it changes, making it hard for any sort of standard practices to keep up with. Outside of some industries that regulate security and privacy, software development has also never attracted the attention of any regulator that may have an interest in actual quality of workmanship (which would be impossible in any case). Can you imagine the architecture equivalent of shipping terrible code? “This software has bugs” is acceptable, “this brand new building is falling down” isn’t. There’s a standard way to build a house, there’s a standard way to perform heart surgery, there’s nothing close to a standard way to build software, and if you can’t properly plan your work, how can you properly manage it? That seems to be the problem these management fads are trying, and failing, to solve. People hated waterfall because you have to do so much planning up front, and in software development, that process rarely works. Project requirements change, or planning assumptions are proven wrong. So you need a management framework that works without that level of planning. That’s the core of agile in my opinion, only plan a little bit of work at a time. Really I think it just leaves you with the same problems, only now you have a lot of small failures rather than fewer large failures. If you look at the agile shops that succeed, they tend to have good leadership that simply has the competency to plan ahead well. Those teams would likely succeed under any management framework, only with agile you now also have the benefits of continuous delivery.
- pkaye 7y agoDoctors, lawyers and pilots are in highly regulated industries so not just anyone can come in with their new methodologies.
- Ididntdothis 7y agoThey are also not asked to be innovative. If the software industry decided to stick to one stack for the next few decades we would also get much better methodology and maturity. Instead we have this constant churn of new stuff where we never learn how to use our tools properly.
- deleted 7y ago[deleted]
- gtycomb 7y ago> What is it about software development that keeps on attracting these "methodologies"? Here is one data point for you from personal experience. A few months after got started at a US company operating in about 30 countries (primary business is manufacturing in the Casino and gaming industry) the word came from the CIO that I implement Six Sigma as part of the enterprise architecture activity that I headed. I countered that neither software engineers nor the IT architects and admins worked in the Six Sigma way and wondered at the meeting where this whole idea came from. I was told this was what the Chief Operating Officer and/or VP of Finance wanted to implement "across the company". Such things happen in this world we live in.
- dreamcompiler 7y agoIt's because software development is always harder than you think it's going to be, takes longer than you think it's going to take, and results in more bugs than you think it should. So the temptation to seek simplistic magic bullets that "fix" software development is overwhelming. A better idea would be to reexamine why we "think" software should be so much easier than it really is. Perhaps it's because when we watch it being done, it looks like typing.
- mmatants 7y agoLaw as an industry is pretty dysfunctional. Plenty of data governance issues, losing track of documents, etc. A lot is at stake there, for sure, but that's actually the thing that process helps with - reliability and safety. And law is very resistant to incorporating that.
- bonoboTP 7y agoLawyers feed on complexity and obscurity. If things made sense and the processes were logical and simple and easy to navigate, nobody would need their services.
- booleandilemma 7y agoNew industry + lots of money being thrown around = lots of attention and snake oil salespeople. Software development is riddled with unscientific practices that are derived from some person’s blog somewhere. 100 years from now when they’ve found out the optimal way to do development we won’t have all these methodologies.
- kakwa_ 7y agoSoftware is also a really immature field. Software development is not an industrial process, it's more like craftsmanship. Part of it comes from the fact the field is relatively young, but also because in software, it is extremely easy to modify to suit new needs and to fix introduced mistakes which results in an inherent instability of design and no strong patterns. It's getting better, but it's still present. For example, nearly each source tree I've seen has its own idiosyncrasies in term of organization and layout. Are the tests in ./test/ or ./tests/? how do I run the tests? where do you put the headers? ./inc/? ./include? what are the options available at compile time? how are they exposed? what are the install targets? does it support the usual variables (looking at you DESTDIR)? Granted more modern languages tend to be more normalized than the previous examples which are valid for C/C++ mainly. But these questions still applies. For example, the Go projects I've seen tend to vary wildly in term of compile tool chain, some have nothing, just run go build, other have a ./build.sh and the better ones have a basic Makefile which is generally not so great (no variable present to override the path to the go binary or set some compilation variables, no proper install target, very weird handling of the ./vendor/ directory in some cases).
- 6thaccount2 7y agoAlso, there are big differences in the paradigm used. Sure OO is dominant in enterprise software, but there is also functional programming and many others that have a big impact on organization.
- deleted 7y ago[deleted]
- rstuart4133 7y ago
- sagebird 7y agoAs the demand for computer automation increased, the market produced tools that less intelligent people could use, like Visual Basic vs C++. Management fads infect the dummies. How many lisp nerds do you see at an agile circle jerk meetup? Lawyers and doctors still have an intelligence test in the form of admissions criteria to universities, programmers don’t.
- thanatropism 7y ago> Lawyers and doctors still have an intelligence test in the form of admissions criteria to universities, programmers don’t. This is both incredibly rude and pretty much irrefutably true. As a startup cofounder I've had the experience to hire like 3.5 programmers to do front-end work in the past year. I'm not at a specially "hot" location for developers, but my n=3.5 anecdata is that the few intelligent programmers you can find have terrible work ethics and continually try to spend more time with what they find interesting and avoid drudgery work. The hoi polloi (who might have made damn fine designers, copywriters, etc.) rely on stack overflow for whatever they can, and dither on the slightly more challenging tasks they didn't know existed. Besides filtering on IQ, one thing a nerdy education teaches you is that challenging problems are often solvable if you will just [wo]man up and try.
- marcosdumay 7y agoDoctors are always on the news for resisting such imposed methodologies, the amount of them should be much larger than what is visible. For pilots, I literally work in a pilots methodology factory :) But if you want to see crazy methodologies, imposed by the ton, by people that have no idea what they are talking about, go look at teachers.
- blihp 7y agoThe fact that software development is not something most organizations understand how to do (well/at all) but still insist on trying to do anyway. Unfortunately, this means that a significant percentage of their projects will fail. Changing out methodologies/tech stacks/languages are great way to redirect blame when things go wrong.
- praptak 7y ago'What is it about software development that keeps on attracting these "methodologies"?' An unbelievably high level of interdependence between worker teams caused by the complexity of the product. This produces chaos, the methodologies promise to tame it.
- micmil 7y agoThey all have methodologies. The pilot's checklist that was already mentioned is just one. For doctors you have different paths of treatment that can be standardized for years, then undergo major changes when new information is discovered. With lawyers it depends on what they do. New approaches to cases, new discovery methods, everything is a process and everything can be improved. Software development attracts these things because software development isn't as firmly entrenched in tradition as doctors or lawyers are. There are way more people that are open to implementing ways of accomplishing tasks that are more open and efficient than there ever could be in most other realms.
- DanBC 7y ago> Why don't doctors [...] have people coming along with a methodologies for doing their jobs? They do. You're not involved in healthcare so you don't read healthcare specific websites. Here's some stuff aimed at the English NHS, but there is lots more. http://horizonsnhs.com/ http://horizonsnhs.com/ https://fabnhsstuff.net/ https://fabnhsstuff.net/ https://q.health.org.uk/about/ https://q.health.org.uk/about/ This tends to be the NHS learning about something and implementing it themselves, rather than hiring a management consultant. That's because they want to protect public money and there has been a lot of bad experience of management consultants for this kind of work in NHS organisations.
- dragonwriter 7y ago> What is it about software development that keeps on attracting these "methodologies"? Nothing. Management theories exist around managing every specific kind of work, as well as generic theories. Software development, HR, and other kinds of work that are done in (or contracted for by) almost every organization of non-trivial size probably get a bit more because more people are managing them. Many of the theories in software development are direct adaptations of process theories from other disciplines. Waterfall —before it was named—was just application of practices from non-software engineering, Lean is from manufacturing, kanban is a specific practice from the manufacturing organization whose processes inspired Lean, etc. “Agile” started in software but it's everywhere. > Why don't doctors or lawyers or commercial pilots have people coming along with a methodologies for doing their jobs? They do. They are even often the same methodologies seen in software: e.g., in healthcare: https://www.healthcatalyst.com/insights/healthcare-project-management-techniques-pragmatic-approach-outcomes-improvement https://www.healthcatalyst.com/insights/healthcare-project-m.... Note that the theories around software are often the theories of process improvement rather than the daily work in other domains (interestingly, this is not true or kanban), because software is just automated process so software development is essentially the exact same task as process development/improvement, where some portion of the process is executed on a computer.
- philpem 7y agoIt's not just software -- manufacturing sees a new "methodology" every other year. Sometimes two or three in one year.
- TheOtherHobbes 7y agoSoftware is derived from the production line/engine room model. It's based almost entirely on metaphors that assume the things that matter happen in a sequence, and there are ways to make the sequence faster, more efficient, more reliable, and predictable. So the same thing applies to software management. And also - in different ways - to management in general. Law is derived from the competitive sport model. The sport is verbal rather than physical, but it's really a form of mental combat with the physical violence abstracted away. So in practice it's a combination of business negotiation, corporate politics, national and international diplomacy, book research, a very specific kind of creative writing, acting, public speaking, and psychology of persuasion, with different emphases in different areas. You could have a process for basic case management, and I would be surprised if practices didn't. But the sharp and pointy end - the part where all the elements are used to create a negotiated contract or a court performance - is very difficult to formalise.
- pnw_hazor 7y agoDoctors, lawyers, and commercial pilots are licensed professionals. Doctors and lawyers are personally liable for their screw-ups. I don't know how liability works with pilots but they will lose their license if they screw up. By operating within the medical standard of care, doctors diminish malpractice liability. So having well-defined systems that help prove that you follow the medical standard of care is important. Lawyers don't have anything like that as a whole. Each lawyer handles their clients their own way. Even in the same firm different partners will have different practices. Some use checklists for their staff to confirm that the certain required forms have been filled out or provided. In the actual work of lawyering, checklists are not a thing I have seen. Though there are "outline" documents to help with bigger projects.
- blaser-waffle 7y agoMethodologies are attractive for situations that are ambiguous. Lawyers and pilots have a clear cut set of procedures. Pilots aren't inventing new technologies each time they fly, they're just driving the bus from City A to City B and worrying about occasional edge cases. Lawyers follow legal procedures and have their own built-in rules and processes; they're tested on these processes to pass the bar. You see methodologies for things that vary wildly like sales, military leadership, and of course, engineering tasks. Each project, situation, or client could be extremely different, and it's not possible to build a prescriptive how-to for each scenario. So you create a methodology and framework so that managers and leaders can quantify uncertain situations and build (and alter) their own how-to's.
- deleted 7y ago[deleted]
- lacampbell 7y agoIt seems to me that if you're an IC in a large team, you are a fairly replaceable cog. Of course a large percentage of the cogs of any machine fly off at the same time, you're in trouble. But I don't think one IC matters much in any large organisation.
- james_s_tayler 7y agoWell you could say it never works optimally, but it depends on what you are optimizing for. A lot of people think that because business need to make money that they should optimize for making the most amount of money and therefore try to maximize productivity. They look at organizations and what they see is very much at odds with that. In reality they don't try to maximize employee productivity, they try to maximize employee fungibility. If all the company is trying to do is survive then I'd say it definitely works.
- _glass 7y agoso this would confirm system theory's point of view, that exactly states that just this can be the goal of a system, where companies are just an instance of precisely that.
- sgt101 7y agoIn the short term; the twin problems - things change (more so now than in the past) and much corporate activity is necessary but unacknowledged in the org chart and balance sheet. Ripping out "inefficiencies" leaves businesses without capability. Reacquiring corporate capabilities (or acquiring them) is a long and risky road. Business schools and investors need to think about diversity of capability and expertise and ability to respond and change as measures of long (even medium term) corporate value.
- wwweston 7y agoTwo other considerations: (1) what does it mean to optimize within limits of average managerial perception? while some management knows the domain well enough they can identify issues and talent that add additional levels of productivity... many can't. Or as some say, A players hire A players, B players hire C players, etc. (2) predictable + control-able levels of productivity may well be more valuable in meeting managerial goals than exceptional levels of productivity. this is a generalization of the fungibility optimization; fungibility is one aspect of predictability and control.
- james_s_tayler 7y agoI liken it to an organism. An organism is trying to stay in homeostasis. It's also either growing or decaying, though it mostly appears static. It's exactly as you say. Many aren't capable of identifying opportunities for optimization. Re: the organism metaphor - an organism can be relatively unhealthy and still survive. Some people are ultra-fit. Most are not. Some people really are quite unhealthy. The bar for survival is fairly low. Project that on to companies you can imagine the ultra fit being those companies whose managers can work together to identify opportunities for all the things they are aiming to optimize for and are able to optimize for more than just staying alive.
- Aloha 7y agoIt works great... until you have an issue the process was never designed to handle, then everything just explodes.
- KON_Air 7y agoIf thing explode and you can't do anything about it then you are clearly in a cargo cult, not under a management that understood the underlaying philosophy; it is a glorified flow chart and you have to come up with your own practices for each step unique to your own process(es).
- sixtypoundhound 7y agoHmm... actually, process and outright automation (the apotheosis of process) work brilliantly for certain types of work. Got something boring and repeatable? Process / Automate the daylights out of it. You'll be better off. Anything that requires innovative thinking or customer focus? Requires fitting square pegs in round holes? Probably isn't going to go so well... Speaking as someone who spends more time trying to manage the former (boring + repeatable), independent humans are generally the key point of failure in any process.
- dragonwriter 7y ago> This is the managerialist dream. To replace employees' judgement and competence with a process and management methodology. That way everyone is just a replaceable cog in their beautiful machine. It's ironic in the adoption of sold-as-Agile processes, since it is precisely the idea that Agile (as in the Manifesto and associated Principles) was a firm reaction against.
- hrktb 7y agoIt's a kind of embrace/extend process: - new ideas come to an enterprise - they decide to apply it and see the "shortcomings" - apply additional processes to where they feel it doesn't match You end up with something not so far away from the original process, but slightly changed and more marketable. It can have noticeable good effects, but usually doesn't end up being any radical change or revolution.
- Ididntdothis 7y agoI think a lot of new ideas also get neutralized by modifying them in a way that the power position of the people on the top doesn’t get threatened. I have seen that now several times. Something like agile gets introduced. Management embraces it but after a while when management would need to change, the enthusiasm stops and no further changes happen. It seems that management only responds to top-down change but not bottom-up.
- sgt101 7y agothis. I got into real trouble a few years ago by speaking my mind to my MD about the latest motivational posters which portrayed our business unit as a machine made of gears and cogs. I had two objections. One, people are not cogs. Two, the gearing system on the pictures wouldn't work. I got approbation because I was not "commercial enough" and also "not onboard" but the pictures stopped being made. So... a win. The thing that strikes me is that engaged and experienced employees deal with rafts of problems silently, using their networks to create and co-ordinate responses without executive intervention. In fact executive intervention is actively avoided because there isn't enough time in the exec's diaries to communicate and debate the issues properly so inevitably such intervention will be via over simplified solutions that often make things worse. The problem with this is that execs do not see what is happening. If they did they would be impressed and pleased with what is going on, but uneasy about the risks and their irrelevance. What this then leads to are management culls where value is lost because the problems that are being solved are not acknowledged in the company before the cull. After the cull this all emerges as a huge and nasty surprise that the company now lacks the capability to deal with. The lesson : not everything (in fact not much) about a business is on the balance sheet, and in the corporate world the dead have no voices.
- 1980phipsi 7y agoapprobation?
- bitwize 7y ago> I got into real trouble a few years ago by speaking my mind to my MD about the latest motivational posters which portrayed our business unit as a machine made of gears and cogs. "A company..." "...is like an enormous clock." "...is like an enormous cl-- yes, precisely!"
- growlist 7y agoNot least because the environment is constantly evolving so as to make the One True Methodology™ redundant.
- RestlessMind 7y ago> a process and management methodology After being a manager, I'd say that is not a wrong goal. If your team's success depends on individual heroes, then it is a fragile setup. People can be absent for a lot of reasons - changing jobs, parental leaves, disabilities, ... A good manager should put in place appropriate processes such that even if someone leaves the team, the show goes on smoothly for everyone else.
- redleader9345 7y agoManager of what? Some things require skill, some things don't. Low skill trades can be transformed into paint-by-numbers processes. High skill trades cannot be so easily encoded into a process.