Forem: Willian Corrêa

Get Promoted: The Data-Driven Guide For Metrics That Actually Matter

Willian Corrêa — Mon, 02 Jun 2025 18:21:53 +0000

How to build an undeniable business case for your raise using quantified achievements, strategic scope, and failure-to-value — while avoiding the mistakes that sink 95% of promotion requests

Let me start with a story that might sound familiar. A talented engineer sits across from their manager, palms slightly sweaty, and delivers what they believe is a compelling case: "I've been here for three years. My rent just went up 20%. I'm starting a family. I really need this raise." The manager shifts uncomfortably, offers a sympathetic smile, and responds with some variation of "Let me see what I can do," which translates to "No."

Here's the brutal truth: Your personal circumstances are irrelevant to your compensation. Your tenure is a data point, not an argument. That growing family you mentioned? Your manager has their own bills to pay. The only currency that matters in promotion discussions is demonstrable business value, and if you can't articulate that value in numbers, you're essentially asking for charity, not recognition.

The most successful engineers and leaders I've worked with understand this fundamental principle: promotions are business transactions, not loyalty rewards. They approach these conversations armed with data, impact metrics, and a clear narrative that connects their contributions directly to business outcomes. They don't ask for promotions; they present an irrefutable case for why promoting them is the logical next step for the organization.

Your failures, properly framed, can be more valuable than your successes in promotion discussions

The Only Currency That Matters: Business Impact

In my years building teams across fintech, healthcare, and aviation platforms, I've reviewed hundreds of promotion requests. The pattern is painfully consistent: about 80% focus on effort and tenure, 15% mention vague accomplishments, and only 5% present quantifiable business impact. Guess which group gets promoted?

Business impact isn't just about writing good code or shipping features on time. Those are table stakes—the minimum expected performance. Real impact means understanding and articulating how your work moves the business metrics that keep executives awake at night: revenue growth, cost reduction, risk mitigation, market expansion, and competitive advantage.

Consider the difference between these two statements:

"I refactored the payment processing system and improved code quality"

"I reduced payment processing time by 47%, saving $2.3M annually in transaction fees while improving checkout conversion by 3.2%, generating an additional $8.7M in revenue"

The first statement describes an activity. The second demonstrates impact. The engineer who can articulate the second statement doesn't need to beg for a promotion—they're stating facts that make the promotion decision obvious.

Revenue generation remains the most straightforward impact to quantify, but it's far from the only metric that matters. Cost reduction through efficiency improvements often delivers more sustainable value than revenue spikes. When I led the re-architecture of a real-time exchange platform, the immediate win wasn't new revenue—it was reducing our infrastructure costs by $2M annually while improving transaction throughput from 120 to 500 TPS. Those cost savings were directly applied to the bottom line, funding three new product initiatives.

Risk mitigation represents another critical, yet often overlooked, impact category. The engineer who implements comprehensive monitoring to prevent a potential data breach hasn't just saved the company from immediate financial loss—they've protected the brand reputation, customer trust, and avoided regulatory penalties that could reach millions. Quantifying prevented disasters requires sophistication, but managers understand this language fluently.

Efficiency gains compound over time, making them particularly valuable for discussions about promotion. If your optimization saves each developer on a 50-person team just 30 minutes daily, you've created the equivalent of hiring three additional engineers. At an average fully-loaded cost of $200,000 per engineer, that's $600,000 in annual value creation. Suddenly, that 15% raise you're requesting looks like a bargain.

Building Your Impact Portfolio

The biggest mistake I see engineers make is waiting until promotion season to start thinking about their accomplishments. By then, you've forgotten half of what you did, lost the metrics that would prove your impact, and reduced your compelling narrative to generic statements like "improved system performance" or "mentored junior developers."

Building an impact portfolio requires the same rigour you apply to system design. You need consistent data collection, regular analysis, and a clear understanding of what metrics matter to your organization. This isn't about self-promotion or politics—it's about professional discipline.

Continue reading at https://businessasusual.io/p/the-data-driven-guide-to-getting

Why engineers with strategic plans earn 40% more and get promoted twice as fast

Willian Corrêa — Wed, 28 May 2025 21:38:16 +0000

Stop Drifting: How Strategic Career Planning Doubles Your Earning Potential as a Software Engineer

