hckrnws

I don't disagree with the article, but after working in big tech, two HN startups, a couple unicorns and others, in two continents, I don't really find this too actionable.

In the last ten years (and even in the 20-people HN startups), the day to day work of engineers has become so incredibly specialised and divorced from the needs of decision-makers and the customers that there is almost nothing I can do to influence whether someone views me as doing my job or not. Mainly because of the presence of Product Managers that insert themselves between engineers and the rest of the company.

I'm always interested in delivering value, but the fight necessary to actually do so has become stressful. It's no longer a collaboration, all my contributions must be filtered through the ego of the person speaking to decision-makers.

In fact, the only time I was actually satisfied with my work in the last 5 years (as opposed to my paycheck) was when I was acting as interim Product Manager for 9 months. Unsurprisingly, me and my team managed to deliver three projects that other teams tried and failed several times.

Most of that was accomplished by communicating with stakeholders and actually figuring out what they needed, rather than endlessly "trying to put my own spin" on it.

So yeah, I'm gonna keep delivering whatever is asked, getting the blame for bugs and not getting the credit for features. At least the pay is alright. I'm constantly searching for the place where I can actually fully contribute, though.

> At least the pay is alright.

I don't know why but this part of your comment really stuck out to me. I have a whole different take on getting stuff done specifically at big tech companies, mainly that being "stagnant" is not such a bad thing at a place like Google or MS.

Say you're like an L-whatever at one of these big tech companies and you bring home say $300k/yr. You don't live in a HCOL so the pay is astronomical compared to anywhere else and even if you work on the same boring project for 10 years there, you can still say you spent 10 years working at MS or Google and that would get you red carpet treatment just about anywhere. I'm sure this would bug a go-getter and would certainty bug a younger version of me, but if you're that kind of person you're most likely trying to work at a smaller company where you get more say and sway.

And to add a bit more to this it's not like I don't care, it's just what I care about has changed over the years. When I was younger I was concerned with climbing the ladder and getting prompted. Now that I'm older I care way more about my family and friends than I do my company. If I was at one of these big tech companies and someone told me I was stagnant and would never get prompted I would just tell them so what. I bring home $300k for my family and I have a good work life balance (most likely). And do I really give a damn about the initiatives of some corporate behemoth, no and to be totally blunt the only thing I like about them is the paycheck and what it does for the rest of my life (all the free shit at the office is just a bonus).

That sounds great if you can ride that into retirement but if you get laid off and you start having to justify your existence again in the job market I dont think "I took home $300k for doing nothing and then got laid off" is a great sell.

But that's kinda the beauty of it. If you get laid off from one of these places the next place doesn't know that you took 300k home to do jack, all they know is you worked for a super prestigious company for 10 years and you can plausibly make up the rest about what you actually did there.

This becomes quickly apparent in a smaller company or if you have a manager that knows what they are doing.

You'll get hired, if you pass the technical interviews, but if you cannot contribute at the level they hired you, you'll be exited and that will be suspicious for your next application.

>but if you cannot contribute at the level they hired you, you'll be exited

But this is the case for anyone anywhere, it doesn't effect the OPs position one way or another.

> you can plausibly make up the rest about what you actually did there.

I would never do this, and if you would do this I wouldn't want to work with you. Maybe I'm a sucker, but I sleep alright.

It's not like the parent would have accomplished nothing in the 10 years. I think they are just talking about framing it in language palatable to the interviewer across the table.

It's highly likely they've achieved nothing that notable in that time.

Chances are high anyone to corroborate was laid off or has moved on, and does the same thing anyway lol

Chances are high anyone to corroborate was laid off and does the same thing anyway lol

You haven't been on LinkedIn in the last few years, then.

What about actually accomplishing some things over 10 years while maintaining good work life balance?

That's the dream, but it requires either luck (to fall into a great company) or burning of political capital (plus luck).

If you're going to lie about experience anyways, you don't have to work for the FAANG company in the first place.

Out of curiosity: Why didn't you continue being product manager?

Good question.

Mostly politics, I guess?

The CTO was about to be fired, so I had nobody to fight for me. The Chief of Product didn't like the optics of a non-PM being more successful than a PM in delivering work.

As for why I don't change careers, I'm an Engineering Manager and I made twice as much money than a senior PM at my previous organization.

I still long for a position where I can be both technical, product and business minded. But I guess the only job where I can do that is as a founder.

I read the comment and had the same question!

I did this myself and ended up with a really satisfying 4ish years as a PM.

That being said while I was perhaps fairly cynical about why PMs needed to exist before trying the role myself, after being in the role for an extended period of time, fully understand why the role exists now.

Of course there can be bad PMs, a good/great one is super worth it.

We probably agree with each other!

I'm not really cynical, and even before I wasn't!

I just think it's a role that's way too critical, and a bad PM can do a lot of damage.

Also bear in mind that you're slowly strolling on the road to burnout.

So you’re saying the only time you were satisfied with your work is when you took the role of a product manager who stepped in between the engineers and the rest of the company and had all their contributions filtered through your ego?

Yea, that sounds pretty satisfying…

No.

Keep in mind that:

- I didn't step in between engineers and the company. I am an engineer.

