Yes. It even happens at medium sized companies.

One answer is to accept the way things are at BigCo and to just coast along in your role, which is not necessarily a bad thing.

Another answer is to work at an early-stage startup or a small non-tech company where you can move fast. The tradeoff there is lack of job security and lesser pay.

Don't ever expect to move fast at BigCo. It's a BigCo for a reason. By moving fast, you could upset the cash cow, hence the friction placed in front of you. But this can work in your favor. Excellence will not be expected of you at BigCo, and if anyone complains about why nothing is getting done, you just repeat exactly why. As long as the company is making money and you haven't made any enemies, the chances of you getting fired are slim to none.

IMO, you have to look at the big picture. If you ignore the friction factor, is life at BigCo so bad? Are your hours reasonable? Do you like your coworkers? Good pay? Learning to let go your frustration with how you think the company should be run may be the most favorable choice. Remember, all jobs suck, more or less. A year after you change companies, you will find things to hate about that one as well.

OP, there's a lot of wisdom in this comment. I suspect you might be 20-something instead of 30-something, and in hindsight I wish I'd relaxed more. And I especially wish I'd learned to play the politics game, or at least pay attention to it. Your alliances will make or break your career at BigCo. You should make sure that your manager feels like you're directly advancing their career, not just yours.

I suggest channeling your ambition into your own projects, hobbies, and interests. If I'd spent more time making my own game engine rather than working on theirs, I'd still have it today.

OP, I’m also a twenty something that moved from a fast paced start-up to a Behemoth.

It’s been 7 months so far and throughout the first 6 months, I have fought and resisted how BigCo operates—it left me tired and even more miserable. Within the last month however, I have stumbled across the same advice as has been given by the wise members above. This advice is invaluable, accept that within these organisations a lot is outside of your control. Rather, focus on projects, learning and hobbies outside of your work that bring you joy.

If your feelings remain unchanged within a couple of months to a year then consider making a change to another Co. Good or bad, these experiences are invaluable in helping us to decide on how we wish to pursue our careers.

Early in my career, I wasted way too much energy and emotion getting upset about things that I probably couldn't change and just didn't matter. I'm not talking about just going with the flow on everything! But I did get unnecessarily upset and angry at people way more often than I should have.

Do you guys ever think there's more to life than being really really really ridiculously well compensated?

When you have a wife and kids the pressure is on earning. It’s fucking expensive to have a family.

But do both you and your wife have to be at BigCo? Maybe you could take a more flexible, fulfilling job that lets you have more time with the kids while she focuses on money. Break those gender stereotypes?

It's expensive to live in the bay area and try to do everything well.

Nobody in my family ever made more than $10/hr growing up. I turned out okay. I think. :)

I will simply not do that

There is. That's what the ridiculous compensation is funding.

From MediumCo I will say: there is a lot of friction, quite intentionally, when you go off the rails. As a backend engineer, messing with things like VMs and SSL certificates yourself is definitely way off the rails. We want that to be hard. You are supposed to be creating and iterating on services using the standard application frameworks, deployed to the standard shared clusters, communicating through the standard service mesh, etc. where all of that is handled automatically.

Make sure there's not a golden path that you're missing? Or that your reasons for departing from it are really insurmountable?

work at managed service provider

everything is a ticket

ssl is expiring,

- make a ticket for the customer,

- request a quotation,

- wait for approval,

- finally issue the cert manually,

- finally deploy it (manually, using some tool of course)

Reminds me of when our license for ElasticSearch was expiring, the process took so long (we wrote a countdown application to test out our local PaaS) that it had expired, and just silently turned off secure auth.

Seems totally reasonable to me.

If you can have such a structured, rote process then why isn't it just automated/self-serve? That is one thing I like about my medium-sized (public) company, you can't necessarily touch things yourself but you only wait in line for human attention if your request is somewhat unusual or actually calls for discretion and creativity.

"Because our users are irresponsible, and will order 1000's of dollars of externally signed certificates..."

shock horror maybe they might actually ... get more done and therefore need more stuff :D

"let's encrypt is not good enough, our customers are "enterprise", bla bla"

> One answer is to accept the way things are at BigCo and to just coast along in your role, which is not necessarily a bad thing.

Sound advice.

The HN community (rightly) skews towards entrepreneur hackers who have a general distain for BigCo employment.

I love this quote from Prof G on joining BigCo:

https://youtu.be/ffDVe-NgFt4?t=662

You're going to have access to what is the greatest wealth generator in history and its called the US Corporation.

On a risk adjusted basis, you're better off working at a Big Corporation

> The HN community (rightly) skews towards entrepreneur hackers who have a general distain for BigCo employment.

On the contrary, I find that most work at bigco or smaller companies and come to HN to play out their dreams of what it would be like to take the risks that people with lots of wealth can make freely

Seems like the more wealth you have the harder it is to make risks…

Also probably true.

This is a great comment. I urge OP to take this on board

Look at the lifers at BigCo, and how they roll with it. They choose their battles carefully, they don't fight the system. They are good colleagues, and they are paid well for their long service. They also go home on time!

Not disagreeing but you can't just give up and coast along either. Don't get me wrong, I've been doing it for a couple of years and getting ready to quit my job because of it. It gets frustrating and a tool that's not used frequently loses its edge.

I'd say do a couple of things -

a) Provide constructive recommendations on the specific friction points. Sometimes, especially coming from a small company background, you fail to realize the need for a process or review. It doesn't mean it can't be improved but resist the immediate urge to hate it.

b) Plan ahead. Once you get familiar with how the processes work, set aside time to raise request before you actually need the resource. I was terrible at this and it came to bite me many times. Anticipate and plan ahead.

I've worked at a few startups that have this problem too. Mostly because tech leadership came from a bank.

I would never hire someone again if they have worked at a bank for more than a couple of years.

I worked at a bank for 8 years, but I learned how to work around the red tape and get things done. I wasn't alone. We had a ridiculous project approval process for any work that would take more than X man hours. They'd shut you down because you didn't have have approval for the budget. Yes, even though they're paying you to sit at a desk, you have to get executive sponsorship for the budget to cover the wages that they're paying you anyway. But if you know your way around the incident / problem / change management processes and you know enough of the userbase, you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem", you get pulled into the next problem review meeting and asked what can be done. You think about it, tell them you have a solution but it'll take a few weeks to build and test. And either you skip through change control because it's a production incident, or the problem management team do all the process for you.

> you can get 10 incident tickets created over a 1 week period, this gets picked up as a "major problem"

This is an interesting perspective but perhaps crosses the line.

Thing is, they were genuine "issues". The bank developed internal software following the waterfall model, with 6-12 months between major releases. Each release had to have a project with a budget. Each release had enormous cost (with individual line items like "$1m: system testing" on the bill). And there was a somewhat passed rollout, but it was pretty much big bang at the end of the dev/test cycle.

After a release, there was a very short period of watchfulness where issues found in production would either be marked as "minor" (this will hold until the next release and the users be damned) or "major" and the entire system would be rolled back (for now). So every release had a bunch of awful bugs that drive users insane. They'd complain, of course, but the senior brass would just disperse "release notes" via fax to the branches and tell them how to work around issues. In other words "button it". So the users wouldn't create incident tickets.

Fast forward a few weeks, you're bored because you're waiting for project approval, so you make use of the incident process to make some improvements. Perhaps it crosses a line. But I had some direct managers (lower rungs) who loved the idea. "Fuck it", they'd say, "the process is there, use it!"

All that from taking the ITIL course seriously. If you're going to hack the system, understand it

I think that working at a bank is fantastic so long as a person can internalize the good parts.

The bank I was at had the best data practices of any company I’ve worked at by a mile. They wouldn’t hesitate to write huge checks to make sure that the hardware systems and teams supporting those systems were perfect. Software management was a bit procedural but the results were consistent and high quality.

I have worked at 2 really big banks and they have many very talented, well-rounded people.

The friction is there to protect the firm.

It's true, though, that upper leadership tends to be incompetent. Don't hire them.

But finance tech VPs and ExecDirs are often highly skilled, smart people.

A lot of the friction in the banks is for legal reasons - they HAVE to abide by certain protocols. If you treat that as an extra challenge rather than a hindrance it will be more rewarding.

Yes and no. There are teams and people who protect their headcount and interests under the guise of compliance. But very often they're enforcing one interpretation or implementation of the law. And very often, they're audited as to whether they follow the process they designed and not the process itself.

Navigating the regulatory landscape to introduce change is high skill and art that I've rarely seen but does exist.

That's a huge bias to bring in an interview.

Sometimes you work on some cool project for a while, then it becomes boring, etc. Or sometimes you're stuck with that job because of lack of other local opportunities. Or whatever other reason.

I agree, big bias. I'm not totally being serious. But I have had really bad experiences with people working at banks.

In Norway it seems you could have an exception for people who worked at Sparebank1, everyone I know who have worked there has been great to work with or listen to.

(I never worked in a bank myself.)

I found that the more I delivered and the happier I made senior people, the more I could ignore the rules and process and friction and get stuff done. Probably a year or so in I barely paid any notice to most of it.

I had a huge amount of freedom, really. But after a bit over a decade I finally moved to the world of startups. I’d never go back.

So while you can definitely work on removing your own personal frictions, and it’s absolutely worth selectively breaking the rules, I’m not sure you’ll ever be as happy as you could be in a different environment if that’s how you feel now.