Every software engineer has faced moments of uncertainty, asking themselves questions like, “Am I on the right track?” or “Is this job really helping me grow?” These moments of doubt often occur due to a lack of clear direction or a coherent strategy guiding their career decisions. Without a definitive roadmap, even talented engineers risk drifting through roles, experiencing frustration, stagnation, and missed opportunities. Imagine two equally skilled engineers at the start of their careers — one who strategically maps out a clear pathway, and another who takes opportunities as they randomly appear. Five years later, who is likely to be more satisfied, more advanced, and more successful?

A career strategy is essentially your professional roadmap — a structured and deliberate plan outlining specific goals, the steps needed to achieve them, and the continuous assessment of progress along the way. It’s not merely about setting objectives; it involves proactively managing your growth, deliberately choosing roles and projects, and regularly updating your skillset to align with industry trends and personal aspirations. Particularly in the technology sector, where rapid change and opportunities are plentiful but highly competitive, a well-defined strategy can make the difference between career excellence and mediocrity.

Why is a career strategy especially critical for software engineers? The tech landscape evolves swiftly, introducing new tools, frameworks, and methodologies at a relentless pace. Engineers who proactively shape their professional trajectories by consistently upskilling and adapting to these changes are invariably better positioned to leverage new opportunities. They achieve higher job satisfaction, earn more substantial financial rewards, and maintain relevance throughout their careers, even in times of industry upheaval or economic downturn.

The Power of Intentional Career Planning
A career strategy can be defined as an intentional, thoughtful plan designed to achieve specific professional objectives over the short and long term. It involves setting clear goals, identifying actionable steps, proactively pursuing skill development opportunities, and regularly reassessing one’s trajectory. Rather than passively reacting to circumstances, professionals with a solid career strategy actively shape their career paths by aligning opportunities with their goals, passions, and skills.

A career strategy is inherently self-directed, whereas a career plan is often narrower, focusing on immediate role-related objectives set by the employer

It is important to distinguish a career strategy from a company-offered career plan. While a career plan provided by an organization typically outlines steps and opportunities aligned with the company’s goals and roles, a personal career strategy encompasses broader professional objectives that may extend beyond a single organization. A career strategy is inherently self-directed, considering personal values, industry trends, and long-term career aspirations, whereas a career plan is often narrower, focusing on immediate role-related objectives set by the employer.

In stark contrast, many individuals “drift” through their careers without clear direction or deliberate planning. This approach often results in missed opportunities, stagnation, and increased dissatisfaction, as career decisions become reactive rather than proactive. Drifters typically accept whatever roles or responsibilities come their way without considering their long-term impact or alignment with personal aspirations. As a result, they risk finding themselves stuck in unsatisfying jobs, unsure of how to transition toward more fulfilling roles.

Research consistently shows that intentional career planning significantly enhances professional outcomes. According to a study published in the Journal of Vocational Behavior (2020)1, professionals who engage proactively in career planning report higher job satisfaction, lower perceived overqualification, and better alignment between their skills and their roles. Moreover, these individuals are also more likely to experience faster promotions and salary increases compared to peers without a clear career roadmap.

Career Progression Metrics: What Success Looks Like
To understand the tangible impact of career strategy, it’s helpful to examine specific benchmarks and KPIs that successful software engineers achieve:

Salary2 Progression Benchmarks:

Junior Developer (0–2 years): $65,000 — $95,000
Mid-level Developer (3–5 years): $85,000 — $130,000
Senior Developer (5–8 years): $120,000 — $180,000
Staff/Principal Engineer (8+ years): $160,000 — $300,000+
Engineering Manager (varies): $140,000 — $250,000+
Engineers with intentional career strategies typically achieve 15–25% faster salary growth compared to industry averages, often reaching senior-level compensation 1–2 years earlier than their peers.

Key Performance Indicators for Career Progress:

Time to promotion (industry average: 18–24 months per level)
Skill acquisition rate (strategic planners master 2–3 new technologies per year vs. 1–2 for reactive learners)
Network growth (200+ professional connections by mid-career)
Visibility metrics (speaking engagements, publications, open-source contributions)
Internal mobility (lateral moves that broaden experience every 2–3 years)
A key element underpinning the power of intentional career planning is the sense of control and empowerment it provides. Software engineers who consciously shape their career journeys feel more confident in navigating industry shifts and identifying growth opportunities. They are more adept at leveraging their unique skills and experiences to stand out in competitive job markets, continually positioning themselves for advancement.

