The Enterprise Experience

The Hacker News discussion revolves around the stark differences and shared experiences of working in large enterprises versus smaller companies or startups, touching upon organizational culture, project management, communication, career progression, and the nature of "enterprise" software itself.

The "Enterprise" Metaphor and Dysfunctional Organizations

A central theme is the use of historical empires as a metaphor for various types of large organizations, highlighting their often-dysfunctional or idiosyncratic ways of operating. Users draw parallels between the perceived vastness and bureaucratic nature of empires and the challenges of large corporate environments.

• "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)..." (solatic)
• "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." (churchofturing)
• "I can't handle such organisations. I simply cannot. I don't care if they pay 3x, they break me within a few months." (gherkinnn)
• "I've 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." (time0ut)
• "This article was worth it purely for "Schrödinger's urgency"." (fergie)
• "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." (Simon_O_Rourke)
• "My humble opinion is that enterprise software is not intrinsically bad. Yes, you can absolutely make good enterprise software, but doing that while adhering to the morass of requirements is a skill unto itself." (Aeolun)

The Scale vs. Agility Debate: Big Problems vs. Big Organizations

A recurring point of contention is whether large organizations are inherently better equipped to handle large-scale problems, or if their size leads to inefficiency and a lack of agility. Some argue that big problems require big solutions and thus big organizations, while others contend that large enterprises often fail to deliver even simple improvements due to their structure.

• "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." (almostgotcaught)
• "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)." (almostgotcaught)
• "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." (linkage)
• "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." (linkage)
• "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." (mcdrake)
• "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." (AdieuToLogic)

Communication Styles: "Quick Calls" vs. Written Communication

A significant portion of the discussion focuses on communication preferences, specifically the ubiquitous "quick call" request in enterprise settings and its implications compared to asynchronous, text-based communication.

• "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?"" (i_love_retros)
• "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." (teddyh)
• "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.)" (nlawalker)
• "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." (9dev)
• "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." (kimixa)
• "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." (davnicwil)
• "A “quick call” usually means a re-org or a layoff in my experience." (al_borland)
• "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." (time0ut)

Career Development and Titles vs. Meaningful Work

The concept of "career development" within large enterprises is dissected. While some see opportunities for growth in taking on larger projects or leadership roles, others view it as a move away from hands-on technical work into managing processes or hierarchies, or simply a pursuit of titles. The trade-off between meaningful work and the perceived stability or perks of enterprise jobs is a significant theme.

• "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?" (BrenBarn)
• "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." (beering)
• "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’" (Agingcoder)
• "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." (marssaxman)
• "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." (throwaway346434)
• "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." (churchofturing)
• "In my experience, the larger the company, the more the problem to solve is interpersonal and/or group politics and not technical issues." (AdieuToLogic)
• "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." (AdamH12113)
• "So I am guessing that is what he means by "career development"; you can acquire impressive titles." (lelanthran)

The Nature of "Enterprise" Software and Its Requirements

A significant thread concerns the definition and characteristics of "enterprise" software. Users debate whether the term inherently implies poor quality or if it reflects the complex, often contradictory requirements driven by large-scale deployments, compliance, and diverse user bases.

• "if a piece of software is in any way described as being “enterprise”, it’s a piece of garbage." (Remys Law of Enterprise Software, quoted by BrenBarn)
• "if safety standards are written in blood then enterprise software is written in lawsuits" (nikcub)
• "it's written to please every customer under the sun" (stackskipton)
• "Yes, with the caveat that the customer is not - nor does not represent - the actual end-users. The customer is someone in procurement." (DaiPlusPlus)
• "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." (jiggawatts)
• "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." (jiggawatts)
• "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?" (Aeolun)
• "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." (Aeolun)
• "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." (hdgvhicv)
• "In my experience, no one is willing to make decisions on what is actually a priority." (al_borland)
• "The value of processes and hierarchies is something that you learn in large companies, and it is a factor that is very important for most founders." (linkage)

Financial Incentives and the "Golden Handcuffs"

The discussion touches upon the financial aspects of enterprise work, including attractive compensation and benefits, contrasted with the often draining nature of the work. The concept of "golden handcuffs" – financial incentives used to retain employees despite job dissatisfaction – is also mentioned.

• "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." (Trasmatta)
• "It hurts to read this. I have seen all of this and more. [...] It is hell, but it pays." (time0ut)
• "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"." (jongjong)
• "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." (AdieuToLogic)

Other Notable Themes

• Interviewing as a "Hazing Ritual": Several users express frustration with arduous and often irrelevant interview processes, particularly at large tech companies.
  • "But just the thought of going through the interviewing hazing ritual takes the wind out of my sails immediately." (neilv)
  • "...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." (ajxs)
• Team Naming Conventions: The practice of giving teams whimsical or generic names, and subsequent renamings, elicits commentary on its perceived ineffectiveness and the administrative overhead it creates.
  • "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" (3eb7988a1663)
  • "Whenever I see or an initiative have "Excellence" in its name I know it's BS" (vjvjvjvjghv)
• Security Theatre: The concept of security measures being performative rather than effective is raised, with examples of strict rules that seem to achieve little.
  • "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." (Simon_O_Rourke)
  • "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." (Simon_O_Rourke)
• On-Premises vs. Cloud: A brief mention of a "big shift back to on-premises infrastructure" suggests a potential trend or internal change within some large organizations.
  • "Now add the big shift back to on-premises infrastructure and it’ll be impossible to get anything done." (stroebs)
  • "Wait, big shift back... tell me more.. you mean to say that someone stopped suckling at the teat of big cloud ?" (worthless-trash)