>I found that the more I delivered and the happier I made senior people, the more I could ignore the rules and process and friction and get stuff done.

Yeah, I agree with this. My strategy has been to figure out what my boss wants to do, figure out what I want to do, and figure out what my job duties actually are. Then focus on the intersection of the first two and doing the minimal work necessary for the third. This means trying to get around process for your boss's pet project or to work on what you want while making your internal customers go through as many hoops as your organizational structure allows when they want you to do your job duties.

This probably comes off a bit cynical and I do have some pride in doing a good job, but this is kind of my basic corporate strategy.

The important thing is that job duties often don’t have to stay static.

Especially if you are already doing a good job at what you want to be doing and keeping someone senior happy, it’s often possible and sometimes even surprisingly easy to evolve your official/main duties in that direction too.

It took me a long time to figure this out, but the BigCo friction does come with benefits. Particularly benefits of scale and risk reduction. Need your app localized? Surprise, that happens automatically with BigCo processes. Didn’t think about GDPR compliance? Surprise, part of the delay you’re experiencing is that review. Need an awareness campaign? There’s a whole marketing team to help you with that.

Thing big and slow, and you’ll work it all out.

Yup, exactly.

The complexities of both running a large operation and operating globally are vastly greater than a small operation. Simply the number of nodes that must communicate has a combinatorial explosion. So, there needs to be a standard way of dealing with that, or entropy also explodes. So, bureaucracy happens, with processes that sorta fit everyone but rarely exactly fit, so friction increases.

A saying I heard from Africa: "If you want to go fast, go alone, if you want to go far, go together". GP is going far and together, and yes the other people will necessarily slow you down vs going alone.

The decision is whether one really wants this journey, in which case, learn how to work within the large org, or actually wants the faster but less secure career.

> A saying I heard from Africa: "If you want to go fast, go alone, if you want to go far, go together".

Love this! Definitely gonna use this sometime.

Indeed - it was very memorable for me too the first time I heard it !

> Another answer is to work at an early-stage startup or a small non-tech company where you can move fast. The tradeoff there is lack of job security and lesser pay.

I work for a very small "non-tech" company, have been here 12 years, and have a great income. The tradeoff I had to make was a much higher level of responsibility. (I'm at the very top of the tech stack - if something isn't working, there's no one for me to blame, aside from a vendor like AWS)

Lesser pay is not always true.

This is corect analysis. BigCo comes with pros and cons, but the pros are typically job security* and a life outside of work. My son was born three months before my father died and wow did that rapidly change my perspective on the relative value of an agile but single threaded rocketship vs. a megalith taking a a six year ootm call option on a few months of brilliant work.

Relatedly, best advice I received was that the grass is green and brown on both sides.

*standard disclaimers about at-will employment

I have worked at several big companies, including BigFatHugeBank and heartily agree with the above comment.

This is not just normal, but this is "The Deal" that you are accepting when you join a large company.

It's normal that a single developer is maybe 20% as efficient at a big company compared to at a small company. What you used to accomplish in one day will now take you a week (after team processes, code reviews, deployment requests, etc, etc).

But the trade-off is the big companies have figured out how to keep thousands of people productive. They might individually be less productive, but as a whole they accomplish more than a small company can accomplish. Some do it better than others, but no big company works like a small company.

That's just how it is. It's easier to solve problems with small groups of people than large groups of people. If the problem takes a large group of people, it will be a lot less efficient.

I would even say that working at a big company as essentially a different skillset than working at a start-up or small company. In a big company, your main job is to get other people to do things and you are successful based on how well you can do that. In a small company, your job is to do things yourself.

If you really hate the big company world, you should consider moving back to a small company. It's never going to not be like that.

I've worked at both relatively large (thousands of employees) and small (less than 10) companies. When I transitioned from small back to large-ish about 10 years ago, a couple things struck me. (Really, I was reminded of because I had worked at a similar magnitude size company previously.) There was so much "machinery" to support me in various ways. But the internal communications to take advantage of that machinery (and to inform stakeholders, the field, etc.) was a huge ongoing effort.

Not all large companies have so much machinery! While people think of MAGMA, maybe Capital One, Clouflare, etc. - there are many huge companies that aren't tech-first that have the internal communication responsibilities but without better developer tooling than small startups. That _sucks_ if you're the kind of person who's used to high personal velocity.

I was using machinery in a more general sense given I don't do development.

For me, it's things like lots of marketing program people, public relations, analyst relations, competitive analysts, designers, editors, etc. They can offload a lot of work (and, in many cases, can do that work better than I could). But it's a lot of people to keep informed and coordinated.

> marketing program people, public relations, analyst relations, competitive analysts, designers, editors

I guess it depends on the role. I don't think startup developers do any of these (except maybe design) :)

I work for a very large corporation (Fortune 100 that everyone has heard of). I was hired by a business unit back in the days before the company even had an IT department (back then everything technical was outsourced to another company). So for decades we did whatever we wanted. Eventually the company created an IT department and about 10 years later they got wind of us and insisted we get moved into IT. Complete hell. Our productivity took an insane nosedive. As you said, it is slow as molasses to get anything done and everything requires so many (SO MANY!) meetings. At first this was very stressful, but eventually I just gave up. Whereas before I could get in a good 30 hours of productive work done a week (meetings are rarely productive), now I am lucky to get 5 hours of productive work done. Instead I spend the majority of my time in meetings or waiting for people to get back to me. 2 things help. First I work on personal projects in all the downtime. Second I started as an online instructor at a university teaching web development to students. So I spend time helping the students. And the company is perfectly happy with my work, since nobody else can get anything done either. It’s insane, but I learned to just let it go. If the company doesn’t care about how much productivity they are losing, why should I care?

> And the company is perfectly happy with my work, since nobody else can get anything done either.

I just switched job from a big company to a fast-growing startup which doubled their engineer team size in one year. I was unhappy with my productivity in the new company, thinking I was not doing enough, but my managers said they were quite happy with my performance. I think I was comparing my productivity with the peak productivity in my previous role where I already spent years working on the system. But what the managers really measured is your relative performance compared to your other peers. So as long as you are doing okay relative to your peers, albeit all being unproductive, you would be okay.

Any tips on how to find gigs teaching web development to students?

Look on university websites. I don’t know if there is a meta search. Lots of universities have online course offerings. The courses are typically designed by university professors and staff and then they hire people who actually work in the field to oversee sections of the course. Typically they require you to have a masters degree.

Cool, thanks. Any Master’s or one in CS?

Your position at a job dealing with friction is much more common than the opposite case. If you're interested in learning and growing, here are some opportunities you may find in your new role:

1) Cultivate an attitude of optimism and gratitude despite the challenges, perhaps through a study of Stoicism and a cultivation of patience via a study of Buddhism. Gain more pain tolerance. Learn to not care so much about the outcomes, and care more about your own presence and the excellence of your contribution. Learn to care more about other people, rather than just getting the job done. Learn to have more fun, while also "digging the digital ditch". Being calm and steady despite feeling uncomfortable is an invaluable life skill essential to growth and doing big things.

2) Learn to politic. Recommended reading (and there is a lot) would be How to Win Friends and Influence People, as well as Robert Greene's The 48 Laws of Power. Navigating people and political systems is also an invaluable life skill and essential to growth and going big things.

3) Develop your life outside of work more fully. Consider getting more involved in helping your family, your friends, and your community. Volunteer opportunities abound. Perhaps they need a speedy hacker like you to help them with some part of their tech?

4) Study the challenges of BigCo for startup opportunities. Lots of startups are created by people who ran into a big challenge at a big co, then broke out on their own to solve the problem, then were able to grow by selling back to their previous employers to solve the problems with tech.

Oh god, yeah. I was happy to stop working at such a place. Leave.

At one such company, no names, they had a rather large consumer facing website. I was told it had no analytics other than a homegrown solution (which was terrible). Then it turned out that had Google Analytics (Enterprise) but everyone had forgotten about it. They denied it at first, but I showed them screenshots of the Network tab in Chrome where it was pretty obvious. Suddenly I had access. So far this is 3 weeks or emails.

With access I realized the implementation was botched. All view states were being handled by a hash in the URL so all Page Views in GA were reported in one URL.

I requested a minor code tweak to account for this. I was told by the dev team it would take 6-8 weeks to implement such a change. I was assured this was rather complex and they'd need to free up people too to work on it so that could take longer.

I told them the code change was already written and I'd included it in the initial request. I referenced the template file within their system where they change would live and included tests. They still dragged their feet. It got completed in my last week. Copy/pasted exactly as I'd written it.

It was utter madness.

Am I correct in assuming that Google Analytics (Enterprise) still stores all the collected data on google's servers, or does the enterprise designation mean it's locally hosted?

Yes - all stored with Google. Not locally hosted.

Sounds like those analytics weren’t important to the company.

One trick I’ve used is quite simply having five things on at once. You keep notes of where each project is, and work to get each one blocked. When they get unblocked, you switch to that thing until it’s blocked again.

There will be people who insist that you should “focus on the most important thing” but if it’s blocked what’s the point?

The other thing to do is make a lot of friends in related departments. It’s amazing how much faster things will go when someone does you a favour. Expect to be doing favours in return.

Enjoy the 35-40 hour work week and stock options that are actually worth something I guess?

