Leading a team, especially a distributed or growing one, can be hard. Oftentimes the best advice and ideas come from other teams just like yours. That’s why we launched Lead Time: How Teams Work. This blog series profiles real teams, how they’re structured, and how they communicate through meetings and other touchpoints. Plus, each article features a top-notch leader who's got proven tips and real stories to learn from.
Cate’s the engineering director and functional leader for the native apps team at DuckDuckGo. They’re a remote, distributed, fast-growing team working across several different time zones and locations. The company is built on transparency and trust, and this is experienced as early as the hiring process. This also applies to DuckDuckGo's working styles with flexible scheduling and locations.
We sat down with Cate to learn about her approach to meetings and processes, and what she’s learned about leadership along the way.
Cate’s responsible for two different teams — her functional native apps team, which is about 25 people, and a group of five (four engineers and one designer) called the objective team. They work on a specific company priority. She has seven direct reports.
Ever try to add a new meeting or process to the mix only to be met with resistance and skepticism? You’re not alone. As our teams grow, meetings and processes need to evolve along with us, but process mandates are an easy way to spawn frustration and disengagement.
Something Cate’s done to counter this is to make process adjustments a team-wide effort through experimentation. (She picked up this idea from agile coach Emily Webber.)
“Now, instead of ‘process changes’ I talk about ‘team experiments’,” shares Cate. “Framing things as experiments is an equalizer. It gives the suggestion that you, as a manager, don’t have all the answers and that nothing is set in stone. It’s an invitation to everyone on the team to participate.”
Cate says experimenting with process also improves buy-in around it.
“Presenting an idea as an 'experiment’ rather than a ‘change’ frames it as needing far less commitment and makes people more likely to be willing to give it a go,” she adds.
In a recent blog post, Cate shared an example: “The first team experiment I ran was on a team that did all their communication in private channels. This wasn’t great for the perception of the team and it had made the folks within it a little insular. Our experiment was to talk only in public for a week. Of course, no one wanted to do that long-term, but doing a more extreme experiment allowed us to very quickly shift the balance of team communication. We put the work chat in public where it needed to be and kept the private channel as a safe space for personal chit-chat. A big win! Without this ‘experiments’ framework, I would have spent months of more tactful efforts to reach the same outcome.”
One important thing to keep in mind as you build out a process experimentation framework on your own team: the goal shouldn’t be to keep every experiment. Cate says if you do, you’re not being ambitious enough with your ideas. 😉
Just like the public/private channel test, Cate recommends trying out new ideas that may feel more extreme or creative than you’re used to. Then, hone in on what you learned. Apply things that worked, get rid of things that didn’t, and use it all to come up with your next round of experiments.
“When trying to turn a good team into a great team, continuous improvement and team engagement have a much larger benefit than top-down process implementation,” says Cate.
Since Cate runs a distributed remote team, she’s constantly thinking about new ways to keep everyone connected
“When you all work in the same office, you can just build structure around the work and let social take care of itself. In distributed companies, it can be more valuable to build the structure around the social connections and let the work happen,” Cate shares.
Some examples of how she does this on her own team include: