For Siva Gurumurthy, organizational success hinges on a pair of core tenets.
“As a SaaS company, the main success indicator of a tech organization is the ability to launch product features at high velocity and quality,” the VP of engineering at fleet manager KeepTruckin said.
To hit those goals, his engineering team has embraced pods to help ensure cohesion, while remaining cognizant of team size so as not to stunt velocity. They’ve also begun using platform groups to preserve product quality.
Of paramount importance, observed Gurumurthy, is an engineering structure that retains a sense of autonomy.
“We figured out the technical architecture that we’re aiming to achieve in order to maintain sufficient autonomy while maintaining consistency. This is the key in earning trust of respected engineers,” he said.
Similarly, Miguel Ríos Berríos, head of data at Brex, has seen how organizational changes are required to “future-proof” robust data operations at the credit card provider. With smaller more focused “sub-teams,” colleagues can stay focused on the respective functions that advance overall business goals.
Key to Brex’s change management? Actively engaging employees to keep abreast of potential hiccups.
“We did a retrospective to understand how the changes had affected team members,” he said. “The retro exercise provided us with an opportunity to be accountable for the reorganization.”
When did you know it was time to reevaluate the structure of your engineering team?
When I joined Brex and assessed the company’s data needs and its growth projections, I was certain we would have to design a better organizational structure. Data at Brex is very centralized: It covers everything from analytics, data platform and tooling, risk and data products. The team’s broad scope and its large number of key stakeholders made it very challenging to scale as a single team. Back then, data was a smaller team. Since the team was about to grow four to five times in a year, we had to future-proof our organizational structure.
How did you determine the right structure for your business, knowing that the team would see growth in the coming months?
Since we were planning to grow all teams rapidly, we took a top-to-bottom approach, where we divided the data function into a small number of teams with broad objectives. Over time, we split each team into pods or sub-teams with more specific charters. This way, each change would happen progressively, avoiding disruptive reorganizations.
We had to future-proof our organizational structure.”
Ultimately, how did you decide to structure your team?
Initially, we separated the data function into three teams: analytics, data platform and risk. The analytics and data platform teams are “platform” teams. They provide access to data and insights to the entire company. The risk team has a single objective, which is to reduce credit and fraud losses. Eventually, the risk team grew enough to have two sub-teams: fraud modeling, focused on avoiding fraud-related losses; and credit modeling, which works on reducing our credit-related losses. Each sub-team in data has a single — and, in most cases, measurable — objective and a small set of stakeholders, simplifying prioritization, planning and alignment.
What steps did you take to try to ensure a smooth transition to the new team structure?
We involved the entire team through the process. With these kinds of decisions, it is very hard to get any consensus. After understanding pain points and ongoing challenges, we developed the first version of the new organizational structure. We presented it to the team, gathered feedback with individuals, addressed their concerns, executed the changes and communicated them with our stakeholders.
Two months later, we did a retrospective to understand how the changes had affected team members. The retro exercise provided us with an opportunity to be accountable for the reorganization. It also gave us the opportunity to look for and correct any potential unintended consequence the reorganization may have caused.
When did you know it was time to reevaluate the structure of your engineering team?
Engineering team structure is constantly evolving. We consider reevaluation of the team structure under different circumstances. For example, when a new individual contributor and EM leaders join, they bring in new practices and new processes. That requires a reevaluation of the engineering structure.
Additionally, when the engineering KPIs — productivity, ship velocity, code quality, performance and stability — need a major boost. Or, when a subset of the team exhibits completely different KPIs than others, that also requires reevaluation. Or when a fundamental shift in technical architecture is required to accelerate the long-term product development velocity.
How did you determine the right structure for your business, knowing that the team would see rapid growth in the coming months?
A good structure creates enough autonomy for the group to be successful while maintaining consistency and interoperability between the teams. As a SaaS company, the main success indicator of a tech organization is the ability to launch product features at high velocity and quality. In order to achieve velocity, an organization needs teams aligned to the mission of the product, either addressing different customer problems or user personas, if your product solves for different personas.
Ultimately, how did you decide to structure your team?
We created a few teams which are solving a common class of user problems. That team primarily owned the business logic for those product solutions, and were primarily back-end teams. The engineering managers for these teams were generally responsible for delivering these product solutions by coordinating across other teams.
The UX teams — mobile, front end and QA — were broken into pods that directly matched the product back-end teams. UX teams usually have different dev practices, and a team needs minimum size to be successful with a constant velocity of projects. Keeping them under the same manager while having these pods afforded both team cohesion as well as fungibility. Having pods allowed each product team to have enough autonomy to deliver their projects. Since these teams measured their success through the customer impact of their product solutions, accountability was straightforward. By constantly learning through the feedback loop, these teams will eventually generate great wins for the company.
To achieve quality, a product needs to be highly available, bug-free, secure, solve for edge cases and be intuitive to use. While the product teams are focused on customer problems and the speed of delivery, there is a need for a normalizing infrastructure and processes to maintain high quality. Each functional engineering team — back end, mobile, front-end, hardware, embedded — needs a platform group. This group enforces good code architecture, good developer practices, brings standardization to the product groups, avoids team taking shortcuts and promotes reusability. More importantly, they are responsible for the infrastructure. They maintain, release and deploy the underlying infrastructure for the company.
Usually, every successful feature requires a virtual team with members consisting of multiple functional groups to make it successful. However, accountability is somewhat separated. A team structure depends on a lot of factors: the size of the business, customer base, number of engineers, growth trajectory and type of problems.
Having pods allowed each product team to have enough autonomy to deliver their projects.”
What steps did you take to try to ensure a smooth transition to the new team structure?
A team starts with a tech lead, followed by individual contributors and then an engineering manager. Depending on their skillset (functional) and interest (product versus platform), a tech lead is placed in different parts of the team to anchor the team. Since the organizational transition starts with a tech lead and is driven from the bottom up, the rest of the change more naturally follows through.
The way we achieved the transition is through the following ways: we identified tech leads who could fill a need if one existed. If not, we focused on hiring the people whose interests aligned with what we needed. We communicated the org strategy to the key tech leads and engineering managers. We explained the need for product and platform components.
We figured out the technical architecture that we were all aiming to achieve in order to maintain sufficient autonomy while maintaining consistency. That was the key to earning the trust of respected engineers. We aligned our org structure to match the technical architecture. We communicated the roles and responsibility of tech leads and engineering managers. We transitioned the role of engineering manager to more of an enabler who would wear two hats: keep teams healthy and achieve the team's mission by taking direct accountability of customer problems.