For what it is worth, I am at a BigCo and while yes it is true you cannot just hammer out 4000 lines of unreviewed code and push to production without someone else being involved, you also benefit because people aren't just changing stuff willy-nilly. E.g. your project you've been working on wont suddenly stop working in production out of the blue because Clive decided to totally change the database table schemas at 4am on Wednesday morning and nobody told you about it etc etc

> you also benefit because people aren't just changing stuff willy-nilly. E.g. your project you've been working on wont suddenly stop working in production out of the blue because Clive decided to totally change the database table schemas at 4am on Wednesday morning and nobody told you about it

It can. I worked at a 2400 person company. 'Dev/tech' side was... ~150 or so, so not thousands of devs, but not just '3 folks in a basement' sort of place. Lots of 'process', but only for some people (like me). Other people - people who were dating management, for example, could make whatever changes they wanted.

I would need to have a formal meeting with 2-3 "sr" folks to request a database index, then have to do a presentation about why it was needed, then wait for 'review' ("this might break something else"). But then other folks would literally just go on the database (because they had direct access) and fuck with whatever they felt like.

And... I'd be dinged because my deliverable was late because... "well... you should have planned your project better" (when... I had no hand in planning or setting deadlines). Not in my wildest dreams did I think requesting 2 indexes on a couple tables that only our application used would require 2.5 calendar weeks and multiple meetings, so... unsure how I should have raised a flag earlier that we might hit some roadblocks.

But yeah... hey, if you already had access to prod dbs, you could just go in and make live changes without testing or documentation ("it's OK, Steve used to be on the database team - he knows what he's doing").

Process/overhead isn't necessarily bad, but applied unequally, you wind up with hypocrisy and resentment (and people like me leaving in less than a year).

Sounds shitty - when there are personal relationships/nepotism/etc going on and it is impacting what gets done, then that is a major red flag for so many reasons. This time it sounds like someone gets to do what they want with database in production, but there can be so much more going on that is simply unseen, but could be much more odious (running the gamut from covering-up/ignoring harassment, right through to fraud or other criminality).

Regardless, I'd probably argue that a company with only 2400 employees let alone engineers is not what most people would consider "BigCo". In my mind, BigCo are thousands/tens-of-thousands of engineers - think FAANG, major Investment Banks, major technology companies (e.g. the IBMs, Microsofts, or Samsungs of the world). The sort of places that people (rightly or wrongly) aspire to work at, or at least have some common mind-share amongst the average person on the street.

Interesting that this is so complicated in a big Bay Area tech company.

At a fruit-themed Bay Area company I can register a domain name behind a load balancer, issue a new cert, kickoff a VM to host it internally all in the same day without any approvals... so long as it is below a certain scale suitable for testing, skunkworks projects, etc. Approvals and meetings only become necessary if I want to deploy a production service, a large-scale service, or both.

Requests for a new repo or Confluence space are fulfilled same day and give me complete admin control over it. I can kickoff custom OS builds and generation of installation images via a self-service portal. I can create new email-enabled LDAP groups via self-service. I decide if the group itself is self-add or not, etc. Anyone else in the company can do the same. Many other things are as simple as direct manager approval.

You don't have to put up with bureaucratic nonsense, it just happens to be common in corporate America where management doesn't trust the peons to make decisions. Or perhaps where everything is driven by division P&L so no one wants to be responsible for spending money outside their fiefdom?

I prefer an environment where individuals have responsibility and yet where we accept mistakes will be made. As long as you learn from a mistake and don't continuously repeat it there is no need for a new process in response to it.

Sometimes the people are paranoid, but what you describe is only possible if the company has spent the time to build that kind of tooling that allows for flexibility for peons while also limiting blast radius.

Glad to hear there are good big companies out there.

management doesn't trust the peons

This.

That is exactly what Big means in this context: something indistinguishable from bureaucracy. I am sorry for you but if you want to be able to work “freely” and “get things done”, a big corporation is the worst place to work in.

I am not happy to bring bad tidings.

Edit: no business gets “Big” without a good paper trail and this implies that no action is performed unless some previous paper work has been carried out.

Yeah, It's a good learning experience at least. Never worked at one of these. Guess I naively assumed that since it was from #SiliconValley it might be different.

What do you think would be the best types of jobs to target for lower friction? Startups I guess.

Mid-sized well established companies engaged in markets where there is active growth. You get maturity, experience, and a true desire for competition... and if you can move the needle for that type of group you will be well rewarded and you'll probably actually enjoy it.

How many employees is considered mid sized? Like 200?

I have not spent much time thinking about this, but anecdotally:

It's hard to quantify that way, I feel it would depend on how "wide" the structure of the organization is. Perhaps "layers of management" between where the money is actually made and where the decisions are made is a good metric. Two or three, in my experience, have been the best places to work.

Anything more than that and the friction exponentially increases.

Ask yourself the bigger question; what do you want out of life? Do you want to grind code for 80 hours a week and deal with 24/7 on-call rotations? Or do you want to put in your 40 hours, collect your RSUs, and live happily ever after? There is more to life than work, and #BigCos make it far easier to enjoy that.

I really want to do interesting enjoyable work to be honest.

Start your own company or work on side projects while you wait on administrative bullshit.

Why wait? Working at big tech is a bankrolling operation. I show up and collect my dough, nothing less nothing more.

Friction is a continuum. As the company gets smaller, the amount of friction gets lower. Also it depends on what you do for the company, putting a button on the front page of Amazon.com has more friction than putting a button on an internal service support tool or a test tool.

That is to say Big companies can be OK if you land in the right department.

Yes, that's probably true, but ... as somebody who actually put a button on the front page of Amazon.com (back in 2010-ish, I wrote the presentation code for an MP3 sample player for album recommendations) it was actually pretty low friction. Write code, test it locally, deploy it as an A/B test, test was not negative - ship it. The only people I had to talk to were translators for internationalization.

There was a team that was responsible for cohesive look-and-feel across the gateway (front page), but mostly they trusted us to do our thing.

The principle of a team completely owning their little bit of territory within a page on the Amazon site was a very good one, IMO, and helped cut down on what could have been a bureaucratic nightmare. Of course it had its downsides: some teams didn't pay as much attention to presentation or browser compatibility or interoperability in a range of scenarios as others did; and by its very nature, this team organisation led to pages which were divided into not-particularly-cohesive slices, each its own little fiefdom.

Still, there are some BigCorps which do at least pay attention to optimising processes, even if it's only in a particular direction. (Shipping stuff at Amazon was easy. Want to talk at an open source conference or ship open source software? ...ooh, we'd better talk to the lawyers.)

> Shipping stuff at Amazon was easy.

This might have been true years ago, but my recent experience has sadly been the opposite. e.g. on the projects I worked involving the website, testing locally has been virtually impossible.

I've come to prefer working in companies that are between Series A and Series B funding: After Series A is when the startups really have money for compensation. Series B is where companies start implementing bureaucracy like OKRs, permissions for everything and the org chart starts getting deep.

Interesting. How can one identify what Series a company is? Ask during interview?

Sure you can ask . Another way is lookin for the company through crunchbase , they often show in what series is the company currently.

Jobs where the people that write the software are close to the people that use the software tend to have fewer process restrictions and less red tape because there is more direct accountability. Science teams, applied research, and some data science groups are set up this way.

A smaller company (not incorporated?), also.

I guess a good indicator is the size of the legal Dpt.

But I work at academia so I am not your best counselor on the topic.

Notice also that you are going to learn A LOT about “due process” and “due diligence”. This will be very useful in your future positions.

Size of Internal Audit team and spend on internal and external audit services is probably a better indicator than size of legal department. In most orgs the legal department mostly serves as a bridge between executives and outside council with minimal emphasis on internal compliance. IA departments on the other hand frequently own responsibility for implementation and enforcement of controls recommended by outside council, as well as controls imposed by non-voluntary regulatory frameworks like SOX and voluntary regulatory/risk control frameworks. The latter are generally the cause of a lot of the 'friction' folks are complaining about here.

Totally right.

Do you always put random "#"s in your sentences? Is it a startup thing?

Its a hash tag. Meant to emphasize an abstract concept. A life variable you could say.

I am too authentic to work at FAANG. My salary as staff eng. is roughly equivalent but I can argue, throw a fit, change direciton, say my opinion etc etc every day. I push through friction, I ignore managers, I do things my way. I ask for forgiveness not permission because I have a bias for action not confirmation.

Software engineering interviews do not value authenticity, typically. They want you to say what they want to hear. I purposely go in the opposite direction. I am always myself, say how I feel, and challenge the interviewer.

My girlfriend ( soon to be wife ) has no issues getting any job she wants in software engineering. She will recite exactly the words they want to hear, and they love her. I will say exactly what I want to say in an interview and they will love or hate me. I have no intention of changing.

My best advice? Leave for a smaller company that lets you do whatever you want to do and perform at an exceptional level. You get the same satisfaction, same pay, and you may only be 1 step down from VP. You can grab VP's, C's for a comment, you can do whatever you want ( as long as you perform ).

That's the way. For me at least.

