Operating Rhythm, #1: Russell Martin CTO of Weel

Weel's Playbook for Planning, Product Development, and Engineering Excellence

‘Operating Rhythm’ is a short series where I interview leaders from some of Australia’s prominent startups to provide an inside look at their product and engineering processes that have been critical to their success.

For my first post of Operating Rhythm I had the opportunity to sit down with Russell Martin, the Chief Technology Officer and co-founder of Weel, a Sydney-based fintech startup with an ambition: "To become the epicentre for how every business manages and spends money."

Since its inception in 2017, Weel has been on an impressive trajectory, consistently doubling its revenue. In December 2022, the company's success was recognised with a $20 million funding round.

In this interview, Russell shares insights into how Weel's history and openness to experimentation have shaped the company's current operations. In particular, he overviews Weel's distinct approaches to planning, engineering process improvement, and quality assurance - all critical factors behind the startup's success.

Russell, what are the top three things you'd attribute Weel's success to?

1. Customer Focus 

At the core of Weel's growth has been an unwavering focus on our customers. My co-founder Dan and I learned the importance of customer centricity in Westpac’s Innovation Team. There we gained a valuable understanding of deeply understanding our target users and applying frameworks, like Jobs to Be Done, to uncover their underlying needs

This customer focus is reflected in Weel's journey. As a business, we pivoted twice - both stemming from listening to customers and understanding why we didn't have product-market fit. We've maintained that customer-centric approach throughout the six plus years we've been running the company.

2. Relentlessness 

Grit and a never-give-up attitude have been critical as well. The startup journey is undoubtedly filled with ups and downs, and there were plenty of moments that could have sidelined us as a company. But we always came back stronger, building on those experiences. In the darkest hours, having that relentless spirit - whether it was figuring out how to raise money, pivot the product, or do whatever it took - was vital.

3. Timing and Luck

The final key factor, which is often underestimated, is timing and luck. There's a great saying: 'Would you back good founders in a bad market or bad founders in a good market?' In my experience, the answer is the latter, as the market is a force you want in your favour. If you can start your company when the market is primed and ready for your solution, with investor money available to build the necessary technology, that's incredibly important. We never lose sight of the good fortune we've had - it keeps us grounded.

How does Weel plan, and how has this evolved over time?

Weel's approach to planning has evolved considerably as the company has scaled. When we were just starting out, it was almost entirely based on Dan and I. We’d assess the key objectives, then based on our insights from customers and the market set the course. 

But as Weel has matured, we've implemented a more robust, multi-faceted planning process. It now begins with a top-down review, where Dan and I evaluate the company's vision and chart the critical priorities for the year ahead. Maintaining our commitment to double revenue annually is a non-negotiable that informs many of these high-level targets.

We then take that strategic framework and work with our leadership team to build more granular, bottom-up plans at the functional and departmental levels. This is a collaborative process where we carefully assess the feasibility of each team's targets, ensure cross-functional alignment, and identify any potential roadblocks.

Execution of these plans is then managed on a quarterly cadence. We have formal check-ins with each team to monitor progress, identify learnings, and determine if any course corrections are needed.

One area we've focused on improving is injecting a healthy dose of realism into our planning. Startups are naturally prone to optimism - which is necessary as they often have to take on near impossible tasks, but it can also make it challenging to set achievable milestones. So we've worked hard to refine our planning process, breaking down bigger goals into more realistic, incremental steps. We've even found that this approach has improved our momentum, which has been a large factor in maintaining morale and staying on track, even as the business has scaled.

How does Weel tackle tech debt and process optimisation?

As a CTO, the challenge of managing technical debt and driving process optimisation is always top of mind. It's a delicate balance - one that often reflects a company's underlying values, culture, and internal dynamics

Over the last 7 years we’ve experimented with a variety of methods to deal with tech debt. In the early days, we did what most startups do - prioritise speed over everything to race towards finding product-market fit. This approach was validated through our two pivots, where we effectively threw out everything, including thousands of lines of code. 

Once we found product-market fit and earned the right to build this properly, the speed-over-everything approach became unsustainable. The main issue is it becomes difficult to ship things consistently because you uncover this 'spaghetti mess' you have to untangle before adding value.

As a financial services product, quality is #1 - accuracy and customer trust is critical. So we are constantly thinking: how do we maintain that quality, but also add pace? How do we simplify processes without sacrificing quality? We call this approach ‘Quality at Pace’.

An example of quality at pace is how we built out rigorous testing and QA processes that are complemented with "self-QA." In this model, engineers take on the responsibility of testing their own work before being reviewed by QA. This has dramatically improved throughput as it means that by the time code reaches QA, 90% of the major issues have already been resolved.

We've also championed initiatives like trunk-based development and preview environments to speed up our delivery cadence, without compromising that quality standard. It's an ongoing balancing act, for sure. But by keeping those twin imperatives of quality and pace at the forefront, we've been able to continually improve velocity without compromising quality. 

