Beyond Platform Thinking at RB Global – Build Things No One Expects, in a Place No One Expects It

Introduction and Background

• The speaker has been working in the industry for a long time, as evidenced by their gray hair, and initially took a brief detour into the finance business before realizing it wasn't the right fit for them (13s).
• In the early 1990s, they raised money with friends to start one of the first ISPs in the US, which eventually became EarthLink, the largest ISP in the United States (36s).
• The speaker advises people not to be successful in their first two startups, as it can color their vision of what's to come next, and notes that they've worked in diverse industries and done a lot of consulting, including at ThoughtWorks (48s).
• The speaker was involved in the Richie Brothers journey, which was a really interesting experience, and notes that the subtitle of the talk is "Build things no one expects, in a place no one expects it" (1m19s).
• The phrase "Build things no one expects, in a place no one expects it" came up in a conversation with a group of people at ThoughtWorks about a year ago, and the speaker was trying to describe how they had reached some of the success in their career (1m27s).

Richie Brothers and its Challenges

• Richie Brothers is the largest global marketplace auction marketplace in the world for heavy equipment, agricultural equipment, and heavy trucking, and has deep relationships with customers across these industries (2m9s).
• The company's customers range from small family farms to major construction firms, and they care deeply about their customers, spending a lot of time on merchandising the equipment they sell (2m45s).
• The speaker notes that many of the people they work with from a seller perspective have built their firms as small or medium-sized businesses that are their retirement assets, and they deeply realize the importance of this (3m9s).
• The company's goal is to provide the best possible pricing and customer service to its buyers, offering professional inspections and accurate information to help them make informed investment decisions in equipment (3m38s).
• The business operates on a "white glove" and hands-on approach on both sides of the transaction, which is a positive aspect for the company (4m2s).
• Richie Brothers evolved into RB Global through acquisitions, including the purchase of Iron Planet seven to eight years ago, which helped the company expand into the digital marketplace (4m22s).
• Despite the growth, the company struggled with integrating its various systems and companies, leading to manual and inefficient processes, which they refer to as "arts and crafts" (5m17s).
• The company aims to improve its digital experience for both customers and employees, with a goal of streamlining processes and reducing the need for manual workarounds (5m53s).
• The company's digital transformation journey began two years ago, with the help of ThoughtWorks, and involved building a large digital marketplace and integrating all its companies (6m9s).
• The company discovered an "architecture perfect storm" with at least three systems for every domain, including merchandising, asset management, and billing, which created complexity and inefficiencies (6m24s).
• Each of these systems was believed to be the best solution at the time, but they were not integrated, leading to manual steps and workarounds (6m40s).
• The system had no single source of truth, and interconnectivity between systems was a major issue, with a combination of database sharing, Kafka, and Boomi used for data synchronization and propagation, but not a true event-driven architecture (6m42s).
• A Teams chat was created to address issues with auction data not propagating between systems, but it became a permanent solution, with the goal of shutting it down being a sign of success (7m28s).
• Technical misunderstandings and myths were prevalent, such as the bidder number only having five digits, with no clear reason or understanding of the consequences of changing it (8m0s).
• Changing the bidder number was thought to break the system, but it was later discovered that this was not the case, and the system was layered with puzzling workarounds (8m18s).
• Scheduling an inspection required tying it to an event, which meant an auction, but the company also ran a business inspecting equipment for companies, requiring a fake auction to be created in the system (8m37s).
• Events had IDs that were running out of space, and the team suggested getting rid of events, but the inspection service team disagreed, saying they could simply remove events, which were not necessary in the first place (9m9s).
• The system was plagued by a "cacophony of voices" with many people having different versions of the story, and a key system constructed online bids and listings by listening to five Kafka topics, hoping to synchronize them (9m52s).
• Timing issues were also a problem, with the system having trouble synchronizing data and propagating it between systems (10m18s).
• The data synchronization was a big mess, and the architecture was full of errors, but nobody wanted to point these issues out due to fear of unpopularity or insulting teams or bosses (10m33s).
• After six months of trying to understand everything, it was realized that no progress had been made, and a new approach was needed, which was to start building and then deal with issues as they arose (11m22s).

Understanding the Business Model and Architecture

