Diversity is important. In a fast-paced scale-up, it’s a goal that can be easy to forget about. However, this is exactly the right time to think about diversity. At N26, the iOS engineering team has been thinking about how we can increase our diversity, improve our culture and enjoy the benefits of different perspectives. Here we will share our motivation and our actions towards creating a more diverse team.
The iOS engineering team at N26 is internationally diverse — as of this writing, our team members hail from 12 different countries. However, aside from heritage and language, we lack diversity in other areas. For example, only 10% of our team is currently non-male.
Early this year, during a question and answer session with our Head of Engineering, I asked about how he is improving gender diversity at N26. This lead to a constructive follow-up conversation about different aspects of diversity. Most importantly, he reversed the premise, and asked a more interesting question; “how can you improve gender diversity at N26?” We agreed that iOS engineers focussing on our team’s gender diversity was a great way to make an impact.
He reversed the premise, and asked a more interesting question; “how can you improve gender diversity at N26?”
This lead to the formation of an iOS-diversity working group focussed on increasing diversity within our team. We agreed on a few early initiatives:
- Ensure that our job descriptions are as inclusive as possible
- Use gender neutral terms during candidate communication
- Adapt our hiring process to be more flexible for people with limited time or availability
- Clarify our onboarding processes to share reasonable expectations
- Improve our team culture to support different communication styles
- Increase awareness and training for underrepresented groups
We will focus on the latter two topics (team culture and training) in this post.
On the topic of culture, we helped the team to understand how changing our communication can help people feel welcome and included. During an iOS team offsite we held a retrospective focussed on communication. We were happy to find that there was a lot of consensus. With the advice from an experienced agile coach, we separated topics into What I want to do & What I would like the group to do. The actual results are shown here (with permission from the team):
This was a great starting point and highlighted how people communicate differently (Respect Silence), while ideas like Keep Calm and Hear Others’ Voices were shared by many team members. This simple activity helped everyone understand that loud, passionate debate is not a productive way to discuss team issues. Not only were we forgetting to make space for everyone, some people even felt disinclined to share their opinions due to the heightened tone. Even more interestingly, simply holding the retrospective helped the team to reflect and communicate more calmly and respectfully for the remainder of the offsite.
…loud, passionate debate is not a productive way to discuss team issues.
Positive communication requires constant practice. We added the item ‘Communication Styles’ to our regular iOS offsite agenda and dedicate 30 minutes or so to topics such as:
- Active Listening
- Explaining new concepts
- Democratising debate (round robin, speaking token, wait 3 seconds)
- Experts listening first
This exercise was hugely beneficial for the team. We noticed that we improved at discussing technical issues without descending into subjective arguments. We were also able to increase the number of voices participating in our conversations. We would recommend any team to regularly perform exercises that keep their communication open and welcoming.
If a team already has a culture that promotes everyone’s voices, new team members will immediately be able to contribute irrespective of their background or experience.
With respect to increasing awareness and training for underrepresented groups we decided to focus on teaching iOS to existing software developers. Teaching programming fundamentals or encouraging software development in school would definitely help, but we chose to move further down the funnel and focus on our specific problem of low gender diversity in the Berlin iOS community.
We discussed how we could make the biggest impact and came up with a plan to run a public workshop series for teaching introductory iOS skills. We could use our passion and expertise in the platform to encourage existing software developers to consider switching to iOS. If we could get a handful of developers from underrepresented groups to move towards iOS development, the community would benefit, and hopefully one day they might choose to work with their favourite teachers.
Our first consideration was how to find a diverse audience. What was the best way to find software developers from underrepresented groups in Berlin? Luckily for us, we found the answer within N26 itself. Amber, One of our frontend engineers is an organiser of Berlin’s codebar events. She agreed to help out with promoting and planning our workshop series. Without Amber’s help our hard work may not have paid off — a huge thanks to codebar and their wonderfully diverse membership!
What was the best way to find software developers from underrepresented groups in Berlin?
Once we were confident about finding an audience, myself and another iOS developer, Lucas, set about writing tutorials for our workshops. We wanted to tailor the content so that we could avoid unnecessarily complex topics, and also highlight some of the platform features that make iOS development such a delight. We decided to make the tutorials publicly available so that attendees could go back and revise steps in their own time.
We created tutorials to guide someone in creating their first app — a simple news reader that downloads articles from the internet, with a few sprinkles of delight.
Preparing the tutorials took a lot longer than anticipated. Writing the sample code, documenting the steps, creating screenshots and gifs took us at least 6 hours (combined) for each tutorial. If you’re planning your own workshops, we’d be delighted for you to reuse/fork/add pull requests to the tutorials we created.
We decided to run each workshop internally as a beta before launching our public workshop series. Fortunately we had a good number of non iOS developers and quality engineers at N26 keen to learn new skills. The beta workshops not only revealed bugs in the tutorial content, they also helped us prepare for issues with different Mac configurations, highlighted confusing iOS concepts, and allowed us to practice our teaching banter. Critically, they showed us what to trim from the longer tutorials too. A huge thanks to our willing beta workshoppers!
With our workshops ready for public consumption we had help from various teams behind the scenes. We contacted security and office management to ensure we prepared properly for external visitors participating onsite. Tech ops helped us with microphones, guest wifi and projectors. Finally events and communications supported us with setting up, merchandise (stickers, pens, mugs), some lovely tweets and a photographer to capture the first workshop. Note: We explicitly asked attendees for their permission to take and use photographs.
We advertised exclusively through codebar and were thrilled to fill our workshop places within a matter of days. We were genuinely excited getting the teaching space ready and preparing for our eager students!
The two hour workshops (four in the series) were an enjoyable combination of networking, eating and drinking, learning, and sharing. We had plenty of willing iOS team members volunteer as tutors and Lucas and I acted as teachers. The tutors were essential in helping participants deal with small issues and bugs. As teachers we tried to have fun, and not to assume any prior knowledge. It was challenging to move at the right pace as we had attendees with varying skill levels. We endeavoured to move slower, assuming that more advanced developers could play around in Xcode while waiting. Again, thanks to our beta sessions we had a good idea of how much content we could realistically cover in the time frame.
As teachers we tried to have fun, and not to assume any prior knowledge.
At the end of each session we recapped what we learnt. We also shared our love and enthusiasm for the iOS platform, explaining why we enjoy developing mobile apps in particular. As a teacher it was particularly rewarding to see new developers discovering iOS for the first time and bringing their first app to life.
We had great continuity with most students attending all workshops. At the end of the series we presented each attendee with a certificate and pointed them towards further iOS resources.
Our learnings from this experience:
- Writing detailed tutorials takes a lot of time
- Finding the right audience is key for public events (thanks codebar!)
- If you can, beta test your workshop content
- Prefer a slower pace when teaching a group with varied experience levels
- Have as many expert tutors as possible when teaching
- Ask permission for any photographs/social media
- Organising a public event is a great way to get to know different teams in your company
We are proud of our contribution to Berlin’s iOS community. We don’t yet have a heart-warming success story of gender diversity within our team, but we are definitely moving in the right direction.
We encourage you to think about how you can improve diversity within the iOS community in your city, your company, your team.
Interested in joining one of our teams as we grow?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at some of the roles we’re looking for here.