On the other hand, we have to lead, inspire, and coalesce massive teams. Amazon, for instance, announced they’d hire 55,000 knowledge workers, mostly in software engineering. These massive teams are then subdivided into their own teams, creating a “team of teams” dynamic that requires precise coordination. Simple handoffs from design to engineering have evolved from one-time events into a constant interplay – the process has gotten so complex that engineering executives could be forgiven for feeling inundated.
So how can you make this massively complex coordination between teams both effective and productive? Your first thought may be to overengineer (pun intended) processes that resembles micromanaging. Fight that instinct. As the Senior Vice President of Engineering at Foursquare, I have a single guiding principle for my teams: empower them. Let them make decisions. On any given task, they know better than I do.
Building a strong team to lean on has always served me well.
It can be hard for a leader to let go of the reins, but it is critical they do so. Leaders should remember team members are closer to the customer than they are. They will make decisions with customers in mind. Your team members are experts on the customer, and they’re closer to the details than any executive could be.
Engineers on your team will do their best work – they will execute on products that could truly upend an industry – when you focus on setting them up for success, not when you focus on their day-to-day tasks. Freedom for your engineers is more productive than micromanagement.
Relatedly, empowerment is the sibling of ownership. Team members who feel empowered to make decisions believe they are responsible for the end product; they care more. Team members who feel empowered are more creative and more helpful to their teammates. They work harder. They make better decisions.
They innovate more and create better products, which is their core responsibility.
The question, then, is “how?” How do you empower employees? It’s not as simple as buying the right tech stack (although that can be helpful). If it were that simple, every company in America would have done it.
Most critically, leaders must listen. Not in a “fill out a form” or Doodle poll kind of way, but in a real, open, supportive forum. If team members have concerns, hear them out all the way, then, most critically, do something about it. Do they need a new tool? Advocate for it in the next budget. Is information flow too slow or disjointed? Find out why.
Further, leaders should not make these conversations the team member’s responsibility. Leaders should remember when they were junior employees and how scared they were to approach their boss with an issue. Instead, have regular check-ins with people up and down the seniority ladder. These can be informal, designed to solicit their genuine feedback, both about what’s not working right and, just as importantly, their innovative ideas.
And it is important to note that organizational design of your team can aid in this empowerment. Foursquare has structured its product development teams along two major axes to ensure collaboration.
First, we have our product-focused teams (i.e., teams around products like Attribution or Unfolded), with personnel from groups around the company that focus around one product. Such teams enable innovation in everything from product design to pricing; just as critically, it gives team members the space to relentlessly improve the product.
Second, we have horizontal teams that focus on building platform offerings affecting the entire company. There are always opportunities to improve the entire platform or, more urgently, to deal with issues impacting our entire suite of products. These teams must have an understanding of everything Foursquare does and, critically, be ready to move fast. They can design fixes that work across the entire enterprise, so customers who use many of our products do not have to implement multiple solutions to the same problem.
I’m not going to pretend setting up this engineering structure is quick or easy. It took a lot of time and effort. The most difficult part was shedding old habits (and, in my case, blending company cultures). We had to discard practices that did not ultimately produce the best results for customers. Building teams around internal disciplines or expertise, rather than anything a customer will ever see, is a comfortable choice. It will also ensure customers don’t like what they end up with.
Similarly, we had to dispense with “tiger teams” – the short-term groups set up to address a particular issue, like a bug or an underutilized feature.” Building trust and “muscle memory” within a team takes time. It is invaluable. It does not make sense to dispose of such a critical asset. Worse yet, tiger teams tend to focus on short-term fixes; they are the duct tape of software engineering. Such short-term fixes rarely end well for companies and, more importantly, for customers. Organizational structures that prioritize short-term solutions essentially promote poor long-term outcomes.
Building a customer-focused structure revolving around empowerment is a whole team effort. It requires modesty; executives must be willing to change their own behavior and listen to feedback. It is a challenge, but, if an engineering executive is to be successful, it is not optional.
Ankit Patel is Senior Vice President of Engineering at Foursquare.