The Cost of Career Drift: Real-World Failure Scenarios
While success stories are inspiring, understanding what happens without a career strategy provides equally valuable insight. Consider these common patterns among engineers who drift through their careers:

Case Study: The Perpetual Junior Sarah, a talented developer, spent six years accepting whatever tasks were assigned without considering skill development or career progression. Despite strong technical abilities, she remained at a junior level because she never advocated for growth opportunities or developed leadership skills. By age 30, she was earning 40% less than peers who started at the same time but had strategic career plans. The lesson: technical competence alone doesn’t guarantee advancement.

Case Study: The Technology Trap Mike became an expert in a legacy system early in his career but never diversified his skills. When the company modernized their stack, he was passed over for promotions and eventually faced layoffs. Without transferable skills or a network outside his company, he struggled to find equivalent roles. Strategic engineers regularly assess market trends and ensure their skills remain relevant and transferable.

Case Study: The Burnout Cycle Jessica took on increasingly demanding roles without considering work-life balance or personal values. Despite rapid initial progress, she experienced severe burnout at age 28, took an extended break, and had to rebuild her career from a lower position. Engineers with strategic career plans typically include sustainability and personal values as core planning criteria.

Statistical Impact of Career Drift:

60% higher likelihood of experiencing career plateaus lasting 3+ years
25% lower lifetime earnings compared to strategic planners
45% higher job dissatisfaction rates
35% more likely to experience career pivots that require starting over
Your career strategy is the only algorithm where you’re both the architect and the code — optimize for growth, refactor for change, and never stop debugging your assumptions. — Willian Correa

Early-Career Benefits of a Clear Strategy
Early-career software engineers often encounter several specific challenges, including unclear job roles, limited growth opportunities, and minimal guidance on professional development. Without clarity, these professionals may become overwhelmed or discouraged, struggling to identify the essential skills they need to acquire or roles best aligned with their career aspirations.

Developing a clear career strategy early on provides significant advantages by creating a clear sense of direction. A well-defined strategy helps early-career professionals pinpoint essential skills and competencies they need to master, fostering faster and more intentional skill acquisition. This clarity allows them to actively seek roles, projects, or training that align with their professional objectives.

Research supports the notion that proactive career planning enhances early employment outcomes. According to studies such as those published in the Journal of Vocational Behavior (2020), new professionals who engage in structured career planning experience improved job satisfaction and reduced feelings of being overqualified or misaligned with their positions. Additionally, a 2023 study by Zhao and Tsuboi explored the onboarding experiences of early-career software developers and found that those who received proactive support — like structured guidance and goal-setting conversations — reported significantly higher satisfaction and retention. These findings reinforce the idea that proactive measures help ensure early-career experiences become constructive stepping stones toward long-term professional goals.

Practical Timeline Development for Early-Career Engineers
Year 1–2: Foundation Building

Master core programming languages and frameworks
Complete 2–3 significant projects demonstrating different skills
Establish mentorship relationships
Begin building a professional network (target: 50+ connections)
KPI: Achieve competency in primary tech stack, contribute to team projects
Year 3–4: Specialization and Leadership

Develop expertise in chosen specialization (frontend, backend, DevOps, etc.)

Continue reading at https://businessasusual.io/p/stop-drifting-how-strategic-career

Lessons from 20+ years in the trenches—raw, practical, and painfully honest. https://businessasusual.io

Willian Corrêa — Fri, 23 May 2025 23:24:07 +0000

AI won't replace your job if you...

Willian Corrêa — Fri, 27 Dec 2024 21:42:41 +0000

The technology industry has never been static. From the early days of computing, where vacuum tubes and punch cards reigned, to the modern era of cloud computing and artificial intelligence, the only constant has been relentless change. As we inch toward 2025 and beyond, a new wave of anxiety is gripping the community of software engineers: Are we heading toward a future where our work becomes obsolete? Can artificial intelligence write all the code for us and, in turn, eliminate the need for software engineers altogether?

Sensational headlines proclaim that software engineering will be replaced by AI systems that can generate code instantly, making human involvement unnecessary. Silicon Valley folklores have even spurred debates about whether aspiring engineers should pivot to another field. The truth, of course, is far more nuanced. While AI is undeniably transformative, it’s not a harbinger of doom for software engineers; it’s an opportunity — albeit one that requires adaptability, foresight, and a willingness to reinvent oneself.