- I didn't step in between my team and the decision makers. It wasn't me who "invented" the requirements, nor it was me who said the projects were complete.

- It was the only time in the last few years where I could actually follow the advice in this article and ship things people need. Because I could TALK with people.

- My entire team got salary increases all across the board.

- Everyone has an ego, and everyone has a personality. But nobody in a team should get to put "more" of their personality over the others. We had brand guidelines and accessibility requirements, but other than that we decided things together.

Based. Nice work!

>> Unsurprisingly, me and my team managed to deliver three projects that other teams tried and failed several times.

Not sure how important delivery was to the company, but it's nice when your personal goals match those of the company.

So, fire the Product Managers?

Good PMs are worth their weight in gold and actually make engineers' jobs easier. Bad PMs create a useless "translation" layer that doesn't help anyone (except, perhaps, themselves.)

Bingo.

It's exactly the same for designers.

Good ones can shave days off complex tasks, and even help the code be more beautiful.

Bad ones can turn a 5-min feature into a week's worth of work. For absolutely no gain, and possibly creating a few bugs along the way.

Unfortunately the only way designers and PMs can learn this is by working together with engineers. Everyone needs to check the ego at the door. Which is borderline impossible with some personalities (from all sides).

How will you define a good PM? I have been looking for this definition for a while.

In my startup experience, it seems to me the best PMs are the CTO and the early engineers who has near infinite business and user context.

Communicates well, focuses on the people, problems and solutions, not tools and processes.

Example: good PM will build a mock up of a UI, go over it in detail with engineers, then let them break up their own work. They are focused on the actual product. Bad PM will write 10 Jira tickets without any real context, assign them without discussion, then add 20 different tracking fields that nobody will use.

Same experience, IME founders make amazing PMs, because they care about the company and they care about people not wasting their time.

Not OP, but I can answer:

They're ok with ideas coming from someone else, check the ego at the door and listen to both engineers and customers. They make engineers work less and produce more value. Most important, they don't have a "vision", they help organize the team so the team has a shared vision built by the team.

EDIT: Also: They're not competing with the engineering manager or lead developer for some sort of leadership. They're talking with customers instead of asking sales to do it. They're working on the product aspect of tasks instead of offloading them to engineers.

yes! The best PMs I've worked with have been founders.

My previous PM was ultra valuable. Put devs in contact with the customers, got out of the way of deciding what to build, and then sheltered the devs from the chaos of customers. He was also smart about what could be done and in what timeline, always working from the estimates engineers gave, working backwards and deciding what scope could be cut and where, who if another team could loan us people. He was the right balance of umbrella, partner and pass through. It was magnificent.

My company, being more than a little bit toxic, he got transferred to a new manager who took an instant dislike to him and he was pulled off all his projects and then fired for not delivering anything. (bit of an exaggeration, he got put onto one of those "all responsibility, no authority" type projects where he was responsible for making sure everyone at the company stopped using the VPN, but he had no authority to force teams to build or migrate services to be available outside the VPN, and there were 2+ decades of services to migrate, and he couldn't direct people to stop connecting to VPN if they needed something that was inside the VPN)

The PM that came along to replace him described himself to all the engineers as "the next Elon", wouldn't let engineers talk to customers, personally decided what features to build with no input from the dev team, even when making technically difficult decisions. He asked for estimates from devs but never used them. Often giving us both half the time asked for, and half the engineers asked for to deliver a project. He never deflected chaos from customers, just added a translation layer that made it impossible to make the customers happy. Everything was an emergency, every feature necessary for an MVP. He'd constantly harass people for status updates, forget what they were working on and harass them again. He constantly asked for documents to be written for himself that he never bothered to open the links too.

He was actively toxic, wrong and an impediment.

He'd send out launch announcements to the org celebrating the projects that were completed and it was customary to list key people who delivered the project. He'd forget whole teams of people that worked on the project. One time he left me off of a project that I lead, got everyone in our sibling team that was helping out though. One person he never forgot to list as being a key person involved in the project was himself. Even in projects he had never heard of before having to write the launch announcement.

That behavior was rewarded, for whatever reason. Although he finally left the company when one of the many rounds of "you must work from the same office as your manager" bullshit caught him up and he wouldn't relocate from canada to the US.

> That behavior was rewarded, for whatever reason.

Sounds like you're describing someone with narcissistic personality disorder. Such people are often extraordinarily good at convincing the people above them they walk on water while shitting on everyone below them.

My greatest wish is for managers to be trained to recognize people with NPD and other disorders and to remove them from the company quickly. They can cause tremendous damage to the organization in a very short time.

I left the government for corporate work, and we didn't have project managers as a specific role. Of course, people were managing projects, but it was nothing like it was in the government. In my short experience, project managers:

- Have no understanding of the technology they're "building."

- Don't understand who is responsible for what.

- Would have NO idea if things were set up incorrectly.

- Are solely working through a checklist of items and asking "is this done, or do you have dependencies?"

- The checklist itself was just built by interviewing different stakeholders, but it's the PM who puts it together and of course the PM who doesn't really understand the detailed or high level view of the project.

It's pretty maddening, and self-evidently stupid. I really cannot fathom why my company and other companies fail to understand what a waste of time and money this is. And worse, than the PMs are often leading to worse outcomes. Please keep this in mind anytime someone tells you that we need to "run government like a business," or suggests that businesses are wildly efficient whereas government is never efficient. If we had EVER had a useless PM like this back in government I would have forced them off the project as part of our criteria for success. In the corporate world, there's really no such option, because project success is always secondary to the businesses wants.

product, not project :-)

