By Ernst van Rensburg, Head of Engineering at Peach Payments

As a developer-turned-manager, my focus has changed from solving coding problems to solving people and business problems. These days, I measure my success based on our teams doing meaningful things and customers loving the product.

In the process, I have come to realise the absolute necessity of cultivating a learning culture. Our clients are mainly retailers, who don’t care whether their customers use a credit card, EFT, rewards or cash on delivery. What they care about is the success rate generated by the triangle of the payment gateway (such as Peach Payments), the merchant bank and themselves. In other words, can they accept payment and sell their product?

We work with innovative retailers – think SweepSouth, Netflorist, Pargo, and OneDayOnly – and technology (such as WooCommerce, Wix, Shopify, and Magento ), so continuous learning and personal development are central to what we do. On top of that, my teams need to be able to work on everything from subscription models to one-click payments, mobile integrations, and gig-economy payment solutions that currently process more than R1-billion a month.

The knowledge-gap problem

Most online shoppers do not realise they’re using one of our products, because payment solutions are the roads and the highways that others drive their trucks and build their businesses on. In 2020, Peach Payments saw a 400% increase in customer acquisition and revenue growth of 130%. There is no way my teams, which are responsible for integrating our payment gateway into whatever requirement a retailer has, could have done this without learning from one another.

I needed to create a framework to allow my new team members to get up to speed fast. We need an engineering team that has to be very diverse in how they approach problems, so the team members are from a vast array of places, speak different languages, and focus on different aspects of technology. We started to notice a lot of conflict and challenges, and it took a long time for individuals to understand the way we build software.

Our products are complex and our technologies are also quite obscure, with few online resources to self-learn. This meant it could take new recruits three to four months to start learning what we’re doing, and six months to start actively contributing, which is a long period to onboard someone. It was a real challenge for us, as most people remain in a position for between three and six years (if it’s a good company), meaning taking six months to learn how to contribute was too long.

The learning solution

In response, we came up with a programme that engineering managers can use to measure how we are learning and how that increase in learning is helping people to join, become immediately effective and have a long-term impact on how long they stay.

We started looking at the indicators that teams are actively learning, and actively sharing what they were learning with their team members and other teams in the engineering group.

We noticed some teams were learning faster than others and that their portfolios were better configured for learning. Conversely, we identified that the obscurity of some of the technologies we work with and the lack of self-learning resources were slowing down learning in other teams. A key finding was that teams that communicated well delivered better results. In addition, teams that made learning a part of every bit of work they did, and asked more and better questions, had better results.

What we learnt about learning

In the process, we learnt that teams could not just copy what another team had done to achieve this culture of learning. They could take inspiration from other teams, but had to understand their very specific work context to foster a learning culture.

We found that those team members who learnt three main contexts early on in their tenure did the best. Those three contexts are:

1. The business logic behind Peach Payments  – the core intellectual property behind what we do and how that translates into systems and processes,
2. The political context – the lines of communication, who is responsible for what, and the rules of engagement, and
3. The strategic context of our work – why we do things in a certain way, our roadmaps and the planned future state of our codebase.

We then focused on helping each team member to become masters in their field. This relies on them being aware of a further three contexts, namely:

1. Tooling – The specific tools they have to work with, including the integrated development environment (IDE), our frameworks, languages, best practices, standards and processes.
2. Analytical – The algorithms that bridge the understanding gap between requirement and functional capability.
3. System dependencies – An understanding of what the specific system they’re working on relies on and what the contracts between the systems are. They also need to know how many of these interactions exist and what their constraints are.

But how does one measure if these are working well in teams?

How to measure a learning culture

We came up with six indicators that our teams have a learning culture:

1. Quality of messages – What is being said? How much detail is given? How digestible is this to new folks? What do you believe in? What are you trying to achieve? Does everyone in the organisation know these top three things? If not, why not? Who does?
2. The state of communication – What is the frequency of questions? From whom? How comfortable is the team with feedback? How often is feedback given? Can teams communicate outside of their domain? How much bureaucracy lives between teams? Do you need to go through individuals or tools?
3. Failure tolerance – If you fail, what happens? Are failures blameless? Where is the line? Are problems looked at holistically? What does accountability look like? When was the last bug/downtime? What did the post mortem look like?
4. Sharing of ideas – How frequently are ideas being shared? How are ideas treated? Are they instantly shot down? Buried in a backlog? Actively talked about? How are ideas showcased? How are idea creators treated when sharing ideas?
5. Team interactions – How long till the new person can make their first meaningful contribution? How are expectations managed? By whom? Do they have autonomy? How much of a vacuum is there? What is the state of the documentation and resources? How long till the team becomes dependent on the new person?
6. Time, space and resources – What is the percentage of time dedicated to intentional learning? What does this look like at the different stages of your journey? Are you comfortable spending time learning? Does this disappear over time? Is learning tied to remuneration? How could this affect the learning process?

Entrenching a learning culture in our teams is an ongoing process, and critical to all of it is that we learn from each other. In an environment where tech skills are increasingly rare, businesses that can attract, develop and retain these key skills will have a competitive edge.