Tactical Q: One thing I've struggled with is maintaining a ready and prioritised tech debt backlog. How do you do this at Weel?

The primary responsibility for owning and managing our tech debt backlog falls on our Head of Engineering. They're in constant dialogue with our engineers, staying attuned to what's slowing them down and reviewing the latest technology landscape.

Operationally we have found the most effective means of addressing tech debt is by allocating 10% of each sprint's capacity to work on tech debt. This ensures it doesn't get deprioritised in favour of more visible product features. It also allows us to measure our performance against these tech debt goals.

That said, we have encountered some challenges around conflicting priorities between our product managers and engineers when it comes to tech debt. While PMs understand the value of reducing technical debt to drive long-term velocity, their performance is still primarily measured by shipping customer-facing features.

To help address this, we've recently experimented with separating the roles of product manager and Scrum Master. Historically, our PMs also served as Scrum Masters for their teams - which made sense in the early days when we just wanted engineers churning out code.

But as Weel has scaled, we've found that this dual role creates challenges. Product managers end up having to sacrifice valuable customer conversations and strategic planning time to focus on the day-to-day sprint delivery mechanics.

So we've now introduced the role of a dedicated Tech Lead who acts as the Scrum Master, responsible for sprint planning, delivery commitments, and day-to-day process management. This frees up our product managers to focus more on the customer-centric, discovery-driven aspects of their role - which has had a positive impact on our ability to balance product innovation with tech debt reduction.

What does Weel's full product development, engineering and design review process look like?

We're currently optimising our product development process, so I'll explain what we are aiming to achieve, even though all the aspects are not yet fully implemented. Inspired by the work of Marty Cagan, the way we currently think about our product process is through the lens of two streams: Discovery and Delivery.

The Discovery phase is all about deeply understanding our customers' problems and rapidly validating proposed solutions. We're fortunate to have plenty of customer feedback coming through our sales team, in-product NPS scores, and direct user reviews. We've also built robust processes to capture and codify all of that invaluable input.

From there, the goal is to validate these customer insights and ideas as efficiently as possible. In the past, this often involved building prototypes. But more recently, we've gotten better at using more lightweight, codeless methods to test our hypotheses.

Once we've successfully validated a solution concept, we then transition into the Delivery stream. This is where we fully scope the end-to-end technical architecture with our engineering team, and then build it out in two-week sprint cycles. Throughout this process, our testing and QA protocols come into play.

The final step is a comprehensive design review, where we ensure the end product aligns with our UX standards and brand guidelines. But the reality is, our designers are closely involved throughout the entire Delivery process, frequently collaborating with engineers to refine the solution.

It's an iterative process - one that we're currently working to accelerate even further. We currently ship updates once a week, but our goal is get to 2 or 3 times per week, while still preserving the quality and rigour of our overall product development approach.

What are the key artefacts that come out of the Discovery and Delivery phases?

The two core artefacts that evolve and take shape throughout our Discovery and Delivery processes are the Product Requirements Document (PRD) and the Technical Architecture Document.

The PRD is where our product managers distil all the insights and learnings from the Discovery phase into a comprehensive, high-level solution overview. This document serves as the blueprint for what we intend to build, capturing the key customer problems, proposed features, and the intended business impact.

Once the Discovery work is complete and the PRD is drafted, we have a checkpoint to assess whether we have final stakeholder approval to proceed with that initiative. Typically, if a solution has progressed to the PRD stage, it's already gone through our roadmap prioritisation process. So it's rare for a project to get blocked at this point, unless we identify major risks or misalignments. 

One recent example where this occurred was an idea to leverage a third-party API as part of the solution. But as we reviewed the results of our experiments, it became clear that there were shortcomings in the third-party offering that wouldn't fully solve the underlying customer pain points. So we made the call to not move forward with that particular approach.

Once the solution is approved and the PRD defined the technical team develops a detailed Technical Architecture Document. This is where the tech engineering lead works closely with their squad and broader engineering leadership to define the full technical solution and approach.

This document then goes through a similar review process with myself and the Head of Engineering. The focus here is less on approving or blocking the project, and more on critiquing the technical architecture to ensure it's the most optimal and efficient way to deliver the proposed solution

One area we're actively working to improve is our ability to quantify the potential commercial impact of the solutions we're building. Currently, we rely heavily on intuition to connect customer problems to potential value and growth opportunities. But we want to develop more rigorous modelling and forecasting capabilities to better compare competing initiatives.

We are currently working with our finance team who are skilled at modelling and forecasting to build this muscle into our process. The goal is to be able to attach clear, data-driven projections of the commercial upside to every major product initiative we pursue.

Tactical Q: What is Weel’s product development stack?

• Wiki: Confluence

• Issue Tracker: Jira

• Developer Code Repository: GitHub

• Communication preference: Slack

• Tactical Q:: Figma

Thank you, Russell! You can follow Russell on LinkedIn.