• The business model was not e-commerce, but rather an online marketplace, with unique inventory that was not identical and had different values, conditions, and sources (12m8s).
• The inventory was distributed across the world, and there was no common merchandising or pricing function, making it different from e-commerce (12m48s).
• The architecture serves the business, not the other way around, and the key domains in the system needed to be identified, which included facilitating transactions between buyers and sellers (13m21s).
• At RB Global, the main function is to facilitate transactions between person A and organization B, collecting money, calculating the take, and sending the rest back to the other person, which is similar to a distribution or finance model (13m49s).
• The goal is to deliver a product by understanding the domains and not modeling something that doesn't represent the business (14m2s).
• The company was transitioning to become a product-driven company, which required a deep understanding of the business and its needs (14m17s).

Product-Driven Approach and Communication

• The product people served as a translation unit between the business and the tech teams, facilitating communication and change (14m43s).
• In a product-oriented environment, it's essential to think about the communication path between the business and teams, and how teams communicate with each other (14m56s).
• Product managers and technical product managers played a crucial role in being the interconnection point between teams and the business (15m7s).
• The goal was to keep teams isolated and focused on their domain, with product people serving as the integrated circuit pin that connected teams (15m16s).

Radical Simplicity and Focus on Business Outcomes

• Radical simplicity was a key goal, breaking down complex processes to their most simplified form (15m41s).
• It's essential to take time to think and not rush into coding, sometimes drawing and thinking about a problem before coding is necessary (16m10s).
• Taking time to think and reflect is crucial, and it's essential to question everything and politely challenge assumptions (17m13s).
• The less complicated the process, the better, and it's essential to dig into requirements and myths to simplify complex systems (17m23s).
• The goal is to achieve business outcomes with the least amount of work, not to write more lines of code, as the focus is on delivering results rather than measuring productivity by the amount of code written (17m27s).
• Valuing fast feedback is crucial, and the architecture and platform are designed to enable shipping every day, whether it's to production or internally, to get feedback and improve quickly (17m56s).

Organizing Complexity and Composable Architecture

• The concept of an "unfair competitive advantage" is discussed, referencing Gordon Murray, a famous F1 designer who used a fan on the back of an F1 car to gain an advantage, and the importance of finding and leveraging such an advantage in business (18m32s).
• Organizing complexity is key, and this involves breaking down complex systems into composable parts with clean interfaces, identifying key domains, APIs, services, and systems, and stopping data sharing by designating a single place for each function (19m40s).
• The aim is to move from a complex, interconnected system to a more organized, composable architecture that enables the creation of different experiences, whether mobile, online, or external API (20m11s).
• The importance of identifying a single place for each function, such as asset management, consignment, and invoices, and composing them to build different experiences is emphasized (20m26s).
• The goal is to achieve a composition with clean boundaries, and to retain deep knowledge, it's essential to decide whether to move things to a new platform or rebuild them, considering the time and resources available (20m42s).
• In the initial phase, the focus is on taking multiple systems and reducing them to one, which was responsible for several things, and then deciding which pieces to build an API around and which to remove (21m5s).
• It's crucial to understand the architecture and be able to explain why certain choices were made, as this is essential for securing funding and support from executives and investors (21m33s).
• The business elements of architecture involve searching for funding and justifying the continuation of complex transformations, which often fail due to a lack of executive courage and follow-through (21m43s).
• To avoid failure, it's essential to provide executives with the necessary inputs to see the value in continuing to fund the project, and to think about the roadmap, including which pieces to remove and which to keep (22m6s).

Bounding Context and Managing Change

• The concept of "bounding context" is essential in masking complexity and creating clean interfaces, and can be explained through the example of Richie Brothers' taxonomy, which organizes equipment data in a catalog (22m32s).
• The taxonomy is mostly tree-based and provides valuable information about equipment, such as dimensions, transport costs, and tax categories, which are essential for calculations and exemptions (22m48s).
• In the past, taxonomical information was distributed across the system, but with the introduction of a modern tax interface, the categories should be centralized, and the team building the tax system should have all the necessary information (23m38s).
• The taxonomy in the system is not fixed and changes over time, which can lead to changes in tax categories and require updates to multiple systems, but containing the taxonomy within the system reduces the "blast radius of change" by minimizing the need for changes to other systems (23m59s).
• The goal is to manage change effectively by identifying which domain is responsible for managing change and understanding which system and team owns that responsibility, even if it changes over time (24m51s).
• Decreasing coupling between systems and having a clean interface is important, as seen in the previous slide, to simplify interactions between systems (25m9s).

Refactoring and Simplifying Systems (Contract Service)

