Part 4 of this series explores my third job — working as an engineer, architect, and a few other roles at a small fintech startup.

Chapter 4: The Startup

I got an opportunity to be involved in every part of building and running applications, from code to DB to infrastructure. I also gained a lot more insight into how the actual business ran and how the pipeline of work was shaped.

Working with Product

One of the first things I really learned at this job was just how useful it can be to really understand how the thing you are building works from a business perspective. I am a firm believer that tech should be involved in the entire product development life cycle, but to do so you have to understand the business you are in. I often tell engineers now that they really need to understand how the thing they are working on makes money.

I also learned it’s important to understand why we are trying to build something, not just what we are trying to build. Understanding the longer term goals can help influence your design, or you might be able to suggest shortcuts to get to where you want to end up in the long term. I’ve seen projects that were broken up into phases to be able to deliver something sooner, even if it wasn’t the end goal, where tech was able to come in and say it’d be almost as fast to skip straight to phase 3 as it would be to build phase 1 (and we could skip phase 2!).

Sometimes the product/tech relationship can feel combative, and to some extent it always is. It’s a game of give and take, but the important thing is that everyone realizes they are on the same team and you only win by working together.

Be Pragmatic

This one can be hard, but it’s important to realize that nothing you build will ever be perfect, and that’s OK. Sometimes it’s more important to ship something than it is to try and make it perfect and never ship it. Incurring tech debt can be frustrating, but sometimes you have to do so, and the important thing is acknowledging and tracking that debt so you can pay it down later. This is often all the more important at a small company running on thin margins, but it’s true at larger shops as well. If you spend too much time trying to do everything the best way possible, you’ll likely be left behind when someone else does it faster. I’m not saying always take the shortest path, as that too will lead to bad things, but as developers it’s important to understand the law of diminishing returns, and find that sweet spot where things are in fact “good enough” that we can deliver quality with speed.

Scaling Processes is HARD

When I joined this startup, there were so many things that just seemed to work so much better than at the larger places I had worked before. We were small and scrappy. Everyone largely knew how every part of the system worked and people could jump around to work on different things when needed. As we grew I noticed that things started to feel like some things got harder and harder. The code base grew and it was harder for everyone to be an expert in the whole thing anymore. Teams grew and had to be split into multiple teams, so often you needed to loop in more than one or two people to get a decision made. While I was there we grew to about 15 times the size as when I started, and so many of our early processes just fell apart when we got that big. I learned there’s no magic bullet here, but you have to adapt and reinvent your processes to be able to scale. This would be even more challenging and insightful when this startup was acquired by a company that was around 100 times larger. I do feel like we’ve been able to bring lessons from what did work for us to American Express, but many of those processes would fail if we tried to keep them as is at that new scale.

Wrap Up

Working at a startup was great and I learned a lot of things. Some of it tech, like the public cloud and infrastructure as code, and some of it not, like a whole bunch of finance stuff. I also got a chance to work with some of the smartest people I’ve ever met. It was often a lot of work, but a very rewarding experience for someone willing to put in the effort.