I've worked as an EM at four different companies, from large enterprises to small startups, and I think "the role of engineering manager" is a myth. Your role varies wildly from one company to another. In every company I've worked at, my job has never been the same:
In the end, engineering management basically requires you to counter-balance whichever of the four pillars your team needs most: Product, Process, People, and Programming.
- Too few people? You'll work on scope to make the deliverables meet reality. Since there's not much communication overhead, you'll be able to program.
- No PM? You now own the product pillar entirely. This takes a lot of your time: You'll need to validate features, prioritize the roadmap, and even talk directly with clients. None of the rest matters if your team is shipping features with no user value.
- Too many people in the team/company? Say goodbye to programming. You'll be responsible for careers, making everyone work cohesively, and navigating the org to get the right resources and support for your team.
- Reporting close to the CEO? You'll handle the bridge between sales, operations, client communications, and other functions.
The common thread is that your focus constantly shifts based on where your team's bottlenecks are. The key is identifying which pillar needs attention and adapting accordingly.
I feel like a lot of leadership positions are like this. I was a Principal Tech Lead at a 300 personal company and I did everything from PMing large tech teams, to collecting info from top users in spreadsheets, to building demos directly for the CEO, to building a key part of our tech used by over 100 other engineers.
I always told people I’d plunge the toilets myself if they were preventing the staff from working. I feel like the closer you get to top leadership the more your job becomes identifying and executing on whatever is highest value that you have the skills for.
> identifying and executing on whatever is highest value that you have the skills for
There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers shouldn't be engaged hands on. Apart from being incredibly hostile to their own interests (it will be central to you getting hired to any future role), it also impairs one of the most strategic aspects of the role which can drastically affect the value you can deliver internally in the future as well.
> but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects
This is an interesting myth, but certainly a myth. I guess if we consider technical skill to be intimate knowledge of the latest fad framework, that might be one source of the myth. But that's not technical skills, just trivia about an implementation detail.
The fundamentals like networking, process and memory management, databases and SQL, all change slowly and are very long-lived career-spanning knowledge.
Agreed, I haven’t seen this in my career at least. I’ve worked with contractors on a yearly basis who would take some time off and then hit the ground running.
If there’s any data supporting the opposite, I’d love to see it.
Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These were all born in the last few decades, so they are rather new, and they will stay for equally long decades. And the list goes on and on... So all of those skills in your list mean nothing when it comes to these fundamental technical tools. They require an understanding on a completely different abstraction level which is equally complex as of those that you listed.
So if you don't have the understanding of these technologies when the project requires it, you are obsolete and you have no right to be in a leading position. And such fundamental technologies are born continuously.
So this myth that you can have fundamentals and that's enough is definitely untrue.
> Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad.
These are indeed good examples of things that are merely tools, not fundamental knowledge.
Time-transport me an expert C programmer from the 80s and I'll have them productive in Go in two weeks. It's all very familiar territory.
O send me a mainframe programmer from the 60s and they'll be up to speed on kubernetes in short order. Pushing your workload to a remote cloud (mainframe) won't be exactly be new to them.
Databases have been studied and their properties understood for a very long time.
Sure, the exact details vary a bit and the command line options are different, but that's not significant.
Yeah, that sounds logical. Some of the most popular technologies of this time are just teeny-tiny tools, but some of long obsolete technologies and their attached skills which have no correlation to anything recent is somehow fundamental and has magical properties in your view :D Thanks for the good laugh!
> Databases have been studied and their properties understood for a very long time.
No they haven't. Noone ever considered schemaless databases or column-storage databases or vector databases for half a century after the birth of computing. So that kind of knowledge (relational DBs, etc in the 60s and 80s) meant nothing in light of these new technologies, and required completely different skills and knowledge.
But it's clear you are not familiar with these technologies, so it's a waste of time to engage with you now
If people think that not being hands-on for a year is unmanageable, then we as an industry are doing something horrifically wrong.
It would mean that no engineer could ever aspire to become a parent, take a sabbatical, further their education, or experiment with alternate career paths.
But I promise you that that is not actually the case. In fact, it is often the engineers who've stifled every other part of their life that are most likely to struggle in their mid-careers and beyond.
Yes, I don't mean actually taking time away - more organisationally, once you assume a role that is divorced from technical aspects and then try to come back to managing those without hands on experience. You will find that other more technically informed people rise up and start to become decision makers - you can't be authoritative any more and constantly have to ask someone else to give input on technical aspects since you aren't up to date with the current set of assumptions about it.
> I always told people I’d plunge the toilets myself if they were preventing the staff from working.
This is a lot closer to a literal interpretation of "shit rolls downhill, so a good manager will be a shit umbrella to protect their team" than I thought I'd ever see.
You have to be careful of the perceived politics around this. Tall poppies get cut down. I still don’t totally understand why but sometimes taking initiative doesn’t sit well with the folks who want their trains to run on time.
I think this varies from person-to-person or maybe organization-to-organization. I've definitely seen variations in the health of organizations but I think you can break up the categories used to judge them, e.g., meritocracy, overtime frequency, planning accuracy, psychological safety, value of work, etc.
I'd say the place I worked felt above average in meritocracy. In other words, it felt like folks sticking out to take initiative were more often rewarded than punished. I don't think we were perfect in every category though.
At least in small companies, my experience is that being adaptive like this applies to ICs as well as managers. Although to be fair the environment I'm thinking of doesn't have any full time managers.
I worry a lot about fads in engineering management. Any time you proscribe process over outcomes you create performative behavior and bad incentives in any discipline. In my observation, this tends to happen in engineering because senior leaders have no idea how to evaluate EMs in a non-performative way or as a knee-jerk to some broader cultural behavior. I think this is why you see many successful, seasoned EMs become political animals over time.
My suspicion about why this is the case is rooted in the responsibilities engineering shares with product and design at the management level. In an environment where very little unilateral decision making can be made by an EM, it is difficult to know if an outcome is because the EM is doing well or because of the people around them. I could be wrong, but once you look high enough in the org chart to no longer see trios, this problem recedes.
The author really got me thinking about the timeless aspects of the role underlying fads. I have certainly noticed shifts in management practice at companies over my career, but I choose to believe the underlying philosophy is timeless, like the relationship between day to day software engineering and computer science.
I worry about the future of the EM discipline. Every decade or so, it seems like there is a push to eliminate the function altogether, and no one can agree on the skillset. And yet like junior engineers, this should be the function that grows future leadership. I don't understand why there is so much disdain for it.
Process over Outcome is something that I think would be easy for anyone to proscribe to a process that they didn't like.
In my younger years, I was very cavalier about my approach to programming even at a larger company. I didn't particularly want to understand why I had to jump through so many hoops to access a production database to fix a problem or why there were so many steps to deploy to production.
Now that I more experienced, I fully understand all of those guardrails and as a manager my focus is on streamlining those guardrails as much as possible to get maximum benefit with minimum negative impact to the team solving problems.
But this involves a lot of process automation and tooling.
The problem imo tends to be not that there are guard rails in place. It's that they are often build by people that only care about the guard rail part and completely forget that its supposed to be last barrier and that there are other things you can do before you get people to hit a guardrail
What if teams were integrated groups of engineers, designers, and product people, managed by polymaths with at least some skill in all of these areas. In this case, do you think it would be easier to evaluate the team’s (and thus the manager’s) performance and then higher levels of management would care less about processes and management philosophy?
You're describing the GM (general manager) model, sometimes called the single threaded leader. This does work well in large scale organizations...especially ones where teams are built around projects and outcomes but exist for a finite time. Video game development tends to have this model.
I tend to believe in this model because when I've seen it in action, bad GMs are quickly identified and replaced for the betterment of the project.
It can be challenging to implement for a few reasons.
- It is difficult for a GM to performance manage across all disciplines. This model works best when you aren't interested in talent development.
- It's bad for functional consistency. GMs are focused on their own outcomes and can make the "ship your org chart" problem worse. It requires strong functional gatekeepers as a second-order discipline.
That's usually a consequence of bad incentives. Either leadership is selecting for that kind of behavior in managers or they don't know how to properly unselect for it.
If a bunch of crap code gets shipped, it isn't always because the engineers are bad. Often it's because they were given a bad deadline. Same with EMs.
There are components of management culture which are fads, like the idea that one could be an effective manager, while not understanding what one's reports are doing, through some management-foo learned from books and blogs.
The success of that fad is no doubt partially due to the economic climate.
People want the tech industry money, but don't have the tech industry skills.
Leadership is timeless, humans have always organized themselves in groups with leaders, and we instinctively play the part of leader or follower according to the situation.
Being a good leader just means allowing the group to accomplish something that would be less likely without one's guidance.
Being a good follower is mostly a selection role, where one exercises judgement in choosing a leader to follow.
The mechanism for dealing with bad leaders has also changed relatively little: stop giving them your own resources, and put distance between you and them.
In the workplace this is asking to switch to another team. You can dress it up with fake reasons, like you are interested in another project, or you aren't learning enough, whatever.
The important thing is that it takes a resource (you) away from a bad leader and gives it to a better one.
Iterate this process enough, and the incompetent leaders are outed through their inability to maintain personnel.
People don't do this enough, it's an easy way to signal to upper leadership who in management is bad at their job, without a direct accusation.
Yes. All leadership is supposed to be technical leadership. Outside of engineering-management, technical just means significant actual domain expertise. If you want an organization that can do stuff, you have to know stuff, there's just no substitute and everything else is basically fake. The "visionary", the "idea person", the experts at alignment / people / processes / ceremonies were always kind of mythical but to the extent they were ever real.. that kind of expertise tends to be removed in large orgs anyway because they are viewed as threatening by fakers who are better at maneuvering.
The fad is non-technical management, and the result is a general crisis in leadership that you can see everywhere across tech, politics, entertainment, whatever. Top leadership is out of ideas and just looking around for others to copy, or cruising on extraction/exploitation of value-creation that came before. It's a slow-motion disaster that's been picking up speed, which is why consumers, workers, and constituents are all pissed off. Seems like the shareholders will be effected soon, so then maybe it starts to change.
> Seems like the shareholders will be effected soon, so then maybe it starts to change.
With companies at least there is direct feedback via company performance - companies led by people who know what they are doing do better than those that aren't.
And well led companies tend to attract and retain more talent.
The feedback in politics is much much slower - in part because often the people you are voting for are not really the people setting policy - that's all done by the party machine ( 20 somethings with no real world experience working as advisors ) - so changing the 'leader' often doesn't make much of a difference.
ie one of the things that is really annoying the electorate is it's really difficult to actually vote in leaders or policies you want because of the way the party system works - leaders change yet everything stays the same.
I mean in the US - who really though Kamala was the best candidate to run against Trump?
Well, I can see your point, but this assumes that engineers only care about their career and or personal relationships. But I know that many engineers care deeply about a project's success and project goals enough to endure bad leadership for very very long times, because they know from experience that the average leader is mediocre, so switching teams or companies is a gamble, and not all life situations allow people to gamble with their lives.
One of the most important things about great performers in any discipline is to be adaptive. This also applies to engineering managers. I think the article is correct that it identifies that fads shifted. Great people were able to both adapt to new expectations while all the while adapting their approach to individual situations and people. If you are a one-trick pony sometimes your trick is in line with fads and expectations and you will do well. Sometimes it’s not in line and you will struggle. If you are adaptive you will do well in a changing landscape.
Only to the extent that a happy team delivers something of value. Teams can be happy doing things that will drive the company bankrupt. there is only so much unhappiness they can stand
If the incentives of the team (team happiness) and the company (delivery of something of value) are misaligned, that's a much higher level failure. Either the engineering manager has been handed the wrong team or assigned the wrong task to accomplish. Setting high level goals for the engineering managers and allocating resources for them to achieve those goals is the entire purpose of senior leadership.
Are you suggesting/implying that OpenAI lacks product-market fit?
I think they found a market for their product, making what they did valuable. That can still lose money for a time, and even maybe run out of money, but what they have is valuable to my mind.
If value can only be delivered by making a group of people miserable then maybe the definition of "value" is fundamentally wrong, like it was/is in the case of slavery.
Even outside the context of capitalism, society only functions when people perform unpleasant tasks which provide value. Nobody has fun collecting garbage, but it has to be done. Nobody finds happiness in digging graves, but it has to be done. Nobody is overjoyed at the prospect of telling a person they have a terminal illness, but it has to be done.
So no, I don't really buy the idea that a team which is "forced" to work on boring, but profitable tasks for a business instead of getting to rewrite core infrastructure in Rust as a fun and interesting intellectual exercise is equivalent to slavery.
> Nobody has fun collecting garbage, but it has to be done. Nobody finds happiness in digging graves, but it has to be done. Nobody is overjoyed at the prospect of telling a person they have a terminal illness, but it has to be done.
but we find ways to make the jobs of people who perform these tasks less horrific.
We makes trucks that reduce the physical toll and increase the cleanliness of garbage pickup, we combine the digging of graves with the maintenance and beautification once they have been buried, sometimes you have to tell someone they have a terminal illness, but the majority of the time you are helping someone get their condition into remission.
I think the critical balance that management has to achieve between "having a happy team" and "having a productive team" is finding ways to keep morale up so that employees don't lose their minds and quit or reduce performance doing the miserable stuff.
I wasn't referring to slavery. There are a number of cases where people are unhappy with their job, but go down the road to a competitor and everyone is happy. The industry/product are essentially the same, yet the happiness level is very different.
So I'm guessing most people are downvoting this as a knee jerk reaction to the comparison with slavery, but I think the core point is quite valid.
At some point, if people are unhappy working towards some goal, you gotta re-evaluate if the goal is worthy. I consistently meet people in other industries who really enjoy their job, whereas in tech, most of the people I know consider their job to be one of the lowlights of their life. And I don't think it's a stretch to say many, many tech jobs are not serving a worthy goal.
So it's disappointing to see people who can't look past "but business value bro", as if we got where we are because capitalism is some holy, inevitable universal law.
The question of leadership is much larger, more general, and more timeless than the last 15 years. I invite those curious about it to look into the American Army.
> Leadership is the process of influencing people by providing purpose,
direction, and motivation to accomplish the mission and improve the
organization.
The American army, the origin of the term "fragging." (to wit, making sure your commanding officer has a close, and final, encounter with a piece of ordnance, such as a frag grenade)
if we are to learn anything from the US military, it is twofold
1. You can absolutely create a self-reproducing tradition of absolute conformity while retaining ample capacity for local decisionmaking, if you have enough money and time. (In the case of the US army, approximately 150 years, and more money than any other organization in the history of man)
2. Segregating the staff into "officers" and "enlisted" is still gonna get a lot of "officers" killed dead, and even more "objectives" un-taken, because it spreads their incentives too far apart.
This is about software and management for software. But software developers have no engineering culture, they have a craftsmanship culture, favoring things like individualism and "taste". The article pretty clearly demonstrates this, as this is not how any actual engineering organization or any actual engineer thinks about management.
Software has something, which no engineering discipline has. Encapsulation. If you are building a car, a plane or a train everything affects everything. Management exists, for the sole reason of creating anything in such a world. What the corporation wants from an engineering manager, is someone who solves that communication problem, what the engineer wants from his manager is someone who figures out what is happening in the rest of the organization.
> Software has something, which no engineering discipline has. Encapsulation. If you are building a car, a plane or a train everything affects everything.
In other engineering disciplines, a lot of work goes into preventing everything from affecting everything. You overbuild a bridge so that you don't have to consider oscillation magnitudes (other than to conservatively figure out the maximum you need to support, and that maximum will be a worst case specifically so you don't need to consider the interaction of everything else.) Any time you're adding a safety margin, you're removing from consideration all of the things that could go wrong but not wrong enough to exceed the margin.
I think my takeaway from this is there is no objective standard for good engineering management - whatever counts for good has to be contextualized within the culture and habits of the organization.
Right, implementation od policy is equal to policy itself. If an org draws up a policy of maximized productivity with minimal staff, good is preventing turnover.
There is no absolute description of good leadership. But there is a relative one. It's about the degree of alignment with goals at the moment, at team level, and org level and being able to convince people about the achieved alignment.
Knowing what these goals are, is just as difficult or even harder, than achieving those goals. Most of these goals are not the ones that are written in big font.
I also hear that middle management is being cut from all companies. Some kind of management is necessary though, no? Otherwise people will get misaligned an all that. I'm not sure what is the point of the article. I guess a good manager doesn't need a bullet list to be able to function so why this person is writing a new one?
If you're talking about the relationship of engineering management with senior management, the most important "core skill," though I wouldn't really call it a skill, is alignment. Thing is, you won't get alignment without being closely aligned with product management, and if product management is weak, acting just as a features accountant, you're screwed no matter how good an engineering manager you are. You have no support to disagree with or shape senior management inputs. Everything else is nice and correct but not determinative the way that alignment will be.
I think you need to pair empathy with its counterpart, "willingness to be disliked." Empathy is great for building relationships but, taken alone, can make you a slave to doing whatever people want. Which stops working as soon as there are conflicting needs.
I've been thinking lately a lot about this. What is it I do when I want to convince someone of something (i.e. "creating alignment" in corporate speak)? I listen to them, am empathic, ask meaningful questions etc. Afterwards, that opens a space for me to make a proposal that is well-received.
It isn't good leadership/management that is a fad. What is a fad is what that looks like to the C-suite and how that is measured. There is no substitute for ability no matter how many management courses or frameworks you know. What is constant is the higher-ups ignoring this and going for the latest management philosophy.
> The conclusion here is clear: the industry will want different things from you as it evolves, and it will tell you that each of those shifts is because of some complex moral change, but it’s pretty much always about business realities changing. If you take any current morality tale as true, then you’re setting yourself up to be severely out of position when the industry shifts again in a few years, because “good leadership” is just a fad.
Institutional rhetoric at high levels is always meant to manipulate labor markets, financial markets, popular opinion. This is basic worldly-wisdom. The question is how does one (who is not at a high level) survive the recurring institutional changes? There seem to be two approaches to an answer: Do one's professional best regardless of change, or try to anticipate changes and adjust with the wind. For the first, gods may bless you, but it is folly to think your bosses will respect you. For the second -- good luck, you're running with bulls. Either way, the pill to swallow is that most employees including managers are grist to the mill.
It's generally a symbiotic relationship though, as the workers grow their own resume while helping their boss grow theirs (and generally the boss is growing his own while helping his boss grow theirs and so on. Sometimes it goes all the way up where even the founder just wants that lifestyle subsidized by investor money and does not care to actually ever build a profitable product).
This kind of perverse incentive comes up when the rank and file has no meaningful way to profit off the company's success, and so it instead becomes more profitable (in future profits from the inflated resume, or kickbacks/favors from vendors, etc) to act against the company. Just like in security bug bounties, companies should reward their employees more than an external malicious actor would, otherwise they will choose the rational option.
Really sharp reasoning. This can be reversed to define an extra ordinary manager: don't care about your head count and just be a fucking grown up who's emotional state does not depend on his team's performance. IMHO this results in having a high head count and a team performing pretty well. Kinda stoic wisdom. Go and figure...
> the pill to swallow is that most employees including managers are grist to the mill
Meaning that employees are disposable, and their only purpose is to produce value for the business.
Your reply:
> Businesses exist to make money. If you want a commune instead, join one!
Thus agreeing with the parent that the sole purpose of a business is to make money above all else.
My reply:
> That's not the only reason why businesses can exist.
Your reply:
> Tell us about a business that does not exist to make money.
This is rhetorical sleight-of-hand to change the counterpoint from "prove me wrong by showing me a business whose purpose is not to maximally exploit employees to maximize the amount of money it makes" to "prove me wrong by showing me a business that does not make money".
I could respond to the latter with an easy "some businesses lose money and exist because the owner finds the process fun", but you could counter with the No True Scotsman of "a business that doesn't make money is a hobby, not a business".
Instead, I will respond to the former, which is the original point, and say that there are plenty of mom-and-pop (or larger) businesses, as well as cooperatives, whose goals are not actually to exploit the worker to maximize the amount of money they make, but is primarily to give the owners a good work/life balance, or to help their community, or to be owned collectively by all workers.
The American-style "walk over anyone to make money" isn't actually the only way to do business, but the kind of person who thinks it is will generally make the tautological argument of "if you aren't maximizing your profits, you aren't a real business".
I know of no business that does not involve making money.
I know of many businesses for which making money is not the primary reason to exist. And the majority of businesses do not try to maximize profit at all costs, even when their primary reason for existence is to make money.
Random example: I know someone who teaches singing. She no longer employs other people, but has done so in the past. The IRS agrees that it is a business. She makes money from it and depends on the money from it. She has other skills that would earn her more money elsewhere. If her business made moderately more money but no longer taught anyone to sing better, she would stop running the business and do something else.
If you're going to say that the business's existence depends on the function of making money, as in if that purpose were removed then it would be called a hobby and not a business, then that's a No True Scotsman argument and it's pointless to discuss.
There's that strawman again. The rest of your argument depends on that, and so is invalid.
I know lots of people who started businesses with the intention of making money (including me). None of them were willing to go at it "at all costs". I don't know where you get this strawman.
It's from the post you replied to, from the part you quoted:
> the pill to swallow is that most employees including managers are grist to the mill
You can't pretend that this part of the conversation doesn't exist simply because you didn't write those words. You were replying to someone who very specifically said this, you were agreeing with them, and to then basically claim "oh I didn't write it, I merely heavily implied it by agreeing with the parent" is disingenuous.
Dammit, Walter, did you not read any of the very extensive comment? It was an entire treatise about why that exact line is misleading and in bad faith, and you reply with it anyway?
It's not at all in bad faith. Businesses are formed to make money. If the IRS discovers that your business is not intended to make money, they will re-define it as a "hobby" and will not let you deduct expenses.
Surely you can give an actual example of a business not formed to make money?
P.S. When you talk about bad faith, I recommend that you do not invent things I did not write, put those things in quotes pretending that I did write them, and then argue with that strawman.
Your answer seems in bad faith because it ignores parts of the answer like this:
> "Instead, I will respond to the former, which is the original point, and say that there are plenty of mom-and-pop (or larger) businesses, as well as cooperatives, whose goals are not actually to exploit the worker to maximize the amount of money they make, but is primarily to give the owners a good work/life balance, or to help their community, or to be owned collectively by all workers"
Those are not hobbies and will not be categorized as such.
The point is that the goal of making money is not necessarily meant at the cost of crushing employees or considering them disposable. The person you're replying to is saying that's a very US-centric way of looking at businesses (e.g. maximize shareholder value even if it costs happiness) but that's not necessarily the only way of making money. It's very cynical to think it's the only way, because it reinforces the status quo (what are you going to do if you don't like it? That's business, join a commune instead!).
> The point is that the goal of making money is not necessarily meant at the cost of crushing employees or considering them disposable.
I never wrote that it was.
But as an employee, you and the business sign a contract in advance. The contract spells out the obligations of the company to the employee, and the obligations of the employee to the company. If you expect more than that, negotiate it as part of your agreement.
Also, if the company does not make money, how are the employees going to get paid? The company has to cut expenses, and that means some of the employees have to be let go. Companies also regularly evaluate employees, and if they are not delivering value in excess of what they cost, they'll be let go.
Yes, you can be let go. You'll also get the severance package you agreed to in your employment contract. You can also quit at any time for any reason. It's a fair arrangement. It's not a marriage.
It's ridiculous to expect every single aspect of the employer-employee relationship spelled out in the contract. There are - or should be - certain societal expectations that the employer will not cause undue stress or unhappiness on the worker. This must not be negotiated in a cutthroat manner; that's such an American thing to expect (which was partly stavros point, I believe).
There are other ways to conduct business that are less exploitative without requiring a specific clause in the contract saying the employee will be treated well.
Companies lay off employees for all sorts of evil reasons unrelated to "we will go under otherwise". There's reason to believe the "great layoffs season" of a few years back was at least partly an act of collusion by big tech companies (which it then cascades to smaller companies) which had more to do with regulating down wages than with them risking going under.
Someone mentioned a few weeks back Nadella's memo explaining some big layoffs at Microsoft where he rambled about how it seemed contradictory that the company was doing so well yet they were letting go so many employees "which we've known and learned from for years" yet "the Lord works in mysterious ways" (ok, I made up this last phrase, but what he said amounted to the same). He failed to point out a single specific reason, and in particular he never mentioned "or else Microsoft's profits will go down" or whatever. I guess if Microsoft ex employees don't like it they can go join a commune!
P.S. as an example of how American this is, in some countries companies cannot simply let someone go unless they can provide legal reasons for this (bad performance beyond all fair chances, justified cost cuttings, etc). You can argue whether this is good or bad, but the point is: there is more than one way of conducting business.
> It's ridiculous to expect every single aspect of the employer-employee relationship spelled out in the contract.
It's not necessary to spell out in the contract what the legal requirements are.
The words "exploitative" and "treated well" are very fuzzy words, and everyone has a different idea of what they mean.
> for all sorts of evil reasons
Then the employee can press charges or sue.
> regulating down wages
How that works out in the real world is companies cheat on these cartels. Remember when Jobs complained that Google was violating their "no poaching" agreement? Cartels are unstable and unable to enforce their cartels, so they don't really work.
Nadella does not need to justify his layoffs. If they don't fit into Microsoft's plans, they get laid off. Microsoft does not owe them a job. BTW, I know many people who have left Microsoft for a panoply of reasons. Many went to other companies, many started their own, some succeeded, some didn't, some went back to Microsoft. It's a chaotic, dynamic system. I also know some that made incredible fortunes off of their stock options. How horrible that Microsoft minted tens of thousands of multimillionaires out of their employees! Some even into 9 figures. What a hell-hole! Microsoft is probably the worst example you could mention as an evil employer.
Dummy me that didn't get hired on by MSFT in the 1980s. Or I shoulda invested everything I had into MSFT stock. When I went to the doc for a catscan, I asked the operator to set the dial to 1987 so I could tell my foolish earlier self to buy buy buy MSFT! Sadly, the catscan machine had the side effect of wiping my memory of the trip.
> You can argue whether this is good or bad
It's bad, because it makes businesses highly reluctant to hire people, which makes the economy less prosperous.
Only if his goal is to make money at all costs, which is the stance you're taking even if you protest you are not.
> It's bad, because it makes businesses highly reluctant to hire people, which makes the economy less prosperous.
(I preempted your reply, because it wasn't the point to debate whether employee protection regulations are right or wrong; the point was to show you there are different ways of conducting a business that are not merely about making maximum money).
Again, this (and pretty much everything else you wrote in your last comment) is a very American way of doing business, precisely stavros' point.
Thankfully there are other, more respectful ways, as others have pointed out repeatedly and you insist in ignoring.
> How horrible that Microsoft minted tens of thousands of multimillionaires out of their employees!
Complete non sequitur, since you're so fond of calling out logical fallacies.
> Dummy me that didn't get hired on by MSFT in the 1980s
Yes, I'm sure you'd be a millionaire and would be spared arguing with random guys on HN. Life's a bitch.
> Surely you can give an actual example of a business not formed to make money?
Why? That was never claimed. The claim was that businesses can have other reasons for existing in addition to making money. Furthermore, those other reasons can be a higher priority for a particular business.
This implies that this is the primary reason businesses exist. Or did you mean "that's just one reason, it might even be very low on the list of reasons, but it is one"?
Because, if you meant that, I don't know why we're arguing about meaningless pedantry and conversational sleight of hand.
FWIW, I enjoyed and agree with your thoughtful comment, and found the response disappointing. Having known privately-owned mom-and-pop businesses, I can confirm not everyone is out for profit at all costs, even in America. For some, it's enough to make ends meet doing something you're passionate about.
> I can confirm not everyone is out for profit at all costs, even in America
Definitely, I didn't mean to imply that every business in the US wants to profit at all costs, I just meant that the culture skews towards that. The US culture towards work tends to have a certain response to cases like one where someone has a popular product/service/business but would rather maximize work/life balance than income.
In other cultures, that's seen as much more of a reasonable choice than in the US, where the response tends to be more on the "I can't believe you're giving up tons of profit for more free time!" or similar.
No offense taken, I totally get it. As an American, I think we're pretty screwed up in our priorities, on many fronts. I hope we all (globally) can figure out how to slow down and work less! Life's too short to spend so much time grinding for money.
You are arguing with "at all costs" which I never wrote, and so do not feel any need to reply to that.
Mom and pop businesses definitely do it to make money. They aren't charities. They pay taxes on the money they make. And if they don't make money, what are they going to live on?
Non-profits are not out to make money, but (again) they are not considered businesses.
Nobody argued pop & mom ("and larger") businesses don't strive to make money, the argument was that that's not their only goal.
We're arguing against your "at all costs" because you did imply it. Maximizing money earned at the cost of employees well being and happiness is ONE way of making money, but not the only way. You can earn money but not seek to maximize the money at the cost of burning out employees, for example.
Then you're arguing with yourself, because I never wrote "at all costs" nor did I imply it. It's your (rather ridiculous) strawman.
Consider I want to enter a marathon with the intention of winning it. Do you think that implies I want to club the other athletes so I can win "at all costs"?
But that's the kind of argument you're making by dismissing opinions that e.g. clubbing other athletes since winning is the most important thing is bad, and that if we don't like it we should "join a commune".
Others have already explained that while a business must make money, that's not always the most important thing, there are competing goals (not excluding money, but sometimes as important).
And if you didn't understand the original comment by stavros, then he clarified what he meant. So now you have the chance to stand corrected: he meant making money at the expense of all else, including worker happiness. This point has been made more than once already, you cannot have missed it.
> if you didn't understand the original comment by stavros, then he clarified what he meant
I understood his original statement, and did not impute additional meanings into it. None of you have accepted that I did not write "at any cost".
> clubbing other athletes since winning is the most important thing is bad, and that if we don't like it we should "join a commune".
And there you invented YET ANOTHER strawman to bash me with.
Frankly, I'd like you to produce a clever argument that challenges me. Using logical fallacies, like strawmen, is kinda boring. It's easy enough to google the list of logical fallacies, and then you'll be able to avoid them and it'll be much harder to dismantle your argument.
Yes, we all know the basic requirements of business.
The replies to your comment are push back against your attitude of "biz make money, don't like it join a commune", in the context of grinding up employees.
We're saying there's a middle ground, where some businesses will sacrifice some profit in exchange for taking care of their employees, instead of treating them as disposable.
Businesses exist to produce value for a society. In return, many societies provide ways for those businesses to profit. But this is outside the scope of the article or my comment on it. Profitable or unprofitable, business leaders today seem to impose chaos on their subordinates, and it can be difficult to know when and how to react.
I think there is this troika of "Leadership", "Management" and "Followship". You don't have to be an engineering manager to be a leader, and just because you are a leader doesn't mean you have any "followers". As someone who's been a team lead, a tech lead, an EM, and a C-level, I feel the goal is to hit that balance between those three. You want to embody a leader by actually being technically great, visionary, empathetic, and leading by example; but you also want to manage people and expectations; and ultimately you want people to follow you - to basically say "I love working for/with this person". Finding this triangulation is essentially what makes you timeless and relevant no matter the fad.
>Then think about our current era, that started in late 2022(...) We’ve flattened Engineering organizations where many roles that previously focused on coordination are now expected to be hands-on keyboard, working deep in the details
Is this everyone's experience nowadays? Personally I haven't experienced such a big shift at all.
Our C-suite is irrationally pushing AI-everything and eng culture is suffering a bit from not fully figuring out how to integrate new tooling safely, but nothing as fundamental as the mentioned changes are taking place so far.
Yes I’ve noticed this change acutely, working at a couple Series A YC startups. I’ve been surprised there haven’t been more articles on this topic because it’s been a miserable shift from my perspective, and I agree with the author that the root cause is the end of the ZIRP era.
Basically, in addition to the irrational AI-everything initiatives in spite of customers not wanting or using those features, as an engineer I’m being asked to basically run my own business unit doing everything from user interviews to product/design, engineering, QA, support, and reporting. There are no EMs anymore, everyone reports to the founders.
I think the author’s post could be boiled down to: in the ZIRP era the engineers had leverage and were treated well, and in the post-ZIRP era the tech companies have the leverage and are squeezing everything they can out of engineers to the point where you’re basically doing the job of a founder within someone else’s startup.
But is it universal for companies that aren't startups (or FAANG, where I hear they are also pushing for EMs to get their hands dirty or be fired -- or was that just Facebook)?
Like the comment you're replying to, I've also have NOT experienced this shift in EM skills. In my experience, they are still about making the team happy and productive, and definitely NOT coding or designing software (though I'll concede most seem technically minded and understand the details well enough to ask relevant questions and push back against bad takes).
But coding? Nope. EMs are still about the team, careers, hiring, alignment, etc.
C-levels forcing AI on everything, whether it makes sense or not, is definitely a symptom of the times.
this guy didn't write a blog post, he wrote the preface material for a training module to be sold to the least-competent HR execs he can find
it is generally a bad sign when you set out to taxonomize all possible productive behaviors. in this case, possibly a worse sign is that this guy has two "clusters" making up eight "foundational skills." for perspective, when Immanuel Kant set out to taxonomize all possible human experiences, he came back with four "clusters" of four "skills"
apparently engineering management encompasses the same complexity as half of all possible human experiences, from tabula rasa. good to know, i guess
(perhaps obviously, i did not read the essay any further than the introduction of "eight foundational skills" in "two clusters." at that point clearly I am being sold nonsense, and I feel free to stop reading and just poke fun at the author instead.)
And more broadly, goals/interests/skills can align really well with company needs and priorities at a time--and then they don't. You may be able to adapt but when the whole reason you were hired basically goes away, maybe it's not a great fit any longer.
This is a good article that is critical of narratives around behaviour within organisations. I particularly enjoyed his criticism of the 'morality tale'.
The author then postulates some guidance for how to survive in organisations more generally, working above these strange social structures largely unique to silicon valley. It wasn't the purpose of the article, but I wish he was a bit more critical of these structures in general.
I read more of the author's blog posts and it's actually insane to me that he not only was involved in one of the worst product deliveries in internet history (Digg v4), but he still justifies it somehow??
Presumably you're talking about this - https://lethain.com/digg-v4/ - "Digg's v4 launch: an optimism born of necessity"
Did you read the title of that post and not the actual content? Because it's a fantastic insider's war story about one of the most infamous product launches in our industry's history.
Here's the conclusion, which you can count as justification if you like but seems like a very interesting piece of insight to me:
> Digg V4 is sometimes referenced as an example of a catastrophic launch, with an implied lesson that we shouldn’t have launched it. At one point, I used to agree, but these days I think we made the right decision to launch. Our traffic was significantly down, we were losing a bunch of money each month, we had recently raised money and knew we couldn’t easily raise more. If we’d had the choice between launching something great and something awful, we’d have preferred to launch something great, but instead we had the choice of taking one last swing or turning in our bat quietly.
> I’m glad we took the last swing; proud we survived the rough launch.
> On the other hand, I’m still shocked that we were so reckless in the launch itself. I remember the meeting where we decided to go ahead with the launch, with Mike vigorously protesting. To the best of my recollection, I remained silent. I hope that I grew from the experience, because even now I’m uncertain how such a talented group put on that display of fuckery.
I can't imagine how reading that could make you think they were less rather than more credible as a source of information on engineering management!
This is like claiming that one of the North Korean nuclear scientists is credible on atomic bombs after theirs immediately fell into the ocean. Presiding over a disaster doesn't give you some magical insight on why you completely failed.
Make sure you get as far as the four core management skills and the four growth management skills, which are very clearly explained and make a ton of sense to me.
A manager’s job isn’t to guide the company, it’s to make sure his team does the tasks they are assigned. Likewise, a worker’s job isn’t to “think about the big picture” and come up with a strategy for the organization.
So who is supposed to do it? Because executives sure aren’t.
Disagree. Software development requires a lot of expert knowledge that executives won't and can't possess. If you're not employing that expert knowledge to benefit the company you're a part of, why are you even in the field?
Personally, I find a lot of appeal in having the expertise and influence to be more than a small cog, even when working as a generic staff engineer at the leaf level of my organization. I don't think there are many professions where that is possible, or at least nowhere where that degree of influence is near as feasible (apocryphal stories about janitors coming up with the next breakthrough product notwithstanding).
I've worked as an EM at four different companies, from large enterprises to small startups, and I think "the role of engineering manager" is a myth. Your role varies wildly from one company to another. In every company I've worked at, my job has never been the same:
In the end, engineering management basically requires you to counter-balance whichever of the four pillars your team needs most: Product, Process, People, and Programming.
- Too few people? You'll work on scope to make the deliverables meet reality. Since there's not much communication overhead, you'll be able to program.
- No PM? You now own the product pillar entirely. This takes a lot of your time: You'll need to validate features, prioritize the roadmap, and even talk directly with clients. None of the rest matters if your team is shipping features with no user value.
- Too many people in the team/company? Say goodbye to programming. You'll be responsible for careers, making everyone work cohesively, and navigating the org to get the right resources and support for your team.
- Reporting close to the CEO? You'll handle the bridge between sales, operations, client communications, and other functions.
The common thread is that your focus constantly shifts based on where your team's bottlenecks are. The key is identifying which pillar needs attention and adapting accordingly.
I feel like a lot of leadership positions are like this. I was a Principal Tech Lead at a 300 personal company and I did everything from PMing large tech teams, to collecting info from top users in spreadsheets, to building demos directly for the CEO, to building a key part of our tech used by over 100 other engineers.
I always told people I’d plunge the toilets myself if they were preventing the staff from working. I feel like the closer you get to top leadership the more your job becomes identifying and executing on whatever is highest value that you have the skills for.
> identifying and executing on whatever is highest value that you have the skills for
There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers shouldn't be engaged hands on. Apart from being incredibly hostile to their own interests (it will be central to you getting hired to any future role), it also impairs one of the most strategic aspects of the role which can drastically affect the value you can deliver internally in the future as well.
> but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects
This is an interesting myth, but certainly a myth. I guess if we consider technical skill to be intimate knowledge of the latest fad framework, that might be one source of the myth. But that's not technical skills, just trivia about an implementation detail.
The fundamentals like networking, process and memory management, databases and SQL, all change slowly and are very long-lived career-spanning knowledge.
Agreed, I haven’t seen this in my career at least. I’ve worked with contractors on a yearly basis who would take some time off and then hit the ground running.
If there’s any data supporting the opposite, I’d love to see it.
Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These were all born in the last few decades, so they are rather new, and they will stay for equally long decades. And the list goes on and on... So all of those skills in your list mean nothing when it comes to these fundamental technical tools. They require an understanding on a completely different abstraction level which is equally complex as of those that you listed.
So if you don't have the understanding of these technologies when the project requires it, you are obsolete and you have no right to be in a leading position. And such fundamental technologies are born continuously.
So this myth that you can have fundamentals and that's enough is definitely untrue.
> Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad.
These are indeed good examples of things that are merely tools, not fundamental knowledge.
Time-transport me an expert C programmer from the 80s and I'll have them productive in Go in two weeks. It's all very familiar territory.
O send me a mainframe programmer from the 60s and they'll be up to speed on kubernetes in short order. Pushing your workload to a remote cloud (mainframe) won't be exactly be new to them.
Databases have been studied and their properties understood for a very long time.
Sure, the exact details vary a bit and the command line options are different, but that's not significant.
Yeah, that sounds logical. Some of the most popular technologies of this time are just teeny-tiny tools, but some of long obsolete technologies and their attached skills which have no correlation to anything recent is somehow fundamental and has magical properties in your view :D Thanks for the good laugh!
> Databases have been studied and their properties understood for a very long time.
No they haven't. Noone ever considered schemaless databases or column-storage databases or vector databases for half a century after the birth of computing. So that kind of knowledge (relational DBs, etc in the 60s and 80s) meant nothing in light of these new technologies, and required completely different skills and knowledge.
But it's clear you are not familiar with these technologies, so it's a waste of time to engage with you now
If people think that not being hands-on for a year is unmanageable, then we as an industry are doing something horrifically wrong.
It would mean that no engineer could ever aspire to become a parent, take a sabbatical, further their education, or experiment with alternate career paths.
But I promise you that that is not actually the case. In fact, it is often the engineers who've stifled every other part of their life that are most likely to struggle in their mid-careers and beyond.
Yes, I don't mean actually taking time away - more organisationally, once you assume a role that is divorced from technical aspects and then try to come back to managing those without hands on experience. You will find that other more technically informed people rise up and start to become decision makers - you can't be authoritative any more and constantly have to ask someone else to give input on technical aspects since you aren't up to date with the current set of assumptions about it.
> I always told people I’d plunge the toilets myself if they were preventing the staff from working.
This is a lot closer to a literal interpretation of "shit rolls downhill, so a good manager will be a shit umbrella to protect their team" than I thought I'd ever see.
You have to be careful of the perceived politics around this. Tall poppies get cut down. I still don’t totally understand why but sometimes taking initiative doesn’t sit well with the folks who want their trains to run on time.
I think this varies from person-to-person or maybe organization-to-organization. I've definitely seen variations in the health of organizations but I think you can break up the categories used to judge them, e.g., meritocracy, overtime frequency, planning accuracy, psychological safety, value of work, etc.
I'd say the place I worked felt above average in meritocracy. In other words, it felt like folks sticking out to take initiative were more often rewarded than punished. I don't think we were perfect in every category though.
At least in small companies, my experience is that being adaptive like this applies to ICs as well as managers. Although to be fair the environment I'm thinking of doesn't have any full time managers.
Yeah, I think true. The smaller a company is the easier and more important it is to think and act holistically.
i found this comment to be more insightful than the article
I worry a lot about fads in engineering management. Any time you proscribe process over outcomes you create performative behavior and bad incentives in any discipline. In my observation, this tends to happen in engineering because senior leaders have no idea how to evaluate EMs in a non-performative way or as a knee-jerk to some broader cultural behavior. I think this is why you see many successful, seasoned EMs become political animals over time.
My suspicion about why this is the case is rooted in the responsibilities engineering shares with product and design at the management level. In an environment where very little unilateral decision making can be made by an EM, it is difficult to know if an outcome is because the EM is doing well or because of the people around them. I could be wrong, but once you look high enough in the org chart to no longer see trios, this problem recedes.
The author really got me thinking about the timeless aspects of the role underlying fads. I have certainly noticed shifts in management practice at companies over my career, but I choose to believe the underlying philosophy is timeless, like the relationship between day to day software engineering and computer science.
I worry about the future of the EM discipline. Every decade or so, it seems like there is a push to eliminate the function altogether, and no one can agree on the skillset. And yet like junior engineers, this should be the function that grows future leadership. I don't understand why there is so much disdain for it.
Process over Outcome is something that I think would be easy for anyone to proscribe to a process that they didn't like.
In my younger years, I was very cavalier about my approach to programming even at a larger company. I didn't particularly want to understand why I had to jump through so many hoops to access a production database to fix a problem or why there were so many steps to deploy to production.
Now that I more experienced, I fully understand all of those guardrails and as a manager my focus is on streamlining those guardrails as much as possible to get maximum benefit with minimum negative impact to the team solving problems.
But this involves a lot of process automation and tooling.
The problem imo tends to be not that there are guard rails in place. It's that they are often build by people that only care about the guard rail part and completely forget that its supposed to be last barrier and that there are other things you can do before you get people to hit a guardrail
I like your thinking about this problem.
What if teams were integrated groups of engineers, designers, and product people, managed by polymaths with at least some skill in all of these areas. In this case, do you think it would be easier to evaluate the team’s (and thus the manager’s) performance and then higher levels of management would care less about processes and management philosophy?
You're describing the GM (general manager) model, sometimes called the single threaded leader. This does work well in large scale organizations...especially ones where teams are built around projects and outcomes but exist for a finite time. Video game development tends to have this model.
I tend to believe in this model because when I've seen it in action, bad GMs are quickly identified and replaced for the betterment of the project.
It can be challenging to implement for a few reasons.
- It is difficult for a GM to performance manage across all disciplines. This model works best when you aren't interested in talent development.
- It's bad for functional consistency. GMs are focused on their own outcomes and can make the "ship your org chart" problem worse. It requires strong functional gatekeepers as a second-order discipline.
> I don't understand why there is so much disdain for it.
I do. It’s often done by people that become tyrants over their little fiefdom.
That's usually a consequence of bad incentives. Either leadership is selecting for that kind of behavior in managers or they don't know how to properly unselect for it.
If a bunch of crap code gets shipped, it isn't always because the engineers are bad. Often it's because they were given a bad deadline. Same with EMs.
There are components of management culture which are fads, like the idea that one could be an effective manager, while not understanding what one's reports are doing, through some management-foo learned from books and blogs. The success of that fad is no doubt partially due to the economic climate. People want the tech industry money, but don't have the tech industry skills.
Leadership is timeless, humans have always organized themselves in groups with leaders, and we instinctively play the part of leader or follower according to the situation. Being a good leader just means allowing the group to accomplish something that would be less likely without one's guidance. Being a good follower is mostly a selection role, where one exercises judgement in choosing a leader to follow.
The mechanism for dealing with bad leaders has also changed relatively little: stop giving them your own resources, and put distance between you and them. In the workplace this is asking to switch to another team. You can dress it up with fake reasons, like you are interested in another project, or you aren't learning enough, whatever. The important thing is that it takes a resource (you) away from a bad leader and gives it to a better one. Iterate this process enough, and the incompetent leaders are outed through their inability to maintain personnel.
People don't do this enough, it's an easy way to signal to upper leadership who in management is bad at their job, without a direct accusation.
Yes. All leadership is supposed to be technical leadership. Outside of engineering-management, technical just means significant actual domain expertise. If you want an organization that can do stuff, you have to know stuff, there's just no substitute and everything else is basically fake. The "visionary", the "idea person", the experts at alignment / people / processes / ceremonies were always kind of mythical but to the extent they were ever real.. that kind of expertise tends to be removed in large orgs anyway because they are viewed as threatening by fakers who are better at maneuvering.
The fad is non-technical management, and the result is a general crisis in leadership that you can see everywhere across tech, politics, entertainment, whatever. Top leadership is out of ideas and just looking around for others to copy, or cruising on extraction/exploitation of value-creation that came before. It's a slow-motion disaster that's been picking up speed, which is why consumers, workers, and constituents are all pissed off. Seems like the shareholders will be effected soon, so then maybe it starts to change.
This is probably one of the most cogent analysis/descriptions of this topic that I’ve read. Thank you.
> Seems like the shareholders will be effected soon, so then maybe it starts to change.
With companies at least there is direct feedback via company performance - companies led by people who know what they are doing do better than those that aren't.
And well led companies tend to attract and retain more talent.
The feedback in politics is much much slower - in part because often the people you are voting for are not really the people setting policy - that's all done by the party machine ( 20 somethings with no real world experience working as advisors ) - so changing the 'leader' often doesn't make much of a difference.
ie one of the things that is really annoying the electorate is it's really difficult to actually vote in leaders or policies you want because of the way the party system works - leaders change yet everything stays the same.
I mean in the US - who really though Kamala was the best candidate to run against Trump?
[dead]
Well, I can see your point, but this assumes that engineers only care about their career and or personal relationships. But I know that many engineers care deeply about a project's success and project goals enough to endure bad leadership for very very long times, because they know from experience that the average leader is mediocre, so switching teams or companies is a gamble, and not all life situations allow people to gamble with their lives.
One of the most important things about great performers in any discipline is to be adaptive. This also applies to engineering managers. I think the article is correct that it identifies that fads shifted. Great people were able to both adapt to new expectations while all the while adapting their approach to individual situations and people. If you are a one-trick pony sometimes your trick is in line with fads and expectations and you will do well. Sometimes it’s not in line and you will struggle. If you are adaptive you will do well in a changing landscape.
Sometimes the real deliverable is a happy team
Only to the extent that a happy team delivers something of value. Teams can be happy doing things that will drive the company bankrupt. there is only so much unhappiness they can stand
If the incentives of the team (team happiness) and the company (delivery of something of value) are misaligned, that's a much higher level failure. Either the engineering manager has been handed the wrong team or assigned the wrong task to accomplish. Setting high level goals for the engineering managers and allocating resources for them to achieve those goals is the entire purpose of senior leadership.
Not fun part is when team delivers good valuable stuff but market isn’t there.
What valuable stuff was delivered if the market isn’t there?
Whatever the sales department failed to create a market for.
It is always possible that dev team did all the code right, good product and still marketing failed or sales didn’t execute for plethora of reasons.
It may have been “good”, but I don’t see how it was “valuable”.
(I also think this is fairly common.)
Like OpenAI is losing money on each user - isn’t it valuable or is it?
If they close tomorrow because of lack of new funding would you say whatever they created wasn’t valuable?
Are you suggesting/implying that OpenAI lacks product-market fit?
I think they found a market for their product, making what they did valuable. That can still lose money for a time, and even maybe run out of money, but what they have is valuable to my mind.
If value can only be delivered by making a group of people miserable then maybe the definition of "value" is fundamentally wrong, like it was/is in the case of slavery.
Even outside the context of capitalism, society only functions when people perform unpleasant tasks which provide value. Nobody has fun collecting garbage, but it has to be done. Nobody finds happiness in digging graves, but it has to be done. Nobody is overjoyed at the prospect of telling a person they have a terminal illness, but it has to be done.
So no, I don't really buy the idea that a team which is "forced" to work on boring, but profitable tasks for a business instead of getting to rewrite core infrastructure in Rust as a fun and interesting intellectual exercise is equivalent to slavery.
> Nobody has fun collecting garbage, but it has to be done. Nobody finds happiness in digging graves, but it has to be done. Nobody is overjoyed at the prospect of telling a person they have a terminal illness, but it has to be done.
but we find ways to make the jobs of people who perform these tasks less horrific. We makes trucks that reduce the physical toll and increase the cleanliness of garbage pickup, we combine the digging of graves with the maintenance and beautification once they have been buried, sometimes you have to tell someone they have a terminal illness, but the majority of the time you are helping someone get their condition into remission.
I think the critical balance that management has to achieve between "having a happy team" and "having a productive team" is finding ways to keep morale up so that employees don't lose their minds and quit or reduce performance doing the miserable stuff.
I wasn't referring to slavery. There are a number of cases where people are unhappy with their job, but go down the road to a competitor and everyone is happy. The industry/product are essentially the same, yet the happiness level is very different.
Why misrepresent what someone else said to make your point?
So I'm guessing most people are downvoting this as a knee jerk reaction to the comparison with slavery, but I think the core point is quite valid.
At some point, if people are unhappy working towards some goal, you gotta re-evaluate if the goal is worthy. I consistently meet people in other industries who really enjoy their job, whereas in tech, most of the people I know consider their job to be one of the lowlights of their life. And I don't think it's a stretch to say many, many tech jobs are not serving a worthy goal.
So it's disappointing to see people who can't look past "but business value bro", as if we got where we are because capitalism is some holy, inevitable universal law.
The question of leadership is much larger, more general, and more timeless than the last 15 years. I invite those curious about it to look into the American Army.
> Leadership is the process of influencing people by providing purpose, direction, and motivation to accomplish the mission and improve the organization.
taken from -
-- https://www.eiu.edu/armyrotc/docs/adp6_22.pdf
The American army, the origin of the term "fragging." (to wit, making sure your commanding officer has a close, and final, encounter with a piece of ordnance, such as a frag grenade)
if we are to learn anything from the US military, it is twofold
1. You can absolutely create a self-reproducing tradition of absolute conformity while retaining ample capacity for local decisionmaking, if you have enough money and time. (In the case of the US army, approximately 150 years, and more money than any other organization in the history of man)
2. Segregating the staff into "officers" and "enlisted" is still gonna get a lot of "officers" killed dead, and even more "objectives" un-taken, because it spreads their incentives too far apart.
This is about software and management for software. But software developers have no engineering culture, they have a craftsmanship culture, favoring things like individualism and "taste". The article pretty clearly demonstrates this, as this is not how any actual engineering organization or any actual engineer thinks about management.
Software has something, which no engineering discipline has. Encapsulation. If you are building a car, a plane or a train everything affects everything. Management exists, for the sole reason of creating anything in such a world. What the corporation wants from an engineering manager, is someone who solves that communication problem, what the engineer wants from his manager is someone who figures out what is happening in the rest of the organization.
> Software has something, which no engineering discipline has. Encapsulation. If you are building a car, a plane or a train everything affects everything.
In other engineering disciplines, a lot of work goes into preventing everything from affecting everything. You overbuild a bridge so that you don't have to consider oscillation magnitudes (other than to conservatively figure out the maximum you need to support, and that maximum will be a worst case specifically so you don't need to consider the interaction of everything else.) Any time you're adding a safety margin, you're removing from consideration all of the things that could go wrong but not wrong enough to exceed the margin.
I think my takeaway from this is there is no objective standard for good engineering management - whatever counts for good has to be contextualized within the culture and habits of the organization.
> whatever counts for good has to be contextualized within the culture and habits of the organization
Within and outside the organization.
A "good" manager during a time of mass recruiting uses a very different skillset to a good manager during times of mass layoffs.
I suspect we won't really know what a good manager in the era of AI tools looks like for another 5 years or more.
Right, implementation od policy is equal to policy itself. If an org draws up a policy of maximized productivity with minimal staff, good is preventing turnover.
There is no absolute description of good leadership. But there is a relative one. It's about the degree of alignment with goals at the moment, at team level, and org level and being able to convince people about the achieved alignment.
Knowing what these goals are, is just as difficult or even harder, than achieving those goals. Most of these goals are not the ones that are written in big font.
I also hear that middle management is being cut from all companies. Some kind of management is necessary though, no? Otherwise people will get misaligned an all that. I'm not sure what is the point of the article. I guess a good manager doesn't need a bullet list to be able to function so why this person is writing a new one?
The article is giving me PTSD.
If you're talking about the relationship of engineering management with senior management, the most important "core skill," though I wouldn't really call it a skill, is alignment. Thing is, you won't get alignment without being closely aligned with product management, and if product management is weak, acting just as a features accountant, you're screwed no matter how good an engineering manager you are. You have no support to disagree with or shape senior management inputs. Everything else is nice and correct but not determinative the way that alignment will be.
Every skill eventually boils down to empathy, alignment is just being empathic
I think you need to pair empathy with its counterpart, "willingness to be disliked." Empathy is great for building relationships but, taken alone, can make you a slave to doing whatever people want. Which stops working as soon as there are conflicting needs.
I've been thinking lately a lot about this. What is it I do when I want to convince someone of something (i.e. "creating alignment" in corporate speak)? I listen to them, am empathic, ask meaningful questions etc. Afterwards, that opens a space for me to make a proposal that is well-received.
I completely agree with you.
I also completely disagree with you. I’ve watched people scream at a room until they got their way. It was awful.
It isn't good leadership/management that is a fad. What is a fad is what that looks like to the C-suite and how that is measured. There is no substitute for ability no matter how many management courses or frameworks you know. What is constant is the higher-ups ignoring this and going for the latest management philosophy.
> The conclusion here is clear: the industry will want different things from you as it evolves, and it will tell you that each of those shifts is because of some complex moral change, but it’s pretty much always about business realities changing. If you take any current morality tale as true, then you’re setting yourself up to be severely out of position when the industry shifts again in a few years, because “good leadership” is just a fad.
Institutional rhetoric at high levels is always meant to manipulate labor markets, financial markets, popular opinion. This is basic worldly-wisdom. The question is how does one (who is not at a high level) survive the recurring institutional changes? There seem to be two approaches to an answer: Do one's professional best regardless of change, or try to anticipate changes and adjust with the wind. For the first, gods may bless you, but it is folly to think your bosses will respect you. For the second -- good luck, you're running with bulls. Either way, the pill to swallow is that most employees including managers are grist to the mill.
> the pill to swallow is that most employees including managers are grist to the mill
Businesses exist to make money. If you want a commune instead, join one!
For many workers, working towards the goal of making the company profitable would be an improvement.
Many workers primarily work towards helping the boss grow their head count, or helping the middle-manager with their emotional state.
It's generally a symbiotic relationship though, as the workers grow their own resume while helping their boss grow theirs (and generally the boss is growing his own while helping his boss grow theirs and so on. Sometimes it goes all the way up where even the founder just wants that lifestyle subsidized by investor money and does not care to actually ever build a profitable product).
This kind of perverse incentive comes up when the rank and file has no meaningful way to profit off the company's success, and so it instead becomes more profitable (in future profits from the inflated resume, or kickbacks/favors from vendors, etc) to act against the company. Just like in security bug bounties, companies should reward their employees more than an external malicious actor would, otherwise they will choose the rational option.
> helping the middle-manager with their emotional state.
Hah, this is hilarious. So very "The Office".
Really sharp reasoning. This can be reversed to define an extra ordinary manager: don't care about your head count and just be a fucking grown up who's emotional state does not depend on his team's performance. IMHO this results in having a high head count and a team performing pretty well. Kinda stoic wisdom. Go and figure...
That's not the only reason why businesses can exist. It's the most common reason in US culture, but there are other reasons and cultures.
Tell us about a business that does not exist to make money.
First post:
> the pill to swallow is that most employees including managers are grist to the mill
Meaning that employees are disposable, and their only purpose is to produce value for the business.
Your reply:
> Businesses exist to make money. If you want a commune instead, join one!
Thus agreeing with the parent that the sole purpose of a business is to make money above all else.
My reply:
> That's not the only reason why businesses can exist.
Your reply:
> Tell us about a business that does not exist to make money.
This is rhetorical sleight-of-hand to change the counterpoint from "prove me wrong by showing me a business whose purpose is not to maximally exploit employees to maximize the amount of money it makes" to "prove me wrong by showing me a business that does not make money".
I could respond to the latter with an easy "some businesses lose money and exist because the owner finds the process fun", but you could counter with the No True Scotsman of "a business that doesn't make money is a hobby, not a business".
Instead, I will respond to the former, which is the original point, and say that there are plenty of mom-and-pop (or larger) businesses, as well as cooperatives, whose goals are not actually to exploit the worker to maximize the amount of money they make, but is primarily to give the owners a good work/life balance, or to help their community, or to be owned collectively by all workers.
The American-style "walk over anyone to make money" isn't actually the only way to do business, but the kind of person who thinks it is will generally make the tautological argument of "if you aren't maximizing your profits, you aren't a real business".
I infer you don't know of any particular business that does not exist to make money?
If you run a business that loses money, who is going to pay for those losses?
I know of no business that does not involve making money.
I know of many businesses for which making money is not the primary reason to exist. And the majority of businesses do not try to maximize profit at all costs, even when their primary reason for existence is to make money.
Random example: I know someone who teaches singing. She no longer employs other people, but has done so in the past. The IRS agrees that it is a business. She makes money from it and depends on the money from it. She has other skills that would earn her more money elsewhere. If her business made moderately more money but no longer taught anyone to sing better, she would stop running the business and do something else.
If you're going to say that the business's existence depends on the function of making money, as in if that purpose were removed then it would be called a hobby and not a business, then that's a No True Scotsman argument and it's pointless to discuss.
(Basically, I'm with stavros on this.)
> at all costs
There's that strawman again. The rest of your argument depends on that, and so is invalid.
I know lots of people who started businesses with the intention of making money (including me). None of them were willing to go at it "at all costs". I don't know where you get this strawman.
It's from the post you replied to, from the part you quoted:
> the pill to swallow is that most employees including managers are grist to the mill
You can't pretend that this part of the conversation doesn't exist simply because you didn't write those words. You were replying to someone who very specifically said this, you were agreeing with them, and to then basically claim "oh I didn't write it, I merely heavily implied it by agreeing with the parent" is disingenuous.
Dammit, Walter, did you not read any of the very extensive comment? It was an entire treatise about why that exact line is misleading and in bad faith, and you reply with it anyway?
It's not at all in bad faith. Businesses are formed to make money. If the IRS discovers that your business is not intended to make money, they will re-define it as a "hobby" and will not let you deduct expenses.
Surely you can give an actual example of a business not formed to make money?
P.S. When you talk about bad faith, I recommend that you do not invent things I did not write, put those things in quotes pretending that I did write them, and then argue with that strawman.
Your answer seems in bad faith because it ignores parts of the answer like this:
> "Instead, I will respond to the former, which is the original point, and say that there are plenty of mom-and-pop (or larger) businesses, as well as cooperatives, whose goals are not actually to exploit the worker to maximize the amount of money they make, but is primarily to give the owners a good work/life balance, or to help their community, or to be owned collectively by all workers"
Those are not hobbies and will not be categorized as such.
The point is that the goal of making money is not necessarily meant at the cost of crushing employees or considering them disposable. The person you're replying to is saying that's a very US-centric way of looking at businesses (e.g. maximize shareholder value even if it costs happiness) but that's not necessarily the only way of making money. It's very cynical to think it's the only way, because it reinforces the status quo (what are you going to do if you don't like it? That's business, join a commune instead!).
> The point is that the goal of making money is not necessarily meant at the cost of crushing employees or considering them disposable.
I never wrote that it was.
But as an employee, you and the business sign a contract in advance. The contract spells out the obligations of the company to the employee, and the obligations of the employee to the company. If you expect more than that, negotiate it as part of your agreement.
Also, if the company does not make money, how are the employees going to get paid? The company has to cut expenses, and that means some of the employees have to be let go. Companies also regularly evaluate employees, and if they are not delivering value in excess of what they cost, they'll be let go.
Yes, you can be let go. You'll also get the severance package you agreed to in your employment contract. You can also quit at any time for any reason. It's a fair arrangement. It's not a marriage.
It's ridiculous to expect every single aspect of the employer-employee relationship spelled out in the contract. There are - or should be - certain societal expectations that the employer will not cause undue stress or unhappiness on the worker. This must not be negotiated in a cutthroat manner; that's such an American thing to expect (which was partly stavros point, I believe).
There are other ways to conduct business that are less exploitative without requiring a specific clause in the contract saying the employee will be treated well.
Companies lay off employees for all sorts of evil reasons unrelated to "we will go under otherwise". There's reason to believe the "great layoffs season" of a few years back was at least partly an act of collusion by big tech companies (which it then cascades to smaller companies) which had more to do with regulating down wages than with them risking going under.
Someone mentioned a few weeks back Nadella's memo explaining some big layoffs at Microsoft where he rambled about how it seemed contradictory that the company was doing so well yet they were letting go so many employees "which we've known and learned from for years" yet "the Lord works in mysterious ways" (ok, I made up this last phrase, but what he said amounted to the same). He failed to point out a single specific reason, and in particular he never mentioned "or else Microsoft's profits will go down" or whatever. I guess if Microsoft ex employees don't like it they can go join a commune!
P.S. as an example of how American this is, in some countries companies cannot simply let someone go unless they can provide legal reasons for this (bad performance beyond all fair chances, justified cost cuttings, etc). You can argue whether this is good or bad, but the point is: there is more than one way of conducting business.
> It's ridiculous to expect every single aspect of the employer-employee relationship spelled out in the contract.
It's not necessary to spell out in the contract what the legal requirements are.
The words "exploitative" and "treated well" are very fuzzy words, and everyone has a different idea of what they mean.
> for all sorts of evil reasons
Then the employee can press charges or sue.
> regulating down wages
How that works out in the real world is companies cheat on these cartels. Remember when Jobs complained that Google was violating their "no poaching" agreement? Cartels are unstable and unable to enforce their cartels, so they don't really work.
Nadella does not need to justify his layoffs. If they don't fit into Microsoft's plans, they get laid off. Microsoft does not owe them a job. BTW, I know many people who have left Microsoft for a panoply of reasons. Many went to other companies, many started their own, some succeeded, some didn't, some went back to Microsoft. It's a chaotic, dynamic system. I also know some that made incredible fortunes off of their stock options. How horrible that Microsoft minted tens of thousands of multimillionaires out of their employees! Some even into 9 figures. What a hell-hole! Microsoft is probably the worst example you could mention as an evil employer.
Dummy me that didn't get hired on by MSFT in the 1980s. Or I shoulda invested everything I had into MSFT stock. When I went to the doc for a catscan, I asked the operator to set the dial to 1987 so I could tell my foolish earlier self to buy buy buy MSFT! Sadly, the catscan machine had the side effect of wiping my memory of the trip.
> You can argue whether this is good or bad
It's bad, because it makes businesses highly reluctant to hire people, which makes the economy less prosperous.
> Nadella does not need to justify his layoffs.
Only if his goal is to make money at all costs, which is the stance you're taking even if you protest you are not.
> It's bad, because it makes businesses highly reluctant to hire people, which makes the economy less prosperous.
(I preempted your reply, because it wasn't the point to debate whether employee protection regulations are right or wrong; the point was to show you there are different ways of conducting a business that are not merely about making maximum money).
Again, this (and pretty much everything else you wrote in your last comment) is a very American way of doing business, precisely stavros' point.
Thankfully there are other, more respectful ways, as others have pointed out repeatedly and you insist in ignoring.
> How horrible that Microsoft minted tens of thousands of multimillionaires out of their employees!
Complete non sequitur, since you're so fond of calling out logical fallacies.
> Dummy me that didn't get hired on by MSFT in the 1980s
Yes, I'm sure you'd be a millionaire and would be spared arguing with random guys on HN. Life's a bitch.
> Surely you can give an actual example of a business not formed to make money?
Why? That was never claimed. The claim was that businesses can have other reasons for existing in addition to making money. Furthermore, those other reasons can be a higher priority for a particular business.
You didn't write "in addition" in what I responded to.
> Businesses exist to make money
This implies that this is the primary reason businesses exist. Or did you mean "that's just one reason, it might even be very low on the list of reasons, but it is one"?
Because, if you meant that, I don't know why we're arguing about meaningless pedantry and conversational sleight of hand.
FWIW, I enjoyed and agree with your thoughtful comment, and found the response disappointing. Having known privately-owned mom-and-pop businesses, I can confirm not everyone is out for profit at all costs, even in America. For some, it's enough to make ends meet doing something you're passionate about.
> I can confirm not everyone is out for profit at all costs, even in America
Definitely, I didn't mean to imply that every business in the US wants to profit at all costs, I just meant that the culture skews towards that. The US culture towards work tends to have a certain response to cases like one where someone has a popular product/service/business but would rather maximize work/life balance than income.
In other cultures, that's seen as much more of a reasonable choice than in the US, where the response tends to be more on the "I can't believe you're giving up tons of profit for more free time!" or similar.
No offense taken, I totally get it. As an American, I think we're pretty screwed up in our priorities, on many fronts. I hope we all (globally) can figure out how to slow down and work less! Life's too short to spend so much time grinding for money.
You are arguing with "at all costs" which I never wrote, and so do not feel any need to reply to that.
Mom and pop businesses definitely do it to make money. They aren't charities. They pay taxes on the money they make. And if they don't make money, what are they going to live on?
Non-profits are not out to make money, but (again) they are not considered businesses.
Nobody argued pop & mom ("and larger") businesses don't strive to make money, the argument was that that's not their only goal.
We're arguing against your "at all costs" because you did imply it. Maximizing money earned at the cost of employees well being and happiness is ONE way of making money, but not the only way. You can earn money but not seek to maximize the money at the cost of burning out employees, for example.
Then you're arguing with yourself, because I never wrote "at all costs" nor did I imply it. It's your (rather ridiculous) strawman.
Consider I want to enter a marathon with the intention of winning it. Do you think that implies I want to club the other athletes so I can win "at all costs"?
But that's the kind of argument you're making by dismissing opinions that e.g. clubbing other athletes since winning is the most important thing is bad, and that if we don't like it we should "join a commune".
Others have already explained that while a business must make money, that's not always the most important thing, there are competing goals (not excluding money, but sometimes as important).
And if you didn't understand the original comment by stavros, then he clarified what he meant. So now you have the chance to stand corrected: he meant making money at the expense of all else, including worker happiness. This point has been made more than once already, you cannot have missed it.
> if you didn't understand the original comment by stavros, then he clarified what he meant
I understood his original statement, and did not impute additional meanings into it. None of you have accepted that I did not write "at any cost".
> clubbing other athletes since winning is the most important thing is bad, and that if we don't like it we should "join a commune".
And there you invented YET ANOTHER strawman to bash me with.
Frankly, I'd like you to produce a clever argument that challenges me. Using logical fallacies, like strawmen, is kinda boring. It's easy enough to google the list of logical fallacies, and then you'll be able to avoid them and it'll be much harder to dismantle your argument.
Yes, we all know the basic requirements of business.
The replies to your comment are push back against your attitude of "biz make money, don't like it join a commune", in the context of grinding up employees.
We're saying there's a middle ground, where some businesses will sacrifice some profit in exchange for taking care of their employees, instead of treating them as disposable.
Businesses exist to produce value for a society. In return, many societies provide ways for those businesses to profit. But this is outside the scope of the article or my comment on it. Profitable or unprofitable, business leaders today seem to impose chaos on their subordinates, and it can be difficult to know when and how to react.
Well, that is just the problem, isn't it?
A lot of the bad behavior in corporate America comes from signalling (for above) and posturing (for below), not from finding ways to make money
(Communes often have the same signalling and posturing problems, but they don't have to additionally worry about shareholders and bonus payments)
I think there is this troika of "Leadership", "Management" and "Followship". You don't have to be an engineering manager to be a leader, and just because you are a leader doesn't mean you have any "followers". As someone who's been a team lead, a tech lead, an EM, and a C-level, I feel the goal is to hit that balance between those three. You want to embody a leader by actually being technically great, visionary, empathetic, and leading by example; but you also want to manage people and expectations; and ultimately you want people to follow you - to basically say "I love working for/with this person". Finding this triangulation is essentially what makes you timeless and relevant no matter the fad.
>Then think about our current era, that started in late 2022(...) We’ve flattened Engineering organizations where many roles that previously focused on coordination are now expected to be hands-on keyboard, working deep in the details
Is this everyone's experience nowadays? Personally I haven't experienced such a big shift at all.
Our C-suite is irrationally pushing AI-everything and eng culture is suffering a bit from not fully figuring out how to integrate new tooling safely, but nothing as fundamental as the mentioned changes are taking place so far.
Yes I’ve noticed this change acutely, working at a couple Series A YC startups. I’ve been surprised there haven’t been more articles on this topic because it’s been a miserable shift from my perspective, and I agree with the author that the root cause is the end of the ZIRP era.
Basically, in addition to the irrational AI-everything initiatives in spite of customers not wanting or using those features, as an engineer I’m being asked to basically run my own business unit doing everything from user interviews to product/design, engineering, QA, support, and reporting. There are no EMs anymore, everyone reports to the founders.
I think the author’s post could be boiled down to: in the ZIRP era the engineers had leverage and were treated well, and in the post-ZIRP era the tech companies have the leverage and are squeezing everything they can out of engineers to the point where you’re basically doing the job of a founder within someone else’s startup.
But is it universal for companies that aren't startups (or FAANG, where I hear they are also pushing for EMs to get their hands dirty or be fired -- or was that just Facebook)?
Like the comment you're replying to, I've also have NOT experienced this shift in EM skills. In my experience, they are still about making the team happy and productive, and definitely NOT coding or designing software (though I'll concede most seem technically minded and understand the details well enough to ask relevant questions and push back against bad takes).
But coding? Nope. EMs are still about the team, careers, hiring, alignment, etc.
C-levels forcing AI on everything, whether it makes sense or not, is definitely a symptom of the times.
fads come and go but idiocy is forever
this guy didn't write a blog post, he wrote the preface material for a training module to be sold to the least-competent HR execs he can find
it is generally a bad sign when you set out to taxonomize all possible productive behaviors. in this case, possibly a worse sign is that this guy has two "clusters" making up eight "foundational skills." for perspective, when Immanuel Kant set out to taxonomize all possible human experiences, he came back with four "clusters" of four "skills"
apparently engineering management encompasses the same complexity as half of all possible human experiences, from tabula rasa. good to know, i guess
(perhaps obviously, i did not read the essay any further than the introduction of "eight foundational skills" in "two clusters." at that point clearly I am being sold nonsense, and I feel free to stop reading and just poke fun at the author instead.)
The job of EM is to be accountable for a team (or teams) which deliver(s) software. A software engineer’s job is to develop software.
And more broadly, goals/interests/skills can align really well with company needs and priorities at a time--and then they don't. You may be able to adapt but when the whole reason you were hired basically goes away, maybe it's not a great fit any longer.
This is a good article that is critical of narratives around behaviour within organisations. I particularly enjoyed his criticism of the 'morality tale'.
The author then postulates some guidance for how to survive in organisations more generally, working above these strange social structures largely unique to silicon valley. It wasn't the purpose of the article, but I wish he was a bit more critical of these structures in general.
Brilliant and true. Finally exposing the tech middle management for what it is!
I read more of the author's blog posts and it's actually insane to me that he not only was involved in one of the worst product deliveries in internet history (Digg v4), but he still justifies it somehow??
Presumably you're talking about this - https://lethain.com/digg-v4/ - "Digg's v4 launch: an optimism born of necessity"
Did you read the title of that post and not the actual content? Because it's a fantastic insider's war story about one of the most infamous product launches in our industry's history.
Here's the conclusion, which you can count as justification if you like but seems like a very interesting piece of insight to me:
> Digg V4 is sometimes referenced as an example of a catastrophic launch, with an implied lesson that we shouldn’t have launched it. At one point, I used to agree, but these days I think we made the right decision to launch. Our traffic was significantly down, we were losing a bunch of money each month, we had recently raised money and knew we couldn’t easily raise more. If we’d had the choice between launching something great and something awful, we’d have preferred to launch something great, but instead we had the choice of taking one last swing or turning in our bat quietly.
> I’m glad we took the last swing; proud we survived the rough launch.
> On the other hand, I’m still shocked that we were so reckless in the launch itself. I remember the meeting where we decided to go ahead with the launch, with Mike vigorously protesting. To the best of my recollection, I remained silent. I hope that I grew from the experience, because even now I’m uncertain how such a talented group put on that display of fuckery.
I can't imagine how reading that could make you think they were less rather than more credible as a source of information on engineering management!
This is like claiming that one of the North Korean nuclear scientists is credible on atomic bombs after theirs immediately fell into the ocean. Presiding over a disaster doesn't give you some magical insight on why you completely failed.
He didn't "preside over a disaster". He was a recent engineering hire who joined two months before the launch.
This really taints the article for me. Maybe I should evaluate the article on its own merits or whatever, but to justify the Digg fiasco...
Make sure you get as far as the four core management skills and the four growth management skills, which are very clearly explained and make a ton of sense to me.
A manager’s job isn’t to guide the company, it’s to make sure his team does the tasks they are assigned. Likewise, a worker’s job isn’t to “think about the big picture” and come up with a strategy for the organization.
So who is supposed to do it? Because executives sure aren’t.
The executives are supposed to, even if they aren't doing so.
Disagree. Software development requires a lot of expert knowledge that executives won't and can't possess. If you're not employing that expert knowledge to benefit the company you're a part of, why are you even in the field?
Personally, I find a lot of appeal in having the expertise and influence to be more than a small cog, even when working as a generic staff engineer at the leaf level of my organization. I don't think there are many professions where that is possible, or at least nowhere where that degree of influence is near as feasible (apocryphal stories about janitors coming up with the next breakthrough product notwithstanding).
You would love working in a bank