• A limitation was discovered in the number of items that could be put on a contract for a seller, which was found to be a system limitation rather than a business limitation, and was caused by the system bogging down when generating the contract exhibit (25m21s).
• The contracts and contract data were stored in Salesforce.com, while the asset management system, Mars, had all the contract terms and asset data, and the two systems were synchronized, causing unnecessary data transfer and computation (25m46s).
• The system was refactored to build a contract Service that generates the PDF for Salesforce, takes bidirectional updates, and provides commission rates, reducing the limitation on the number of items and simplifying the system (26m46s).
• The contract Service also reduced the hassle for the payouts system, which no longer needs to go to the monolith to find out commission rates, and instead goes to the contract Service (27m12s).
• By extracting domains and assigning the right responsibility for contracts and item association, a major barrier for customer service was broken, allowing for simpler contract management with multiple items (27m34s).

Improving Event-Based Architecture

• Event-based architecture was used to improve data synchronization, but initially, it had issues with inconsistent payloads and missing data (27m50s).
• To improve event-based architecture, it's essential to understand the model being used, keep it simple, and be consistent, thinking about the information sent as an API payload (28m20s).
• The bidding engine was sending winning bids with incomplete data, missing the currency, which caused issues with the system (28m44s).
• The system was modified to include the currency in the payload, and it was emphasized that inconsistent payloads make systems chatty and difficult to manage (29m26s).

Leveraging External Services and Building Internal Capabilities

• The company uses Stripe for payment APIs and money movement, leveraging their services to comply with rules around trust accounts in the UK, EU, and US (30m21s).
• Stripe's services were chosen over building their own due to the low rate and high fiscal compliance, demonstrating the importance of communicating choices and not rebuilding existing solutions (30m57s).
• The company built a tax calculation engine from scratch, despite the availability of off-the-shelf solutions, to help the board and leadership understand the company's needs and to communicate and negotiate with them (31m0s).
• A diagram was used to communicate the main business capabilities and domains in the system to leadership, showing what the company cares about and has built on its technology infrastructure (31m29s).

Automating Payment Processing and Checkout

• The company started its process in the middle, focusing on automating payment processing and post-payment processing, which was previously mostly manual (32m6s).
• On the Richie Brother's side, there were no online payments, and customers received invoices from a 25-year-old VBA-based system, while on the IronPlanet side, some payment processing was automated (32m10s).
• The company automated the checkout process, allowing customers to complete purchases online and pay for items, leveraging Stripe for payment options such as bank transfers and online credit card payments (32m58s).
• The manual process of figuring out what to pay out to sellers was also automated, which was important for meeting the company's payment deadlines and taking advantage of opportunities for float (33m24s).
• The company started in the middle of the process, but did it wrong, and this is an important lesson in the process, particularly when dealing with white glove service and exceptions (33m53s).

Focusing on the "Happy Path" and Accounting Integration

• The initial approach to building a workflow focused on managing exceptions, resulting in a complex process that negatively impacted the customer experience and accounting integrations (34m31s).
• The goal of automating the checkout and calculation process was to get the correct entries in the finance system, specifically Oracle Financials, which is mission-critical for automating payouts to customers (34m59s).
• The team realized they had gone off track and refocused on defining the "happy path" from winning a bid to completing the accounting process, which made building exceptions easier (35m44s).
• The team learned about anti-corruption rules in the EU, including immutable invoices, and incorporated these rules into their workflow, which helped them define a high bar for accounting and logic (35m22s).
• By defining the end goal and happy path, the team could value-check their work and ensure they were doing it correctly, which was an important lesson for future integrations (36m7s).

Building a Unified Platform and Checkout Experience

• The team's initial platform included Stripe and Thompson ERS as finance partners, as well as a Richie Brothers Legacy website and an Iron Planet website, which they eventually replaced with a new standalone checkout experience and account management experience (36m53s).
• The team added mobile to their checkout app, but it would have been better to integrate it into the existing app rather than building a standalone experience (37m11s).
• The team's goal was to achieve radical simplicity by enabling a transaction from Tom to Fred, keeping the money in between, and accounting for everything properly (36m37s).
• The existing app was built on a 20-year-old unstable platform with a complex "spaghetti data flow" that made it difficult to work with, so standalone pieces and core capabilities were built around contract management, settlement, and invoicing to make the checkout work successfully (37m17s).
• A unified new modern website for RB Global was built, replacing the old 20-year-old LifeRay platform with bad microservices in Java, and is now in a new modern stack with less interference in data transactions (37m51s).

Integrating IronPlanet and Future Roadmap