it becomes clear that this moment is actually calling on software engineers to do what they’ve always done: solve problems, innovate, and adapt.

In the face of these mediatic prophecies, it’s tempting to feel paralyzed or frantic about how to keep your skills relevant. But if you break down the challenge, it becomes clear that this moment is actually calling on software engineers to do what they’ve always done: solve problems, innovate, and adapt. The future of software engineering is not about passively waiting to see if you’ll be replaced but about strategically positioning yourself to leverage AI and all emerging technologies to your advantage.

Software engineers who concentrate solely on a particular framework or language often find themselves scrambling when trends shift — just as once-in-demand WordPress or Fortran developers did when newer approaches took center stage. Frameworks such as React/NextJS may dominate headlines and job postings today, but in a few years, the industry will — for certain — pivot again to something entirely different. The underlying, timeless skill that will keep an engineer relevant and marketable is problem-solving — being able to dissect a challenge into its fundamental parts and devise efficient, innovative solutions. Frameworks and languages are tools: valuable as they are, they should serve the problem at hand rather than dictate an engineer’s professional identity.

This article aims to give you a comprehensive outlook on how to thrive in a tech market that’s rapidly shifting under the influence of AI. We’ll look at the big questions to ask yourself, and we’ll reflect on the industry's evolving demands. We’ll discuss everything from core fundamentals in software development to the expansive skill sets that will help you remain indispensable. You’ll see that while AI might change how code is generated, there will still be an entire universe of tasks that only creative, holistic, and ethically-minded humans can handle. If you’re looking for a roadmap to stay relevant, read on.

Read the full article at https://medium.com/@wgcorrea/staying-relevant-in-an-era-ai-advancements-a-2025-and-beyond-playbook-for-software-engineers-ec2e8caa06e9

You don't know TDD... yet

Willian Corrêa — Thu, 28 Sep 2023 05:14:25 +0000

Test-driven development (TDD) has been a cornerstone of software engineering for years, yet its core principles are often misunderstood or misapplied. This article aims to shed light on these overlooked aspects, elevating your understanding of TDD regardless of your experience level. While the title may come across as provocative, it’s inspired by Kyle Simpson’s seminal book series, ‘You Don’t Know JS Yet.’ The goal here is not to question your expertise, but to challenge conventional wisdom and enrich your perspective on TDD.

As a Software Engineer and Consultant with 23+ years of experience, I’ve been fortunate to guide engineering teams toward high performance. One commonality I’ve noticed is how TDD is frequently both praised and criticized, sometimes for the wrong reasons. The discourse tends to focus on surface-level practices, leaving the deeper, more meaningful aspects of TDD unexplored. This article won’t serve as an introductory guide to TDD or delve into its origins. Instead, it aims to expose and clarify the misconceptions and lesser-known facets that could make or break your experience with TDD.

By examining these misconceptions and the rationale behind them, this piece will help you avoid pitfalls that even seasoned engineers sometimes fall into. We’ll go beyond the basic “red-green-refactor” cycle and discuss what often gets overlooked: the discipline, the commitment, and the philosophical underpinnings that make TDD a compelling practice for teams striving for excellence. Whether you’re a beginner seeking clarity or an expert looking to refine your understanding, this article will offer valuable insights to enhance your TDD practice.

Common Misconceptions about TDD

Before diving into the nitty-gritty, it’s important to clarify that misconceptions about TDD are not exclusive to newcomers. Even seasoned professionals can fall into certain traps. The following list identifies some of the most prevalent misunderstandings that I’ve observed across a range of engineering teams.

Over indexing on Writing Tests First
Not having a test list to determine what tests to write, ordered by simplicity
Using versioning (git) against the principles of working software
Not knowing when to stop
Thinking Test Driven Development is about quality when in fact it’s about design
Believing TDD is for backend only and does not apply to frontend

By examining and addressing these common misconceptions, we can develop a more informed and effective approach to TDD. Knowledge is power, and understanding where you might go astray can help you fully harness the benefits of this methodology.

Full article: https://medium.com/@wgcorrea/you-dont-know-test-driven-development-yet-e0787273db6c

Stop creating Technical Debt

