To be frank, working in an engineering organization at the premier corporate level is completely different than what you’ll experience elsewhere. It can get even more daunting when you’re doing so in the most tech-centric area in the world, maybe even in history, Silicon Valley. Which in truth makes a lot of sense.
Engineering at this level successfully requires more than just being competent. It alters the way you think about programming and logic. Making it difficult to adjust to life after. Luckily though there are some ways to tackle this before making an exit. Today, we’re looking at what needs addressing first. Your mindset.
Corporate Engineering Environment
In these codebases, you’ll always find some bloated mix of legacy code critical to business, patches of greenfield architecture that either is slowly being pushed or deprecated, approval committees for any new technologies and test coverage needs to be between 75% to 80%. That’s the most common environment, and that’s really just the top of the iceberg! The biggest influences on this codebase environment are the large-scale collaboration and red tape.
Large Scale Collaboration
Collaboration isn’t just a buzzword in these engineering environments. You’re a member of a scrum team(typically <= 10), that’s usually a part of a larger sub-group. That sub-group is then a part of an even larger slice of the greater engineering org you’re a part of. Lastly, that same slice rolls up into the overall Engineering organization at your company. On average, you can expect to be one of 1,000(s) of engineers.
Red Tape
Be prepared to have every decision big enough to affect others needing to go through group reviews, confirming with cross-department engineers, security review(if adding a new third party package/integration), and possibly panel/council approval. Imagine you want to add a new package you found somewhere online. To get it incorporated, you’ll have to go through all these steps. Which, more or less, would take 1 – 3 months going through every step.
Pushing Problems Down The Hill
Engineering issues in these environments have a very simple cycle. Debug best you can => discover as close as possible a root cause => find team that owns that section of the codebase => notify them => repeat or fix. Simple! This isn’t necessarily something due to laziness, but more so the best use of time and engineering resources. Unfortunately, this isn’t really possible in smaller companies. There’s a problem, you’re an engineer, fix it. So different.
How To Transition
Working in this type of situation for years creates a certain mindset. Unfortunately, it’s pretty difficult to move away from. However, just because something is difficult doesn’t make it impossible. Moving away is possible, and here are a few tips that can make it easier.
- Breathe, and take it slow. Relearning is hard
- Code outside your corporate confines for some time
- Try learning a new framework or language
- Contract at a small fast-paced company and familiarize yourself with processes there
- Spend time developing different, more relatable soft skills
In Closing
Mindset can be a savior or killer for you in this industry. The wrong mindset at the wrong company will automatically lead to a failed opportunity. That’s just life. So when you’re looking to leave your A+ prestige level company to go to a smaller scale company, don’t think it’ll be as easy as opening up your IDE. It takes time, putting in the work, and realigning yourself for where you’re about to be. Not so much where you’ve been. That’s just to validate your background honestly.