Individual contributors don't avoid strategy out of stupidity, we do it out of respect for the person whose job it is.
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.
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.
It might be the article struggling to find the perfect frame, but what also stands out is the reason a lot of excellent executors get locked out of strategy decisions is that they don't want to be involved. It isn't a source of regrets.
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.
If this is what your job is encouraging then just wow. The engineers that I've seen be most productive are the ones pushing the design approaches and identifying gaps in the approach and tasks etc.
No, the authors of the article seem to be writing from personal experience and have used an interesting analogy to describe the solution in somewhat geometric terms (a “watershed”). If there were some mathematical way to describe the wiring of the neurons of someone making good decisions maybe they would have used that instead. Absent such a concept they resorted to metaphor instead. Such is the burden of philosophers.
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.
>No, the authors of the article seem to be writing from personal experience and have used an interesting analogy to describe the solution in somewhat geometric terms (a “watershed”). If there were some mathematical way to describe the wiring of the neurons of someone making good decisions maybe they would have used that instead. Absent such a concept they resorted to metaphor instead. Such is the burden of philosophers.
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.
> 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?
>> 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;
However, 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, or perhaps unless someone gives the engineers time to think about it.
>However, 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
Maybe the audience of FOSS is "self" and therefore I will obviously write something that matches my need.
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."
There are also no deeply invested customers for most FOSS development. It's not really surprising that most FOSS design feels aimless when the developers only need to meet (or aren't funded beyond) their own needs -- the bar is way lower. I don't think the mere existence of "managers" or "designers" is the critical factor.
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?
I think most software engineers are (in a way) glad that they don't have to talk to customers, and that there is someone in the middle. Managers and such are tolerated by developers for this reason.
The biggest problem with this stance is that far too often those middle-managers or other customer interfaces understand neither the customer's actual needs nor the programmer's needs.
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.
No, it's not. Nearly all Open Source software has terrible UX/UI with really questionable decisions regarding almost everything besides the technical aspects.
I actually liked the "Downward Strategy Spiral" diagram, which I think is the one you are referring to. It's one of the few things I liked about the article.
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.
Is that them not thinking of it or just realizing that anything that requires greater time investment will be a fight?
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.
> 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.
> People like fire fighters. The fire inspector is broadly considered annoying.
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.
The strategy mindset is impossible in large corporations because you don't have the power to change those things, and even if you did, it would become a project involving everyone and taking years.
There is a reason why people go for the workaround mindset and that is because they are just tiny cogs in a machine.
I think you are missing the point of the article, as an ex-engineer shifting to business and strategy, one key mental model change comes from focusing on the "hows" to the "whats and whys" - mentioned at the start of the article.
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.
Strategic thinking isn’t just the generative idea creation of a “strategy”. It’s also about savvy execution within a strategic context.
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.
Oh, absolutely. On both counts: strategic decisions that have been delegated to you are important to get right, and relentless self-promotion is the single most important skill inside and outside of any workplace. It's also important to recognize it for what it is, though, and TFA, well, is what it is.
> 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.
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.
i liked the water shedding idea because it is new to me. But otherwise, the blog makes me ask the question, so if engineers get trained early to focus on executing solutions who is training? Are you just blaming them on the degrees? But don't we know lots of graduates are not job-ready? The point here being there are systemic problems here. Just like there is with so many other issues and that's getting ignored.
> "Each person leads with their beliefs and emotions. . ."
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.
I think comparing people in groups who are competing for glory and promotions to idealistic scientists trying to find the truth of the universe isn't accurate.
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.
Well, Kuhn talks about two competing paradigms. In the corporate world, you have a large number of people with contrary interests--in other words, n-paradigms where n > 2.
“ 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.”
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.
That's the part they keep forgetting. Often, in the face of a management hierarchy, foolhardily perpetuating a failing approach (until team change) can be a better strategy than trial and error. This is not the fault of the ICs, but rather a problem with how deep management strategy goes (not deep at all) versus how deep management thinks it goes.
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.
> spent decades of effort on futile attempts to refute it.
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.
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.
>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.
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).
I had no idea there was physicists that quit the field. Does anyone know any articles or anything on this? Sounds interesting to read what their thoughts were.
I'm by no means a physics historian. I'm pretty sure quantum physics pissed off Einstein so much he spent the rest of his career trying to refute it. "God does not play dice with the universe". I'm just some jackass on the internet, so I'll leave it to Hawking to talk about emotional attachment to determinism https://www.hawking.org.uk/in-words/lectures/does-god-play-d...
Yes! My life would be so much better if my juniors would practice more strategic decision-making and help me understand how it can all be fixed if we moved to 10k micro-services in kubernetes.
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.
Ahhhh the utopian thought of an apocalypse in which all the entrenched interests (but not us engineers!) will magically disappear, after which we can rebuild in peace without all these concerns of 'backwards compatibility' and the demands of 'other stakeholders'.
Let the second coming of the dot-com crash bring salvation to us all :)
Not like that. But it will mature over crysis like all old industries. And of course engineers are not saints, we will get our wake up call as well. I did in 2008 for example.
I'm about a quarter of the way in, and this seems a pretty transparent "this is the contrived problem where engineers are basically idiots, and assuming that's always true, here's our solution." Most engineers I know are not idiots, and discussions would stay well away from personal attacks. Additionally, while they generally can identify wider issues, they also need to solve the current issue as a "strategic" solution is much more likely to become a talking shop or a "strategic"-level solution involving the spending of lots of budget, the purchase of something useless and then blaming the engineers when it doesn't work.
I feel like we have phrases in software like bikeshedding particularly because these sorts of problems are common in teams. It’s not about being idiots it’s about software being more art than science and these things just being hard and people wanting to treat it more like science than art.
In my experience, engineers are mostly told “make this” and denied the opportunity to exercise broader strategy decision making skills.
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 :-)
My biggest bugbear is higher ups don’t take gut feeling from people who have done engineering for decades seriously and so undermine their strategy with assumptions that could be corrected if they listened downward.
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.
There are also implications as to whose names should be on the ownership paperwork if everyone is all participating at a high level, which should be a constant reminder as to where the power is and is kept.
It is tthe agile mindset also which is contributing to the problem. Agile should only be used while executing, when you know all the requirements and just need to execute. Agile should not be used for R&D or when you are trying to come up woth a new thing. Of course time bound it, but it cannot be broken down intto user stories or whatnot.
Agile is taking all the fun out of software development. Turning engineers into software factory workers.
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.
Agreed. But the problem itself may not really be an engineering problem, and therefore a potential solution may exist outside.
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.
If it is not an engineering problem, then engineers should not be bothered with it, simple as that. Not because we cannot do it, but because we can do things others cannot. And these things take time and focus to do well. And without them, all the talking and planning and strategizing and wearing suits, becomes pointless, because there is no product to sell.
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.
Thanks for the link. I will check it out. I too see the word "strategy" thrown around without being well defined, and it should be clearly defined, especially for engineers who want to move into decision-making.
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.
This is an advice article for engineers written by two people who are not engineers. That's not necessarily bad, it's good to have outside perspective. But I didn't find the article particularly helpful. It makes some strange, vague analogies to watersheds and doesn't give much actionable advice. This article feels like an advertisement for this company's workshops or seminars.
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.
I'm sure she's very intelligent and is probably great at coding. All I meant by that comment is that she is not currently a software engineer by title, she is a CTO, and the stuff mentioned in the article may be more relevant to founders/CTOs.
Sorry, but being an engineer is different than knowing your way around "code and stuff". Being an engineer is also different than being a computer scientist or programmer. The authors studied arts and mathematics, but that didn't stop them from starting the post by making it look like its written by engineers:
"Early in our careers as engineers, we’re told to invest in technical skills."
> Crisply articulate and build alignment around your decision-making criteria
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.
The goal could be something as simple as, “design a search page.”
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.
Try strategizing in a mid-sized non technical mid-sized company. Here is where engineers are treated like mechanics at pep boys. You are either ignored or put to your place about the kind of work your are supposed to do, with the exception of crisis scenarios or 'no-one is interested in the outcome' scenarios.
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.
> 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.
> If you want a fulfilling career as an engineer, don't work in a cost center.
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).
>If you want a fulfilling career as an engineer, don't work in a cost center.
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?
The how is incredibly relevant when it comes to software engineering. If it doesn't matter, you don't have a real engineering problem.
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.
>Why and What are important, but they are limited in possibility by the How
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.
I got good career advice a while ago that the longer I work the more it makes sense.
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.
One of the nice things that has come out of being forced into early retirement (from a management role), is returning to my roots as a "sharp point" engineer; creating software, via compilers, linkers, testing, and delivery.
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.
Something wrong that I’ve done in my own career was to become the principal expert in company/industry specific technical details. My philosophy in education was always to steer to general engineering and business because of its wide applicability and my desire to understand the complete operation, and work at an executive level. Now I find myself with career ambitions that are seen as a negative at my current employer. They would find it difficult to replace my technical skills, so they prefer to keep me in my current role - where I’m most valuable. The thing that isn’t discussed in the article is that the most valuable employees are usually those making the technical contributions and housing the knowledge, which is why managers don’t want to move them. Unfortunately in business these employees are not compensated for their fair value or promoted because the management layers have their own incentives to find the best contributors possible at the lowest possible cost. In my case by doing the natural thing and learning all the details of my position and producing high quality work, I’ve made management hesitant to change my role.
A lot of this advice has to do with what role you play in a company. As a mid-level IC engineer, especially as one prone to moving companies, I have no strategic role.
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.
>A lot of this advice has to do with what role you play in a company.
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.
I have never been in a company that will give out raises, nor one with meaningful equity grants (we get equity, but it was 3K at my last company or nothing to deter switching jobs).
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.
A team where your manager takes an active interest in your career growth, protects the team from bullshit, and expects the same behavior from his/her manager.
This reads as mildly offensive. It isn't that people don't know of the myriad of "whats and whys". It's that they're resigned to not having any say in the matter. It makes me wonder if they applied their own framework to this particular problem.
As a software engineer I think you need a good balance of both. Strategy that never sees the light of day isn’t that good. Part of the great joy of the art of being a software engineer is putting your stuff out into the world and showing it.
One way to establish that expertise would be to execute and show the others that your advise/strategy is good. For that I think we have to execute fast. So we can build first, ask permission later. And if you build fast enough, then others won't question you as much.
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.
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.
Not in that area. Other than the safety and cleanliness the rest is pretty universal. Merit, hard work, etc has gotten be no where. I make under $100k and support a family. Coasting is not good in this situation, but I don't have any good options.
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.
Nah, I'll just do one. There are about 3-4 hours of meeting most days. If km going to go through that kind of stress or juggling, then I might as well try to find a good job.
This article is really hard to read and follow. Yet, there really isn't new insight (much of which I agree with) being presented here that I haven't seen elsewhere.
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.
FTA : "Realigning as necessary as you learn new things"
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.
Agile is much, much, less complicated paradigm and it has been turned into some Frankenstein of borrowed past processes at every company I've ever worked at. I can only imagine what would happen to this watershed model if it became popular.
This is interesting because it's what I suspect happens (Too much focus on execution creates skill/career stagnation), but I'm too early in my career to know for sure.
It depends what your career goals are. Repeated execution of non-trivial things in different contexts builds your engineering sense and intuition. Amazon has a quote, "there is no compression algorithm for experience".
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.
all the management speak and analogies about watersheds aside which I think obfuscate more than illuminate I think one fundamental problem with this sort of thinking is that it has a wrong opinion on why some people favour execution type mentalities.
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.
In most startups I’ve worked at, the engineers have for the most part been the ones yearning to work on more sustainable strategic solutions to problems, but it’s the pressure from the rest of the business to ship ASAP that forces everyone into a tactical execution mode.
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.
Whole heartedly agree. One metaphor I love is that a Ford Focus wins the race against a Ferrari every time if the Ford Focus has a better navigation system. If my goal is to go 1 mile due north but my compass points me due south I'm gonna spend all my time going around the whole globe. Prudence makes you more successful and your life easier.
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.
Engineers should avoid pursuing the perfect, most-generic, elegant solution. Spending too much time to decide the best tools, the right design pattern, etc. Coding is a lightweight process (compared to other forms of engineering). So it is easy to go back and rebuild and upgrade, which will be required in any case.
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.
In my experience the issue is that teams don't have influence beyond their team or sister teams.
"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.
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.