Leaving Big Finance
I'm sharing my experiences as an engineer in transitioning from large companies in finance to a smaller late-stage startup, because I know how much I would have benefited from this information while making my own decision.
Finding a new job is a complicated process. It takes time and effort to locate a company that has an appealing mission and is looking for people with your specific qualifications. There are resumes to polish and interviews to prepare for. If you’re already employed, taking time off to interview at other companies can be difficult. During my recent job transition, there was an additional factor to consider that made my switch extra tricky: I didn’t know what it would be like to move from a large established company to a smaller late-stage startup. I didn’t even know if that was something I wanted to entertain.
Spoiler alert: I made the switch and it’s been great. I’ve decided to share my experiences here because I know how much I would have benefited from this information while making my own decision. If you’re considering making a similar career change, I hope this will be useful to you.
First, some background information to set the stage. I’m a software engineer with 12 years of experience in the financial services industry, and I have worked for companies ranging from 14,000 to 250,000 employees. Though my work experience is limited to finance, I’m confident that my observations will hold true for you if you’re transitioning to a smaller company in any industry. In order to increase the sample size of experiences to draw from (and to ensure my experience wasn’t unique in any particular way), I spoke with a handful of colleagues who previously made the switch to Betterment from a larger company and found that their experiences closely mirror my own.
I’ve identified a few key differences to keep in mind if you’re considering this transition: pace of development, team structure and resources, and expectations placed on the individual developer. There’s a lot more to consider when changing jobs, but I hope these thoughts will pique your curiosity enough to explore further.
Pace Of Development
One of the most noticeable differences about working at a smaller company is the rate at which we build and release software. It may be no surprise to some that the amount of red tape scales in proportion with the size of the company, and when that overhead is minimized, it ultimately leads to a faster and more efficient pace of development.
The sign-off required to start major initiatives is a perfect example of this. I’ve seen first hand how conversations with stakeholders, approval from supervisory teams, and buy-in from business can delay the start of new initiatives. These are all important first steps to take, but in slow-moving organizations the amount of time required for each step can quickly add up. And in my experience, the longer it takes to start work on a new project, the less likely it is that project will come to fruition.
This isn’t to say that Betterment doesn’t understand the importance of thinking through any new functionality before cranking out code. We regularly sit down with our peers to have open discussions about upcoming development work and how to avoid potential pitfalls. But this happens over the course of days instead of months.
Testing is also a key component of our development culture here, and is one of the reasons we’re able to deliver functionality as quickly as we do. By requiring every change to be reviewed by a minimum of two peers, we minimize the amount of time spent tracking issues and troubleshooting bugs. And by minimizing the amount of time it takes to start new development we’re able to shorten the feedback loop: being able to test faster surfaces potential problems in the design or implementation much earlier in the process.
The “Last Mile Problem” in software development is based on delivering these new features to your users, or being able to easily deploy new code to production. Many large-scale companies have audit policies in place that create release moratoriums. At my last company, policies like these prevented us from releasing more than twice a month. These constraints made missing a window of opportunity to deploy code so costly that developers were required to dedicate a non-trivial amount of time to planning and coordinating releases. While we have policies in place at Betterment in order to minimize website downtime and overall system disruption during trading hours, we’re still able to push code to production on a daily basis. This keeps production-ready functionality from piling up and eliminates the need to spend any time managing releases.
Many of my current coworkers who have also worked at larger institutions have said that they can now do in a week what might have taken them a month at their previous company. I’ve experienced this firsthand, and I wholeheartedly agree. While this aggressive pace can be stressful at times, I have found it leads to a much greater sense of individual productivity and job satisfaction.
Team Structure And Resources
Larger companies generally have more resources at their disposal, while smaller companies are forced to do more with less. One excellent example of this is how each type of company structures teams.
At a previous job, there was a group of developers whose sole responsibility was testing the functionality of the work done by other engineers. Supporting a hyper-specialized team like this obviously takes more resources, like additional payroll and the space required for more employees. If financially viable, this type of setup can have a lot of advantages.
However, when resources aren’t as abundant, there can be several positive outcomes as well. In my experience at Betterment, for example, we start with the expectation that engineers are flexible enough to approach a variety of tasks with confidence. We have no specialized teams that exist solely to test code. Regardless of their level, every engineer is expected to write comprehensive unit and integration tests when building new functionality. Ensuring adequate testing is a large part of our two-step review process and is core to our success.
This multi-disciplinary approach extends beyond writing code: when an engineer feels we stand to benefit from procedural or platform improvements, our engineering organization empowers them to enact said change. Not only does this cultivate a collective sense of ownership and responsibility, it also fosters a culture of empathy wherein everyone cares about the platform as a whole. And when developers feel invested in something more than the lines of code they write, they increase both their value as employees and their ability as engineers.
Expectations Of The Developer
Another difference that was immediately obvious to me upon joining a smaller company is the freedom engineers at smaller companies have to pick the tools and frameworks that best suit the job at hand. This freedom ranges from being allowed to choose our own IDE or external HTTP client for development, to being able to transition older applications to frameworks we’ve decided are more modern and performant. Depending on the impact of the tool they’re selecting, engineers can make decisions independently or can choose to initiate a larger discussion with more perspectives included.
In my previous jobs at larger companies, these tooling decisions were made by dedicated teams that were often detached from the engineers who’d end up using the tool and were therefore limitedly impacted by the outcome of the decision. At Betterment, we believe the engineers who will use the tools are best equipped to drive the research, decision-making, and implementation of the right tool for the task.
This type of change may seem unquestionably positive. However, with this freedom and trust comes the serious expectation that engineers will do what’s best for the company as a whole. Sure, it might be fun and challenging to learn a new language and introduce it to your codebase, but will that change be sustainable in the long run? Expecting that employees act in the company’s best interest is common across companies of any size, but at smaller organizations, greater freedom must also be balanced by more self-discipline and careful consideration.
A smaller team also means there are higher standards for measuring individual performance. In my time spent at larger companies, I noticed how easy it was for team size to mask weaker performance. Everyone wants to believe that hard work and dedication will result in promotion and greater responsibility – the foundation of a true meritocracy. However, organizational bloat affords employees with ample opportunities to hide if they simply want to coast. In a smaller company, where there’s often much greater emphasis on processes that drive organizational transparency, this isn’t an option. All employees are expected to meet and exceed certain performance benchmarks, or move on to another opportunity.
It’s critical for everyone – engineers and non-engineers alike – to constantly take stock of their current role and identify what values are most important. Maybe you value an opportunity that allows you to work independently of a larger team, or maybe you value the community aspect of working closely with colleagues. Is feeling empowered to enact change important to you? How about the ability to take on initiatives above and beyond your day-to-day responsibilities?
There is no perfect job; every position is going to come with some downsides and moments of frustration. However, after evaluating what’s most important to you, if you find that your current role is falling short in more ways than not, maybe it’s time to consider a change.
I started working at Betterment 10 months ago, and while it took a few months to get accustomed to all the changes mentioned above, I’m incredibly happy about this career transition. If you’re looking to make a larger impact on your business, or you’re unhappy with stagnating growth as an engineer, or you feel your creativity is limited by your current employer — or even if you’re simply open to experiencing new processes or a different pace of development — I highly recommend considering a similar change. At Betterment, we pride ourselves on providing an environment in which anyone can learn and grow, regardless of their experience level.
No matter what your next job is, I would challenge you to inventory what you’re looking for and see how your values align with any potential employer. And if you’re interested in contributing to the engineering culture we’re building here at Betterment, don’t hesitate to be in touch!
This article is part of Engineering at Betterment.
These articles are maintained by Betterment Holdings Inc. and they are not associated with Betterment, LLC or MTG, LLC. The content on this article is for informational and educational purposes only. © 2017–2019 Betterment Holdings Inc.
WebValve – The Magic You Need for HTTP Integration
Struggling with HTTP integrations locally? Use WebValve to define HTTP service fakes and toggle between real and fake services in non-production environments.
Guidelines for Testing Rails Applications
Discusses the different responsibilities of model, request, and system specs, and other high level guidelines for writing specs using RSpec & Capybara.
6 Ways to Retain Top Talent with Financial Wellness
Beyond just handing over a paycheck, supporting your employees’ financial wellness plays a crucial part in retaining top talent.
Explore your first goal
Our high-yield account built to help you earn more on every dollar you save.
This is a great place to start—an emergency fund for life's unplanned hiccups. A safety net is a conservative portfolio.
Whether it's a long way off or just around the corner, we'll help you save for the retirement you deserve.
If you want to invest and build wealth over time, then this is the goal for you. This is an excellent goal type for unknown future needs or money you plan to pass to future generations.