Same pathology, different symptoms. They are professional proxies.

Or at least hold them accountable for failing to get things done and communicating badly with developers. Which is something that I'm yet to see.

In previous companies, as an engineering manager, I had to burn a huge amount of political capital to steer my team in the right direction, several times.

My people (engineers) want to achieve their goals and create value, and the higher-ups want working software making money. I don't see why this has become so hard to achieve.

Because it’s easier to create chaos for some people than it is to actually do what they are supposed to do.

How do the evade accountability so often and so deeply? It's bizarre.

By shielding decision-makers/customers and engineers.

To give an example of when I had to burn political capital:

I had to "skip rank" a few times and go directly to CEOs. They are appreciative when you provide concrete facts, such as "I worked for two weeks on the redesign of this page that zero people use and I'm frankly tired of this bullshit".

CEO's and VP's and customers appreciate this type of work, but YMMV. Speaking from experience, you'll be surrounded by more enemies in your day-to-day when the side effect of your customer obsession negatively impacts the KPI's that are used to stack rank your direct management chain against other teams and managers. it is quite kafkaesque to be treated as the black sheep after you save $10m a year for the org, then get a pay decrease + meets expectations 8 months later.

Your reply sounds too ironic and too real at the same time. :D

But you're 100% right. You have to know when to use the nuclear button. And sometimes you can't press it, which means you take a backseat and watch the company burn money for no reason. This is the point where I start agreeing with _fat_santa's post [1].

[1] https://news.ycombinator.com/user?id=_fat_santa

Usually the same way folks like Trump do it.

DARVO, leverage, etc. etc.

I can't tell if you know :) https://medium.com/illumination/google-once-fired-all-manage...

I fundamentally object to any notion of done-ness that is solely focused on pleasing the few people who happen to be in positions of power.

Are we all embedded in absurd structures of primate dominance? Sure. Primates gonna prime. But that is no more the root of what's going on than being able to mark something done in Jira, or getting a compiler to stop complaining. Proximate hurdles are not ultimate goals.

Nobody gets to the end of a technical career and says, "Welp, that was 40 years well spent making a rotating series of bosses and grandbosses happy."

I don't know. I'm 30 years into those 40 and, while I can list plenty of "achievements" ... that's not what got me promoted. There _is_ value in making bosses & grandbosses happy.

I don't think it's good for you to be a cynic(because there's more to life than "promotion!"), but I think it's good to know/be well aware of the cynical viewpoint, because there's often a lot of truth in it.

We agree: There is value in making the compiler happy. There's value in getting tasks done. There's value in pleasing bosses. They are necessary means to an end.

However, my point is that one's analysis of the purpose can't stop with any of those. That focusing only on any one of those is ultimately shallow.

And in particular, my critique of this article is that he's just shifting focus from one proximate goal to another. Is pleasing the bosses necessary? Under our current dominant theories of work, yes. Is it the point? No. Always and forever: no.

Agreed - the better take is "getting promoted in large tech companies requires marketing" (and even that is only true for the senior roles, in the junior roles, being good at your trade is typically enough to get promoted to "less junior").

But people have different ways of expressing this same idea, because it gets tiring to see/read it in only one form.... so I guess one has to get a bit provocative in order to draw attention :)

(and to be fair, given how distasteful many programmers find the "marketing" part, it's somewhat useful to have many different ways to tell them that it's needed).

Agreed, and as I tried to say in another comment, the real purpose is to help the company make money (and achieve its other goals). Ideally your management knows what those goals are and pleasing them is a proxy for that. Not always true, but in that case you have another problem, and its good to know that.

> that was 40 years well spent making a rotating series of bosses and grandbosses happy

Isn't that the definition of being employed? pleasing the persons who pay you to do what they ask?

The golden rule. He (or she) who has the gold makes the rules.

While I generally agree with this, I’d add one thing: to understand what your managers want, you really need to understand the business. At the highest level, how does your company make money, or at least think it’s going to make money? What other things does the company value? It’s surprising how often I find developers who don’t know, either because they aren’t curious, are too busy to learn, or (surprisingly common) think it’s somebody else’s job to make money…they’re just doing what they’re told. My advice is to actively try to meet upper managers, sales and support people, marketing people, and ideally customers. You almost always learn something you can apply. In big tech it is way too easy to be insulated from what the output of your job actually is. This applies even if you work on internal systems—-somewhere those systems either add value or protect the company, and understanding that helps get your job done. And if it turns out your group doesn’t add value, or you can’t figure out how it does, then start looking at what groups do add value and whether you can move there. I did a few jobs that were not clearly aligned with the company needs and those always turned out to be a mistake. The valued work not only pays better is (usually) more satisfying.

