The Core Data-Driven Decision Framework for Engineering Managers
The core data-driven decision framework for engineering managers consists of five sequential steps: Hypothesis Formulation, Metric Selection, Trade-Off Scoring, Controlled Rollout, and Post-Launch Audit. This framework converts subjective architectural debates into measurable technical trade-offs by tying every engineering proposal directly to an observable business or operational threshold. Applying this systematic process cuts decision latency by establishing explicit success criteria before writing code or altering production infrastructure.
[ 1. Hypothesis Formulation ]
|
v
[ 2. Metric Selection ]
|
v
[ 3. Trade-Off Scoring ]
|
v
[ 4. Controlled Rollout ]
|
v
[ 5. Post-Launch Audit ]
Yet, possessing telemetry rarely makes technical decisions straightforward.
The Manager’s Dilemma: Telemetry Overload
Telemetry is the automated collection and transmission of operational measurements—such as latency, error rates, and CPU load—from remote systems to monitoring dashboards for real-time analysis.
Modern engineering environments generate terabytes of this data daily. You see this dynamic play out during architectural reviews: one senior engineer pushes to migrate an API layer to gRPC, pointing to p99 latency spikes in Datadog. A principal engineer argues for keeping REST to avoid client refactoring costs, citing current error budgets. Both cite real numbers from the same monitoring cluster.
Data without an evaluation structure increases friction instead of resolving it. A study published in Stripe’s Developer Coefficient report revealed that software engineers spend 33% of their work week (roughly 13.5 hours) dealing with technical debt and bad code, often caused by misaligned technical choices. When leaders lack concrete data-driven leadership principles, dashboards become weapons for confirmation bias. Engineering managers freeze, waiting for clearer telemetry that never arrives.
Two-Way Doors vs. Rigorous Data Protocols
You do not need an exhaustive multi-week evaluation for every engineering choice. Applying heavyweight analysis to minor pull requests slows down release velocity and exhausts your team.
A two-way door decision is an easily reversible technical or procedural choice that a team can quickly undo without significant financial or operational loss.
In his 1997 letter to Amazon shareholders, Jeff Bezos distinguished between irreversible "Type 1" choices (one-way doors) and reversible "Type 2" choices (two-way doors). Engineering managers must separate technical proposals along these lines to maintain delivery speed:
- Two-Way Door Decisions: Modifying an internal CI/CD build cache, tweaking non-critical cron schedules, or testing an open-source logging library on a staging environment. These require a 70% confidence threshold and a fast rollback plan. Use rapid protocols such as those outlined in our guide to lead under pressure: 5 steps to fast decisions.
- One-Way Door Decisions: Migrating your primary relational database, rewriting a core billing service, altering customer SLAs, or selecting an enterprise vendor contract that commits $150,000 annually. These demand the complete 5-step framework.
When facing irreversible choices, pairing structured evaluation with broader strategic decision making frameworks keeps engineering velocity high while protecting system reliability.
Frequently Asked Questions
How do you prevent analysis paralysis during metric selection?
Limit your evaluation to one primary success metric (such as p95 latency under 200ms) and no more than two guardrail metrics (such as AWS compute costs remaining below $4,000 per month). If a metric does not directly impact user experience or operational budgets, exclude it from the decision scorecard. Learn more about refining your evaluation criteria in our guide on developing data-driven decision making skills.
What is the fastest way to score technical trade-offs between competing architectures?
Build a simple scoring rubric that rates each alternative from 1 to 5 against four criteria: implementation speed, maintenance overhead, horizontal scalability, and licensing cost. Weight each category based on current quarterly goals. You can adapt the model from our weighted decision matrix for high-risk ventures to compare competing technical designs objectively.
Now that you know which technical choices require structured evaluation, you must establish the exact scoring rubrics and step-by-step documentation templates needed to run this process with your team.
Key Takeaways
- Define concrete hypotheses and baseline metrics before evaluating competing engineering solutions.
- Isolate leading indicators like deploy frequency from lagging metrics like system availability.
- Document technical trade-offs using weighted decision matrices to accelerate stakeholder consensus.
- Schedule 30- and 90-day post-rollout audits to validate actual performance against initial projections.
Table of Contents
- The Core Data-Driven Decision Framework for Engineering Managers
- Step 1 & 2: Define Falsifiable Hypotheses and Isolate True Metrics
- Step 3 & 4: Quantify Trade-Offs and Run Controlled Rollouts
- Step 5: Run 30- and 90-Day Post-Implementation Audits
- Your Copy-Paste Data-Driven Decision Template for EMs
- 1. Context & Problem Statement
- 2. Hypothesis & Target Metrics
- 3. Counter-Metrics (Guardrails)
- 4. Evaluated Options
- 5. Rollout Gates & Abort Triggers
- 6. Stakeholder Sign-Off
- 1. Context & Problem Statement
- 2. Hypothesis & Target Metrics
- 3. Counter-Metrics (Guardrails)
- 4. Evaluated Options
- 5. Rollout Gates & Abort Triggers
- 6. Stakeholder Sign-Off
- Sources & Further Reading
Step 1 & 2: Define Falsifiable Hypotheses and Isolate True Metrics
A falsifiable hypothesis is an engineering proposal structured so that clear operational telemetry can directly prove or disprove it within a defined timeframe, preventing subjective debates about whether a project succeeded.
Most engineering roadmap proposals start as vague aspirations. A tech lead asks to spend 6 weeks refactoring an ingestion pipeline to "improve maintainability." This phrasing makes objective evaluation impossible. You cannot measure "maintainability" on a production dashboard, nor can you verify when the work is finished.
To apply strategic decision making frameworks to technical choices, you must translate every architectural pitch into a measurable bet. If the goal is pipeline refactoring, the hypothesis becomes: "Rewriting the ingestion worker in Go will reduce p99 processing time from 420ms to under 150ms and drop average CPU utilization per Kubernetes pod from 78% to 35% within 14 days of release." Now your team has an unambiguous target.
Categorize Your Decision Inputs
Once your hypothesis is clear, isolate the raw metrics you will track. Engineering decisions generate noise across multiple logging tools like Datadog and GitHub. You must group your metrics into three distinct categories to avoid optimizing the wrong variable:
- Velocity signals: DORA metrics are four standardized software delivery indicators established by Google’s DevOps Research and Assessment team that measure deployment frequency, lead time for changes, change failure rate, and time to restore service. Nicole Forsgren, Jez Humble, and Gene Kim demonstrated in Accelerate that elite engineering teams deploy multiple times per day with lead times under one hour. Tracking these ensures your workflow changes actually remove bottlenecks.
- System health telemetry: These are raw operational numbers, such as endpoint error rates, memory saturation, database connection pools, and API latency.
- Operational overhead: This measures the human burden of running the system. Track weekly on-call alert volume, off-hours pages, and the number of hours spent on manual release verification.
Strengthening your team’s capacity for data-driven decision making in leadership requires treating these categories as interconnected systems. Improving velocity signals while ignoring on-call alert spikes creates hidden burnout.
Pair Every Target Metric With a Counter-Metric
Goodhart’s Law states that when a measure becomes a target, it ceases to be a good measure. If you tell a backend team to cut CI/CD pipeline runtimes from 28 minutes to 6 minutes, they might simply delete test suites. If you push for 5 deployments per day, developers might push smaller, untested commits into trunk.
An error budget is the maximum allowable threshold of system unreliability and downtime that a service can experience over a set period without violating customer service agreements. In Google’s Site Reliability Engineering book, authors Betsy Beyer and Niall Richard Murphy emphasize using error budgets as the natural counterweight to release velocity.
Every target metric requires a counter-metric that runs in direct tension with it:
- Primary Metric: Increase deployment frequency from 2 releases per sprint to 8 per sprint.
Counter-Metric: Keep Change Failure Rate below 4.5% on a rolling 30-day window. - Primary Metric: Reduce test suite execution time from 22 minutes to 5 minutes.
Counter-Metric: Maintain code coverage at or above 82% across all critical paths. - Primary Metric: Cut infrastructure cloud spend by $14,000 per month.
Counter-Metric: Keep 99th-percentile API response latency below 200ms during peak load hours.
Practicing and developing data-driven decision making skills means enforcing these paired constraints before work begins. Use the template below in your next architecture review or sprint planning session to align your team on measurable boundaries.
Copy-Paste Template: Engineering Decision & Metric Matrix
ENGINEERING INITIATIVE PROPOSAL 1. HYPOTHESIS SPECIFICATION - Proposed Change: [Describe specific architectural or workflow change] - Current Baseline: [Current state with numeric baseline, e.g., 420ms p99 latency] - Projected Outcome: [Expected result with target number, e.g., <150ms p99 latency] - Timeframe to Evaluate: [Number of days/weeks post-deployment, e.g., 14 days] - Falsification Criteria: This initiative will be considered a failure or rolled back if [Specific metric failure condition, e.g., p99 remains above 300ms after 14 days]. 2. METRIC TAXONOMY - Velocity Metric: [e.g., Reduce build time from 25 min to 8 min] - System Health Metric: [e.g., Maintain 99.95% HTTP 2xx success rate] - Operational Overhead Metric: [e.g., Reduce weekly on-call pages from 18 to <4] 3. PAIRED COUNTER-METRIC GUARDS - Primary Optimization Target: [Target metric and goal value] - Paired Counter-Metric: [Constraining metric] - Guardrail Threshold: [Breach value that triggers an immediate freeze, e.g., Change Failure Rate > 5%]
Once you lock down your hypotheses and guardrails, the next challenge is extracting signal from noisy production data without falling into cognitive traps.
Step 3 & 4: Quantify Trade-Offs and Run Controlled Rollouts
Engineering debates often stall when senior developers argue over architectural purity while product managers push for delivery speed. You cannot settle a build-versus-buy debate with gut instinct. You need an objective scoring system that translates technical complexity and business cost into comparable numbers.
Construct a weighted decision matrix before writing a single line of code or signing a vendor contract. Define your criteria across technical debt risk, implementation time, operational overhead, and direct financial expense. Assign each factor a percentage weight based on company priorities, ensuring the total equals 100%.
Applying Data-Driven Leadership Principles removes political bias from these architectural crossroads. For major infrastructure investments, adapting a Weighted Decision Matrix for High-Risk Ventures (With Template) allows you to balance 480 hours of internal engineering work against an $85,000 annual third-party SaaS license.
| Evaluation Criterion | Weight | In-House Build (Score 1-5) | Weighted Build Score | Commercial Vendor (Score 1-5) | Weighted Vendor Score |
|---|---|---|---|---|---|
| Time to Production (under 6 weeks) | 30% | 2 | 0.60 | 5 | 1.50 |
| Annual Cost (under $50,000 total) | 25% | 4 | 1.00 | 2 | 0.50 |
| Maintenance Overhead (< 5 hrs/mo) | 20% | 2 | 0.40 | 4 | 0.80 |
| Security & SOC2 Compliance | 15% | 3 | 0.45 | 5 | 0.75 |
| Feature Customization Flexibility | 10% | 5 | 0.50 | 2 | 0.20 |
| Total Score | 100% | — | 2.95 | — | 3.75 |
Once your matrix reveals the winning approach, do not push the change to your entire user base at once. You must isolate operational risk through progressive delivery stages using feature management platforms like LaunchDarkly.
A canary deployment is an engineering rollout strategy where you release code to a tiny fraction of live users before exposing the entire customer base to the update.
Route exactly 5% of incoming user traffic to the new service instance during the initial release phase. Monitor real-world telemetry in Datadog for a mandatory 60-minute verification window before increasing traffic to 25%, 50%, and 100%. According to the Google Cloud DORA 2023 Accelerate State of DevOps Report, teams with established continuous delivery and automated rollback practices achieve a 7-times lower change failure rate than low performers.
A circuit breaker is an automated software switch that halts outbound traffic to a failing system component to protect the overall application from cascading downtime.
Set your observability platform to trigger an automated rollback if the HTTP 5xx error rate spikes above 0.5% or if p99 latency climbs by more than 120 milliseconds over a 3-minute rolling window. You should also consult Martin Fowler’s Canary Release guide to structure automated blue-green traffic switching. Hard rules like these remove human hesitation and panic during high-stress production incidents.
With your rollback tripwires active and live performance metrics flowing in, you can now evaluate the real-world operational data against your baseline targets using the structured checklist below.
Step 5: Run 30- and 90-Day Post-Implementation Audits
Deploying a technical change without verifying its long-term impact is just guessing with extra steps. You need a structured review mechanism to prove your changes worked and to catch slow-moving system regressions before they hit production. Practicing data-driven decision making in leadership requires tracking systems well after the deployment ticket closes.
Production telemetry is the automated stream of real-time operational data, such as server latency, error counts, and resource usage, captured directly from live software systems to monitor operational performance.
According to Google’s Site Reliability Engineering handbook by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, teams should run post-event reviews not just for outages, but for major releases to reconcile design assumptions against real system behavior. The 2023 DORA (DevOps Research and Assessment) report found that teams reviewing telemetry continuously maintain change failure rates below 5%, compared to 15% or higher for teams that skip post-release verification.
The 30- and 90-Day Post-Implementation Audit Framework
-
Pull the 30-day telemetry delta against baseline projections
Export raw metrics from your monitoring platform (such as Datadog or Amazon CloudWatch) 30 days after rollout. Compare actual p95 latency, error rates, and CPU utilization against the target numbers established in your original project proposal. If your migration projected a 40% reduction in database read times but telemetry shows only an 18% drop, flag that 22% variance immediately for team review. -
Update Architectural Decision Records (ADRs) with observed telemetry
Open your team repository and update the original ADR with production findings. Record the exact configuration settings, unexpected memory bottlenecks, and any new rate limits discovered under real customer traffic. Documenting these empirical findings ensures your team avoids repeating failed assumptions in future design sprints. -
Execute the 90-day financial and technical debt review
At the 90-day mark, inspect your cloud infrastructure billing in AWS Cost Explorer or Google Cloud Billing. Compare actual compute and storage expenditures against your initial return-on-investment (ROI) models. Assess whether the engineering hours spent on maintenance dropped by the projected hours per sprint. -
Deliver a single-page business impact brief to executive stakeholders
Translate raw technical improvements into commercial metrics your VP of Finance or Chief Operating Officer cares about. Frame a 140ms drop in API latency as an operational efficiency gain that protected $24,000 in monthly checkout transactions. Use clear business terms: cost savings, system capacity headroom, and engineering hours reclaimed for product delivery.
Following this structured review rhythm is essential for developing data-driven decision making skills across your engineering staff. You create a continuous feedback loop where production realities inform future planning.
To see how these retrospective metrics feed directly into your next planning cycle, examine the customizable scoring worksheet and decision matrix template below.
Your Copy-Paste Data-Driven Decision Template for EMs
An Engineering Decision Record is a short document that captures a technical choice, the architectural context behind it, the metrics used to evaluate it, and the explicit consequences of the change.
Software architect Martin Fowler’s work on Architecture Decision Records established this practice to stop teams from rehashing old debates. The template below standardizes this format for managers running high-stakes technical evaluations.
The Engineering Decision Record (EDR) Template
Copy this Markdown block directly into your team’s knowledge base or pull request template.
# EDR-[YEAR]-[NUMBER]: [Short Title of Decision]
## 1. Context & Problem Statement
* **Status:** [ Proposed | Accepted | Rejected | Superseded ]
* **Driver:** [ Technical Debt | Performance Bottleneck | Cost Reduction | Compliance ]
* **Owner:** [ Name/Role ]
* **Decision Deadline:** [ YYYY-MM-DD ]
* **Current State:** [ Describe current production behavior in 2-3 sentences ]
## 2. Hypothesis & Target Metrics
If we [implement specific change], then [primary metric] will move from [baseline value] to [target value] within [timeframe].
* **Primary Metric:** [ e.g., p99 latency, compute spend, MTTR ]
* **Baseline Value:** [ Current telemetry reading + date measured ]
* **Target Threshold:** [ Quantifiable success threshold ]
* **Measurement Tool:** [ e.g., Datadog dashboard, AWS Cost Explorer ]
## 3. Counter-Metrics (Guardrails)
*What cannot degrade while chasing the primary metric?*
* **Counter-Metric 1:** [ e.g., Error rate must stay below 0.05% ]
* **Counter-Metric 2:** [ e.g., Monthly cloud spend must not increase by > 5% ]
* **Counter-Metric 3:** [ e.g., Deploy frequency must not drop below 2x/day ]
## 4. Evaluated Options
| Option | Est. Engineering Hours | Monthly Run Cost | Complexity Risk (1-5) | Reversibility (High/Med/Low) |
|---|---|---|---|---|
| A (Status Quo) | 0 | $ | 1 | High |
| B (Proposed) | X hours | $ | X | [Level] |
| C (Alternative) | Y hours | $ | Y | [Level] |
## 5. Rollout Gates & Abort Triggers
Phase 1: Shadow Traffic (10%)
│
â–¼
Gate 1: Error rate < 0.01% for 48h
│
â–¼
Phase 2: Canary Production (25%)
│
â–¼
Gate 2: p99 latency meets target
│
â–¼
Phase 3: Full Cutover (100%)
* **Immediate Abort Trigger:** [ Specific condition that forces an automated rollback ]
* **Rollback Time SLA:** [ Maximum acceptable time to revert, e.g., < 15 minutes ]
## 6. Stakeholder Sign-Off
* **Engineering Lead:** [ Approved / Rejected - Date ]
* **Product Manager:** [ Approved / Rejected - Date ]
* **Security / SRE:** [ Approved / Rejected - Date ]
How to Facilitate the EDR Review in 4 Steps
A decision template fails if your team spends four weeks debating it. You need a structured protocol to move from proposal to consensus quickly. Building your competency in strategic decision-making frameworks keeps these discussions focused on measurable trade-offs rather than opinions.
Step 1: Enforce Asynchronous Reading (24 Hours Prior)
Do not allow live walkthroughs during meetings. The owner publishes the draft EDR at least 24 hours before the review session. Team members must post inline comments and challenge data points asynchronously. If the document lacks a baseline metric with a timestamp, return it without a meeting.
Step 2: Run a 30-Minute Challenge Session
Structure the live meeting with a strict clock:
- First 5 minutes: The owner states the problem, the primary metric, and the counter-metric. No slides.
- Next 15 minutes: Red-team the assumptions. The facilitator asks: "What telemetry signal tells us this failed after 72 hours?"
- Final 10 minutes: Review rollout gates and assign sign-off owners.
Step 3: Run the "Pre-Mortem" Friction Test
Ask the room: "Assume it is six months from today and this rollout caused a severe production outage. What broke first?"
According to research in the Google Cloud DORA 2023 report, high-performing engineering teams with well-defined operational safeguards deploy code 208 times more frequently with lower failure rates. Identify the failure modes before you write production code. If the team discovers an unmeasured failure mode, add it to the counter-metrics table immediately.
Step 4: Apply the Two-Way Door Rule
If a decision is reversible with less than 8 engineering hours of cleanup, approve it immediately once counter-metrics are locked. If it is a one-way door (such as a database schema rewrite), require validation against all rollout gates before merging.
For broader organizational decisions involving upper management, you can pair this technical process with a 5-step senior executive decision process to align budget and platform roadmaps.
Worked Example: Production Database Migration
Here is a filled-out EDR evaluating a migration from PostgreSQL to Amazon DynamoDB for a high-volume session management service.
# EDR-2024-04: Session Store Migration from RDS PostgreSQL to DynamoDB
## 1. Context & Problem Statement
* **Status:** Accepted
* **Driver:** Performance Bottleneck & Horizontal Scaling Limits
* **Owner:** Sarah Chen (Staff SRE)
* **Decision Deadline:** 2024-11-15
* **Current State:** RDS PostgreSQL instance `db.r6g.4xlarge` hits 88% CPU saturation during peak traffic (14,000 writes/sec). Write lock contention causes cascading connection pool exhaustion across 18 microservices.
## 2. Hypothesis & Target Metrics
If we migrate session token storage to Amazon DynamoDB with on-demand capacity, write latency will drop below 15ms at 25,000 writes/sec within 30 days of cutover.
* **Primary Metric:** p99 Write Latency
* **Baseline Value:** 410ms at 14,000 writes/sec (Recorded Oct 12, 2024, Datadog APM)
* **Target Threshold:** < 20ms at 25,000 writes/sec
* **Measurement Tool:** Datadog Service Level Objectives (SLO) Dashboard `[Sessions-Core]`
## 3. Counter-Metrics (Guardrails)
* **Counter-Metric 1:** Monthly infrastructure cost must not exceed $12,500 (Baseline RDS cost: $14,200/mo).
* **Counter-Metric 2:** Read-after-write consistency errors must remain at 0.000%.
* **Counter-Metric 3:** SRE on-call alerts must not increase beyond 2 pages per 7-day shift.
## 4. Evaluated Options
| Option | Est. Engineering Hours | Monthly Run Cost | Complexity Risk (1-5) | Reversibility |
|---|---|---|---|---|
| A: Upgrade RDS to `db.r6g.8xlarge` | 16 hours | $22,400 | 1 | High |
| B: Migrate to DynamoDB (Proposed) | 120 hours | $9,800 | 3 | Medium |
| C: Self-hosted Redis Cluster | 160 hours | $11,500 | 4 | Low |
## 5. Rollout Gates & Abort Triggers
Phase 1: Dual-Write (Async)
│
â–¼
Gate 1: 0% data drift over 7 days
│
â–¼
Phase 2: Dark Read Verification
│
â–¼
Gate 2: DynamoDB p99 < 15ms for 48h
│
â–¼
Phase 3: 100% Read/Write Cutover
* **Immediate Abort Trigger:** Any data corruption detected during Phase 2 dark reads triggers an instant kill-switch back to PostgreSQL reads.
* **Rollback Time SLA:** < 30 seconds via AWS AppConfig feature flag `USE_DYNAMODB_SESSIONS`.
## 6. Stakeholder Sign-Off
* **Engineering Lead:** Approved (Marcus Vance, 2024-10-18)
* **Product Manager:** Approved (Elena Rostova, 2024-10-19)
* **Security / SRE:** Approved (David Kray, 2024-10-19)
Which Path Fits You?
If your team struggles with analysis paralysis on large refactors…
Standardize on clear primary and counter-metrics to remove subjective debate. Start by running a skill gap audit for engineering managers to ensure your technical leads know how to build proper observability baselines before pitching architectural shifts.
If you are managing an urgent production crisis or sudden platform regression…
Bypass full multi-week template cycles and run a condensed 5-step triage. Use our guide to lead under pressure with fast decision templates to stabilize production telemetry in hours rather than days.
If you are evaluating multi-million dollar vendor contracts or cross-department bets…
An EDR handles team-level architecture, but enterprise business bets require financial scoring models. Read our framework on weighted decision matrices for high-risk ventures to score vendor viability and operational risk side-by-side.
If you are stepping into a new management role and inheriting undocumented architecture…
Establish baseline metrics during your first month before greenlighting any system rewrites. Follow the 90-day plan for new engineering managers to systematically inventory current performance, cost, and reliability bottlenecks.
Take the EDR template above, paste it into your team’s repository as DECISION_TEMPLATE.md, and require it on the next pull request that introduces an architectural change.
Sources & Further Reading
DORA metrics are four standardized software delivery benchmarks—deployment frequency, lead time for changes, change failure rate, and time to restore service—used to evaluate engineering throughput and system stability.
Anchoring your decision-making template in empirical research prevents the team from chasing vanity numbers. According to the Google Cloud DORA State of DevOps Report 2023, elite engineering teams sustain a 7 times lower change failure rate and recover from production incidents in under 60 minutes compared to lower-performing peers.
Metric hygiene also requires understanding statistical variation before reallocating engineering sprints. Research published in Harvard Business Review by Andrew McAfee and Erik Brynjolfsson demonstrated that data-driven organizations achieve 5% to 6% higher operational productivity than their peer group. Pairing statistical process control with clear guardrails ensures that sprint optimizations do not degrade system reliability over a 14-day release cycle.
- Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps, IT Revolution Press — Establishes the statistical link between software delivery performance and organizational stability.
- Google Cloud (2023). State of DevOps Report 2023, DORA — Provides quantitative benchmarks for deployment frequency, recovery times, and failure rates across thousands of engineering teams.
- McAfee, A., & Brynjolfsson, E. (2012). "Big Data: The Management Revolution", Harvard Business Review — Quantifies the productivity differential between intuition-led and data-directed leadership teams.
- Wheeler, D. J. (2000). Understanding Variation: The Key to Managing Chaos, SPC Press — Details statistical process control charts to differentiate systemic software issues from random noise.
- Davenport, T. H., & Harris, J. G. (2007). Competing on Analytics: The New Science of Winning, Harvard Business School Press — Outlines organizational frameworks for building automated analytics pipelines.
Featured image by RDNE Stock project on Pexels