By Ruberto Paulo, 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 culture of learning. 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.
Our products are complex and our technologies are also quite obscure, with few online resources to self-learn.
This means it can 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
I needed to create a framework to allow my new team members to get up to speed fast. 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 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 refining our process, we learnt that teams can’t 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 culture of learning.
We found that those team members who learnt three things early on did the best:
The business logic behind Peach Payments – the core intellectual property behind what we do and how that translates into systems and processes,
The political context – the lines of communication, who is responsible for what, and the rules of engagement, and
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:
Tooling – The specific tools they have to work with, including the integrated development environment (IDE), our frameworks, languages, best practices, standards and processes.
Analytical – The algorithms that bridge the understanding gap between requirement and functional capability.
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 do you measure if these are working well in teams?
We came up with six indicators:
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?
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?
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?
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?
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?
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 learning from each other.
Additionally, we need an engineering team that is very diverse in how they approach problems. So we work to ensure our team members are from a vast array of places, speak different languages, and focus on different aspects of technology.
In an environment where tech skills are increasingly rare, businesses that can attract, develop and retain these key skills will have a competitive edge.