by Pravin Paratey

Structuring your Engineering team


At Affectv, we grew extremely rapidly over the course of 3 years. Our headcount exploded from 2 to 70 and the Engineering & Product teams more than tripled each year. This is a compilation of what I learned optimising product delivery and reduce bottlenecks through trying different team structures.

In the beginning — No model

When we added our first few engineers, we didn’t have a structure in place. All engineers reported directly to me. I was their manager, tech lead and the systems architect.

As our business grew and we started adding more engineers, this model just couldn’t scale. It was time to try something else. Since all the companies I had worked in before had used the time tested functional model, that is what I decided to adopt.

The Functional model


This is the the oldest model and is heavily used not just in software development, but in pretty much all areas ranging from the military to manufacturing and pharmaceuticals.

In this model, you divide the team by function. For instance, you may have the front-end team responsible for web development, the back-end team writing server side code and the data-science team responsible for analysing the data.

There are a number of advantages to this model,

  1. It’s simple to understand. People know exactly what’s expected of them and their area of ownership.
  2. Fosters experts. Over time, people gain expertise in their area and experts from outside the company can be hired to do specific functions.
  3. Common tools and processes. It’s easier to standardise on platforms, coding standards and processes, thus improving productivity.
  4. Management. Reporting lines are simple and performance management and KPIs become easy within each function.

However, there are disadvantages too,

  1. Silos. An unintentional consequence of this structure is that your teams become siloed. Instead of focusing on product, sprint planning discussions tend to focus more on the APIs/interfaces needed between the various teams. At best, your processes change from agile to waterfall. At worst, it becomes a blame game. Then again, who is responsible for the areas that don’t clearly fall with their defined “functions”?
  2. Lack of ownership. Another consequence is that engineers do not feel ownership of the product anymore, and ownership moves to their code or function. This problem exacerbates for functional teams building multiple products.
  3. Slow Development. With growth in product features and teams, development slows down as communication between teams is harder to manage. Beyond a certain team size, this is perhaps the hardest structure for agile development.
  4. Measuring team impact. How does one measure the performance between the Backend, Data and Frontend teams in a fair way? It becomes a non-trivial to set performance expectations with the team that align with the business outcomes.

When I first created the Web, Server and Data teams, it was really great experience for the company. Having some structure, where previously there had been none, was really great! Engineers now knew what they were responsible for and were excited at becoming domain experts. Our sprint planning processes changed.

As the team sizes increased and we added a bunch of products, it became harder to get things done due to the disadvantages mentioned above. The time-tested functional model wasn’t suited to a startup trying to iterate quickly and try new products.

The Pod model

It was time to try the Pod model — where one built a team around a specific product. An example of this, could be a product team with a DevOps engineer, PHP developer, HTML developer and a Javascript developer responsible for building a client’s website.


Companies like Facebook use this model quite extensively and I was keen to understand if it would help with our situation. Before jumping to it, I wanted to learn about it’s drawbacks.

  1. Line Management. Line management is a challenge. If line managers are responsible for a pod, they may not be able to fairly evaluate all the different functions. If line management remains functional, the line manager will not be part of every pod and thus lack context.
  2. Built-in Redundancy. Since functions are replicated in each pod, the wheel may be re-invented in each pod. Show & Tell sessions are useful to increase flow of information and reduce work replication. Also, headcount may have to be replicated across different pods, compared to the Functional model where one person would’ve been able to support both products.
  3. Standardisation. Unless different pods talk often, use of frameworks will diverge. Also, pods might choose to use esoteric technologies. Care must be taken to ensure that technology fragmentation is managed.

The benefits as I saw it were,

  1. Autonomy. Pods can be made to operate as autonomous, self-directed units with minimal red-tape.
  2. Self-sufficiency. Each pod was self-sufficient as they had exactly the people and skillsets needed on the pod.
  3. Flexibility. Pods are immensely flexible. They can be formed and dismantled as per business needs. They are technology agnostic. And immensely replicable.
  4. Replication. As your business grows, and there are new product ideas, you can simply add more pods.
  5. Measuring team impact. Team impact equalled product performance in the market, can be tied to revenue and is so much easier to measure. Each pod can operate it’s own P&L.

We divided our teams into various pods, each responsible for a single product. We ensured each pod had a Product Manager and a Tech lead/Manager who would be jointly responsible for its output.

The results were pleasantly positive. Morale improved significantly, more ideas were generated and the pace of production increased. Product Managers were happy as they knew exactly what resources they had and didn’t have to negotiate for resources. Meetings became more efficient and less frequent for most people. The slight downside was that the team leads/managers had the additional responsibility to ensure knowledge flowed between pods and common standards were maintained.

Why is structure important?

As your business grows and you add more engineers, planning your growth becomes essential. Growth, if not managed carefully, can quickly get out of hand resulting in loss of productivity and morale. Things that were crystal clear become fuzzy all of a sudden. For example, take ownership — when a team is small, ownership is apparent. Decision making quick. And adding new features easy as the the system is simpler and most people can keep it in their head.

So if you feel like your current team structure isn’t working effectively, and your team is demotivated and productivity has plummeted, perhaps its time to try something different?

There is no perfect team structure. Companies, as they evolve must adapt and change their structure and processes to maximise their teams productivity and happiness. This is the lesson I learned.