We are excited to bring Transform 2022 back in-person July 19 and virtually July 20 - 28. Join AI and data leaders for insightful talks and exciting networking opportunities. Register today!


“Who owns the Refund Processing for American Builders?” Jane came rushing to my desk on a rainy January afternoon with a look of urgency. Our office was always bustling with engineers, product managers, and business development folks hustling to create something new. “Well, you know how I feel about ‘ownership’… what problem are we trying to solve?” I replied. Jane knew the drill but still couldn’t break the habit, having spent 10 years working with product owners in companies like Twitter and Google, and two smaller startups in the gaming industry. It took us 10 minutes to understand the issue at hand and dispatch a task force comprised of two engineers, neither of them ever having “owned” the refund payment processing before. Nevertheless, they were fully qualified to support our partner, and by the end of that day, they had identified the problem and its root cause, issued a fix, and written a quick wiki page on how to troubleshoot it in the future. Not bad for a project without an owner.

Our approach relies on Dynamic Team Assignment (DTA). And while it may sound counterintuitive, abandoning the ownership model was the best thing I ever did for my team.

Similar to my colleague Jane, technical leaders often default to the idea of ownership. Everyone from project managers to engineers are encouraged to “own” their domain, becoming a subject-matter expert and single point of contact for their respective area of responsibility. As with many trends that emerge from Silicon Valley, this model may be best exemplified by Apple, which famously assigns a directly responsible individual to every project.

The ownership model has worked well for some companies, however, team management doesn’t necessarily lend itself to a one-size-fits-all approach. Too much stability tends to stifle innovation, which is why the processes differ when working at an established company with thousands of employees. For example, not every product needs continued investment all the time, and during those times, you don’t want certain product owners to be underutilized. Additionally, we should remember the “Bus Factor” consideration: There’s the risk of losing a critical team member, without whom the project wouldn’t continue. In fact, the ownership model can disincentivize people from sharing knowledge and working toward shared conventions, as their exclusive knowledge makes them indispensable.

As we reimagine workplace norms today, leaders are being given an unprecedented opportunity to rethink the structure of their teams’ growth. In hyper-growth environments and times of fast-paced change (amplified by external pressure like the COVID-19 crisis), a high level of adaptiveness and agility is essential. Without even realizing it, companies and their employees are embracing the concept of “anti-fragility” and are shifting toward more flexible ways of thinking and operating. For example, while previous generations tended to stay with one company for life, today’s employees will hold an average of 12 jobs or more. It makes perfect sense as an adaptation to a world where jobs are changing more rapidly than ever. Stay flexible, the thinking goes, and you’ll always be ready for the next big thing.

Nonetheless, companies applying the same agile approach to their team structure are still few and far between. Facebook has mused publicly about switching models for a while, while Asana has published tips on how to mix together ownership with distributed responsibility. But these are fringe cases; most companies still see the ownership model as sacred and are not planning to rock the boat.

I strongly believe it is time to make a change and practice more intentional team agility.

Practicing the technique of DTA — the deliberate method of assigning people to priority projects as needed — is the antifragility we need to survive today. One of my esteemed colleagues, McKinsey’s Yuval Atsmon, wrote an article depicting the future of work that explains that “as jobs evolve, appear and disappear, adaptability will be more valued than longevity.” The best employees will still care deeply about their projects; and their “ownership” mindset should apply to the system as a whole, along with the company’s mission and the journey to get from A to B. This way, teams can band and disband as often as needed, based on priorities and projects.

DTA became habitual for me early in my career, during my time as a management consultant. Then I experimented with it in tech leadership after attending Prof. Boaz Ronen’s Focused Operations Management workshop, which trains leaders on how to do more with their existing resources. Recognizing that our biggest asset is talented employees, I set out to see if I could apply his optimization theories to team structure. The result was a more agile team, more resilient systems design, and a culture of flexibility.

I’ve implementing this method numerous times since then and have learned that every business is different and every team has its own ethos of success. The first step is to decide whether dynamic team assignment is indeed right for you. Here are a few steps to consider:

  • Talk to your team and engage the senior leadership. Don’t be surprised if you experience some initial pushback, especially in mature organizations with established procedures. They may not have even considered that another model is possible, especially if their current model is not evidently broken. Most leaders, however, are willing to experiment when you explain the benefits. After leading dynamic teams at both large organizations and small startups, I have seen that this approach can work for companies of any size, as long as there’s buy-in from the top.
  • Get your team to embrace continuous change (if and when leadership is on board). Many people ultimately love the chance to challenge themselves and try new things, but it may take some convincing — and possibly some goodbyes. Not everyone is suited to an agile mode, and that’s OK. Work to create a team driven by a shared mission. Be open when talking about your team’s fears, and try to align on why this is a great opportunity for everyone to learn and develop.
  • Set new hires up for success by making the structure clear from the get-go. Screen candidates for agility and flexibility, in addition to technical skills and aptitude, to qualify for this type of environment. Once they join, review their performance and collaborative abilities regularly. This can help address relationship friction quickly and give you insight into the types of projects your team members are best at.
  • Here’s the heart of it: At least once a quarter, shuffle your teams to reassign people to different projects and priorities — even when those teams are working successfully. Encourage individuals to take on a variety of temporary leadership roles, letting them experience the responsibilities of management without the burden of choosing a professional ladder to climb. This is a big deal for my team. The decision to pursue a Principal Architect or an Engineering Director role is a career choice that is often hard to make. With flexible team assignments, people can find out what suits them before they have to commit. Rent the Runway generously shared this idea in their engineering ladder blueprint, describing jobs as tasks instead of titles, and encouraging engineers to try as many as possible.
  • Implement clear conventions and standards. Some expert engineers write highly complicated code only they can understand, which makes it hard — and less likely — for other engineers to further adapt their work. Martin Fowler calls this build-up of low-quality code “cruft,” and it inevitably leads to technical debt. Clear conventions and standards can combat this. On my team, we regularly push our engineers to write code that is “open-source quality,” because someone else will be taking over their code when they move to the next assignment. No matter what the role, using conventions, standards, and best practices will help your employees make their solutions future-proof and transferrable.
  • Be prepared for pushback. There’s still a great deal of skepticism about abandoning the ownership model, so you’re likely to get some pushback until the results begin to speak for themselves. Conviction is key. For anyone who’s not quite on board, coaching, training, and reiterating the benefits can make a big difference. And for those who are intently not playing along, consider addition by subtraction. Remember, change resilience is a muscle: The more you flex it, the stronger it becomes.

Last week, I was on vacation and keeping up with the action by passively listening into some of our Slack channels. It was such a delight to see an ad-hoc team get formed to address a customer problem — fully organically, with no top-down mandate, two senior folks and a couple of newbies formed a team — just because the need was evident and they wanted to self-organize quickly. The first question they asked was “What problem are we trying to solve?” And I knew right then that the team was headed in the right direction and I could truly enjoy vacation.

If you’re ready for a new, more flexible way to work, give dynamic team assignment a try. And be prepared — you may never go back.

Ran Harpaz is the Chief Technology Officer of Hippo Insurance.

VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Learn more about membership.

Author
Topics