Multi-Dimensional Engineering Management
There are two common strategies for structuring engineering teams:
Functional teams that group engineers by specialization led by an engineering manager.
Cross-functional teams that group engineers with different strengths, often led by a less technical business manager.
Each approach has strengths and weaknesses, but why settle for one?
At RJMetrics, we organize our engineering across three dimensions. This can be a bit confusing at first and might seem like there are multiple bosses and overlapping responsibilities, but here’s why we do it.
Did you ever have a manager who was a technical wizard, but was weak on communication? Is your manager great with people, but gets lost when you try to explain why your project is behind schedule?
Have you ever been stuck on a project Way. Too. Long?
These are the kind of problems we’ve tried to address at RJMetrics by
- Taking advantage of our individual personality strengths
- Cycling through projects quickly, while maintaining technical consistency and code quality.
I created this interactive D3 visualization to illustrate the three dimensions we organize across.
Personal: Each member of the team is assigned a manager responsible for helping them level-up as an engineer and plot out their career trajectory.
Functional: We have three teams covering our technology areas. Core handles microservice standards, infrastructure, deployment, devops, etc. Data handles data replication and transformation. Web builds out the application layer and user interface. Each team is responsible for maintaining code quality and managing their own tech debt. Engineers may move from one team to another, but it’s rare.
Project: Projects are spun up to tackle problems that should take between 2 and 10 weeks, so no one is stuck slogging it out on the same projects for months at a time. Each team is assigned 2–5 engineers with one serving as the tech lead. Leads are responsible for technical direction and decision making and this gives engineers a chance to level up their leadership skills.
In the past our functional teams lasted indefinitely and worked on 1–3 projects at a time. This made us more specialized, but also didn’t give our engineers exposure across the code base, reducing our bus factor. We then moved to a cross-functional team system where engineers could be moved onto to any project, but in that system we felt we were losing our control over tech debt and code quality. Our current system helps us balance those two concerns.