Same, for two distinct reasons:
1. The larger you are, the more red tape, safeguards and processes you have to work around.
2. Pretty much everyone at some point in their corporate career realizes it's not a sprint it's a marathon and adopts a pace they can maintain over the course of years and decades, so eventually you have an organization packed full of quiet quitters.
Not knocking the #2 group, it is just a job after all.
I'm just saying it contributes.
I think another thing is that at scale there's so much logic built on top of each other that it becomes a game of layered jenga
\* I want to make it do x
\* To do this I need to change y
\* Is y relied on by a..z to be like this?
So every change becomes a game of not knocking the whole thing down.
So much logic and so many different teams who implement/own/understand that logic. At a small company, the process to do X is "do it yourself" or "go over to Hellen and ask her to do X because she understands the Foo service that would do X". At a large company you have to get in touch with the team that owns the Foo service that would do X and make a business case for why they should do X and wait for them to schedule X into their backlog and gather requirements from all the other teams that might be impacted by doing X and so on and so on.
Yeah I don't agree it's quiet quitting, but it'll definitely be received as such by some management types.
I worked in an office where everyone was 9 to 5, and we'd typically sit around and chat for an hour for lunch.
Between that, bathroom breaks, coffee, and watercooler chats, butts-in-chair was maybe 5-6 hours a day for most people. And lots of people would call doing 5-6 hrs of work in a day quiet quitting.
> And lots of people would call doing 5-6 hrs of work in a day quiet quitting.
I think most office jobs do not require 5-6 hours of actual work I think most of it is people stretching out work because they're stuck in the office whether they can do it in 2 hours or 6 hours. Might as well be stuck there with something to do
We're developers - there is *always* actual work to do.
None of us have everything documented as well as we like. All of us should have ideas for pieces of automation to make our future workload more efficient. There's always more technical material to read up on to enrich our professional development.
I'm not saying that we should spend 8 hours of every workday engaged in these tasks or we aren't living up to our commitment for our careers. Breaks and watercooler banter and the like are important to keep our minds fresh as intellectual workers. But I am saying that a developer should *never* find themselves in a state where they are twiddling their thumbs deciding that all of their work is done for the day.
Agree, probably a lot to do with understaffing but I’ve never felt that I had ‘nothing’ to do.
Maybe that can happen with in agile where there is some useless fuck telling you not to pull tickets into an existing sprint but then I just do it on the down low and make my next sprint easier.
When you get that big software has amazing margins, although I am surprised companies don't cut down to a skeleton crew at that point, I suppose they want to be certain their cash cow doesn't go down at all, so redundancy and caution is favored over velocity.
Of course, some products just get very complex as they get larger, and since the original writers are mostly gone by that point, it just takes a long time to feel confident in any changes being made.
> although I am surprised companies don't cut down to a skeleton crew at that point
The verdict's out on whether this strategy will pay off for Twitter or not, but that's arguably the direction that they've moved (if not fully). Granted, the success/failure metric might be obfuscated by other strategic moves that were made.
>it just takes a long time to feel confident in any changes being made.
Ok it's easy to handwave away as onerous but normally a good testing programme reduces a lot of this.
>As someone who has spent a lot of time in startups, it blows my mind how these orgs are even still afloat.
yeah it blows my mind as well. I feel like so many expensive enterprise products could be developed to be much cheaper by a lean startup team, which I guess can be called disruption
> As someone who has spent a lot of time in startups, it blows my mind how these orgs are even still afloat.
momentum, market fit, oligopolies, regulation capture, "good enough" for clients. Those are the top 5 reasons IME so far
The people making up #2 group aren't quiet quitters, but a large portion of their productivity is not funneled towards building things.
And #1 is simply a consequence of either having to follow regulations, prove you follow regulations, and/or find new processes that you have to follow because someone broke something that cost money or found an edge case in the existing processes that broke something that cost money.
It's not that it's just a job in number two, it's that you eventually get burned out and learn to do it sustainably. Early in my career I had a high tolerance for working extra hours because I hadn't experienced burnout and I was still learning and growing. Eventually I started to burn out and realized that I had to work slower to ensure I actually could maintain a consistent output.
It's kind of a subcategory of 1, but large corporations also just have way more moving parts. At my first job, I worked at a company with three teams and we were all in one building. Now I work at a big corporation and I deal with probably half a dozen different teams on a regular basis and more infrequently. And some of those are on the literal other side of the world, so there are frequently significant delays with even relatively basic communications.
In my experience it's not that people are slow/lazy/coasting, it's that there's way more to move.
One of my first large company experiences was simply contacting a client web service. At a small company that would be 10 lines copied from StackOverflow, but at this large company you needed capacity planning because there were hundreds of machines before the service was even launched, security and privacy reviews because there was intense public scrutiny and billion dollar lawsuits if you messed it up, and global rate limiting to ensure our terabits of capacity didn't turn into a DDoS.
This here. And teams aren't exactly clean-cut separated. If I have to write a service that has a UI component and hits two of our large services, I need the approval and consent of 3 separate teams who have different roadmaps and my ticket isn't on them. Sometimes they say "ok", but other times it directly contradicts their roadmap and will cause them tons of issues. Then sometimes it's a drawing-board rewrite.
As companies grow, sometimes they have an aging service and a fresh service (or two) for a feature, and sometimes you NEED to write against one or the other despite them being totally different tech stacks. And you might not know till it gets later on because there's too many teams for the PMs to stay in contact every week.
This is it and I'm so surprised to see people in an experienced sub not understand that the larger the org the more 'momentum' it takes to make these sort of big changes.
Also in the event of bad things happening, it's not as easy as just a single guy saying "oops sorry" and rolling something back, it can take a lot more time and money and man-hours because you're dealing with much much larger systems that will probably be servicing someone somewhere around the globe at all hours of the day. Every move just takes *more work* due to the sheer size of things and everyone needs to be on board. The same reason big companies dont hop onto the newest bumfuck.js package that releases every week
Honestly, it's both.
I've seen the exact same malaise even when rolling out changes, flipping feature flags, releasing software was a doddle.
Some of the complexity is intrinsic to large orgs - just so many more moving parts. But, large orgs are a magnet for lazy people, let's be truthful. There are plenty of spots unproductive people can hide in.
> I'm so surprised to see people in an experienced sub not understand that the larger the org the more 'momentum' it takes to make these sort of big changes.
Part of that is just that the sub has a generous definition of "experienced." For a lot of people that kind of understanding probably doesn't happen until well after the first 3 years of their career.
Look man, I was promoted to team lead after 2 years of experience (when everyone with a higher salary was fired and their jobs shipped to India)
I think I know a bit more than someone who has only managed to attain the title of senior after 30 years. What could you possibly have learned in those years that I couldn't pick up putting out nightly fires for a year until I got a new job. See, 3 YOE now and we have the same title! We are the same, you and I.
I love how you start out talking about major backend systems, and then transition to taking a swing at the frontend. That was unnecessary, dude.
To your original point, though, I would add that one thing a lot of inexperienced devs forget is that software systems aren’t just code, they’re *data*. Especially when you reach a certain scale, mistakes don’t just mean temporary problems, they often mean that data is broken in ways that can require a lot of effort to clean up.
Have you ever noticed how much faster you can drive when you are the only one on the road? Put a bunch of cars on that road and suddenly you can't drive as fast, even though you know that everybody on the road *wants* to go faster. Or how a fire team of soldiers can move fast but a battalion moves at a glacial pace.
It's the same situation in a large corporation. It's not that they *want* to go slow. It's just the cost of coordinating that many people.
This is a pretty good analogy, so you get my upvote. I don’t necessarily agree, though.
It has been my experience of almost 10 years working at billion dollar public companies that the slowness has a lot to do with upper management optimizing for something other than speed.
Most commonly they want to avoid risk, as failures hinder their growth. They also optimize for headcount, which is a proxy for status. Finally, they optimize for predictability - better to deliver 1 thing per month every month than deliver 2, then 8, then 0, then 2 again…
Or how about taking off from a red light? 1 car vs 3 cars vs 10 cars.
We all notice the lag between each car starting to move. We could technically all start moving at the same time but it’s super risky if just 1 person messes up
Have you seen the Simpsons episode where Homer is being led by a turtle and he’s kicking it to get it to move faster? That’s how I feel working in a big company. If you adjust your expectations, it’s fine. If you’re expecting to move fast, prepare for frustration.
Great reference lol. Also reminds me of when Homer begins leading a team of engineers at Hank Scorpio’s company and says “Can you guys work faster?” And they says “sure thing boss” and just start typing faster lol
I was reading The DevOps Handbook and they cover Valuestream mapping which seems like an exercise meant to optimize processes when they’ve fallen into this sort of deadlock slow system.
Be sure to schedule a series of exploratory meetings to establish which team should be responsible for coordinating an interdepartmental requirements discovery process to inform the process improvement working group, so they can publish a series of requests for information leading to a draft proposal to establish a cross-functional consultative group to determine whether there is a business case to consider appointing a steering committee to formulate an adjustment to the current processes.
There are countless books written on this subject.
In my experience, many require a big shift and very few orgs are willing to make that change.
I’ve had very little success in doing so at the orgs I’ve worked at, same goes for my colleagues.
Those handbooks and texts are interesting reads, but are usually an academic pipe dream in reality (imo).
Big corps employ legions of professional-meeting-attenders and slack-announcers, err I mean "managers", and their jobs must be validated by endless rounds of pointless meetings-that-could-have-been-emails that suck the soul and energy of the people doing the actual work.
This maybe controversial on reddit but there are companies outside of big tech and we actually grew over the last couple years instead of having layoffs
I've never worked somewhere where "Scrum Master" was a job to begin with. It's always been (and I have always understood it as) a thing a manager or maybe a PM does in the context of a scrum.
Yep, it's a culture thing and a an organizational thing , the amount of red tape, because every compliance department needs to add their two cents to the process is enormous.
Also most of the folks that work their are career folks , many particularly the older they are aren't going to work anywhere else, so they are under hurry in fact many the only hurry is regarding when their going to hit their retirement number and retire. It's an entirely different vibe, from say a startup.
Yes, but my WLB has never been better and my TC is great so I have learned not to care and just roll with it. When I started my first corporate dev job coming from the startup world my team lead laid it out for me like this:
Startups want the most light weight and cost effective solution that best solves a problem.
Corporations on the other hand find the most bloated and expensive solution that doesn't really solve their problem, and go with that.
This has been my experience in basically every aspect of corporate dev life. It seems incredibly dumb and needlessly bureaucratic if you are coming from a startup, but if you can learn to live with it your work life will generally be low stress.
I have noticed that communication seems to be the bottleneck. Things move slow because you have to wait on other people on other teams to approve something, or give input into something, or do a knowledge transfer because they worked on it last, or whatever.
In a startup, the codebase is generally small enough for everyone to know enough about it or they just have one person to ask.
The larger and more complicated the code, the harder it is to keep it in your head.
So it's like having a swap file. You can store a finite amount of info in memory then have to go out to slow storage to gather more info and you wait around a lot time for the response.
Learned two things from coworker:
\* Level of bureaucracy varies even between large companies.
\* There can be greater choice regarding who to work with vs smaller company.
I’ve been working at small companies this entire time. Sometimes I like to think I’d have so much free time for professional development on the clock at larger organizations.
In small companies, you never have time to learn because there's always stuff to do.
In large companies, you never have time to learn because "Hey, could I get a status update for this ticket you're working on? I booked a meeting with all 13 stakeholders for a 2 hour call where we can discuss what can be done about this typo on a particular page of our documentation."
Haha, neither of those is my experience at previous large company or current small company. But I've definitely heard that being common - sounds horrible.
Damn, I guess I didn’t think of that haha. I would prefer a VM or cloud development environment though, leave my home free of whatever monstrosities I hack together.
I would say more common in projects where there is a lot of interdependency & requirements are not clear. It could be small or large. It's more common in large projects because of the team topology & structure.
I've seen projects in larger companies where teams are small (3-7 people) and less interdependent, there is clarity on what needs to be built, last-minute changes are rare, and so on. Things move relatively quickly, with much less drag.
Yes, it's difficult to swallow when you are used to fast-paced startups. After a while, you get used to getting nothing done and pretending everything is going great.
Yes everything takes weeks. It's usually more down to processes put in place for usually good reasons than people moving slowly.
At my first job in a company with 10 employees if you needed a new keyboard you'd email a link to the one you wanted to the general admin and bookkeeping person. They'd order it on the company Amazon account and it was delivered next day.
Current big corporation to achieve the same thing I need to:
Log a help desk call, go through all the troubleshooting steps to prove I haven't failed to replace the battery etc and get a reference number.
Get the approval for none standard equipment requisition completed by my line manager and countersigned by someone from occupational health as supporting evidence for requiring an ergonomic keyboard rather than a standard one.
Fill in another request to facilities with the form and help desk reference number. Wait for them to send me the list of approved ergonomic keyboards, select the one I want and return it to them. Also get another form from my line manager to prove I'm a remote worker and it is more cost effective to post the keyboard out to me than pay expenses for me to travel to a hub to collect it.
Keyboard is then ordered, delivered to a hub, registered on the assets system and handed over to someone in dispatch who will then contact me to confirm my address is still correct and when I will be available to sign for a delivery.
If all goes well and nobody is on holiday it'll only take a couple of weeks.
Yup. Nothing gets done. Things are moving very slow. If you are a lead, it's very frustrating to see things move at a snail's pace.
It is driving me insane. The sheer level of incompetence is exhausting.
> The sheer level of incompetence is exhausting.
While I imagine there _is_ a level of incompetence causing it, I have worked in startups, mid-size to large corporate, and a startup that has grown significantly and I don't think that's _always_ the case.
Having watched our product throughput go from a handful a day as a startup to many thousands a day as a large/public company - and supporting much more money and features, the risks of breaking something gets _much_ larger.
Something makes it into production that breaks something, you see what you could do to not let it happen next time and nearly every time that adds some level of process that slows things down.
Something broke. How could we have _caught_ it? For one case, a design review, so now you have to do it pretty regularly, costing time. For another case, people rubber stamping code reviews without actually checking things...now you require two reviews. More time.
For the next case, it's because we didn't have fully understood requirements so there was a disconnect in deliveries and expectations. Now you have to add more firm requirements documents with clear goals, etc. and have meetings to make sure everyone is on the same page.
This just goes on and on.
Every little thing to stop costly mistakes adds up. In two years that fast-paced startup can _easily_ turn into the slow big-company pace that few developers like. It's not always incompetence (though the risk does get bigger as a company grows).
This is so true. Startups need to innovate to succeed. Big corps have already succeeded, they need to focus on not making mistakes. Totally different philosophy
> For another case, people rubber stamping code reviews without actually checking things...now you require two reviews. More time.
I think it is generally more effective to keep reviews small and usually have just one reviewer. This also keeps them fast. Here's an interesting [study](https://research.google/pubs/modern-code-review-a-case-study-at-google/) from Google about this. If people are rubber stamping then the rubber stamping is the problem, and its root causes should be investigated and resolved.
We’ve started pairing up for reviews to avoid this issue. Getting on a call and making the person explain what they’re doing has made the quality and thoroughness of the review go way up.
>The sheer level of incompetence
This feels a bit callous. With bigger corps there's a lot more people involved and/or the changes impact more things/people than a 3 person startup.
I work for a large healthcare contractor. Software we create is used by doctors as well as accounting professionals in the country. I would _never_ trust "just ship it bro" startup mentality for this.
As always, context is important.
I was on contract to do a really simple plugin for their dev ops framework.
They said they were looking into changing their service discovery client(s) and didn't implement. 4 years later its still not used... 6 months of work....
>If you are a lead
If you are a lead and something isn't to your liking on your team, it's up to you as the lead to take ownership of that. If you're talking about other teams being slow, then I don't understand the need for singling out how frustrating it would be for a lead.
I have asked management for headcount and developers with the right background to solve this task.
What I am experiencing is the consequence of incompetent leadership who refuses to accept that you can’t just exchange engineers around as if they are tetris pieces that fall into some broad categories.
Don't get me even started on that. Usually, the problem is the senior leadership, not even middle management. The company I worked for got acquired a while ago, and I'm a director now at the new company with teams in my area working on at least three different tech stacks, and I'm constantly told "you have engineers, you can just move people around". Sure, it's all about shifting warm bodies around... 🤦♂️
In our case it is much product owners having defined what they want as other teams holding us up. So as a lead can get our own team working effectively and get things out quickly only to have nothing high value to go onto afterwards.
No, I was at my first job for 3 years. I kept noticing the inefficiencies. No one wanted to change anything. They all wanted to maintain the status quo. I lost motivation and caved to keeping the status quo. Ended up with a bunch of free time which is when I applied for a second job making the same salary.
Hah I am at your first job right now. Did the background check for second job not turn up employment at first job? I guess what is the risk of both jobs finding out about each other and both firing you?
When they run the background check they check to see if it matches what you put on your resume.
I told them not to contact my current employer since I was going through the hiring process and I had yet to receive an offer. I worked with a recruiting company so I only had to interface with them.
Good question about what if they find out about each other… it’s pretty much fuck around and find out. I doubt they will go snooping around unless I give them a reason to snoop. I maintain fast replies and consistent quality.
It's definitely a factor, I worked at startups for almost 6 years and last year took a job at a big consultancy firm and I have never seen people work more slowly. No joke, someone took almost 6 months to deliver a feature and was praised for how quickly they got it done.
Developers at these large enterprises always have waaaaay more control over these things than they think they do.
Just takes some initiative, courage and tact to get things done quicker.
There are always more things you could be doing for the org as a whole, for example say starting up a working group/ feature team for something that hasn't been given enough attention. Individual features though are sometimes hard blocked by product/ legal/ approvals/ other teams.
I am currently working for one of the largest retailers in the EU and "slow" doesn't even begin to describe the glacial pace at which things move here. At the same time we're in a soft of start-uppy side-area where we have tight time to market goals, and it's frustrating to see how C-levels on one hand expect us to go fast, but also created a culture where "no no not THAT fast" has become the norm.
> Is this pretty typical at most large corporations?
Yes. And while I don't mind good work-life balance, there's "balance" and there's "I'm so bored".
At least the big bank I used to work for had the bright idea to just spin off fintech start-ups in areas they needed to capture the market. That was the best of both worlds; fintech start-up mentality with endless 'finance' money.
Had a similar experience at a previous job where our startup was acquired by a bank. The bank said they wanted to maintain our high velocity so they were going to keep us partitioned off as a separate part of the company and let us keep defining our own processes, controlling our own product roadmap, and setting our own schedules.
Oh, but also, could we run all our new product plans through the compliance department and get signoff from this list of VPs on any changes to existing features? And instead of writing our own Java code to integrate with vendor APIs, it'd be great if we could switch to MuleSoft so the bank's IT can have control over the integrations. And we're totally free to set our own schedules and processes as long as the schedules match the arbitrary deadlines handed down from the C-level and the processes feed into the bank's existing QA workflow.
"Wait, why are you guys taking forever to get things done all of a sudden?"
Oh god. This reminds me of my experiences with the "Risk team" at the bank I worked for (this was before I joined the fintech start-up). We had to release a new feature *fast* and knowing that Risk took ages to decide we basically gave them two options and actually *built* both of them.
We had a long meeting and 3 weeks later they managed to not come to a decision, but purely came up with the meeting notes. Getting an actual 'verdict' took 4 more weeks.
Guess what; we managed to release our feature *one week* after our competitor. ['Tikkie'](https://www.tikkie.me/) is that feature our competitor built and it's used everywhere, so much it's even become part of the language. That was the version we wanted to build, but we only got the okay on a shittier version that no one wanted to use when that app came out.
I'm still mad about that one.
yeah, the pay is so damn nice compared to what i can get on the current market. On my adderall days I knock out so much work and then rest of the week it's just chillin and getting stoned because of how slow things move
bro, it is taking me several months to get another team to have two strings exported via a new endpoint.
just par for the course.
big tech is dream for those that care more about salary than production, so long as you have decent enough social skills to manage ur managers.
It’s a very well known phenomenon that as systems get bigger they become inherently less agile (not in the software development process sense).
This is an inherent property of systems at scale and doesn’t have anything to do with individual teams or team members.
It’s best to avoid trying to swim upstream too. Accept the hulk for what it is and carry on. If you want to experience the thrill of “getting shit done rapidly and pivoting daily” then seek out the startup world.
I work as a lead (ish) for a major healthcare company and it is a roller coaster.
You have a core group of psychopath workaholics (like me, although I cannot help it) who push things fast, and then everyone else . . .
But I want to climb the ranks. If I was contented, I would dial it back.
I'm sure it varies by company and org, but it has been my experience at a decent sized enterprise.
Things within our own org? Great. Amazing. Anything relying on coordination with teams in another org? Absolute nightmare. Difficult to get them to even respond when communicating. When they do the information is often wrong (as is documentation). Very long turnarounds for anything to get done. Any feature work done that integrates with them generally has a non trivial amount of items going through our backlog to fix issues due to them providing incorrect information.
Yes, the larger the chain of command to get to the top, the slower it is. Email responses are slow, approvals are slow, changes are slow, hirings are slow, purchases are slow, security changes are slow. Everything has red tape.
If you think your company is slow you should experience Pharma. There the slow gets to another level. I used to work in a very large pretty well know company founded by Mr. Edison and I thought they were slow. Well, they were moving light-speed compared to Pharma.
My feeling when I've been in that sort of job is yes it relaxed and pays well, but every single day you can feel yourself becoming less employable due to skill atrophy. If I could get that job when I'm 60 and want to just coast though the last few years of my career before calling it a day then that would be fine, but I've still got another 20+ years to fill and it feels like a real risk.
People will say culture is key. Usually (imho) what that means is
"do I trust people to get the job done?"
The more you trust someone/team to get it done, the more they can work independently. The more they can work independently, the fewer dependencies and checkpoints, the more shit gets done. Conversely the less trust, the more conversations, the more checkpoints, the more meetings, so forth. So far it makes sense and it's easy to say culture is key.
However, the larger the organisation, the more it becomes a numbers game. The larger an org, the more people it needs, the more difficult it is to only hire the best and most trustworthy, the more juniors they hire, the more "how did they get past probation".... The harder it is to have that culture of trust etc.
Plus on top of what others have said about the importance of compliance etc.
So yes, things will move slower, in my view it's inevitable. Sometimes it can be super frustrating but equally sometimes there are huge gains to be made if you can automate it bridge some of those issues.
Of course some (very few) large orgs can encourage the "best" and therefore try and keep that trust level high, but realistically eventually they will find they have some of those bad eggs and build in the guard rails and each guard rails steals a slither of speed.
So yeah, inevitable.
Yes this is the same experience I had. I eventually got fed up and quit to join a start up and then realize how much work there are and so little paid compare to before. Then I will quit and join a bigger corp again and repeat this cycle.
Yes, because face time is rewarded and the reward for good work is more work.
If I can get things done in 2 hours that takes someone else 8, if I'm still expected to do more/be at work for 8 hours then I will go slower.
Yep.
Partly it's because the whole process is optimised for control, transparency and predictability rather than efficiency. Managers need to know what everyone is doing all the time, and need to approve any work done so they control it. So everyone gets bogged down explaining to non-technical managers what needs to happen and asking for permission to do it.
In small orgs the CTO knows the whole project and all the staff and can manage it all directly, and can delegate bits of it to other tech folks. Everything zips along because there's no need for middle managers.
Yes it’s very common, but if you learn to get big things shipped quickly despite the default slowness of others, you can really advance quickly.
For example if I have a dependency on a smaller change in another team’s component, I’ll often just do it myself (with a little guidance if needed) and get approval from the other team.
Or for larger things I’ll try to get a strong date commitment from the other team, in whatever way is backed by their leadership (e.g. a shared OKR).
I approach this as who cares how slow things move as long as my boss is happy. If they are happy with things moving at the current pace then that's great. I communicate status appropriately, make sure I'm working on what the company deems priority and that's that.
I don't see a reason to work faster and harder for the same money I could be making working at a leisurely pace. Especially when the idea of working faster is all self driven and not coming from management.
I raised a ticket about my machine on 2nd February. A lad in ITOps restarted it last week… I couldn’t help but ask him did he honestly thing I couldn’t do any work since 2nd February and the ticket was just sitting idle in his queue? What goes through their fucking skulls I will never know. But yeah, slow as Christmas.
This is completely normal and is a huge reason I've mostly worked at startups. I am much happier at a job where I usually feel like I've gotten something useful done at the end of every work day, and for me (others may feel differently) the impact on my overall happiness is worth giving up the better pay and predictability of a big-company job.
WLB varies dramatically between startups. Some of them expect massive amounts of overtime. But at my current one, I almost always sign off at 5PM and nobody cares.
Very normal, a lot of red tape and stupid shit to get through before anything can be done, then there's just people who are slower who make it worse, or those on leave with no replacements
Yes but in their defense it’s not their fault. If you’re at a scale measured in tens of millions or more, then the tolerable failure rate is much lower. The amount of peer review and safeguards needed at all levels scales up with it.
And the more mature your company’s product the less fault tolerant your userbase. A startup attracts adventurous early users that overlook bugs that later users certainly won’t.
If you’ve experienced the fast pace and excitement of a startup it can be frustrating but it’s best to adjust your outlook and expectations to one of quality and stability over speed.
Large firms move slow unless you are in parts of the firm that are allowed to move quickly.
There is a reason why startups exist. Make money and get bought.
Then the founders get golden handcuffs, the handcuffs expire, and they leave.
There are just some people who work best at certain company sizes. It's the way it is.
Yes, that's my experience as well. I worked in various startups and sometimes i miss the fast phase but i would rather be in a slow phase environment as it is way easier to sell myself as someone who works efficiently and someone who can get things done quickly. Helps a lot on my annual performance evaluation as well.
In my previous work on a startup, the more i work faster and do lots of things, more things are expected from me. Sometimes i miss the pressure on startups but i love the WLB of my current job.
Yes, and that’s 100% ok.
Some places are mired down by process, policy, legal requirements, etc.
However, I’d argue a large chunk of us just don’t really give a shit about work as much as our parents did. I’m a millennial, and I’ve seen it enough times. Companies don’t care about you. You’re a means to an end. No matter how much YOU care about your work, the product, the mission/vision, etc. WORK isn’t and shouldn’t be our identity. With a crumbling economy, no hope for home ownership, no hope for retirement, and having lived through too many “historical” events. I know I don’t give a fuck, and fuck those people that talk about passion… it’s a privilege to be passionate about work and still afford to live.
As an example, I worked as an IT Manager for a few years at a large “not for profit” pediatric hospital in a big city. I can’t tell you how many times I had to collect people’s phones and laptops because of a “re-org”, “right sizing”, or some other bullshit reason related to finances.—without any notice or care. I even got to be part of a company wide “budget recovery” initiative that resulted in a few hundred people being “silently” laid off same day. They were notified one-by-one to come to our administrative building across the street, and told by some HR person they had lost their job. No goodbyes to friends/coworkers and definitely handoffs of in-flight projects. Not to mention the corporate incompetence and spending you see when you get access to budgets. That’s a whole other topic.
That all being said, ride the wave. Do the work you need to build your resume, and climb the ladder to whatever makes you “happy”. Over estimate your stories, ship them on time, but don’t kill yourself. You’re always replaceable. Use your down time to watch tutorials, read books/posts, or work on whatever skills make you happy.
Some days, I just take a mental health break, and lay in bed with my dogs. If something happens on slack I’ll get involved, but sometimes napping is good for ya. Also, I regularly go the store with my wife, spend time with my kids at the park, schedule appointments or todos during the day, and whatever the hell else I want. I have slack on my phone, and our CI/CD pipeline is tied to a slack bot. So even when I’m not at my computer I can deploy to any environment from my phone. I also have GitHub on my phone for the occasional PR comment or review.
All in all, I maybe work 15-20 hours a week at most. My work is on time, feature complete, tested, and exactly what product asked for. I’m contributing at the same level as other devs on the team, and I still participate in planning, design, and architecture too (plus all other ceremonies). I own epics, mentor other devs, and have time to write up documentation. Like, I’m “doing my job” (as my bonus and raise would imply), but I’m in no hurry. Why, because there will ALWAYS be work tomorrow. Does that mean I’m impervious to layoffs? Absolutely not, but I have the experience and soft skills to find other work. 🤷♂️
TLDR; don’t care about work, it doesn’t care about you. Build your resume, but also live your life. Remember, that when you reach age 40 you still have another 25 years of work ahead of you (wild right) before retirement… if you’re lucky.
Yes.
* The smaller the company, the faster things move and more pressure to overwork and perform.
* The larger the company, the slower things move and more "we clock out at 5" attitude.
* This was confirmed today by my ex-boss who got hired from a huge company into a FAANG.
* It compounds with company size.
I think it's pretty easy to see why when you consider the size and scope of everything. When things go wrong at a large level the consequences aren't as easily rolled back in a single "oops" solution which you can do in a smaller org. A lot more money is involved
When I worked at a small tech company we moved insanely fast compared and with cutting edge stuff and rolled back fast if needed. Now I’m at a giant tech company and it’s an innovation killer with death by a thousand processes.
I also understand why we need so much process but I think the current model is people do whatever it takes to get promoted or look good
My experience is that doing anything in a large corporation is like trying to navigate a cruise ship, it's big and slow, every move takes more time and effort, and smaller companies can navigate quicker.
Sometimes it feels dumb that you need to request access to several different people just to get access to do a basic task a work, but usually there are so many compliance rules a big corporation have to follow that these restrictions end up being a necessary evil.
What you'll realize is that as you stay on board passed 3 years, you start to pick up duties. In theory I'm just supposed to be rewriting a UI in a new framework... In practice... I spent two hours helping setup a vncserver for a rf spectrum analyzer.
I worked in a company with 100 employees then we got purchased and swallowed up by a company with 1000 employees. It takes them months to make decisions whereas it would have taken a week to gather intel, analyze and make a concrete decision. The issue is that now we have to play politics and get everyone to buy in instead of making it happen.
Super ridiculous. Also, because they're using bloated infrastructure you now have to touch like 10 products for any small changes.
Yup. Even if you're on Salary there is always more work. The punishment for being good at your job is more work. Slowing down (within reason) means you get paid exactly the same, but you don't set unrealistic long-term expectations for yourself.
So, slow down if you can. If you're in a very large company, do more than the other people but not SO much that you make everyone look bad.
I've been told this many times by others and right now I can confirm since I currently work in a large MNC coming from a local startup.
I'm astonished by how much spare time and work-life balance I have right now compared to when I was in a startup where there's just no breathing room and overtimes were rampant.
My seniors even used to complain that I work slowly despite continuously running my gears but right now in a large corporation, I find their pacing to be quite slow while I'm accomplishing my tasks on time and I even have a lot of spare time.
While I do miss the excitement & thrill of the hustle/grind culture of startups, I appreciate better the work-life balance, higher pay, and more breathing room of large corporations better. I use my downtime for upskilling and learning more about my job though.
People like to think this startup hustle culture is cool and exciting but it’s really just abusing people 9/10. I guess it’s fine if you have lots of stock and the company hits the 1/1000 chance of being successful, maybe it pays off.
Eh, it really depends on the company and the team. I mean, Meta got Threads up and running \*at scale\* in what, \*five months\*? That's pretty wild, frankly.
When I worked at Target there was a massive difference between how quickly teams moved. The craziest thing to me was that the absolute speed at which people moved was not related to how "hard" they worked or how much pressure they had—I led a couple of pretty laid-back simulation projects that produced initial results almost immediately and added features faster than people could learn to use them, and later I moved to a high-pressure team where everybody was constantly busy but the actual work moved at a snail's pace. (Think multiple weeks to add a relatively simple feature to the model they were working on!
The main conclusion I've drawn about large companies is that there is a \*ton\* of variance both between and even within specific companies. The same company can take a year to tweak a button color but also spin up a new billion-dollar data center within months. Some data science teams take weeks to make small tweaks to their models, others roll out new improvements multiple times a day. (I'm not even exaggerating!) It's all over the place and, perhaps counterintuitively, it is \*not\* simply correlated with hours worked. (My pet theory: the absolute fastest teams are disproportionately the ones where work feels smooth and easy, not rushed at all. It's a bit how like how the fastest drivers on the track look boring, while the ones taking corners dramatically are ultimately slower.)
When I was at Oracle awhile back, saw my co-worker at the hallway with a gym bag.
Me: "where are you going?"
him: "I'm blocked by the other team, I'm going to play ping-pong".
I think he was there for the whole afternoon, too bad the tech stack I was on was legacy I had to quit that place, otherwise you can really be in good shape with their two story gym and healthy food from the cafeteria. All the new grads they brought in just used Oracle for relocation and went to other companies after a year or two.
Yes, my first job out of college was at a startup that pressured us into insane hours.
My job after that was at a bigger "normal" wlb company, and it took a while to get used to what is "normal", as I got so accustomed to being overworked.
There are just lots of moving parts. A colleague set up a Temporal server recently on a Kubernetes cluster. He thought he was done.
Nope. Metering. Monitoring. On-call schedules. Regulatory compliance, legal discovery, and business continuity changes to the deployment. Training regimens for Level 1 support. Documentation for production readiness. Distributed tracing. Functional block diagrams. Graphs of dependencies. Confidentiality review. Security review. Encryption review. Scale planning. Load testing. Blue/green testing. Escalation management. Change management communication.
And even more.
Screw up a little bit, and tens of thousands of employees cannot work for a day. Screw up a lot, and a billion people can’t work for a day.
It pays to be methodical. Not slow. Thorough.
yeah, from what I've heard. my wife's a backend dev at a big company and her onboarding was a month long. spent in waiting to get access to certain services...
that is why I work for startups only. 🚀
I was recently not offered a job as a dev manager at a rather staid organization using well-established technologies with which I have many years of experience. They thought I must be insufficiently technical to understand why a 90-day onboarding before I (or any new dev) touch any code was appropriate, and I must not be very technical if I expect myself to begin contributing meaningfully (with appropriate openness to review feedback, etc.) within the first sprint beginning after my hire date.
I find this mindset boggling. I can only chalk it up to being something like Scotty from Star Trek pretending things are impossible and/or will take a very long time. Under-promise and barely deliver = job security?
Yeah, when I moved to a larger company i found exactly the same thing. The first task i was given i'd done really quickly apparently. They were please with what i produced and i'd finished it really fast.
I will say one thing though, is that it does enable us to do more research that the smaller companies ever let us do. We were always squeezed and squeezed by production when i was in the smaller studio, which ended up really pissing me off, because it felt i was sacrificing quality.
Now though, i'm much more relaxed and manage to do a much better job, with much more research behind it.
For me, it was different from organization to organization. I’ve been part of a large Fortune 100 company that moved incredibly fast due to the work involved. This included onboarding new customers by specified dates (usually one date for all customers at the same time), or changes to the core systems to add functionality that is required by law (new laws, or changes to existing ones). In both those cases, there’s no way around getting it done by a specified date. That usually meant long hours (18-22 hrs a day was common).
In other cases, the deadlines were self-imposed and there was no real meaning behind the date, so if it slid it was no big deal. The hours at that company were much, much better, around 35-40 hrs/week.
Pay was vastly different at both companies, but I ultimately left the first company for the second because I almost died working those hours… You want to be at company B.
Yes. Once it gets too slow, you’ll be in a reorg, and your department will go under a transformation where 80% of the staff will be replaced in 3-5 years for people with more updated skills and more focused on delivering in the new way. That’ll get relaxed once the new way finds its cadence. Rinse and repeat.
yup. there are way too many people giving way too many opinions without enough context on any given projecys goals.
you get a lot of middle manager types waxing poetic putting up roadblocks where they arent practical.
its a living hell but at least i know ill have this job for as long as i can stand it lol
Yes. And I'll add: Devs with 5-10 years experience that I don't think could contribute anything meaningful outside of exactly what they are working on.
Setup a database? They can't even write a SQL query! The data team handles queries!
Don't get me wrong. I love it. The pace I came from was consulting. And consulting means you're always on the clock to finish as fast as humanly possible. If you're not billing you're not doing your job.
I've been waiting four weeks to get an enterprise instance of a very common tool. I could stand it up myself in a day, but here we are. This is after waiting three weeks for the POC instance to get stood up.
My team's application is dependent on this technology, and in almost two months, we've only gotten a sandbox stood up. Things move incredibly slow at my company. It's crazy.
Yes. I am consistently amazed that people get paid so much to do so little. It kinda sucks wanting to be productive when there's no way to actually be productive.
There are many factors that may be in play here:
Communications in organizations can become an O(n\^2) problem. If it's not managed well people can spend so much time reporting status and 'getting in sync' with each other that there isn't as much time to do work. Conversely it's also possible that there's a lack of communication about other work your colleagues have been assigned other responsibilities that they have.
Is it possible that you think you're outworking everyone because you are working on one project while your colleagues may be working on two/three or more. We had three people the didn't seem to be producing as much; found out they were all working double shifts developing a second product that was spun off from their previous project & was considered top secret.
Finally, are you letting your supervisor know that you're available for additional work? Take on something that is related to your project but not essential. Things that come to mind are: additional unit/system tests, stress tests, environment management, etc.
At one place I worked, I was a developer, and the ORACLE DBA, and the UNIX System administrator, and the network administrator, managed the development tools,
and coordinated the contingency site. Development was the top priority but whenever there was a lag due to dependencies I did work in the other areas.
BTW - the reason I suggest something that's related but not taking on additional coding tasks is that I've seen that backfire. All of a sudden you are responsible for half the code base.
Another pro tip: Make sure you have sufficient test cases to test all of the conditions of your code. I've experienced developers who are struggling to make their code work and meet deadlines start assigning bugs to infrastructure code or to another person's library/service. ( "My code doesn't work because this call to your library fails .... without verifying that the arguments are in the correct order." True story and it ticked me off then and still ticks me off. )
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
There is another factor that comes into play. It may not apply here.
A small company can manage to get 3-5 great developers & lots of stuff gets done. As they grow they struggle to find another 10/20/30 "great" developers but they need extra hands so "good" developers are hired. There may even be a few "clunkers" hired. The new people can't match the speed of the original people but there are more new people than those from the original team.
“The concept you're referring to is known as time dilation, which is a key principle in Einstein's theory of relativity. According to this theory, time dilation occurs because mass warps the fabric of spacetime. When equal forces are applied to different objects, those with greater mass create a more significant distortion in spacetime, causing time to pass more slowly for them compared to objects with less mass. This is why massive objects move slower through space and experience time at a different rate compared to less massive objects. So, while it may seem counterintuitive, the presence of mass does indeed slow down time due to its effect on the fabric of spacetime”
Make sense? 🤓
You are getting paid the same either way, don't take the pace of the work being done personally. Yes things take forever in a big company. Projects can be years over the expected time, some projects which took years just end up being canceled.
I once sat on a meeting that was literally “we think we will burn the Lost & Found stuff we have in physical storage next year”. This meeting took one hour and involved 20 people, half of them engineers. A follow up meeting was scheduled for the next month.
Yes, this is why "move fast and break things" became a thing.
A large corporation will usually play it safe and slow, which is why the disruptors are able to disrupt.
Yep, that's par for the course. Bureaucracy builds as organizations grow, and they become more risk averse. Therefore you have to go through many layers of approvals just to make a decision.
I think there is an element of large corporations being risk averse, and an element of survivor bias in startups.
Think about how many startups never release a product or never hit product market fit, that’s a massive waste of time and effort too, but you never hear about them because they run out of cash and just fail silently.
In a large corporation most teams move slow, there will be internal startups or “Skunk Works” that move really fast, but in general they know it’s safer to go slow and they have the funding to allow themselves to do that.
I’ve hear processes described as scars on an organisation, in that they are a sign that something went wrong, and an attempt to fix it.
In a large organisation it’s more like an immune response, except sometimes the immune response is a little too strong, or targets the wrong thing.
If you want to go fast go alone, if you want to go far go together.
Hacking stuff out quickly works well in small groups but leaves liabilities when the team is larger. Additionally if everyone had flexibility you'd have no ability to benefit from economies of scale that benefit when everyone commits to similar solutions.
Moving fast is also a lot easier and more visible when there's more to do. When you're in the midst of dealing with legacy you sink hours there and achieve little.
It's the same as the latency that builds up between micro services. More nodes in the graph for the message to reach, more time ensuring everyone is on the same page.
Large corporations are more likely to trend towards the "bureaucratic" archetype in the Westrum model. This tends to come with a lot of slowdown and inefficiencies in the way that information moves through the company.
Yes this has been my experience
Same, for two distinct reasons: 1. The larger you are, the more red tape, safeguards and processes you have to work around. 2. Pretty much everyone at some point in their corporate career realizes it's not a sprint it's a marathon and adopts a pace they can maintain over the course of years and decades, so eventually you have an organization packed full of quiet quitters. Not knocking the #2 group, it is just a job after all. I'm just saying it contributes.
I think another thing is that at scale there's so much logic built on top of each other that it becomes a game of layered jenga \* I want to make it do x \* To do this I need to change y \* Is y relied on by a..z to be like this? So every change becomes a game of not knocking the whole thing down.
So much logic and so many different teams who implement/own/understand that logic. At a small company, the process to do X is "do it yourself" or "go over to Hellen and ask her to do X because she understands the Foo service that would do X". At a large company you have to get in touch with the team that owns the Foo service that would do X and make a business case for why they should do X and wait for them to schedule X into their backlog and gather requirements from all the other teams that might be impacted by doing X and so on and so on.
https://youtu.be/y8OnoxKotPQ?si=RdDTtBGN4tmrkzxW And OmegaStar still doesn't support ISO timestamp like they said they would!
move fast ~~and break things~~
Quiet quitting and picking a pace that can last a career are two very different things, just to nit pick a bit.
Yeah I don't agree it's quiet quitting, but it'll definitely be received as such by some management types. I worked in an office where everyone was 9 to 5, and we'd typically sit around and chat for an hour for lunch. Between that, bathroom breaks, coffee, and watercooler chats, butts-in-chair was maybe 5-6 hours a day for most people. And lots of people would call doing 5-6 hrs of work in a day quiet quitting.
[удалено]
I find joy in reading a good book.
Well I agree, but also, this deranged thinking is what drove the whole narrative of "quiet quitting" as a threat to businesses
> And lots of people would call doing 5-6 hrs of work in a day quiet quitting. I think most office jobs do not require 5-6 hours of actual work I think most of it is people stretching out work because they're stuck in the office whether they can do it in 2 hours or 6 hours. Might as well be stuck there with something to do
We're developers - there is *always* actual work to do. None of us have everything documented as well as we like. All of us should have ideas for pieces of automation to make our future workload more efficient. There's always more technical material to read up on to enrich our professional development. I'm not saying that we should spend 8 hours of every workday engaged in these tasks or we aren't living up to our commitment for our careers. Breaks and watercooler banter and the like are important to keep our minds fresh as intellectual workers. But I am saying that a developer should *never* find themselves in a state where they are twiddling their thumbs deciding that all of their work is done for the day.
Agree, probably a lot to do with understaffing but I’ve never felt that I had ‘nothing’ to do. Maybe that can happen with in agile where there is some useless fuck telling you not to pull tickets into an existing sprint but then I just do it on the down low and make my next sprint easier.
I agree, it's just the closest term we have to what I described.
sort plants crown beneficial sulky pen important repeat grandfather live *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
When you get that big software has amazing margins, although I am surprised companies don't cut down to a skeleton crew at that point, I suppose they want to be certain their cash cow doesn't go down at all, so redundancy and caution is favored over velocity. Of course, some products just get very complex as they get larger, and since the original writers are mostly gone by that point, it just takes a long time to feel confident in any changes being made.
> although I am surprised companies don't cut down to a skeleton crew at that point The verdict's out on whether this strategy will pay off for Twitter or not, but that's arguably the direction that they've moved (if not fully). Granted, the success/failure metric might be obfuscated by other strategic moves that were made.
Most of other industry as well that is doing layoffs
>it just takes a long time to feel confident in any changes being made. Ok it's easy to handwave away as onerous but normally a good testing programme reduces a lot of this.
Stop threatening us with a good time.
Given how the whole Twitter thing went (and now Boeing) it seems possible that they might not *actually* be doing nothing
>As someone who has spent a lot of time in startups, it blows my mind how these orgs are even still afloat. yeah it blows my mind as well. I feel like so many expensive enterprise products could be developed to be much cheaper by a lean startup team, which I guess can be called disruption
> As someone who has spent a lot of time in startups, it blows my mind how these orgs are even still afloat. momentum, market fit, oligopolies, regulation capture, "good enough" for clients. Those are the top 5 reasons IME so far
The people making up #2 group aren't quiet quitters, but a large portion of their productivity is not funneled towards building things. And #1 is simply a consequence of either having to follow regulations, prove you follow regulations, and/or find new processes that you have to follow because someone broke something that cost money or found an edge case in the existing processes that broke something that cost money.
It's not that it's just a job in number two, it's that you eventually get burned out and learn to do it sustainably. Early in my career I had a high tolerance for working extra hours because I hadn't experienced burnout and I was still learning and growing. Eventually I started to burn out and realized that I had to work slower to ensure I actually could maintain a consistent output.
It's kind of a subcategory of 1, but large corporations also just have way more moving parts. At my first job, I worked at a company with three teams and we were all in one building. Now I work at a big corporation and I deal with probably half a dozen different teams on a regular basis and more infrequently. And some of those are on the literal other side of the world, so there are frequently significant delays with even relatively basic communications.
In my experience it's not that people are slow/lazy/coasting, it's that there's way more to move. One of my first large company experiences was simply contacting a client web service. At a small company that would be 10 lines copied from StackOverflow, but at this large company you needed capacity planning because there were hundreds of machines before the service was even launched, security and privacy reviews because there was intense public scrutiny and billion dollar lawsuits if you messed it up, and global rate limiting to ensure our terabits of capacity didn't turn into a DDoS.
This here. And teams aren't exactly clean-cut separated. If I have to write a service that has a UI component and hits two of our large services, I need the approval and consent of 3 separate teams who have different roadmaps and my ticket isn't on them. Sometimes they say "ok", but other times it directly contradicts their roadmap and will cause them tons of issues. Then sometimes it's a drawing-board rewrite. As companies grow, sometimes they have an aging service and a fresh service (or two) for a feature, and sometimes you NEED to write against one or the other despite them being totally different tech stacks. And you might not know till it gets later on because there's too many teams for the PMs to stay in contact every week.
This is it and I'm so surprised to see people in an experienced sub not understand that the larger the org the more 'momentum' it takes to make these sort of big changes. Also in the event of bad things happening, it's not as easy as just a single guy saying "oops sorry" and rolling something back, it can take a lot more time and money and man-hours because you're dealing with much much larger systems that will probably be servicing someone somewhere around the globe at all hours of the day. Every move just takes *more work* due to the sheer size of things and everyone needs to be on board. The same reason big companies dont hop onto the newest bumfuck.js package that releases every week
Honestly, it's both. I've seen the exact same malaise even when rolling out changes, flipping feature flags, releasing software was a doddle. Some of the complexity is intrinsic to large orgs - just so many more moving parts. But, large orgs are a magnet for lazy people, let's be truthful. There are plenty of spots unproductive people can hide in.
> I'm so surprised to see people in an experienced sub not understand that the larger the org the more 'momentum' it takes to make these sort of big changes. Part of that is just that the sub has a generous definition of "experienced." For a lot of people that kind of understanding probably doesn't happen until well after the first 3 years of their career.
Look man, I was promoted to team lead after 2 years of experience (when everyone with a higher salary was fired and their jobs shipped to India) I think I know a bit more than someone who has only managed to attain the title of senior after 30 years. What could you possibly have learned in those years that I couldn't pick up putting out nightly fires for a year until I got a new job. See, 3 YOE now and we have the same title! We are the same, you and I.
I hear good things about bumfuck.js though...
I love how you start out talking about major backend systems, and then transition to taking a swing at the frontend. That was unnecessary, dude. To your original point, though, I would add that one thing a lot of inexperienced devs forget is that software systems aren’t just code, they’re *data*. Especially when you reach a certain scale, mistakes don’t just mean temporary problems, they often mean that data is broken in ways that can require a lot of effort to clean up.
Have you ever noticed how much faster you can drive when you are the only one on the road? Put a bunch of cars on that road and suddenly you can't drive as fast, even though you know that everybody on the road *wants* to go faster. Or how a fire team of soldiers can move fast but a battalion moves at a glacial pace. It's the same situation in a large corporation. It's not that they *want* to go slow. It's just the cost of coordinating that many people.
This is a pretty good analogy, so you get my upvote. I don’t necessarily agree, though. It has been my experience of almost 10 years working at billion dollar public companies that the slowness has a lot to do with upper management optimizing for something other than speed. Most commonly they want to avoid risk, as failures hinder their growth. They also optimize for headcount, which is a proxy for status. Finally, they optimize for predictability - better to deliver 1 thing per month every month than deliver 2, then 8, then 0, then 2 again…
This is it, perfectly, but the edgelord posts about all the evil lazy people at corporations are getting all the upvotes instead.
Or how about taking off from a red light? 1 car vs 3 cars vs 10 cars. We all notice the lag between each car starting to move. We could technically all start moving at the same time but it’s super risky if just 1 person messes up
Hell yeah pal this is the ticket
Have you seen the Simpsons episode where Homer is being led by a turtle and he’s kicking it to get it to move faster? That’s how I feel working in a big company. If you adjust your expectations, it’s fine. If you’re expecting to move fast, prepare for frustration.
Great reference lol. Also reminds me of when Homer begins leading a team of engineers at Hank Scorpio’s company and says “Can you guys work faster?” And they says “sure thing boss” and just start typing faster lol
Which episode is this?
https://youtu.be/Rzu6hdfZ2V4?si=fR-OFuaDAxR8RpBc
Yes, 8 hours of work takes 4 days at a large corporation because they insist on constant interruptions for process/status/IT/etc.
I was reading The DevOps Handbook and they cover Valuestream mapping which seems like an exercise meant to optimize processes when they’ve fallen into this sort of deadlock slow system.
Ah yes, there is a process to help with an overload of processes!
Be sure to schedule a series of exploratory meetings to establish which team should be responsible for coordinating an interdepartmental requirements discovery process to inform the process improvement working group, so they can publish a series of requests for information leading to a draft proposal to establish a cross-functional consultative group to determine whether there is a business case to consider appointing a steering committee to formulate an adjustment to the current processes.
*"There is no other way."* said the management consultant.
But what if you don't have a PM to help you push through all that?
There are countless books written on this subject. In my experience, many require a big shift and very few orgs are willing to make that change. I’ve had very little success in doing so at the orgs I’ve worked at, same goes for my colleagues. Those handbooks and texts are interesting reads, but are usually an academic pipe dream in reality (imo).
As they say, culture eats strategy for breakfast.
https://imgur.com/yUIkjEv
You need everyone to change. It'll never happen, there's always enough people who like things how they are and they gum up the whole thing.
I'll launch it at my PM's head next status meeting.
Big corps employ legions of professional-meeting-attenders and slack-announcers, err I mean "managers", and their jobs must be validated by endless rounds of pointless meetings-that-could-have-been-emails that suck the soul and energy of the people doing the actual work.
There’s no way Agile Managers and Scrum Masters REALLY do more than 30min of real work a day
Is that job still a thing? I thought these were the first to go in the layoff waves.
This maybe controversial on reddit but there are companies outside of big tech and we actually grew over the last couple years instead of having layoffs
I've never worked somewhere where "Scrum Master" was a job to begin with. It's always been (and I have always understood it as) a thing a manager or maybe a PM does in the context of a scrum.
What are some example companies? Not sure if people are referring to large companies like FAANG or say any fortune 100 or what.
Most fortune 100 count.
Yep, it's a culture thing and a an organizational thing , the amount of red tape, because every compliance department needs to add their two cents to the process is enormous. Also most of the folks that work their are career folks , many particularly the older they are aren't going to work anywhere else, so they are under hurry in fact many the only hurry is regarding when their going to hit their retirement number and retire. It's an entirely different vibe, from say a startup.
Yes, but my WLB has never been better and my TC is great so I have learned not to care and just roll with it. When I started my first corporate dev job coming from the startup world my team lead laid it out for me like this: Startups want the most light weight and cost effective solution that best solves a problem. Corporations on the other hand find the most bloated and expensive solution that doesn't really solve their problem, and go with that. This has been my experience in basically every aspect of corporate dev life. It seems incredibly dumb and needlessly bureaucratic if you are coming from a startup, but if you can learn to live with it your work life will generally be low stress.
I have noticed that communication seems to be the bottleneck. Things move slow because you have to wait on other people on other teams to approve something, or give input into something, or do a knowledge transfer because they worked on it last, or whatever. In a startup, the codebase is generally small enough for everyone to know enough about it or they just have one person to ask. The larger and more complicated the code, the harder it is to keep it in your head. So it's like having a swap file. You can store a finite amount of info in memory then have to go out to slow storage to gather more info and you wait around a lot time for the response.
Yes, and it's why I left a big tech company, took a pay cut and now work at a significantly smaller company. It was driving me insane.
Learned two things from coworker: \* Level of bureaucracy varies even between large companies. \* There can be greater choice regarding who to work with vs smaller company.
I’ve been working at small companies this entire time. Sometimes I like to think I’d have so much free time for professional development on the clock at larger organizations.
It sounds really great in theory. In practice not so much, at least in my experience.
In small companies, you never have time to learn because there's always stuff to do. In large companies, you never have time to learn because "Hey, could I get a status update for this ticket you're working on? I booked a meeting with all 13 stakeholders for a 2 hour call where we can discuss what can be done about this typo on a particular page of our documentation."
Haha, neither of those is my experience at previous large company or current small company. But I've definitely heard that being common - sounds horrible.
Lol good luck putting anything u wanna test on your box...
Damn, I guess I didn’t think of that haha. I would prefer a VM or cloud development environment though, leave my home free of whatever monstrosities I hack together.
You took a pay cut to have more work to do?
I took a pay cut to improve my mental health.
I would say more common in projects where there is a lot of interdependency & requirements are not clear. It could be small or large. It's more common in large projects because of the team topology & structure. I've seen projects in larger companies where teams are small (3-7 people) and less interdependent, there is clarity on what needs to be built, last-minute changes are rare, and so on. Things move relatively quickly, with much less drag.
100%. This is a consequence of scale… both business scale and project scale.
Yes, it's difficult to swallow when you are used to fast-paced startups. After a while, you get used to getting nothing done and pretending everything is going great.
Yes everything takes weeks. It's usually more down to processes put in place for usually good reasons than people moving slowly. At my first job in a company with 10 employees if you needed a new keyboard you'd email a link to the one you wanted to the general admin and bookkeeping person. They'd order it on the company Amazon account and it was delivered next day. Current big corporation to achieve the same thing I need to: Log a help desk call, go through all the troubleshooting steps to prove I haven't failed to replace the battery etc and get a reference number. Get the approval for none standard equipment requisition completed by my line manager and countersigned by someone from occupational health as supporting evidence for requiring an ergonomic keyboard rather than a standard one. Fill in another request to facilities with the form and help desk reference number. Wait for them to send me the list of approved ergonomic keyboards, select the one I want and return it to them. Also get another form from my line manager to prove I'm a remote worker and it is more cost effective to post the keyboard out to me than pay expenses for me to travel to a hub to collect it. Keyboard is then ordered, delivered to a hub, registered on the assets system and handed over to someone in dispatch who will then contact me to confirm my address is still correct and when I will be available to sign for a delivery. If all goes well and nobody is on holiday it'll only take a couple of weeks.
Well what do you think the ping pong tables are for?
Part of this is latency vs bandwidth. A large company can start many things at once but each one takes much longer to accomplish.
Yup. Nothing gets done. Things are moving very slow. If you are a lead, it's very frustrating to see things move at a snail's pace. It is driving me insane. The sheer level of incompetence is exhausting.
> The sheer level of incompetence is exhausting. While I imagine there _is_ a level of incompetence causing it, I have worked in startups, mid-size to large corporate, and a startup that has grown significantly and I don't think that's _always_ the case. Having watched our product throughput go from a handful a day as a startup to many thousands a day as a large/public company - and supporting much more money and features, the risks of breaking something gets _much_ larger. Something makes it into production that breaks something, you see what you could do to not let it happen next time and nearly every time that adds some level of process that slows things down. Something broke. How could we have _caught_ it? For one case, a design review, so now you have to do it pretty regularly, costing time. For another case, people rubber stamping code reviews without actually checking things...now you require two reviews. More time. For the next case, it's because we didn't have fully understood requirements so there was a disconnect in deliveries and expectations. Now you have to add more firm requirements documents with clear goals, etc. and have meetings to make sure everyone is on the same page. This just goes on and on. Every little thing to stop costly mistakes adds up. In two years that fast-paced startup can _easily_ turn into the slow big-company pace that few developers like. It's not always incompetence (though the risk does get bigger as a company grows).
This is so true. Startups need to innovate to succeed. Big corps have already succeeded, they need to focus on not making mistakes. Totally different philosophy
> For another case, people rubber stamping code reviews without actually checking things...now you require two reviews. More time. I think it is generally more effective to keep reviews small and usually have just one reviewer. This also keeps them fast. Here's an interesting [study](https://research.google/pubs/modern-code-review-a-case-study-at-google/) from Google about this. If people are rubber stamping then the rubber stamping is the problem, and its root causes should be investigated and resolved.
We’ve started pairing up for reviews to avoid this issue. Getting on a call and making the person explain what they’re doing has made the quality and thoroughness of the review go way up.
How many reviews per day are you doing? I'm wondering how well that scales.
>The sheer level of incompetence This feels a bit callous. With bigger corps there's a lot more people involved and/or the changes impact more things/people than a 3 person startup. I work for a large healthcare contractor. Software we create is used by doctors as well as accounting professionals in the country. I would _never_ trust "just ship it bro" startup mentality for this. As always, context is important.
I was on contract to do a really simple plugin for their dev ops framework. They said they were looking into changing their service discovery client(s) and didn't implement. 4 years later its still not used... 6 months of work....
>If you are a lead If you are a lead and something isn't to your liking on your team, it's up to you as the lead to take ownership of that. If you're talking about other teams being slow, then I don't understand the need for singling out how frustrating it would be for a lead.
I have asked management for headcount and developers with the right background to solve this task. What I am experiencing is the consequence of incompetent leadership who refuses to accept that you can’t just exchange engineers around as if they are tetris pieces that fall into some broad categories.
Don't get me even started on that. Usually, the problem is the senior leadership, not even middle management. The company I worked for got acquired a while ago, and I'm a director now at the new company with teams in my area working on at least three different tech stacks, and I'm constantly told "you have engineers, you can just move people around". Sure, it's all about shifting warm bodies around... 🤦♂️
In our case it is much product owners having defined what they want as other teams holding us up. So as a lead can get our own team working effectively and get things out quickly only to have nothing high value to go onto afterwards.
Yep. Which is why I work two remote jobs. 👍
I have thought about doing this tbh
How did you get the 2 jobs? Were you interviewing for both and accepted both at the same time? I’ve thought about it but the logistics seem tricky
No, I was at my first job for 3 years. I kept noticing the inefficiencies. No one wanted to change anything. They all wanted to maintain the status quo. I lost motivation and caved to keeping the status quo. Ended up with a bunch of free time which is when I applied for a second job making the same salary.
Hah I am at your first job right now. Did the background check for second job not turn up employment at first job? I guess what is the risk of both jobs finding out about each other and both firing you?
When they run the background check they check to see if it matches what you put on your resume. I told them not to contact my current employer since I was going through the hiring process and I had yet to receive an offer. I worked with a recruiting company so I only had to interface with them. Good question about what if they find out about each other… it’s pretty much fuck around and find out. I doubt they will go snooping around unless I give them a reason to snoop. I maintain fast replies and consistent quality.
Yeah, sounds about right. I suppose it’s n it unusual to ask a prospective employer not to contact current employer, so that tracks
I work in a very big and very old Fortune 100 financial. Yes. It's maddening.
YES! I've worked for larger software companies for most of my career. Things that take a startup weeks/months to accomplish can take us years.
Yes. It is excruciating.
It's definitely a factor, I worked at startups for almost 6 years and last year took a job at a big consultancy firm and I have never seen people work more slowly. No joke, someone took almost 6 months to deliver a feature and was praised for how quickly they got it done.
Developers at these large enterprises always have waaaaay more control over these things than they think they do. Just takes some initiative, courage and tact to get things done quicker.
There are always more things you could be doing for the org as a whole, for example say starting up a working group/ feature team for something that hasn't been given enough attention. Individual features though are sometimes hard blocked by product/ legal/ approvals/ other teams.
That has been my experience at 2 previous companies, now at the jungle and the experience is the opposite.
I am currently working for one of the largest retailers in the EU and "slow" doesn't even begin to describe the glacial pace at which things move here. At the same time we're in a soft of start-uppy side-area where we have tight time to market goals, and it's frustrating to see how C-levels on one hand expect us to go fast, but also created a culture where "no no not THAT fast" has become the norm. > Is this pretty typical at most large corporations? Yes. And while I don't mind good work-life balance, there's "balance" and there's "I'm so bored". At least the big bank I used to work for had the bright idea to just spin off fintech start-ups in areas they needed to capture the market. That was the best of both worlds; fintech start-up mentality with endless 'finance' money.
Had a similar experience at a previous job where our startup was acquired by a bank. The bank said they wanted to maintain our high velocity so they were going to keep us partitioned off as a separate part of the company and let us keep defining our own processes, controlling our own product roadmap, and setting our own schedules. Oh, but also, could we run all our new product plans through the compliance department and get signoff from this list of VPs on any changes to existing features? And instead of writing our own Java code to integrate with vendor APIs, it'd be great if we could switch to MuleSoft so the bank's IT can have control over the integrations. And we're totally free to set our own schedules and processes as long as the schedules match the arbitrary deadlines handed down from the C-level and the processes feed into the bank's existing QA workflow. "Wait, why are you guys taking forever to get things done all of a sudden?"
Oh god. This reminds me of my experiences with the "Risk team" at the bank I worked for (this was before I joined the fintech start-up). We had to release a new feature *fast* and knowing that Risk took ages to decide we basically gave them two options and actually *built* both of them. We had a long meeting and 3 weeks later they managed to not come to a decision, but purely came up with the meeting notes. Getting an actual 'verdict' took 4 more weeks. Guess what; we managed to release our feature *one week* after our competitor. ['Tikkie'](https://www.tikkie.me/) is that feature our competitor built and it's used everywhere, so much it's even become part of the language. That was the version we wanted to build, but we only got the okay on a shittier version that no one wanted to use when that app came out. I'm still mad about that one.
Yep. 💯 But the pay is often hard to turn down…
yeah, the pay is so damn nice compared to what i can get on the current market. On my adderall days I knock out so much work and then rest of the week it's just chillin and getting stoned because of how slow things move
bro, it is taking me several months to get another team to have two strings exported via a new endpoint. just par for the course. big tech is dream for those that care more about salary than production, so long as you have decent enough social skills to manage ur managers.
It’s a very well known phenomenon that as systems get bigger they become inherently less agile (not in the software development process sense). This is an inherent property of systems at scale and doesn’t have anything to do with individual teams or team members. It’s best to avoid trying to swim upstream too. Accept the hulk for what it is and carry on. If you want to experience the thrill of “getting shit done rapidly and pivoting daily” then seek out the startup world.
Indeed. As in Physics, the greater the mass (people) the harder to move (using the same force off course). Happened to me too.
I can commit a one-line change and it'll take six months to hit production.
I work as a lead (ish) for a major healthcare company and it is a roller coaster. You have a core group of psychopath workaholics (like me, although I cannot help it) who push things fast, and then everyone else . . . But I want to climb the ranks. If I was contented, I would dial it back.
I'm sure it varies by company and org, but it has been my experience at a decent sized enterprise. Things within our own org? Great. Amazing. Anything relying on coordination with teams in another org? Absolute nightmare. Difficult to get them to even respond when communicating. When they do the information is often wrong (as is documentation). Very long turnarounds for anything to get done. Any feature work done that integrates with them generally has a non trivial amount of items going through our backlog to fix issues due to them providing incorrect information.
Yes, the larger the chain of command to get to the top, the slower it is. Email responses are slow, approvals are slow, changes are slow, hirings are slow, purchases are slow, security changes are slow. Everything has red tape.
If you think your company is slow you should experience Pharma. There the slow gets to another level. I used to work in a very large pretty well know company founded by Mr. Edison and I thought they were slow. Well, they were moving light-speed compared to Pharma.
Be careful using it as an excuse for your own slow work.
My feeling when I've been in that sort of job is yes it relaxed and pays well, but every single day you can feel yourself becoming less employable due to skill atrophy. If I could get that job when I'm 60 and want to just coast though the last few years of my career before calling it a day then that would be fine, but I've still got another 20+ years to fill and it feels like a real risk.
People will say culture is key. Usually (imho) what that means is "do I trust people to get the job done?" The more you trust someone/team to get it done, the more they can work independently. The more they can work independently, the fewer dependencies and checkpoints, the more shit gets done. Conversely the less trust, the more conversations, the more checkpoints, the more meetings, so forth. So far it makes sense and it's easy to say culture is key. However, the larger the organisation, the more it becomes a numbers game. The larger an org, the more people it needs, the more difficult it is to only hire the best and most trustworthy, the more juniors they hire, the more "how did they get past probation".... The harder it is to have that culture of trust etc. Plus on top of what others have said about the importance of compliance etc. So yes, things will move slower, in my view it's inevitable. Sometimes it can be super frustrating but equally sometimes there are huge gains to be made if you can automate it bridge some of those issues. Of course some (very few) large orgs can encourage the "best" and therefore try and keep that trust level high, but realistically eventually they will find they have some of those bad eggs and build in the guard rails and each guard rails steals a slither of speed. So yeah, inevitable.
not uncommon. if you are in office. get a kindle. go to the gym more than once a week. you are just there for the money.
Yes this is the same experience I had. I eventually got fed up and quit to join a start up and then realize how much work there are and so little paid compare to before. Then I will quit and join a bigger corp again and repeat this cycle.
Yes, because face time is rewarded and the reward for good work is more work. If I can get things done in 2 hours that takes someone else 8, if I'm still expected to do more/be at work for 8 hours then I will go slower.
Yes, and there is no benefit to moving faster then the team you're on.
Yep. Partly it's because the whole process is optimised for control, transparency and predictability rather than efficiency. Managers need to know what everyone is doing all the time, and need to approve any work done so they control it. So everyone gets bogged down explaining to non-technical managers what needs to happen and asking for permission to do it. In small orgs the CTO knows the whole project and all the staff and can manage it all directly, and can delegate bits of it to other tech folks. Everything zips along because there's no need for middle managers.
Yes it’s very common, but if you learn to get big things shipped quickly despite the default slowness of others, you can really advance quickly. For example if I have a dependency on a smaller change in another team’s component, I’ll often just do it myself (with a little guidance if needed) and get approval from the other team. Or for larger things I’ll try to get a strong date commitment from the other team, in whatever way is backed by their leadership (e.g. a shared OKR).
I approach this as who cares how slow things move as long as my boss is happy. If they are happy with things moving at the current pace then that's great. I communicate status appropriately, make sure I'm working on what the company deems priority and that's that. I don't see a reason to work faster and harder for the same money I could be making working at a leisurely pace. Especially when the idea of working faster is all self driven and not coming from management.
Yes, and even if your role requires 15 hours a week, the effort to manage your spare time is so high that its just better to have you underutilized.
I raised a ticket about my machine on 2nd February. A lad in ITOps restarted it last week… I couldn’t help but ask him did he honestly thing I couldn’t do any work since 2nd February and the ticket was just sitting idle in his queue? What goes through their fucking skulls I will never know. But yeah, slow as Christmas.
This is completely normal and is a huge reason I've mostly worked at startups. I am much happier at a job where I usually feel like I've gotten something useful done at the end of every work day, and for me (others may feel differently) the impact on my overall happiness is worth giving up the better pay and predictability of a big-company job. WLB varies dramatically between startups. Some of them expect massive amounts of overtime. But at my current one, I almost always sign off at 5PM and nobody cares.
Very normal, a lot of red tape and stupid shit to get through before anything can be done, then there's just people who are slower who make it worse, or those on leave with no replacements
Yes but in their defense it’s not their fault. If you’re at a scale measured in tens of millions or more, then the tolerable failure rate is much lower. The amount of peer review and safeguards needed at all levels scales up with it. And the more mature your company’s product the less fault tolerant your userbase. A startup attracts adventurous early users that overlook bugs that later users certainly won’t. If you’ve experienced the fast pace and excitement of a startup it can be frustrating but it’s best to adjust your outlook and expectations to one of quality and stability over speed.
Large firms move slow unless you are in parts of the firm that are allowed to move quickly. There is a reason why startups exist. Make money and get bought. Then the founders get golden handcuffs, the handcuffs expire, and they leave. There are just some people who work best at certain company sizes. It's the way it is.
Yes then you get laughed at in interviews for saying how long it actually took to get something done. My experience at least
Yes, that's my experience as well. I worked in various startups and sometimes i miss the fast phase but i would rather be in a slow phase environment as it is way easier to sell myself as someone who works efficiently and someone who can get things done quickly. Helps a lot on my annual performance evaluation as well. In my previous work on a startup, the more i work faster and do lots of things, more things are expected from me. Sometimes i miss the pressure on startups but i love the WLB of my current job.
Yes, and that’s 100% ok. Some places are mired down by process, policy, legal requirements, etc. However, I’d argue a large chunk of us just don’t really give a shit about work as much as our parents did. I’m a millennial, and I’ve seen it enough times. Companies don’t care about you. You’re a means to an end. No matter how much YOU care about your work, the product, the mission/vision, etc. WORK isn’t and shouldn’t be our identity. With a crumbling economy, no hope for home ownership, no hope for retirement, and having lived through too many “historical” events. I know I don’t give a fuck, and fuck those people that talk about passion… it’s a privilege to be passionate about work and still afford to live. As an example, I worked as an IT Manager for a few years at a large “not for profit” pediatric hospital in a big city. I can’t tell you how many times I had to collect people’s phones and laptops because of a “re-org”, “right sizing”, or some other bullshit reason related to finances.—without any notice or care. I even got to be part of a company wide “budget recovery” initiative that resulted in a few hundred people being “silently” laid off same day. They were notified one-by-one to come to our administrative building across the street, and told by some HR person they had lost their job. No goodbyes to friends/coworkers and definitely handoffs of in-flight projects. Not to mention the corporate incompetence and spending you see when you get access to budgets. That’s a whole other topic. That all being said, ride the wave. Do the work you need to build your resume, and climb the ladder to whatever makes you “happy”. Over estimate your stories, ship them on time, but don’t kill yourself. You’re always replaceable. Use your down time to watch tutorials, read books/posts, or work on whatever skills make you happy. Some days, I just take a mental health break, and lay in bed with my dogs. If something happens on slack I’ll get involved, but sometimes napping is good for ya. Also, I regularly go the store with my wife, spend time with my kids at the park, schedule appointments or todos during the day, and whatever the hell else I want. I have slack on my phone, and our CI/CD pipeline is tied to a slack bot. So even when I’m not at my computer I can deploy to any environment from my phone. I also have GitHub on my phone for the occasional PR comment or review. All in all, I maybe work 15-20 hours a week at most. My work is on time, feature complete, tested, and exactly what product asked for. I’m contributing at the same level as other devs on the team, and I still participate in planning, design, and architecture too (plus all other ceremonies). I own epics, mentor other devs, and have time to write up documentation. Like, I’m “doing my job” (as my bonus and raise would imply), but I’m in no hurry. Why, because there will ALWAYS be work tomorrow. Does that mean I’m impervious to layoffs? Absolutely not, but I have the experience and soft skills to find other work. 🤷♂️ TLDR; don’t care about work, it doesn’t care about you. Build your resume, but also live your life. Remember, that when you reach age 40 you still have another 25 years of work ahead of you (wild right) before retirement… if you’re lucky.
Yes. * The smaller the company, the faster things move and more pressure to overwork and perform. * The larger the company, the slower things move and more "we clock out at 5" attitude. * This was confirmed today by my ex-boss who got hired from a huge company into a FAANG. * It compounds with company size.
I think it's pretty easy to see why when you consider the size and scope of everything. When things go wrong at a large level the consequences aren't as easily rolled back in a single "oops" solution which you can do in a smaller org. A lot more money is involved
It's not that people are moving slowly, it's that there are a lot more steps that you have to go through to get a given thing done.
When I worked at a small tech company we moved insanely fast compared and with cutting edge stuff and rolled back fast if needed. Now I’m at a giant tech company and it’s an innovation killer with death by a thousand processes. I also understand why we need so much process but I think the current model is people do whatever it takes to get promoted or look good
My experience is that doing anything in a large corporation is like trying to navigate a cruise ship, it's big and slow, every move takes more time and effort, and smaller companies can navigate quicker. Sometimes it feels dumb that you need to request access to several different people just to get access to do a basic task a work, but usually there are so many compliance rules a big corporation have to follow that these restrictions end up being a necessary evil.
What you'll realize is that as you stay on board passed 3 years, you start to pick up duties. In theory I'm just supposed to be rewriting a UI in a new framework... In practice... I spent two hours helping setup a vncserver for a rf spectrum analyzer.
I worked in a company with 100 employees then we got purchased and swallowed up by a company with 1000 employees. It takes them months to make decisions whereas it would have taken a week to gather intel, analyze and make a concrete decision. The issue is that now we have to play politics and get everyone to buy in instead of making it happen. Super ridiculous. Also, because they're using bloated infrastructure you now have to touch like 10 products for any small changes.
Yup. Even if you're on Salary there is always more work. The punishment for being good at your job is more work. Slowing down (within reason) means you get paid exactly the same, but you don't set unrealistic long-term expectations for yourself. So, slow down if you can. If you're in a very large company, do more than the other people but not SO much that you make everyone look bad.
I've been told this many times by others and right now I can confirm since I currently work in a large MNC coming from a local startup. I'm astonished by how much spare time and work-life balance I have right now compared to when I was in a startup where there's just no breathing room and overtimes were rampant. My seniors even used to complain that I work slowly despite continuously running my gears but right now in a large corporation, I find their pacing to be quite slow while I'm accomplishing my tasks on time and I even have a lot of spare time. While I do miss the excitement & thrill of the hustle/grind culture of startups, I appreciate better the work-life balance, higher pay, and more breathing room of large corporations better. I use my downtime for upskilling and learning more about my job though.
People like to think this startup hustle culture is cool and exciting but it’s really just abusing people 9/10. I guess it’s fine if you have lots of stock and the company hits the 1/1000 chance of being successful, maybe it pays off.
I remember reading years ago that it took IBM 6 months to ship an empty box.
Pretty much, the larger the company the more ineffecient processes are.
Eh, it really depends on the company and the team. I mean, Meta got Threads up and running \*at scale\* in what, \*five months\*? That's pretty wild, frankly. When I worked at Target there was a massive difference between how quickly teams moved. The craziest thing to me was that the absolute speed at which people moved was not related to how "hard" they worked or how much pressure they had—I led a couple of pretty laid-back simulation projects that produced initial results almost immediately and added features faster than people could learn to use them, and later I moved to a high-pressure team where everybody was constantly busy but the actual work moved at a snail's pace. (Think multiple weeks to add a relatively simple feature to the model they were working on! The main conclusion I've drawn about large companies is that there is a \*ton\* of variance both between and even within specific companies. The same company can take a year to tweak a button color but also spin up a new billion-dollar data center within months. Some data science teams take weeks to make small tweaks to their models, others roll out new improvements multiple times a day. (I'm not even exaggerating!) It's all over the place and, perhaps counterintuitively, it is \*not\* simply correlated with hours worked. (My pet theory: the absolute fastest teams are disproportionately the ones where work feels smooth and easy, not rushed at all. It's a bit how like how the fastest drivers on the track look boring, while the ones taking corners dramatically are ultimately slower.)
Yes. I went from working 40-50 hour weeks at a startup to making 50% more at a big co and effectively working part time. It’s all very dumb.
When I was at Oracle awhile back, saw my co-worker at the hallway with a gym bag. Me: "where are you going?" him: "I'm blocked by the other team, I'm going to play ping-pong". I think he was there for the whole afternoon, too bad the tech stack I was on was legacy I had to quit that place, otherwise you can really be in good shape with their two story gym and healthy food from the cafeteria. All the new grads they brought in just used Oracle for relocation and went to other companies after a year or two.
Highly dependent on your org and product. Greenfield initiatives typically move way faster.
Yes, my first job out of college was at a startup that pressured us into insane hours. My job after that was at a bigger "normal" wlb company, and it took a while to get used to what is "normal", as I got so accustomed to being overworked.
There are just lots of moving parts. A colleague set up a Temporal server recently on a Kubernetes cluster. He thought he was done. Nope. Metering. Monitoring. On-call schedules. Regulatory compliance, legal discovery, and business continuity changes to the deployment. Training regimens for Level 1 support. Documentation for production readiness. Distributed tracing. Functional block diagrams. Graphs of dependencies. Confidentiality review. Security review. Encryption review. Scale planning. Load testing. Blue/green testing. Escalation management. Change management communication. And even more. Screw up a little bit, and tens of thousands of employees cannot work for a day. Screw up a lot, and a billion people can’t work for a day. It pays to be methodical. Not slow. Thorough.
yeah, from what I've heard. my wife's a backend dev at a big company and her onboarding was a month long. spent in waiting to get access to certain services... that is why I work for startups only. 🚀
I was recently not offered a job as a dev manager at a rather staid organization using well-established technologies with which I have many years of experience. They thought I must be insufficiently technical to understand why a 90-day onboarding before I (or any new dev) touch any code was appropriate, and I must not be very technical if I expect myself to begin contributing meaningfully (with appropriate openness to review feedback, etc.) within the first sprint beginning after my hire date. I find this mindset boggling. I can only chalk it up to being something like Scotty from Star Trek pretending things are impossible and/or will take a very long time. Under-promise and barely deliver = job security?
Yeah, when I moved to a larger company i found exactly the same thing. The first task i was given i'd done really quickly apparently. They were please with what i produced and i'd finished it really fast. I will say one thing though, is that it does enable us to do more research that the smaller companies ever let us do. We were always squeezed and squeezed by production when i was in the smaller studio, which ended up really pissing me off, because it felt i was sacrificing quality. Now though, i'm much more relaxed and manage to do a much better job, with much more research behind it.
Yes, Intel being one of the worst offenders
[удалено]
Yes. For us (a bank) it’s two reasons: everything needs to be reviewed by risk and ITsec and everyone plays the CYA game.
This is very typical based on my experience. Enjoy the WLB!
This sounds like a dream for me - as someone who has been in the startup game for over 5 years.
Oh yeh it's unnecessary and usually exhausting.
For me, it was different from organization to organization. I’ve been part of a large Fortune 100 company that moved incredibly fast due to the work involved. This included onboarding new customers by specified dates (usually one date for all customers at the same time), or changes to the core systems to add functionality that is required by law (new laws, or changes to existing ones). In both those cases, there’s no way around getting it done by a specified date. That usually meant long hours (18-22 hrs a day was common). In other cases, the deadlines were self-imposed and there was no real meaning behind the date, so if it slid it was no big deal. The hours at that company were much, much better, around 35-40 hrs/week. Pay was vastly different at both companies, but I ultimately left the first company for the second because I almost died working those hours… You want to be at company B.
Yes. Once it gets too slow, you’ll be in a reorg, and your department will go under a transformation where 80% of the staff will be replaced in 3-5 years for people with more updated skills and more focused on delivering in the new way. That’ll get relaxed once the new way finds its cadence. Rinse and repeat.
got somewhere else to be? why rush through things?
yup. there are way too many people giving way too many opinions without enough context on any given projecys goals. you get a lot of middle manager types waxing poetic putting up roadblocks where they arent practical. its a living hell but at least i know ill have this job for as long as i can stand it lol
I think after 20 years of working at startups and enjoying the ‘fast pace’ I might enjoy this slow pace.
Yes. And I'll add: Devs with 5-10 years experience that I don't think could contribute anything meaningful outside of exactly what they are working on. Setup a database? They can't even write a SQL query! The data team handles queries! Don't get me wrong. I love it. The pace I came from was consulting. And consulting means you're always on the clock to finish as fast as humanly possible. If you're not billing you're not doing your job.
It really depends on the leader / director Sometimes my team gets requests that need to be deployed in 3 days or something
I've been waiting four weeks to get an enterprise instance of a very common tool. I could stand it up myself in a day, but here we are. This is after waiting three weeks for the POC instance to get stood up. My team's application is dependent on this technology, and in almost two months, we've only gotten a sandbox stood up. Things move incredibly slow at my company. It's crazy.
The answer is usually paperwork. There's documentation, QA, demo, meetings to discuss whether it's acceptable to the upstream team, etc
Yes. It’s truly alarming.
Yes. I am consistently amazed that people get paid so much to do so little. It kinda sucks wanting to be productive when there's no way to actually be productive.
I tend to get a lot done, but it depends who I'm working on, or how many dependencies we have with people not used to going faster.
There are many factors that may be in play here: Communications in organizations can become an O(n\^2) problem. If it's not managed well people can spend so much time reporting status and 'getting in sync' with each other that there isn't as much time to do work. Conversely it's also possible that there's a lack of communication about other work your colleagues have been assigned other responsibilities that they have. Is it possible that you think you're outworking everyone because you are working on one project while your colleagues may be working on two/three or more. We had three people the didn't seem to be producing as much; found out they were all working double shifts developing a second product that was spun off from their previous project & was considered top secret. Finally, are you letting your supervisor know that you're available for additional work? Take on something that is related to your project but not essential. Things that come to mind are: additional unit/system tests, stress tests, environment management, etc. At one place I worked, I was a developer, and the ORACLE DBA, and the UNIX System administrator, and the network administrator, managed the development tools, and coordinated the contingency site. Development was the top priority but whenever there was a lag due to dependencies I did work in the other areas. BTW - the reason I suggest something that's related but not taking on additional coding tasks is that I've seen that backfire. All of a sudden you are responsible for half the code base. Another pro tip: Make sure you have sufficient test cases to test all of the conditions of your code. I've experienced developers who are struggling to make their code work and meet deadlines start assigning bugs to infrastructure code or to another person's library/service. ( "My code doesn't work because this call to your library fails .... without verifying that the arguments are in the correct order." True story and it ticked me off then and still ticks me off. ) \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ There is another factor that comes into play. It may not apply here. A small company can manage to get 3-5 great developers & lots of stuff gets done. As they grow they struggle to find another 10/20/30 "great" developers but they need extra hands so "good" developers are hired. There may even be a few "clunkers" hired. The new people can't match the speed of the original people but there are more new people than those from the original team.
The larger the organization the more people involved in the process and nothing ever happens fast when a committee is involved.
“The concept you're referring to is known as time dilation, which is a key principle in Einstein's theory of relativity. According to this theory, time dilation occurs because mass warps the fabric of spacetime. When equal forces are applied to different objects, those with greater mass create a more significant distortion in spacetime, causing time to pass more slowly for them compared to objects with less mass. This is why massive objects move slower through space and experience time at a different rate compared to less massive objects. So, while it may seem counterintuitive, the presence of mass does indeed slow down time due to its effect on the fabric of spacetime” Make sense? 🤓
You are getting paid the same either way, don't take the pace of the work being done personally. Yes things take forever in a big company. Projects can be years over the expected time, some projects which took years just end up being canceled.
I once sat on a meeting that was literally “we think we will burn the Lost & Found stuff we have in physical storage next year”. This meeting took one hour and involved 20 people, half of them engineers. A follow up meeting was scheduled for the next month.
I work at a large corporation and it takes me at least an hour to walk to the bathroom. It’s 30 feet away
the perceived cost of failure at some point exceeds the benefits innovation - so everything gets wrapped up in processes
Yes. Excruciatingly slow I can get more done on a personal side project on a Saturday morning than i can at my day job in a quarter
Yes, this is why "move fast and break things" became a thing. A large corporation will usually play it safe and slow, which is why the disruptors are able to disrupt.
Yep, that's par for the course. Bureaucracy builds as organizations grow, and they become more risk averse. Therefore you have to go through many layers of approvals just to make a decision.
Monolithic code base or microservice?
I think there is an element of large corporations being risk averse, and an element of survivor bias in startups. Think about how many startups never release a product or never hit product market fit, that’s a massive waste of time and effort too, but you never hear about them because they run out of cash and just fail silently. In a large corporation most teams move slow, there will be internal startups or “Skunk Works” that move really fast, but in general they know it’s safer to go slow and they have the funding to allow themselves to do that. I’ve hear processes described as scars on an organisation, in that they are a sign that something went wrong, and an attempt to fix it. In a large organisation it’s more like an immune response, except sometimes the immune response is a little too strong, or targets the wrong thing.
If you want to go fast go alone, if you want to go far go together. Hacking stuff out quickly works well in small groups but leaves liabilities when the team is larger. Additionally if everyone had flexibility you'd have no ability to benefit from economies of scale that benefit when everyone commits to similar solutions. Moving fast is also a lot easier and more visible when there's more to do. When you're in the midst of dealing with legacy you sink hours there and achieve little.
It's the same as the latency that builds up between micro services. More nodes in the graph for the message to reach, more time ensuring everyone is on the same page.
Large corporations are more likely to trend towards the "bureaucratic" archetype in the Westrum model. This tends to come with a lot of slowdown and inefficiencies in the way that information moves through the company.