Jokes don't work in this context. You have no idea how many people I encounter on a daily basis who don't understand economics. Considering that my economic theory is an extra step past modern, published theory, this includes professional economists with Ph.D.s and every single person who has a Nobel Prize in Economics--although a lot of those folks are targeting market economics or microeconomics to a degree beyond my personal understanding, whether or not my grasp of macroeconomics will enhance their field or not, so I'm sure they'd have something legitimate to say about what they know that I don't.
Honestly it's driving me crazy. Or maybe humans just weren't meant to be polymaths; look at what happened to DaVinci.
That is simply not true. The hunter-gatherers worked less that us today, let alone the glorious times of the industrial revolution with its 16 hrs working days and horrendous safety record.
Hunter-Gatherer: Wander around all god damn day trying to find or kill food. Agrarian society: Put food in one place, have food available, fewer people working, less time, more reliable access to food. Agrarian society replaced hunter-gatherer society directly because it was less work. If it were more work, they wouldn't have stopped hunting.
Herd animals move, and so you have to constantly follow them (effort) instead of settling in one place; wild plants don't grow close enough together, so you need to forage over large areas rather than farm in one place; and a big enough community makes food scarce, so you have to hunt and gather over a broad span of land, which mans, again, walking all over the place, expending more effort to collect enough food to feed everyone... versus just raising your own food in one place.
It's been found that hunter-gatherers worked for 5 hours per day average day. That's 1820 hours per person per year. The US has 749,000 farmer feeding 340 million Americans on 50-hour working weeks--2600 hours per farmer, 5.72 hours PER YEAR per American. That's an inflated number, of course: 63% of wheat, 51% of soy, and 45% of rice go out, so you can estimate about half of that feeds Americans--2.86 hours per American per year. That's not quite right, either: Farmers also produce (and export) cotton, which isn't food; but also produce other types of perishable vegetables, which aren't exported.
Hunter-gatherer: 1,820 hours per person per year to obtain food.
Agrarian: 2-5 hours per person per year to obtain food.
Industrial revolution: 479 labor-hours to make a shirt by hand. 6 labor-hours to do it using a machine, including the labor-hours that went into building the machine (amortized over the number of shirts produced by the machine, and including all maintenance in the machine's life time).
Clothes by hand: 479 hours to make a shirt, including all tools, dyes, and materials produced along the way.
Clothes by machine: 6 hours to make a shirt, including all tools (machines), dyes, and materials (including fuel, electricity) produced along the way.
Everything we do cuts down on labor invested to produce a product. Every step.
Do you now [for instance] that the average height of humans took a hit after farming was "invented"? Sitting on one place without trade means [usually] poor diversity of food....that's just a small tread to pull if you like to study the subject....
This has nothing to do with the discussion. We could also discuss penis size or the modern styles of beer versus Egyptian beer, but it would be irrelevant.
Yeah, but if you have all day to be bored, you can do your job right for a bunch of other businesses, too. That means there's a market to charge 4x as much for contractor time, but contractors work 1/10 as much, so it costs 40% as much for the client.
I have an ostensible 40-hour job at which I work maybe 4 hours a year. The rest of the time is Slashdot. This happened because I streamlined every process into automated scripts and shit, and removed shit that breaks a lot in favor of shit that produces the same results but has fewer complex and volatile components.
My next job will have me working for 15, 20, 40 different clients doing the same, and not hanging out on Reddit all day.
2008 Chevy Cobalt and 2004 Mazda 3 lack them. I used to drive a 1991 Nissan that had centrifugal and pendulum locks (both), and was surprised at the lack of primary restraint when braking hard or yanking the seatbelt sharply in newer cars.
They started disabling seat belts when they integrated air bags. Seat belts don't have centrifugal or pendulum locks anymore, so don't lock up in a collision. They let you slam face-first into the airbag, which is itself dangerous (the statistics lie: airbags occasionally kill people, and we can see that plain enough; but every single non-fatal high impact in which an airbag has deployed is marked as "airbag saved this person's life", which simply assumes seatbelts never did save lives. They don't take a delta statistic of how many more lives were saved per such collision after airbags were introduced--not that it would be less than bullshit itself, since we can't measure if these collisions in these cars would have been fatal anyway).
I just want real, working seat belts. Is that too much to ask?
As in, beyond what's currently in modern circulation.
Unless you want to go back to Karl Marx, who pointed out that goods have "value" based on how much labor is invested, and so lose value when you make them more efficiently (with fewer workers), and so the key to a working economy is to make sure nobody does anything with any less labor (that is, make everything by hand, so it takes hours and hours of human labor to make stuff).
Do you remember when people stopped laboring with that hunter-gatherer stuff and started farming? Agrarian society... less work, less labor invested to produce food to feed the tribe.
How about the Industrial Revolution, when 479 labor-hours--that's $4,000 at today's $8.25 minimum hourly wage--went into producing a shirt? After mechanization, we now invest about 4-6 labor-hours, if we assume the labor is mainly $1.75-$2.50 Chinese workers; in truth, much of the cost is $30/hr invested in fuel and steel (machines) and shipping, although the amount of fuel and machine time invested in making one individual shirt is what's produced a hundred times over in mere seconds of operation (yeah, it doesn't take a lot of machine power to make a shirt... not much oil consumed at all). It's more like 20 labor minutes.
479 labor-hours to 0.33 labor-hours.
That's how it works. Each step forward is a reduction in labor invested to produce goods. Reducing the cost involved in producing goods creates more buying power--the same total number of dollars exist in the economy, after all (the rich might just have more of it--more profits), even though it costs less to produce a thing, leaving some of those dollars unspent. Market factors eventually reduces the price. Reducing the price transfers that increase in buying power down to the consumer base. The production base then wants that buying power, so must employ labor to create goods to sell to consumers.
Reduction of labor employed to produce a good or service.
Why do you think we have IAAS, SAAS, and so forth? What do you think off-the-shelf software is? Can you imagine the labor requirements if everyone built their own OS and server software in-house? Remember when they did that for cell phones, before everyone moved to Android? Do you think infrastructure hasn't gotten easier and less laboreous to build, now that we have off-the-shelf products which a skilled administrator can implement fully in 20 minutes? There's no more configuration diving and running through setting up 100 services to make something work; you put it together, enter the correct configuration, supply your keys, and it sets up all services and communications between devices and works out of the box.
We've come a long way since you had to manage/etc/lmhosts by hand.
I'm pretty sure that global economic realities will allow employers to continue this trend, but I think they will facing rapid diminishing returns on their efforts. I
can whip my dog and get some control over him, but ultimately he will stop doing anything useful. I'm much better off positively reinforcing the behaviors I want.
The "global economic reality" is that we've figured out how to produce more output with less labor. You still need the employees, but not full-time. "The Cloud" is a fancy word for "outsourcing"; we're going to move to more outsourced services, hiring data center engineers to work 100 hours per year to keep our shit running, paying some outside contractor to supply the engineers instead of bringing our own. Then, for your $95,000 salary, you'll be busy as living fuck--for 40 hours per week.
That's cheaper.
It means each 2000 hour engineer becomes a 100 hour engineer. Instead of 20 companies with 20 engineers, you have 20 companies outsourcing to 1 contractor with 1 engineer. 19 unemployed engineers. The salary load might increase (with so much unemployment in the field, it could decrease--and everyone will still go to college for those free STEM degrees, and argue that free college creating an overrun of cheap labor is a *good* thing, instead of putting the responsibility on businesses to build a valuable work force with exactly the same number of jobs), but the number of employees will decrease.
It's the old wealth cycle that nobody's bothered to document because economists are concerned with this "value" thing that has no place in economics. You need 100 labor-hours to make a thing; you find a new way to do it in 50 labor-hours; it costs half as much to produce; market forces eventually push the price down (fast forces like direct competition, and slow forces like changing consumer demands); consumers now have more residual wealth (as money), an increase in buying power caused by transferring the wealth of the displaced laborers to the broader consumer market; a new product is produced, or a niche product expands, to capture that wealth (this can take capital investment, which is why we need a few rich people); production requires labor (labor is 100% of all costs), so this creates jobs to replace lost jobs; and now people spend the same proportion of dollars available but buy more shit, thus there is more wealth (more buying power) in total.
In truth, the labor cost is measured in cost: cheaper labor does this as well; but, in the long term, you can't reduce labor costs without reducing total labor hours invested. Some workers may be $8/hr and some may be $12/hr, but those boundaries fluctuate back and forth; the longer downward trend of labor cost comes from cutting away raw invested labor time, but the measure of cost comes from the measure of buying power invested.
We'll see new unemployment as we pack these idle workers into contracting organizations. We'll then find new jobs for them. That turn-over takes time (and, in best fortune, happens simultaneously between markets) and may not employ the same displaced workers (1000 unemployed becomes 1100 unemployed, which becomes 1000 unemployed; the new unemployed may all still be unemployed at the end, and some of the old unemployed are newly employed). If you ever see people screaming about automation causing mass unemployment, this is the crux of it: if we don't slow the bleeding, we're going to see 80 years of high (like 60%-80%) unemployment; the same mass unemployment spread over a decade or two will probably just be an annoyance, more so to some people than others.
You avoid annoyed engineers by managing fields you have a passing familiarity with. If you were an airplane engineer 30 years ago, you shouldn't have any engineering position in an airplane maintenance facility--not without a brand new apprenticeship. You can manage the facility with minimal pain, though, as long as you shut your damn mouth when someone's explaining something to you.
If you're not an airplane engineer, at all, and you try to manage an airplane maintenance facility, there's going to be a lot of explaining all the damn time, and a lot of showcasing your ignorance to everyone. Constantly. It will irritate people. That doesn't mean you can't pull it off; it will be slow, annoying, and comically stupid, but you can do it. In the interest of efficiency, we should stick with someone who knows a little about planes.
This is less of a problem when you're managing the airplane maintenance company, rather than the actual facility. You don't need to know nearly as much about the maintenance of airplanes; the bits you do need to know will go out of date between needing to know them.
Now that my manager is a VP, he's legally not allowed to touch some of our critical licensing systems. It's not that he doesn't know what they do or how they work; it's that he's expected to know their business function, and expected to command an engineer to flip the big metal radiation switch. The engineer will tell you if it's a distinctly bad idea to fix the big metal radiation switch, or if he hasn't established conclusively that we've completed all proper safety checks and other preparation.
Even NASA knows this. NASA loses its shit if someone's management chain authorizes a design or a launch when the Engineers have raised concerns not brought up to NASA.
I doesn't appear that you were stupid enough to do so in any of the things you listed
I've taken practically every job I've held blind. I've gotten used to jumping into careers I know nothing about, with no training, and figuring it out. I just don't push the big red button until I've read the damn manual *and* asked everyone who's been around 10 years longer than I have why we have all this shit plugged into the big red button and what the implications of all the results of pushing the big red button will be for the business. This frequently results in the TECHNICAL UNDERSTANDING that pushing the big red button will be fine and is routine, but the BUSINESS UNDERSTANDING that there are certain things in our particular business which will be particularly *not* fine if we don't take specific actions before pushing the big red button.
A lot of that information comes from people who know nothing about my job.
In my current job, I'm the only sysadmin; I came from a network security background managing Sourcefire appliances, after spending a year monitoring IDS devices through Base, after working for Geek Squad. I've been more of a systems integration engineer than a Unix admin here: they tell me what they need, and I tell them what pieces of hardware and software to glue together, and then do all the system setup to make it work. I've learned how to build enormous CDNs from scratch and get clusters and clustered file systems running (and all the background knowledge on that) in my time as the sole Unix admin for a DevOps department.
None of that matters.
I frequently face systems I didn't build and don't use, systems to manage legal requirements, to handle finances, to keep our major business functions running. These systems integrate with multiple departments, and many are older than my tenor here. Before I touch them, I go around asking people in legal, finance, accounting, networking, and everywhere else what they do, how they're used, how critical they are, and, often, if there's precedent for things I'm asked to do by end users (recover accounts, restore or extract data, etc.). Often I find concerns about our previously-documented processes, and have to set up maintenance windows and create back-up and restore and testing processes outside the scope of what anyone's really asked for, because our business needs require it and nobody else thought of that.
I don't touch things unless I know full well the implications of what I'm about to do. Frequently, that means I'm asking questions nobody expects me to ask to people nobody expects me to talk to. I have my areas of expertise; I'm not severely limited by them, but I perform better when put to some tasks more than others. I still know how to approach my limits, and how to expand them when necessary. This is not a unique skill; it's an important skill for management--it's *the* skill for management. It's also one you can develop by main force.
But the newbie does not even know who to ask or asks the wrong questions
New managers aren't experienced managers, and thus are bad at this. Usually. Some of us can become quite good at things by reading about them; that's mostly a result of recognizing the gaps in your knowledge--which is a result of intentionally looking for them--and taking steps to mitigate them. I realize a lot of people do, in fact, dive head-first into shit they don't understand, and try to grope at every lever they can find in an attempt to accomplish their goal; and, as I've said, good managers don't need to know what all the levers do--they can't--but rather need to learn to recognize what levers are unsafe simply because they don't understand them, and find someone else to operate them.
as in my NDT example above where he did impose a time limit that was not possible with the resources at hand.
Your manager isn't using his SMEs well enough. Your example lacks the finesse that confuses an issue in the well and truly confusing stance that real life actually takes; it's very simple and straight-forward.
He was a construction manager.
He had a construction crew.
He apparently didn't ask the construction crew for proper estimates. I have a book within arm's length here that tells me how to do that in general. You use historical information about how long prior projects took and scale them; you use SME estimation to scale complexity; you get opinions of your experts in the field on how long it should take; you get these people to take all of this information and generate a low, most likely, and high estimate of how much time and how much budget is required.
All of that is complex. You've given an example where your manager didn't even try, which leaves us with not much to say on the topic besides "he fucked it up because he's dumb." We can't much use this example to show how hard it is to get on-point--which would take us into an enormous discussion about risk, the practice of measuring frequency of deviation to estimate the likelihood of threats and opportunities and taking steps to mitigate or exploit them.
We can mention scope at a distance. Before proclaiming how fast you can do something, you should definitely have a full measure of what that something is--Project Managers call that "requirements gathering", and sales people call that "asking the Project Manager so he doesn't shout at your boss that you sold the customer a 5 month project to be delivered in 2 weeks". PMs use the above techniques to estimate costs and time; once the project is accepted, they work with SMEs to generate a full work breakdown, estimating each piece, generating a more precise schedule. Sometimes they start performing the breakdown before hand for better estimation; for standard projects, standard breakdowns provide better estimation.
Each layer of management has its own duties, though. A CEO isn't a Project Manager; a CEO is a business strategy manager. The CEO decides the direction of the company and, in tandem with and by the leveraging of the other C-level managers, who all obtain information from VP-level management, makes actionable decisions about what strategies to follow and how to execute them. That's why he's the Chief Executive Officer: the other Chiefs all bring their take on their part of the business to him, and he makes the primary decisions. Many of those decisions pass specific strategies down to the lower Chiefs, who make their decisions on how to execute strategies of Finance (CFO), Operation (COO), Risk (CRO), Information management (CIO), Information Security (CISO), and so forth.
Everyone thinks executives just sit around drinking expensive brandy and throwing their incompetent "vision" at people. Hell, even some executives think that--see: Oracle. That's not actually how it works, and the fact that a lot of them are bad at doing their job right doesn't change that; it just means we should demand more from people who make $25 million salaries.
Read "value" as "something that will make money for oracle" and it makes sense.
My point was Android being non-Java would irreparably diminish Oracle's value proposition from Java in its entire, while rendering any Java-based mobile phone OS obsolete before its existence (look at what happened with Blackberry and Windows Phone offerings since Android/iOS, and try to talk about introducing a new phone OS with a straight face).
Mobile phones have moved from a variety of javame supporting system (which paid licensing fees to oracle) to andriod (which doesn't). Oracle is unhappy about this.
I realize it's trite, but Java is GPL now. Oracle doesn't have a claim here. Whether they're unhappy about it isn't an issue; their new monetization model is either A) sell Java platform consulting, Java contract programming, and Java training; or B) piss off.
The core services of the system required to actually function include, mainly, kernel event systems not supported by GNU kernels; message passing buses using systems not supported by GNU kernels; graphics display systems developed well before GNU; init systems that don't even work on GNU kernels (systemd; upstart was also made by Canonical, though), and which use non-GNU shells to bring up the system (/bin/sh is the alquist shell, ash; Debian uses their own version, dash); and so forth.
The entire support system to bring up the OS, get you logged into a desktop environment, and run Chrome or Firefox to get on Slashdot is non-GNU, save for glibc--which is a highly-replaceable core C library (some Linux distributions even use a different libc). Further, modern glibc and other core GNU libraries contain specialized code to access Linux-specific kernel functions, thus making them, at best, GNU for Linux, rather than a primary and defining component of GNU/Linux. The GNU components are the smallest and most insubstantial parts of the operating system as a whole.
I'm more confused about the informal fallacy of begging the question.
Android has irreversibly destroyed Java's fundamental value position.... how?
Android has made Java the core, fundamentally-valuable language to know for the global mobile phone and tablet market. With eleven times the global market share of iOS, Android devices have literally decimated Apple's envisioned control of the market. It seems Android's use of a Java-compatible runtime has created a mobile market which bolsters Java's usefulness in other markets, as programmers in this substantial market will necessarily have such programming skills in Java so as to make the use of Java a good investment for those wishing to create enterprise applications with the most cohesive and readily-available team of programmers. Each programmer is now more likely to have competent Java programming experience.
Imagine if Google just used CIL. Everyone would be C#.NET and Java would be well and truly dead. Would that not have irreversibly destroyed Java's fundamental value position within and outside the scope of mobile device operating systems?
Someone put in charge of programmers has to at least have some idea that MS Word is not written in a day.
Houses aren't built in a day. Ships don't sail from Japan to Delfarahk in a day. The Apollo moon mission wasn't conceived of and executed in a day.
If your first question isn't "how much time this will take," but rather, "What time limits will I impose upon this," you belong in a place where you can't do any damage with your stupidity.
Thus you have enough of the understanding of the field you are working in to know your limits and to get advice from people that you know are effective instead of at random
Dude, I can do this with law, healthcare, and airplane engineering. Mind you I'd be more effective managing DevOps--I bring this up in such discussions about my capabilities--but I can, in fact, manage finance and HR and engineering projects. I'd rely more on a foreman with 20 years of experience to take up project management on constructing a highway bridge crossing a body of water, but I could do it if I had to; it would be considerably more effort, and more meetings, and more annoyed engineers explaining limited amounts of shit to me mostly so I can pick who should be making what decisions.
Managing a soda company is not the same as managing a computer company
I've been CEO and accountant of both. Granted, it was a front for an illegal gambling business, and I was keeping double books and defrauding the IRS for thousands of dollars. I moved past that phase over a decade ago. They were different times.
Sculley did not know enough to be able to seek out good advice,
Sculley did not know enough to keep her damn mouth shut until she sought out an appropriate amount of information on the subject. "Are people supposed to be tinkering with our products?" is not a legal question; it is a PR question, a finance question, and a technical engineering (in this case, programming and security) question.
Were I in the business of selling airplanes and had it brought to my attention that people were modifying the wing plan to get more fuel efficiency and flight stability, I would ask legal about liability and contracts, and seek advice from our sales, marketing, and engineering leads, as well as involve the CRO because the CRO should always be involved. This may result in telling people their contracts flatly state we cannot assume any warranty of liability for their planes, or commanding them to cease and desist due to our liability due to Federal Aviation regulations; it may also result in selling them services to have our own engineers provide consulting on what modifications they should select, and to come out and re-certify their planes to keep their warranties in tact.
I don't know. I don't know anything about planes. Suggesting that we could re-certify a plane with a modified wing using a design we haven't rigorously tested and verified in our own labs may be the single stupidest thing I've ever come up with. I know I'd have a list of people well beyond who I just listed by the time I was done finding out what I need to find out about handling the situation, though; and one of them would tell me if that was the kind of dumb-ass suggestion only a complete idiot would conceive.
After people finished telling me all the crap I should probably keep my mouth shut about, I'd render some kind of actionable decision. That's kind of how management works, unless you're a head-up-ass dumbass.
Not really. I simply believe knowing what you don't know is far more important to the decision-making process than knowing a whole lot of shit and thinking that makes you smart.
In high-end problem solving circles, we often find the least-knowledgeable of us has answers the most-knowledgeable haven't thought of; this is why many of us train ourselves to approach problems by naivete and mental encyclopedia: a problem is a new problem, as if we don't know about the topic, and conclusions are drawn using the raw information in our brains. This is different from problem solving by experience, where prerequisite knowledge is used to draw conclusions: a lot of extra time is expended doing analysis we already know the results of, which tends to raise a lot of considerations we usually miss--and, in cases of debate, discourse, and research, we find we're wrong about stuff a lot.
It's better than letting the janitor become the genius of the group, after all.
The point is managers and leaders aren't just talking heads, and they're not technicians and engineers; they're decision-makers, and decision making is itself a demanding technical task. It's not a matter of "vision" or "business acumen" or whatever mystical qualities you want to assign to successful business people who must be more than human; it's a developed skill, just like computer programming or rocket surgery.
I'll tell you this much: generals who got political promotions because of their nobility status and their 30 years of army service frequently turned out as disasters as well. A man who's been in the medieval army for 30 years is going to have all kinds of firm beliefs about how battles work out; then the enemy shows up with all long-range rifled muskets and a firing rate of four shots per minute, and your cavalry is suddenly obsolete.
The general with 30 years of experience as a soldier isn't necessarily the general you want; you want the guy who has a general understanding of overall tactics, who has studied war history, and who is prepared to recognize when battle outcomes indicate something is wrong--and to recognize when some new tactic of the enemy has just invalidated their own. He might not know anything about the new artillery, but he can understand enough to get his sergeants and commanders together to hash out new tactics (with lots of arguments).
Meanwhile, the command chain above them have no fucking clue what's going on, and just get lots of explanation from different branches of command, and compile new tactics, and have them distributed to the officers, and have the officers work out larger war strategies with them.
This happens as you go higher and higher up: you rely on the people below you to understand more, to compile good decisions from the bickering of people below them, and to debate the merits of various strategies with each other, while you mediate. Somewhere along the line, you realize you'd piss yourself and then die if anyone handed you a rifled musket with a paper cartridge bullet and a ring bayonette, because this is just not how wars were fought in your day and you have no clue how to defend yourself effectively with this crap; but that's not really a problem, because you can see the implications of battle tactics, and so the precise training and martial methods involved are unimportant at your level.
Generally, generals who spend most of their time in the field also know how to load artillery. Generals who spend most of their time in a command tent or back 100 miles from the fighting generally understand that gunpowder goes in behind the ball, but would make for shitty gun crew in a pinch, and probably shouldn't be in direct command of an artillery line. At all.
Problem: I'm fully capable of using the resources at hand to make decisions about things I don't understand. The very purpose of management is to recognize your needs (which tend to be your business's needs), recognize your abilities, recognize your limits, and then fill those gaps by leveraging the abilities of other people.
Managers need to recognize when a situation has been resolved--when everyone has raised their concerns, and when we have assessed them, put down their risks, and decided which to accept and which to mitigate. Being able to do that allows you to pull in lawyers, engineers, finance managers, accountants, and computer programmers, and get done everything you need done, without knowing how any of it works.
It's what Steve Jobs did. It's what Bill Gates did (Gates, hilariously, asks things like, "Can we make the ACPI standard in such a way that Linux can't use it?" because he doesn't understand how software works). It's what CEOs at places like HP or Oracle fail to do.
Fact of the matter is I understand everything from HR to finance to IT to programming to project management to a broad array of VP and C level management positions. I'm sufficiently qualified for all of them that I could take any position without it being a disaster, although I don't consider myself qualified for many of them--averting a disaster is distinct from performing well. My best skills are information security, unix administration, system integration (i.e. taking a business goal and turning it into a list of software, hardware, and integration tasks to make that happen), and project management. Even without my broad base of knowledge--which does help, in any case--I could make effective business decisions at any level; even with all the knowledge I have now, I make technical decisions only after ferreting out everyone else's comments and concerns, which frequently adds new technical knowledge or cross-domain considerations, sharply averting blunders I'd otherwise make.
The value of my technical knowledge in strategic decision making is limited. It's not unimportant; it's just not possible to leverage it in its own right. I always have to approach new problems--or the same problems after any sufficient change in landscape--from a direction of naivete, calling on everyone else around me to provide their take on the matter. Trying to be the brilliant, isolated visionary who stands above all others in my grace would just lead to a lot of raining idiocy from on high, regardless of what 40-years-of-engineering-experience babble I can come up with to justify thinking I know what I'm doing.
It's called "propaganda" and it has a stronger preventative mechanism than effective mechanism. It weakly moves people toward whatever the propaganda indicates; new generations form habits following the propaganda more readily.
Really, part of the problem is everyone wants a panacea for everything. Democrats r ebil, republercans r teh devilz, etc. If we just taught computers in school, all kids would become brilliant, they'd all get jobs as computer programmers, and they'd develop logical reasoning skills to save themselves from politicians. So on and so forth everyone get free college.
Things aren't done by halves; they're done by tiny little building blocks, grains of sand that eventually form Arrakis.
I can communicate extremely technical answers across departments to finance people who have no fucking clue what I'm talking about, and they grasp it well enough for their purposes. Stop using jargon and analogies; start reading your target audience's needs and framing in those needs.
External security testing comes in two flavors: criminals who want to attack people, who are going to do whatever anyway, and will keep their secret weapons to themselves; and security people trying to make sure their walls are tight enough. The criminals are going to harm our business by harming our customers; our customers and third-party researchers aren't going to find anything they can use to damage our business, outside of attacking us criminally, and so can only help us better serve our customers by improving our product.
No astocrated frobnicators or reticulated splines.
Slashdot Mirror
In many engineering fields unemployment is 1%
99% of engineers are employed. 50% of engineers work in non-engineering jobs. They're all trash men and burger flippers.
Jokes don't work in this context. You have no idea how many people I encounter on a daily basis who don't understand economics. Considering that my economic theory is an extra step past modern, published theory, this includes professional economists with Ph.D.s and every single person who has a Nobel Prize in Economics--although a lot of those folks are targeting market economics or microeconomics to a degree beyond my personal understanding, whether or not my grasp of macroeconomics will enhance their field or not, so I'm sure they'd have something legitimate to say about what they know that I don't.
Honestly it's driving me crazy. Or maybe humans just weren't meant to be polymaths; look at what happened to DaVinci.
That is simply not true. The hunter-gatherers worked less that us today, let alone the glorious times of the industrial revolution with its 16 hrs working days and horrendous safety record.
Hunter-Gatherer: Wander around all god damn day trying to find or kill food. Agrarian society: Put food in one place, have food available, fewer people working, less time, more reliable access to food. Agrarian society replaced hunter-gatherer society directly because it was less work. If it were more work, they wouldn't have stopped hunting.
Herd animals move, and so you have to constantly follow them (effort) instead of settling in one place; wild plants don't grow close enough together, so you need to forage over large areas rather than farm in one place; and a big enough community makes food scarce, so you have to hunt and gather over a broad span of land, which mans, again, walking all over the place, expending more effort to collect enough food to feed everyone... versus just raising your own food in one place.
It's been found that hunter-gatherers worked for 5 hours per day average day. That's 1820 hours per person per year. The US has 749,000 farmer feeding 340 million Americans on 50-hour working weeks--2600 hours per farmer, 5.72 hours PER YEAR per American. That's an inflated number, of course: 63% of wheat, 51% of soy, and 45% of rice go out, so you can estimate about half of that feeds Americans--2.86 hours per American per year. That's not quite right, either: Farmers also produce (and export) cotton, which isn't food; but also produce other types of perishable vegetables, which aren't exported.
Hunter-gatherer: 1,820 hours per person per year to obtain food.
Agrarian: 2-5 hours per person per year to obtain food.
Industrial revolution: 479 labor-hours to make a shirt by hand. 6 labor-hours to do it using a machine, including the labor-hours that went into building the machine (amortized over the number of shirts produced by the machine, and including all maintenance in the machine's life time).
Clothes by hand: 479 hours to make a shirt, including all tools, dyes, and materials produced along the way.
Clothes by machine: 6 hours to make a shirt, including all tools (machines), dyes, and materials (including fuel, electricity) produced along the way.
Everything we do cuts down on labor invested to produce a product. Every step.
Do you now [for instance] that the average height of humans took a hit after farming was "invented"? Sitting on one place without trade means [usually] poor diversity of food....that's just a small tread to pull if you like to study the subject....
This has nothing to do with the discussion. We could also discuss penis size or the modern styles of beer versus Egyptian beer, but it would be irrelevant.
Yeah, but if you have all day to be bored, you can do your job right for a bunch of other businesses, too. That means there's a market to charge 4x as much for contractor time, but contractors work 1/10 as much, so it costs 40% as much for the client.
I have an ostensible 40-hour job at which I work maybe 4 hours a year. The rest of the time is Slashdot. This happened because I streamlined every process into automated scripts and shit, and removed shit that breaks a lot in favor of shit that produces the same results but has fewer complex and volatile components.
My next job will have me working for 15, 20, 40 different clients doing the same, and not hanging out on Reddit all day.
2008 Chevy Cobalt and 2004 Mazda 3 lack them. I used to drive a 1991 Nissan that had centrifugal and pendulum locks (both), and was surprised at the lack of primary restraint when braking hard or yanking the seatbelt sharply in newer cars.
They started disabling seat belts when they integrated air bags. Seat belts don't have centrifugal or pendulum locks anymore, so don't lock up in a collision. They let you slam face-first into the airbag, which is itself dangerous (the statistics lie: airbags occasionally kill people, and we can see that plain enough; but every single non-fatal high impact in which an airbag has deployed is marked as "airbag saved this person's life", which simply assumes seatbelts never did save lives. They don't take a delta statistic of how many more lives were saved per such collision after airbags were introduced--not that it would be less than bullshit itself, since we can't measure if these collisions in these cars would have been fatal anyway).
I just want real, working seat belts. Is that too much to ask?
No, it's advanced economic theory.
As in, beyond what's currently in modern circulation.
Unless you want to go back to Karl Marx, who pointed out that goods have "value" based on how much labor is invested, and so lose value when you make them more efficiently (with fewer workers), and so the key to a working economy is to make sure nobody does anything with any less labor (that is, make everything by hand, so it takes hours and hours of human labor to make stuff).
Do you remember when people stopped laboring with that hunter-gatherer stuff and started farming? Agrarian society... less work, less labor invested to produce food to feed the tribe.
How about the Industrial Revolution, when 479 labor-hours--that's $4,000 at today's $8.25 minimum hourly wage--went into producing a shirt? After mechanization, we now invest about 4-6 labor-hours, if we assume the labor is mainly $1.75-$2.50 Chinese workers; in truth, much of the cost is $30/hr invested in fuel and steel (machines) and shipping, although the amount of fuel and machine time invested in making one individual shirt is what's produced a hundred times over in mere seconds of operation (yeah, it doesn't take a lot of machine power to make a shirt... not much oil consumed at all). It's more like 20 labor minutes.
479 labor-hours to 0.33 labor-hours.
That's how it works. Each step forward is a reduction in labor invested to produce goods. Reducing the cost involved in producing goods creates more buying power--the same total number of dollars exist in the economy, after all (the rich might just have more of it--more profits), even though it costs less to produce a thing, leaving some of those dollars unspent. Market factors eventually reduces the price. Reducing the price transfers that increase in buying power down to the consumer base. The production base then wants that buying power, so must employ labor to create goods to sell to consumers.
Reduction of labor employed to produce a good or service.
Why do you think we have IAAS, SAAS, and so forth? What do you think off-the-shelf software is? Can you imagine the labor requirements if everyone built their own OS and server software in-house? Remember when they did that for cell phones, before everyone moved to Android? Do you think infrastructure hasn't gotten easier and less laboreous to build, now that we have off-the-shelf products which a skilled administrator can implement fully in 20 minutes? There's no more configuration diving and running through setting up 100 services to make something work; you put it together, enter the correct configuration, supply your keys, and it sets up all services and communications between devices and works out of the box.
We've come a long way since you had to manage /etc/lmhosts by hand.
Why not print a copy of the Book of Pasquale on it?
I'm pretty sure that global economic realities will allow employers to continue this trend, but I think they will facing rapid diminishing returns on their efforts. I can whip my dog and get some control over him, but ultimately he will stop doing anything useful. I'm much better off positively reinforcing the behaviors I want.
The "global economic reality" is that we've figured out how to produce more output with less labor. You still need the employees, but not full-time. "The Cloud" is a fancy word for "outsourcing"; we're going to move to more outsourced services, hiring data center engineers to work 100 hours per year to keep our shit running, paying some outside contractor to supply the engineers instead of bringing our own. Then, for your $95,000 salary, you'll be busy as living fuck--for 40 hours per week.
That's cheaper.
It means each 2000 hour engineer becomes a 100 hour engineer. Instead of 20 companies with 20 engineers, you have 20 companies outsourcing to 1 contractor with 1 engineer. 19 unemployed engineers. The salary load might increase (with so much unemployment in the field, it could decrease--and everyone will still go to college for those free STEM degrees, and argue that free college creating an overrun of cheap labor is a *good* thing, instead of putting the responsibility on businesses to build a valuable work force with exactly the same number of jobs), but the number of employees will decrease.
It's the old wealth cycle that nobody's bothered to document because economists are concerned with this "value" thing that has no place in economics. You need 100 labor-hours to make a thing; you find a new way to do it in 50 labor-hours; it costs half as much to produce; market forces eventually push the price down (fast forces like direct competition, and slow forces like changing consumer demands); consumers now have more residual wealth (as money), an increase in buying power caused by transferring the wealth of the displaced laborers to the broader consumer market; a new product is produced, or a niche product expands, to capture that wealth (this can take capital investment, which is why we need a few rich people); production requires labor (labor is 100% of all costs), so this creates jobs to replace lost jobs; and now people spend the same proportion of dollars available but buy more shit, thus there is more wealth (more buying power) in total.
In truth, the labor cost is measured in cost: cheaper labor does this as well; but, in the long term, you can't reduce labor costs without reducing total labor hours invested. Some workers may be $8/hr and some may be $12/hr, but those boundaries fluctuate back and forth; the longer downward trend of labor cost comes from cutting away raw invested labor time, but the measure of cost comes from the measure of buying power invested.
We'll see new unemployment as we pack these idle workers into contracting organizations. We'll then find new jobs for them. That turn-over takes time (and, in best fortune, happens simultaneously between markets) and may not employ the same displaced workers (1000 unemployed becomes 1100 unemployed, which becomes 1000 unemployed; the new unemployed may all still be unemployed at the end, and some of the old unemployed are newly employed). If you ever see people screaming about automation causing mass unemployment, this is the crux of it: if we don't slow the bleeding, we're going to see 80 years of high (like 60%-80%) unemployment; the same mass unemployment spread over a decade or two will probably just be an annoyance, more so to some people than others.
You avoid annoyed engineers by managing fields you have a passing familiarity with. If you were an airplane engineer 30 years ago, you shouldn't have any engineering position in an airplane maintenance facility--not without a brand new apprenticeship. You can manage the facility with minimal pain, though, as long as you shut your damn mouth when someone's explaining something to you.
If you're not an airplane engineer, at all, and you try to manage an airplane maintenance facility, there's going to be a lot of explaining all the damn time, and a lot of showcasing your ignorance to everyone. Constantly. It will irritate people. That doesn't mean you can't pull it off; it will be slow, annoying, and comically stupid, but you can do it. In the interest of efficiency, we should stick with someone who knows a little about planes.
This is less of a problem when you're managing the airplane maintenance company, rather than the actual facility. You don't need to know nearly as much about the maintenance of airplanes; the bits you do need to know will go out of date between needing to know them.
Managers aren't engineers.
Now that my manager is a VP, he's legally not allowed to touch some of our critical licensing systems. It's not that he doesn't know what they do or how they work; it's that he's expected to know their business function, and expected to command an engineer to flip the big metal radiation switch. The engineer will tell you if it's a distinctly bad idea to fix the big metal radiation switch, or if he hasn't established conclusively that we've completed all proper safety checks and other preparation.
Even NASA knows this. NASA loses its shit if someone's management chain authorizes a design or a launch when the Engineers have raised concerns not brought up to NASA.
I doesn't appear that you were stupid enough to do so in any of the things you listed
I've taken practically every job I've held blind. I've gotten used to jumping into careers I know nothing about, with no training, and figuring it out. I just don't push the big red button until I've read the damn manual *and* asked everyone who's been around 10 years longer than I have why we have all this shit plugged into the big red button and what the implications of all the results of pushing the big red button will be for the business. This frequently results in the TECHNICAL UNDERSTANDING that pushing the big red button will be fine and is routine, but the BUSINESS UNDERSTANDING that there are certain things in our particular business which will be particularly *not* fine if we don't take specific actions before pushing the big red button.
A lot of that information comes from people who know nothing about my job.
In my current job, I'm the only sysadmin; I came from a network security background managing Sourcefire appliances, after spending a year monitoring IDS devices through Base, after working for Geek Squad. I've been more of a systems integration engineer than a Unix admin here: they tell me what they need, and I tell them what pieces of hardware and software to glue together, and then do all the system setup to make it work. I've learned how to build enormous CDNs from scratch and get clusters and clustered file systems running (and all the background knowledge on that) in my time as the sole Unix admin for a DevOps department.
None of that matters.
I frequently face systems I didn't build and don't use, systems to manage legal requirements, to handle finances, to keep our major business functions running. These systems integrate with multiple departments, and many are older than my tenor here. Before I touch them, I go around asking people in legal, finance, accounting, networking, and everywhere else what they do, how they're used, how critical they are, and, often, if there's precedent for things I'm asked to do by end users (recover accounts, restore or extract data, etc.). Often I find concerns about our previously-documented processes, and have to set up maintenance windows and create back-up and restore and testing processes outside the scope of what anyone's really asked for, because our business needs require it and nobody else thought of that.
I don't touch things unless I know full well the implications of what I'm about to do. Frequently, that means I'm asking questions nobody expects me to ask to people nobody expects me to talk to. I have my areas of expertise; I'm not severely limited by them, but I perform better when put to some tasks more than others. I still know how to approach my limits, and how to expand them when necessary. This is not a unique skill; it's an important skill for management--it's *the* skill for management. It's also one you can develop by main force.
But the newbie does not even know who to ask or asks the wrong questions
New managers aren't experienced managers, and thus are bad at this. Usually. Some of us can become quite good at things by reading about them; that's mostly a result of recognizing the gaps in your knowledge--which is a result of intentionally looking for them--and taking steps to mitigate them. I realize a lot of people do, in fact, dive head-first into shit they don't understand, and try to grope at every lever they can find in an attempt to accomplish their goal; and, as I've said, good managers don't need to know what all the levers do--they can't--but rather need to learn to recognize what levers are unsafe simply because they don't understand them, and find someone else to operate them.
as in my NDT example above where he did impose a time limit that was not possible with the resources at hand.
Your manager isn't using his SMEs well enough. Your example lacks the finesse that confuses an issue in the well and truly confusing stance that real life actually takes; it's very simple and straight-forward.
He was a construction manager.
He had a construction crew.
He apparently didn't ask the construction crew for proper estimates. I have a book within arm's length here that tells me how to do that in general. You use historical information about how long prior projects took and scale them; you use SME estimation to scale complexity; you get opinions of your experts in the field on how long it should take; you get these people to take all of this information and generate a low, most likely, and high estimate of how much time and how much budget is required.
All of that is complex. You've given an example where your manager didn't even try, which leaves us with not much to say on the topic besides "he fucked it up because he's dumb." We can't much use this example to show how hard it is to get on-point--which would take us into an enormous discussion about risk, the practice of measuring frequency of deviation to estimate the likelihood of threats and opportunities and taking steps to mitigate or exploit them.
We can mention scope at a distance. Before proclaiming how fast you can do something, you should definitely have a full measure of what that something is--Project Managers call that "requirements gathering", and sales people call that "asking the Project Manager so he doesn't shout at your boss that you sold the customer a 5 month project to be delivered in 2 weeks". PMs use the above techniques to estimate costs and time; once the project is accepted, they work with SMEs to generate a full work breakdown, estimating each piece, generating a more precise schedule. Sometimes they start performing the breakdown before hand for better estimation; for standard projects, standard breakdowns provide better estimation.
Each layer of management has its own duties, though. A CEO isn't a Project Manager; a CEO is a business strategy manager. The CEO decides the direction of the company and, in tandem with and by the leveraging of the other C-level managers, who all obtain information from VP-level management, makes actionable decisions about what strategies to follow and how to execute them. That's why he's the Chief Executive Officer: the other Chiefs all bring their take on their part of the business to him, and he makes the primary decisions. Many of those decisions pass specific strategies down to the lower Chiefs, who make their decisions on how to execute strategies of Finance (CFO), Operation (COO), Risk (CRO), Information management (CIO), Information Security (CISO), and so forth.
Everyone thinks executives just sit around drinking expensive brandy and throwing their incompetent "vision" at people. Hell, even some executives think that--see: Oracle. That's not actually how it works, and the fact that a lot of them are bad at doing their job right doesn't change that; it just means we should demand more from people who make $25 million salaries.
Read "value" as "something that will make money for oracle" and it makes sense.
My point was Android being non-Java would irreparably diminish Oracle's value proposition from Java in its entire, while rendering any Java-based mobile phone OS obsolete before its existence (look at what happened with Blackberry and Windows Phone offerings since Android/iOS, and try to talk about introducing a new phone OS with a straight face).
Mobile phones have moved from a variety of javame supporting system (which paid licensing fees to oracle) to andriod (which doesn't). Oracle is unhappy about this.
I realize it's trite, but Java is GPL now. Oracle doesn't have a claim here. Whether they're unhappy about it isn't an issue; their new monetization model is either A) sell Java platform consulting, Java contract programming, and Java training; or B) piss off.
The core services of the system required to actually function include, mainly, kernel event systems not supported by GNU kernels; message passing buses using systems not supported by GNU kernels; graphics display systems developed well before GNU; init systems that don't even work on GNU kernels (systemd; upstart was also made by Canonical, though), and which use non-GNU shells to bring up the system (/bin/sh is the alquist shell, ash; Debian uses their own version, dash); and so forth.
The entire support system to bring up the OS, get you logged into a desktop environment, and run Chrome or Firefox to get on Slashdot is non-GNU, save for glibc--which is a highly-replaceable core C library (some Linux distributions even use a different libc). Further, modern glibc and other core GNU libraries contain specialized code to access Linux-specific kernel functions, thus making them, at best, GNU for Linux, rather than a primary and defining component of GNU/Linux. The GNU components are the smallest and most insubstantial parts of the operating system as a whole.
I'm more confused about the informal fallacy of begging the question.
Android has irreversibly destroyed Java's fundamental value position.... how?
Android has made Java the core, fundamentally-valuable language to know for the global mobile phone and tablet market. With eleven times the global market share of iOS, Android devices have literally decimated Apple's envisioned control of the market. It seems Android's use of a Java-compatible runtime has created a mobile market which bolsters Java's usefulness in other markets, as programmers in this substantial market will necessarily have such programming skills in Java so as to make the use of Java a good investment for those wishing to create enterprise applications with the most cohesive and readily-available team of programmers. Each programmer is now more likely to have competent Java programming experience.
Imagine if Google just used CIL. Everyone would be C#.NET and Java would be well and truly dead. Would that not have irreversibly destroyed Java's fundamental value position within and outside the scope of mobile device operating systems?
Someone put in charge of programmers has to at least have some idea that MS Word is not written in a day.
Houses aren't built in a day. Ships don't sail from Japan to Delfarahk in a day. The Apollo moon mission wasn't conceived of and executed in a day.
If your first question isn't "how much time this will take," but rather, "What time limits will I impose upon this," you belong in a place where you can't do any damage with your stupidity.
Thus you have enough of the understanding of the field you are working in to know your limits and to get advice from people that you know are effective instead of at random
Dude, I can do this with law, healthcare, and airplane engineering. Mind you I'd be more effective managing DevOps--I bring this up in such discussions about my capabilities--but I can, in fact, manage finance and HR and engineering projects. I'd rely more on a foreman with 20 years of experience to take up project management on constructing a highway bridge crossing a body of water, but I could do it if I had to; it would be considerably more effort, and more meetings, and more annoyed engineers explaining limited amounts of shit to me mostly so I can pick who should be making what decisions.
Managing a soda company is not the same as managing a computer company
I've been CEO and accountant of both. Granted, it was a front for an illegal gambling business, and I was keeping double books and defrauding the IRS for thousands of dollars. I moved past that phase over a decade ago. They were different times.
Sculley did not know enough to be able to seek out good advice,
Sculley did not know enough to keep her damn mouth shut until she sought out an appropriate amount of information on the subject. "Are people supposed to be tinkering with our products?" is not a legal question; it is a PR question, a finance question, and a technical engineering (in this case, programming and security) question.
Were I in the business of selling airplanes and had it brought to my attention that people were modifying the wing plan to get more fuel efficiency and flight stability, I would ask legal about liability and contracts, and seek advice from our sales, marketing, and engineering leads, as well as involve the CRO because the CRO should always be involved. This may result in telling people their contracts flatly state we cannot assume any warranty of liability for their planes, or commanding them to cease and desist due to our liability due to Federal Aviation regulations; it may also result in selling them services to have our own engineers provide consulting on what modifications they should select, and to come out and re-certify their planes to keep their warranties in tact.
I don't know. I don't know anything about planes. Suggesting that we could re-certify a plane with a modified wing using a design we haven't rigorously tested and verified in our own labs may be the single stupidest thing I've ever come up with. I know I'd have a list of people well beyond who I just listed by the time I was done finding out what I need to find out about handling the situation, though; and one of them would tell me if that was the kind of dumb-ass suggestion only a complete idiot would conceive.
After people finished telling me all the crap I should probably keep my mouth shut about, I'd render some kind of actionable decision. That's kind of how management works, unless you're a head-up-ass dumbass.
Not really. I simply believe knowing what you don't know is far more important to the decision-making process than knowing a whole lot of shit and thinking that makes you smart.
In high-end problem solving circles, we often find the least-knowledgeable of us has answers the most-knowledgeable haven't thought of; this is why many of us train ourselves to approach problems by naivete and mental encyclopedia: a problem is a new problem, as if we don't know about the topic, and conclusions are drawn using the raw information in our brains. This is different from problem solving by experience, where prerequisite knowledge is used to draw conclusions: a lot of extra time is expended doing analysis we already know the results of, which tends to raise a lot of considerations we usually miss--and, in cases of debate, discourse, and research, we find we're wrong about stuff a lot.
It's better than letting the janitor become the genius of the group, after all.
The point is managers and leaders aren't just talking heads, and they're not technicians and engineers; they're decision-makers, and decision making is itself a demanding technical task. It's not a matter of "vision" or "business acumen" or whatever mystical qualities you want to assign to successful business people who must be more than human; it's a developed skill, just like computer programming or rocket surgery.
I'll tell you this much: generals who got political promotions because of their nobility status and their 30 years of army service frequently turned out as disasters as well. A man who's been in the medieval army for 30 years is going to have all kinds of firm beliefs about how battles work out; then the enemy shows up with all long-range rifled muskets and a firing rate of four shots per minute, and your cavalry is suddenly obsolete.
The general with 30 years of experience as a soldier isn't necessarily the general you want; you want the guy who has a general understanding of overall tactics, who has studied war history, and who is prepared to recognize when battle outcomes indicate something is wrong--and to recognize when some new tactic of the enemy has just invalidated their own. He might not know anything about the new artillery, but he can understand enough to get his sergeants and commanders together to hash out new tactics (with lots of arguments).
Meanwhile, the command chain above them have no fucking clue what's going on, and just get lots of explanation from different branches of command, and compile new tactics, and have them distributed to the officers, and have the officers work out larger war strategies with them.
This happens as you go higher and higher up: you rely on the people below you to understand more, to compile good decisions from the bickering of people below them, and to debate the merits of various strategies with each other, while you mediate. Somewhere along the line, you realize you'd piss yourself and then die if anyone handed you a rifled musket with a paper cartridge bullet and a ring bayonette, because this is just not how wars were fought in your day and you have no clue how to defend yourself effectively with this crap; but that's not really a problem, because you can see the implications of battle tactics, and so the precise training and martial methods involved are unimportant at your level.
Generally, generals who spend most of their time in the field also know how to load artillery. Generals who spend most of their time in a command tent or back 100 miles from the fighting generally understand that gunpowder goes in behind the ball, but would make for shitty gun crew in a pinch, and probably shouldn't be in direct command of an artillery line. At all.
Problem: I'm fully capable of using the resources at hand to make decisions about things I don't understand. The very purpose of management is to recognize your needs (which tend to be your business's needs), recognize your abilities, recognize your limits, and then fill those gaps by leveraging the abilities of other people.
Managers need to recognize when a situation has been resolved--when everyone has raised their concerns, and when we have assessed them, put down their risks, and decided which to accept and which to mitigate. Being able to do that allows you to pull in lawyers, engineers, finance managers, accountants, and computer programmers, and get done everything you need done, without knowing how any of it works.
It's what Steve Jobs did. It's what Bill Gates did (Gates, hilariously, asks things like, "Can we make the ACPI standard in such a way that Linux can't use it?" because he doesn't understand how software works). It's what CEOs at places like HP or Oracle fail to do.
Fact of the matter is I understand everything from HR to finance to IT to programming to project management to a broad array of VP and C level management positions. I'm sufficiently qualified for all of them that I could take any position without it being a disaster, although I don't consider myself qualified for many of them--averting a disaster is distinct from performing well. My best skills are information security, unix administration, system integration (i.e. taking a business goal and turning it into a list of software, hardware, and integration tasks to make that happen), and project management. Even without my broad base of knowledge--which does help, in any case--I could make effective business decisions at any level; even with all the knowledge I have now, I make technical decisions only after ferreting out everyone else's comments and concerns, which frequently adds new technical knowledge or cross-domain considerations, sharply averting blunders I'd otherwise make.
The value of my technical knowledge in strategic decision making is limited. It's not unimportant; it's just not possible to leverage it in its own right. I always have to approach new problems--or the same problems after any sufficient change in landscape--from a direction of naivete, calling on everyone else around me to provide their take on the matter. Trying to be the brilliant, isolated visionary who stands above all others in my grace would just lead to a lot of raining idiocy from on high, regardless of what 40-years-of-engineering-experience babble I can come up with to justify thinking I know what I'm doing.
It's called "propaganda" and it has a stronger preventative mechanism than effective mechanism. It weakly moves people toward whatever the propaganda indicates; new generations form habits following the propaganda more readily.
Really, part of the problem is everyone wants a panacea for everything. Democrats r ebil, republercans r teh devilz, etc. If we just taught computers in school, all kids would become brilliant, they'd all get jobs as computer programmers, and they'd develop logical reasoning skills to save themselves from politicians. So on and so forth everyone get free college.
Things aren't done by halves; they're done by tiny little building blocks, grains of sand that eventually form Arrakis.
That happened. What's all this mean, and should I have any particular concerns?
Bread crumb trail starts.
I can communicate extremely technical answers across departments to finance people who have no fucking clue what I'm talking about, and they grasp it well enough for their purposes. Stop using jargon and analogies; start reading your target audience's needs and framing in those needs.
External security testing comes in two flavors: criminals who want to attack people, who are going to do whatever anyway, and will keep their secret weapons to themselves; and security people trying to make sure their walls are tight enough. The criminals are going to harm our business by harming our customers; our customers and third-party researchers aren't going to find anything they can use to damage our business, outside of attacking us criminally, and so can only help us better serve our customers by improving our product.
No astocrated frobnicators or reticulated splines.