I think it's fair to think of yourself as a carpenter. Devs talk a lot about this being a craft. You build to spec but point out problems when the spec is not possible or silly.

It's the business's jobs to know how to explain the business and their needs. If they can't explain it, they probably don't understand it. If they do understand it but can't explain it, they probably need to work on their soft skills. You're also going to learn the business implicitly if they're explaining it well.

You could be a developer that also knows the business, but where's the compensation for going the extra mile? Especially when the layoffs come around. Another perspective is if you have time to work the business side, what could you have been working on technically to improve things? So there's potentially an opportunity cost too unless everything is currently as optimal as it can be.

It just happens that two of my good friends are carpenters. And they are highly aware of the business. They have to be in order to ensure they have work as construction and remodeling and other types of work ebb and flow. It’s precisely when the layoffs come that it is valuable to understand the business. You are absolutely right that ideally the business people understand and explain the business, but are you really going to trust your livelihood so completely on that? Sometimes their job is to keep you working, fixing bugs, adding features, until they reach the point they can lay you all off (this pretty much happened to a bunch of my friends at an early job). Furthermore, just building to spec suffers from the Henry Ford problem of the customer asking for faster horses. Unless your business people understand the tech as well or better than you do, it is very likely you can improve the product more if you understand the business than if you just do what you’re told. This does not have to be very time-consuming, and ideally your manager helps, but just paying a little attention, spending some time with people in other disciplines, can have huge payoffs.

While I understand the point being made, and have experienced this reality first hand, I still object to it.

I have seen countless projects spun up, the company declares the problem solved (done), and then the team is disbanded to go work on new problems.

What happens next? The product they built has issues, new features are needed, the rest of the company keeps evolving… all the while, there is no one to actually maintain that “done” project and it becomes technical debt.

Eventually a new manager comes in, sees this mess of an old project and builds a new team to solve this problem all over again from scratch. They have to learn everything all over again and repeat a lot of the same mistakes of the first implementation, and the cycle continues.

This doesn’t seem like an effective way to run anything. If I can use an air conditioning metaphor, it is more efficient to set the house at a temp and keep it there, than to keep turning the AC off, letting the house heat up, and trying to bring it back down from 90.

I had a little side project at work that upper management didn’t care about, but was immensely useful to various support teams. At one point it had over 500 unique users internally, through word of mouth, as it was only designed for one team of about 50. The initial build took some effort, but once it was running it still needed care and feeding to keep it relevant. I managed it personally for over 10 years, and my priority was always responding to organizational change to keep it relevant and as a trusted source. The second it fell out of date, people would lose trust in it and start looking elsewhere, which is when tooling starts to fracture. It didn’t take much time. Sometimes I’d go months without touching it. Most updates took 5 minutes, some more involved changes might take a day here or there. But that was important work to prevent needing to re-invent the wheel down the road once it became too painful to use due to lack of maintenance.

This is one of a whole genre of HN-boosted blog posts that are basically saying to engineers: "you can't just write code, you actually have to do sales also". People who don't like sales think that they can go to a big company and just do engineering work. Nope, it doesn't work that way: you still have to promote your work, you still have to sell your work, you still have to talk to your customers, you still have to understand business, you still have to make deals, etc etc.

I strongly dislike "alignment" as a buzzword, and I think its existence is ipso facto an indication of our industry's dysfunction, but it nevertheless represents a legitimately important concept. You, your manager, and (to quote the article) some appropriate number of your skip-levels should ideally agree on what the most important next work items are. And to the extent that you don't, that's a problem for you as the individual contributor. Is this right? Is this fair? Of course not. Not in any moral sense, at least. But those are the cards we're dealt, and we play them as best as we can. The article is right that, on some level, we are paid to do what we are told to do. This is not a great outcome. Some of us are fortunate enough to have some sway in the opposite direction. This is the so-called "managing up" - another buzzword I strongly dislike, but again represents a legitimately important concept.

I have mixed feeling on this.

Some parts of this are probably good advise, at least with respect to clocking titular promotions. No disagreement around visibility of delivered "big wins" being key.

However, I feel like this article is subliminally pro-management, with the thesis statement essentially being just make your manager (and their manager) happy. But what happens when there's no clear direction from management on what the team's goals are? Or when priorities shift on a weekly, or even daily basis? It seems pretty hard to deliver anything meaningful, if by the time you're finished they've already moved on to the next shiny thing.

Additionally, in my experience this "make your manager happy" approach goes hand-in-hand with a "yes boss" manager-subordinate relationship. Managers are empowered to flurry out executive dispatches on what, when, and how things ought to be done, and engineers are encouraged to follow orders. Results are normally not great.

The solution to this is pretty simple: when you find yourself working for idiots, just quit. It’ll suck for a little while, and then it will get better. Which is much better than spending months trying to make stupid and under-qualified people understand things that smarter people would understand intuitively.

Is this sentiment the reason why a lot of "engineers" will provide terrible quality in code / tests (lack thereof) / documentation / etc.?

If all that matters that someone at the top sees it and is happy about it at this specific moment in time, why bother writing code that can last and doesn't leave behind an absolute unmaintainable ball of mud?

