Concluding that we need an "anti-bullshit movement" to get rid of bullshit is missing the forest for the trees.
Bullshit is organizational self-deception. Comfortable statements intended to insulate leaders and followers from uncomfortable problems.
In other words, bullshit isn't abnormal; it's natural. A reflex to maintain the status quo while the surrounding environment decays.
And, the greater that decay, the more wool must be spun to pull over our eyes. It is said that, in North Korea, the only state organ that worked every single day during its great famine, was its propaganda department.
In my view, calling upon employers to have the courage to be genuine, to think and talk in more authentic ways... will give birth to yet another management fad. A movement shouldn't center around some vaguery, nor should it rely on each individual's moral fiber.
Instead, a better approach would be to determine what bullshit is the everyday kind versus the kind concealing systemic failures in our present and future society, e.g. "Bullshit jobs" -> Basic Income, or "Corporate Social Responsibility" -> Tax Avoidance .
Finding and solving the latter would reduce the need for, and thereby existence of, the more unbearable bullshit. Attack the disease, not just its symptoms.
As usual, the really interesting bits are in the comments. I especially find "bullshit jobs" -> Basic Income especially true. I've always thought the same thing for as long as I've had a professional career. I worked in the aerospace industry as my first programming job and saw so much bullshit flying left and right, and identified that at least 60% of my coworkers and 80% of my bosses did exactly nothing but bullshit like reporting and summarizing on things that were already reported or summarized, or creating useless documentation that had to be created because of some arbitrary standards. We were very top-heavy and at one point I saw a hilarious org chart where there were more managers than engineers. Then one day I thought to myself that this whole project was basically equivalent to wealth redistribution and was not at all the meritocracy I had envisioned it to be. Now, 20ish years later, I'm pretty damn jaded and the bullshit has only increased, but now it's just more cleverly disguised in management methodologies like "SCRUM" and "Agile", with all of that deeply-imbedded culture and terminology baked into our everyday tools like the Atlassian toolset (Jira, Kahnban boards, etc.). Bullshit is here to stay, but in a sense it saves us from our own incompetence.
> Then one day I thought to myself that this whole project was basically equivalent to wealth redistribution and was not at all the meritocracy I had envisioned it to be.
This is precisely why I have loathed the cult of "pay per performance". Bonuses, salary bumps and promotions become a sort of (I wish this were an exaggeration of terms but it isn't) conspiracy to pass wealth and prestige to buddies. But they fill it with phony paperwork and propaganda about how the buddies have been objectively evaluated and are all top performers. If you are an honest worker doing good things but not in a management in-crowd, this can have crippling effects on morale.
I've seen agile work and not work. It doesn't transmit well from a book or blog post.
I think it's fairer to say that excitement generated by a new concept attracts dilution by bullshit artists and folks learning via the telephone game. By the time the hubbub dies down, the original sparks of insight have long since drowned in a sea of mediocrity, ranging from the shallows of well-meaning ignorance through to the dangerous deeps of machiavellianism.
I worked for a fortune 500 company that had been developing their own in house software for 30 years. They decided that they wanted to switch from their traditional waterfall approach, to scrum and agile.
Honestly, the transition went pretty well. Meetings decreased, test coverage went up, feature delivery rate seemed to increase. People were spending more time working on the problem at hand, and less time creating and managing huge requirement documents. There were rough spots. Obviously requirements didn't go away, we just went to a just-in-time model instead of a heavily front loaded model, and sometimes it was difficult to manage just-in-time requirements in a way that gave everyone clear oversight as to what was being implemented (our business rules were extremely complex for regulatory).
One interesting thing I noticed was that every time there was a problem, people would try to add more layers of bureaucracy to "solve" the problem. The hardest part we found was figuring out which ceremonies were useful to stop future problems and which "solutions" were just a reflexive attempt to go back to the way things were before and make things more difficult for everyone.
I see Scrum/etc as a program for people. It implies certain values, and defines new words, but in that sense it's like any program (in the machine sense). You may not like it, but it's hardly bullshit in the sense of the article.
I have known companies that were entirely run on the stuff. C-levels and wannabe C-levels would spew it in every direction. It was simply a signaling mechanism that you were a company player. It was so patent that it could serve no other purpose. If one rotated it the correct way, it was not unlike a Monty Python sketch.
At some point I had a list of banned words, because they had lost all meaning, turning only into rest stop on a Markov chain road-trip. It simply wasn't possible to think with them, the Sapir-Whorf-Frankfurt Hypothesis.
> In my view, calling upon employers to have the courage to be genuine, to think and talk in more authentic ways... will give birth to yet another management fad.
The best thing about the Netflix culture deck linked in that article is how much "bullshit" it contains. The part about "adequate performance gets a generous severance" is especially amusing, since most measures of performance are also bullshit. It's also "we only work with the best" re-worded.
>Concluding that we need an "anti-bullshit movement" to get rid of bullshit is missing the forest for the trees.
Bullshit is organizational self-deception. Comfortable statements intended to insulate leaders and followers from uncomfortable problems. In other words, bullshit isn't abnormal; it's natural. A reflex to maintain the status quo while the surrounding environment decays.
Sure, but that's assuming we need those organizations, and we need them to continue to operate as they do.
And if not that, it at least assumes that some companies don't overdo this thing.
Do you have a reference re: north Korea comment. I am so interested in what actually went down but so little official information has reached the picking through refugees.
It comes from a passage in "The Cleanest Race" by B.R. Myers[1], which I recommend as a lens into the internal effects of North Korea's propaganda
>"One colleague told me he finds the North Korean personality cult too absurd to take seriously; indeed, he doubts whether even the leadership believes it. But no regime would go to such enormous expense, year in, year out for sixty years, to inculcate into its citizens a worldview to which it did not itself subscribe. (The only institution in the country that did not miss a beat during the famine of the mid-1990s was the propaganda apparatus.”
There was another book on North Korea which corroborated this statement with actual numbers; I'm having trouble pulling it up at the moment.
That's more a statement of just how backwards North Korea is in an increasingly prosperous world in which the median standard of living is at an all-time high and continues to rise by the year, famines are between extremely rare and non-existent, and global poverty is at an all-time low. It looks increasingly like North Korea may be among the very last of the failed state hold-outs. Even Cuba looks like it's set to change considerably for the better in the coming years.
> "But no regime would go to such enormous expense, year in, year out for sixty years, to inculcate into its citizens a worldview to which it did not itself subscribe."
That seems like an odd and unsubstantiated assertion.
I see a pattern, based on this article and in my daily life. A lot of these processes and ridiculous terminologies are usually created by managers who have no real hard skill. Instead of doing any real work this is what they come up with in order to validate themselves. What does the delegator do when the work has all been delegated? Nothing absolutely nothing and that’s where all these ideas, terminologies mentioned in this article come from.
IMO the best managers are the people who have hard skills and leadership skills as a combination. They are able to solve their own problems and help other people solve their problems, and are able to ensure everyone on their team comes out with a net positive on happiness.
The stereotypical manager is often classified as the failed engineer. I’ve certainly seen it happen where managers are the smooth talking bullshitters who can’t cross the street without help while the more introverted types continue to do all the heavy lifting.
> What does the delegator do when the work has all been delegated? Nothing absolutely nothing and that’s where all these ideas, terminologies mentioned in this article come from.
Delegating work is still work which needs to be done. In a large organization, figuring out which work to delegate to who is a full-time job. Just creating the (ever-changing) structure of the company - what positions you have, what responsibilities they take, etc - is also a pretty hefty effort, done by managers.
It's difficult for me to not parallel your "no hard skill" complaint with how farmers in my country complain that programmers "don't create any physical product" but get paid more. Organizing even small numbers of people(10-20) calls for someone with quality soft skills, otherwise the efficiency of everyone drops significantly.
I think you misunderstand my point about 'hard skill'. When I say 'hard skill' I mean any kind of skill contributing to the product (by product I mean the actual product and working with the customer). Whether it's physical goods or providing some kind of service.
As for the point about farmers complaining programmers don't create 'physical' product that's a whole different discussion. That complaint is coming from someone who due to whatever constraint hasn't taken the time to understand, the nature of the software business.
I don’t necessarily believe that managers need hard skills relevant to the business (and I say this as an engineer).
However, they need to be crystal clear on what they manage (wether it’s just a team, department or entire company) is supposed to deliver and how it will be evaluated. If they don’t know this they can’t prioritize and they can’t ask the relevant questions to the experts to help them with that.
This brings me to the second thing Managers really need; they need to be able to listen. The manager is there to manage, he or she is not there to build stuff and thus he or she has to acknowledge that they don’t know as mych about the problems facing the project as the experts. A manager needs the experts’ opinions to guide them towards the best decision.
Plenty of managers can talk (that’s one of the readons they were noticed by their superiors) but few can listen and are thus oblivious to what should be prioritized above what (I work mainly on the backend, I had to basically force the issue of load testing before launch into meeting after meeting but my manager was very interested in the colors of the GUI) and which problems will take a lot of work and which could be fixed in 15 minutes.
If you want a manager with hard skills as good as yours, wouldn’t you rather have them as a member of the team instead?
I agree when you say 'They need to listen' but the ability to listen requires a lot of time and experience working in the trenches. How can someone sympathize with the people they are managing if they've never put themselves in other people's shoes on a day to day basis. How are they ever going to offer solutions to problems that crop up when they have minimal or no domain knowledge?
Most managers I talk to are all about the 'power' over people. When I meet them a a social gathering and ask them what they do the replies are usually along the lines of "I manage 5 people on a daily basis" or "I have 10 people under me". It just shows the mindset of these so called, manager so clearly.
Management is something of an art, don't get me wrong. It is a very important skill, what I'm saying is to be a good manager you need to have the 'hard skill' it's a prerequisite to being a good manager.
There's a Peter Drucker quote, I believe, that I can't manage to find, but goes something along these lines (totally paraphrasing):
Businessmen tend to use fancy jargon for mundane things, which gives more exciting and important trappings to what is, in reality, a tremendously dull job. We should let them have it -- somewhat obfuscated language is a small price to pay to let them feel a little bit better about the boring tasks they accomplish day in and day out.
I found this article to be of little utility. Some random history about corporate management, crapping on an entire layer of the organization, because they are called "management" (there are good managers and they serve a purpose) and in the end not suggesting a single thing to help improve the clarity of one's own language.
Agreed, nothing really of substance here, which is impressive, given that there's plenty to say on the topic... and it's a much wider topic than management.
I often see complaints about Agile and SCRUM met with, "You're just not using it correctly." In some circles, it's almost like a religion that you're not allowed to criticize. After all, it's The Process(TM), I guess.
But from where I'm sitting, "correct" SCRUM looks like a whole lot of weird not-overhead-but-totally-overhead that seems difficult to manage across multiple projects. For example, what a "point" represents is constantly in flux.
Instead, I actually prefer subsets of the methodology. When the company I work for was young, we all worked from home, and so daily standups were extremely effective at keeping us on task and productive while maintaining good balance (once you're done, you're done -- no creep). The board has been effective as organizing tasks and their progress.
What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments.
Basically, I prefer a more focused and leaner version of the approaches.
> I often see complaints about Agile and SCRUM met with, "You're just not using it correctly."
To be fair, this is true a lot. Agile has quickly become "whatever you were doing before Agile but now with stand-ups and kanban boards."
The real problem with Agile is that it's kinda stupid to assume that companies will radically change their development process and that they won't just do "whatever we were doing before but with a couple bits and pieces from this other thing."
It's way easier to keep doing whatever you were doing before and just say that it's "Agile." See, for example, the number of teams that have long-winded standups even though that's pretty explicitly discouraged.
> What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments.
Totally my take on the whole point system, but:
They're definitely related (hours and points), but basically the whole idea is vagueness. Figuring out if something will take 3 hours or 5 hours is kinda meaningless, because you really have no idea until you get into it. Saying it's worth "5 story points" might suffice as a rough representation of that 3-7 hour chunk.
If it ends up taking 20 hours, oh well - good to know for next time!
The idea is not to bicker over whether something will take 3 hours or 5 hours or 7 hours, but to just slap a vague label on it as "low-to-moderate difficulty." It's supposed to save time in that regard.
> Basically, I prefer a more focused and leaner version of the approaches.
I think any reasonable Agile advocate would tell you to discover what's working for your team and what isn't, and to adjust accordingly.
The point is mostly to move away from that extremely long-winded waterfall process and move towards rapid iteration. Story points and stand-ups are just tools for accomplishing that (by estimating velocity and having regular check-ins).
Agile requires flexible features since the deadlines are fixed. The point system is there to give an idea of how much you can cram before the deadline and negotiate with the client about what to axe from the release
Easy bullshit scrum test: go to a manager and ask what feature will be in the release and what will be axed.
If nothing is going to be cut from the requirement docs, all the castle about poibts priority and speed just falls down (or you have a ridicolously lax deadline, of the likes I’ve never seen in practice)
> The point system is there to give an idea of how much you can cram before the deadline and negotiate with the client about what to axe from the release
Well, it's more than that though - otherwise you'd just assign each developer 80 "points" worth of work for each two-week sprint.
> If nothing is going to be cut from the requirement docs, all the castle about poibts priority and speed just falls down (or you have a ridicolously lax deadline, of the likes I’ve never seen in practice)
Adding stories to an iteration in progress is also (I'm pretty certain) explicitly discouraged.
If your manager is doing that, you've already kinda lost the Agile battle.
I think that's sorta what people mean when they say people are doing Agile wrong - they do these things that are explicitly discouraged.
Whether there's any way to reconcile that, I can't say.
> I think that's sorta what people mean when they say people are doing Agile wrong - they do these things that are explicitly discouraged.
Usually how it goes. It's like critics of communism. Or libertarianism. Maybe--just maybe--it's a shit ideology that is totally unworkable.
I think my current place is on their, what, 8th "reset" now? Where they try to correct their process because it's "not working." Despite not listening at all to the developers who are telling them week after week exactly what is wrong: management forcing unreasonable deadlines on developers and throwing all process out the window.
It would be more amusing if I wasn't one of those caught in this demented whirlwind.
I think I'll start a new fad. Instead of Waterfall, I'll propose we call it: Typhoon Development. It's where management focuses all their attention on a single project for a short period of time, stressing the developers to the breaking point and eventually moving on. But not before completely destroying the code base in their wake.
> Maybe--just maybe--it's a shit ideology that is totally unworkable.
Could be. Much like communism, it's something that seems to work remarkably well for small groups of people but seems to have problems with large, entrenched groups.
There are enough agile success stories though that I don't think the ideology is completely silly.
> I think my current place is on their, what, 8th "reset" now? Where they try to correct their process because it's "not working."
It's highly unlikely that any methodology would have any effect on your current place, regardless of how brilliant or revolutionary it is.
I think it's tempting to dismiss Agile as stupid or unworkable because it's failed to produce any results at organizations like this (and often just made things worse).
The truth is really that your organization is highly dysfunctional and the problem is management. There's no development methodology that will fix that, and indeed it won't get better until those people see the light of day (unlikely) or leave/are replaced.
For more functional organizations, or even organizations where management is willing to admit they might be wrong, Agile can be a nice set of guiding principles for development work that makes life easier.
> There are enough agile success stories though that I don't think the ideology is completely silly.
Any lonk to read one account of such written by devs themselves, as opposed to the vast majority that are written by consultants selling agile packages?
I have used scrum in two completely different companies and it was working really well in both.
In both cases management was on board with scrum and knew what that meant. Everything was estimated by devs, not managers. If there was an external deadline, scope was adjusted to meet it.
> Saying it's worth "5 story points" might suffice as a rough representation of that 3-7 hour chunk.
> If it ends up taking 20 hours, oh well - good to know for next time!
The idea behind points in this situation is to start equating that 5 points = 20 hours (for this type of problem, for this team). If you think of it in terms of "this story is about the same complexity as this other one". Whether you call that 5 or 15 or 50 points is largely irrelevant, so long as all 5 point stories are roughly equivalent and a 10 point story is about double the work of that.
The rest of the uncertainty around complexity and people is supposed to wash out in the averages of the team: for example the fact that one person may typically do 12 points a week while another does 30 does not really matter for figuring out the overall velocity (team points per week), assuming the team does dozens of points per week total.
Now that said, I've never successfully used points. Sometimes it was due to endless discussions trying to equate hours to points (mostly from management and others outside the dev team), poor estimates, radically different estimates or skill levels, and probably several other reasons I'm unaware of.
Now my team does t-shirt sizes for long term things, and hours for the stuff in sprint (basically as it's started), but it's still often way off.
Does anyone have successful (long term) experience using points? What did you do to make it work? Does it actually have material advantages over other methods?
Yes, we have been using them successfully for quite a while. We only use it to estimate roughly what fits into a sprint.
No comparisons to time or between team members are made. I think that's really important. Management is on board with that. If it wasn't, it probably wouldn't work.
> Now that said, I've never successfully used points. Sometimes it was due to endless discussions trying to equate hours to points (mostly from management and others outside the dev team), poor estimates, radically different estimates or skill levels, and probably several other reasons I'm unaware of.
After two years of managing the same team of developers and gathering metrics, my PM[0] and I were able to successfully forecast tasks to within a few hours of precision for the team's 2 week feature work sprints.
The key to doing this was having a behind the scenes multiplier that was applied to each developer's capacity. Visual Studio Team System (or whatever it is called today) actually supports doing this. Work was still entered in "hours".
I forget how we even did it so that the devs didn't see the multipliers, but it all worked out some how.
Another key is never have a task that is more than 8 hours. Break it down further, and further, and further. However at some point there is a trade off between spending time breaking tasks down and actually doing tasks. Learning how to break tasks down is a skill that only comes with a lot of forced practice. No one likes doing it, no one likes learning how to do it, and for a new team I'd say it might not even be possible. Some familiarity with the code base and problem space are needed before 2-4hr tasks can be generated for 100% of all work that needs to be done.
We used t-shirt sizing only for initial planning of what work was going to be done. In our case we had 2 types of requirements, internal engineering work (code quality, refactoring, adding new libraries, etc), and feature requests coming from, mostly, external. We'd first triage based on t-shirt sizing, saying we had enough capacity in a sprint to do, for example 2 large, 2 medium, and 4 small sized items.
A senior dev (expensive!), myself, PM, and UX lead, would all sit down in a room and use the planning method taught in BJ Fogg's boot camp (https://www.bjfogg.com/bootcamp.html), which sounds new agey and stuff but it 101% works and ends with everyone in the room agreeing on exactly what should be done[1]. Once the t-shirt sized features were decided on, developers would spend a couple hours (or more...) breaking those features down into ~4hr tasks. At this point we'd discard any work that was over in hours, based on priority. Basically a second pass filter. (If devs guesstimated one of the other t-shirt items would actually fit, a quick breakdown would occasionally be done to see if we could squeeze it into the sprint).
The overhead here was really high. The first part was ~3 hours of prep + meeting for senior leadership: myself, UX lead, PM lead, and stakeholders in the feature work that sprint. The second half was basically the better part of a day for the entire dev team[2]. The super cool advantage of this was that at our peak, all the work was super parallelizable. Dependencies between tasks were mapped out, and anyone could go onto the task board and grab work that they knew would fit in just in time to the work their team members were doing. I cannot express enough, having everything broken down into less than a day provides amazing benefits, and also clarity of though.
We were kind of in a Goldilocks scenario though. Clean code base, all written by the developers there, multiple years experience in the same code base, and a PM team who lets us take a month+ to refactor when things got out of hand. Even then, it took us ~2 years before we were able to reliably hit our burn down every single sprint.
But wow it felt good when the machine finally became perfectly oiled and we were able to ship out embedded firmware every 6 weeks (3 week sprints, 2 weeks feature work, 1 week code quality[3], every other version went out) without stress or crazy[4] hours.
[0] A good PM is a force multiplier, a bad PM is a force divider.
[1] It is the best planning technique by far. Once we switched over to his style of planning sessions, everyone walked out of the room genuinely happy with what we were going to do that sprint!
[2] Once we did a session over fresh made to order Piña coladas, made in coconut shells. I think my PM almost cried from the lack of productivity that day.
[3] Bug fixing and code base improvements. This went up and down accordingly to stay under our bug bar. And after a dev came off of a feature push, they would be told to just work on whatever bugs they felt like for a sprint so as to avoid burn out.
[4] Not counting a couple devs who would refuse to go home, even after I cut their excess feature work and literally came in on weekends to drag them out of their chairs. There was 0 penalty for ICs in not shipping! Design didn't always help, they had cool new visual effects that some of the devs really wanted to see. Doing fancy visuals on an embedded processor with kilobytes of RAM is one of the coolest feelings ever.
> If it ends up taking 20 hours, oh well - good to know for
> next time!
If a project is adding real productive value to the business there won't be a next time as the tasks should be intrinsically unique. A non-unique task suggests either poor product strategy, poor architecture, or that there's a pre-existing package or product that you should be using instead of recreating the wheel. At best, unavoidable repetition signals deficiencies in the state-of-the-art (e.g. overall Linux or Windows ecosystem), but those are rarely the sorts of tasks where you see trouble communicating or planning.
> The idea is not to bicker over whether something will take
> 3 hours or 5 hours or 7 hours, but to just slap a vague
> label on it as "low-to-moderate difficulty." It's supposed
> to save time in that regard.
The purpose of scoring is to enhance the precision of time management. Theoretically, you should be bickering over details! The point is to reliably track so-called velocity with increasing precision to assist executives with product planning and orchestration of resources. But as I mentioned above, if you're doing anything of real value you're constantly creating unique solutions to unique problems. Those solutions and problems should constitute the bulk of your effort. As you suggest, your scoring necessarily must be uncertain and imprecise to be accurate and reliable, at least when you're attacking worthwhile problems. But that's completely at odds with the function and aim of scoring in Agile, which is to achieve increasing precision.
Agile methodologies come from the world of industrial automation where you're trying to refine the process of building millions of identical widgets with designs that evolve relatively slowly. Increased precision in resource management (e.g. real-time inventory management) allows managers to squeeze more profit out of the product without any additional expenditures. It's one of the rare management tools where they can uniquely add measurable value. But repetition and slow evolution is pretty much the complete opposite of what you should see from an efficient and capable programming team. At best, something like SCRUM routinizes poor value-add. Agile isn't a recipe for success, it's a recipe for making failure more efficient. (Not the experimental, knowledge-building definition of failure.)
In the context of software, Agile tries to achieve the impossible, which is to mechanize innovation. It's fundamentally broken. If you cherry pick aspects of SCRUM (or any particular Agile methodology) it's no longer SCRUM, nor is it novel. At best the Agile fad has introduced more programmers to, e.g., unit testing. But Agile is neither necessary nor sufficient to adopt unit testing; nor is unit testing always the most efficient use of time, especially when formal verification is practical. And while fast iteration is ultimately what you want to achieve, again the point of fast iteration is remove as much repetition and wasted effort (e.g. orchestration latency) as possible. If you're iterating fast, you're spending less time on tasks that are easily articulable, let alone predictable, and thus not amenable to fine-grained, precise time management. This is a consequence of the very purpose of software programming--to shift tasks that exhibit regularity to the domain of computers.
As for me, I left my previous job the moment people started complaining that our velocity was "too fast"; that (I kid you not) we should slow down the pace of work on a big, high-priority project in a futile and misguided attempt to make our time management more predictable (like the more junior teams), oblivious to the tensions between accuracy and precision and to the fact that the inaccuracy of our overly precise scoring was actually evidence (especially in light of other evidence) that we were working particularly efficiently.
As far as I understand, my prediction about when the project would wrap up if my preferred strategy (for which I was effectively the deciding vote) wasn't followed was accurate nearly down to the week, for a project that was supposed to take 3-4 months but ended up taking 9 and which was supposedly the highest priority for the entire (NYSE-listed) company. It easily could have taken 3-4 months if some of the engineers didn't approach time management through the lens of Agile development. They would have been more tolerant of the predictive errors for the easy tasks and more suspicious of the estimates for the more complex tasks, many of which were backloaded in this particular context. The lens of SCRUM in particular and Agile more generally primed them to equivocate tasks; to see similarity and repetition where there wasn't any.
10 minutes a day, an hour every other week for retro, a half hour every other week for showing the work to the stakeholders and whatever time it takes for the team to understand and clarify the work? (Grooming)
I mean, I don't love SCRUM, but I don't understand everyone talking about how much overhead it is.
That said, learning the process can take time - early grooming sessions can be terrible. However, on an experienced (in SCRUM) team in a functional organization, it doesn't take much time at all.
An hour a day for standup, five hours a week for retro. Grooming sessions never made a dent in the backlog. 30 person team, VP in the room during some standups.
Obviously that monster was not what anyone intended by agile, yet the trappings of scrum slot neatly into what the organization actually wanted. Interchangeable workers, a progress chart to show the SVP, enough hipness to sound like the management isn't to blame.
An hour long meeting is not a standup. The whole reason it is called a standup is that it is short enough that no one gets uncomfortable standing through the whole meeting.
Except it's not 10 minutes a day. It's like a half-hour a day because, "Oh, it's 10 minutes to scrum. I can't finish this task in 10 minutes. I'm going to go get a drink of water and talk to John by the water cooler until scrum." + the one person at scrum who explains everything they're doing in detail because they never learned to summarize so it takes longer than 10 minutes + 10 minutes afterwards because, oh look, it's almost lunch time and I can't finish anything up in 10 minutes.
> an hour every other week for retro
Plus the after-talk that people do with each other about things like, "I don't think they really understood my point about our dev tools being a problem," or whatever things didn't or couldn't be said in the actual retro.
> a half hour every other week for showing the work to the stakeholders
Except that the stakeholders never show up on time so you end up waiting around for them, and they want to ask inane questions for the next few hours...
Everyone has a different definition of "agile." Its always going to be different and one of the key points of _agile_ is that you bend it to fit your own needs.
That said, there are certainly pitfalls to taking some aspects of one methodology without understanding why those methods are the way they are and perhaps whether they rely on some other aspect of the methodology that is skimmed over.
For example, story points. The reason they're made up is because people fixate on man-hours being a literal hour worth of work no matter the man. Instead you use a fuzzy point system that at first is impossible to use as a prediction but is supposed to become more accurate over time. Everyone estimates points differently? Fine. that's why its points and not hours. You make burn down charts and measure your velocity in points as well so as long as the point estimation doesn't fluctuate wildly you can start to get something. Plus, it doesn't even matter if you can predict things. Points are are also just an abstract concept to get people talking about task difficulty in general. "300 points?! Why do you say that? What don't I understand about this task." The main goal is to get relative values, not absolute hours.
That said, a lot of these methods are taken as religion and used as a cudgel every two weeks.
The basic idea behind points is not bad, the problem with it is humans and the fact that they are numeric/ called "points". Might as well call them "gold coins", since soon enough people all around will start to believe there's genuine value in having/collecting many "points".
I like to believe that it'd be much more productive if the tasks were T-shirt size. Since that would prevent people from computing "productivity" or "velocity" or whatever - while still allowing you to do rough estimates, if you recorded this for long-enough.
(actually, I think you need some sort of tshirt size for several dimensions - like, "dependencies/ how many people you need to communicate with for this feature"; or "uncertainty - how much is this 'just work'(implementing a known solution) versus 'exploration'/ trying to identify the solution first ")
"You're just not using it correctly" is absolutely correct, by definition, in all cases where "Agile" is imposed as some kind of top-down corporate policy.
A mentor once taught me that all actions taken by a company's people should be focused on making money, saving money, and saving time. This is mostly a sniff test for "does this thing we're doing make sense in some obvious way." When sniffing the value of any given team's Agile process, I usually find a notable lack of attempting to make money, save money, or save time. Often I found people are very good at spending money, wasting time, and being completely detached from how they actions contribute to making money in a meaningful way.
This sounds common-sensical, but of course in practice it's almost impossibly hard to tell if any reasonable course of action really will make money, save money, or save time.
Will refactoring help? How about a continuous integration system? A better bug tracker?
In fact will fixing bugs make/save money/time at all? Customers seem to put up with them, and it's always easier/cheaper not to bother.
Will customers leave if our product is shit? Often they won't. Sometimes they will, because a competitor's product eats our lunch.
So what's the best course of action?
One problem with Agile - and all management fads - is exactly this lack of prescience. Future outcomes are unknowable. They can sometimes be estimated, but given a huge field of possible actions, making optimal choices is incredibly hard, and there's always a trade-off between long-term and short-term rewards.
The bigger problem is that corporations and businesses are very rarely primarily dedicated to making money. Internally, the true function of business processes is to highlight and maintain a political hierarchy which supports resource concentration for senior management and shareholders. Senior management and shareholders may know what's best for themselves, and that may well not be what's best for the long-term survival of the company - not even in terms of an apparently simple metric like "Does this make money?"
Because you can't answer that question without also asking "For whom?" And it's not that unusual for senior management to choose actions that protect their status over actions that increase income.
Consider that agile is an absolutely minimalistic team process structure compared to what came before it. Maybe there are better methods now. But you have to have SOME kind of system in place, the baseline isnt $0 + no planning needed.
So, when you say that it spends money, wastes time and so on, what process structure do you compare it to?
Agile doesn't directly help you make money, save money, or save time. I think of it as a way to reveal what people are working on, including myself. If I'm working in the corner on who knows what, and as a leader you wanna know WHAT I'm working on, Agile can help with that. Agile may get me to communicate that I'm working on something awesome or something horrific, and what you do with that information is up to you.
If it's more efficient than some alternative, then it IS saving me money and time. Having NOTHING in place is clearly not an alternative. We must always have something. Therefore, whether it's saving money or time is relative as to the alternatives, or relative to whatever processes we had before the introduction of agile.
What did you have in mind that you consider to be more efficient than agile?
(Btw, I noticed you snuck the word "directly" in there, as in "agile doesn't directly help you make money…". This makes the rule of thumb nearly useless as the only people who directly make money is sales. Very nearly everything else that goes on in an organisation is in indirect support of them, one way or another.)
A lot of people don't do it correctly. They identify 2 things that the company already does and then declare they are completely agile, having changed nothing about the way they do anything.
Read up on “cargo cults” and “cargo cult agile” and it makes a lot more sense.
There are some genuinely good ideas in SCRUM and other development methodologies. But trying to codify those ideas into a set of rules for newcomers always leads to some degree of misinterpretation.
I don’t know what the solution is, other than to ensure each team has constant input and support from somebody with authority and deep understanding of software development practices...and how often do you find people like that!
I feel the same way about "Representative Democracy". Sounds like a great idea, and if it worked as advertised, it'd be great way to run a country. Unfortunately, its far easier to say "We have a representative democracy" than to actually implement one, and its in the interest of everybody "in the system" to just take bribes and do whatever the fuck they like. Scrum (its not an acronym) is the same. If you can get a bunch of people together who know what the fuck they are doing and want to write software that works for the customer, then its a great process. But 90% of "Scrum" I've seen is wankword bingo.
While this is a valid point, I've found the biggest issue with "Agile" to be that business thinks that this is the primary (or only) input that needs to be heard from the tech side. They think that because they're tossing us the "Agile" carrot they have carte blanche elsewhere and it is a "get out of jail free" card for their absolutely terrible decisions...like demanding the use of a CMS like AEM when building a dynamic RIA because they may feel the need to change the text of a button down the road.
By being "Agile" the team can make up for the ignorant and time wasting technical decisions foisted upon by business.
it's not the terms "agile" and "SCRUM" that are bs, it's the application of them. agile just doesn't work in most top-down organizations, where bs tends to be highest, because at it's core, agile is about providing a thin layer of self-accountability to self-organizing teams that are fairly autonomous. most (bad) managers want to believe they know better than the underlings and won't give up that much control.
I kid because I love, but I will say it depends on where you're attempting to do it, how much control you have over the process, whether you are a contractor or government employee, and how much your can convince your leadership of the good parts (these typically require actual risk-taking / change)
Great article, until the very end when it sounds like he wants to come up with with some anti-bullshit bullshit.
However I really did enjoy the read especially learning about the history of bullshit and how we got here.
I think the fundamental problem he mentioned has to be solved - "As factories producing goods in the west have been dismantled, and their work outsourced or replaced with automation, large parts of western economies have been left with little to do"
This is the key issue. There just isn't enough actual productive work to get done in many jobs and people can't just leave when the work is done due to being payed by the hour or being seen as lazy by their coworkers and bosses.
I'm not smart enough to give solutions to big general issues like this but I certainly see it as a problem in my own life. I have no idea what people actually do in most jobs these days and therefor when trying to decide on my next career move, I have trouble estimating how competent I would be when considering a job. Also it seems hard to develop any real skills in most jobs these days other than learning how to fit in and bullshit.
However, those skills do not transfer to a new position with a different 'culture'.
I've mostly worked blue collar labor type jobs in my time and had a clear task to complete but you end up getting pushed around by management types and are at great risk of personal injury for very little compensation. In my last job at a warehouse I worked my way up from a temp labor grunt to getting pretty close to management but I couldn't handle it. The higher up I got the less there was to do other than bullshit consumption and production, by the end I wanted to just go back to working with the guys on the floor (but again you aren't making enough and risking injury every day). I hope to find a job that I can actually do things and gain clear skills over time, but if I can't figure that out I'll have to become another sellout bullshitter since I'm not getting any younger and my body isn't gonna be able to handle the hard labor in the long run.
This reads like an Adam Curtis piece: starts with an obscure historical reference, and builds it up to dramatic ripple efect on the world, usually by way of a cultural shift.
Many are mentioned in the article. One I particularly loathe is 'reaching out'. In my generation, 'reaching out' is what someone with a serious drug or alcohol dependency did when they hit rock bottom and it was either get help or die. I cringe, I cringe....
A few years ago, it was 'at the end of the day', which my boss said 42 times in one 60 minute meeting. Yes, 42. I counted.
I eschew 'reaching out'. It can be replaced by more honest and/or accurate terms. The big problem is that it is part of the problem - people that use this phrase tend to use other occluding language. And people that speak or write that way - as per TFA - tend to do it a lot.
Btw, 'intending to help' I don't think is implied. Naturally you may 'reach out' to provide or offer assistance, but in a business context there should be a business driver for doing the actual contact thing, and then you can choose to specify the context or not.
I haven't heard "reaching out" all that often, but the one that makes me cringe is "moving/going/looking forward." I once heard my boss use it 3 times in one sentence (it was something like "going forward, we'll ... and going forward, ... to set expectations going forward.") The surreal experience was further enhanced by the fact that none of the 6 others in the same meeting even seemed to notice or find it unusual.
Aside from overuse in that example you gave, what's the issue you have with "going forward"?
I use language along these lines, often after talking about an issue, as a way of steering the conversation onto solutions. In my experience, it can be a useful phrase.
Those are specific forms of reaching out. Contact is different but not any more efficient IMO, so I guess we will have to agree to disagree. If I had to direct someone to look into it, I might say --
'Please find out if Bob's surf shop carries Mr. Zog's Sex Wax.'
A few of the terms in the header image on the article seem perfectly appropriate to me depending on context, but I'm probably thinking of them being used literally (reaching out as in contacting, incentivising as in more money paid, deep dive as in RCA) and have insufficient exposure to the BS versions to comment - so, I'll stop!
The reason reach out is used is to give the individual being asked some autonomy / responsibility in the action.
Eg if you ask someone to call bobs surf shop and they don’t answer they might stop there or call back later. If you ask them to reach out they might go down there and see them, set up a meeting, speak to a friend that works there, etc.
Both Wiktionary and dictionary.com list definitions of "contact" as a verb. I don't have access to the OED at the moment, but I assume they would have it listed as a valid verb as well.
there are manager bullshit and verbal tics like the one you mentioned.
I tend(ed) to use "long story short..." to force myself to summarize, but when a colleague of mine started to use it over 3 times in a single sentence, I've since stopped using it.
We have too many to count, but some of my favorites:
-Kabuki Dance
-Coal Face
-KT (Knowledge Transfer)
-Across the Piece
-And my personal Rockstar: Like Putting Socks on an Octopus
Our HR group actually put together a wonderful "Leadership" website complete with a "Leadership Handbook" (Buzzword Dictionary). Of course, it's hidden on an obscure sub-site and is unsearchable. I've never met anyone else who's actually seen this site or handbook, but it's been fun for me!
Ah yes, the knowledge transfer! Two wires running from one person's brain to another, "Battlefield Earth" style.
To be fair though, it is straightforward to understand what it means. On the other hand, it took me a while to adjust to "throw under the bus", "rounding error" (a small amount of money), and "up to one's eyeballs".
- "Synergy" is the archetypal word that wasn't even brought up in the article.
- "Cross-functional"
- "Ping"
- "Green Field"
- "ROI" (this actually means something specific, but it's often mis-used to imply something like 'overall value')
- "MVP" (this actually means something but has now been co-opted to sound agile while meaning 'the thing we're willing to release to users and keep our pride')
Again, those only seem like that because you dont understand them:
- Synergy: explained in my other post
- Stakeholders: anyone who holds any power over a decision, even if it isn't formal power
- Everyone on the same page: make sure that everyone has the right context and knows all the important facts to date
- ROI: how much bang you're getting for the buck
- Green Field: building from scratch, without using existing infrastructure (as building a factory on a Green Field), compare to brown field (using existing infrastructure)
- Cross functional: when you're working with engineers and lawyers, aka, people who will absolutely never understand each other
Sure, you could use long phrases to replace any of those, but what's the point?
However having to ask indicates these phrases communicate poorly. (This obfuscation, as the article states, is intentional.) Instead of "green field", for example, call the project "brand new" or "from scratch". There's no need to concoct additional synonyms in a language that already has so many.
Further reading:
- Orwell's "Politics and the English Language"
- Musk's "Acronyms Seriously Suck"
> However having to ask indicates these phrases communicate poorly.
No, they actually speed up communication. Sure, to someone outside that area of work, it might seem like poor communication, but that's valid for any profession.
> This obfuscation, as the article states, is intentional.
Might be in some cases, but dismissing all of it as obfuscation is naive.
> Instead of "green field", for example, call the project "brand new" or "from scratch".
No, doesn't have the same meaning. Both "brand new" or "from scratch" might also refer to the design.
Building a "brand new" datacenter "from scratch" doesn't have the same meaning as calling it "a green field project".
Every profession has its own language. Just because you don't understand, doesn't mean it is obfuscation, or inefficient.
I agree that this language can be useful in a specific domain, but you should not underestimate the barriers this creates to actual communication, confusion because you think it means one thing and your colleague thinks it means another, and/or alienating those outside the team that uses it and understands it. This goes for any language, business or otherwise.
This is a real problem, especially for customer facing teams that continue to speak their own language instead of the client's language, and it will destroy your relationships if you do it wrong.
The article is about this language being used to convey expertise when it does not exist (understanding of the language does not imply understanding of the subject you're supposed to know, but may make you sound smart in a meeting).
Obviously feel free to keep using the terms if they work for you, but do so while also knowing the impact of the words.
TL;DR: Words matter, sounds like you are of the same opinion :) As long as we use them purposefully and understand the trade-offs, all good.
I've worked in consulting for most of my career and have a deep understanding of the meaning of these terms - but thanks for your definitions. The whole point is to make people feel silly for having to ask, even if you just made up the term.
The whole point of the article was that business created / re-purposed a number of these things to mean something specific to _business_ rather than using regular words. The parent poster asked for some favorite examples of this, so I provided them.
I am not saying that I think all these words are worthless in a corporate context, but if you trotted out some of this during a bar discussion you might get laughed at. All disciplines have their own languages, and to really know it you should speak it, but sometimes this is used to hilarious effect.
"Hey - quick ask: can I link up with you tomorrow at 6 to talk fantasy baseball?"
"Yeah, let me ping my stakeholders and make sure I can get a block for some real ideation, you know, deep work."
"Alright. I'll take an action to get it on your calendar, and will capture learnings / best practices in a deck and send via email so we can circle back with the rest of the league."
And since when is that exclusive to business? Pretty much every single profession does that. How many times have I heard other engineers using lingo to say bs? Countless.
Every single profession has its own language, and they all use it to keep outsiders out.
But apparently most people here in HN can't understand business lingo, so they just assume it is all bs.
Just look at the example you gave. I don't know about you, but I've never seen anyone use business lingo like that.
But I bet you could say the same bullshit using eng speak: "oh, hang on, I need to ping all the other peers, make sure they're up and running then run a distributed consensus algorithm to achieve sync and schedule the processes".
Re: "Stakeholders", I don't think it has to mean someone who holds power over a decision, but rather someone who is affected by a decision and thereby has a vested interest in it. Though this is orthogonal to the power: they might have power as well.
Someone who is affected but has zero influence over a decision isn't in the way I most commonly see it being used a stakeholder.
If HR decides to lay you off, you're probably not a stakeholder.
But I agree that YMMV, and I see how it could also be used in the way you suggest.
The best example of Stakeholder is a director who a teammate presented a project to before taking it to the VP. The director said:
- I don't agree with this project, but it isn't my decision. But I'm a trusted advisor of the VP.
One of the best classes I ever had was called "Power and Politics in Organizations", and dealt with identifying, managing and using power in organizations. Power comes from many different sources (information, money, influence, friendship, knowledge, formal authority, etc.), and managing is one of the most important learnings when working in any organization with more than 2 people.
Sadly, most engineers overlook those skills and focus only on "hard" skills, which I personally find to be far easier than "soft" skills (which are hard as hell to master, IMHO).
Having moved from engineering to management, I can attest that at least some of these terms have specific meanings where I work, except when they're abused. It's just that they used to sound like nonsense when I weren't faced with management responsibilities.
KT - the expectation is that the recipient should be able to perform the conductor's responsibilities after the knowledge transfer.
Stakeholder - there is a very specific group of people (mostly VP and above) that fall into this category. They need to be "kept in the loop" (another bullshit word, I suppose) when major changes to features, resources or business strategy are made.
ROI - for us, this boils down to a number, either in dollars or an expected change in a KPI (another bullshit term?)
On the same page - when a meeting/mail thread is started with this intent, the idea is that multiple teams with different/conflicting priorities need to agree on something so that they won't later claim "why weren't we told about this?"
Going forward - it's better than saying "from now on", which feels like a finger-wag to me
Huh. For us, cross functional means very specifically that backend, mobile, and frontend engineers are on the same team (previously there was a backend team, a frontend team, and a mobile team, and getting a major feature done required coordinating all three).
Get on the same page is one I use. As is stakeholders. I find that sometimes they are the words that best communicate what I need to communicate, usually in the context of setting up a meeting. "We need to get on the same page with this" is a diplomatic way of saying "You don't get what's going on, or I don't understand what you are doing and we need to figure out what the end goal is and how we are going to go about it". And stakeholders is a convenient shorthand for "everyone affected by this project".
It makes me wonder how much corporate bullshit I hear is actually better communication.
Ah! MVP has lost any meaning. Better use PoC (proof of concept) because an MVP is just a finished product with all the bells and whistles because "product management" wants it all
I have a new favorite sentence for the ones I've heard lately: "There's a world where there's a solve for that ask."
"There's a world where..." replaces "Imagine if..." or "It's possible that...", and I think it's actually a neat way of presenting an idea -- if used very sparingly.
"Solve" and "ask", in this context, replace the words "solution" and "request". I'm not sure how people started abusing these words, but it's pervasive in my industry. I suspect it follows the recent trend of "nouning" verbs (a reverse-Calvin thing to do: https://i.imgur.com/l5AC4qG.jpg) like using "gift" as an action verb ("they gifted me a calendar"). I can understand that because there isn't an equivalent alternative word in English. We could just say "give", but it doesn't have the same meaning as "give as a gift". "Solve" and "ask" are nouns that already have suitable traditional words to use instead!
I applied once as an intern to a company that "offered innovate solutions" to "deliver value to customers." At no point on their entire website did they use the phrase "PR Firm." Turns out no one thought to mention that on the website. Apparently they specialized in public figures who got into scandals, which is actually super interesting and I might have done better at the interview if I had known what the fuck they did.
The worst I've seen so far are posters with mindless and vulgar motivation propaganda such as "Bullshit-free Zone" and "Get Shit Done" [1].
These seem to be popular with a customer of mine who went all-in on SCRUM last year (believe me, you haven't seen anything yet if you haven't worked in a German team throwing around everyday or pseudo English terms in an attempt to appear cool).
It probably is, but there are pseudo-English idioms in use that just hurt. For example, "public viewing" is used in German for featuring sports events on large screens in the public, "handy" is used for mobiles, etc. See https://german.stackexchange.com/questions/40586/why-do-germ... for a discussion about this phenomenon.
I will leave that to others, but one thing I will say is that having been around the business world since the early 80's I can typically date someone just by hearing what expressions and bullshit they use. Anything that we didn't use in the 80's appears strange to hear. For example back then we didn't use 'circle back' (and now I can't even remember what we used for that I think it was simply 'I wanted to get back in touch with you'..) And yes I know circle back has been around for a long time (could even have been late 80's or early 90's).
To someone who isn't in the corporate world, the job title "agile coach" is about as bullshit as anything out there.
People in this role are actually paid to walk around inside an organisation, finding things that aren't sufficiently 'agile' and coaching people on how to make them 'agile'. Concrete deliverables=none, ability to measure success=none, ability to achieve any actual tangible outcome whatsoever=none, ability to invoke apparently-meaningful-yet-utterly-irrelevant anecdotes=infinite.
'Experts' in this field are highly in demand, and held in fear &/or awe at many corporates.
For me, the "favorites" are "engage" and "socialize". As a fresh example, Microsoft "engaged" with open-source community to the point they almost drove .NET into the ground. They "socialized" with crowds via GitHub while doing really stupid things like platform segmentation, misrepresenting alpha-quality releases as production-ready ones etc.
Kaizen terms used in teams or organizations where kaizen is definitely not being practiced as a general philosophy. At a previous employer, the only time anyone ever actually used the word kaizen was to describe management being tied up in day-long meetings debating the nature or source of some problem.
For example, "reimagining customer service", as in, complementing 20yo kids hired for peanuts offshore with bloated and expensive contact centre software.
I've seen this done where you want a 10 min meeting to get all the developers on the same wavelength before a meeting with the business so everyone will contribute in way that will drive a point forward. Usually this is when moving through security checkpoints for new features / systems.
Kind of like going through TSA "nobody make any jokes I don't want to have to spend hours here explaining this."
Management consulting has got to be the pinnacle of corporate bullshit...some favorites of mine are "synergies, deliverables, alignment, collaboration, circle back"
It only seems that way for those who don't understand it:
- Synergy: savings due to economies of scale when joining organizations or due to vertical or horizontal integration
- Deliverables: whatever product you agreed to deliver at the end of a project
- Alignment: getting a bunch of higher ups to agree on something
- Collaboration: duh
- Circle back: when you're trying to get a lot of the higher ups to agree (sadly, through individual meetings), and one of them has big concerns, you have to relay that to the other higher-ups
Programmer phrasing all sounds like bs to someone who doesn't know it. "Let's do our daily scrum standup and get the scrum master and the product owner to agree on the architecture for the data storage module".
"Scrum master", "daily scrum standup", and "product owner" aren't programmer phrasings, those are mangement phrasings in the field of software.
There's plenty of other actual programmer phrases you could have put here, but it's somewhat telling to me that your sentence of programmer phrases actually has more management phrases.
Even manager doesn't mean much. There are managers (manage people) and manager (managed a business, process, product, etc).
"Management" is manager (business). An engineering manager isn't management, is just a people manager.
Engineering phrases made it to business, and business phrases made it to engineering, that is normal. Berating a profession because you don't understand their lingo is pointless.
And the issue isn't you accusing me of being a manager, but implying that that is bad in some way.
He's right though. The typical meaning of "bullshit" is "usage of jargon to exclude from the discussion those who aren't skilled in said jargon, and to make things look more complicated than they are to the outside observer".
Many (not all) of those speaking the jargon when it's inappropriate do so knowingly, but there is indeed a significant percent of people who are so used to the jargon that they don't realize when it's inappropriate.
Many of us have strong reactions to some kinds of business jargon. But use a programming term metaphorically and we have no trouble with it, even though people who don't have the background won't get it.
Perhaps this cringing at certain terms is not entirely rational?
> Some Pacific Bell employees wrote to their congressmen about Kroning. Newspapers ran damning stories with headlines such as “Phone company dabbles in mysticism”
> "The Californian utility regulator launched a public inquiry, and eventually closed the training course, but not before $40m dollars had been spent."
Makes me wonder how the founders of Fairchild Semiconductor would have reacted. Bob Noyce, Gordon Moore, Eugene Kleiner... How much bullshit would they have tolerated in 1960?
I am essentially the highest ranking officer of my family's business (Business Unit Manager, overseeing 333 employees) here in Italy and I have to say that local (Italian) native corporate culture seems to have remained largely unaffected by the creep of such meaningless language into everyday intracompany discourse. It is on the rise in infracompany communication, however.
I have an acute disdain for empty verbiage and what I like to think of as a very critical mode of thinking, so I spend my time nipping these things in the bud and doing what the organisational machinery beneath me cannot, by its very axioms, be relied upon to do: cut down on bureaucracy and eliminate pointless paperwork and/or circular processes whenever I come across them. Not to eliminate people, but to free them up to do what they actually are here to do (and presumably/hopefully enjoy doing). Lots of cogs in the transmission is not something that the company needs or can make use of.
My personal favorites: 'downsizing', 'to better serve you' and 'you are important to us'.
There's nothing new about this though, at bank I worked for in the mid 80's (Chase Manhattan) there were plenty of such business bullshit words. I wished I had thought of cataloging them.
> During the course of an hour, I recorded 64 different nuggets of corporate claptrap. They included familiar favourites such as “doing a deep dive”, “reaching out”, and “thought leadership”
With 64 nuggets, you could've created some 8 x 8 grids and put one nugget in each square. Photocopy them, pass them around the office, and next time there's a meeting called by management, play "Bullshit Bingo". First person to hear a line of 8 nuggets spoken, either vertically, horizontally or diagonally on their grid, wins the pool.
It's so difficult to stay awake in these meetings that just taking in what you hear is an achievement. I've a theory Bullshit Bingo was actually invented by the managers themselves as a way to keep the attendees awake during such gatherings.
Does anyone have advice on how to resist this bullshit? Recently, I've been moved away from software into an operations role where my entire propose is to create bureaucracy and make numbers look good for managers' managers. I lack experience and data for my voice to be heard when I point out that we're obviously going backwards.
One thought that I have it to refuse to use any neologism that substitutes for an already-existing word or phrase. The problem I have is that business BS has been going on for longer than I've been alive, so I don't have a good sense for old BS neologisms.
For one seeking to truly understand the origin of the "Dilbert" cartoons, this article nails it.
down voters: the article includes a short anecdote on how Dilbert began, and it's humorous/entertaining/informative. please read/enjoy before flaming me.
> After the meeting, I found myself wondering why otherwise smart people so easily slipped into this kind of business bullshit. How had this obfuscatory way of speaking become so successful?
Because there's no solid link between inputs and outputs. For most management techniques it's almost impossible to measure the output of a given management function. It's unfalsifiable. Like any other domain of human endeavor when operating in an unfalsifiable space you can neither confirm nor debunk a particular technique. The only thing you can do is _assert_ and flit from one fad to the next.
The paradox here is that while management seems to be required for corporate structures to function properly so much of it is fluff or outright BS. I have to wonder if a properly trained ML algorithm could replace 90% of management decisions by cutting out the cruft and ambiguity.
If you want to get promoted, your managers need to approve of you. At the top, sometimes it's the CEO/Owner/Chairman needs to approve of you.
Easiest way is to speak their language. Unfortunately their language is often gibberish. So now all these people in middle management have learned to speak gibberish so they can make more money and get closer to the real money at the top.
How much of the hatred of business speak is driven by resentment of the fact that the business people usually make more money than the people they supervise?
A lot of it, and in the tech industry it's usually accompanied by resentment that their particular skills don't get them either the worship for intellectual prowess they so strongly believe they deserve or the money and prestige.
The irony is that while the words are stupid (“alignment”, “intentionality” and “end-state visions”) - this pretty good actually.
Most white collar jobs are full of 'waking sleep' - and if we focus on outcomes, and drive them forward with intentional work - we would be more productive.
"Bullshit jobs" - if you doing anything to move the ball forward - like working a checkout or pumping gas - your job may feel meaningless, but it's not BS by any means. Middle management tends to be the most BC. And many gov. jobs.
"US employee now spends 45% of their working day doing their real job. The other 55% is spent doing things such as wading through endless emails or attending pointless meetings."
This is part of the job. Communicating is work, and we can't be 100% efficient at all times.
I'm finishing up my accounting degree, a field which I honestly have no interest in pursuing. But, screw it, I didn't know I wanted to be a programmer when I started it and I have less than a year left.
I take issue with the idea that business BS started in the 80s. If you read material from the 20s and 30s, it was likewise filled with meaningless jargon and memes. Motivational posters are very old and they're filled with vapid and empty sayings, with the belief that by some magic hanging a sign that says "work harder" will make employees work harder (whatever that means) and make you more money that way.
What I've learned is that when you teach a soft skill, you get people teaching garbage. In an accounting class or a supply chain and logistics class, there can be some real meat to be learned, even when there's not science per se. But for most things, the books are full of arbitrary enumerations of "types of managers" and acronym to make it sound like we're being taught something. But, sadly, the attitude people have in business is that they want to be in charge of people and so they don't have to worry about the details. The details are for the expendable people you make money off of. The way you get rich in America is by being so awesome, because that's what the rich people told us is how they made their fortune.
And the problem is that they're kinda right. At the top of the food chain, everything breaks down into politics. There's little to no way of evaluating quality, and so this self-serving culture of bullshit develops. Everyone thinks they're a great judge of character and that they have these ineffable skills that cannot be measured that justify why they've gotten to where they are. But it's all just marketing. They're doing their job, sure. But there's bullshit in business for the same reason there's bullshit in marketing and politics. You're selling something and the product is interchangeable with a thousand other ones.
I agree with your assessment, and came to realize these things when I did my first internship in a company, as my university requires this to graduate (that was almost 10 years ago now).
At the time, I felt quite depressed by it. The person who was my boss's boss would regularly say completely technically incompetent things, and yet here she was running a dev team and making tons of money too.
As I've moved forward in my career, I've slowly come to feel better about things. It might take a few painful failures, but over time you become good at spotting the people who are all talk and no skills/knowledge, and you know to avoid them. Conversely, you learn how to spot the people who know what they're talking about, and know to accept their job offer instead of the employer who gave you a higher offer but gave you a bad impression during the interviews. And because you are (hopefully) getting better at what you're doing, you have more options, and more leeway to say no.
It's almost empowering to tell yourself that if these idiots can make bank, then all you have to do is learn their ways and bend them to your advantage.
Bullshit is organizational self-deception. Comfortable statements intended to insulate leaders and followers from uncomfortable problems.
In other words, bullshit isn't abnormal; it's natural. A reflex to maintain the status quo while the surrounding environment decays.
And, the greater that decay, the more wool must be spun to pull over our eyes. It is said that, in North Korea, the only state organ that worked every single day during its great famine, was its propaganda department.
In my view, calling upon employers to have the courage to be genuine, to think and talk in more authentic ways... will give birth to yet another management fad. A movement shouldn't center around some vaguery, nor should it rely on each individual's moral fiber.
Instead, a better approach would be to determine what bullshit is the everyday kind versus the kind concealing systemic failures in our present and future society, e.g. "Bullshit jobs" -> Basic Income, or "Corporate Social Responsibility" -> Tax Avoidance .
Finding and solving the latter would reduce the need for, and thereby existence of, the more unbearable bullshit. Attack the disease, not just its symptoms.