Willian Corrêa — Wed, 16 Nov 2022 09:37:23 +0000

Technical debt is a great metric to measure how much pressure and bad decisions from management are affecting the team, product, and overall business.

Technical debt is completely avoidable and unnecessary. In fact, from dozens of projects my teams inherited to course correct, we could see the total investment, cost of maintenance, and cost of ownership was on average 1.8x higher when compared to projects with zero technical debt and similar complexity and size.

Common justifications to adopt technical debt:

A temporary solution to deliver something within a fixed timeline
Time-to-market to beat the competition
Minimal Viable Product
Infrastructure direct costs
Promise to pay it later

Accepting technical debt will inevitably lead to significant reinvestment in the future. This is also true even if there is a set limit to the amount of technical debt or a process to pay it at every iteration.

Proper Digital Ops practices - modern quality, continuous delivery, and evolutionary architecture can contribute to avoiding technical debt. However, embracing Agile and improving feature prioritization practices are the real game changers for better solutions that will not require re-engineering and re-investments in the future.

Headless CMS: 6 best practices to boost value generation, reduce risks and accelerate time-to-market

Willian Corrêa — Thu, 08 Sep 2022 17:07:42 +0000

To the point:

1. To avoid vendor lock-in, use a composable architecture with proper layers to isolate the core business. It will reduce common SaaS vendor risks, allow scalability, and better cost control in the mid & long term.

2. For small sites, static site generators (SSG) combined with deployments using content delivery networks (CDN) will provide the best performance and time-to-market strategy. For larger sites and eCommerce, the strategy is likely to require a solution based on cache and server-side rendering (SSR); which can be further improved with edge computing.

3. Mobile apps must use a local-cache-first strategy for content. For high-risk content, a time-to-live approach can be adopted to enforce compliance. I have seen many projects trying other approaches and failing to keep time-to-market at a competitive pace, to the point re-engineering was put back in the backlog.

4. In general, a separate vendor for media management is recommended. The SaaS offering is vast and offers specialization capabilities that will help teams to optimize performance and compliance. They also offer out-of-box integrations with the main headless CMS solutions.

5. eCommerce with a simple catalog or with a small set of SKUs can be implemented using the headless CMS solution. However, keep in mind that specialized headless e-commerce platforms provide built-in solutions for payments and shipping. Other capabilities like subscriptions, bookings, or digital assets will require a deeper evaluation of the strategy.

6. Adopt infra-as-code and content-model-as-code; it will prevent common bugs, enable continuous delivery and accelerate time-to-market.

I'm curious to learn from you. What are the challenges preventing your organization to adopt a headless CMS solution?

Enforcing 100% adoption of a Design System is an anti-pattern and a high-risk factor for the organization

Willian Corrêa — Thu, 01 Sep 2022 19:38:17 +0000

In the same avenue that 100% code coverage by automation tests is not possible to achieve unless depreciating quality; enforcing 100% adoption of the design system's components will prevent the team to innovate and evolve products faster. In other words, it will affect the organization's capacity to stay competitive.

In a recent research, we found that on average highly effective design systems have 74% of adoption when compared to custom components. Also, the average lifetime of a custom component is about 1.5 months, until it's either incorporated into the design system or removed.

Well-executed design systems share common factors such as:

Product teams have the freedom to create custom components, experiment, measure results, and report back to the design system team
The design system makes the tokens available to product teams, so they still can be on-brand even building custom components
The Design System project adopts continuous delivery, allowing incremental improvements and frequent releases

At Rangle, we help organizations of all sizes and complexities to plan, implement and adopt Design Systems in the right way. We focus on enabling product teams to build better products faster and generate more value.

Reach out and let's talk about how to unlock your design system to generate more value and justify the investment.

Design Systems: building custom vs building on top of an open-source design system

Willian Corrêa — Mon, 22 Aug 2022 22:34:00 +0000

Technology teams must support the Design mandate in the journey of creating, adopting, and maintaining a design system. At the risk of limiting the design team's innovation capabilities and UX ambitions, engineers might need to find optimizations, enablers, and levers outside of the approaches used in other types of digital projects. One example is the typical decision point: building custom vs building on top of an open-source design system.

Choosing to build on top of an existing open-source design system to optimize cost and time-to-market has the same risk, if not higher, as building completely custom. It's too easy to feel like the right choice; engineering teams are used to relying on third-party libraries to optimize for time and cost in traditional projects all the time.