• The new checkout system is being released, and the next task is to integrate IronPlanet with Ritchie Brothers by combining their sales processes into the new platform, which requires changes to consignment, asset tracking, and other processes (38m21s).
• The integration will modify or replace existing processes and systems, but understanding domain boundaries and architecture will make it easier to move away from the old monolith and into the new platform (38m57s).
• The architecture allows for incremental migration, and a test suite can be used to ensure that changes work as expected, making delivery of concepts easier (39m17s).

Engineering Enablement and Delivery Infrastructure

• Delivery infrastructure and tooling were built around engineering enablement, including a productized delivery platform on Kubernetes, to simplify the process for developers and reduce the need for knowledge about complex technologies (39m54s).
• The goal is to build well-factored APIs and use Kubernetes APIs to make it easier for developers to work with the platform, wrapping up deep knowledge to make it simpler for others (40m11s).
• At Richie Brothers, engineers can easily provision services like Dynamo DB by adding a few entries to their Helm chart, without needing to learn Cloud APIs for Azure or AWS, thanks to the use of Kubernetes tools such as Mission controllers and operators (40m31s).
• The company has built a deep knowledge of these tools into simple APIs, making engineers more effective and allowing teams to go from formation to shipping to production in under an hour (40m58s).

Prioritizing Joy and Investing in Engineers

• Engineers are treated as a competitive advantage, and the company focuses on investing in its own organization, including providing training for employees to learn new ways of working (41m33s).
• The company prioritizes joy as a metric, rather than productivity, with the goal of creating opportunities for engineers to have joy every day from delivering work (41m48s).
• The company's engineering leaders are encouraged to prioritize getting work out the door quickly, rather than waiting for perfection, to avoid frustrating engineers and to get their work seen in the marketplace (42m18s).
• When partnering with development partners, the company looks for partners who can create or uplift the environment, rather than just providing more hands-on keyboard, and prioritizes partners who share similar goals, culture, and values (42m43s).

Partnering and Mentoring

• Mentoring is also seen as important when partnering with external experts, to ensure that knowledge and skills are transferred to internal employees and to avoid being left with nothing when the partner leaves (43m25s).
• The company has a team-based approach where partners are included as part of the team, and everyone is considered part of the same family, whether they work on legacy systems or new projects (43m36s).
• In the past, there was a distinction between the "cool kids" who worked on transformation projects and those who worked on legacy systems, but this distinction has been eliminated, and everyone is expected to contribute to both (43m55s).
• The company has a lot of existing systems, referred to as "pets," that need to be maintained, and everyone is expected to take turns caring for these systems, as well as working on new projects (44m5s).

Transformation Journey and Capability Platform

• The company's transformation journey involves building a capability platform, and the goal is to create a system that can be used in multiple ways, providing multiple returns on investment (45m25s).
• One sign of success is when people across the organization start using the same language and concepts, such as the "provisioning domain" or "Consignment domain," and applying them in new ways (45m31s).
• Another sign of success is when business owners start speaking in the same language as the technology team, indicating that the transformational knowledge is being adopted across the organization (45m50s).
• The company is working to shift from a project-based approach to a product-based approach, which is a challenging but important part of the transformation journey (46m8s).
• The transformation effort, referred to as "RB 2.0," is not a project that will end, but rather an ongoing effort to change the way the company approaches technology and uses it to drive business value (46m18s).
• When working on a project, it's essential to fund it properly and not back away from the challenges, as this can lead to legacy software and the need to revisit the same issues in the future (46m50s).

Final Thoughts and Key Takeaways

• It's crucial to set aside time to think and reflect, allowing yourself to stare out the window and consider new ideas and perspectives (47m20s).
• It's essential to differentiate between action and results, as activity doesn't always translate to outcomes (47m40s).
• Architecture is about tension, and it's necessary to balance slowing down and speeding up, making decisions quickly when faced with uncertainty (47m55s).
• When faced with a decision, it's essential to take action and make a choice, rather than getting stuck in indecision (48m7s).
• Digital disruptors are coming for the industry, and it's necessary to be able to experiment quickly and stay ahead by building a good architecture (48m26s).
• It's essential to remove friction from the value stream, thinking deeply about what blocks the process from ideation to delivery, and working with business leaders to understand the impact on the business (48m42s).
• Everyone can be a servant leader, regardless of position, and it's essential to educate the business about value stream management and processes (49m7s).
• The principles of value stream management and servant leadership can be applied to all areas of the business, not just engineering (49m11s).