Very mixed. Stalin had a liberal arts education in the broadest sense. Krushchev was a metal worker, Brezhnev was an engineer (metallurgy), Gorbachev was a lawyer. Andropov studied marine engineering but was really only at the university to become a professional political lifer and switched to studying politics and history after the war...
You should read the book Soviet Science Wars, it's fascinating. The Soviets almost didn't get nukes because Lenin disagreed with physics on the nature of atoms...
It totally doesn't make sense. When I look at my company lawyers are rarely the ones that come up with new strategies or anything innovative. They implement what others tell them to do. That's a valuable thing but I don't think being a lawyer is a good qualification for leadership. I would argue you can see this in Congress where they seem to be more interested in fighting than actually delivering something.
I'm certainly not suggesting all leaders should be lawyers, just that a fair number of the ones making laws should be. The US legal system is complex. Every time my very business-minded senator opens his mouth, there's a real good chance that he will say something dumb about the way the legal system works.
Also, I'm generally not looking for laws that are innovative. Companies are suppose to innovate and risk a lot to do so. But if a company goes bankrupt, it's rarely a big deal. Governments don't have that level of flexibility. They need good, stable policy, from people who are good at seeing both sides of whatever argument is in play. You know what kind of people are good at doing that? Lawyers.
Each member of Congress has a substantial number of lawyers behind them to write the actual laws. That's necessary. But the direction should come from people from all walks of life, not just lawyers. I think the real problem may be that Congress creates laws by lawyers for lawyers.
Fun fact: the current Secretary-General of the UN is an EE graduate, who taught Systems Theory and Telecommunication Signals before becoming a politician.
This is one of those 'common' knowledge things that is pushed forward by non-engineers and further backed up by other non-engineers. Since we account for ~ 1e-3 or less of the population we are so outnumbered it becomes part of the culture.
If you can program you are likely among the smartest people in the world and can do better at any analytical task than almost anyone else.
Considering 90% of “programming” as a trade, especially as it pertains to this audience, is basically gluing Excel sheets together or figuring out more clever ways to extract capital from consumers...
I would like to see a compiler/PL expert or a ML expert take on extending our knowledge of quantum mechanics or cosmology, though, since they’re apparently better at solving analytical problems than everyone else. Maybe Bryan Cantrill or Theo de Raadt can go team up with Stephen Hawking and we can finally explain dark matter conclusively. Programmers were all that was missing, it seems like.
No, the problem is that intelligence doesn't work that way to begin with. Not only the smartest people are programmers, and being a smart programmer doesn't make you capable of doing someone else's job.
In that case it is counterexample, because plenty programmers sux at analysing people or political situation and dealing with them.
I don't think it is inherent to job. But youngsters without social skills are seen as potential techies even if they are not that great at math or anything really related.
It's funny how opinionated you are for someone that thinks that opinions don't matter?
I'm more than happy to hear a differing opinion. Let me ask you kindly to use your analysis skills and answers a simple question in regards to what's important when managing.
How come there are so few engineers who are CEO's of Fortune 500 companies?
Please establish tbe facts first. What is the % of engineering CEOs vs % of engineers in general corporate employment. How was this data measured? How does it define “engineer”?
I stopped being called an “engineer” after i became a “manager”. 6 years later I became a CEO. And i don’t have a college degree. How would I have been categorized?
> If you can program you are likely among the smartest people in the world and can do better at any analytical task than almost anyone else.
This one of prime reasons why young managers with engineering background fail. And why everyone around them concludes that just anyone else would be better, that stereotype is true and nerds are arrogant dicks. It is incredibly frustrating to work with know it all who knows zero about your work, but is utrely convinced that him being smartest makes up for that.
Coincidently, managers and analysts with engineering background without above believe have a chance to be good.
The people you reference exist, and they are frustrating. But if you are a good developer and really want to be a good manager, your analytic tools can really help.
Rule number one. A good manager does no actual work. They rely on others to do work, your job is to empower everyone who works for you to be productive, solve problems and to look to you for help whenever blocked. You are only as good as your subordinates.
> > If you can program you are likely among the smartest people in the world and can do better at any analytical task than almost anyone else.
Designing a system for humans is NOT an analytical task. It can be supported via analytics, but it's a political task (that requires others to be convinced that it is a good solution. For example, you can raise income levels, but if people get pissed off at inequality, you can't argue your way with numbers. They may or may not take it. And that was my point in the article).
Yea you know nothing about engineering management. To a man with a hammer every problem is a nail, and you love your hammer.
I’m an engineer. I’ve built a 45 person engineering team that shipped dozens of releases of award winning software without ever missing a schedule or compromising quality. There is nothing but analytical tasks for the engineering manager.
1. How do you maximize developer productivity? Motivation? Job satisfaction? How do you help them make technical decisions and plans?
2. What process best allows your specific teams to ship quality releases on time? How much planning overhead is necessary to do so, and how much isn’t benefiting the process or product?
3. How do you make your quality assurance staff most productive at finding and reporting problems? How can they best organize their testing to ensure the most useful/necessary test coverage, and how do they communicate their progress clearly?
4. How well do all these things meet the needs of your first level customer, the product owner?
5. How do you communicate your groups capacities to executives? How do you tell them what can be done, what can’t be done, and what shouldn’t be done?
Your tools, technologies and customer requirements are changing over time. Analysis never ends, you can always get better.
You sound like you somewhat understand politics more than you really understand engineering. Engineering is not math. Neither you can practice it in an idealized world and winning all arguments by showing a pretty table of numbers; you already cited tradeoffs and even with just that they are more often than not subject to opinions, and then I remind that not even all the "tradeoff" are known (far, very very far, from that). And big projects are obviously highly integrated with politics from the very beginning.
Now I understand that there exist some people still named engineers that are only preoccupied about how to make a mechanical item solid and light enough to satisfy a requirement, or how to design a really cool and fast hash table. This is still completely in the engineering field, but only constitute a (tiny) part of it. And even then it is dubious to consider they are either not at all preoccupied about how to work efficiently with their peers, or not even subject to that kind of consideration.
Some problems are engineering problems - design and estimate the cost of a highway bridge that crosses a river at point X; and some problems are "political" - decide the point x where a bridge will cross a river. Only an engineer can decide if a problem is an engineering one or a political one.
I completely disagree with this for several reasons. The main reason is that the article, sells short engineers abilities.
Let's look at software engineering, because that is what I am most familiar with.
First, not every problem has a well defined solution. For example, trying to decide what is the best way to pack a truck for deliveries is essentially the knapsack problem and has no solution that we could actually implement. Instead, what is done is to use heuristics to find an approximate solution.
In addition, in software engineering, there is such a thing as a desire to write beautiful and elegant code and design. Those things don't have an objective definition, but a subjective definition. Software engineers will try to write that kind of code and will discuss and debate the various methods of achieving that (look at the whole functional programming debates).
Finally, the article makes it seem like everybody's morals and values are so different. It over exaggerates the differences. The vast majority of people want things according to Maslow's hierarchy of needs https://en.m.wikipedia.org/wiki/Maslow%27s_hierarchy_of_need.... They generally want government to make sure the lowest 2 levels (physiological needs - ie clean drinking water, food, etc and security - low crime, rule of law, etc) are provided while being allowed to pursue the things higher up the pyramid.
What was described above is an optimization problem. Sure, there is no feasible and probable perfect solution. However, engineers deal with this all the time. Most code that is written does not have formal proofs. Often heuristics are used and measurements of performance in common scenarios bare taken. The same approach can also be used with social issues. Experienced engineers are also good at communicating to the rest of the team why a certain approach is a good one. This communication skills can also be used in the social arenas.
Thus don't let this article discourage you. Engineers do have the ability to deal with ambiguity and tradeoffs and communicate about them and can be excellent leaders.
> First, not every problem has a well defined solution. For example, trying to decide what is the best way to pack a truck for deliveries is essentially the knapsack problem and has no solution that we could actually implement. Instead, what is done is to use heuristics to find an approximate solution.
But even if optimal solutions are not to be found, you can state it objectively and know it's an unsolvable problem and so you interpret results in the same light. In human system, you cannot even state the problem objectively.
>Finally, the article makes it seem like everybody's morals and values are so different. It over exaggerates the differences.
If I was overexaggerating, we wouldn't have ISIS, Korea and many other cultures that pose threat to human existence every now and then. The difference of opinions is all around us, just open any news website.
> But even if optimal solutions are not to be found, you can state it objectively and know it's an unsolvable problem
There are plenty of problems in computer science where even the existence of a solution is unknown.
> If I was overexaggerating, we wouldn't have ISIS, Korea and many other cultures that pose threat to human existence every now and then.
All terrible ideologies employ the same mechanisms to encourage otherwise good people to do terrible things: they dehumanize "others". They simply differ in who they classify as the out group.
Disagreements are then driven less by opinion than prejudice.
Even bleeding hearts leftists employ these tactics. Take a pill and see how many would sit down and have e a civil meal with Trump.
> For example, trying to decide what is the best way to pack a truck for deliveries is essentially the knapsack problem and has no solution that we could actually implement.
NP-Complete problems can't be solved in polynomial time, but they can still be solved algorithmically, and the solution to an instance of a problem is perfectly well-defined.
It's nonsense to suggest that engineering decisions are simple black and white decisions compared to other kind of problems. We may be able to calculate the properties of a particular bridge design reasonably accurately but engineering is full of tradeoffs. Some of those tradeoffs are part of even doing those calculations (which necessarily involve simplifications and imperfectly known or measurable inputs and involve cost benefit tradeoffs). There are vast numbers of complex tradeoffs in designing and engineering a bridge beyond that: costs and timelines vs quality, aesthetics and other qualities, projections of future traffic patterns... Fundamentally engineering is all about smart tradeoffs, including those involving working with limited data about the problem vs. gathering more data.
On the other side, politics is full of examples of objectively bad policies where relevant experts know better ways to achieve the stated objectives. In reality many of the problems with politics stem from the fact that the stated objectives are not the real objectives behind policy decisions.
The article is riddled with other errors and fallacies too, too many to list in detail.
Author here. I'd love to get a list of errors and fallacies. I actively try to learn to think better, so it'll be great if you could point them out.
You are missing the point of the article. The question isn't about tradeoffs, it is about knowledge (or lack of such tradeoffs). In engineering problems, tradeoffs are known and in human systems, tradeoffs aren't known.
> On the other side, politics is full of examples of objectively bad policies where relevant experts know better ways to achieve the stated objectives. In reality many of the problems with politics stem from the fact that the stated objectives are not the real objectives behind policy decisions.
If you read the notes (and the paper linked), that's the exact point I'm making in the article.
I don't believe I'm missing the point of the article, I'm fundamentally disagreeing with it. You say "In engineering problems, tradeoffs are known and in human systems, tradeoffs aren't known.". I believe this is more false than true on both counts.
I don't believe my second point is the one you make in the article. I'm saying that frequently policies are not the best known means to achieve the stated objectives of the policies. The problem there is not that people can't agree on the problem they are trying to solve (though that is frequently a problem, both in politics and engineering) but that the policy solutions are known to not be good ways to achieve the stated goals and that in part that is due to the real goals being different.
Not really. In non trivial projects, you also have to "manage" the unknowns. Viewing engineering projects as completely controlled is a myth; even what we make with actual engineering practices (planes, etc.) fail every so often because of design issues. This is not because of known tradeoff, except if you twist the definition as far as pretending that the lack of infinite study and simulation is a tradeoff. Catastrophic failures often (always?) come from highly non-linear causes, you can think that kind of chaos also leads in other areas, especially among social interaction. Because of the non-linearity, even estimations of failure rates are only really estimations with absolutely no hard bounds. So said non trivial (real) engineering projects actually have to be inserted in the society as a whole, including for example insurances.
The (real) engineer also have (a moral obligation) to consider the social impact of their work.
In the end, both engineering work and leading a society is reducible to exercising reason to attempt to achieve a goal. The remaining differences are mere details.
One example of fallacious reasoning is the comment that "This is why despite his IQ, Donald Trump got elected as the president of US.". In context it can be taken as a claim that Trump has an IQ below 120 but that his exceptional persuasion abilities more than compensate.
This whole section is filled with fallacious reasoning but I'll just point out that Trump's IQ has been the topic of much debate but there is no reliable source for what it actually is. Any vaguely impartial attempt to estimate it however has to conclude that it is significantly above average, e.g. http://www.bbc.com/news/world-us-canada-41573846
Unless you have special access to Trump's IQ test results (I'm sure the media would love you to share) this comment doesn't support your line of reasoning and probably undermines it.
“in human systems, tradeoffs aren't known.” You keep making this claim without any proof. It’s a gross simplification at best, and reduces your reasoning level to pop psychology drivel.
Humans are predictable. If i slash the wages paid my engineers I can successfully predict that most will quit. Thats a known tradeoff of trying to reduce payroll costs.
Maybe you should look at historical examples. Are there successful companies founded or led by engineers? Daimler/Benz, Rolls Royce, Siemens, General Electric (successor of Edison General Electric), Amazon, Google,.. Not every good engineer is a good company leader, but those who are make history.
author cites the problem of motivating a sales team...anywhere I have worked, this has been the quintessential "objective" process; meet quota, get bonus. fail to meet quota thrice, adios.
The article seems to make two different points that don't completely fit together:
1. Non-engineers are better leaders because they can find solutions to "wicked problems", problems with many interacitng parts where there is no predefined objectively right or wrong solution.
2. Non-engineers are better leaders because they are better at persuading others that their shitty solutions are actually good.
I might buy #2 (for some definition of "better leaders"); I'm not so sure about #1.
#1 flows from the strange rationalization that regardless of anything else in life, studying humanities for four years in college turns one into a great abstract thinker....while studying engineering for four years permanently transforms you into a robot
amazing that people still believe that an undergrad education either turns you into Napoleon or R2D2
How odd. There is a meme in engineering circles that people who don't study math or science are somehow less able to think and reason. I wasn't aware of the sort of inverse you posit.
My personal experience on this is extremely lopsided: it's rare for me to encounter a non-techie who doesn't fawn embarrassingly at me when I tell them what my academic background is (physics) or gush over how smart and good at math I must be, etc., while on the other hand I hear from engineer peers all the time about how non-techies are dumb, incompetent, play politics, etc.
The bias is rather that engineering makes you great at building things, but humanities is required to know what to build.
It's just as suspect to me as it probably is to you. Humanities is just as susceptible to building castles in the air as software engineering, flights of intellectual fantasy about how the world ought to be. Difference is, when humanities makes a mistake, you get fascism or communism, rather than crashing code or broken bridges.
> problems with many interacitng parts where there is no predefined objectively right or wrong solution
This actually defines most problems engineers solve. Well, at least the "predefined right solution" part. If you really already have a predefined, correct solution to your problem, do you really need an engineer to solve it?
Most engineering solutions come in the form of making acceptable trade offs. While there almost certainly exist "wrong" solutions (risking human life for little to no benefit would be an unnaceptable tradeoff and a wrong solution), the pool of acceptable (and therefore correct, in a sense) solutions is most often at the very least greater than unity.
>1. Non-engineers are better leaders because they can find solutions to "wicked problems", problems with many interacitng parts where there is no predefined objectively right or wrong solution.
I'm not making the claim that non-engineers are better leaders. I'm merely saying the analytical approach of solving problems works against (rather than helping) any resolution of a human system problem. I'm not making a claim of non-engineers knowing how to solve wicked problems (they're called wicked by researchers _because_ there is no solution).
> Thus anyone claiming an objective basis for a problem in society is taking a simplistic view. And that’s my issue with saying technology is causing progress.
The author seems to create a false dichotomy between solving “wicked problems” according to a pure engineering approach and the alternative, which is not articulated.
Yes, there is probably not an engineering solution analogous to building a bridge to issues such as poverty. There is, however, a boatload of research about various facets of the problem that will inform a good solution. A good leader will become apprised of this research and use it to support a position that they advocate for. The ultimate position will of course be motivated by values, culture, etc but if it ignores evidence - gathered by science - or execution - informed by engineering, then it’s not a good solution.
Yes, I have. As a clarification, by good engineers, I mean the mode of thinking that goes with good engineering / problem solving skills. People can have multiple skills.
Engineering isnt simply solving known problems. Research in engineering is working in exactly the situations that he describes: where there are potentially many unknowns and trying to optimize for some variable, the same as we would in a political situation. The main difference is the inputs and outputs to the system: with a lot of engineering its pieces of hardware + software where as in politics its policy + law.
Why is this article with this click-bait title on the top of HN? A lot of leaders start off as engineers then go to CTOs, VP level, CEOs etc.
And this idea that engineers are purely scientifically minded totally ignores the endless number of articles suggesting that the best senior engineers have strong product and business sense, and in many places (but not all) having those skills are a defining quality of a senior engineer.
Engineers definitely NEED scientific background to enter the field, but this totally ignores that engineers grow business and product skills throughout their career, and need to do so to be effective
I think a pair of issues are being improperly conflated here with respect to the complexity of human systems. We see a similar problem contained within software engineering (and chemical engineering): most humans, including most engineers, are terrible at analysis and engineering of complex distributed systems. Human systems are just another example of this problem domain.
Systems level engineering breaks a problem-solving heuristic that people rely on to make analysis simple: that changing a variable does not feedback into the value of that variable, which allows you to break a big problem into a bunch of trivial small problems that can be solved independently. For systems level engineering problems, you have to consider the interaction of all components simultaneously, which is a very different type of analysis (you are designing for locally stable and hopefully approximately optimal systems level equilibria). It also has characteristics that go against the way humans want to design things: the general design pattern is that you can't design for "good" outcomes per se, you can only design systems that mitigate "bad" outcomes, with optimal "good" outcomes being the natural result of efficient pathology minimization. Most people tend to design for the outcome they want, rather than minimizing the outcomes they don't want, but only the latter works.
Bringing this back to human systems, in a naive analysis you can take any variable, label it "good", and dial it up to eleven with some direct trivial changes. I almost always see it approached this way at a policy level. In a systems level analysis, it never works that way and you have less control of the tradeoffs than you might like as a matter of policy. We suck at human systems because, thus far, we haven't come to terms with the reality that a systems level analysis doesn't let you dictate the absolute values of "good" and "bad" no matter how you define them and controlling the relative values is far from trivial in a systems level analysis. We have tools for approaching this, as some types of engineering require it, but we don't apply it because it doesn't lend itself to the kind of naive analysis people understand and the tools don't allow the kinds of outcomes in human systems we wish we could engineer.
>Human systems are just another example of this problem domain.
It isn't. Of course, both are systems of some sort, but there are several differences:
1. You can simulate a systems engineering problem and if it doesn't give you an acceptable solution in the first go, change some parameters and re-run again. In human systems, you (usually) do not get such luxury.
2. Components in an engineered system behave predictably. Humans are free agents who often act in irrational, surprising ways. You cannot simulate and analyze that. This is why there are black swans.
We cannot bundle these two systems as one and the same thing.
Your view of engineering seems too narrow. How would you classify a traffic engineering problem? Humans area a crucial component, and it certainly doesn't have an objectively correct solution (except possibly in narrow cases).
Not so simple, since driverless cars will still have to interact with pedestrians, bicyclists, etc. Not to mention that humans will still ultimately determine where the cars go, and when - even if all cars are driverless, massive numbers of people will hit the road the day before Thanksgiving.
>Not to mention that humans will still ultimately determine where the cars go
Incentives.
Right now the road network has no information on where you are going. Because of this it is near impossible to route or plan traffic beforehand other than using historical estimates. It is everyone for themselves. In a completely driverless world people could submit their driving route the day before a major event like Thanksgiving so the network has more information on what traffic will look like then. The people that plan ahead could then be given a 'queue credit' or 'queue boost' that routes their car in to the faster moving lanes, where those that did not get stuck in the slower lanes for longer.
1. You can simulate human systems too in big enough numbers. Guess what half of marketing is. Guess what crowd engineering is. Or economics.
2. Humans in general also behave predictably, though not rationally.
Human engineering is surprisingly quite similar to debugging native crashes, but not, say civic engineering or software design. It is also similar to art, with its rule governed creativity.
3. Most engineers promoted into leaders were not great engineers, and especially not great systems engineers. Peter principle is hard at work here. Not even good managers.
4. Many of the problems posed to managers are completely ill-posed (heck, not even amenable to satisficing) and likely not possible to solve properly.
5. There is a difference between a leader and a manager. One does not necessarily excel at the other's job either.
6. It's a terrible mistake to not apply engineering methods to society. Author has it completely backwards. The problem is almost always not the method, but optimization algorithm and the metric used.
Author presupposes changes that are immeasurable. Well, how does he know about them then? Guesses?
7. The standard solution to an open optimization problem is to use powerful methods for analysing infinite impulse response systems and nonlinear systems. And multivariate analysis. Since these are hard, they are often glossed over and preference is given to simpler ones.
8. Author provides no good concrete examples. Only suppositions.
9. Uses correlation with IQ ignoring the fact that social and mental problems are more pronounced at the extremes and it is a well known fact, this reversing causation.
(Consider how sane you have to be to explain the obvious thing time and again.)
10. The unsaid rule about leadership is that you're not a good leader when you don't get elected for the next term or people you lead start to resent you. Even if you can convince them. The thing about convincing people, it never works in the long term because it does not solve any cause.
11. Many people touted as great leaders are actually pretty shielded from consequences and also employ or employed armies of lower rank leaders and managers.
Contrast to Toyota, where, if I recall correctly, VPs are expected to be able to do personally the roles beneath them in the org chart. Also, the application of Lean principles to food banks and other service charities.
There were a couple of recent article from HBR making a similar point[0][1]. They make the point that it is important for leaders to have expertise about the domain that they are leading in.
It's absurd to believe someone can't learn a new way of thinking, even if they are not predisposed to it. Plenty of doctors are also amazing photographers. I've spent my whole career around engineers from the leadership side of the house, and I can firmly say I believe many of them could learn to be wonderful leaders. I think mixing disciplines requires you to switch to child eyes on your other skills, but that's about it. Great leaders are eternally humble (I know nothing), great engineers are eternally arrogant (I know this). There is certainly beautiful in both. :)
I think that’s the key point, to learn. So many tech companies make management the only way to continue getting promoted. Then they don’t offer any way for employees to learn how to be a good manager. So they’re left to learn by doing.
It boggles my mind so many great engineers are willing to work for leadership teams that contains nobody who has built organizational structures at scale. It's almost like going in for surgery by the person who made the scalpel.
I'm not sure what to take away from this article. Yes, Engineers are perhaps bad at solving insoluble problems. 'Leaders' are equally bad at solving soluble problems. However, there are a few things I do know:
Engineers can become Leaders (difficult, dicey, possible)
Leaders cannot become Engineers (ain't gonna happen)
I don’t agree with the assertion that leaders cannot become engineers. I have had leadership experience before even becoming a software engineer through my time in the Marine Corps (infantry), and it has served me well in being able to demonstrate excellence in leadership, as well as in engineering.
I have run into other Marines who have similarly succeeded in making the transition. On the flip side, some of the best managers I’ve had were former software engineers.
I think overly broad assertions made like in the article do a disservice. I think one’s ability to be successful in either role comes down to one’s own characteristics more than anythig else.
Management is an engineering problem whether we want to admit it or not. It's about maximizing the potential of the people who are working for you. Designing a team is just as much of an engineering problem as building a large scale web service. People will argue and say, but humans are emotional, greedy etc. That to me just sounds like inputs to the optimization problem at hand. How do I get team member x, to produce y for me given that x1,x2,x3 factors? Some of the best executives were formerly great engineers. Engineering is as much a people discipline as it is a technical discipline. This author's article is all over the place and I think that they miss this point entirely. This author doesn't do a good job of actually defining what they think a "good" engineer is to begin with.
it’s meaningless to say human society had made progress without stating areas that you’re considering and not considering when it comes to assessing such progress
Is it meaningless to say that some areas are more worthy of consideration than others? There are reasons why the OP chose infant mortality and education as example areas. Those reasons could be made explicit and examined objectively: for instance to see if they make sense by their own terms. For example is a society that prioritises a certain area able to continue to do that well into the future, or not?
The title of this article is click-bait and a complete oversimplification. I'm tired of seeing shit like this in HN and can't believe people are upvoting it.
112 comments
[ 2.6 ms ] story [ 157 ms ] threadhttp://www.answers.com/Q/What_percentage_of_US_congress_memb...
"lawyers comprise the biggest voting block of one type, making up 43% of Congress. Sixty percent of the U.S. Senate is lawyers."
Also, I'm generally not looking for laws that are innovative. Companies are suppose to innovate and risk a lot to do so. But if a company goes bankrupt, it's rarely a big deal. Governments don't have that level of flexibility. They need good, stable policy, from people who are good at seeing both sides of whatever argument is in play. You know what kind of people are good at doing that? Lawyers.
(His predecessor at Exxon has a PhD in chemical engineering)
If you can program you are likely among the smartest people in the world and can do better at any analytical task than almost anyone else.
That's an awfully strong unsupported statement.
I would like to see a compiler/PL expert or a ML expert take on extending our knowledge of quantum mechanics or cosmology, though, since they’re apparently better at solving analytical problems than everyone else. Maybe Bryan Cantrill or Theo de Raadt can go team up with Stephen Hawking and we can finally explain dark matter conclusively. Programmers were all that was missing, it seems like.
Who takes out your garbage?
Agreed. Though I do not consider managing people to be an "analytical task."
I don't think it is inherent to job. But youngsters without social skills are seen as potential techies even if they are not that great at math or anything really related.
Key rule from Pragmatic Marketing. “Your opinion, while interesting, is irrelevant”.
I'm more than happy to hear a differing opinion. Let me ask you kindly to use your analysis skills and answers a simple question in regards to what's important when managing.
How come there are so few engineers who are CEO's of Fortune 500 companies?
Consider how many dropouts are at fortune 500 lists. Or how many were born into money and power.
I stopped being called an “engineer” after i became a “manager”. 6 years later I became a CEO. And i don’t have a college degree. How would I have been categorized?
This one of prime reasons why young managers with engineering background fail. And why everyone around them concludes that just anyone else would be better, that stereotype is true and nerds are arrogant dicks. It is incredibly frustrating to work with know it all who knows zero about your work, but is utrely convinced that him being smartest makes up for that.
Coincidently, managers and analysts with engineering background without above believe have a chance to be good.
Rule number one. A good manager does no actual work. They rely on others to do work, your job is to empower everyone who works for you to be productive, solve problems and to look to you for help whenever blocked. You are only as good as your subordinates.
Designing a system for humans is NOT an analytical task. It can be supported via analytics, but it's a political task (that requires others to be convinced that it is a good solution. For example, you can raise income levels, but if people get pissed off at inequality, you can't argue your way with numbers. They may or may not take it. And that was my point in the article).
I’m an engineer. I’ve built a 45 person engineering team that shipped dozens of releases of award winning software without ever missing a schedule or compromising quality. There is nothing but analytical tasks for the engineering manager.
1. How do you maximize developer productivity? Motivation? Job satisfaction? How do you help them make technical decisions and plans?
2. What process best allows your specific teams to ship quality releases on time? How much planning overhead is necessary to do so, and how much isn’t benefiting the process or product?
3. How do you make your quality assurance staff most productive at finding and reporting problems? How can they best organize their testing to ensure the most useful/necessary test coverage, and how do they communicate their progress clearly?
4. How well do all these things meet the needs of your first level customer, the product owner?
5. How do you communicate your groups capacities to executives? How do you tell them what can be done, what can’t be done, and what shouldn’t be done?
Your tools, technologies and customer requirements are changing over time. Analysis never ends, you can always get better.
All the things you think are important, aren’t
Now I understand that there exist some people still named engineers that are only preoccupied about how to make a mechanical item solid and light enough to satisfy a requirement, or how to design a really cool and fast hash table. This is still completely in the engineering field, but only constitute a (tiny) part of it. And even then it is dubious to consider they are either not at all preoccupied about how to work efficiently with their peers, or not even subject to that kind of consideration.
Let's look at software engineering, because that is what I am most familiar with.
First, not every problem has a well defined solution. For example, trying to decide what is the best way to pack a truck for deliveries is essentially the knapsack problem and has no solution that we could actually implement. Instead, what is done is to use heuristics to find an approximate solution.
In addition, in software engineering, there is such a thing as a desire to write beautiful and elegant code and design. Those things don't have an objective definition, but a subjective definition. Software engineers will try to write that kind of code and will discuss and debate the various methods of achieving that (look at the whole functional programming debates).
Finally, the article makes it seem like everybody's morals and values are so different. It over exaggerates the differences. The vast majority of people want things according to Maslow's hierarchy of needs https://en.m.wikipedia.org/wiki/Maslow%27s_hierarchy_of_need.... They generally want government to make sure the lowest 2 levels (physiological needs - ie clean drinking water, food, etc and security - low crime, rule of law, etc) are provided while being allowed to pursue the things higher up the pyramid.
What was described above is an optimization problem. Sure, there is no feasible and probable perfect solution. However, engineers deal with this all the time. Most code that is written does not have formal proofs. Often heuristics are used and measurements of performance in common scenarios bare taken. The same approach can also be used with social issues. Experienced engineers are also good at communicating to the rest of the team why a certain approach is a good one. This communication skills can also be used in the social arenas.
Thus don't let this article discourage you. Engineers do have the ability to deal with ambiguity and tradeoffs and communicate about them and can be excellent leaders.
> First, not every problem has a well defined solution. For example, trying to decide what is the best way to pack a truck for deliveries is essentially the knapsack problem and has no solution that we could actually implement. Instead, what is done is to use heuristics to find an approximate solution.
But even if optimal solutions are not to be found, you can state it objectively and know it's an unsolvable problem and so you interpret results in the same light. In human system, you cannot even state the problem objectively.
>Finally, the article makes it seem like everybody's morals and values are so different. It over exaggerates the differences.
If I was overexaggerating, we wouldn't have ISIS, Korea and many other cultures that pose threat to human existence every now and then. The difference of opinions is all around us, just open any news website.
There are plenty of problems in computer science where even the existence of a solution is unknown.
> If I was overexaggerating, we wouldn't have ISIS, Korea and many other cultures that pose threat to human existence every now and then.
All terrible ideologies employ the same mechanisms to encourage otherwise good people to do terrible things: they dehumanize "others". They simply differ in who they classify as the out group.
Disagreements are then driven less by opinion than prejudice.
Even bleeding hearts leftists employ these tactics. Take a pill and see how many would sit down and have e a civil meal with Trump.
NP-Complete problems can't be solved in polynomial time, but they can still be solved algorithmically, and the solution to an instance of a problem is perfectly well-defined.
On the other side, politics is full of examples of objectively bad policies where relevant experts know better ways to achieve the stated objectives. In reality many of the problems with politics stem from the fact that the stated objectives are not the real objectives behind policy decisions.
The article is riddled with other errors and fallacies too, too many to list in detail.
You are missing the point of the article. The question isn't about tradeoffs, it is about knowledge (or lack of such tradeoffs). In engineering problems, tradeoffs are known and in human systems, tradeoffs aren't known.
> On the other side, politics is full of examples of objectively bad policies where relevant experts know better ways to achieve the stated objectives. In reality many of the problems with politics stem from the fact that the stated objectives are not the real objectives behind policy decisions.
If you read the notes (and the paper linked), that's the exact point I'm making in the article.
I don't believe my second point is the one you make in the article. I'm saying that frequently policies are not the best known means to achieve the stated objectives of the policies. The problem there is not that people can't agree on the problem they are trying to solve (though that is frequently a problem, both in politics and engineering) but that the policy solutions are known to not be good ways to achieve the stated goals and that in part that is due to the real goals being different.
Not really. In non trivial projects, you also have to "manage" the unknowns. Viewing engineering projects as completely controlled is a myth; even what we make with actual engineering practices (planes, etc.) fail every so often because of design issues. This is not because of known tradeoff, except if you twist the definition as far as pretending that the lack of infinite study and simulation is a tradeoff. Catastrophic failures often (always?) come from highly non-linear causes, you can think that kind of chaos also leads in other areas, especially among social interaction. Because of the non-linearity, even estimations of failure rates are only really estimations with absolutely no hard bounds. So said non trivial (real) engineering projects actually have to be inserted in the society as a whole, including for example insurances.
The (real) engineer also have (a moral obligation) to consider the social impact of their work.
In the end, both engineering work and leading a society is reducible to exercising reason to attempt to achieve a goal. The remaining differences are mere details.
This whole section is filled with fallacious reasoning but I'll just point out that Trump's IQ has been the topic of much debate but there is no reliable source for what it actually is. Any vaguely impartial attempt to estimate it however has to conclude that it is significantly above average, e.g. http://www.bbc.com/news/world-us-canada-41573846
Unless you have special access to Trump's IQ test results (I'm sure the media would love you to share) this comment doesn't support your line of reasoning and probably undermines it.
Humans are predictable. If i slash the wages paid my engineers I can successfully predict that most will quit. Thats a known tradeoff of trying to reduce payroll costs.
http://psycnet.apa.org/record/1999-01567-001
1. Non-engineers are better leaders because they can find solutions to "wicked problems", problems with many interacitng parts where there is no predefined objectively right or wrong solution.
2. Non-engineers are better leaders because they are better at persuading others that their shitty solutions are actually good.
I might buy #2 (for some definition of "better leaders"); I'm not so sure about #1.
amazing that people still believe that an undergrad education either turns you into Napoleon or R2D2
My personal experience on this is extremely lopsided: it's rare for me to encounter a non-techie who doesn't fawn embarrassingly at me when I tell them what my academic background is (physics) or gush over how smart and good at math I must be, etc., while on the other hand I hear from engineer peers all the time about how non-techies are dumb, incompetent, play politics, etc.
It's just as suspect to me as it probably is to you. Humanities is just as susceptible to building castles in the air as software engineering, flights of intellectual fantasy about how the world ought to be. Difference is, when humanities makes a mistake, you get fascism or communism, rather than crashing code or broken bridges.
This actually defines most problems engineers solve. Well, at least the "predefined right solution" part. If you really already have a predefined, correct solution to your problem, do you really need an engineer to solve it?
Most engineering solutions come in the form of making acceptable trade offs. While there almost certainly exist "wrong" solutions (risking human life for little to no benefit would be an unnaceptable tradeoff and a wrong solution), the pool of acceptable (and therefore correct, in a sense) solutions is most often at the very least greater than unity.
I'm not making the claim that non-engineers are better leaders. I'm merely saying the analytical approach of solving problems works against (rather than helping) any resolution of a human system problem. I'm not making a claim of non-engineers knowing how to solve wicked problems (they're called wicked by researchers _because_ there is no solution).
The author seems to create a false dichotomy between solving “wicked problems” according to a pure engineering approach and the alternative, which is not articulated.
Yes, there is probably not an engineering solution analogous to building a bridge to issues such as poverty. There is, however, a boatload of research about various facets of the problem that will inform a good solution. A good leader will become apprised of this research and use it to support a position that they advocate for. The ultimate position will of course be motivated by values, culture, etc but if it ignores evidence - gathered by science - or execution - informed by engineering, then it’s not a good solution.
In fact, I'd go further: having an engeneering mindset is necessary but not suficient for good leadership
The engineer is a methodical thinker and tinkerer. I would think in fact engineers would make excellent central committee material. :)
"Salesmen" as leaders. Well, let's see how that turns out. MAGA or GAGA, tbd ..
Get those silly little ideas out of your head and back to whatever it is you do. Isn't your boss waiting?
And this idea that engineers are purely scientifically minded totally ignores the endless number of articles suggesting that the best senior engineers have strong product and business sense, and in many places (but not all) having those skills are a defining quality of a senior engineer.
Engineers definitely NEED scientific background to enter the field, but this totally ignores that engineers grow business and product skills throughout their career, and need to do so to be effective
Systems level engineering breaks a problem-solving heuristic that people rely on to make analysis simple: that changing a variable does not feedback into the value of that variable, which allows you to break a big problem into a bunch of trivial small problems that can be solved independently. For systems level engineering problems, you have to consider the interaction of all components simultaneously, which is a very different type of analysis (you are designing for locally stable and hopefully approximately optimal systems level equilibria). It also has characteristics that go against the way humans want to design things: the general design pattern is that you can't design for "good" outcomes per se, you can only design systems that mitigate "bad" outcomes, with optimal "good" outcomes being the natural result of efficient pathology minimization. Most people tend to design for the outcome they want, rather than minimizing the outcomes they don't want, but only the latter works.
Bringing this back to human systems, in a naive analysis you can take any variable, label it "good", and dial it up to eleven with some direct trivial changes. I almost always see it approached this way at a policy level. In a systems level analysis, it never works that way and you have less control of the tradeoffs than you might like as a matter of policy. We suck at human systems because, thus far, we haven't come to terms with the reality that a systems level analysis doesn't let you dictate the absolute values of "good" and "bad" no matter how you define them and controlling the relative values is far from trivial in a systems level analysis. We have tools for approaching this, as some types of engineering require it, but we don't apply it because it doesn't lend itself to the kind of naive analysis people understand and the tools don't allow the kinds of outcomes in human systems we wish we could engineer.
It isn't. Of course, both are systems of some sort, but there are several differences:
1. You can simulate a systems engineering problem and if it doesn't give you an acceptable solution in the first go, change some parameters and re-run again. In human systems, you (usually) do not get such luxury.
2. Components in an engineered system behave predictably. Humans are free agents who often act in irrational, surprising ways. You cannot simulate and analyze that. This is why there are black swans.
We cannot bundle these two systems as one and the same thing.
Incentives.
Right now the road network has no information on where you are going. Because of this it is near impossible to route or plan traffic beforehand other than using historical estimates. It is everyone for themselves. In a completely driverless world people could submit their driving route the day before a major event like Thanksgiving so the network has more information on what traffic will look like then. The people that plan ahead could then be given a 'queue credit' or 'queue boost' that routes their car in to the faster moving lanes, where those that did not get stuck in the slower lanes for longer.
2. Humans in general also behave predictably, though not rationally. Human engineering is surprisingly quite similar to debugging native crashes, but not, say civic engineering or software design. It is also similar to art, with its rule governed creativity.
3. Most engineers promoted into leaders were not great engineers, and especially not great systems engineers. Peter principle is hard at work here. Not even good managers.
4. Many of the problems posed to managers are completely ill-posed (heck, not even amenable to satisficing) and likely not possible to solve properly.
5. There is a difference between a leader and a manager. One does not necessarily excel at the other's job either.
6. It's a terrible mistake to not apply engineering methods to society. Author has it completely backwards. The problem is almost always not the method, but optimization algorithm and the metric used. Author presupposes changes that are immeasurable. Well, how does he know about them then? Guesses?
7. The standard solution to an open optimization problem is to use powerful methods for analysing infinite impulse response systems and nonlinear systems. And multivariate analysis. Since these are hard, they are often glossed over and preference is given to simpler ones.
8. Author provides no good concrete examples. Only suppositions.
9. Uses correlation with IQ ignoring the fact that social and mental problems are more pronounced at the extremes and it is a well known fact, this reversing causation. (Consider how sane you have to be to explain the obvious thing time and again.)
10. The unsaid rule about leadership is that you're not a good leader when you don't get elected for the next term or people you lead start to resent you. Even if you can convince them. The thing about convincing people, it never works in the long term because it does not solve any cause.
11. Many people touted as great leaders are actually pretty shielded from consequences and also employ or employed armies of lower rank leaders and managers.
[0] https://hbr.org/2017/11/can-you-be-a-great-leader-without-te...
[1] https://hbr.org/2016/12/if-your-boss-could-do-your-job-youre...
I have run into other Marines who have similarly succeeded in making the transition. On the flip side, some of the best managers I’ve had were former software engineers.
I think overly broad assertions made like in the article do a disservice. I think one’s ability to be successful in either role comes down to one’s own characteristics more than anythig else.
Is it meaningless to say that some areas are more worthy of consideration than others? There are reasons why the OP chose infant mortality and education as example areas. Those reasons could be made explicit and examined objectively: for instance to see if they make sense by their own terms. For example is a society that prioritises a certain area able to continue to do that well into the future, or not?
The entire position of lead engineer/developer seems to disagree with this.
Has this ever been made public?