I think the key here is to make sure you minimize these costs. For example, if you decide to make a microservice every time you want some independently-useful feature, you'll have to set up CI, get a domain name, get an internal cert, get permission to route packets at production priority, have a privacy review, get a launch review, etc. If that's the org, then you never want to be making a microservice. Shove everything into your monolith (and hey, maybe let other teams do that too and share some of the operational burden). Be adaptable; find the processes that are time consuming and make sure that you only go through them once. Make sure that if you impose process, it has value.

The other side of the coin is that all these processes exist for a reason. If an outage costs you a billion dollars, it's financially great if you're filling out paperwork and having meetings instead of checking in features that break production.

The key is to be adaptable. Observe what is a necessary waste of time, and get it done and out of the way. Observe what is an unnecessary use of time, and work around it. And, accept that you can't always win. Sometimes it's socially imperative to do something that's objectively a waste of time (status meetings), so you have to do it.

(Why do they make it so hard to get work done at big companies? No idea. I could never go back. Not being productive at work isn't worth the extra money they pay you. Kind of sad when you think about it.)

> accomplishing things

[I also ended up at a BigCo along with others from a small startup that pivoted multiple times after making v1 products that could have been successful.]

What I learned is to reframe expectations. At the startup, I could develop software and features rapidly with no impediments than my own lack of knowledge in an area. At the BigCo, the product is large, changes are slow, and processes are safe. The payoff though is that when you do ship that feature, it's being used by thousands-to-millions more users than it would have been at the startup.

At the same time, all the one-off things I used to do at the startup should have been streamlined at the BigCo so that I can think primarily about the problem I'm trying to solve and not the peripheral routine elements of every service that gets shipped. If this is not the case, perhaps the BigCo's processes are not very well streamlined.

I've found some ways to adapt, but some things still take much longer than they should, like PR reviews (but I'm also guilty of being a slow reviewer).

> emotionally exhausting

This is because you have an expectation that a certain thing should only take a certain amount of time and effort.

The best general advice is to work on multiple things concurrently, so that when one thing has delays you can switch to another one that's ready for work.

You have to decide whether you want to actively improve these inefficient processes, accept them, adapt, or move on. Anything else will be suffering. If you move to another BigCo the annoyances will be different more to your liking, or not.

Yes, many of us have dealt with this as you can see from the existing comments.

One thing you are mentioning is the friction around the dev experience however and there is perhaps an action you can take, if you're willing this early in your tenure there, to put your neck out on the line.

My very firm belief is that a bad dev experience results in a high cost of experimentation which means people don't try new things out and innovation stops. The only way things get done is through massively coordinated efforts. If you can associate a cost of the gate keeping with productivity and then directly back to the money it costs the company, or money that could be saved, or feature velocity to be gained, you can make a case for improving the experience. Making the case and seeing this all through will take you 6-9 months.

Ah, fond memories. At the worst place, it was 5 weeks before I could log into a computer. Then daily "scrum" conference calls with 40 people on 3 continents, which took about 90 minutes each. Detailed written proposals (Word docs, multiple pages) required for every code change, even small fixes.

Minimal friction is the opposite scenario - be a contractor, take whole jobs, do it all yourself. I prefer it, but there's no coasting.

Can there be a better display of first world (actually SF bay) problems than this post by OP?

All Over the world, workers yearn for breathing time - A few minutes away from the the production line. They wish their tool breaks and the management takes a long while to provide a replacement.

What’s your issue, op? You seem very excited to generate shareholder profit.

It's not wrong to enjoy your work. This person's experiences are real to them, and they have the right to feel them.

If only the most unfortunate person in the world can claim injustice or dissatisfaction, if only their problem can be solved, progress will grind to a halt.

If they have the right to their experiences, I have right to provide my opinion on their experiences. And let's be honest, if their way of life makes it worse for the rest of the world, it's perfectly okay to publicly shame even.

OP didn't say you didn't have the right, OP merely shared their opinion on your opinion of someone's experiences.

Put another way, software engineers are some of the few people afforded a healthy relationship with their labor - to take pride in its craftsmanship, to be satisfied by things working well and dissatisfied by things working poorly. That is cause for gratitude and celebration.

This kind of oppositional attitude is toxic. I'm glad not to find it in my coworkers. And I would not accept an environment where coworkers displayed it.

Feeling like you're constantly blocked isn't fun either. Starting to get into the groove only to have to immediately stop, having to keep track of lots of threads where people put up roadblocks to justify their own jobs, etc. is not "a few minutes away from the production line". It's work all the same, and not the work most engineers sign up to do.

During that while, what stops you from reading a book, working on a consulting project on the side (thanks, WFH), learn some new skill? Life is more than serving your boss in the office.

There are still targets to be met and demands still being made of you. Sure, if you have nothing to do, do something good with your time; that's not always the position people are in.

> Life is more than serving your boss in the office.

Sure, I don't think anyone's saying you exist to serve your boss. But if you have to work a job, why not find one you actually like doing? I think what the OP describes would be a complete drain of my energy, even if I could read a book occasionally; working on actual code during my workday gives me an opportunity to be paid to learn new things and is honestly actually energizing. Why work on a tiny Nix environment on a toy project when I could be setting up a real-world Nix development environment that's deployed across tens of developer laptops, y'know?

I'm not serving my boss. My boss has a whole set of metrics and expectations that are quite distinct from delivering working software to customers; I use my considerable autonomy as a white-collar worker to half-ass those behind her back and spend my energies on what is actually satisfying to me, which is to craft good systems and make things work well. And as the sibling comment mentions, this is a lot more interesting when there are real customers and stakes.

Problem is you're normally still judged by what you deliver, so you can't just chill and wait for things to get done

no, not really. You are judged relative to others. And others aren't producing crap ton in this sort of environment.

i'm always baffled at the amount of effort it took pass the interview vs how easy it is to actually coast in this job and yes, you need to do just enough to keep pace with your peers.

Agreed that purely generating shareholder profit is not worthwhile. It does suck to be forced to spend a lot of time doing something both painful and meaningless tho. Something psychological there

I see a lot of comments saying to stick it out, etc. But for me, I worked at a fairly Big Co for a year and a half and it really really affected my mental health negatively. The pace the company moved at compared to how much needed to be done created substantial existential dread within myself. I did everything I could to have a good attitude about it, worked the politics of it all, enjoyed side projects and hobbies, etc. But at the end of the day, I think I'm just not built for such a slow moving company so I moved on and have been a lot happier for it.

That being said, to each their own and I know a lot of my coworkers were really happy there.

Yea, the existential dread is real. I don’t understand all the people who are like, “just rest and vest, do side projects, etc” I can’t do that, it makes me feel like a worthless human faking my way through life. Extrapolating on this thread and the industry in general, really just makes me think this is a big fucking waste of time, and makes my skin crawl working with others who don’t seem to think this is a problem. Like, we didn’t evolve this far to fucking toil around on zoom calls and shittily written emails from passive aggressive narcissists. Anyways, uhhh yea — thanks for mentioning the mental health bit, I clearly have some work to do and/or new jobs to look for.

I'm on the other side, where the grass is greener. Always worked at small companies and early stage startups. Always putting out fires, sometimes worked till the middle of the night. Sometimes pushed to production without code reviews. Stress always at an all time high. Never made great money.

Someone please explain to me why I should not dream of working at BigCo where code reviews take a week. A remote job like OP's is a literal dream to me. No stress? above market average compensation? As long as I can work from home I'll know how to keep myself busy.

This is why they pay you. If they are not paying you enough, well ... you'll come to some conclusion.

The risk to a small company is that the product will not make money, impressions don't convert, and the runway runs out.

The risk to established companies is every other risk - software license risk, security risks, etc, etc, etc.

Big Co also runs some or all IT as a cost center - people don't get to make the product better, it's difficult to staff appropriately for the work load.

Big Co also treats people as cogs to churn out some "work" - management at the top cannot understand or help with every project, so they have tools to understand what hours are spent on which project. Then they expect those tools to tell them something useful, so they hound the middle managers based on the work recorded in the tools. "You manage what you measure"

Friction is minimal when your job is very repeatable, or when you don't actually try to do anything.

Yes. I've dealt with all of it. Don't be emotionally invested in your work and enjoy the comp and work life balance.

I have worked in tech for two very large companies, both fortune 100, and well over 50k employees. I also worked for a small company that I could best describe as a late stage startup that was coming to terms with being a lifestyle business.

The trick to escaping bureaucracy is the same for both. Making friends with people, and talking to them directly when you need to massage the processes. It's just that it is much easier to be friends with 50 people than 5000. Working from home can be an issue, make sure to video chat when you can and goto as many official and unofficial events as you can.

If you have a good manager, and your manager has a good manager, they should have contacts around the company that can help with the red tape. Never abuse it, and when you're in a situation where your urge is to be a roadblock to another team, go out of your way to help them instead. It always comes back in a good way.

Office politics sucks, but it's the only way to stay sane in these environments.

Sometimes you have to remember that the friction is because they just don't know any better, or because they do no better, but they're too busy or too tired to create a better system. They are all dealing with the same nonsense, and it is soul crushing.

In my current job, I had managed to skirt a lot of the corporate nonsense for a long time, but we merged with a company that had a very by-the-book culture, and my manager had to resign for health reasons. Things have been downhill for the past few years, and if I could get a job making the same at a company that didn't do all that, I would probably take it.