We don't need gold plating and yet billions could be saved by having invested more than the bare minimum.

More and more you run into people who simply don't care about craft and quality.

I can already hear the chorus of people that will scream "I'm not paid enough to care" or "it's just a job for some people", and those things are often true; but, nonetheless, people used to take much greater care in their craft even when they were paid less. There was a sense that, even if it was just a job, it should be done well. A certain sensibility of care and craftsmanship has faded away.

> A certain sensibility of care and craftsmanship has faded away.

It got replaced with professionalism, as in "being a professional", which nowadays seems to mean prioritizing business needs above all.

Caring about quality and craftsmanship is not professional - it's just not being economical with company time and money. It's better for the business for dev teams to tick features off a list as quickly as they can, because marketing can polish a turd and shove it down customers' throats much more cost-effectively than devs can make a half-decent piece of software that provides genuine value.

No surprise more and more people don't care. They keep hearing everywhere - including here - they should abandon childish pursuits, stop reinventing the wheel, writing too clever code, shaving yaks, going down rabbit holes, etc. - they should be professional. Well, that's what we're getting now.

> Caring about quality and craftsmanship is not professional - it's just not being economical with company time and money.

I disagree, but only partially. The real question is when is the project done as in you would shred the source code and nobody would ever care. Some projects are done when they ship version one - you wouldn't fix any bugs or add new features, so code quality doesn't matter. Some projects are never done - someone will be touching this code in 50 years (after you are dead), so quality matters.

If the code is done then craftsmanship doesn't matter and putting effort into it is an unprofessional waste of time. However if the code will be maintained for years in the future then not putting effort into craftsmanship is unprofessional. You need to know where you are. Sometimes writing ugly code is a good use of your time, sometimes writing good clean code is well worth it.

The important thing is to know where you really are. The wrong choice will hurt you.

> people used to take much greater care in their craft even when they were paid less

I think people used to care more when there were less BS involved in the software development process. Nowadays you get: scrum masters, product managers, product owners, engineering managers, daily standups, refinements, "getting things done", "shipping impact", "10x engineer", "red-carpet engineers from FAANG", and CEOs that want X or Y for yesterday. So, yeah, in that kind of environment, I couldn't care less about anything. I just do it for the money.

All my craftsmanship goes into my personal projects.

The level of respect that the typical manager or C-level has for the developers' efforts and time spent into keeping up-to-date with the industry has decreased, and now with the big promises of AI it will become even lower. Professionalism demands a certain baseline level of respect for one's effort and expertise.

> More and more you run into people who simply don't care about craft and quality.

Many talented and conscientious craftspeople, to pay the bills, work jobs which don't afford them full creative freedom, or even appreciate it.

> people used to take much greater care in their craft even when they were paid less

Did they? Maybe this is the golden tint cast when we reminisce about "the good ol' days". I currently know some people who take much greater care in their craft, than some other people I used to know.

The attitude of "I'm not paid enough to do that" feels, to me, to be closely correlated with a company asking the employees to do more for/with the same or less, giving less freedom to choose what to do, micromanaging/policing how they do it, and all the while showing a decreasing amount of loyalty and humanity towards them. It'd be unreasonable to expect the employees to then suck it up, grin, and bear it -- They are equal partners in an employment relationship in which one party is attempting to unilaterally change the status quo.

The chorus drones on about you're paid to deliver value and customers dont pay you for docs or tests or refactoring.

If anything this is worse.

I don't think anyone purposely writes terrible code.

You know the old standard:

    Never attribute to malice what is equally explained by incompetence 

Also many software engineers are just not very good, frankly. It's extremely difficult to become an actuary without a strong mathematics background. It is very easy to become a software engineer with any kind of background, even if being a good one is just as difficult.

Everybody has their reasons to take on the role. If you make no-/low-budget films this is important to remember — that camera person might want to try things out, that actor needs something for their reel, the sound guy might just want to make contacts in the industry, etc. If you manage to align your goal of making a film with theirs, everything works out.

Now if you don't let engineers live out their passion, you made the choice to select for the ones who just do it for the money. That can be a legit choice, but comes with risks.

I've been trying to figure out what bugs me about this advice. I think it's applicable narrowly to someone with no technical leadership on their project, but also doesn't give them enough groundwork to really succeed either.

Someone fresh enough to think anyone cares about the backlog deserves a manager that knows to meet them where they are, not expect the employee to meet them in the arena of management games. In practice, this often doesn't exist. Rather than the lowest rung of management bridging the gap into the tech, it's usually on seniors to "manage up" and shadow manage the team. Seniors good at this are more common, but time strapped with the rest of their dayjob.

The target audience of this article needs a powerleveling guide to all the management sills of a senior, because they're in a vacuum with no seniors or technically competent managers. But instead it's the tiniest taste of the management world needed to orient someone towards being a better cog.

> this fact is a trap for competent but unagentic engineers

Is “unagentic engineer” a euphemism for human/not-AI?

Unfortunately for companies whose engineers work this way, they’re on a one-way trip to expensive cloud bills, data breaches, and frustrated customers.

A good amount of that “never done,” work is:

- Patching security vulnerabilities

- Fixing mistakes made due to lack of planning/testing

