I left a large tech company for a startup partly because of this. The politics of shipping were exhausting. At a certain scale, what gets rewarded isn't always what's valuable.
But I'd push back on the idea that all tech companies work this way. Smaller companies and startups can be different. The feedback loops are shorter, you're closer to customers, and it's harder to hide behind the appearance of shipping.
The trick is finding places where the incentives actually align with the work.
> You ought to know that crushing JIRA tickets is rarely a path to promotion (at least above mid-level), that glue work can be a trap, that you will be judged on the results of your projects, and therefore getting good at shipping projects is the path to career success.
Notice that the author didn't write "getting good at delivering value." They wrote "getting good at shipping projects" because
> Shipping is a social construct within a company.
Delivering solid software that helps people get work done is a platonic ideal. Unfortunately there are many companies that value whipping stuff out the door more highly. As corny as this sounds the iron triangle ("good, fast, cheap - pick two") is a thing for a reason. Crapping something out as quickly as possible and leaving others to deal with the fallout of a bad data model and chaotic on-call isn't something to be rewarded but it's how many companies seem to work.
> Crapping something out as quickly as possible and leaving somebody else to deal with the fallout of a bad data model and violent on-call isn't something to be rewarded IMO.
Sadly you've described precisely the optimal engineering strategy for promotion at my FAANG
And yet those five companies are among the most valuable in the world.
There's a cognitive dissonance that arises when you join a company that is performing extraordinarily well only to perceive dysfunction and incompetence everywhere you look.
It's so hard to reconcile the reality that companies can be embarrassingly wasteful, political, and arbitrary in how they run and yet can still dominate markets and print money hand-over-fist.
> Crapping something out as quickly as possible and leaving others to deal with the fallout of a bad data model and chaotic on-call isn't something to be rewarded but it's how many companies seem to work.
Engineers who do this leave nothing but ashes in their wake even if they keep getting promoted for it.
Do you ever get tired of playing this “visibility,” “impact,” “promo politics” game and think, “I came into this industry because I like computers, not… whatever this is”?
The more I read these kinds of things, the more I agree with
> The only way to truly opt out of big-company organizational politics is to avoid working at big companies altogether.
I've done plenty of really fun, engaging and interesting work in smaller companies. If you're able to be involved in open source work, what you do can still be something that many people appreciate, beyond the customers of your company,
> The only way to truly opt out of big-company organizational politics is to avoid working at big companies altogether.
This is perhaps what I find somewhat odd about Sean's writing. It sometimes reads to me like a scathing critique of the dysfunctional bureaucratic dynamics of big tech companies, but that isn't really his conclusion!
The key point is at the end of the OP. The dysfunction and bureaucracy are annoying, even to the people who make a career out of it, there's no level of enlightenment where it stops being so. It's just an inevitable consequence of doing some kinds of things and making some kinds of decisions. If you're faced with an important decision affecting 10,000 employees or a million users, there's no perfectly good way to make it, only a least bad way.
glue work is real work and a lot of projects get stalled or blocked because there was no glue; especially in SOA where you have different teams with differing roadmaps integrating with each other. It's not just about communication/socialization, but also how code interacts and how the contract is defined.
I left a large tech company for a startup partly because of this. The politics of shipping were exhausting. At a certain scale, what gets rewarded isn't always what's valuable.
But I'd push back on the idea that all tech companies work this way. Smaller companies and startups can be different. The feedback loops are shorter, you're closer to customers, and it's harder to hide behind the appearance of shipping.
The trick is finding places where the incentives actually align with the work.
> You ought to know that crushing JIRA tickets is rarely a path to promotion (at least above mid-level), that glue work can be a trap, that you will be judged on the results of your projects, and therefore getting good at shipping projects is the path to career success.
Notice that the author didn't write "getting good at delivering value." They wrote "getting good at shipping projects" because
> Shipping is a social construct within a company.
Delivering solid software that helps people get work done is a platonic ideal. Unfortunately there are many companies that value whipping stuff out the door more highly. As corny as this sounds the iron triangle ("good, fast, cheap - pick two") is a thing for a reason. Crapping something out as quickly as possible and leaving others to deal with the fallout of a bad data model and chaotic on-call isn't something to be rewarded but it's how many companies seem to work.
> Crapping something out as quickly as possible and leaving somebody else to deal with the fallout of a bad data model and violent on-call isn't something to be rewarded IMO.
Sadly you've described precisely the optimal engineering strategy for promotion at my FAANG
> FAANG
And yet those five companies are among the most valuable in the world.
There's a cognitive dissonance that arises when you join a company that is performing extraordinarily well only to perceive dysfunction and incompetence everywhere you look.
It's so hard to reconcile the reality that companies can be embarrassingly wasteful, political, and arbitrary in how they run and yet can still dominate markets and print money hand-over-fist.
> Crapping something out as quickly as possible and leaving others to deal with the fallout of a bad data model and chaotic on-call isn't something to be rewarded but it's how many companies seem to work.
Engineers who do this leave nothing but ashes in their wake even if they keep getting promoted for it.
Do you ever get tired of playing this “visibility,” “impact,” “promo politics” game and think, “I came into this industry because I like computers, not… whatever this is”?
He somewhat addresses that at the end. Maybe soon enough we can replace management with AI and just download Pliny's latest promotion jailbreak.
I dearly hope so. Not that I am saying software development shouldn't be a social activity, but does it have to be this performative & toxic?
The more I read these kinds of things, the more I agree with
> The only way to truly opt out of big-company organizational politics is to avoid working at big companies altogether.
I've done plenty of really fun, engaging and interesting work in smaller companies. If you're able to be involved in open source work, what you do can still be something that many people appreciate, beyond the customers of your company,
> The only way to truly opt out of big-company organizational politics is to avoid working at big companies altogether.
This is perhaps what I find somewhat odd about Sean's writing. It sometimes reads to me like a scathing critique of the dysfunctional bureaucratic dynamics of big tech companies, but that isn't really his conclusion!
The key point is at the end of the OP. The dysfunction and bureaucracy are annoying, even to the people who make a career out of it, there's no level of enlightenment where it stops being so. It's just an inevitable consequence of doing some kinds of things and making some kinds of decisions. If you're faced with an important decision affecting 10,000 employees or a million users, there's no perfectly good way to make it, only a least bad way.
How many large tech companies has the author worked for? I don't see how general lessons can be drawn from the stuff on their LinkedIn.
Correction..how dysfunctional companies work..
glue work is real work and a lot of projects get stalled or blocked because there was no glue; especially in SOA where you have different teams with differing roadmaps integrating with each other. It's not just about communication/socialization, but also how code interacts and how the contract is defined.
There are two things that drive your value (aka salary):
1. Do people like working with you 2. What would a competitor pay to hire you
The driving factor in the first is your UI, the second your skills.
Actual title: You Have to Know How to Drive the Car.
Actual theme: LARGE tech companies suck.
Declared subject: you have to know how tech companies work
Actually subject: you have to know how large-and-or-disfunctional-and-or-sales-or-finance-bro-led-companies work.
Tagging @dang re title.