..but that brings me to another point, I loved that small company, like family. Then One day a bunch of my friends were fired for personal/political reasons. I left a year or so later, and a year after that they sold the company, and a year after that the new company closed the office and just kept the data center. The point is that bigger companies are more stable, if you have a mortgage or kids it's really no choice.

To sound a slightly different note:

Yes - there's lots of friction. Bureaucracy is inevitable, given the cost of turning the ship/the risk level if something bad sneaks through.

That said, there is a ton of potential leverage at BigCo - the scale is extraordinary.

It is a trade - you get a far bigger lever, but it takes way longer to pull.

Yup, risk is a huge differentiator. Ship a perf regression at startup? Who cares: hotfix and carry on. Ship a perf regression at #BigCo: risk massive financial impact when mega app falls over.

Deploy a vulnerable VM at startup you configured wrong? Probably nobody will even notice. At #BigCo, risk an advanced persistent threat that's actively scanning your infra finding it immediately and compromising a massive amount of data.

Thank you. I've been feeling frustrated at how slow (and hard) it is to pull the lever, and never noticed how much more powerful the lever is.

What you call friction is usually a symptom of process. BigCos use process to protect themselves from stress and failure. When things go wrong at BigCo, it often hits the news and can affect the livelihoods of a large number of people and cost millions. Process is designed to stop that happening.

In contrast, few people notice if SmallCo's website is down for a while or a bill isn't paid.

Having worked at both Big and SmallCo, the stress/salary rate is usually much lower in BigCo thanks to that process, so, assuming you want to carry on working there, embrace the process and understand that (most of) it is your friend.

I'll trade you responsibilities.

I work at a small agency and often do work for non-technical clients, or get hired to work on a completely unmaintained legacy system. I end up owning nearly everything myself, and it's a massive pain in the ass.

You might be frustrated with the process of getting a new VM, but you also don't have to own and maintain all the VMs by yourself. I bet you won't have to personally manage the billing of this VM directly, or monitor for any changes in usage or pricing, etc, but somebody in your organization will.

I often have to own and manage the SSL certs on dozens of unrelated properties... and own and address all the front end issues in every framework... and all the ci/cd issues for every legacy codebase... and anything else I want I gotta do. I also have to properly research all providers and price tiers and budget it all for my clients and then sell them on any service I consider worth it.

Or software (and hardware) lifecycle. When to patch, what has support, is it a compliant configuration, etc

> Anyone else dealt with this? > Anyone have any type of jobs where friction is minimal?

Tactically:

Get better at navigating it. Is there a person hitting a button somewhere? Get to know that team well. Make it easy for them to approve your requests by being exemplary. Automate the process on your end. I've written scripts to fill out forms and open sourced them internally at large companies.

Strategically:

Understand why it's so filled with friction at a systemic level. Legacy organizational structure? Lack of engineering resources on the platform teams? Try to suggest sensible, iterative fixes. This only works at some companies, others are so tribal that another team approaching them with a low effort / high return suggestion is seen as aggression.

It's much more rewarding to attempt to solve these problems and be an owner than to go into ugh whatever mode and passively take it. It's also better for your career in the long term.

Part of the difficulty you're dealing with is just learning how a new system works. There are reasons for this friction, you really dont want your inhouse CA to mess up and issue an invalid cert, you want to make sure that each of your several thousand VMs are running the correct up-to-date OS and are on the correct hardware. Once you've learned how to negotiate the new environment a lot of this "friction" will be less painful.

So far I have found the key to being efficient in this type of environment is to have many things on the go at once.

You are used to things having few dependencies so you can focus on one task and take it to completion. Now there are many dependencies and so you have lots of downtime. You can use this downtime to set other things in to motion.

Keep this in mind:

In a large organization, NO SINGLE PERSON makes a decision. It's THE PROCESS that makes the decision. And THE PROCESS takes time. One of the greatest skills you can learn at a large organization is identifying, bypassing and avoiding THE PROCESS. It can be done, you just need to figure out how.

A Kafkaesque view of corporations, if I’ve ever seen one.

The startups and small companies are playing offense - they are trying to get their foot in the door and hunting.

BigCos are playing defense - they want to maintain the status quo and not kill the golden goose. They've built a castle to protect it. It's only natural that they will add friction everywhere for the fear of killing the damn bird.

Relax and coast for a bit, and jump to a small company. But like others have said, you will work more hours, and they can be insanely high cognitive load for other reasons.

> Anyone else dealt with this?

I imagine that the majority of white collar workers are employed by large corporations, and so the majority have to deal with this.

Given the number of startup layoffs happening, I imagine a lot of people will be having their first experience with large corporate bureaucracy.

> To get anything done is emotionally exhausting.

Onboarding as a new hire is usually the most frustrating period, because you need to request a lot of things and can't get any work done in the meantime. Eventually you have enough access that you can at least do work while waiting on other requests.

One thing that helps is knowing how to use the corporate tracking system to know which individual specifically the request is stuck on, and then relentlessly following up with that individual via email until they approve your request.

You should also track your tasks and identify the ones that are stalled because you're waiting on a request, and then regularly show the list to your manager (along with your follow up efforts). That way you have a solid reason for not getting those tasks completed.

serious question: why do you want to "get work done"? You are getting paid regardless. Maybe take time out and work on an open source project. Maybe do consulting on the side. Read a book or something, perhaps?

I feel like it's not ridiculous to want to have the single biggest part of your life be for something.

Yeah, and it sucks. I'd much rather be doing something charitable.

I've been at big companies and really small startups. I've tended to alternate between them.

My Big Company experience was they broke us up into smallish teams (6-20 people), which made us work more like a small company in many respects. There was a lot of process, but it was actually a good discipline to have. (Its always startling when I started in academia the "code repo" was CVS and not hardly used..)

My big company code was more thoroughly reviewed and frankly better.. I learned a lot from those reviews and being given the time to design before coding. Having to do it all at a small company you learn a lot too. Big companies actually measured productivity, and had a processes.. Much less input into what we were going to do.

Though it wasn't all great: I was put on the "Morale Committee" because morale was low. This didn't help my Morale, but we did get the company to do some ice-cream socials.

Warning: personal rant first, maybe helpful point of view at the end:

rantish story

I work at a BIG Co (think 700k+ global employees) and we work for other Big(ish) Co as more or less data & code wrangling consultants.

How did I end here? I worked for a small(ish) agency with around 500 people. We moved fast, we build cool stuff, we already to worked for the Big Companies and Banks in our market (Germany). We were at a point were quite a few more formal processes would have been necessary to put into place to fulfill compliance regulations of different markets (think banking or automotive - these require a lot of stuff in terms of compliance from their vendors).

But we got lucky (?) and bought because BIG Co was not able to build their own agency - so they bought a lot of agencies to build a new one.

In the "good ol' days" I knew whom to ask to get anything done. There was an official process and the ones in the know knew how to navigate the short cut. Ask the right person, receive special treatment and be on your way flying fast.

OK - it made the process longer for the lowlies who didn't know the right people. And that is exactly the problem. There already was a two class society of workers. Because we already were too big for "no process" and too small for BIG Co process (and that drags us down nowadays). But the people following the process unbeknown to them got blocked by us knowing the shortcut.

So yeah - it feels shitty and slow and probably as if someone wants to gauge ones eyeballs out with a hot branding iron.

maybe helpful POV

But think of it like this:

Try to transport a 20 foot container on a high power speed boat. The speed boat will be way faster, more agile, more flexible. But if a somewhat bigger wave appears it will crash. And it will also not be able to deliver that much impact (containers) as the big ship once it arrives in the harbor.

Lots of advice of "just grin and bear it", and "get along"... etc.

IMO, it depends on the friction. If this is just your own expectations not being met... you can adjust those.

If, however, you have other people on your team or people you answer to expecting things to be faster, but other parts of the system are working against you... that seems to be a recipe for constant pain/friction, unless/until others leave/change (which you generally have no control over).

Things that should take 2 hrs taking 2 weeks are annoying/frustrating on their own. If you have other people setting deadlines for you which don't align with the processes you're tied to - that's a whole other level of pain, and it might be worth trying to find someplace a bit less internally conflicted.

There's a way to work in such an environment and not go crazy, but it will take time to get used to it. Think of it system with big asynchronous methods. You need to arrange your work to put in the slow running requests early, then focus on other things while waiting.

I’ve faced this at multiple jobs at orgs of different size. My solution was to always have more than one thing available to work on so when one task bogs down in the mud due to organizational processes, I can go work on something else until the blocked task makes progress.

If you don’t have alternative things to do while things block, you might see about getting other things to do. Or, adapt your work style to minimize the number of times you run into these obstacles. The people I see get most frustrated are those that don’t adapt to the system and get frustrated when it doesn’t work the way they want it to. Adapting may be annoying and may break some comfortable habits, but in the long run I find it to be the route of least angst.

Days? It once took me 4 months to have a package manager installed that was blocking a project. Defense software engineering is a whole other level of misery.

I left defense and I'm now in a BigCo. and loving life because things only take days at most. Appreciate what you have?

This is my experience in defense as well. After my proposal for a talk at a software conference was accepted, I found out that the estimated date for getting the required content review from Corporate Communications, Legal, and InfoSec was several weeks later than the conference itself. In practice, though, a thoughtful VP up the management chain recognized that this was a problem and fast-tracked it.

