From inboxing to thought showers: how business bullshit took over
theguardian.com
theguardian.com
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.
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.
>"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.
[1] https://www.amazon.com/Cleanest-Race-Koreans-Themselves-Matt...
That seems like an odd and unsubstantiated assertion.
It already exists, it’s called “radical honesty”.
http://firstround.com/review/humans-hate-being-spun-how-to-p...
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 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.
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.
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.
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.
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?
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.
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.
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.
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.
All to sell the author's book. Wish I had passed.
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.
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.
So, when you say that it spends money, wastes time and so on, what process structure do you compare it to?
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.)
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).
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)
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 of scrum as training wheels to get started for organisations that aren't used to operating in an agile fashion.
There are agile techniques that don't have sprints.
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.
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.
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?
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.
> 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?
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.
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!
> 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.
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.
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.
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.
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.
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...
it never ends.
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 ")
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)
Disclosure: I work for Pivotal. Through Pivotal Labs we have various consulting engagements with the US government, including the DoD.
By being "Agile" the team can make up for the ignorant and time wasting technical decisions foisted upon by business.
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 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.
What are some "favorites" from the HN crowd?
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.
'Can you call Bob's surf shop and see if they carry Mr. Zog's Sex Wax?'
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.
That's where you can use the more general and succinct term, "contact".
'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!
"can you reach out to Carol and see when that will be done" vs "can you ask Carol when that will be done?"
Ever since Walking Dead came out, "reach out" evokes thoughts of hordes of zombies grabbing for me.
Annoying? Oh yea.
But what is wrong with reaching out? Seems like a different way of phrasing “make contact with”, except with a connotation of intending to help.
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 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.
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.
- "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')
- "A matrixed organization"
- "Get everyone on the same page"
- "Stakeholders"
... many others...
- 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?
Don't be confused, ask what it is :)
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"
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.
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.
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).
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."
"Great, thanks."
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".
Pure bullshit.
It makes me wonder how much corporate bullshit I hear is actually better communication.
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
Synergy - yup, it's mostly bullshit
-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!
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".
"Putting socks on an octopus" helped me find a buzzword dictionary online: http://www.theofficelife.com/business-jargon-dictionary-P.ht...
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.
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).
Kind of like going through TSA "nobody make any jokes I don't want to have to spend hours here explaining this."
Personally, I find the use of ‘architecting’ instead of ‘design’ to be particularly irritating.
> pseudo english terms
isn't that just the english language? A mix of norse, french, latin, alotta patoise and irish and ... just sudo english
This inspired me: I'm am now renaming /bin/sudo to /bin/pseudo
For example, "reimagining customer service", as in, complementing 20yo kids hired for peanuts offshore with bloated and expensive contact centre software.
"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!
Also this is fun: http://www.atrixnet.com/bs-generator.html
- 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".
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.
I see what you did there, nice ad hominem. But don't worry, proper Computer Engineer here, with a capital E.
But the example holds, despite your ad hominem.
Not that you are a manager. At least, that is what I assume you mean by calling it an ad hominem.
I probably could have worded it better.
"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.
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.
Perhaps this cringing at certain terms is not entirely rational?
https://www.upi.com/Archives/1987/03/24/Phone-company-dabble...
> "The Californian utility regulator launched a public inquiry, and eventually closed the training course, but not before $40m dollars had been spent."
http://articles.latimes.com/1987-10-30/business/fi-11672_1_p...
https://en.wikipedia.org/wiki/Fairchild_Semiconductor#/media...
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.
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.
Now, back to first principles.
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.
down voters: the article includes a short anecdote on how Dilbert began, and it's humorous/entertaining/informative. please read/enjoy before flaming me.
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.
> a properly trained ML algorithm
#ThinkingFaceEmoji
It would be really efficient, too...
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.
Embrace failure and shoot for the moon — tech cliché bingo
https://www.ft.com/content/c6509e8e-e6f5-11e7-8b99-0191e4537...
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.
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.
Good luck!