The Team Leads Community at AppsFlyer R&D

Why does AppsFlyer need a team leads community?

We noticed that team leads face specific challenges, and we wanted to take them on together and turn them into something good. You could say there are 2 things that set team leads at AppsFlyer apart from other management layers:

We're the largest management layer in the organization. When we started there were 40 team leads, and today we're more than 60.
We're the management layer that touches every group in the company. On one side we have a direct line to senior management, which is more strategic. On the other, we're the only management layer that works directly with the people who build the product, the developers responsible for delivery. Beyond that, as team leads in AppsFlyer R&D we wear 2 hats: we're both managers and software people. A team lead might run a small team of 2 to 3 people, and some teams have 10. That combination creates specific difficulties and challenges for us as team leads, and it's the foundation of this community.

How did the community start?

The idea for the community came from a colleague, Dror Davidi. He saw the need, reached out to people he thought could be partners in it, and I was one of them. He put together a team of 4 to 5 people, and we became the founding fathers and mothers of the community. Dror came in with a mind map of the problems team leads face, the topics a community could tackle, and how a community like this could help team leads. The second I saw it, before I'd even gotten through 10% of it, I knew there was something big here with the potential to create a ton of value, and that's where we started. The community launched in May of last year (a year and 4 months ago), but we'd been developing the idea for a few months before that. Alongside the team leads who led the community, we had support from people in the organization (representatives of HR, developer relations and L&D) who knew how to connect us to the right places in the organization to make initiatives and collaborations happen.

What is the team leads community and how does it work?

When we started, we focused on 2 things. The first was mapping the problems team leads have. The second was figuring out how to run a kick-off, so we could see whether team leads actually wanted to be part of a community like this.

Back then we didn't know how to run a kick-off or how to bring people together. We went through some really tough times in the first few months and even in the first year. But we learned a lot, much of it the hard way. Since we came in with no background, what helped us most was a lot of trial and error. We'd start with a particular experiment, run it for a few weeks or months, gather feedback, and learn what needed to change and improve.

First, we wanted to hold a kick-off and spread the word that a team leads community was on its way. It mattered to us that every team lead in development knew it was happening and could join. We also wanted to deliver value from the very first moment. For the kick-off we invited an external speaker and our CEO, who spoke and made it clear that the organization stands behind this community, that it supports and encourages it. After the kick-off there was real euphoria. It was a very successful event.

Beyond the kick-off, we opened a private Slack channel for the community so there could be ongoing communication, and we decided to work along 2 tracks:

Regular in-person community meetings. We started meeting once every 2 weeks, realized that was too often, and today we meet once a month.
We saw a community as something continuous that creates value daily or weekly, rather than a one-off. So alongside the community meetings, we also ran a kick-off for working groups. We formed the working groups after running a survey to understand which of the topics we'd raised were the most pressing for team leads at AppsFlyer. We landed on 4 working groups: a knowledge group, an onboarding group for new team leads, a group in charge of bonding, and a learning processes group.

We split people into working groups arbitrarily. We assigned team leads to groups at random and told them that if they wanted to switch, they should let us know and we'd make it happen. In hindsight, that wasn't a good decision. People weren't engaged with their assignment, so they had no motivation to explore what the other groups had to offer, and they simply stopped coming to meetings. Looking back, the right thing would have been to build that engagement, maybe hold a session that just presented the groups and let people choose.

In practice, some groups made more progress than others, and over time we wanted to narrow down to more focused activity. For example, the onboarding group joined forces with the learning group, and together they built an onboarding program for team leads at AppsFlyer. Our overarching goal is to create change, lead projects and bring them into the organization bottom-up. Our way of working is to run a pilot, see that it works well, and then bring it in officially through L&D, since the community already gives us that connection to them.

The idea behind the working groups was to delegate as much as possible. We understood that we were a leading body and didn't have the capacity to lead projects in every area ourselves. Each group started from scratch and defined the biggest pain points in its own area. Each group had to set its definition of success and work backward from there to build a plan with measurable goals. Here too we had plenty of growing pains. At first we didn't understand how we wanted to measure success. We decided we'd just start running and we'd feel it when we were succeeding, and that wasn't good enough. For example, we ran with a big project that had a lot of potential for the organization, but we had no metrics to tell us when to stop and move on to the next problem or project. At some point, after a few months of running with the groups, we realized we needed to identify each group's low-hanging fruit, harvest it, and then think about the next step. Today we're more or less there. Each group has harvested the fruits of what it achieved, and now we're thinking about what comes next.

When did you realize the community was working?

The moment I knew it was working was when we launched a mentoring program that paired mentors and mentees from within the community. For me, the big success and the big surprise was how strong the response was. This project came out of the community. No one from the organization led it, and still 16 participants signed up. We had 8 pairs, more than 30% of the community's members. The feedback was excellent too. Team leads told us it had a very meaningful impact on their day-to-day. We recently opened registration for the program's second cohort, and we're hoping to pass 20 participants.

