From 5 engineers to 50: What a fast-growth team has taught me

Routable has grown significantly during my time here: two funding rounds (Series A and Series B), two new accounting integrations (Oracle NetSuite and Sage Intacct) and countless new features. Our team has exploded in size from when I first joined, starting with only five engineers to now over 50. I’ve learned so much along the way, and in this post, I’d love to share five of my main takeaways from the experience so far.

1. Establish your values and norms early—and document them

Every company has values and norms, but have you written them down? Routable has.

In the beginning stages, founders and early employees establish the culture of their organization in explicit and implicit ways. A few examples include how you give praise, take time off, deal with conflict and give feedback. As growth occurs, culture can shift organically—and not in ways you sometimes expect or want. Writing down your values helps new employees understand what’s expected of them, how their success will be measured and how to navigate the culture of the company.

In my former life, I was a special education teacher. I carry a lot of that experience with me as an engineer and manager. I believe you shouldn’t expect someone to know something unless they’ve been taught. We all remember that teacher who’d put questions on the test that wasn’t on the study guide. Don’t be that teacher.

At Routable, we set up new employees for success by having a solid onboarding aligned with our values. We use tools like Rippling and Lattice to automate onboarding tasks and set up recurring one-on-ones, allowing us to start building authentic relationships that allow us to engage with empathy during every interaction. Everyone gets an introduction to the product with WorkRamp courses and hands-on experience with Routable using TestRail so that they’re able to own their role and build with purpose. Our norms are documented all over Notion in the form of repeatable processes.

2. Rethink team organization

That same growth that necessitates clear values and norms necessitates a different organizational structure. When Routable started, we had two groups of engineers: frontend and backend. This worked because each group had only about five engineers. Now, we’re organized into Pods.

A Pod is a team that consists of about five engineers along with a product manager, designer and a quality engineer. At Routable, we have nine Pods. I’m part of the Partner Management Pod where we build an industry-leading vendor experience and give our Routable clients awesome tools to manage their business relationships.

Pods can also own and build a business domain. They can change, grow and split as the organizational needs dictate.While there is no one-size-fits-all solution that works across all companies, there is some research to support the basic concept of a Pod-like structure. Enter one of the biggest organizations in the world: the U.S. Federal Government.

As a search and rescue volunteer in Southern Oregon, I use the Department of Homeland Security’s National Incident Management Structure (NIMS for short). NIMS supports interoperability and flexibility.

That sounds like a growing company to me. Interoperability translates to communication and eliminating information silos. Flexibility means that the system can grow, shrink, shift, and change to meet the demands of any problem. My favorite NIMS principle is manageable span of control: One boss should have about five direct reports. Much more and you can’t support everyone or have a general overview of team effectiveness. Any less and you’re under-utilizing resources.

3. Keep code quality up with automation

One of our hardest tasks has been balancing our code quality standards with the need to build quickly. Routable Pods each developed a subset of norms about what is acceptable code quality while staying true to the overall “sweat the small stuff” engineering culture.

Our venerable CTO Tom Harel has always said, “If it’s not linted, we shouldn’t care.” I’ll add my own feelings: Let computers do the dumb stuff.

On most of our projects, we have a robust set of linting rules that automates code formatting and the other “small stuff” that keeps a codebase clean.We also have a robust set of unit and end-to-end tests we run using continuous integration, on each pull request. Back in the dark days before this system, the whole company would have to spend half a sprint QAing the product for major releases. Engineering’s investment in testing allows us to free up our brains to solve harder problems faster.

4. Build with the future in mind

Another huge component that supports code quality, discoverability, velocity—all the important stuff—is overall system architecture. At Routable, we’re constantly thinking about the next iteration, because doing things right the first time almost always saves money, capacity, headaches and sanity in the long run. Doing the right thing may even accelerate growth, like the time we spent building our own server-driven table UI to quickly support more accounting integrations. Slowing down and building for the future isn’t a new concept, but it can feel aspirational when you’re in “startup mode.”

One thing we’re trying to do as we look to the next iteration is to consider how to break our application into smaller, more atomic pieces. Not quite microservices but a service-oriented architecture.

Our use of Django on the backend lends itself to this type of architecture through sub-apps which could theoretically be pulled out and owned by a single Pod. At this point, we’re not quite big enough for that to make sense; having to make code changes across tons of different repositories would slow product development to a crawl. Instead, because writing new code is almost always easier than refactoring old code, we’re looking at ways that new services can be created as we roll out more features.

The frontend is a different challenge. We can pull out our component and design library into a shareable package. We’ve started adopting TypeScript for self-documenting code; the static typing also provides more safety at scale to JavaScript. We need to reduce our state management boilerplate and find a better way of making use of the JSON:API structure to cache assets.

5. The Three Ps: Process, Process, Process

As we think ahead to the future of engineering at Routable, we’ve got these huge scalability goals. But to meet that challenge, our processes have to scale as well.

Take a look at how our product development has changed over the years.

In our early days:

• The CEO or CTO presented an idea based on customer interviews.

• The designer (yes, the one designer) would translate those ideas into a solution.

• Frontend engineers would code those designs to life.

• Backend engineers built the data models to support the functionality.

• At some point, frontend engineers and backend engineers would either wire together the pieces or not—everyone was working on one feature, so problems would get resolved pretty quickly.

This process doesn’t work as you get bigger.

In our more mature product development life cycle, here’s what we do now:

• Our executive team works together with product and engineering to set OKRs and KPIs to move the company forward.

• Product managers discover features or improvements aligned with those goals and interview customers to validate their ideas.

• Designers turn these ideas into visible assets (and magic, lots of magic). Pod tech leads evaluate the product specifications and designs to create a valid architectural framework for the solution, which they bounce off of code architects.

• Tech leads also support sprint development through ticket writing and guiding ticket refinement.

• The engineering managers help plan sprint capacity and timelines, all while the individual engineers are crunching away on their code.

Phew. That’s actually all of my previous four lessons I learned tied up in one meaty process. This development cycle is documented as a norm, includes a lot of team players, delegates responsibility so individual engineers can focus on code quality, and thinks ahead to the future by including architectural review.

In summary…

The best time to plant a fruit tree is 20 years ago. The second best time is now.

• We started with documenting our values and norms. We believe in teaching our folks what’s expected of them through great onboarding and mentorship.

• As we grew, we considered how our team structure supports team members to live those values and follow those norms. We set ourselves up for success by having a flexible organizational structure that supports the open flow of communication and ideas.

• Routable had strong code quality standards early. We used tools and automation to enforce those standards so they became second nature to our engineers. We’re always thinking ahead to the future. We can’t future-proof everything, but we can “save us from ourselves” with just a little more effort.

• As our company has matured, so have our processes. And we’ve written those processes down so that they can be reused and iterated upon.

We didn’t have all of this stuff figured out when I joined Routable, but we’re engineers. We solve problems and we’re culturally committed to making Routable a great place to work and build a product that solves real pain points for real people.

Interested in joining our engineering team? Check out open roles on our Careers page.