Deciding which projects and how many engineers should work on a project is a controversial topic in almost any company. Some companies call this “resource allocation.” We do not view our engineers as simple resources, but still the planning and the agreeing needs to happen for us to be an effective business. Often times the conversation is around sheer quantity — how many software engineers should we hire? I’m going to completely ignore this (Hiring) question in this post and instead focus on the problem of allocating them once you have them.

Our Context

First, let’s understand what we focus on here at Enova. We have six businesses that need development, internal tools that need support and internal teams that build our next generation architecture. The goals of each of these groups are somewhat aligned, but the detail and priority of these various teams are allowed to operate relatively independently. One thing is for sure, though, they all need engineers to accomplish their goals. Thus they vie for resources to be allocated to their project which brings up some tough questions for us to answer as a team:

• Should we allocate engineers to the most revenue generating projects?
• Should allocate the most people to projects that have the highest growth potential?
• How many engineers should focus their complete attention to tech debt?
• How should we balance investment in future technology vs maintenance of current technology?

All of these questions are challenging to answer individually, let alone all together at once. If you don’t invest in the future you may never be able to make strides to evolve your product through actual technology leverage.

However, if you don’t support revenue today, you may not even make it to “the future”. Also, whichever allocation method you use, how do you adapt to changing business priorities and market conditions while predictably providing the resourcing required for mid to long term planning? These are all difficult challenges, but here’s the system we have decided upon for now at Enova.

Dedicated Software Teams

We have teams that are “dedicated” to a single business, internal tool (one example is our custom CRM tool, Aperture), or a set of services (two examples being an amortization calculation service and our payment gateway). The size of each of these dedicated teams are determined at the beginning of our fiscal year and are re-visited mid-year.

The relative stability of the size of these teams provides software engineering and product managers the predictability to drive a roadmap reliably and forces prioritization within that dedicated team’s initiatives. From an engineer’s standpoint, a dedicated team provides a stable context in which to grow their skills and potentially try new things technologically in a familiar environment.

Ranger Software Engineers

To address our ability to change to market conditions, we have another type of team we call a “ranger” team. These teams are small (generally 3-5 engineers) and rotate around to dedicated teams as needed by business priority.

These teams are re-allocated every 6-8 weeks through a stage-gating process we call EPG (Enova Planning Group). How we prioritize projects is a whole topic in and of itself that we will cover in an upcoming post. The group consists of product managers, product directors and executives from across the company.

The EPG process is where any product manager for a dedicated team can make a pitch to the EPG group for a ranger team. The pitches are stack ranked and this ranking drives which dedicated teams the ranger teams are re-allocated to.

For engineers, ranger teams provide exposure to a lot of different areas of the company and they can build experience working in different environments, different teams, and different people while building some of our highest priority short term projects.

That’s the basics on how Enova allocates our software engineers. Do you have questions or comments or want to share your system? Feel free to reach out to me on LinkedIn or Twitter.