- reducing costs due to lack of planning (ship it now, make it better later)

- responding to customer feedback

If the business you’re working in doesn’t see the value in the work you do then, when you can, find a new place to work. They’ll sink their ship well enough on their own.

Of course you're right. But that's the point of the article.

Companies, departments and teams operate on a spectrum from reality-centred to status-centred.

In a reality-centred culture all the things you mentioned matter. Reality-centred management understands this, manages it, and rewards it.

Reality-centred cultures are better at medium/long-term planning and at handling issues rationally.

In a status-centred culture the most important product is status in the hierarchy. A "competent" engineer delivers status to superiors. That's their only job. The quality of the product, codebase, and the customer relationships is secondary - sometimes irrelevant.

Status-centred cultures tend to be reactive, not innovative, and the orientation is emotional, not rational. Hierarchies are strict, communication is poor, and low-status people are treated badly. (Because how else is everyone else supposed to know they're low-status?)

No one cares when things work smoothly, but if there's a problem that causes a loss of status, someone has to be blamed for it.

Status cultures don't necessarily implode. If they have an effective monopoly, they can survive for decades.

They're more likely to seem like huge players until suddenly one day they aren't any more, and everyone wonders what happened.

> Status cultures don't necessarily implode.

Sometimes they do, though. And while it’s spectacular to see it up close, it won’t make you feel any better.

Nice reply, all true.

> Status cultures don't necessarily implode.

True! And they're often not a great place for developers to work (unless you want to join in and become a manager and leave development behind).

“Unagentic” is a terrible made up word to say that employees lack agency.

Basically, people like when employees show initiative, operate independently and influence their surroundings independently. At least they like to say that.

It’s a common trap for engineers, many of whom like to burrow in and crank out stuff. You’re toiling away slaying tickets and doing your thing, but become invisible or don’t realize managements attention elsewhere.

It doesn't have to be that way, but that's certainly the default unless executives put in the work to make certain kinds of work legible.

A great example that is less cynical is interface design - I greatly enjoy building user interfaces that are correct for lots of little interactivity details. It pains me to release an interface that breaks on tablets, or where the container doesn't have padding so the button awkwardly juts up against it.

This kind of attention to design detail is not automatically rewarded except for at companies and startups for whom that's something that is valued, and design intuition is praised. I've had people come to me for work in the past specifically because they love that I pay extra attention to this stuff.

That said, in many places this is not appreciated at all and none of this would be a value add.

> Is “unagentic engineer” a euphemism for human/not-AI?

Pretty sure it means someone who plods along in life, going with the flow, working but with no self-conceived roadmap of ambition, low extroversion, low desire to make decisions, etc

> Is “unagentic engineer” a euphemism for human/not-AI?

I read this as engineers without agency - those who have little to no freedom to make any decisions on their projects.

> Is “unagentic engineer” a euphemism for human/not-AI?

No, it refers to people that are not "high agency", i.e. they might be smart and competent but need guidance on what to work on, as opposed to taking initiative themselves.

I had to look up "skip-level" since my large tech company lingo was lacking.

It is defined as:

used to describe someone who works for a company at two levels higher than another person, or a meeting or relationship that involves an employee and a manager at two levels higher

by Cambridge's dictionary[1]. That makes it really complicated when the article talks about 1-3 skip levels, I'm not sure how to interpret that ... is it (my level + 1 + n) or (my level + 2 * n)?

Edit: the mathyness.

[1]: https://dictionary.cambridge.org/dictionary/english/skip-lev...

You “skip” over your boss to talk directly to your boss’s boss. If the hierarchy is very deep, you can skip even more levels

Skip level is your manager’s manager, presumably 2 is one further step etc

> How can you finish things in a world where you can keep improving systems indefinitely? It means getting them to a point where the decision-makers at the company are happy.

Rational mindset for an employee, but the problem (for the company) is that upper management is usually unqualified to distinguish good vs. bad technical work. So under this advice, engineers do the minimal work to “deliver” lots of features in order to check off the OKR for upper management, but the engineering is done poorly. Upper management has no insight into the quality of the work, but over time the bugs and performance degradation pile up, while engineering managers get promoted and OKRs completed.

The only real resolution is to push technical expertise as high up into the org as possible, so that even if engineers are only appeasing upper management, upper management will demand good quality work. Apple is the notable example of this org structure: there are no general managers except Tim Cook; everyone who reports to Cook is a technical expert.

> What does it mean to get things done in large companies? Most importantly, it means finishing things.

So that's why Google releases a new chat app every two years...

> If you want to get things done you can’t be a gardener.

Unless you are selling your own product or service that you yourself are working on (possibly indefinitely).

Which is surely an enjoyable position, as long as you don't mind having no like-minded coworkers.

> they start delivering a stream of marginal improvements to a particular subsystem1. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most value they can to their company.

These people are often force multipliers, or "developer velocity engineers". They do work that doesn't deliver direct customer value, like updating old dependencies, swapping out deprecated APIs for new ones, always fixing warnings in CI pipelines and lint tools, etc. They free up others to deliver the "value" at higher speeds.

But yes, they are the first to go when layoffs happen. But I think these types are absolutely necessary for an efficient org, and no matter how many times this type is fired for it, someone will end up falling into the same work again eventually - because this "no-value" work needs to get done.

"once software is done, you might be tempted to maintain it, but don't fall into that trap!" seems like a bleak thesis to me

They are implying that it is up to the decision makers to decide whether maintaining it is valuable.

Never maintain it for "free".

> The easiest way to do this is to deliver things that they already know about, such as projects that they’ve asked you to do

I've struggled with this recently. I feel like advancement requires getting credit for the idea itself, otherwise you're just implementing other people's designs. But ideating (will actually good ideas) is pretty tough.

Simultaneously correct and devastating. Where I work, senior leadership don’t have a technical background and so don’t know when something is “good enough“.

The result is that most of our products are dogshit and are force fed to users within the company and to its clients.

While the OP’s post is helpful, I’d argue it glosses over several other, far more critical points that other commenters have touched upon here:

* Doing work on the right team is more important than doing the right work

* Good PMs and managers are more critical than good work

* Good reporting structures are more important to visibility than a high-quality result

* Doing work that aligns with leadership goals is infinitely more valuable than work that supports the functioning of the business

* Always be ready to do the whole thing yourself, because politics in big tech will always disincentivize cooperation across silos.

Yesterday I pointed out to the founder of the company that I work for, in the context of tech debt:

"Well, since we moved the goalposts on that project, now we're out of 'credit card' tech debt and now in 'Adjustable Rate Mortgage' tech debt. Our goal should be to get to 'Fixed Rate Mortgage' debt."

The problem is that too much tech debt can hold back feature development, or even materially impact hosting costs. In our case, we're a 10-year-old startup, and many parts of our stack were built in a way that makes them very hard to maintain, or on end-of-life technologies that are impractical to hire for. To be quite blunt: The tech debt got to a point where we spent more time on the debt than feature development.

The problem with this article is that it glosses over the impact of tech debt, and how it needs to be handled. An umpteeth refactor for a 3% performance improvement is very different than a 3000x performance improvement that reigns in hosting costs. Backfilling unit tests needed to prevent regressions when building a new feature is also different than rewriting a major UI component because it depends on a UI toolkit that was end-of-life 7 years ago. All have a very different impact to the business and product.

Yeah. I would phrase it like this:

There is two things to avoid: "overengineering" and "underengineering". The first case has happened when it later turns out that the developer did put in too much work into a feature than was necessary in retrospect, in the second case that they did put in too little work.

At the time of engineering it is usually not clear how much work would constitute over- or underengineering, as this depends on how much the feature gets to be used and evolved in the future.

But usually it makes sense to "err on the side of overengineering". Because (limited) overengineering merely means some development effort was wasted, while underengineering can easily mean years of painful tech debt that is an order of magnitude or two more expensive than the wasted effort from overengineering.

(It's similar to building a house. You usually want to make doubly sure you really do everything right or more than right, because if there are any flaws that turn up later, this often gets very expensive to rectify, sometimes so expensive that it isn't even worth fixing at all.)

> In large tech companies, this fact is a trap for competent but unagentic engineers. They see an infinite queue of tasks that they’re capable of doing, and they start delivering a stream of marginal improvements to a particular subsystem. From their perspective, it feels like they’re crushing it. After all, they’re putting out work at their top speed: no downtime, no waiting on other teams. But they’re not doing their actual job, which is to deliver the most value they can to their company. From the perspective of their manager and skip-level, they’re not getting anything done.

I strenuously disagree with this premise, not because I don't think this ever happens (it definitely does!), but because it's not the responsibility of an individual contributor to attempt to divine the organisation's priorities: that's a core management function.

My employer buys forty hours of my time each week. It's my employer's responsibility to allocate tasks to me in order to best suit the organisation's needs and goals. Recently, I spent an entire week waiting for a specific person to review my code. It's my responsibility to (tactfully) inform my managers of this problem, but it's not my responsibility to solve this problem on my own initiative. The person might have a temporary backlog of tasks, they might be dealing with personal issues, they might have some workflow problems: in some of these cases, the root cause is something I shouldn't know about.

This isn't to say that I'm just the monkey at the bottom of the tree being shat on by those further up: I do pass my (frequently misinformed) opinions and observations up to my managers, but it's up to them to decide whether and how to act upon them. They have more information - feedback from more people for a start - and consequently can make better decisions than me.

If you feel that you have to fight your organisation to serve its needs, something has gone seriously wrong - possibly with you, but more likely with the organisation itself. Organisational pathologies are themselves Chesterton's fences - they exist for some reason, even if the reason is stupid - and are consequently difficult to fix. Perhaps making things difficult for you makes things easier for everyone else. Perhaps fixing the issue will involve so much change to the way the organisation is managed that it's actually better to leave things as they are.

> It's my employer's responsibility to allocate tasks to me in order to best suit the organisation's needs and goals.

I don't disagree that your personal employment relationship is like that, but keep in mind that you are describing only you here.

Contrast with another example: It is my employer's responsibility to describe the organization's needs and goals, and to give me the freedom and leeway to figure out how to best accomplish them according to agreed-upon measures.

> because it's not the responsibility of an individual contributor to attempt to divine the organisation's priorities: that's a core management function

The trope that ICs are incapable of understanding and balancing business interests against their wishlist of work items is just a cope that incompetent management chains tell themselves, because they need to believe that there’s something that they’re providing to the team that it won’t get elsewhere. The fact of the matter is that understanding your project in depth does not cause myopia. Big tech is fat with managers who provide absolutely nothing to their teams, other than filling a management req which was conjured up out of thin air. The best teams have technical leadership and work relatively autonomously.

"Getting things done" means applying torque to one or more of the cogs in the corporate cash flow machine of which you are a part.

Unfortunately that doesn't always correspond with "build a better product". If it doesn't but it is what you personally want to "get done" then you're going to need to circumvent the people whose job it is to keep you turning those cogs.

Your work in a large tech company is done when your manager (or a manager two levels above) gets promoted.

Then the cycle starts again.

> But they’re not doing their actual job, which is to deliver the most value they can to their company.

The article goes on to talk about legibility of value or perception of value which is a subtly different concept.

The post is apt in getting things 'done'. I prefer to get things done. Of course I can't always just do what I consider important, so I balance them, I meet the requirements of 'done' without much more, and I spend more time than most getting important stuff done, sometimes things that take a longer time--I'll do the gardening so that it eventually gets done.

People won't notice this extra effort for a long time, but from time to time, some problem/issue will arise and one of those things in my garden will be instrumental in solving or mitigating it. Over time, you get recognized as someone who gets things done well.

Basically get stuff 'done' in 80% of your time and make your own 20% time. What's funny is that I've often been given explicit 20% time, but I've found that I can't schedule/manage that time explicitly like that, so I went back to taking approximately 20% time if/when I thought it's appropriate.

This piece appears to be a quick summary of a much better and more thorough piece by the same author that was discussed extensively a few months back:

How I ship projects at big tech companies (1425 points, 381 comments) https://news.ycombinator.com/item?id=42111031

In my experience, the two most important things to get "things done" is the other part of that sentence, the "things".

Without well defined scope and deliverables, you cannot get "things done".

Never-ending projects means the scope was not well defined, there is a constant scope creep, or the deliverables were not well defined. Or, worse there are good idea fairies in the organization.

(https://www.urbandictionary.com/define.php?term=Good%20Idea%...)

Absolutely true, and absolutely one of the reasons that working in large tech companies can be soul destroying.

I see it completely differently.

If the execs don't see the value, customers don't see the value, and you can't prove money is being made (or saved), where is the value of your work, really? You're not paid to make art.

You're right, but this assumes that the execs have the insight to see that maintenance tasks save money. If preventing next year's incident isn't understood as being as valuable as doing the hero work to untangle this year's incident then it can be hellish unless you like hero work.

Well, that is also why large segments of the big corp work environment check out and do the absolute minimum - or even create chaos to make it less obvious who is doing what for whom.

Because the paycheck is indeed useful for them, eh?

This is why small companies can compete. What they lose out on economies of scale, they gain on avoiding this.

They can also get completely nuked by market forces a lot easier.

Also, pay is usually a lot less.

These people are comfortable collecting a paycheck despite providing little value. I'm not.

Do you like working with those people? That's part of it.

Sounds painful!

I don’t want to be negative, but writing a mathematical proof and planting a tree are about the worst metaphors I could possibly think of. Building a house is probably a better example for something that could be infinitely maintained and improved.

After the bad metaphors, all the article really says is “do visible work and finish it”. This seems obvious.

I continue to be amazed how the respect for the work of IT professionals gets lower and lower. This article attempts to reduce software development down to "people pleasing". A prostitute is also paid to make the "investors" happy but even people who've never hired one agree that not every demand by the "investor" can be fulfilled and that the prostitute can set boundaries. Yet, when it comes to software development, people such as the author of this article claim that the only true definition of done can be derived solely from the desires and wants of the business people (some of who tend to change opinions depending on what time they'd woken up). Imagine if civil engineers operated in this way.

This whole article could be boiled down to "it doesnt matter what you do it only matters what executives perceive you as having done".

The thing is, if in order to be successful in a big company you need to be a great salesperson and technically adept as well as organized then basically you're already a great entrepreneur. You're just a pet entrepreneur being kept on a leash.

And yes, lots of companies want pet entrepreneurs. That way all they need to bring to the table is capital.

I feel the author’s telling us to play politics without using the word politics.

>Declare victory and walk away: go and do something else

That works really well if you're a contractor/job-hopper and can actually walk away. Otherwise, someone who doesn't understand the code will be asked to make modifications and you, the original author, will be called back in to rescue the thing when it has turned into a dilapidated mess.

The problem the OP is having is not failing to please his boss, but working for a boss that isn't technical and has no idea what is happening. Those bosses are generally terrible for your career and if you have one, you should just quit.

Shallow content slop red flags abound. Might as well keep moving the definition of done goalpost-- nothing is done until it provides utility that a customer exchanges money for. How about until there are enough customers are paying to make the system profitable? How about nothing is done until you hear it referred to as "legacy"?

enshittification: perspective of the camp guard