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.
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.
> 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.
> 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.
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.
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.
> ... 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.
> 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?
- 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
>- 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.
> - 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.
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?
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.
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.
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".
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.
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.
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.
> 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.
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.
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.
> 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.
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
Wait until this guy experiences the wrath of big consultants...
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.
You can still toy with ideas without putting much effort into them, just to keep the creativity going. I’ve been so overworked that I even stopped doing that but luckily I got a break now, not sure how long it’ll last but slowly an getting back at trying new ideas. AI is fun to bounce ideas back and forth.
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.
I 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.
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 have
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.
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.
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.
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?
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.
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.
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.
> 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.
> 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.
> 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.
> 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
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.
> ... 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.
> 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?
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
>- 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.
> - 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.
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.
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.
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".
Cross functional excellence is an important KPI when you want to expand your market leading synergies.
"Excellence" was a huge miss on my part!
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.
* https://en.wikipedia.org/wiki/Revealed_preference
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.
I can't handle such organisations. I simply cannot. I don't care if they pay 3x, they break me within a few months.
Compensation is inversely proportional to how much work you actually need to do.
The key is to be on a heroic dose of zoloft.
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.
> 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.
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.
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.
Been at $ENTERPRISE for 18 months. This is true it hurts.
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.
> 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!
It hurt to read this. I have seen all of this and more.
Wait until this guy experiences the wrath of big consultants...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.
You can still toy with ideas without putting much effort into them, just to keep the creativity going. I’ve been so overworked that I even stopped doing that but luckily I got a break now, not sure how long it’ll last but slowly an getting back at trying new ideas. AI is fun to bounce ideas back and forth.
Thanks for sharing. A lot of insight about office politics and the importance/role of the management
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.
I 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.
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:
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.
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.
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.
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?
Happy for you man!