I have seen many teams failing with Material or Carbon having a final product looking like Google or IBM products - missing the ambition set by the design team. Attempts to customize these libraries to fit the design's vision often led to more time and investment rather than achieving the shortcut desired.

On the other hand, endless debates about conventions, tokens and atoms led teams not to deliver a consumable and effective design system when building it custom. Also, the overwhelming amount of decisions in this scenario often slows delivery, not rarely increasing pressure on the team and reducing quality standards.

Successful design system teams often optimize to deliver the best UX as quickly as possible to customers. They choose a strategy based on incremental releases that enable the adoption process to start sooner. They establish a communication channel with teams consuming the design system to collect feedback and improve it iteratively. Also, they will consider the design system as a product: it's never done; it's constantly evolving.

If an open-source design system does not support the design's team ambition & vision, or creates challenges for the characteristics of successful projects above, then building custom is the way to go. In other words, if the design expected requires more than adjusting the theme options (tokens values), the custom route is a better option.

It's a common mistake to assume it is easy to change and adapt the default components offered by the framework. Teams overlook the complexity since the customization implies reviewing documentation, impacts on composed components, accessibility and quality checks at best. Often it also requires creating more atoms and tokens, which can quickly bloat and add complexity to the maintenance. Customizations often create barriers to keeping the project up-to-date with the original system, missing bug fixes and improvements.

Building custom means you need a proper team and budget to support the design system. More decisions around the stack and tooling will be required to enable the project and adoption. The team will need more support to stay focused on making progress and avoid common traps.

Another false assumption is that building a custom design system means starting from zero. Tooling and resources are available to enable teams to start a custom design system from a more advanced stage that will not compromise the solution in the long run. Radius from Rangle is a good example - it is a collection of open-source tools and libraries that guide and help you to build a custom design system faster.

Creating a strategy for a design system is a complex task that we can help with. At Rangle, we partner with our clients and help them to make better decisions. With the "one team, one goal" approach, we unblock their teams and unlock market opportunities. Hands-on learning opportunities and co-creating design systems mean that our client's teams can build great customer experiences long after their engagement with Rangle is over. In addition, we focus on great processes that are scalable and aren't dependent on hiring star developers or designers but on ensuring everyone in your organization can deliver to the best of their ability.

I'm curious to learn about the challenges and experiences you have with Design Systems. Reach out, and let's exchange ideas.

You don't need code reviews and PRs

Willian Corrêa — Wed, 17 Aug 2022 23:25:15 +0000

PRs & Code reviews are a blocker and bottle-neck for value generation. Allow me to explain.

A Pull-request was a feature created to allow maintainers of an open source project to receive changes from unknown contributors. It solves a trust problem, allowing the maintainer to review code before rejecting or accepting changes.

Developers working together as part of a team don't have trust issues. Otherwise, it is a different problem in which PRs are not the solution. At best, the issues of a team are about quality and norms.

Automating testing and practices like TDD, CI, and CD can solve quality problems. Automated tests create faster feedback loops when compared to a PR waiting for review and the usual back & forth with comments.

Testing Driven Development helps developers to design their code better and enable testability. Tests are created to support the acceptance criteria in the stories. When they all pass, developers are free to merge the code and move to the next story.

Continuous Integration reduces the chances of merge conflicts. It supports the idea that any code in the main branch is working software ready to ship to production. Pipelines produce feedback and help to avoid regressions.

Continuous Delivery accelerates teams by avoiding branch strategies. Everything is merged into the main branch and continuos tested. Code is deployed into production often, and feature flags can be used to allow for tests in production or canary releases

Pair Programming or Mob Programming eliminates the need for code reviews. Code is reviewed as it is produced. Disagreements can be solved on the spot instead of async through comments. Knowledge is shared, avoiding silos.

Norms can be enforced with code static analysis tools as part of the pipeline and pre-commit hooks. Quality gates can be added to implement minimum thresholds. Developers can focus on value generation rather than reviewing code that is faulty in style but functionally correct

For regulated markets, compliance and regulations can be satisfied without code reviews in most cases with modern Quality practices.

Unless you are developing an open source project, you should seek to stop doing PRs & Code Reviews. It will accelerate time-to-market and help to improve the product further with more frequent customer feedback.