How do the nuts and bolts of such “pod” structures work? One element that often causes anxiety is who is managing whom. When we moved to this team organization, we did not change the management structures. Engineers were managed by engineering managers and reported in to me. Product managers reported to the head of product. But determination of who was working on what was done largely by the pod itself. This meant that you could still get technical guidance and oversight from your engineering manager, but your day-to-day work was determined by the needs of the pod’s roadmap.
Of course, every function has its own focused needs. Usually someone in engineering needs to oversee critical core systems, and you probably need a few specialists around for things like the core web platform, mobile, or data engineering. I kept these functions in a small infrastructure organization that was not generally assigned to product development. Even with a dedicated infrastructure group, the engineers assigned to product pods still need some time to account for engineering-specific tasks like on-call, interviewing, and sustaining engineering (aka technical debt). I advise reserving 20% of all engineering time for such work, based purely on my personal experience and the experience of my peers in engineering management.
This cross-functional structure is not unique to small startups. Many large companies also structure their teams in this fashion. Banks, for example, often have technology teams that are attached to specific areas of the business, and while the management structure is formed by engineers, the roadmap and day-to-day work are jointly determined by the needs of the business unit and its associated engineering team. There is generally a centralized infrastructure team that supports both fundamental systems as well as large frameworks and technologies that will be used by many teams across the company. Even many technology companies are structured in this way, although the “business units” may themselves be headed by former engineers who act as product or business managers instead of business specialists.
The implications of the cross-functional structure are subtle. The values of everyone in these teams will start to change. In technology-focused structures where engineers work solely with other engineers, particularly engineers of their same “type” (mobile, backend, middleware, etc.), the focus is on being the best engineer by some measure of engineering excellence. People who design complex systems or who know the details of the latest iOS are the leaders and role models for the teams. In a product-focused structure, the leadership focus changes. Now the engineers who have the best product sense, the engineers who are capable of getting features done quickly and efficiently, and the engineers who communicate the best with the other functions will start to emerge as the leaders of the team.
I mean no value judgment here, but I encourage you to be aware of the product/business versus technology focus and apply it where it makes sense. What is truly important to the success of your company or your organization? If the most important thing is evolving a product that is a function of many different business areas coming together, you probably want leaders who have that business sense. On the other hand, in the areas where the technology must be rock-solid or exceptionally innovative and cutting-edge, you probably want teams that have more of an engineering focus and that are led by people who can design complex systems. You don’t have to go entirely one way or the other, but recognize that one of these will lead the company as a whole, and — especially if your role is in senior management — focus your skill set on the one that the company itself most values and hire in for the other.