Engineers should invest in decision-making skills early
reforge.com
reforge.com
Strategy is the ultimate bikeshed: the prerequisites for having an opinion are very low, so everyone has one. Don't mistake avoidance of scapegoat duty for not having an opinion. Everyone has an opinion. Unfortunately, the evidence never unambiguously points to a single course of action and paying everyone to daydream and argue about the big picture is wildly inefficient, so the key to getting anything done is to delegate the decisions to a single person per team, give them time to cultivate big picture knowledge and political connections, and then to respect those decisions even if you privately disagree.
It would be awfully nice if that respect were reciprocated, but this article is an exercise in the polar opposite: it's a declaration that "management rules, labor drools," complete with a childish "descent into failure" diagram. Don't make the mistake of actually getting things done! You might out yourself as a stinky engineer and NEVER make it up into management! Mind the Peter Principle!
Maybe next week they can blogspam on how management compensation is about leveraged value creation, not Rules for Rulers.
In every project a thousand decisions are made by “drooling labor” and the better each of those decisions ladders up to the strategy the more meaningful the impact of the work.
Watching people proclaim no impact on strategy but thinking they deserve tons of credit for their code is a failure mode I’ve seen with engineers. Watching people get frustrated not being promoted when “idiot peers” get credit was often more about their own idiocy.
Don’t dismiss the impact you have in every role, it’ll hurt your career and the actual impact you have.
The article is pure "Management/Leadership Speak" nonsense complete with contrived/farfetched analogies and blaming of Engineering/Engineers for actually delivering something but which may have been "Strategically Wrong" because somebody else made that decision. Engineers are told to "Execute" and not "Strategize" (which means everything and nothing).
Given the responsibility, most Engineers are fully capable of Strategizing/Prioritizing/Executing on an Idea/Customer requirements so this insidious idea that Engineers are incapable of "Higher Managerial Functions" needs to die.
Complete these questionably specified tickets and when you are done, come back for more tickets.
Absolutely Wrong!
(I still prefer FOSS, but user-friendliness is not where it shines.)
Also, your original statement didn't say anything about FOSS:
> [...] most software engineers are bad at creating user-friendly products unless someone with product design skills tells them exactly what the UX should look like, [...]
The software engineers I've worked with want to make user-friendly software that meets needs. You know what usually gets in their way? They're not able to work with the end users to understand what the destination should be. They're fed streams (tides!) of loose feature requests with no apparent cohesion. What kind of software do you expect to get out of this process?
Garbage in, garbage out.
Every successful project I've been part of has required me to meet directly with the customer and understand what isn't working. Asking someone else to ask the customer for a specification just leads to the wrong solutions being solved or an endless stream of feature requests that make no sense in isolation.
Can you provide one example ?
because gnome is FOSS and I have heard complaint it's 'too simple'
and https://birchtree.me/blog/screwing-up-the-simplicity-of-it-a... : "Most people get maybe 2% of the potential of their Macs and Windows PCs today. Have you watched most people use a computer laterly? Most people I see have all apps in full screen all the time, no matter how big their screen is. Most people I see use keyboard shortcuts for copy and paste, opening new tabs, but basically nothing else. I've seen numer ous Mac users download apps, open the DMG, and run the app from the DMG forever because they don't know you should move it to the Applications folder. Many people have a desktop full of files because the desktop is the file system."
(and SAP and any Oracle Enterprise products...)
More generally I would cast the skill of decision making—while being creative—as this: it’s the ability to navigate a many dimensional design space.
Normal engineering has been reduced to a series of unidimensional logical decisions. This is my constraint…these are my material properties (or whatever) and I shall optimize for cost. Easy peasy. A computer could do it. This is the realm of building codes and strict industry standards.
But to be creative, you need to navigate a large search space of ideas. Every decision you take opens up new pathways and poses new challenges to solve. What is the best path through such a space? Copy someone else’s design and call yourself an innovator? Stick to first principles? Develop your intuition and then use it to guide your choices? Iterate often and fast? Being creative involves a completely different mindset for working a decision making…and I think it’s different because navigating a large dimensional idea space requires more than mere logic. This is what distinguishes creative people from mere mortals. And decision making in such a space has to be different too.
That was why the article was so interesting. One day there might be a mathematical way to define this problem and solution properly. Until then, like philosophers of old, they will have to resort to metaphor to explain what they have grasped with their minds. Some people will get it and some will not. But it’s not nonsense business-speak.
He called them the Sons of Martha and the sons of Mary.
The "Watershed Metaphor" doesn't make any sense at all. You can contrive anything and call it "Creativity"/"Philosophizing" etc. but that doesn't make it correct.
>the skill of decision making—while being creative—as this: it’s the ability to navigate a many dimensional design space
This is just a platitude and can mean anything and everything.
>Normal engineering has been reduced to a series of unidimensional logical decisions. This is my constraint…these are my material properties (or whatever) and I shall optimize for cost. Easy peasy. A computer could do it. This is the realm of building codes and strict industry standards.
WHAT ??? Nobody who knows the "Scientific Method" and has trained as an "Engineer" will ever agree with you. You are taking "one facet" of a specific Engineering Discipline and generalizing it to the whole Domain of "Engineering". This is a fundamental logical fallacy.
>But to be creative, you need to navigate a large search space of ideas. Every decision you take opens up new pathways and poses new challenges to solve. What is the best path through such a space? Copy someone else’s design and call yourself an innovator? Stick to first principles? Develop your intuition and then use it to guide your choices? Iterate often and fast? Being creative involves a completely different mindset for working a decision making…and I think it’s different because navigating a large dimensional idea space requires more than mere logic. This is what distinguishes creative people from mere mortals. And decision making in such a space has to be different too.
This is mere verbiage. See Baron's Thinking and Deciding for a detailed study of the relevant subjects.
>That was why the article was so interesting. One day there might be a mathematical way to define this problem and solution properly. Until then, like philosophers of old, they will have to resort to metaphor to explain what they have grasped with their minds. Some people will get it and some will not. But it’s not nonsense business-speak
You setup your own points and traced a path through it; means Nothing.
As an example
> WHAT ??? Nobody who knows the "Scientific Method" and has trained as an "Engineer" will ever agree with you. You are taking "one facet" of a specific Engineering Discipline and generalizing it to the whole Domain of "Engineering". This is a fundamental logical fallacy.
How is it a fundamental logical fallacy? Why are we making broad statements for the whole industry?
My above-quoted comment was in response to;
>> Normal engineering has been reduced to a series of unidimensional logical decisions. This is my constraint…these are my material properties (or whatever) and I shall optimize for cost. Easy peasy. A computer could do it. This is the realm of building codes and strict industry standards.
The fact that this is ludicrous should be self-evident to any "Scientifically Minded" person.
Trying to explain the "Why" would have to start at the Basics and would be too long. Instead i will list the relevant resources for further study;
- https://en.wikipedia.org/wiki/Fallacy_of_composition from https://en.wikipedia.org/wiki/List_of_fallacies
- https://en.wikipedia.org/wiki/Engineering#Methodology from https://en.wikipedia.org/wiki/Engineering
- https://en.wikipedia.org/wiki/Scientific_method#Elements_of_... from https://en.wikipedia.org/wiki/Scientific_method#Models_of_sc...
People don't generally sign up for an engineering role because they want to provide strategic direction to others. Such people exist, but are rare. There is a clear bias in Engineering disciplines towards people who really enjoy executing and don't particularly care what they execute.
And seconding the manager-speak angle. This article will be nearly useless to someone who doesn't already know how to identify and balance conflicting needs to make a decision. This is a rehash of the usual advice - take a step back, breath deeply and ask if what you are doing is leading to outcomes you value.
The problem with the article is that it tars the "Engineering Discipline" and practicing Engineers with the brush of implicit incompetence as if they are incapable of "looking at the big picture" and burying their Head in the sand. Nothing could be further from the Truth. The Complexity of the Problem/Solution demands that each of us focus only on our area of Specialized Expertise thus allowing the "Whole System" to be built from "Components". Analyze/Design Top-Down but Build Bottom-Up. Our "Modern World" is dependent on Technology all built by Scientists and Engineers.
PS: Take a look at the works of Jacques Ellul for a fascinating study of the relationship between Technology and Modern Society.
I've seen a lot of engineers and SREs (especially SREs!) get stuck in the execution mindset: get the job done, no matter what it takes.
Ultimately this leads to a situation where, instead of questioning why tools and platforms and processes suck, people apply shortcuts and workarounds without thinking about how they fit into the big picture. These workarounds accrete, eventually causing serious problems.
One example: a CD system has a very rigid definition of what an "environment" is, and it's not possible to run more than one version of a given software package simultaneously in an "environment" in order to do performance tests or canarying or things like that.
The "execution mindset" approach to that situation is to create new "environments" in order to just get the code deployed and close your ticket. Pretty soon the org ends up with dozens of these, some of which are only used by a single team, e.g. "prod" and "teamA-prod-sandbox" and "teamB-prod-perf-test." The "strategy mindset" approach is to say, hey, wait a minute, this "environment" design is not working well, people are hacking around it by creating new "environments," so let's fix that design so people don't need to do that anymore.
As much as many of us (myself included) are socially clueless, we do notice when people are annoyed with us and that is often when there is a problem (something SREs would need to deal with a lot if prod goes down).
I have binned a lot of improvement proposals simply to keep management happy and not having the desire to fight for the required time/resources. Half the time I might share it with a fellow rank and file dev for interest sake, but it dies there.
People like fire fighters. The fire inspector is broadly considered annoying.
I don't think it's a binary. I've also shelved a lot of proposals that I believed in, not because I didn't want to fight for them, but because a smart strategist picks and chooses their battles. Fight fires by all means, but use some of the capital you accumulate that way to point out and resolve the causes of future fires.
Good engineering orgs don't think that way. However it's also true that you need to build credibility and trust, and have some communication skills and an understanding of the larger picture, in order to act as a successful fire inspector.
Improvement work always has to be balanced against feature development, but if you can show that developer productivity and the reliability of the product are being impacted, good managers will tend to listen. (Conversely, if those things aren't impacted, then why is your suggestion important?) If they don't care, it's time to move on. Seriously: there has never been a better job market in software and if you aren't happy you should be looking for other jobs.
Every branch has its own full stack of services and dependencies dedicated to it; and it all gets torn down the moment the branch disappears.
There is a reason why people go for the workaround mindset and that is because they are just tiny cogs in a machine.
Even if you master data analysis skills (ie. as an analyst), which is completely different than what engineers are trained to do, this is only the "hard skills", which are the least important when it comes to management. Don't underestimate "soft skills" seen in many non-technical PMs. Keep yourself humble, keep learning - if you conquer both hard and soft skills, you are better guaranteed to succeed - evidenced by many ex-engineer CEOs in tech.
I don't agree with this in general. I've been forced into too many projects that were obviously bad from my perspective, but the Fearless Leader didn't care about anyone's input. I wasn't held accountable when those projects failed, but it was still depressing to have to do them.
I get the impression that corporate drones hate having to debate a decision, and they structure their organizations to absolutely minimize the need for it. But personally I enjoy a spirited debate -- one focused on the merits, and with rational, civil people.
I wish there was more deliberation in the workplace and less "do stupid things as fast as possible in the hopes that one of them will not be stupid". But there aren't enough people like me to sustain an organization, and that's why most orgs are top-down command-and-control hierarchies.
This is a common problem but there's something I'd call the Feynman solution, as he describes it in several of his lectures (New Zealand QED lecture I think). It's probably applicable to engineering problems as well as to scientific research.
Basically, you have to train yourself not to be emotionally tied to a particular outcome. In Feynman's case, he was talking about scientific theories about the nature of the universe, in the context of a question about whether he 'liked' quantum theory or not. As he put it, you don't get to tell nature how to behave, if you want to understand nature you're going to have to accept that some cherished theory or other that you wanted to be true is going to end up in the garbage bin of failed notions. A corollary is, have something else to get emotionally involved in, family, art, music, etc.
It seems the same with engineering of all sorts. Love that brilliant code you wrote, love that language you've spent all that time learning, love that system you spent a decade building, love those architectural blueprints you slaved over for six months? If it doesn't work for the problem at hand, it's best to toss it out the window and try something else, and getting emotional about it is a mistake. Equivalently, tossing something that works just because you have antipathy towards it for some reason is not the way to go.
Otherwise you end up like all those physicists who hated quantum mechanics so much that they either quit physics or spent decades of effort on futile attempts to refute it.
https://medium.com/starts-with-a-bang/einstein-schr%C3%B6din...
I am pretty good at this when I can work alone but once you have team members and have to justify things to management it gets increasingly hard.
They can't distinguish failing strategies from good ones, but they can see, and punish observed mistakes. With such management, admitting mistakes or justifying strategy changes can be a very stupid approach.
Emotional detachment to engineering solutions is one of the hallmark of the maturity of a senior engineer. Senior here means in general being separated from new and inexperienced engineers, not to particular title.
Then another level beyond senior is that engineers start to be able to have emotional attachment to engineering problems. It's like back to the beginning when someone is new and inexperienced. The difference is that the attachment now is about the joy of learning, instead of the frustration of feeling not be able to solve the problems easily.
Science is a collective endeavor that transcends any group boundaries. The objects of study are simple physical entities. They don't have dreams or goals and cannot be negotiated with.
People in corporations have a strong vested interest in being attached to goals that would help their own careers. People job hop so often it's easily possible that any concern shown for the good of the company isnt sincere. Nobody will come out and say - I built this solution and my promotion depends on it so we just go with this. Anyone savvy will learn to couch their interests in the language of collaboration and solidarity. Repeat this across hundreds of people at many different levels and you have the dysfunction that is typical to any large organization.
The only way to fix this is to work on culture and incentives. And it's a constant work in progress. At scale everything becomes about culture.
Even science isn't free of this hence the saying - "Science advances one funeral at a time".
Eventually this happens to companies too and hence we need a way for companies to die without taking down the world with them. Hence I would say - Capitalism advances one dead company at a time.
Thomas Kuhn would have something to say about that.
They did just the right thing trying to refute it. They did as much good as those who spent their time trying to prove it. That's how science works by trying to prove it and disprove it.
They didn't get the glory of being right but their work was very important to show that QM could not be proven wrong.
There is value in trying to prove something is wrong - and then there is also fighting against new ideas with institutional power.
I don’t think those were necessarily futile. No theory is as strong as one that has been assaulted relentlessly for years and still stands :)
Of course, there is a lot of hindsight at work here. If one of those physicists had succeeded in refuting quantum mechanics then we'd remember them as geniuses ahead of their time. I suspect that the practice of individual scientists in choosing which hypotheses to confirm or refute is highly irrational in general. It's just that we remember the people who guessed right (or who really did have some kind of deep insight – it's hard to tell).
We should all be leaders. Organizations would be so much more efficient. Stop wasting time on developing actual hard skills. That is soooo boooooring. Skip right up to being a CTO like me!
But how do you actually implement all that? You like the sound of it, you want it in you life, but where do you actually start? Good thing you asked: just buy our "cohort-based program"! We will teach you how to be a better engineer from our actual experience of never being one!
---
Let the second coming of dot-com crash wash away with a great flood this putrid decadence so we can rebuild anew.
Let the second coming of the dot-com crash bring salvation to us all :)
It’s “don’t worry your pretty little head”, “we need you spending time on this, not wasting it on that”, “you don’t have all the information”, “the best way to help is to be heads-down programming and let us do our job of strategy”.
All ways to keep you in your place. Fast forward ten years, and is it really surprising that a perfectly capable engineer wouldn’t succeed on the first shot?
Funny thing, give him six months of practice (often the current strategy people had far more) and surprise, he’s perfectly competent!
Bjarne Stroustrup - An Organisation that treats its Programmers as morons will soon have Programmers that are willing and able to act like morons only.
Note also that most successful Tech. Companies were Started/Managed/Grown by "Engineers" rather than MBA types (who just come in later to claim the glory :-)
Agile is taking all the fun out of software development. Turning engineers into software factory workers.
It’s a trope: the company that turned from the brink when management listened to staff, perhaps cutting out middle management as a comms layer, but its never been my experience that anyone wants to do that.
They’ll hear you but listen and take seriously?
How many companies deny tech debt paydown but then have people working on badly researched feature ideas that add no value to the business.
I often see the word “Strategy” thrown around, often referring to meaningless corporate speak or fluff. In fact, it’s a whole field of study, and I feel many engineers will love it if they gave it a chance.
In order to develop a strategy you must have a challenge or hard problem to solve. Then you define a cohesive set of actions or policies backed by an argument to solve the challenge. Strategy should define the “how” to solve the problem by clearly articulating the hard choices you have to make.
“Increase customer value”, or revenue or profits, those are not strategies. Being the best, or “leading”. Those are goals or wishes. Defining how to achieve that, given a whole set of constraints, that’s the heart of strategy. And engineers are generally great at solving those type of complex puzzles.
The solution is not one that may involve code or even engineering in general, but rather, a clear understanding of the problem, its constraints, and the argument for choosing some specific set of trade-offs.
Problem is: The only way to really understand a problem in engineering, is trying to engineer a solution for it.
I agree though, particularly in tech, the tendency is for great leaders to be deeply knowledgeable on engineering details because that is a requirement for a good strategy.
Nonetheless, in a broader sense, defining success for a business can create a solution space that extends well beyond engineering.
I am a coder. It is not my responsibility to sell our product, convince someone to see a demo, or do "market research" into what features we require.
"division of labour" exists for a reason. If I am supposed to be doing the job of the guys in suits&ties, in addition to be able to write, read and test code, then I have to ask the question why we should pay these guys in the first place.
Strategy is "the plan to win". An engineer's work is to execute the plan. It's like coaching the team vs playing the game. Engineers are the players, and the job of the player is to score the next goal. Executives (or Managers) are the coaches. The job of coaches is to win the game (and the season). These are not opposing goals, they are complimentary. Unfortunately, in the technology field, players and coaches are oftentimes at odds as though they have opposing goals.
The article makes a case for engineers who want to get into management, but haven't found a way to make that happen. Not every engineer wants to manage, even if that management is of technology rather than managing people. But for those engineers (players) who want to get into management (coaching) the case the article makes is this: players who want to coach must think like coaches.
One of the authors (Karen Sun) is the CTO of a tech company.
Also I had the chance of working with her (for her, really) and I can tell you that A) she's definitely an engineer and B) she knows her way around code and stuff.
"Early in our careers as engineers, we’re told to invest in technical skills."
Heavily founder type technical so I suspect that skews the advice in that direction, but still.
...and I'm not even sure if I agree, because it's quite hard to extract the actual point
Corporate-speak like that is a recipe for bad outcomes. What engineers need to learn is the same thing corporations need to learn but avoid - plain speaking.
See the Challenger O-ring disaster history for a case study.
Or am I misunderstanding what this means when plainly spoken?
Product/bizfuck person will re-think autocomplete, client-side rendering of results, want categories of results that don’t exist in the data, dynamism for each user that can’t exist given the data.
Developer wants to build search page like every other one so that we can get to market faster and move onto something that will actually affect the business.
Everyone has different priorities but the engineers are usually based in reality as we have to actually make the f’ing thing.
In large companies strategy is mostly about helping power brokers to do their bullshit jobs.
In my experience, only opportunity for engineers to contribute to a meaningful strategy is in a small team with business person as CEO/Owner and they really want to listen to the engineer's opinion.
Maybe in tech companies engineers might have different experience.
Of course they do!
At non-tech companies, tech is a cost center. The only strategy that will be valued is a strategy to cut costs.
At tech companies, tech is the product, so it's a profit center.
If you want a fulfilling career as an engineer, don't work in a cost center.
> In my experience, only opportunity for engineers to contribute to a meaningful strategy is in a small team with business person as CEO/Owner and they really want to listen to the engineer's opinion.
That might be true at very small companies. At large tech companies most engineers will never meet the CEO, but they still have input on strategy. Of course that means developing some credibility and trust within the organization before people will listen, but that's true in all industries.
You can definitely still have a fulfilling career. Somewhere along the ladder the right CTO or VP can make all the difference in how that branch of the organisation operates (and lo and behold, somehow that branch is particularly effective too).
By that definition, I guess the above article is not a help to a whole class of engineers out there. Now I really doubt if they even be called engineers?
Why and what are important, but they are limited in possibility by the how. How can sometimes allow people to rethink what they want, because they didn't even know they could have it. The why might not have existed before the how, think cryptocurrency, lots of people have why's and what about it now, but it all started from a how.
How is the equivalent of technological innovation and progress, that is a big enabler for opportunity in rethinking what and why.
This is why I much prefer executive leaders who have a good understanding of how, and might even have been an engineer themselves, because they can think through simulatanously about why, what and how in tandem.
Very well said!
This is why we do trial-and-error, proof-of-concept, prototyping etc. In general, you have to play with the "How" a little bit before the "Why" and "What" become clearer and you can nail them down as actual "Requirements". All three are interlinked and cannot be looked at in isolation.
If you're interested in expanding beyond a specialist (or just further your specialist experience), there are 3 main areas of business you should get experience in (note - I didn't say "learn").
Those are:
- strategy roles - these can vary, but it's really about making decisions on what direction a company should go
- operations/execution roles - actually putting a strategy into practice - this is where a lot of CS folks sit
- customer facing roles - doesn't have to be sales, but just some contact with customers
The reason I've found this to be a good approach is they are all mutually supporting roles. You can't be an outstanding strategy person if you've never executed (I know I vastly underestimate the effort involved), and you can't be a good technical person with getting close to the customer.
You don't have to love each role and it doesn't have to do it for long - even a 6 month internal rotation can help. But I think it does make you a better generalist (if that's what you want) because you start understanding your role from the bigger picture.
I have been a strategist since my very first engineering project, in 1987 (I can prove it, because I still have the manual). I've written software infrastructure that lasts decades, and I believe that a long-term, holistic, strategic approach is how I got there. Here's an example of one open-source project that I started[0], and that is now a world standard (but has been taken over and extended by a new team. I can't take credit for some of the awesome stuff they have done). You'll note that a strategic approach generally involves a great deal of compromise.
But I really like crafting software that individual people (as opposed to institutions, or other programs) use. My software does tend to be somewhat more ambitious than your run-of-the-mill software project, but it is still the kind of thing that lots of "Big Software" folks like to sneer at.
Sneer away, if that makes you feel good. People seem to like the stuff I write, and that makes me feel good.
Frankly, I will not be at the company long enough to have a strategic impact as I will have left in a few months. Solutioning keeps the day to day moving. It won't be my problem 10 months from now.
And with the endless churn on dev teams, you can't build a stable enough team to get beyond that. I wait to serve on a team that has less than a 50% replacement rate in a year.
So everyone (myself included) switches companies annually. In 2.5 years, I have had 6 (soon to be 7) different managers across three companies.
Lots of smart people involved and great to work with, but the incentives of this industry are for short fast tenures.
And an engineer has only a few chances (2-3) to get this early in their career.
Exactly! A company employs me to deliver on a specific set of primary responsibilities, everything else is secondary. While i of course can push for greater responsibilities/roles to play/grow, until and unless that has been officially acknowledged and agreed upon, the primary is what i need to unambiguously deliver on.
Why the hell are software articles inundated with these non-words? The proper word is SOLVING!
But tbh I have had only reasonable success this way and you have to be ok with pushback. And gets is harder if others around you make it a point to pushback - instead of seeing if your solution solves the problem and letting you own the solution for a period of time.
Merit gets you nowhere anymore.
Dunno if you are bay area. The blog article is mostly about SF, but his points about work culture might apply to the broader bay area. Maybe issues like safety and cleanliness are better in other parts. Practically, for younger folks, "American dream" has to be realized in the big cities and they all probably have a similar story to SF.
Weren't tech companies historically in the San Jose area ie "Silicon Valley"? SF is relatively new on the "tech" scene.
Also the blog author's moving to Miami, he's gonna coast at the beach.
Thoughts on getting another gig or contract work? There seems to be plenty of software work that can be done remotely. Maybe you can coast thru 2 jobs.
Also, I'm curious to see what everyone thinks of the "Examples of Decision by Role" RACI chart. How realistic is it? I don't expect the Junior IC to be making any of those decisions the authors wrote.
ah ah ah. It basically means you made what you think is a very good decision, it actually is pretty good indeed, but somehow it doesn't align with your own management's goals (those who decide for you). For example: you decided to build a good solution for the customer, that will avoid many issues in the futures but your managemetn says that you must have a positive cash flow right now; not in the future.
So you have to realign.
For me the issue is not about making good decisions. Anybody can make good decision provided he/she looks past the solution-oriented mind set. The skill that you need to develop is : defend your decision in front of people who actually totally disagree with you and have ways to make your life miserable if you go with your decision anyway. I understand somle people can do that, I sure can't.
Please God, No! :-)
Let it disappear along with this article.
People who fast track that step too much are not on a stable footing. You can probably sometimes get away with it, which is why we see the kind of "thought leadering" shared in the OP ... but I'll say that I'm "only" ~10 years in to my career and I've already seen quite a few instances of VP+ people who bet the farm on some nonsense and end up flaming out.
Read and Follow this instead: "Speech given by Dave Packard to HP Managers" - https://gizmodo.com/the-hp-way-how-bill-hewlett-and-i-built-... (they founded Silicon Valley).
It's not, at least most of the time, because people are unwilling to ask 'why', it's because in a lot of cases there is no neat strategizing step, disconnected and well ordered from what is actually going on in reality. In a large organization, things move all the time. There is uncertainty about who is where and doing what, you can plan something and when you're finished someone has already done something, there is imperfect information, and so on.
So if you want to strategize you first need to create time and resources to do so. It's the problem with all kind of grand strategy mentalities. What to do isn't clear most of the time, there is no guarantee to figure it out ahead of time, and things are asynchronous and not ordered. Executing quickly can be wasteful but it recognizes the real-time aspect of making decisions.
There’s always been an emphasis on the numbers that need to go up, in order to make the fundraising deck look good so that the company can keep existing; whilst focusing on the long term can often temporarily have a negative impact on numbers (or at least stall them), such that those accountable for those numbers will never sign off on it.
Yet these companies ended up as unicorns, so they’re at least doing _something_ right.
As an engineer, it's hard leave some things half baked, but it is what it is.
Say what you will about his snake oiliness but I got that from Tai Lopez and he's right. Prudence is a key skill and may trump almost every other skill.
But of course watch if the need to redesign/rebuild becomes a pattern. Then invest more time up ahead. But most times, a decent engineer is able to get to a fairly accurate and good solution.
"We got paged last night because of unexpected problem in System X and an associated config change in System Y meant our transitive dependency System Z did something we weren't expecting so our service went down." Ok fine but what can we fix? You can "strategize" as much as you like to fix the wider problem, but is that inside your team's sphere of influence?
If your strategy requires addressing the root-cause why, but that means you have to go change/replace other team's infrastructure/operational practices/etc ("we should change System X to use k8s, and then System Z is obsolete and we can refactor System Y to use NoSQL instead of poatgres then we will have solved the why"), it is unlikely to be something that is decided in your small team in reaction to a page.
TL;Dr - Your team of 5 or 6 is not the correct group to decide the overall strategy for changing your entire company's technical architecture.