I Needed to Rewire My Brain at the First Year at Big Tech

Disclaimer: All views here are my own.

I started working at Big Tech Company as a Software engineer. And to my surprise, rules of small or medium tech companies, does not apply here.

All my career, everyone kept telling me to take the ownership of your work. Know your product end-to-end. The key to the success is — creating dependency among the team and outside. Try to get involve throughout the product creation.

But as soon as I started working at big tech, that was no longer true. The Engineering teams were so vast, it’s not only infeasible but also stupid to take ownership of anything beyond task in hand. In the companies I worked before, I used to read the code, develop an understanding and then started to work on task. This way, I would know what and how my changes impact the system.

When I joined the company, I was immediately put to work. Don’t get me wrong, there were few onboarding sessions. But there was no time to waste, or we call it honeymoon period. I was given my first task at the first week here, I was hesitant to start, as I don’t have much understanding of the code, I don’t know the end-to-end flow. I insisted to my manager, that I need more time. I am not ready. But I later realized it was not a great first ask from the manager. I saw that the repo I was asked to commit the code, and it had 200k+ files. If I start understanding 10 files a day, it will take me 50+ years to understand the code end-to-end. So, I reluctantly, going against my first intuition started with the tasks.

1. Get High level architecture understanding of service and code.
2. Decided where my changes will go.
3. Write the code and tests.
4. and Commit.
5. Phew!
6. Repeat.

And it’s been now almost a year and a half, that’s how I go about it. The projects I work on changes quarterly, so I never get time to do a deep dive, the above steps are way to go and be.

But my habits were hard to get rid of, soon later I was assigned a high priority feature, which spanned across 10 teams. I started taking very seriously, I was like — “Our VP needs this feature completed, let me understand fully the feature end to end and I will see where I can help unblock.” Everything was going great until there was a big issue with the approach I had in mind.

Project manager: “This is a big issue; we need to resolve this urgently. How long will it take to fix this?”

Me: “Umm... I will try my best. I will work for day and night. And deliver in two days.”

I tried to wrap-up in two days and bang I delivered. But Surprise! Suprise! soon later, we had a failure in some other downstream service.

Project manager: “This is a big issue; we need to resolve this urgently. How long will it take to fix this?”

Downstream service Team: “We have plenty going on our side. It will take 2–3 weeks.”

~One week later~

Project manager: “I am going on a vacation. You guys take care of this.”

Me: “What? Wasn’t this an important ask, Arnt you the point of contact for all the team? How can we make progress without you? Isn’t this the most important feature.”

Project manager: “You guys will be fine without me.”

We struggled at first, but somehow, we managed to join the pieces of the puzzle. He was right, we will be fine. We delivered the functionality without him. My manager said, “if you would have delivered your piece in a week, it would have been fine. Don’t be so hard on yourself.”

With the project this vast, there is no dependency on anyone. Its great if you stretch, but a couple of extra days to land a functionality does not make much difference. You care about your skilling-up and maintain high standards for engineering work that assigned to you and that’s it. Everything else, is external; is taken cared by someone else.

Project Manager/ Lead: responsible for completed the features, identifying the blockers and resolving them.

Product Manager: responsible for talking to customers and engineers, taking requirements and negotiating the deadlines.

Various teams’ Engineers: Responsible for their services and expertise, delivering the functionality on their end.

Leaders: Setting up the priorities and providing resources and escalation if needed.

Everyone in the hierarchy works perfectly like a Symphony. If someone not able to complete a work, someone else will be assigned. If something needs urgently than more resources or more senior engineer will be assigned.

The vastness extends to the risk management as well. Once I made seemingly innocuous change in addition to my code changes. I was like “That code is never going to hit, lets remove it.” And I hit commit and sent for PR review. The principal engineer declined my PR and asked to remove that line. The reason he gave me was that it was Friday evening, and they are not ready to waste their weekend for a change that doesn't even ask from anyone. I was not satisfied, with the explanation but I reluctantly reverted the change. The code clearly wasn’t getting hit. Can’t a principal engineer see that!

But sooner I understood the vastness of the system during my on-call, when I received a sev2 call on which I spent a week to know the root cause. The funny part was no service was deployed from our side in last two weeks, then what was causing the failures? The answers were in deep inside the downstream system. A release there surfaced some of the vulnerabilities in our code. And at that very moment, I understood the reason why the principal engineer was reluctant to add my changes. My lesson I learned: We don’t know what impact something will have, so unless you can do a proper testing end to end, you don’t commit anything to prod even however small and seemingly local and innocuous that change appears.

These incidents made me shifted my way of working, learning as well as collaboration. The actual tech in the big companies is maybe same than the medium or small enterprises, but the mindset is very different. Here, you see the power of human organization for real. How thousands of people come together and deliver the marvel of technology. I have seen teams giving their baby project to some other team, because it was the right thing to do for the project. I have seen biggest leaders saying “I don’t know” in the meetings, because that’s the answer. The ego does not matter. What matters is what you built. Just Move the Needle!

Thank you for stopping by.