We started the project because we felt we had a significant resource in the community that we weren't using: the community members themselves. We have very experienced team leads, and we have team leads in their first management role. We realized there could be a very strong fit if experienced team leads mentored newer ones in a safe environment, where they could vent, air challenges and frustrations, and share the everyday dilemmas they face.

Cracking the win-win: how do you make sure both the community and the organization get value?

The win for the community

Professional value and personal development, growth for team leads, sharing platforms that make day-to-day work easier, and connections and relationships between team leads.

The win for the organization

Processes that cut across teams and the organization, rollout of processes developed bottom-up, stronger team leads, better working interfaces between teams, and better communication between the execution layer and senior management.

What challenges did you face?

We had all kinds of challenges, and there were moments when we felt the community was about to fall apart. I'd guess they came mainly from not having a community expert, so we learned a lot as we went.

Creating a safe space for team leads to share. Psychological safety matters a great deal. A manager needs to feel safe sharing something they did that they might be embarrassed about, something they wish they'd done differently. In general, team leads and managers are very aware of sensitivities around employees. There are ways to share personal stories without revealing names or specific teams, so in a broader forum you can do it anonymously. At the same time, there are smaller forums where it's understood that people can open up freely, and that the information is sensitive and stays between the people in the room. One example of a smaller space like that is the "Team Lead for Team Lead" mentoring program. The mentoring takes place in a safe format, and everything said there stays within the mentoring.
Taking part is optional. On one hand, that makes things a bit harder for us, because there were periods when we didn't have momentum and didn't have many participants, or not as many as we wanted. On the other hand, it means that whoever does come is there because they want to be. I prefer not to make it mandatory, because I don't want team leads in the room who don't want to be there. I'd rather have people who want to take part and see the community's potential. On the positive side, I'm still surprised by how many people come to our in-person meetings. When we hold one and 30 to 40 people show up, that's a big part of the community giving an hour of their week, and to me that's not something to take for granted.
We had leadership challenges too. There were meetings of the community's leadership forum where only 2 or 3 people showed up and things seemed stuck. Even with challenges like people not coming to meetings, as long as the leadership forum keeps meeting, thinking and wrestling with the problem, the way I see it there's hope, because there's a group of people who really want to get this off the ground. When leadership thinned out, it surprised me, and we didn't know where things were headed. At the same time, we saw some of the working groups get stuck, and it wasn't clear what value the community was giving its members. Those were very shaky moments.

From our experience and what we learned, I want to share a few things we did that helped us get through these crises:

First, accept them with understanding. They matter. It's natural for this to happen, and instead of fighting it, accept that sometimes you're riding a wave of momentum and sometimes it's a quieter period. Beyond that, it may even be a good thing, because it helps you stop and think about what you could do differently.
From there you can get to the next point: sit down and think about why things are stuck and what's missing, and ask an important question: which assumptions are we making that we don't necessarily need to make? We carry hidden assumptions, like "every team lead wants to be part of the community." Says who? What does it depend on? Why would they want to take part? Put your heads together and ask for input, including within the community. There's no shame in going to the community and saying, "It looks like things aren't working the way we want. Help us think it through together."
A lot of trial and error. Don't make big decisions based on isolated signals that might just be noise. What worked for us was making a decision and running with it for a while without changing it. Take the meeting format, for example. Give it 3 to 5 meetings, let it run, collect feedback, and then adjust.
Also, don't fall in love with the community's ideas and initiatives. If a project isn't working, just drop it and move on to something else. You don't want to do everything. You want to do what matters to the community and creates impact. Keep in mind that the community members' time, and yours, is very precious. Cherry-pick the specific things you want to push forward.

Today we're at a very good point of balance, and we're thinking about how to take the community to its next stage.

Tips for building a successful community

Leadership support. We have full support from our managers. Everything we do in the community is voluntary. Each of us is a full-time team lead, and we do this on top of the role. The company supports people who want to take on personal projects or do things beyond their role. That's true across AppsFlyer, at the level of the organizational culture.
Patience. Things like this take time to catch on, and there's value in running consistently over time and showing the value over time. When you start something like a community inside an organization, you have X team leads. A year later you have 50% more, and the new ones join a reality where the community already exists. That's different. You need patience, and you move forward and grow with the organization.
Trial and error. Try things out with small changes and see how they're received in the community.
Listen to the community. Keep collecting feedback and adjusting accordingly.
Finally, keep thinking about how to create value for the community.
It all comes together in a single tip: build a short feedback loop, try things with the community, and be patient. Give it a chance to catch on and keep improving.