Big Companies don't often have the same speed in terms of cross departmental (and sometimes cross team) efforts. Anything that basically splits between your immediate team and everything else has process involved, for many many reasons, one of the biggest being work tracking (Jira Tickets and the like) so that everyone else's time is accounted for to handle that task.

Once you realize its all about work tracking, basically, it becomes either more of a hurdle or easier to understand and manage, but thats basically what you're up against here.

I've done this, except it was big government.

Pick your battles. Not only is it exhausting to make everything a fight, but people will appreciate it more, and be on your side more, if you pick only the important things to stand your ground on.

Make friends. There will be people who feel the same way, finding them is usually good to get things done quickly. It can be important also to break down the team barriers. Requiring a different team to accomplish something is a big part of friction, and knowing individuals in those teams that get stuff done can help. The way to get them on side is to make their jobs easier, and again picking your battles and compromising are good ways to do this.

Get buy in on big changes. So this is different from making friends. You need to develop people that agree that a change needs to happen, and on a way of making that change. I'd start small, with convincing Individual Contributors first, particularly if there are very well respected ones. Then seeking out management and building the case that the changes will improve their situation. This can be a slow process. Managers will appreciate it if it can seem like their project, and once it does, you'll have their backing because they don't want it to fail.

All that said, there are certainly places where this sort of friction is minimal, usually remote devops driven start-ups or consultancies.

I'd use buzz words also, to help make your case. The whole DevOps shift comes with some principles that you can wield to make the case that infra changes should belong in the team, and CI/CD and similar require that VMs (well, pods really) be spun up easily, and from an API.

> I get great satisfaction at work out of accomplishing things and this is just rediculous to the point of making me dislike working.

Welcome to BigCo. That's all there is.

Sorry to piggyback on the question, but I just got an offer from one of those big companies.

The starting date is fast approaching, but offer is contingent on the background check which hasn't come in. The third party company hired, generated their background report over two weeks ago, but the hiring company hasn't communicated their approval. The check had some warnings, because I worked for small companies that have been resold since, and nobody answered them when they called.

The recruiter who works directly for the company has said they will get back to me soon, but nothing happened yet. As we got into closer than two week from the scheduled start date, I asked to push the hiring date.

However do I just keep pushing the date until background is done?

I can't see myself quitting current job until the background is signed off. Or should I?

Should I just like somehow do two jobs (I don't think I mentally can)? Until the background is done?

I've been at my current company for several years, and I can't risk having no job (quit, then new job finds something they don't like), so what do I do?

I'm fine waiting for months and pushing the date, but will they still want me?

Do NOT quit your current job until you have assurance from your new job that you are officially hired.

If you're worried about not having enough time to gracefully exit your old job before starting the new one, that should have been part of your counter-offer to the new company. It's not necessarily too late to do that still, and the new company should be understanding with pushing back the start date, especially since they are the ones dragging their feet with the final steps. THEY are the ones causing the delay and the humans involved should be sympathetic to that. If they are not, you don't want to work there anyway.

This is normal. Background checks - of the sort where they actually try to contact old employers and verify employment history - are a total joke, especially ever since everyone in HR started to 'work' from home. I've seen background checks come back a full month after the person had already started their job and had access to all of the internal systems and were collecting paychecks. Most companies won't deny you the job just because the background check is taking a long time. And if they did, that would be a bad PR move for them I think.

But how do I start the new job? I still have my old job, and I'm afraid to quit until the background is done, is this wrong? Should I just go for it?

I get how people without a job can start, but how do I start? Feels risky to resign from current.

If it’s a reasonable company, they will be willing to move your start date upon (polite) request, justified by the delay. In my recent job change, there were a couple of things that moved the timelines (only a couple of weeks, not months like your case), and the recruiter adjusted my start date like it was SOP.

Re resigning: make sure you have some concrete evidence of passing all contingencies in the hiring process (even go so as to ask the recruiter if any steps remain). Only after that, give your notice.

I had the same issue. I got every W-2, a paycheck stub from every job, a boss contact from every job, all my school transcripts, and pretty much any and all paper work I could come up with and uploaded to the background check ppl.

Then I bugged the background check people literally every 2 to 3 days and asked the status.

I would push back your start date until it's confirmed though to be honest.

How long did it take you to finally get approved?

I don't even have a contact with the background people, I filled out information on the third party site, and they finished report within a day or two. But they couldn't reach the companies, and didn't ask me about any proof, just wrote a report that they couldn't reach them.

I had a company like that and my companies HR department handled it directly. It took me two weeks specifically because of that one company.

If you have w-2s, paycheck subs, and Boss contacts I think you HR company can handle it also.

Also you can make a W-2 online if you lost yours. just download the template and use a paycheck stub to fill it out.

> I'm fine waiting for months and pushing the date, but will they still want me?

Yeah, most big corporations will understand you can't give a 2 weeks until you're cleared to start. For you, this is a life impacting decision, for them it's just business as usual.

When latency increases, concurrency increases. This means extra pressure on you to create personal systems that help you deal with more concurrent processes, and systems that help you follow up on long-lived processes. Your a process who's been living in a synchronous, snappy world, and now you live in an asynchronous, slow world. Your throughput can be high, but you need different tools.

Concretely: it helps to have one or two ongoing mini-projects that are insulated from upstream requirements and not too difficult to dip in and out of.

All these people telling you to coast are right for 80% of the population.

If you have great ability, do t squander it. Get another job where you can be more effective. Find your passion and your fortune will likely follow.

I eschewed advice like the others give, and I didn’t have to work after 35. Yes I got lucky but I also worked hard and failed and got back up and found a place to succeed.

Big companies are mostly for drones.

Survivorship bias is a thing :)

For every 1 person who got a big payout, there are 99 more that just worked themselves to burnout and maybe got a mediocre options payout worth about 1/2 the salary they'd have made at BigCo.

This is probably more true if you're employee number <10 and stick with it through the long haul, which may not be appealing for a variety of reasons. It can also be true if you spin a personal project into a business, but you can do that while employed anywhere.

There isn't any guaranteed, or IMO even likely expectation of a big reward if you join SmallCo and simply "work hard". The reward for that is usually more that higher-ups recognize you're capable and choose you as the go-to person any time they have any sort of tough problem. This is both exhausting and frustrating if you're the designated hero fixer but cannot convince leadership of broader changes they need to make to limit the number of fires that need fighting or train other employees to handle tasks as effectively as you. The general rule that you'll most likely see a salary increase by hopping jobs anyway still applies.

I want to push back on this. "Big companies are for drones" is a way to shame people who aren't a part of tech bro hustle culture, and it's a way to play yourself up as being better than the average person.

It's an expression and promotion of inequality: only the "best" get to have a fulfilling job, everyone else has to work tech support at CVS or flip burgers at Burger King. I'm doing well because I "worked hard and failed." [1]

If you're stuck doing something lame, you're just a "drone" who wasn't smart, connected, and cool enough.

> Find your passion and your fortune will likely follow.

Will it? I'd like you to meet some very talented illustrators and graphic designers I know who still live at home or with roommates. If you've got "fortune" (never needing to work after 35), you've got luck and privilege, not passion.

Big companies pay more, give out equity that's worth something on the open market, and have better retirement and health plans. What fortune do you expect someone to find being ground down to burnout by a startup expecting 60 hour weeks with crap benefits?

I say, let's dispense with the unrealistic notion that any of us are going to "change the world" through for-profit work. We are all drones, and pretending we are not is at best going to lead to an endless cycle of chasing career fulfillment that's just out of reach.

We should strive to be happy with just existing and that means not overworking ourselves in hopes of being a part of "the next big thing." We should also strive for enough income equality so that people who didn't get lucky like you aren't suffering from overwork, poverty, and poor health outcomes.

We're born and we work and we die. Even people who "changed the world" at their company mostly just made some money for the investors. Numerically, most startup companies that have ever been founded don't exist anymore.

What was all that hustle worth for employees at GrooveShark, Vine, Pebble, or StumbleUpon? Their sweat eventually swirled right down the drain, meanwhile their peers at Microsoft are "droning" their life away at the beach right now.

I'm not saying "allow yourself to be miserable and bored at work," but I am saying that it's wrong to shame people for making this kind of tradeoff.

It's also wrong to assume that big companies don't have any interesting projects. You wouldn't want to work on Apple's chip design team? You don't think JPMorgan has any opportunities to work on software that has interesting scale and performance challenges? You think Ford has nothing interesting for a UX designer to do?

[1] https://www.marketplace.org/2021/01/19/why-rich-people-tend-...

I your case, was the fortune a product of starting your own company or working at a smaller one?

As an organization scales and grows, the layers through which decision making is required inevitable increase. Now, that doesn't mean you have to accept this. You have found yourself in an opportune place where you can have impact and reduce some of the overhead. BUT, be warned, you can never fully eliminate overhead. That is the cost of growth and BigCo status.

This sounds suspiciously similar to where I used to work, and was one of the reasons I left. Every project required working with 3-5 other teams for either help or 'alignment' (aka approval). Getting a new service live required many tickets, meetings, manual edits to configuration by other teams, etc.

I think large companies with low friction are the exception, not the rule. It takes MASSIVE amounts of work to build the infrastructure that thousands of engineers need (or be willing to spend millions of dollars for SaaS). I can think of only a few large tech companies with low friction (Google, Netflix, Meta), and they spend a lot on tooling.

There's a few ways to deal with it. What I noticed was that the 'effective' engineers would avoid the standard process and be 'noisy'. They were comfortable asking directly via chat or in person for what they wanted instead of filing tickets or having meetings. They used their relationships (which they did work to build) to skip the line and save time.

You also need some kind of perspective change at large companies. You've moved from rowing your own boat to a battleship. Process is there for protection from rogue employees wreaking havoc on the system, not to make you move fast. Think of it from a manager or platform team's perspective. How do you manage over 1,000 SSL certs (and renew them)? Prevent VM proliferation that needs to be accounted for and secured? Certainly it can all be automated, but at a BigCo's scale, that is a 4-5 person job, and that team is competing with other 'revenue generating' teams for headcount.

I would also recommend to give it some time. You will adjust and learn over time how to work more effectively. I noticed after a few years that I could grease the wheels a bit because I had spent time cultivating relationships with various teams.

Good luck!

Google, a low friction company?

I moved to Google from Microsoft, and I was shocked with the amount of friction and chaos at Google. Everything takes longer to get done.

Depends on product area, team

At SmallCo, scales are small enough that most of the information systems exist in wetware. The boss knows each employee personally and where they fit, more or less. You or the VM guy knows that the VM resources will not be abused. Relatively little is defined in software-backed protocol.

At BigCo, there is a lot more protocol, because there has to be. The boss is physically incapable of knowing every employee personally. You are physically incapable of knowing every possible point where VMs might get used or abused. There needs to be a protocol to authorize these requests and keep a record of it.

This is just the way it is, and you should understand and accept it if you want to keep working in these environments.

If there are BigCo's that seem to work better, it's because they spend more resources on improving their protocols and processes, not that they magically bypassed the inherent complexity of running an organization of 10,000 people.

I've worked for LittleCo, and now I work for BigCo, a F100. I outgrew the LittleCo. There was literally nobody I could talk to about my work, and doing stuff at a higher level was probably threatening to a business with no succession planning.

Sometimes I amuse myself by imagining things from a management perspective, which I'm supposed to represent. I'm a physicist, not a software dev, so I don't know VM or SSL, in their particulars. But still, if the company has a process for making those things, in a way that's manageable and secure for the business, then it's a step towards automating them. From that perspective, the tasks that you did at LittleCo are seen as things that could, if not should, be automated. Or delegated.

One comment in this thread mentions BigCo turning people into drones, but viewed from a couple levels above you, doing work that could be automated or delegated, is drone work. Each "side" has its own view of what drones are and do.

It may take some effort, or even just patience, to get over the annoyance of "friction" that doesn't seem to bother the higher ups, and focus on the things that they care about, or you care about, or both. After nearly 25 years at BigCo, the friction actually has a negligible impact on my work. I avoid taking an emotional stake in stuff that isn't valued when viewed from above. What I take away is the learning that's of more widespread or lasting value.

Or you might like LittleCo better. In Man and Superman by George Bernard Shaw, two people are in heaven and hell, respectively, and neither one can stand it, so they agree to trade places. A couple things I've liked about BigCo: 1) It's unlikely that I will ever be the smartest person. There are world experts in my skill areas, whom I can talk to. 2) They've managed to stay in business, whereas not being able to stay in business was why the company had to sell out to BigCo in the first place.

I mean, I have a similar experience, where I can be demotivated because I took a summer to deploy a website which has one button on it, and a service to write a bit when the button is pushed.

I felt like I could have built out the project in a weekend with php, and I don't even know much php.

But then, in the "productionalization step" there was a lot of leverage from being at bigCo. I could get it internationalized super easily. I got security, encryption keys, done. I got a hostname with a few clicks. I got redundant deployments, and separate release / dev environments. I have metrics and monitoring. My DB is backed up and region sharded and all kinds of stuff I don't care about. Users can delete their accounts and my db can get purged.

So building the "demo" version felt a lot slower, but transitioning it to the production version was a lot faster than me working on my own.

Felt the same at an org (~$30B) I worked at (non-faang). Ended up leaving after two years, did a startup (greenfield/build whatever for mvp, fun/learned a lot/sweat-equity) that didn't succeed, broke, got back into regular job.

For me it was the SDLC part... as in a seemingly small feature would take 2 weeks to get done because you needed to: create a TDD read me that described what you were going to do, how, unit tests involved, side effects, etc... then write the code, unit tests, PR, write more integration testing, PR... get it into a package to be released. But later on I realized that is standard/how to maintain large applications.

Also the other thing that is not as fun is your job is very small/specific I found at the first place I was at. I didn't touch the build pipeline, didn't work with containers, I just wrote front end code basically.

This is why I have decided to stay focused on smaller growth phase companies where I feel like my impact is wider and I can drive change and see results.

I think it's important for everyone to experience different types of companies different roles, and find a space where you feel happy and successful.

The spot may change over time or it may not.

I worked at a BigCo after a bunch of small ones, and got totally stressed about the friction as well. Took me a couple years away from the experience to realize that slow processes can be a great thing in their own right because it gives you a lot of time to think about your own interests in and outside of coding.

Yes, bring the hacker ethos to the system. You’re not fighting code you’re fighting the system.

Need that SSL cert? Request it a month before you need it.

Need that column in the table? Request it long before you need it. Didn’t end up needing it? Sell it to another team, sure it might not be named what they want but they can use it today.

Perhaps not all BigCos are the same? Mine is by no means a startup but stuff like internal SSL certs and similar are mostly self-service and instantaneous. On the other hand if you wanted to delete an unused parameter on a revenue-impacting code path you'd be in for a fun couple of quarters.

I left BigCo that was not in the bay or tech and am at small_co (<500 people). I think its just a matter of the size of company and make-up of engineering org.

