What Makes an Effective Engineer?(broman.blog)
broman.blog
What Makes an Effective Engineer?
https://broman.blog/effective-engineer
14 comments
A very traditionalist view. Close to the mark, but also impractical.
I manage a small but very cross-disciplinary R&D team (also hardware/electronics/software) and do not expect people to execute on all of those capabilities. It would surely be a great help if they could, but it's just unrealistic to find people who are that well rounded.
I find that engineers are often domain-specific and their thinking may be clouded by a core or familiar domain. For example in cross-domain problems you'll often see software engineers who want to solve everything with a stack they're familiar with, mechanical engineers who reach directly for industrial automation components, and electronics engineers so stuck in high-cost-of-iteration or large production mentalities they are unable to operate in high-iteration modes with alternative tradeoffs.
In general, I would say that: (1) engineering process management is a different discipline to most domains of engineering; (2) competency at generalist or cross-domain engineering is a relative rarity in those identifying as engineers; (3) R&D engineering is a different skillset (both engineering and management process wise) to production engineering (and the magnitude of these differences is often related to the fabrication/iteration processes and associated costs and timelines in the domain in question); (4) Engineers who excel at cross-disciplinary thinking and novel problems tend to be those without overly formal engineering backgrounds; (5) In some ways, all management is human process engineering, and it's simply unrealistic to expect all engineers to be effectively multi-domain.
I manage a small but very cross-disciplinary R&D team (also hardware/electronics/software) and do not expect people to execute on all of those capabilities. It would surely be a great help if they could, but it's just unrealistic to find people who are that well rounded.
I find that engineers are often domain-specific and their thinking may be clouded by a core or familiar domain. For example in cross-domain problems you'll often see software engineers who want to solve everything with a stack they're familiar with, mechanical engineers who reach directly for industrial automation components, and electronics engineers so stuck in high-cost-of-iteration or large production mentalities they are unable to operate in high-iteration modes with alternative tradeoffs.
In general, I would say that: (1) engineering process management is a different discipline to most domains of engineering; (2) competency at generalist or cross-domain engineering is a relative rarity in those identifying as engineers; (3) R&D engineering is a different skillset (both engineering and management process wise) to production engineering (and the magnitude of these differences is often related to the fabrication/iteration processes and associated costs and timelines in the domain in question); (4) Engineers who excel at cross-disciplinary thinking and novel problems tend to be those without overly formal engineering backgrounds; (5) In some ways, all management is human process engineering, and it's simply unrealistic to expect all engineers to be effectively multi-domain.
Say I give you a box with 1,000 puzzles written on sheets of paper, and I ask you to estimate how long it will take to solve all the puzzles. You take out a small random sample and time how long it takes you to solve each, and then you develop a cost distribution from that, scale it up to 1000, add a healthy 2-sigma buffer on top, and tell me you're 95% certain you can solve all the puzzles within that time. You've accomplished your step D. Oops, on one of the papers was the Collatz Conjecture, so you're fucked, I'm fucked, everyone's fucked, everyone's unhappy, and you get fired.
Your steps work great in an idealized perfect world where everything is simple, and they are absolutely awful, bloated, and ineffective in the real world. The perception that this is what engineers should be contributes to why a huge percentage of real-world projects go over-budget by triple-digit percentages, get cancelled entirely, or completely fail to live up to their expectations.
It's quite the other way around. If you're doing something new, you just don't know everything yet, so you simply cannot do this monotonous waterfall method. You can only do this with well-known problems that have well-established solutions. If you define an engineer as someone who is producing a practical solution to a problem that has never been solved before, at least in this exact way (on this site, in this heat, at that speed, at this scale, within that organization, etc.) then you have it exactly backwards -- anyone who follows this process is a technician, solving a problem by following an SOP or a textbook or a WikiHow article. Engineers realize this is all just dumb bullshit they have to do that takes their time away from actually exploring, understanding, and ultimately solving the (probably different, by this point) problem.
Your steps work great in an idealized perfect world where everything is simple, and they are absolutely awful, bloated, and ineffective in the real world. The perception that this is what engineers should be contributes to why a huge percentage of real-world projects go over-budget by triple-digit percentages, get cancelled entirely, or completely fail to live up to their expectations.
It's quite the other way around. If you're doing something new, you just don't know everything yet, so you simply cannot do this monotonous waterfall method. You can only do this with well-known problems that have well-established solutions. If you define an engineer as someone who is producing a practical solution to a problem that has never been solved before, at least in this exact way (on this site, in this heat, at that speed, at this scale, within that organization, etc.) then you have it exactly backwards -- anyone who follows this process is a technician, solving a problem by following an SOP or a textbook or a WikiHow article. Engineers realize this is all just dumb bullshit they have to do that takes their time away from actually exploring, understanding, and ultimately solving the (probably different, by this point) problem.
I always got rejected by big tech, even when I passed their algorithm questions. They said I’m not there yet on leadership stuffs.
Now I work in a private trading firm instead. The best company ever I’ve encountered, and really smart people that I’m sure could run around in circles against big tech employees.
Good work life balance. Can do WFH whenever wherever. Good food. Less bureaucracies, less meetings. No middle managers. No PMs. Just work directly with the traders and implement what they want. I get to see my creation goes live and make money for the company. Priceless.
Oh, and the pay is nice too. Pays better than big tech. One dude making $400k as a 21 year old engineer here lol. Full cash.
Now I work in a private trading firm instead. The best company ever I’ve encountered, and really smart people that I’m sure could run around in circles against big tech employees.
Good work life balance. Can do WFH whenever wherever. Good food. Less bureaucracies, less meetings. No middle managers. No PMs. Just work directly with the traders and implement what they want. I get to see my creation goes live and make money for the company. Priceless.
Oh, and the pay is nice too. Pays better than big tech. One dude making $400k as a 21 year old engineer here lol. Full cash.
Except you're producing nothing of value to humanity. 400k a year to waste your life enabling the vampires to keep playing zero-sum games. Not a good bargain.
I've worked in fintech for a few years and I consider it one of the biggest mistakes I've ever made.
I've worked in fintech for a few years and I consider it one of the biggest mistakes I've ever made.
most of us like playing games. and the stock market is not zero-sum. Forex is, not the stock market.
I would rather play money games than status games and spend my life virtue signaling to climb the status hierarchy. Status is zero-sum in case you didn't notice.
I used to think like this, until I realized Facebook as a big tech created more damage to society than me.
Also, our trading firm provides liquidity, so it is not not providing value.
Also, our trading firm provides liquidity, so it is not not providing value.
hiring?
Yes, DM me.
You don't have an email set up on your account. You can click on my name and see my email if you want.
Pragmatism and understanding your purpose is to drive value for the business.
When an engineer understands their job is to deliver value to the business as oppose to fussing over the pedantry of a specific style or framework or “perfect solution” or inventing problems that don’t exist. When they understand they can negotiate the deliverables to minimize time and maximize impact to the product while maintaining an extensible code base. That’s what makes an effective engineer. They are nearly unicorns.
When an engineer understands their job is to deliver value to the business as oppose to fussing over the pedantry of a specific style or framework or “perfect solution” or inventing problems that don’t exist. When they understand they can negotiate the deliverables to minimize time and maximize impact to the product while maintaining an extensible code base. That’s what makes an effective engineer. They are nearly unicorns.
Since this article starts with $$ values, I’m not sure if the effectiveness of engineers is even related. It has lots to do with the nature of the product and business. Yeah you could build crypto exchange or maybe Instagram with a dozen engineers, but good luck with that for more complex product like AWS, Tesla. The key IMO is a successful business can be technically simple to start with, but it could rarely stay simple for too long
The truth? A team player.
That’s the number one thing.
Primadonna? Not interested.
That’s the number one thing.
Primadonna? Not interested.
A team player who can do the work. "Team player", by itself, is not enough.
And, to be a team player, they have to be able to communicate technical information, reading, writing, and speaking.
And, to be a team player, they have to be able to communicate technical information, reading, writing, and speaking.
A) work together effectively with other engineers, scientists and team leaders;
B) define the problem being solved in detail (requirements) through thorough investigation and analysis;
C) devise a safe, cost-and-time efficient solution (design) that addresses a majority of the requirements using fundamental knowledge of math, science, logic and prior engineering solutions;
D) carefully estimate the cost, schedule and labor/expertise required to build the proposed solution;
D) document and articulate the design and cost/labor estimates for others to review, analyze, and provide feedback and expert opinions so the design may be improved and the cost/labor can be minimized;
E) build rapid prototypes for part or all of the design to reveal hidden requirements, flaws and/or potential design nuances that can be better understood by engineers and the customer;
F) devise a way to test the proposed solution so that all requirements can be demonstrated as complete;
G) build and/or manage the labor team required to build the solution with an eye for quality and maintenance of cost and schedule limits;
H) test and/or manage the testing of the as-built solution; and
I) be able to communicate effectively during the entire engineering process with the customer, other stakeholders and corporate management.
This is what is required to be an “engineer,” whether that be an electrical engineer, a mechanical engineer or a software engineer. Anyone not meeting these qualifications is a technician and not an engineer.