Good engineers make terrible leaders(invertedpassion.com)
invertedpassion.com
Good engineers make terrible leaders
https://invertedpassion.com/engineers-make-terrible-leaders/
112 comments
Causality and Correlation.
People who try to box engineers into some sort of hyper-rational over-simplified box to separate them from real world messy problems are silly.
I suspect the underlying reason is that once you start measuring things, you tend to learn thing fast and that typically shakes up the status quo in a way that disciplines "far away" from the hard sciences aren't emotionally ready for. You don't question their sacred cows.
Let me give you a software example which shows how basically even the "tamest" seeming problem in software engineering is pretty "wicked", requiring some of the same skills you'd use to tackle a social issue.
Is website A faster than website B? What do we mean by fast? Sure we agree we can use a clock, and to bucket relativistic effects we can talk about things on planet earth. So if you're sitting there in front of a computer with a clock, what should you measure to tell if website A is faster than website B?
The answer is nobody really knows but some answers seem better than others. The most simplistic measure is to measure the time from when a request is sent to when the last byte of the response is received. But once we have a number we have to ask what it means in terms of "faster" and if it's the right number.
Some single page apps these days are really fast by that measure. They just give you a static shell, that would sure beat the pants off just about any other webpage download. Of course for single page apps giving you a static shell, the initial download is not the end, but the beginning. They start to load css and javascript and images, etc.
We might say that page download time is a poor metric because if I'm some poor schmuck trying to visit a page, the time that the html took to download doesn't really mean anything to me.
For a while people thought time to first byte was more interesting. Of course it really means nothing, but in some cases, for a short while (streaming pages from jsps, etc) before mvc became the predominant paradigm, a good ttfb was correlated with sending some html that the browser could get to work on, allowing it to render content sooner, which seemed like a good thing.
Do you see the wickedness here? In order to even tackle the problem we have to invent measures and targets, even though this is a "tame problem" with a objective stopwatch for measuring.
We kind of "knew" the right measurement was one that the human interacting with the web page would intuitively understand as "website A is fast". How long until they could see the page, how long until they could "touch" it and interact with it?
As people started doing more javascript, the approximation of TTFB stopped being as useful. There were easy things to measure, domready and page loaded. Dom ready meant that a page had loaded enough for javascript to begin interacting with a "complete" document. So almost by definition it wasn't a good measure since it marks the beginning of the lifecyle of an AJAX app or client side mvc or single page app or whatever we're calling it next week. Content loaded often was too conservative of a measure. It didn't fire until the last image had downloaded and rendered. That could be below the fold and as they say: "out of sight out of mind".
So at this point if we want to answer the question: "is website A faster than website B?" we only know the real answer is somewhere between 2 numbers.
Of course facebook cheated. They attached event handlers to the body pre-domloaded that just appended events to a Array (queue) so that people could see a button and click on it and even though the "app" wasn't done rendering, you could say: "a customer could see the page and interact with it without those interactions being lost".
So if we want to measure "when can I see a webpage and start interacting with it?" it's a pretty tough question that might not have an answer. The best we can do is say: "you loaded a web page at time t0 and at time t1 you performed an action and it (did|did not) work. We could compare those 2 things... if the action was something you could do on both websites.
You can make videos of websites rendering and visually compare them.
I've spent my career as a performance engineer and I don't really know how to, in the general case, answer the question: "is website A faster than website B". In specific cases it's sometimes clear. For example I could visit a static html page with no buttons and say: "it was definitely loaded in 50ms" and then visit some monstrosity of a single page app that displays a loading screen for several seconds and conclude: "the static webpage was faster than the app".
But I'm sure designing a bridge is sooo much simpler and there's no ambiguity there.
Right?
I suspect the underlying reason is that once you start measuring things, you tend to learn thing fast and that typically shakes up the status quo in a way that disciplines "far away" from the hard sciences aren't emotionally ready for. You don't question their sacred cows.
Let me give you a software example which shows how basically even the "tamest" seeming problem in software engineering is pretty "wicked", requiring some of the same skills you'd use to tackle a social issue.
Is website A faster than website B? What do we mean by fast? Sure we agree we can use a clock, and to bucket relativistic effects we can talk about things on planet earth. So if you're sitting there in front of a computer with a clock, what should you measure to tell if website A is faster than website B?
The answer is nobody really knows but some answers seem better than others. The most simplistic measure is to measure the time from when a request is sent to when the last byte of the response is received. But once we have a number we have to ask what it means in terms of "faster" and if it's the right number.
Some single page apps these days are really fast by that measure. They just give you a static shell, that would sure beat the pants off just about any other webpage download. Of course for single page apps giving you a static shell, the initial download is not the end, but the beginning. They start to load css and javascript and images, etc.
We might say that page download time is a poor metric because if I'm some poor schmuck trying to visit a page, the time that the html took to download doesn't really mean anything to me.
For a while people thought time to first byte was more interesting. Of course it really means nothing, but in some cases, for a short while (streaming pages from jsps, etc) before mvc became the predominant paradigm, a good ttfb was correlated with sending some html that the browser could get to work on, allowing it to render content sooner, which seemed like a good thing.
Do you see the wickedness here? In order to even tackle the problem we have to invent measures and targets, even though this is a "tame problem" with a objective stopwatch for measuring.
We kind of "knew" the right measurement was one that the human interacting with the web page would intuitively understand as "website A is fast". How long until they could see the page, how long until they could "touch" it and interact with it?
As people started doing more javascript, the approximation of TTFB stopped being as useful. There were easy things to measure, domready and page loaded. Dom ready meant that a page had loaded enough for javascript to begin interacting with a "complete" document. So almost by definition it wasn't a good measure since it marks the beginning of the lifecyle of an AJAX app or client side mvc or single page app or whatever we're calling it next week. Content loaded often was too conservative of a measure. It didn't fire until the last image had downloaded and rendered. That could be below the fold and as they say: "out of sight out of mind".
So at this point if we want to answer the question: "is website A faster than website B?" we only know the real answer is somewhere between 2 numbers.
Of course facebook cheated. They attached event handlers to the body pre-domloaded that just appended events to a Array (queue) so that people could see a button and click on it and even though the "app" wasn't done rendering, you could say: "a customer could see the page and interact with it without those interactions being lost".
So if we want to measure "when can I see a webpage and start interacting with it?" it's a pretty tough question that might not have an answer. The best we can do is say: "you loaded a web page at time t0 and at time t1 you performed an action and it (did|did not) work. We could compare those 2 things... if the action was something you could do on both websites.
You can make videos of websites rendering and visually compare them.
I've spent my career as a performance engineer and I don't really know how to, in the general case, answer the question: "is website A faster than website B". In specific cases it's sometimes clear. For example I could visit a static html page with no buttons and say: "it was definitely loaded in 50ms" and then visit some monstrosity of a single page app that displays a loading screen for several seconds and conclude: "the static webpage was faster than the app".
But I'm sure designing a bridge is sooo much simpler and there's no ambiguity there.
Right?
China’s leadership is mostly engineers, and in the US we have lawyers. Seems to be working well for China.
Some stats for the U.S:
http://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."
http://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."
Fun fact: the current Secretary-General of the UN is an EE graduate, who taught Systems Theory and Telecommunication Signals before becoming a politician.
Rex Tillerson has a degree in civil engineering. Seems like perhaps that's not a panacea.
(His predecessor at Exxon has a PhD in chemical engineering)
(His predecessor at Exxon has a PhD in chemical engineering)
How'd it work out for the Soviet Union?
Were Soviet leaders mostly engineers?
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...
In general, I think it makes sense for a large percentage of the people making laws to be familiar with how laws work.
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.
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.
[deleted]
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.
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.
[deleted]
> 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.
That's an awfully strong unsupported statement.
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.
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.
so I am either a lifelong academic physicist or I am an idiot?
Who takes out your garbage?
Who takes out your garbage?
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.
"...better at any analytical task"
Agreed. Though I do not consider managing people to be an "analytical task."
Agreed. Though I do not consider managing people to be an "analytical task."
Have you ever managed people? I couldn't disagree more, unless you're using "analytical" in some narrow mathematical sense.
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.
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.
The only people who think that managing people isn’t an analytic task, are either bad managers or clueless.
[deleted]
Or maybe they don't see the world so Black and White :)
Analysis isn’t a black and white issue, it’s the collection of factual data to help make the best decisions.
Key rule from Pragmatic Marketing. “Your opinion, while interesting, is irrelevant”.
Key rule from Pragmatic Marketing. “Your opinion, while interesting, is irrelevant”.
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?
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?
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?
Easy to explain: they spend their formation years making things instead of going after rich connections.
Consider how many dropouts are at fortune 500 lists. Or how many were born into money and power.
Consider how many dropouts are at fortune 500 lists. Or how many were born into money and power.
[deleted]
1 in 1000? seems too low. I found a stat for Germany 2010, and it says engineers were 0.8% of the population, or 8e-3
> 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.
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.
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).
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.
All the things you think are important, aren’t
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
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.
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.
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.
I agree with you. The best managers I've had have done software before or keep doing it, as I hope someday too.
> 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.
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.
Author here.
> 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.
> 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.
Just to a reminder that there are two Koreas, and one of them probably doesn’t deserve to be lumped in with ISIS.
> 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.
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.
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.
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.
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.
> In engineering problems, tradeoffs are known
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.
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.
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.
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.
“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.
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.
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.
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.
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.
Problem: It's been shown time and again that this doesn't work.
(For all but the lowest simple, mechanical, repetitive tasks.)
http://psycnet.apa.org/record/1999-01567-001
http://psycnet.apa.org/record/1999-01567-001
counter example: the world economy, most of which is still kept running with the threat of repercussions
How is this a counterexample?
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. 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.
> 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.
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 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
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.
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.
nowhere did I claim that only engineers were numerate, logical or analytical
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.
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.
And that an engineer can't be interested in humanities - there are plenty of engineers who have hobbies outside engineering.
>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).
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.
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.
Fully aggree.
In fact, I'd go further: having an engeneering mindset is necessary but not suficient for good leadership
In fact, I'd go further: having an engeneering mindset is necessary but not suficient for good leadership
This clickbait headline is leaning on a study behind a paywall so we can't argue the actual points or data. Don't bother
OP is conflating "method" and "mindset".
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 ..
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 ..
[deleted]
Engineers: Know your place and stay within it.
Get those silly little ideas out of your head and back to whatever it is you do. Isn't your boss waiting?
Get those silly little ideas out of your head and back to whatever it is you do. Isn't your boss waiting?
For the record, I'm an engineer myself.
Surely you've met engineers that aren't purely analytical?
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.
okay, well if you really believe this...why the article?
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
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.
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.
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.
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.
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.
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).
Current traffic engineering is almost a complete human problem. Swap it out to driverless cars and it becomes more like routing IP packets.
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.
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.
I like the way you think. I've wrote a little satire along those lines once: http://250bpm.com/blog:88
Just another self-promoting Twitter startup bro. Who is upvoting this complete gibberish? At least that article on the cult guy was interesting...
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.
[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...
[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...
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.
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?
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?
>Good engineers make terrible leaders
The entire position of lead engineer/developer seems to disagree with this.
The entire position of lead engineer/developer seems to disagree with this.
Philosophers make terrible judges of engineering managers.
Laconic, I like it. (Yes that is a philosophy.)
>This is why despite his IQ, Donald Trump got elected as the president of US.
Has this ever been made public?
Has this ever been made public?
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.
> While a leader with an engineering mindset works hard at finding at a better solution, other leaders use their personality, power or charm to persuade people that their solution will be in everyone’s benefits, even if it actually isn’t. This is why despite his IQ, Donald Trump got elected as the president of US.
I'm no Trump fan, but have to wonder why, in an article proposing an objective truth, I have to read the author's opinion of Donald Trump -- in this case regarding his IQ.
If the author can prove the lowness of Trump's IQ, I'd love to see the objective proof. Otherwise I would suggest the author stick with his main points and not involve his politics.
Moreover, it's sickening to me to read the veiled insult of the voters (the "even if it actually isn't" statement) who put Trump in office. Again, perhaps the author would consider sticking with his main thesis and avoid denigration of those with whom he clearly disagrees.
I'm no Trump fan, but have to wonder why, in an article proposing an objective truth, I have to read the author's opinion of Donald Trump -- in this case regarding his IQ.
If the author can prove the lowness of Trump's IQ, I'd love to see the objective proof. Otherwise I would suggest the author stick with his main points and not involve his politics.
Moreover, it's sickening to me to read the veiled insult of the voters (the "even if it actually isn't" statement) who put Trump in office. Again, perhaps the author would consider sticking with his main thesis and avoid denigration of those with whom he clearly disagrees.
This may be country-specific: http://www.economist.com/node/13496638
This did not make any sense to me. The article does not back its title in any way. Material progress for humanity achieved through technology somehow 'cannot be objectively measured'. Plus some empty statements about engineering being task-executors with no political/planning ability?
Engineers, like most professions, contain all the diversity of humanity. The only filter is that the portion of the populace that couldn't attain that level of education, or who can't hold onto a job, aren't included.
Sure, there's some commonality in that it's a group that has been exposed to a certain form of thinking, but if you asked people to write their thoughts on solving the poverty problem, I seriously doubt you'd be able to identify the engineers from what they wrote.
Sure, there's some commonality in that it's a group that has been exposed to a certain form of thinking, but if you asked people to write their thoughts on solving the poverty problem, I seriously doubt you'd be able to identify the engineers from what they wrote.
>> I seriously doubt you'd be able to identify the engineers from what they wrote.
This isn't meant to be funny, but I bet you could identify good engineers from what they wrote rather quickly. What does a good engineer do when they discover a faulty resistor while debugging a circuit? Cut it out, throw it in the trash, and replace it with a working one. They never pause to consider the moral impact of suddenly removing it from the board, attempt to rehabilitate it, or try to empathize with it. They cut it out and move on.
If you apply engineering principles to societal problems, the die-hard engineer may come up with a similar result. I'm only speculating, but their line of reasoning could resemble... "these (good productive) citizens do not harm other citizens, and they support their economies through labor and taxes.... discard every other citizen that does not do this, and replace them with a working one".
Sounds like a dystopian sci-fi plot to me.
This isn't meant to be funny, but I bet you could identify good engineers from what they wrote rather quickly. What does a good engineer do when they discover a faulty resistor while debugging a circuit? Cut it out, throw it in the trash, and replace it with a working one. They never pause to consider the moral impact of suddenly removing it from the board, attempt to rehabilitate it, or try to empathize with it. They cut it out and move on.
If you apply engineering principles to societal problems, the die-hard engineer may come up with a similar result. I'm only speculating, but their line of reasoning could resemble... "these (good productive) citizens do not harm other citizens, and they support their economies through labor and taxes.... discard every other citizen that does not do this, and replace them with a working one".
Sounds like a dystopian sci-fi plot to me.
As a society, we have demonstrated a remarkably limited ability to coherently articulate what the problems are.
Now, if you can articulate a clear problem, I might be persuaded that engineers as class will solve it a specific way. But my experience is that once a problem is identified anyone could do it. Identifying the problem is the part that generates friction.
In the one-line example you came up with, you imply:
* Working is good
* Economic productivity is the end goal
* Possibly a link between morality and citizenship
* That 'replacement' based on some unknown process will be legitimate
If I am allowed to assume things like that, every human problem becomes easy and I can engineer it. But a 'landslide' in politics is 60% agreement on a subject - assumptions like this do not fly. I, for example, disagree with at least 2 of those points.
Now, if you can articulate a clear problem, I might be persuaded that engineers as class will solve it a specific way. But my experience is that once a problem is identified anyone could do it. Identifying the problem is the part that generates friction.
In the one-line example you came up with, you imply:
* Working is good
* Economic productivity is the end goal
* Possibly a link between morality and citizenship
* That 'replacement' based on some unknown process will be legitimate
If I am allowed to assume things like that, every human problem becomes easy and I can engineer it. But a 'landslide' in politics is 60% agreement on a subject - assumptions like this do not fly. I, for example, disagree with at least 2 of those points.
Funny you mention this, I made exactly this argument against the philosophy of hard determinism a few months ago. After all, under hard determinism, people have no more value than any other aggregate of deterministic particles, so why should we even try to reform them as most hard determinists argue?
So it's not just engineers that might reach these conclusions.
So it's not just engineers that might reach these conclusions.
Of course HN would be a terrible place to make an argument that "good engineers make terrible leaders".
Engineers here would just deconstruct it.
Anyone see the irony?
Engineers here would just deconstruct it.
Anyone see the irony?
And leaders will ignore it as baby talk. Or posturing.
Let’s wrap it up. Confuses engineering and science. Reduces engineering activities to closed problems. Thinks science does not successfully offers models for fuzzy systems (<cough> thermodynamics, man </cough>). Puts doubts on the fact that technology enabled human progress above its animal condition. And finally, seems to ignore that the main role of an engineer is to safely /lead/ the work in factory or on construction sites. Really, I have seldom read something so inaccurate, up to the point where I suspect it may have been written on the sole purpose of annoying the HN crowd...
Bad artical paddling completely unsubstantiated theory and making absurd claims - very likely to benefit his own career as non-engineer leader.
Author basically rides his argument on one "paper" which also makes out-of-the-thin-air arguments in similar fashion. The central point of the argument is that science is incapable of dealing with complex incompletely specified systems with uncertainties. Then author goes one step ahead and makes a sweeping statement that people who are good at scientific approach have decreased abilities to deal with this kind of problems! On the other hand, so called "leaders" have this natural "charm" to allow them to work with such systems without requiring scientific mindset. He then cites Donald Trump as proof of his argument. In my long career I have actually came across such leaders with natural "charm" and I can attest that chances of have them destruct the project is much higher than a leader with engineering background.
So the conclusion is that if person is less scientific then better chance that he would be good leader. I think author has time travelled from 500 BC and is not aware of entire fields of complexity theory, chaos, probability, statistics. He is probably also unaware that virtually every major leader from Alexander to JFK have used science to win their wars and had fairly good understanding and ability to naturally apply those methods to their problems.
No need to waste your time in reading this BS.
Author basically rides his argument on one "paper" which also makes out-of-the-thin-air arguments in similar fashion. The central point of the argument is that science is incapable of dealing with complex incompletely specified systems with uncertainties. Then author goes one step ahead and makes a sweeping statement that people who are good at scientific approach have decreased abilities to deal with this kind of problems! On the other hand, so called "leaders" have this natural "charm" to allow them to work with such systems without requiring scientific mindset. He then cites Donald Trump as proof of his argument. In my long career I have actually came across such leaders with natural "charm" and I can attest that chances of have them destruct the project is much higher than a leader with engineering background.
So the conclusion is that if person is less scientific then better chance that he would be good leader. I think author has time travelled from 500 BC and is not aware of entire fields of complexity theory, chaos, probability, statistics. He is probably also unaware that virtually every major leader from Alexander to JFK have used science to win their wars and had fairly good understanding and ability to naturally apply those methods to their problems.
No need to waste your time in reading this BS.