The Concept: the Inverse-Advocacy Process
Most enterprise decisions are based on the status quo and existing staff experience levels—which in an enterprise usually includes 1-2 technologies over a 5-6 year period—and a consensus of well-meaning people listening to each other. However, to make a transformation happen, decisions must be faster, more pragmatic, and based on the end-state outcome necessary for the business. It’s why Rangle does frontend on frontend cloud, and nothing else. It’s why our architect to developer ratio is 1:3. Our teams make the right decisions based on ten years of modern frontend and customer-experience centric delivery models. As soon as you staff developers and not experienced teams, that goes away as each individual doesn’t have the confidence, support or experience to navigate the status quo.
But even then, decisions have to span a larger footprint of a large organization. And to move beyond “Rangle’s opinion” which may be seen as being driven by vendor incentives, we would like to make the following suggestion.
We recommend inverting the decision-making process and starting with industry best practices by default. If someone wants to use the status quo instead of industry best practices, they must justify that decision and bear the responsibility of proving why the status quo is a better choice in that particular situation.
To paraphrase JFK, “Ask not what this platform can do for me, but ask what I can do for this platform.”
This approach enables delivering the right foundation and informs the process of effectively getting from product to platform in a business-friendly time-frame.
The Importance of Clear Decision-Making and Commitment
The absence of a clear "decide and commit" approach may lead to team members feeling overlooked or misunderstanding the decision-making principles. This situation can result in continuous restarts and misaligned actions, which hinder progress and may even derail the project. Consequently, more time is wasted on insignificant tasks rather than addressing the project's core issues.
Teams that struggle with decision-making or problem-solving often resort to excessive planning, which further slows down the entire process. A modern digital reference model should be founded on functional software and a collaborative team effort.
In other words, it is crucial to understand that your organization might not be more intelligent than the market. However, your unique processes can make a difference.
The Core Decision-Making Rubric (Industry best practices by default)
While this decision-making rubric may be overly prescriptive in some cases, we recommend starting with a tentative plan, placing the burden on those who advocate for the status quo or cutting-edge solutions to justify their positions. It is essential to involve domain experts from various applications in the final decision-making process.
Based on a substantial sample size of validated best practices, the following decisions are recommended for your digital transformation project:
- Frontend cloud: When aiming to succeed in the experience economy with a digital-first, customer-centric approach, gaining a competitive advantage requires leveraging a modern frontend cloud. Choose from Figma, React/Next.js, Vercel, Angular, or Vue, and a headless CMS, depending on your use case. Most enterprises are so far away from being an elite digital-first organization, any compromises on what is a de facto best-practice could leave them years behind the competition.
- Decouple the customer experience (CX) using GraphQL for existing systems slow to change, and tRPC or React Server Components without GraphQL for net new platforms and for wrapping GraphQL for older systems. Next.js + React Server Components have build in “Backend for Frontend” that allows microservices to optimize for performance, capability and state management, while the frontend team can handle non-state scenarios, drastically reducing friction across frontend and backend teams and significantly improving team velocity in a way that GraphQL only hoped to do.
- Develop a Design System that includes CSS supporting server components and compiling in the toolchain. We strongly recommend Tailwind and shadcn/Radix and using a Design System Meta-Framework, Radius 3.0.
- Implement a monorepo for your product-to-platform transition. In any core platform development, you are changing software in service to your customer and your future customer-centric platform. Optimizing for internal future processes based on the assumption that you will have built the right abstractions to span all facets of your experience-layer is a mistake.. Forcing collaboration across teams rather than in code will drive a much slower development process and incur significant technical debt due to the collaboration friction. Rather, treat the design system, platform, and product as effectively one codebase for 6-12 months. Applying dependency management to separate them might be counterproductive when aiming for rapid evolution to platform-level outcomes. Once the platform reaches 80% completion and two products are fully onboarded, you can separate them as needed, but modern monorepos make that unlikely.
The Inverse-Advocacy Process in Action
By requiring team members to invest time and effort in making a case for their preferences or any deviation from best practices, this method fosters well-informed decisions and encourages a more critical evaluation of established norms. Encourage them to research and present their arguments in writing, followed by a read-through with experts on the core modern platform.
Decisions for features that are often unnecessary
Micro-frontends
Teams frequently consider implementing micro-frontends to align them with microservices. However, frontend experiences tend to have more cross-cutting concerns—updating product affects all parts of the interface. There is no natural division of the application into micro-frontends. Microservices, on the other hand, focus on narrow transactional services and are easier to isolate.
The only practical reasons for micro-frontends are legacy technology that can’t easily be built with new functionality you are building, or organizational barriers that can’t be overcome. Team autonomy and speed is true for microservices, but not micro-frontends.
Micro-frontends are generally for legacy code and operating models—useful when there is a clear problem to be solved with either. Outside of that, they incur significant overhead in architecture and collaboration, and will be a key factor in accumulating technical debt and more costly development. If the problem they are solving isn’t articulately clear and irrefutably, they are a risky choice.
Off-the-shelf Design Systems
For digital businesses or those concerned with digital scalability, we highly recommend NOT using off-the-shelf design systems and instead utilizing headless components and modern compiler-oriented CSS tools, such as Tailwind. shadcn, Radix, or the Panda ecosystem all provide a fantastic foundation for design systems without getting trapped in someone else’s ecosystem or upgrade path. The effort to understand, extend, and upgrade off-the-shelf design systems is almost always more effort in the long run. 2023 and 2024 were the year of Tailwind, Radix and shadcn, and we lean strongly to those—even releasing a Design System Meta-Framework built around them. Build your custom design system around headless technologies, and add a few 3rd party components that are of extremely high value (e.g. grids).
Switching your teams’ languages
For example, transitioning from Angular to React should be based on your team's comfort level with the language and your current codebase. Contemplate making a switch only if there is a significant benefit in the new language ecosystem for addressing your specific challenges or if the local talent market favours the new language.
CSS Flavours
Engaging in endless debates about CSS strategy is not particularly productive. Instead, choose a modern approach that supports accessibility, server-side components, and compiling to CSS. Tailwind has proven to be extremely effective for speed and maintainability and is generally a good foundational choice. A Design System that allows composition of features from components, not styling of features, is also strongly recommended (see above).
Alternative Decision Considerations for Objection Handling
Vercel/Frontend Cloud
A common objection to adopting a frontend cloud is that "We have our own DevOps and deployment system."
Response: To achieve elite performance from teams, elite DevOps and Production agility are essential. Elite SEO and market performance require elite production systems (deployment, performance, observability, and monitoring—any friction that puts you on your back heels moves you further away from the customer). Elite conversion relies on elite performance enabled by continuous learning, personalization, and metrics against goals broken down into hypotheses. Elite customer-experience (for those that want to be in Forresters’ 3% of companies customer-obsessed) requires iterating internally AND iterating in production (to which the status quo screams “hell no!” with a long list of reasons that are immediately solvable in a turnkey manner with Vercel).
It's worth considering sticking with your existing system if it can deliver these results. However, keep in mind that not having the next optimization and the one after that may impact revenue, costs, and risk. And you are probably not considering the friction and the second and third-order impact of not having frictionless digital operations.
GraphQL
Most modern frontend applications rely on a domain information model consisting of key-value pairs, which is what the frontend needs. The services that return information and their mechanisms are typically not relevant to the frontend. By abstracting the backend behind one or two API endpoints (maybe one fast and one slow for hydrating complex datasets with complex queries and optimizing caching), you create a simple product contract that API teams can work with. If your GraphQL instance uses a language your frontend team understands, they can become "stack-and-a-half" developers who can modify the graph configuration in the GraphQL layer.
As mentioned above, the problems solved by GraphQL are solved well by other frontend technologies now such as tRPC and React Server Components. However, GraphQL can still be powerful as a layer over legacy systems as it lets you work on the frontend concurrently with the backend instead of being blocked by it. But in a new modern platform you are probably better off moving GraphQL behind tRPC or React Server Components which provide a more effective modern frontend services layer.
Design System
If you don’t do a design system:
- Design is twice as expensive.
- Development is twice as expensive.
- Experience velocity is ½ what it could be.
- Experiences are not validated fast enough or clearly enough to inform design and feature product roadmap priorities.
- Customers are confused by inconsistency across products and channels.
- You reimplement the same features in multiple products.
- Most systems have to be rewritten to be rebranded.
- You end up competing in a market with a system that looks 20 years old, or that can’t represent modern UX practices.
- And… you implement a design system anyway, except now it’s an expensive set of extensions to someone else’s design system, and it's implicit, hard to maintain, and slows down both design and development.
Monorepo
Objections to a monorepo approach are the challenges around code ownership, dependency management, managing complexity at scale, and the need for specialized tooling, which may not be necessary with a polyrepo approach.
Responses:
- Dependency Management: You are doing dependency management without a monorepo—you are just doing it in endless meetings, slow release cycles, and lots of integration issues when releasing dependencies through the organization. Think of this as technical dependency debt, and it's the biggest hurdle to efficiency in large organizations. Monorepos are like cleaning your house as you go versus a 8 hr marathon right before Christmas visitors.
- Improved collaboration and visibility: We recommend sharing access across the platform, design system, and one product initially, as these teams need to collaborate closely. The main consideration is managing access when scaling to a large set of product teams.
- Stability and Risk: Using a monorepo promotes accountability and reduces technical debt. It also allows for the implementation of elite DevOps metrics.
- Future Evolution: Modern monorepos offer some traditional access control and security. However, if a monorepo isn't sufficient for collaboration at scale, consider transitioning to a polyrepo once the platform, platform mechanics, and ways of working are stable.
Why this rubric leads to better decision-making
This is a simplistic model, but research shows that human decision-making in large organizations can be quite flawed, as illustrated in Noise by Daniel Kahneman. This approach follows the "simple linear model," which has outperformed human decision-making since the 1950s, even before the advent of machine learning and artificial intelligence.
By adopting this model, you can enable the "reverse Conway manoeuvre," which helps prevent the reimplementation of your previous system and the perpetuation of your organizational structure. There is no competitive advantage in solving problems that have already been solved. Most people agree that competitive advantage comes from being customer-centric and addressing their unmet needs.
Finally, this approach emphasizes the importance of shipping, as stated by Paul Graham about Steve Jobs: "The Other Half of Artists Ship." If you don't ship, you risk losing your talented team members. By defining shipping in terms of the design system, platform, and pipeline outcomes, you can address any barriers to shipping collaboratively within the repository. By staffing appropriately and leveraging deep experience to remove initial barriers, your teams will learn and adapt, making shipping the norm. This way, you facilitate change easily (pull transformation) instead of trying to manage change (push transformations that often stall or fail).
Getting to Done
To get started:
- Create a monorepo for your target next-generation platform.
- Integrate your design system into the repository or create a new one if it doesn't exist.
- Develop the basic structure of your platform, including:
- Pipelines
- Authentication (Auth)
- Security
- Databases
- Testing
- Deployment
- Blue/Green environments
- Feature flagging
- And any other components you deem necessary
- Move your product into the monorepo and refactor it as needed to accommodate the Platform DevOps.
- Start integrating the platform into your product using the design system. Initially, focus on shared services across products, such as login, authentication, authorization, and roles. Then, implement into the new platform pipelines.
- Define your migration roadmap and heuristics:
- Assess the coupling and cohesion between modules to apply the design system effectively, considering both developer experience and product ROI. Balance short-term and long-term outcomes pragmatically.
- Determine what is "core" to shared services and what is optional.
- Establish a rule-of-thumb for moving any particular effort to the design system, such as:
- If it takes less than 2 days, update as-is unless there's compelling value in using the design system.
- If it takes between 3 and 10 days, refactor to the design system if less than 2x the effort.
- If it takes more than 2 weeks, rewrite to the design system if less than 2x the effort.
- Optional: Reskin your product using the CSS-only export of the design system.
- Outcome 1: After updating 10-15% of your code in both products, you'll be ready to move your second product into the monorepo and refactor it to use the platform's shared services. Once the second product is running faster than before and has a clear plan for adopting the platform long-term, you've achieved the first outcome.
- Outcome 2: With two products on the platform, you have a true platform foundation. Consider pulling a third product into the monorepo or changing your repo strategy if a different team topology makes sense. However, avoid changing the status quo until you reach this point.
- Outcome 3: Your team is now effectively transformed, with your new platform becoming the new status quo. The mix of leaders, problem solvers, and journey people in your team is clear, as they have been vetted through the adoption of the platform and its continuous delivery pipelines. All future changes will be incremental.
Conclusion
This topic could be expanded into a book, but a high-level roadmap and set of principles inspired by Dave Snowden's Cynefin framework should suffice. A book or a framework may not provide the answers for the unknown unknowns, as they often fail to address the liminal spaces where problems reside.
It's important to understand that you can only externalize 10% of your tacit knowledge, and complexity is more about chefs navigating uncharted territory (wayfinding) than following recipes and rules.
This is a simple yet effective model: determine the date you need to launch your platform and calculate the ROI of doing so by that time or sooner. Then, assemble a skilled team and start developing superior products on your market-leading digital experience platform.
With a well-thought-out plan and less time wasted on unimportant tasks, you can be two years ahead in your replatforming roadmap within 6-12 months.
