Self-Organization at Tapad

“A large organization is a collection of local communities. Individual and institutional growth are maximized when those communities are self-governing to the maximum extent possible.”

(Mary Parker Follett 1924)

It’s a series of struggles that many startups face as they experience growth spurts and begin to mature: how do you maintain a culture of innovation, keep employee morale high, and scale the delivery of market-changing products?

For many companies the answer is clear; they must remain “agile” and “lean” and eschew traditional heavy process. Unfortunately it’s not always so cut and dry, and many of the key principles that inform things like the Agile Manifesto get lost with the influx of new talent, new executives, and increased customer demands.

One of the most crucial of these principles is the notion of the Self-Organizing team. According to the 12 Principles behind the Agile Manifestio, “[t]he best architectures, requirements, and designs emerge from self-organizing teams.” More and more we see even traditional, larger enterprises trying to embrace this notion and empower their employees in an effort to remain competitive with their peers. Why?

For over 100 years, efficiency experts and management professionals have been espousing the benefits of the self-organized team. Typically such teams show incredible productivity gains, increased morale and job satisfaction, and the ability to both innovate upon existing products and introduce new, market-shifting products.

And yet, one of the first things lost when companies grow is this tenet of the Self-Organizing team. As organizations expand so do the numbers of managers, and with them a corporate hierarchy is established. A natural trend to a command-and-control, top-down approach to business seeps in, affecting those three key efficiency metrics: morale, production, and quality.

Here at Tapad we are attempting to mitigate these potential growth-risks by baking self-organization into our organization structure. By establishing product-focused pods, we ensure that teams are small enough to reasonably self-organize around business objectives provided by our executive team.

Rather than the top-down, traditional approach of an executive team issuing orders to their subordinates, the pods are given concrete and attainable goals and expectations. Whether they are revenue numbers, the number of new clients signed up, or improvements in system performance, these goals are quantifiable – allowing management to track KPIs and evaluate the performance of each team as well as the company as a whole.

Each pod’s General Manager, working with the various team members (including, but not limited to Product Owners, Engineers, Designers, and more) are free to identify what they believe to be the best course of action for achieving their stated objectives. Through regular usage of tools like retrospectives, the pods can self-evaluate their performance and adjust their plans to ensure they stay on track.

It’s not limited to just team-based work either; we have some efforts, like our Product Commercialization process, that require cross-discipline members to regularly work together with company-based goals in mind. Each effort, each product has different objectives and needs and so the Commercialization teams have to work together to identify the best course of action given the people involved and the goals at hand.

Through communication and collaboration amongst the interested parties, each Product Commercialization effort has established its own framework for moving forward, and each framework is regularly and frequently reviewed by the people involved. Doing so has helped prevent both the potential for management-based command-and-control experiences as well as the burden and bureaucracy of excessive and wasteful meetings.

This freedom and autonomy does, admittedly, create some chaos. Not two pods do things the same exact way, so working across pods or when other such dependencies exist can exhibit some pain – but no more than what occurs with any sort of inter-team dependencies, with one minor exception – we allow the teams to self-organize amongst themselves, as well, in an effort to reflect upon those pain points and come up with potential solutions.