The Enterprise Experience
churchofturing.github.io507 points by Improvement 4 days ago
507 points by Improvement 4 days ago
Always worth keeping in mind Remy's Law of Enterprise Software (https://thedailywtf.com/articles/graceful-depredations): if a piece of software is in any way described as being “enterprise”, it’s a piece of garbage.
Joking aside, I was intrigued by the list of good things at the end of the post. Some I could understand, but some seemed to fall into that strange category of things that people say are good but really seem only to lead to more of the things they say are bad. In this list we have:
> There are actual opportunities for career development.
Does "career development" just mean "more money"? If so, why not just say "there are opportunities to make more money"? If not, what is "career development" that is not just becoming more deeply buried in an organization with the various dysfunctions described in the rest of the post?
> It's satisfying to write software used by millions of people.
Is it still satisfying if that software is bad, or harms many of those people?
> Does "career development" just mean "more money"? If so, why not just say "there are opportunities to make more money"? If not, what is "career development" that is not just becoming more deeply buried in an organization with the various dysfunctions described in the rest of the post?
In life, everyone that thinks a lot is eventually confronted with the reality that we're all just minor players within much bigger systems. When you follow this thread, pretty deep questions start to fall out like "how can I be just in an unjust society?". Or "what's the best way that I, as an individual, can have a positive impact on my community?". Or "Is there any point in trying to change systems given my small role within them?".
To these types of questions there's various different responses and consequences. Some people dive in feet first and engage heavily with the mechanisms they have to enact change (such as local politics, grass roots political movements, activism etc). Some people, overwhelmed by the weight of the system, disengage entirely.
Now to answer your question, I believe in the work that we're doing (or else I probably wouldn't have joined). Career development at the company isn't just more money (though that's obviously a component), it's being given more responsibilities alongside the capacity to enact more and more change.
Faced with a dysfunctional organisation that you're a part of, what do you do? The options as I see it are roughly:
- Change companies, and acknowledge that the dysfunction is insurmountable.
- Do your job and stay at the position you're in.
- Embed deeper into the dysfunctional organisation, with the view that you can be an agent for positive change.
>Is it still satisfying if that software is bad, or harms many of those people?
To some people, yes. There are people out there that take satisfaction in doing harm. Not me, nor do I believe the work I do is harmful. I didn't think I had to be so granular as to say "It's satisfying to write software I believe is a net positive to society used by millions".
Thanks for your thoughtful reply. I see what you're saying, although with the way the world is going, I'm increasingly doubtful of the potential of that approach, because it seems that companies are becoming more brazen about explicitly selecting for their narrow and immediate self-interest. In other words, the more you use your responsibility and influence to enact change, the more likely you'll just lose that responsibility and influence (i.e., get fired, demoted, or just shunted away to places where you can make less of a difference). However, that's not entirely the case everywhere yet, and it sounds like maybe you've found a place that's big but still not entirely evil, which sounds promising. :-)
In any case, I didn't mean to imply that what you're doing is any more objectionable than anything I or a zillion other people do when we make the same tradeoffs you allude to. What I was mostly reacting to was that you mentioned those things in the section on things you viewed positively, whereas they seem to me like they still incorporate a tradeoff involving a significant amount of badness. Perhaps though you simply meant they were tipped at least slightly toward the positive side on balance, which makes sense.
Sure, "It's satisfying to write software I believe is a net positive to society used by millions". But, if there was no increase in compensation, you would try to move up the corporate ladder?
I'm not trying to invalidate your post; I think your essay is great. I think it just does have enough cynicism. These $ENTERPRISE companies basically set up their employees some kinda game. There are certain rules (some written, some unwritten) for how you get a good performance review and how you get promoted. Just like there were dumb rules for you had to write code on a whiteboard to get the job despite the fact that you have never written algorithms ever, much less on a white board. So you have to balance how much you are doing something actually useful with jumping through whatever hoops that are downstream of whatever idea your VP has come up with this week. In the ideal case you move yourself to a part of the company that aligns with your values and interests so that the promotion comes easily, but sometimes it is easier to stay where you are and just grind through whatever absurdity it takes to stay employed.
People are motivated by status just as much or even more so than by money. Consider startup founders who eat ramen for years just for clout, or people who continue to pursue wealth long after marginal diminishing returns have gone to 0, that's about status.
> Does "career development" just mean "more money"?
Big companies means more opportunities to lead bugger project. At a big company, it’s not uncommon to in-house what would’ve been an entire startup’s product. And depending on the environment, you may work on several of those project over the course of a few years. Or if you want to try your hand at leading bigger teams, that’s usually easier to find in a big company.
> Is it still satisfying if that software is bad, or harms many of those people?
There’s nothing inherently good about startups and small companies. The good or bad is case-by-case.
My experience at big companies has been that you only get the opportunity to do something big if you are willing to waste years "proving yourself" on a lot of tedious bullshit first. The job you want is not the job you get to apply for, and I've never had the patience to stick it out. Smaller companies let me do meaningful work right away.
Politely, I disagree. It means you are in a context where the risk aversion is high, everyone keeps their head down.
Done right, you can be a disruptor, for what are very benign or proven changes outside of the false ecosystem you are in.
I recommend these changes are on the level of "we will allow users to configure a most used external tool on a core object, using a URI template" - the shock, awe, destruction is everyone realizing something is a web app and you could just... If you wanted... Use basic HTML to make lives better.
Your opponents are then arguing against how the web works, and you have won the framing with every employee that has ever done something basic with a browser.
You might find this level of "innovation" silly, but it's also representative of working in the last few tiers of a distribution curve - the enterprise adopters lagging behind the late adopters.
> Big companies means more opportunities to lead bugger project. At a big company, it’s not uncommon to in-house what would’ve been an entire startup’s product. And depending on the environment, you may work on several of those project over the course of a few years. Or if you want to try your hand at leading bigger teams, that’s usually easier to find in a big company.
Okay, so career development means "bigger projects"?
> There’s nothing inherently good about startups and small companies. The good or bad is case-by-case.
Well, maybe not, but I think the post illustrates some ways big companies are worse. I'd say that, all else being equal, companies tend to get bigger by becoming more doggedly focused on money, which tends to lead to doing evil things because you no longer see refraining from doing so as important compared to making money. Also, all else equal, a company that does something bad on a small scale is likely less bad than one that does something bad on a large scale.
projects beyond a certain size in a large org imply things which are very different - people, networking, money, regulations, politics, business, security etc all things which don’t look spectacular when you have three people, but become very important and much harder with hundreds of people.
So career development really means ‘learning a completely different skillset which is not technical’
That's a good way to put it and is something I've often thought as well, although not just in the technical realm. I think of it as "doing a different job". You used to be a teacher but now you're the principal; you used to hammer in nails but now you direct the construction crew; you used to be writing software but now you manage other people who write software; etc.
Personally I'd struggle to consider that "development" for my own life, since it often amounts to no longer doing the job I like and instead watching other people do it. I can understand how adding new skills is positive, though.
This can be mitigated by learning other technical fields ( infrastructure, security, etc ) and using your technical knowledge to steer things in the right direction - but yes, you’re otherwise right and I understand your point of view.
> Does "career development" just mean "more money"?
If you want to become a researcher in data science or developper evangelist for instance, you'll need a org that can sustain your work.
Or if you want to be a micro service architect, you'll be booed in a 3 people shop but heartfully welcomed in 3000 people companies.
Same for engineering manager paths, it only makes sense if you have the headcount.
> software is bad, or harms
What you work on doesn't need to be Enterprise software. Hopefully it isn't.
> heartfully welcomed in 3000 people companies
Unfortunately, because most of those 3000 will think about the fact their org is 3000 people. Not that the user base for the new product is 5 people using it only on the weekend.
I’ve worked in a lot of enterprises on “tiny projects” but never on something that only went to 5 users. In one role I was the sole maintainer of a “small internal tool”…that had 1,000 daily users logging 5 hours/day each.
> Does "career development" just mean "more money"?
No. Career development includes paid training sessions, title promotions (junior -> senior, etc.) opportunities to work on larger projects in more significant roles (resume building), and opportunities to transfer into management, as well as (in some cases) opportunities to publish conference papers and the like. As you get older, this kind of career development becomes more important because it is recognized by people who will hire you.
> Does "career development" just mean "more money"? If so, why not just say "there are opportunities to make more money"?
That was not my takeaway, because earlier he alluded (twice) to the fact that titles are a thing:
1. A senior technical person who can't turn on a computer and an analyst not being able to speak english,
2. `I have met no less than 6 (six) people with the title "head of architecture".`
So I am guessing that is what he means by "career development"; you can acquire impressive titles.
I've never understood why anyone would care about titles at all.
With more title comes more salary. Usually more ability to influence more policy too.
"More title" can also be used to quell ambitious, but naive/misguided people into not asking for a higher salary. I've met quite a few people who attach way too much pride to how "high" they are in the corporate ladder. They saw the title itself as a part of their compensation.
> I've never understood why anyone would care about titles at all.
I cannot understand this sort of notion at all.
1. You don't care about $SOMETHING - great, I can understand that.
2. You don't understand why others care about $SOMETHING - Sure, I can understand that too.
3. You feel a need to broadcast this lack of understanding to the world - wtf?
I mean, I'm ignorant on a lot of subjects, but I hardly ever boast about my ignorance.
It's like when people proudly tell me "Oh no, I've never been any good at Maths": sure, lots of people aren't good at reasoning, but is being stupid something to brag about?
Hint: he's not broadcasting a lack of understanding, he's boasting, posturing, that people who think titles mean something are dumb and he is too smart to be taken in by it. Ideas like "titles look better on a resume to future employers" or "titles make my extended family proud when they know nothing about my job or industry" or "bigger titles get a default level of respect from distant employees within the company" are lost on him.
It's not like when people tell you about their low maths ability, that's generally not boasting it's more trying to make a social connection. Like "I'm humbling myself and admitting flaws, not putting myself above anyone else (which would be rude)" or "you computer guy must be a math person, don't hate me because I'm dumb, please be kind" or "I've never liked <those> people, you're like me, right?" where <those> is book-smart people (or any <other_people> target group).
Aren't you doing exactly the same thing yourself? Your reply literally begins with the words "I cannot understand ..."
> Aren't you doing exactly the same thing yourself? Your reply literally begins with the words "I cannot understand ..."
Yeah, but mine was contextual; I replied to someone complaining that they can't understand. That reply was not contextual, it was simply virtue signalling.
I don’t think enterprise software is by definition bad. You can absolutely make good enterprise software, but doing that while adhering to the morass of requirements is a skill unto itself.
And something that most people in an enterprise are just not all that interested in, since they’re never judged on how pleasant the software they deliver is to use.
Hell, they not ever see any of the users interacting with the software. I’ve been at $ENTERPRISE for 7 years, and I’ve visited our users exactly once.
I was in Enterprise software and even though I didn’t visit users, I dealt with them regularly eg through video calls or engaging with them via support forum if support escalates an issue.
And yes we were judged on how pleasant to use our software was. If we miss a feature or ship a feature that customers intensely dislike, best believe that we’ll get a torrent of negative feedback on our support channels
Agreed. Another point IME is that the problematic requirements are also often non-essential, such as using a certain in-house framework made by some director, or building the whole project inside some abomination, like the workflow system of the Enterprise Content Documentation system.
This is how I’ve seen two-month projects becoming multi-year multi-team behemoths.
In my experience enterprises do not want to pay for excellent software, simply because it is expensive. I would love to work on software that was:
- in more than two AWS regions
- required screen reader / disability support
- required multi-language support
- required multi-cloud
- actually needed a big Hadoop cluster - most enterprise data processing can be done on a MacBook Pro M4.
My second major project at $ENTERPRIsE was 15 years ago and incorporated the first 4 (well multiple servers on different continents, why would I care about AWS)
It was internal shadow IT at its finest. It’s still used today, despite the people at the top not liking it the users think it’s the best thing since sliced bread.
> ... Remy's Law of Enterprise Software ... the list of good things at the end of the post.
Like the poster of the blog article, I too have worked in very large enterprise. Think 200K staff, 10K distinct servers, etc...
I had the lucky opportunity to assist the CTO in hundred-million-dollar enterprise software purchasing decisions. I got to interview vendor after vendor, grilling them to see if they're compatible with "large enterprise".
Most weren't.
This wasn't about some Kafkaesque hoops they had jump through while blindfolded and on fire, although I'm sure that's the impression most of them got.
The requirements were simple and perfectly sound architecture principles that they either met or did not meet. If they didn't meet them, then maybe their software was "good enough" for tiny clients, but would never work at scale.
I even made a list, which from memory was something like:
1. Support single-sign-on from external sources such as LDAP, OAuth, whatever. (We're not going to sync our directory and every user password to your insecure garbage software.)
2. Have some sort of audit log. Administrative or configuration changes especially. (Some places have hundreds of admins, not all of whom are fully trusted.)
3. Have an unattended installation process, even if it's just VM cloning or whatever. (I'm not clicking through your GUI wizard 500 times at 3am on Sunday morning.)
4. Allow incremental migrations/upgrades. I.e.: The "easy" process of stop-the-world; one-way-big-bang; start-the-world process is not viable in an enterprise with 10K tenants where the upgrade may or may not work for all of them on the first try.
5. Scale. This can be as simple as having indexes on "user" and "tenant" tables, which is easily overlooked when the typical dev works with a scale of 1 user and 1 tenant. Similarly, using combo boxes / drop downs is a no-go for most fields such as security groups. (We have 700K security groups. No, we can't delete 699.9K as a workaround to make your GUI not crash from an OOM error.)
6. Accessibility is mandatory. With up to 200K permanent and 1 million occasional users, every disability will be represented. Not just vision or hearing problems, but motor-neuron issues, amputees, etc... (You name it, we have someone on staff with it.)
Etc...
Seen in that light, Enterprise software starts to make sense. It's not baroque or malicious, it's just taken on a certain form to suit a purpose.
For example, I didn't understand why Active Directory uses search dialog boxes for every "picker" GUI control instead of a simpler drop-down or something similar... until I worked in an environment with 2 million objects in the directory.
Great list. I remember being called in to look at software my company was thinking of buying, once... Only our finance/accounting people had looked at it so far. The thing barely worked. The desktop window kept flashing. Special characters were accepted and then broke the output. Extreme lack of features needed for the supposed goal.
I was able to find us an open-source / self-hosted solution that worked far better (bookstack). But I was amazed at how far the company selling the software got with us -- seems like most never get pushback, they just make sales by labeling themselves as fit-for-purpose regardless of whether or not they generally work.
You shouldn’t have 700k security groups though. I know that you end up with that, but it feels like a sign of organisational disease (not that we’re doing much better, but the ratio is more 1 to 1, instead of 3.5 to 1
> You shouldn’t have 700k security groups though
The 700k groups also comes about when the security tools are all inter-operating at the wrong abstraction level. If a third party appliance needs to import all 700k of your security groups it means the appliance is performing authorizations itself, logging it differently than your other apps, and even make decisions based on stale data it's cached (you can't load all 700k groups on every request.)
This task should really be delegated to a dedicated authz system, too bad more of the world doesn't run on Zanzibar.
> For example, I didn't understand why Active Directory uses search dialog boxes for every "picker" GUI control instead of a simpler drop-down or something similar... until I worked in an environment with 2 million objects in the directory.
And that’s when you realize that searching in AD is actually dog slow, and you are better off just syncing the whole thing to a proper database, then checking if the object still exists after.
Seriously, why does a search that takes 1ms in postgres take 3 full seconds in AD?
It's a very simple database engine, effectively the same as Microsoft Access but 64-bit and server hosted. The internal data representation is also sub-optimal because it uses a triplestore (key-column-value) to support LDAP schema changes without having to apply matching SQL schema changes. I don't believe it has any sort of full-text indexing capability either, it just uses ordinary sorted indexes. Hence, some search types are effectively table scans.
>Seriously, why does a search that takes 1ms in postgres take 3 full seconds in AD?
Because when specialization occurs, every specialized component (including people) is selected against performance and other non-essential metrics.
That was an eye-opening insight into enterprise software requirements. Thank you for sharing.
> if a piece of software is in any way described as being “enterprise”, it’s a piece of garbage.
if safety standards are written in blood then enterprise software is written in lawsuits
Disagree that it's written in lawsuits, it's written to please every customer under the sun and due to this, code base has become Rube Goldberg machine that few people understand.
> it's written to please every customer under the sun
Disagree with this. In the places I’ve worked, I’ve lost count of the number of times we turned down feature requests with the explanation that - this isn’t common practice and seems to be unique to you.
I think you are one working at Unicorn. Most Enterprise software I've dealt with ends up with internal coding engine so it can be extended to do whatever the customer needs. Bonus points of getting to charge massive implementation consulting hours for all coders that come along during implementation.
> it's written to please every customer under the sun
Yes, with the caveat that the customer is not - nor does not represent - the actual end-users. The customer is someone in procurement.
...or nepotism is involved.
Commenting just on:
> > It's satisfying to write software used by millions of people. > > Is it still satisfying if that software is bad, or harms many of those people?
I work for a bank, so the software/service my colleagues and I deliver is probably at best "bottom of mind" for most people and at worst actively despised by many (maybe not even our specific implementation of it, but the idea in general that you depend on some behemoth to receive and send money).
Still it's very satisfying to deliver it, because if I mess up it's my mom that will no longer be able to pay for her online purchase or that large energy company everyone knows that can not pay out their salaries. What I do directly impacts people's lives in very practical and real ways. I would really miss that if I worked on some niche SaaS product with a few customers only.
>> There are actual opportunities for career development. > Does "career development" just mean "more money"?
To me it seems it’s related to the specialist-generalist point that it’s easier to focus on one thing rather than to do all the chores you face in SME environments.
> Is it still satisfying if that software is bad, or harms many of those people?
sadly many engineers might detach or feel powerless or simply not their part of the job, and only be attracted to the huge scale. sadly you can only ever work at that scale if you work for a few of the giants, of which mostly all do the same algorithmic dark patterns extraction methods shareholder benefit maximalism capitalism pushes them into
> At this point I hadn't realised that finding who is responsible for something in a large organisation is very much not straightforward.
This resonated strongly with me. Last time I worked in an Enterprise shop, I happened to inherit the approval system - every app in the entire org, whether an internal app or from a vendor, got configured into this home-grown monstrosity of an access approval system. It actually worked well despite being made of spaghetti, but one side effect of being the tech owner was that I knew exactly who was in charge of every system in the organization. At some point I realized that my success there was at least partially due to being the human who knew how to connect all the dots, because when someone needed such info, the answer for the entire org was, "Ask Dave."
That’s because denial of responsibility is one of purposes of enterprises. It’s not an accidental byproduct.
I did a contract at an airline. I was tasked with figuring out why the barcodes a new system was generating weren't scanning. I never did find a person still working there who knew what was wrong, but by sheer persistence I finally found an old email someone had saved a copy o to their space on the company SharePoint. The problem turned out to be the wrong kind of cryptographic signature on content.
Missing
- new leadership will push out the old guard and replace them with friends
- groups get renamed for the Nth time in N years. People continue to do the same job, but now the department has an additional "Innovation", "Discovery", or "Leadership" inserted into the title
> - groups get renamed for the Nth time in N years. People continue to do the same job, but now the department has an additional "Innovation", "Discovery", or "Leadership" inserted into the title
Sometimes, I wish we name the team ‘Pikachu’ and continue on working. This way, others would know the name does not really matter, so they would stop changing the name. The amount of work to change the documentation and lets others know our team changed name has caused a lot of unnecessary work.
God do I hate teams and systems with cute names. It's all cute and fun until you're the one from another team who needs to integrate with you and decode what Pikachu and Tyrion are responsible for, and discover that Fassbender is just a nickname for a Postgresdb maintained by the "It's over 9000" team. AuthService, CacheService, Db and EntrypointTeam are perfectly fine names. I don't care that namespaces are still aligned with 4 names ago, as long as I can somewhat infer what things do based on their names
The upside of having cutesy team names and mascots is that nowadays people just throw something into an AI image generator prompt, and you get a mascot that has clearly been trained on furry fetish art, and during Zoom meetings you get to look around and see who else is trying to stifle laughter when their slide comes up on a presentation.
How much I hate cute sprint names. How is "sweet summer breeze" better than 2023-03? At least I know if it's current or five years old
It won't gonna change how people (mostly management) see the name. I've seen whole empire named after Pokemon, only for another round of restructure that will change teams name to another Pokemon.
While talking to friends at other empire:
> I've been digging around, who are the members of Ludicolo?
> Oh, we've renamed to Felbat.
“Manager, no, you don’t get it. We can’t just name it ‘Felbat’. Pikachu evolves into Raichu, not Felbat. Even then, Pikachu don’t really want to evolve”
I was on a pair of teams (why two teams? who knows) that worked with a given project for about five years. Every year or so, we'd change names - so I've been on "$PROJECT Access", "$PROJECT Insights", and some third thing I forget the name of.
I unironically suggested we just call ourselves $PROJECT RED and $PROJECT BLUE, and refer to the entirety of the team-pair as $PROJECT PURPLE. Nobody liked that, but it is what we ended up calling ourselves internally.
This comment gives me mixed feelings and some nostalgia for when our company was < 100 people and one of the core software teams was called “meow” - today we call it human robot interaction.
>- new leadership will push out the old guard and replace them with friends
My mortal nemesis brings his whole helpdesk and development team across slowly whenever he starts at a new business. Which is crazy, because as far as I can see the benefit to him is simply loyalty. They dont complain or go over his head when he fails to deliver. I have receipts from staff who worked with him at other businesses where he just follows the same pattern.
1. Identify problems (The problem is the lack of a new CRM from a big microsoft partner.)
2. Spend lots of money to fix the problem (Free trips to vegas 3 times per year thanks to the CRM partner and microsoft)
3. Fail to deliver the CRM (The problem was not a big enough scope)
4. Rescope the project. (more bennies)
5. Would have failed to deliver it again however I just got a new job transforming another business enjoy your crapheap.
We have an internal infrastructure-as-code library built on Terraform CDK that automatically provisions monitoring resources in Datadog and Pagerduty. One day, I simply removed a required argument named 'team', realizing that it has a half life of 7 months.
Whenever I see or an initiative have "Excellence" in its name I know it's BS
Everywhere I've worked that added "Excellence" to a name did it when they really wanted to say: "This team wasn't working hard enough before , so I told them to be better now".
Agreed, and a great example of the signal often hidden in anodyne corporate titles.
Cross functional excellence is an important KPI when you want to expand your market leading synergies.
About urgency, there is a simple way to tell what is really urgent and what is "urgent".
If your boss tells you it is urgent, it is probably not.
If people working in the field call you directly, now you have a real emergency.
The reason is simple. If it comes from your boss, it probably went up the ladder, showed up in red in some report made to the top management who then got all worked up, started shouting orders that got down the corporate ladder until it hit you. In reality, it may have taken weeks between the time the problem happened and the time it came back to you. It can wait until you finish your current task.
People stuck on the field are not going to wait that long, they want a solution now and if they can't do it by themselves, they will focus all of their energy into finding people who can and contact them directly, instead of just writing a memo to whoever wants to read it.
> If the selection function for senior leadership is tuned to a certain personality type, you're doomed to repeat your mistakes.
Amen, Amen... Preach brother!
All this rings true, from the complete org dysfunction, to the security theatre, all of it paints the hellscape of large enterprises in great detail.
My own personal struggles in this corner world resonate strongly here. I worked in a large energy company, with layers upon layers of incompetence and waste.
Including paying a consulting company a small fortune to build a data warehouse that was so locked down that they had to pay them more and regularly, to access the data it contained.
Security theatre where bozos would open your desk drawer if it was unlocked and confiscate your paper notes and books unless you crawled back to the apologizing.
> Security theatre where bozos would open your desk drawer if it was unlocked and confiscate your paper notes and books
The ultimate shame. Do you care nought for the security of the ip on those pages?!
This almost entirely applies to any public sector organisation, too - except for:
Remove the comment about ever having to work a weekend
Remove the comment about there being opportunities for (technical) career development
Remove the comment about upskilling / training being encouraged
I'm not sure the opening paragraph's line about "fun and financial profit" applies either.
fun depends on the person, some people like masochism.
financial profit, again, depends on the person but those $ENTERPRISE 401k's are pretty nice w/ company matching.
Very fun and interesting article. I'm currently working in enterprise for around 3 years. I sure am growing technically, but I feel like I learn more about people, communications and bureaucracy here. That comment about budget and mouse is also on track, but with financial stability that working in $ENTERPRISE brings, I can just buy the mouse myself. Maybe some empire will question me regarding the unauthorized mouse, but I can just... ignore... um, talk myself out of the fake urgencies of mouse authorization.
s/mouse/COL yearly raise
If you prefer. Millions wasted on projects going nowhere fast, it no budget for even keeping up with inflation for salaries.
This article is highly relatable. IMO, everything is done better in startup land except one single thing; enterprise people are willing to concede that everything is complex. This is the one piece of wisdom that enterprise people understand (and often abuse to maximize their billable hours).
Startup people tend to neglect complexity and repeatedly underestimate the harm which comes as a result of 'cutting corners'. The hilarious thing is that once in a millennia, a hot startup like Facebook comes along and grows at such an incredible rate, that they can basically get away with cutting all corners... Proving the exception, not the rule; most startups who try this same approach invariably go out of business because it turns out that technical debt is actually very expensive; not every company can afford throwing hundreds of highly paid engineers at the problem of refactoring a code base over and over... Not every startup can afford to rewrite an entire PHP engine from scratch to achieve a modest speedup.
But the thing which is funny about this is that a startup like Facebook/Meta attracts so much attention that everyone is clamoring for their advice... Literally, everyone wants to take advice about reality from a company whose experience of reality is unlike that of any other company which has ever existed or will ever exist in the foreseeable future... I do believe that the average entrepreneur has more to learn about startups and software development from a bum on the streets of San Francisco than from a tech exec.
I can't handle such organisations. I simply cannot. I don't care if they pay 3x, they break me within a few months.
Sometimes I consider optimizing for money, and getting a much higher paying job at $ENTERPRISE, then peacing out once I have enough saved for an extended sabbatical. But just the thought of going through the interviewing hazing ritual takes the wind out of my sails immediately.
I'm currently at $MIDSIZENOLONGERSTARTUP, which incidentally has its own slew of insane and draining things that are breaking me in its own way.
> ...interviewing hazing ritual...
In my experience it's the small shops who are more likely to batter you with 12-stage interview processes, LeetCode-style tests, and creepy 'Record a video of yourself talking about why you want to work for BONTO' exercises. I've worked nearly my entire career at enterprise companies, and I can safely say they've always treated me with more respect in both the interview process and the job itself, than the smaller companies. Keep in mind, I live in Australia, and I've never worked for FAANG, which will skew my perspective.
> But just the thought of going through the interviewing hazing ritual takes the wind out of my sails immediately.
Several times, I've been ready to do really great work for my two favorite FAANGs, but their insistence on the hazing rituals wipes out any interest I have.
One must think Sisyphyus happy, right? At the end of the day we’re just swapping our boulders for boulders.
Compensation is inversely proportional to how much work you actually need to do.
> As paradoxically as it sounds, aside from the rounds of redundancies the job security feels quite good.
As paradoxically as it sounds, aside from the rounds of russian roulette my health feels quite good. ... what?
Should you really just accept that and still claim job security?
Is this what stockholm syndrome feels like?
I think it's relative, really. The redundancy waves have a rhythm to them, and if you avoid one you're safe until the next. Contrast this to one of my previous experiences at a startup where I came in on Monday to discover there was no money, the CEO had been funnelling company funds to his boyfriend and once discovered the small office had turned to Lord of the Flies.
I wouldn't say I have the perfect job security, but I'm reasonably assured I'll get paid this month and I try not to worry about situations that haven't happened yet. I think if I had a family that depended entirely on me I'd be much more concerned.
I'm not sure I'd call it stockholm syndrome directly, but I'd agree it's definitely some form of conditioning.
That is somewhat of a sensible view if you've seen the worst of the worst in startups - I just feel that rounds of layoffs are more common; but then again I work in a government-y enterprise situation with no layoffs.
I've only really worked for $ENTERPRISE and for just a single reference point the last two places I worked spent >$10M/month on their AWS bills. Most of the points in the article ring true to my experience. I will say that reading comments on HN/X/Reddit/etc it sometimes feels a bit lonely in that even though I know I work with tens of thousands of technologists, I rarely see the unique challenges in getting things done represented in even the slightest way.
I'm in a similar environment and found this article painfully accurate. I keep thinking my job is to solve problems and ship software...but those are clearly not the revealed preferences* of my org.
The author went from small companies to a big one. Has anyone gone the other way? I'm looking to make that shift and I'm curious how others framed their Enterprise™ experience in a way that resonates with smaller teams.
It's a tale of two cities, in my experience. Much like you, I'm sick of wasting away the best years of my life doing nothing of consequence at $ENTERPRISE and I'm willing to take a 20% pay cut at this point for a chance to actually ship things at a small company.
Unfortunately, I've found that describing what I've learned over the past three years (without any negativity) gives founders the ick. The survival skills you need in the jungle are very different from the ones you need in a zoo, and they feel I've spent too much time in a zoo.
Similarly, large companies want to hire people who understand the value of processes and hierarchies, and interviewing at these places is a challenge for those who have spent most of their career in startups.
> I'm willing to take a 20% pay cut at this point for a chance to actually ship things at a small company.
Unfortunately the pay cut might be a lot bigger than 20%. I've seen people have "the same job" where one gets paid $300k p.a. at FAANG and another $60k at a small company (while getting a lot more done).
> Unfortunately, I've found that describing what I've learned over the past three years (without any negativity) gives founders the ick. The survival skills you need in the jungle are very different from the ones you need in a zoo, and they feel I've spent too much time in a zoo.
Try describing where you want to be and not so much where you have been.
By that, I mean when interviewing with smaller organizations, pick out the things you have learned which would be beneficial to a much lesser funded effort. For example:
- automated builds are repeatable
- unit/feature/integration tests translate to lower costs
- too many layers of management stifles progress
- <insert other lessons you have learned here>> The author went from small companies to a big one. Has anyone gone the other way?
I have and the biggest difference is that the larger the company, the more the problem to solve is interpersonal and/or group politics and not technical issues.
Large companies typically take a Golden Handcuffs[0] approach to retain valuable employees. Usually, this makes people who have options to leave accept more organizational bovine excrement than if the financial carrot stick did not exist.
As to how to frame the "left mega-corp to effect change" argument needs to be framed... Well, that's about it. Every smaller team I have had the privilege to work with has understood why I did.
Pretty accurate having worked for startups and $ENTERPRISE alike.
I recently switched from startup to $ENTERPRISE and the thing I’m struggling with the most is time zones. My manager is 11 hours ahead and infrastructure/security change approvers are 6 hours behind.
Now add the big shift back to on-premises infrastructure and it’ll be impossible to get anything done.
Wait, big shift back... tell me more.. you mean to say that someone stopped suckling at the teat of big cloud ?
Gartner claims 25% of the Fortune 500 are currently working to move back to on-prem for the majority of their applications. It’s not sexy so doesn’t appear in tech news as much but it’s happening
> Then I heard word there are other empires. Some were run by tyrannical rulers with strange idiosyncrasies. I began to hear strange whispers, like the next empire over doesn't write any tests, and their only quality assurance process was an entire off-shore team manually clicking through the application. Or that an empire in a distant land has pyramids of software that touch the sky, crafted by thousands of people over decades.
Other empires besides the British (with plantations of manual QA) and the Egyptians (pyramids): the Mongols (ride in out of nowhere to bombard you with requirements and have ridden away before you figured out whether you actually need to deal with them or not), the Spanish (who insist that El Dorado isn't a fictious utopia of a project with full test coverage, full CI/CD, perfect monitoring, but will add every linter and bit of friction they can find to try to get there), the Japanese (who go to floors and campuses across the oceans to commit career suicide by yelling at random stakeholders that they have displeased The Emperor), the Chinese (their floors are always quiet, good luck finding your way through the Forbidden City of Zoom meetings without a map)...
I really enjoyed how you ran with this thought, it made me chuckle. I've been warring with the Mongols for some time and if history is anything to go off, things aren't looking great.
Thanks for reading!
I'm in a similar situation, having left a startup a year ago to work at $BIGCORP, naively thinking it would benefit my résumé. This is all painfully accurate.
The other thing about working for $BIGCORP is that it molds your skills to be hyper-specific to this company. It's less about learning to use cool technology stacks, than it is about learning the internal tools, procedures, and unspoken etiquette of the company. Skills that are vital to navigate the everyday complexity of $BIGCORP, but that you can't really export to any other job.
On the other hand, working at $BIGCORP will probably give you very good domain knowledge (as $BIGCORP's software is likely complex and actively used by many many people who signed very expensive contracts, and besides that also the knowledge on how to navigate the internal complexities of a $BIGCORP) that will be useful for work in other companies?
Yeah that's also true, to a degree. Clearly, there are interesting challenges that I would have never been faced with had I stayed at a startup.
But I also found that once you reach a certain level of expertise at $BIGCORP there are few opportunities to try to push the boundaries of your domain knowledge, lest you are dead-set on taking initiatives and swim against the current of a rigid organisation. That may just be specific to my job and employer though.
And while the part about navigating internal complexity is true as well, it's harder to highlight on a CV than "I have worked with technologies X, Y and Z". At best you can say "I have worked with X at a big corp, and also Y, which you probably don't know because it's an internal tool." You just have to hope that the name of your employer alone carries enough weight on its own.
> that will be useful for work in other companies?
No. But all those tools and processes? Those are valuable at smaller companies -- or maybe even a SaaS when you leave.
Tools and processes from Meta or Google? Yes, absolutely.
Tools and processes from “third-place mobile phone operator in country X” or “leading grocery wholesaler in country Y”? Most likely not.
The world is full of quite large companies that need surprisingly much software and are very bad at it.
The tools and processes we have here, I would not wish them on any other company, especially a smaller one.
You often can’t see what problems they were built to solve. But go work for a company transitioning crossing the threshold at 100-200 employees and you’ll think “oh, that’s what that annoying process was trying to solve”. The problem is that many people try to use technology to solve people problems instead of recognizing them for what they are.
Bigger enterprises only care about consistency in delivering what they want to deliver. The actual goals may be set by chasing a number, regulatory process, executive fiat or a million other things.
Rationality as we humans see it doesn’t apply.
Also missing: - vendor review takes 18 months - adding a new product with an existing vendor triggers a totally new vendor review for unknown reasons - you get promoted by building complexity that should never need to exist
Great read, would love to hear more from you
Fun read, from a Swedish background "Uncertainty is weakness" seems so very American though and the opposite of both how we operate and what TheRightWay (tm) should be. As a senior dev working as a consultant for the past 8 years coming in and questioning how things work and recognizing what's unknown or doesn't make sense on a daily/weekly basis sometimes feels like my biggest contribution to the team and usually starts many interesting and productive sessions.
> In these situations a good manager is what makes the difference; some will fold to the pressure in the hopes that being a "team player" will get them brownie points from leadership (it wont), and some will stick up for their team out of decency and hoping it will get them brownie points from their colleagues (it will).
One of the dimensions I judge my managers on is the "I screwed up, what now?" factor. A good manager will be the shield between me and the higher-ups and will meet with me to discuss the issue to understand it better. A bad one will tell me everyone including them is angry at me. So far I've been lucky to mostly have seen the former.
It hurt to read this. I have seen all of this and more.
- Teams that produce negative output for years with no consequence
- Six figure monthly AWS bills on unused resources
- Technical people who can't use a computer
- Constant re-orgs and turn over
It is hell, but it pays. I get my fulfillment building my own things outside of work and dream of the day I can escape.
I don’t have the energy to build anything outside of work. I spend all of my free time trying to mentally recover. I’m left drained after work. If I’m going to do extra “work”, I always think I should do more work stuff, to attempt to get ahead on some project and reduce the stress of things than have been hanging over my head.
The only time this shifts is when I have a couple weeks off. During that period I will inevitably start some kind of project, but I have to keep it small, because I know it will die as soon as I start back to work again.
It took me a while to realize that there is no getting ahead. Something else is always waiting, so better for my health to prioritize and make those whose job it is to prioritize actually make the hard decisions they're paid to make.
There is always more to do, sure. But I’ve found there is value to being ahead of expectations.
In my experience, no one is willing to make decisions on what is actually a priority.
To channel Peter from Office Space, my only real motivation is to not be hassled.
I think that your motivation is going to burn you out.
In order not to burn out one has to start prioritizing other things higher than work, like your health or your hobbies. That means thinking: "someone wants this done and will hassle me for it, but I'm letting it go now."
Edit/addition: there will always be more things to be hassled about.
> I always think I should do more work stuff, to attempt to get ahead on some project
Are you a manager? Are you, personally, responsible for this stuff working or not working?
If not, don't let it hang over your head. You work at the circus with the monkeys, but they are not in any way meaningfully your circus or your monkeys.
Its moments when I read things like this that I'm thankful for my colleagues.
Been at $ENTERPRISE for 18 months. This is true it hurts.
I've been at $ENTERPRISE for 20 years... I dont mind it tbh. Its only soul crushing if you let it be.
It only crushes your soul if you let it eat at you 24/7.
Clock in in the morning, clock out in the evening. It's just a job (I repeat to myself like a mantra.)
Thanks for sharing. A lot of insight about office politics and the importance/role of the management
I once worked for an $ENTERPRISE which made, among other things, office telephones. Like the real physical ones, with buttons. I also found the problem with no one knows what X is or who owns it.
My solution was to just PICK UP THE PHONE and talk to the last person who had a commit in the version control system on that thing. Which worked fine until I tried calling an engineer in Elbownia, when I realized that part of what made offshoring so profitable was that this company, who made phones (and softphones) didn't even give phones to people outside of North America and Europe.
> Maybe I'll come back in 9 years and see how my views have changed.
I'm in year 10. My views are pretty much how you've outlined here. Some differences based on my $ENTERPRISE vs yours, but overall not a wide gap.
And I wouldn't say that's necessarily a bad thing. Once you've adapted and realize where to look for who and what and how to prioritize and estimate your time, you're pretty set. Company succeeds and you succeed.
Good luck, OP!
This article was worth it purely for "Schrödinger's urgency"
Yeah, point for point this sounds like exactly the enteprise I find myself in.
I think the difference is that different engineering team empires always push us to use their stuff, which then inevitably ends up being garbage.
> Getting paid on time.
It's incredible how starting a family and hitting your 40s moves this bullet point to somewhere near the very top of priorities for work. For all the complaints I've had about work over the past few years, I always finish it with: "But the paychecks don't bounce."
Also if your preferred method of non urgent communication is message based such as slack, good luck in an enterprise.
Sure you'll get messages, but every one will be "quick call?"
A “quick call” usually means a re-org or a layoff in my experience.
I once had a boss who used to day, “got a second” every time he was pulling someone out to lay them off. He said it to me once and my stomach dropped… turned out he was just giving me my review. I told him to never say that to me again. He had no idea the entire team picked up on that phrase and it had a reputation.
If it is a higher up, someone I am actively working with, or someone I know well, then I take the "quick call". Otherwise, I push back and ask them to write out their question somehow.
This ends up a few outcomes, usually positive:
- They give up (pretty common)
- Writing it down helps them to answer the question themselves
- I can directly answer with a response or link to the relevant docs
- We have an actual agenda for the meeting they want to haveI do this in a startup. Mostly when we have an ongoing conversation and it gets too tedious to explain something elaborate in text, when we could just talk it over and maybe share the screen or look at something together.
I get the text-based communication preference, but I’ll stand by calls being far more efficient sometimes.
I generally like text even if it might take slightly longer to communicate, as it can then be referred back to later easily, and often the mental effort and time required to put it into words in the first place often means you have a clearer mental model of what you're trying to convey in the first place.
One thing I've seen work well is to write up the conclusions of the call, then ask the other person or people in it to review/edit.
That way, you get the benefits of higher bandwidth on the back and forth getting to those conclusions and then still get most or all of the benefits of written communication that you mention.
It sucks when your communication preferences are overridden! To be fair though, many valid reasons to prefer a quick call over a message (a potentially infinite sequence of messages, really). Even on the receiving end of a request: perhaps I want to poke around the context behind their non-urgent ask, like what they are _actually_ trying to achieve, why not do X instead etc. -- often easier to call and solve all the follow-up questions interactively on the spot.
I understand that async communications has some benefits, but I am continually flabbergasted that instead of weighing async & sync comms suitability for different situations, we've landed in a place where everyone is terrified to make or receive a phone call.
People adopt the communication style of others. If the “quick call?” method is common, it means that many of its users don’t want their communications logged, meaning they commonly ask for sketchy stuff. Act accordingly; i.e. always send a follow-up email summarizing what they asked you to do, and give them the opportunity to change their tune.
>If the “quick call?” method is common, it means that many of its users don’t want their communications logged, meaning they commonly ask for sketchy stuff.
In my experience, the reason for most "quick calls" isn't quite this nefarious. It's usually just about making a request for which the asker wants immediate confirmation of handoff, and/or for which they haven't done much thinking or built a good justification, and they are proficient at controlling synchronous conversations to avoid questions and clarifications while still getting to yes.
/cynicism And, there are plenty of people out there who genuinely do prefer the personal touch and talking to others.
The cynic view is so true. Quick calls are so often made to not have to meddle with actual requirements, and indeed to have the freedom to change the requirements in a future "quick call".
I mean conversely you will absolutely get advised by lawyers to not use email for discussions about things which might be litigated. But this happens at any scale: it's evergreen advice.
Agreed. I've seen multiple large enterprises where messaging was common (perhaps with a bit more emphasis on emails than normal) and calls were not. It's not an inevitable consequence of scale.
I moved from startup to enterprise a couple of years ago. I never realised a job could be simultaneously so easy, while also being so frustrating.
It feels like there's very little commercial or technical juice, and very low standards. Frankly this became even more noticeable after the last wave of offshoring.
The "cloud sales" & "enterprise architecture" nexus has got a lot to answer for as well. There's an entire parallel ecosystem of people whose job is purely to sound impressive to non-technical stakeholders and then funnel money to AWS. Currently these guys are busy rebranding as "agentic systems" experts, just like they went from being OOP to microservices experts in the 2010s.
>> ... culture shock trying to reconcile the scale of the monetary waste ... Your entire retirement fund spunked in two weeks on a project that was doomed to fail from the offset.
I can very much relate to this point. I once worked for a company which spent more each month than I could save in my entire career... And they basically did absolutely nothing with it... The same company offered me a 2% raise while saying that I was their top engineer and that me threatening to quit was akin to "holding a knife at the company's throat". I followed through on the threat, the company is still fine, still spending over $1 million per month, still achieving nothing... Meanwhile, I've been desperate to do my own startup ever since, built stuff that would put their puny systems to shame... and yet I never managed to earn above $1000 per month from my own projects.
>> Generational wealth being funnelled directly to Bezos's mega-yacht via AWS
My wife made a similar joke when she saw my recent AWS bill though it was about our contribution to Bezos' wife's massive diamond ring. My wife then said "We can't even afford to do my fillers" to which I responded "Meanwhile, she can afford so much fillers, there's barely any space left for her meat."
Then my wife laughed and said "You're funny, that's why I married you."
Just kidding, she laughed and said "You loser, when are you going to shut your mouth and start earning money?"
Love it. Describes my new job at $ENTERPRISE very well.
If you work at a real enterprise that actually takes security seriously I can assure you a large portion of it is not theater. You will find this out when they come knocking and point out something boneheaded that happened on your watch. I once had an intern that mistakenly committed a non-prod credential into source control. They realized their mistake and replaced it with a token. But not before it had triggered some infosec alert and they blasted me with a stern “ACTION REQUIRED” email. I also had people on my team get snagged by simulated phishing emails and other such things which are run constantly.
> But not before it had triggered some infosec alert and they blasted me with a stern “ACTION REQUIRED” email.
Why didn’t it fail the build before it was committed if they can automatically do this
I've worked in technology for 20 years, and at least 15 of those have been inside large enterprises. In my experience, technological innovation is almost nonexistent in these environments. Most people in enterprise IT are not deeply connected to technology itself — many come from unrelated areas, grew into roles without genuine interest in the craft, or were absorbed into the system through inertia. The result is a cycle of delays, low standards of software development, and a near-total disregard for quality and maintainability.
On top of that, the consultancy model dominates: endless "transformative" projects, pitched with buzzwords, costing upwards of $300,000 per month for an "agile squad" — usually 5–6 junior or mid-level developers rebranded as "senior." Value delivery is irrelevant because another part of the enterprise machine is dedicated to "protecting" budgets, ensuring they don't shrink year over year, and inflating headcount so managers can parade the size of their teams.
This creates the elephant-in-the-room effect: organizations that are slow, rigid, and performative rather than adaptive. In more than one company I've worked at, it was rare to find someone on a technology team who could even write a simple SQL query. But they were experts in "agility," microservices, and "scalability" — all while serving theie super systems/projetcs with a super number of 8 daily users and a mess of integrations with SAP, Salesforce, or whatever the enterprise flavor of the month happened to be.
With that I can say, it's frustrating, it's messy,full of political interactions, but it pays the bills, but it's still shit, maybe you decorate it a little here or there, but in the end it's just decorated shit.
It's just so so sad that the cost of living is so high, that it's so hard and sooo risky to strike off on your own & to try to get stuff started.
How the world has captured so much potential, such an amazing era, and lashed it to this middling servitude is so sad. But it feels so impossible to try to begin better, the odds so stacked against us, the society about us so cowed and so FUD'ed up against "socialism" as to be unwilling to do anything to improve access to health care child care housing food and utilities. All ventures made available to the already wealthy.
Fuck enterprises, and worse, fuck this too scared world for being propagandized into cowardice that obstructs human spirit from being able to make a real go at better.
“The menu is not the meal” - what a great spin on “the map is not the territory”.
[dead]
[dead]
[flagged]
Happy for you man!
I think people have these kinds of thoughts (and then commit them to paper) because they're utterly flabbergasted that such things can exist - as if there's some kind of massive conspiracy by Big Enterprise that enables this even though both $ENTERPRISE and SMEs play in the exact same market (by definition).
Newsflash: yes small organizations are better solving small problems (like "small tool has broken feature X"). Everyone knows that and feels it "on their skin". But they cannot solve large/enormous problems. It's just physics: big problems -> big requirements. Think stuff along the lines of "getting to the moon" or "building the Chunnel". Myopic individuals, who are bound to only see and understand work within their own vicinity, necessarily will bemoan the existence of large organizations. This is why reading history is valuable - because it is indeed myopic.
You're conflating development with operations. Many of the greatest software tools we use every day were built by small teams.
Your examples of big projects are great, but the majority of enterprise companies are not sending people to the moon or building physical infrastructure. If you look at the top 20 companies in the United States by headcount, the majority of those companies are large because they require a physical presence all over the country (Walmart, Home Depot, Marriott). The largest company that does not require a physical presence is Cognizant. Has Cognizant ever made anything worth using?