If work is broken out to specialized teams (SSL certs, scans, security stuff - team A, VM's and storage - team B, networking/firewalls - team C, etc.) there will be friction, doesn't matter if its some cool company or some boring Fortune 500 company making farm equip.

You should be able to figure out the scale of friction with interview questions like "say a new project spins up to build a web+mobile app/CRUD/SQL and needs servers - walk me through how many teams+time it takes to get servers up and running where a dev can deploy code"

It sounds like it’s pretty early, I’d give it time if you think you can hang on.

I do think it’s worth recognizing that any big company used to be a tiny company, and the road to “big” was probably long and complex.

The growth process from small to mid-sized, and mid-sized to large, comes with a lot of challenges that you may have never witnessed if you’ve been at smaller places. Some of the high-velocity/low-friction approaches to things you might miss (for good reason) become a nightmare at scale. Some of that friction might actually be healthy.

In that regard it’s a lot like jumping into a codebase that’s been around for many years. If it’s your first time some of the code is going to look just awful, but you don’t know why yet.

- maybe pressures at the time meant that code was the right call back then, but it’s not now

- maybe that code is the right call and you don’t fully understand the problem yet because you’re brand new

- or maybe the code really is just bad!

Either way, you can’t really know until you spend some time with it and gain context about the problem domain and the system’s history.

That said, your perspective as a new hire from a place that moved faster is really valuable. I hope you take some notes about these experiences and let them collect for a few months as you gain more context. A good manager and leadership chain should be interested in what you have to say! The more time you spend there the more you’ll be able to flag the areas that seem the best suited for improvement. That kind of stuff can turn into promotion-level accomplishments really fast if you have the right support.

FWIW I had no patience for big companies early in my career and I’m happy I left for smaller ventures, it just wasn’t what I was looking for whether or not the “friction” was justified. These days the pace and process of larger (but not massive) companies suits me better, and I can see some sound reasoning behind some of the things we do that would look like bureaucracy to someone coming from a startup.

Worst case scenario you’ll find out the BigCo life just isn’t for you, at least for now. It’s sweet you’re getting paid to find out :D

Part of the beauty of BigCo is you are being paid to deal with the inefficiency. You have two options sit back, rest and vest or try and streamline things (often a political rather than technical endeavor).

Both can be lucrative journeys.

> The one thing I'm noticing is that it's miserable to work here because EVERYTHING has friction and takes days to get done

I worked at a large media corporation with an office in times square NYC and it was the most unprofessional and demoralizing experience. The level of CYA behavior was mind blowing, it was like interacting with an alien race wearing people suits.

There are people that get off on this kind of environment and thrive in it. They don't care how corrosive it is to the people forced to tolerate it for survival.

It never gets better, get out now before they start inventing KPIs to shame you into submission

Unfortunately, a lot of big orgs build up process as organisational "scar tissue" after someone has eff-ed something up. It is also used as a way to compensate for hiring cheaper/lower quality people.

I work at environment with a lot of peocess. There are a few approaches you can take:

1. Try and get some consensus of support from your peers and/or managers for improvements to make the processes less onerous

2. Do all you can to foster good relationships with the people in the various processes. You would be surprised how much things can be expedited if you're on good terms with the gatekeepers.

Sit back, and enjoy being paid to do nothing. #Friction is accepted at #bigco so while you can enjoy speed, they probably don't.

The company is paying you to work to their schedule, and unless you're working on "efficiency" or workflow improvement - just take it as it is and keep on top of it with your calendar.

Yeah, it's silly to file a ticket for a self signed cert, but it also puts the onus and responsibility on that team ,not you. Yes you'll miss out on small wins like that, but really - it's a cert in the end, and once you raise it up - let the team deal with it.

The big difference between large companies and small companies is that large companies prize specialization. The way to thrive at a big company isn't to be the person that sets up the entire stack for the company, it's by finding value in deep obscure corners of very specific niches and smoothly rolling out that value to orders of magnitude more people than you would had impacted with a package of full stack decisions in a smaller company.

> Anyone else dealt with this?

welcome to corporate world, AKA the meat grinder.... it's all about: "just because you( your work, actually ) are necessary, doesn't mean you ( your work ) are important". Just collect the checks ( i hope they are fat ) and "go through the motions". By the time you grow really sick of everything, let's hope you have saved/invested enough money to be really close to (early) retirement.

Friction is usually caused by reactive policies. Pain causes reaction. Pain like a customer complaint, or accidental data deletion. It usually causes red tape or people that got chewed out from allowing certain changes. It's good and it's bad. It's obviously good because there will be fewer customer complaints. But it's bad because the product does not evolve fast anymore - which may cause fewer customers long term.

I see it as a game. The startup environment is level 1 of the game. you learn about VMs and how to start them. At BigCo, this is level 5 or 10. Nothing is easy, to start a VM you have to make sure your system is compliant, the ip is restricted from some countries, the linux version is LTS and bla bla bla

To keep your sanity, make sure to have a personal side project where you can do things fast

Accept the fact that it takes a lot longer to do anything at a big co. Also, accept the fact that whatever you do, is not crucial to the company as you are just another engineer out of thousands. Hence, why the rush?

If you feel creatively constrained, try to do a fun project so you can learn new things. But don't through away a good job just because it takes long to do anything.

Is this about the same for BigTechCos as much as BigRegularCos?

I've done work for big insurance companies, "tech companies" like Verizon, or big soda companies, and they're as high friction as you'd expect. Somehow I imagined BigTechCos to use better tools and be nimbler on decision-making, letting employees make their own decisions without as much oversight.

Not only does everything have friction, most of it is by design to keep other less talented people in jobs.

If it's truly unpleasant, then try to be that guy who can "make a few calls" and get stuff pushed through a small bit quicker. Pander to the egos you'll encounter, hop to their beat until you get things done because fighting it will just end up taking longer.

I work for a big US corporation. Every job or project is slow to get approved and staffed, and often of little importance. They pay me well and as far as I understand, the company does not fire people and is unlikely to lay people/departments off without at least a few months' notice.

The first 18 months were tough. I came from one of the best tech companies in the world, one of those included in the famous acronym and starts with A and is based in Seattle, and I got quickly frustrated in my new job with the slowness, the incompetence, the politics. And people didn't listen to any of my ideas, how rude!

They would tell me, "yes, good idea," "of course we'll do it," only to realize that no one thought it was a good idea, if they even listened to what I was saying, and no one was working to get anything done.

Then I understood the situation and calmed down. This is the way things work here, I told myself, and nothing I do is going to change anything in such a large company.

Now, some, maybe many among the HN crowd would tell me to move to another job, to find a place in which my ideas, assuming they make sense, are respected, properly valued, where promotions don't happen mysteriously but they reflect the value that the individual is bringing and will bring to the organization.

But why?

Why should I give up on a life that allows me to work little, take plenty of official and unofficial vacations, explore avenues of creativity like writing, painting, and cooking, build up my body by working out at the gym and tan properly by laying in the sun?

Why would I want to work again for a demanding machine in which I am a cog like 95 percent of my stressed, overworked and largely unhappy colleagues?

Why would I want to spend the time I can now devote to reading fiction in the summer sun, listening to great classical music while cooking, preparing instead for interviews that would put me in front of people who, at my advanced age, want to find a reason not to hire me because I am not as smart as they think, wildly overestimating their quality, that they are?

A reasonable question is: well, when this idyllic situation will change, because nothing convenient is forever, what are you gonna do? I guess, if I need, I will start working "seriously" again. But not today, today I am reading a collection of short stories written by one of my favorite Japanese authors.

I ran into that at a previous job. I'd need permission just to get a docker hub repo created or set up an S3 bucket. Too many layers of approvals. I came from a smaller company background where I had full authority to do anything I needed. I couldn't stand a lot of process and overhead, so I quit and went back to a smaller company.

I wrote a post on this topic: https://www.google.com/amp/s/blog.container-solutions.com/wh...

Based on moving from a technology company of 700 to a bank of 120000

You're not being paid to accomplish work, you're being paid to not work for a potential competitor.

That is what you get with already established projects and teams. And it's only the beginning; legacy code will follow, along with horrible styles and ancient practices, and it will be much worse.

That is why I love startups. I gotta find me a nice startup in need of a sr. full stack engineer with backend emphasis.

Yes. I did things like create custom scripts to work more effectively with many different drafts in the revision control we were using. This allowed me to have more than a dozen projects going at a time so there was always something I could switch to that wasn't held up by the friction.

It has friction because you're not working in a vacuum, pun intended. The more people you're working with, the more friction/overhead there is. The trick is trying to automate as much of it as possible, and to batch what's impossible to automate

Explore the limits of your responsibility and find out where you can make your life easier. Find allies in other parts of the business; politics are a fact of life in any big business. Carefully choose which hills are worth fighting for.

I've always done well at big companies because I'm good at going around and talking to people trying to smooth the friction. Consider looking at the friction like some detective work and the opportunity to get some exercise

It's easier to ask forgiveness than beg for permission. And if you look at the rules and systems closely enough you can find an assortment of gaps through which you can operate without having to ask for either.

Not dealing, but living with this, here in Mexico is a common practice even in small companies, everyone seems to be trying to "not doing". I'll read all the comments about this.

You are a cog in the machine whereas you are often the whole machine at small shops. Working for big companies allows you to become anonymous. There's usually no hiding place at small places.

This is standard practice for all #BigCo. That’s why I will never apply for a job at any #BigCo. I love creating things and solving problems. #BigCo routinely makes that almost impossible.

I do not have a job at technology corporations yet but i think it just takes time to you to learn the work and get set emotional to not let things around you dictate how you feel.

I rode a company from 30 people to 7000. Loved it. By the end however, I had to seek other opportunities with a much smaller company because of what you are talking about.

Not gonna lie, I work for a big ISP and I've given up on improving anything. At least I guess you're handsomely paid, which I can't say.

I also work at a large company, I learned to have about 3 things in flight at all times because there will inevitably be a blocker on everything.

Main reason I've always stuck to small companies. Some people are fine with that BigCo environment, but some of us just need something else

Welcome to the real world. We don't have cookies, they were cut as a part of a cost saving package signed by the corporate.

It's not your job to fix it. Keep your head down, get your work done to the best of your ability, be successful.

Friction is just something that comes along with the size of the org. It has matching lubricant - politics.

This is why I work at ~20 people startups.

Occasionally, these jobs end suddenly, but I gladly accept that risk.

Enjoy the idle time while you have it. It's better to have it rather than not.

What happens when you try to go fast through friction? You only generate heat.

I had worked at smaller shops, then took what I thought was going to be a next big step at a company who's mascot is a reptile. Friction EVERYWHERE. The TLDR was that I left after 5 months and that company was the most unhappy I've been in my career.

When I started, I had a single monitor machine that didn't have Visual Studio installed. I was told I'd have to wait till the next budget cycle for a second monitor. I didn't get Visual Studio installed for 3 WEEKS and no one seemed to care. I'm not sure why they thought it was fine for a six figure developer to basically be sitting idle for 3 weeks, but that attitude was basically the norm.

When I actually got coding, everything was road blocks. Policies and procedures everywhere. No one had time to explain anything. Everything had to be submitted through a ticketing system. It was just bad. Daily standups where I just made up BS because they'd barely given me anything to work on, and no one seemed to care.

The thing was that when I looked forward at my team lead, my manager, etc., who in theory would've been my next steps at the company I'd have to jump through ridiculous hoops just to get into those positions, and they all fundamentally had very little power. They were still at the bottom tier middle managers, and the BS policies, procedures, and technology decisions all got handed down from managers above them.

I couldn't deal with the environment, but from my coworkers who were there, I got the sense from them that they just accepted things. Progress was slow, jump through the hoops you're told to jump through, but by in large, it was steady well paying work that they could just check out at the end of the day. No harm in that, but it just felt like my career would just stagnate there, and I'd find it very hard to get out once I got comfortable with it. I planned on sticking around till 6 months, then looking. I wound up starting to reply back to recruiters earlier and was out in 5. Best decision I made was leaving.

> Anyone else dealt with this?

Yes, I too have worked at German owned companies

Read “Orbiting the Giant Hairball” and see if it resonates.

There was another thread[1] a few months ago with a very similar question. I'm not going to cut and paste my reply[2] here, but it applies to this question too I think. TLDR: There are very good reasons everything has friction and requires approval--they're not doing it just to be ridiculous.

1: https://news.ycombinator.com/item?id=29639486

2: https://news.ycombinator.com/item?id=29644628

tl;dr - work at smaller companies in less regulated industries

I'm a PM for security at a CI/CD company, and adding "friction" comes up as a feature request in 50%+ of calls with customers and prospects. As companies grow to a certain size, as a practical matter you can't trust employees to not do bad things. Also, in order to win more business you have to comply with more regulations. Access controls, separation of responsibilities, etc.

Restated, one person's friction is another person's compliance.

How big is the co?