At Serengeti, we use something called The Team Extension Model. (Here is also a video about the model.) The model was developed because our founder saw companies desperately try to find software development help, but not be able to find a group of developers that was both flexible and had expertise.
The common problems you run into trying to scale up a developer team are these:
- You try to hire freelancers: … but that doesn’t scale.
- You try fixed-price outsourcing: … but you get missed deadlines and limited expertise.
- You hire in-house: … and it’s time-consuming, expensive, and unfortunately you don’t always get high-quality people.
You bring in outsourced development teams: … and the teams have different processes than your organization, different leadership, and it never feels like a good fit.
Those were the four big problems. Entrepreneurs solve problems. So here’s what we wanted to set out to do:
- Give clients access to developer expertise.
- Give clients access to flexible scale-up and scale-down models for busy seasons and product launches.
- Give clients access to developers who were very product-focused.
- Give clients access to proven best practices and resources.
- Give clients the most flexibility possible.
Over time, we’ve managed to successfully build this -- for about 10 years now. We have 150+ engineers who hold 300+ certifications, with 43% of our available developers at the “lead” level and another 28% at the senior level.
How exactly does this all work, especially with concerns about in-office and melded teams because of COVID?
The general process is that we begin onsite. This is starting to happen more again as some countries have better vaccination and immunity rates, but it’s been happening recently on video chat. The onsite portion of the relationship is about knowledge transfer, explaining priorities and goals, and team-building. There is an idea called “grafting,” which means it’s not just about how good the developers are -- they need to become part of the team. That’s what we try to accomplish in the onsite phase.
In the onsite portion, we also learn management structures, application background, programming technologies, and look at previous builds and infrastructure, while talking to the existing team about what’s gone right (and hasn’t) on previous deployments.
The second phase is the transition phase. The ambassadors from the onsite portion become the team leads, and we get to work. Here are a few examples of recent projects.
The biggest benefits of this system are best seen at different levels of an organization:
- The C-Suite/senior leaders: They get rapid-scale deployment of new tech/product. They get flexibility in the staffing model. They get cost containment and value at the same time.
- Internal technical leads: They don’t have to hire or fire, and the technical managers are not threatened -- instead, we work with those technical managers on deployment. We just serve as an extension of their team. There’s also limited micromanagement.
One concern we do hear sometimes from prospects is “Well, Serengeti has all this expertise among developers, but what if someone leaves Serengeti or has a kid and goes on leave, or something?” Well, first of all, not a lot of developers leave Serengeti. Our turnover rates are very strong. We do, though, have a Shadow Developer Program, which allows junior developers to shadow a senior/lead developer and get up to speed on projects faster. We designed it as a way to help with quicker onboarding, but the added benefit is that if someone goes on maternity or paternity leave, we can immediately plug someone else on your project without interruption.
That’s a little bit about how the process of extending your team into our team as one team works. What other questions do you have? Feel free to reach out.
