{"id":58245,"date":"2026-10-08T12:37:27","date_gmt":"2026-10-08T12:37:27","guid":{"rendered":"https:\/\/www.bridge-global.com\/blog\/?p=58245"},"modified":"2026-10-12T13:58:52","modified_gmt":"2026-10-12T13:58:52","slug":"software-engineering-metrics-delivery","status":"publish","type":"post","link":"https:\/\/www.bridge-global.com\/blog\/software-engineering-metrics-delivery\/","title":{"rendered":"Software Engineering Metrics That Actually Drive Delivery"},"content":{"rendered":"<p>Most engineering dashboards are built on a comforting mistake: more data creates more visibility. It doesn&#039;t. A dashboard packed with commits, tickets, story points, pull requests, and lines of code can still miss the only question that matters to a CTO: are we delivering better software, faster and safer?<\/p>\n<p>In regulated software, that failure is expensive. A healthtech release can meet its schedule and budget targets while introducing defects, security exposure, documentation gaps, or workflow failures that affect patient care. Finance teams face the same problem when a platform ships on time but increases operational risk or creates audit findings. Delivery activity is not delivery value.<\/p>\n<p>The right software engineering metrics program connects four views: product quality, delivery process, people and team health, and business outcomes. DORA measures the delivery system. SPACE adds the human and organizational context. ISO\/IEC 25010:2023 provides a broader quality model so teams don&#039;t reduce product quality to defect counts or test coverage alone. The result is a balanced scorecard, not a leaderboard.<\/p>\n<p><figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2026\/10\/software-engineering-metrics-dashboard-misinterpretation.jpg\" alt=\"A diagram illustrating how excessive data volume and lack of context lead to poor business decision making.\" \/><\/figure>\n<\/p>\n<blockquote>\n<p><strong>Practical rule:<\/strong> If a metric can&#039;t change a decision, remove it from the executive dashboard.<\/p>\n<\/blockquote>\n<h2>Why Most Engineering Dashboards Miss the Point<\/h2>\n<p>A useful dashboard doesn&#039;t try to describe every engineering activity. It exposes the constraints that prevent teams from creating safe, valuable software.<\/p>\n<p>The 1994 Standish Group CHAOS research remains a stark warning. Only 16.2% of software projects in its reported sample were classified as successful, meaning they were completed on time, within budget, and with the required functionality. 52.7% were challenged, while 31.1% were impaired, meaning they were canceled before completion. For challenged projects, the average final cost reached 189% of the original estimate, and the average schedule overrun reached 222% of the initial time estimate.<\/p>\n<p>Those figures don&#039;t prove that more reporting would have saved every project. They show why leaders need measures that reveal delivery health, not just visible activity. A team can increase commit volume while requirements remain unclear, reviews queue up, production incidents rise, and the expected business benefit never arrives.<\/p>\n<h3>The first page should answer four questions<\/h3>\n<p>A CTO&#039;s first dashboard page should stay deliberately small:<\/p>\n<ul>\n<li>\n<p><strong>Are we shipping?<\/strong><\/p>\n<p>Show deployment frequency and change lead time.<\/p>\n<\/li>\n<li>\n<p><strong>Are we shipping safely?<\/strong><\/p>\n<p>Pair change failure rate with failed-deployment recovery time.<\/p>\n<\/li>\n<li>\n<p><strong>Is the product fit for purpose?<\/strong><\/p>\n<p>Show escaped defects, reliability signals, security findings, and relevant quality attributes.<\/p>\n<\/li>\n<li>\n<p><strong>Are we creating value without exhausting the team?<\/strong><\/p>\n<p>Show customer or patient impact, benefits realization, and developer experience signals.<\/p>\n<\/li>\n<\/ul>\n<p>That structure prevents DORA from being mistaken for a complete productivity model. It also keeps product quality and business outcomes visible when delivery throughput improves.<\/p>\n<p><a href=\"https:\/\/www.iso.org\/standard\/78176.html\" target=\"_blank\" rel=\"noopener\">ISO\/IEC 25010:2023<\/a> defines nine software and ICT product quality characteristics, with additional subcharacteristics, as a reference model for specifying, measuring, and evaluating quality. The standard doesn&#039;t prescribe one universal target. It helps teams translate relevant attributes, such as security, reliability, usability, and maintainability, into explicit acceptance criteria for a particular product and risk context.<\/p>\n<h2>The Four Categories Every Metrics Program Needs<\/h2>\n<p>Start by placing every metric into one of four categories. This simple act exposes gaps and prevents one framework from being forced to answer questions it wasn&#039;t designed to answer.<\/p>\n<p><figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2026\/10\/software-engineering-metrics-categories.jpg\" alt=\"A diagram categorizing software engineering metrics into four key areas: product, process, people, and platform development.\" \/><\/figure>\n<\/p>\n<h3>Product metrics describe what users receive<\/h3>\n<p>Product metrics cover defects, reliability, test effectiveness, security findings, maintainability, and usability. In a healthtech platform, that might mean tracking escaped defects in a clinical workflow, failed integrations, vulnerability severity, and whether critical documentation is complete.<\/p>\n<p>Don&#039;t treat test coverage as proof of quality. Coverage can tell you which code execution paths tests reached, but it can&#039;t establish that the product behaves correctly for the people who depend on it. Use the ISO\/IEC 25010 model to connect quality characteristics to product requirements, risk levels, and operational conditions.<\/p>\n<h3>Process metrics expose where delivery slows or fails<\/h3>\n<p>Process metrics describe how work moves from idea to production. DORA belongs here, alongside queue time, review duration, test duration, approval delays, and deployment rework.<\/p>\n<p>A finance engineering team might discover that implementation is quick, but code review and release approval create the dominant wait. The remedy isn&#039;t asking developers to write code faster. It&#039;s redesigning the queue, ownership model, review policy, or automation that holds work back.<\/p>\n<h3>People metrics reveal whether the system is sustainable<\/h3>\n<p>People metrics include satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. These are the five dimensions of the <a href=\"https:\/\/arxiv.org\/html\/2510.24265v2\" target=\"_blank\" rel=\"noopener\">SPACE framework<\/a>.<\/p>\n<p>For an on-call team, people data might reveal that incident response is consuming focus time even when delivery metrics look stable. A developer survey can surface alert fatigue, poor tooling, or weak psychological safety before those problems appear as missed commitments or staff turnover.<\/p>\n<h3>Outcome metrics connect engineering to business responsibility<\/h3>\n<p>Outcome metrics answer whether delivery produced the intended result. Track customer impact, patient-impacting incidents, benefits realization, audit findings, adoption of released capabilities, and operational performance tied to product requirements.<\/p>\n\n\n<figure class=\"wp-block-table\"><table><tr>\n<th>Category<\/th>\n<th>Useful question<\/th>\n<th>Healthtech example<\/th>\n<\/tr>\n<tr>\n<td>Product<\/td>\n<td>Is the software fit for purpose?<\/td>\n<td>Reliability of a clinical workflow<\/td>\n<\/tr>\n<tr>\n<td>Process<\/td>\n<td>How does work reach production?<\/td>\n<td>Review queue and failed deployments<\/td>\n<\/tr>\n<tr>\n<td>People<\/td>\n<td>Can the team sustain delivery?<\/td>\n<td>On-call load and developer experience<\/td>\n<\/tr>\n<tr>\n<td>Outcome<\/td>\n<td>Did the investment create value safely?<\/td>\n<td>Benefits realization and audit findings<\/td>\n<\/tr>\n<\/table><\/figure>\n\n\n<p>This model gives leaders a shared vocabulary. It also clarifies ownership. Teams can use process and product signals to improve their work, while executives review aggregate trends and business outcomes without turning individual activity into a performance score.<\/p>\n<h2>DORA Metrics Done Right<\/h2>\n<p><a href=\"https:\/\/www.ibm.com\/think\/topics\/dora-metrics\" target=\"_blank\" rel=\"noopener\">DORA is widely recognized<\/a> because it measures the delivery system rather than pretending that developer activity equals productivity. Its established indicators are deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time.<\/p>\n<p>The first two describe throughput. Deployment frequency measures how often an application reaches production. Lead time for changes measures the elapsed time from a code change being committed to version control until it is deployed to production. The latter two describe stability. Change failure rate measures the percentage of production deployments that require immediate remediation, while failed-deployment recovery time measures how quickly service is restored.<\/p>\n<h3>Define the events before you publish the numbers<\/h3>\n<p>DORA becomes unreliable when teams use different event boundaries. Decide, in writing:<\/p>\n<ol>\n<li>\n<p><strong>Which event starts lead time?<\/strong><\/p>\n<p>A commit to the production branch is usually more useful than a ticket being created.<\/p>\n<\/li>\n<li>\n<p><strong>What counts as a production deployment?<\/strong><\/p>\n<p>Count successful deployments to the production environment, not commits, pull requests, or sprint completions.<\/p>\n<\/li>\n<li>\n<p><strong>What qualifies as a failed deployment?<\/strong><\/p>\n<p>Define incidents, rollbacks, hotfixes, and other immediate interventions consistently.<\/p>\n<\/li>\n<li>\n<p><strong>When recovery ends?<\/strong><\/p>\n<p>Use genuine service restoration, not the moment someone acknowledges an alert.<\/p>\n<\/li>\n<li>\n<p><strong>How are results segmented?<\/strong><\/p>\n<p>Separate services, release types, and risk classes so a low-risk web change doesn&#039;t hide the profile of a high-risk clinical or financial workflow.<\/p>\n<\/li>\n<\/ol>\n<p>A team that splits one risky release into multiple deployment events may improve the frequency number while changing nothing about delivery capability. A team that avoids classifying deployment-related incidents may lower change failure rate while increasing operational risk. DORA metrics only work when teams review throughput and stability together.<\/p>\n<p>The framework also evolved. Availability was added in 2018, reliability expanded the model in 2021, failed-deployment recovery time was refined in 2023, and deployment rework rate was added in 2024, as documented in <a href=\"https:\/\/dora.dev\/insights\/dora-metrics-history\/\" target=\"_blank\" rel=\"noopener\">DORA&#039;s metrics history<\/a>. Deployment rework rate highlights unplanned deployment activity caused by production incidents, which makes reactive engineering effort visible.<\/p>\n<blockquote>\n<p><strong>DORA is a thermometer, not a target for individual developers.<\/strong> Use it to diagnose the delivery system, then invest in the capability that explains the trend.<\/p>\n<\/blockquote>\n<h2>Beyond DORA with the SPACE Framework<\/h2>\n<p>DORA can tell you that delivery is slowing or instability is rising. It can&#039;t tell you whether developers have the focus, support, trust, or collaboration needed to improve the system.<\/p>\n<p>SPACE addresses that missing context through five dimensions:<\/p>\n<ul>\n<li>\n<p><strong>Satisfaction and well-being<\/strong> show whether people feel supported and able to do sustainable work.<\/p>\n<\/li>\n<li>\n<p><strong>Performance<\/strong> focuses on outcomes such as software reliability, feature completeness, or user satisfaction.<\/p>\n<\/li>\n<li>\n<p><strong>Activity<\/strong> captures observable work, including commits and code reviews, but doesn&#039;t treat those counts as value.<\/p>\n<\/li>\n<li>\n<p><strong>Communication and collaboration<\/strong> reveal how effectively people coordinate and share knowledge.<\/p>\n<\/li>\n<li>\n<p><strong>Efficiency and flow<\/strong> show whether work moves smoothly or stalls through interruptions and queues.<\/p>\n<\/li>\n<\/ul>\n<p>The framework&#039;s central discipline is refusing to reduce productivity to one number. A commit count says that code changed. It doesn&#039;t say whether the change solved a valuable problem, introduced rework, or consumed more review capacity than the team could sustain. Sprint velocity has the same limitation. Story points are useful for a team&#039;s own planning conversations, but they aren&#039;t a defensible measure of individual productivity or customer value.<\/p>\n<h3>Use SPACE to explain, not rank<\/h3>\n<p>Suppose deployment frequency declines while change lead time grows. DORA identifies a delivery problem. SPACE can help explain it. A survey may show that engineers are losing focus to meetings, communication data may expose unclear ownership, and flow data may show that review queues have become the bottleneck.<\/p>\n<p>The opposite pattern matters too. Deployment frequency can increase while developer well-being falls and review effort rises. That isn&#039;t an uncomplicated productivity gain. It may indicate that leadership has shifted cost from coding into validation, support, and maintenance.<\/p>\n<p>Don&#039;t build leaderboards from SPACE dimensions. Ranking teams by activity damages collaboration and encourages people to create visible work rather than useful outcomes. Use team-level signals in retrospectives, capacity decisions, platform investments, and organizational health reviews.<\/p>\n<h2>Instrumenting the Engineering Pipeline for Real Data<\/h2>\n<p>A metrics program is only as credible as its event data. Start with the delivery path, not a dashboarding tool.<\/p>\n<h3>Build the data chain in layers<\/h3>\n<p>Version control supplies commits, branches, pull requests, approvals, merges, and timestamps. CI\/CD systems add build, test, deployment, rollback, and environment events. Production observability connects deployments to service health, incidents, and recovery. Incident management records classification, ownership, intervention, and restoration.<\/p>\n<p>Add two less technical sources. Code review data exposes waiting and review duration. Developer surveys provide the context that system telemetry can&#039;t capture, including focus, tooling friction, and confidence in automated tests. Bridge Global&#039;s guidance on <a href=\"https:\/\/www.bridge-global.com\/blog\/test-automation-methodologies-for-modern-ci-cd-pipelines\/\">test automation methodologies for modern CI\/CD pipelines<\/a> is relevant here because automated feedback must be treated as delivery infrastructure, not merely a testing activity.<\/p>\n<h3>Make the first dashboard operational<\/h3>\n<p>Use a single reporting period and show trends by service and risk class. A useful first page might contain:<\/p>\n\n\n<figure class=\"wp-block-table\"><table><tr>\n<th>Dashboard area<\/th>\n<th>Signal<\/th>\n<\/tr>\n<tr>\n<td>Throughput<\/td>\n<td>Deployment frequency and lead time<\/td>\n<\/tr>\n<tr>\n<td>Stability<\/td>\n<td>Change failure rate and failed-deployment recovery time<\/td>\n<\/tr>\n<tr>\n<td>Quality<\/td>\n<td>Escaped defects, security findings, and relevant ISO quality attributes<\/td>\n<\/tr>\n<tr>\n<td>Flow<\/td>\n<td>Queue time, review duration, test duration, and approval delay<\/td>\n<\/tr>\n<tr>\n<td>Outcomes<\/td>\n<td>Customer impact, audit findings, and benefits realization<\/td>\n<\/tr>\n<tr>\n<td>People<\/td>\n<td>Developer experience and on-call burden<\/td>\n<\/tr>\n<\/table><\/figure>\n\n\n<p>Define missing historical data transparently. Don&#8217;t backfill estimates and present them as measured facts. Mark the point at which instrumentation became reliable, then compare trends from that point forward.<\/p>\n<p>Consider a healthtech SaaS team whose lead time improves after AI-assisted coding is introduced. A closer look shows that code review queues are growing, security remediation takes longer, and documentation work is accumulating. The headline metric improved because one stage accelerated. End-to-end delivery didn&#8217;t improve because the bottleneck moved.<\/p>\n<p>The dashboard should make that movement visible. Segment AI-assisted work where the data supports it, compare the full flow, and investigate queue time alongside lead time rather than celebrating a single favorable trend.<\/p>\n<h2>Metric Pitfalls and How to Prevent Gaming<\/h2>\n<p>Every metric attached to status, compensation, or executive attention will attract optimization. That&#8217;s not a character flaw. It&#8217;s a predictable response to a poorly designed measurement system.<\/p>\n<p>The most common mistake is pairing a target with no countermeasure:<\/p>\n<ul>\n<li>\n<p><strong>Deployment frequency without stability:<\/strong> Teams split one risky release into smaller reported events. Pair frequency with change failure rate, rework, and recovery time.<\/p>\n<\/li>\n<li>\n<p><strong>Low change failure rate without incident integrity:<\/strong> Teams classify fewer incidents as deployment-related. Review incident records, rollbacks, hotfixes, and customer impact together.<\/p>\n<\/li>\n<li>\n<p><strong>Velocity without scope discipline:<\/strong> Teams inflate story estimates or divide work into smaller tickets. Use planning accuracy as a diagnostic, not a productivity target.<\/p>\n<\/li>\n<li>\n<p><strong>Coverage without test quality:<\/strong> Teams count happy-path execution while leaving critical failure modes untested. Review coverage trends alongside escaped defects and risk-based acceptance criteria.<\/p>\n<\/li>\n<li>\n<p><strong>Commit volume without value:<\/strong> Developers create smaller, more frequent commits or generate code that increases review and maintenance work. Track production outcomes and rework instead.<\/p>\n<\/li>\n<\/ul>\n<p>A metrics review should ask what behavior the measure encourages. It should also ask what the number omits. If a team reports faster delivery but support incidents, audit findings, or security remediation are rising, the dashboard is rewarding the wrong system behavior.<\/p>\n<h3>Audit the dashboard for hidden incentives<\/h3>\n<p>Use a short anti-gaming review:<\/p>\n<ol>\n<li>\n<p>Identify who benefits when each metric rises.<\/p>\n<\/li>\n<li>\n<p>List the easiest way to improve the number without improving the product.<\/p>\n<\/li>\n<li>\n<p>Add a paired quality, risk, or outcome guardrail.<\/p>\n<\/li>\n<li>\n<p>Check whether event definitions are consistent across services.<\/p>\n<\/li>\n<li>\n<p>Review trends with the teams that generate the data.<\/p>\n<\/li>\n<li>\n<p>Remove metrics nobody can act on.<\/p>\n<\/li>\n<\/ol>\n<p>Technical debt often explains why a team appears slow or unstable. Bridge Global&#8217;s discussion of <a href=\"https:\/\/www.bridge-global.com\/blog\/technical-debt-in-software-development\/\">technical debt in software development<\/a> provides useful context for treating rework, fragile systems, and maintenance burden as investment signals rather than individual failures.<\/p>\n<p>For leaders assessing broader research and technology trends, <a href=\"https:\/\/1chat.com\/research\" target=\"_blank\" rel=\"noopener\">1chat&#8217;s research page<\/a> can serve as a supplementary research resource. It shouldn&#8217;t replace primary operational data from your repositories, pipelines, incidents, and product systems.<\/p>\n<blockquote>\n<p>A metric without a guardrail is an invitation to optimize the wrong thing.<\/p>\n<\/blockquote>\n<h2>Measuring AI-Assisted Engineering Without Fooling Yourself<\/h2>\n<p>The wrong AI question is, how much code did the tool produce? Generated lines, commits, or pull requests show activity. They don&#8217;t show time-to-safe-value after review, testing, remediation, documentation, and maintenance.<\/p>\n<p>Early evidence makes simplistic productivity claims especially risky. <a href=\"https:\/\/tech-tech.life\/wp-content\/uploads\/2025\/01\/dora-space-devex.pdf\" target=\"_blank\" rel=\"noopener\">One 2025 empirical study reported<\/a> a 31.4% productivity increase from AI-assisted code generation alongside a 23.7% increase in introduced security vulnerabilities. Those figures shouldn&#8217;t be treated as a universal forecast. They demonstrate why throughput must be evaluated with security and quality outcomes.<\/p>\n<p>Track AI-assisted work against:<\/p>\n<ul>\n<li>\n<p>Escaped defects and patient or customer-impacting incidents<\/p>\n<\/li>\n<li>\n<p>Vulnerability severity and security remediation effort<\/p>\n<\/li>\n<li>\n<p>Change failure rate and failed-deployment recovery time<\/p>\n<\/li>\n<li>\n<p>Rework hours and deployment rework rate<\/p>\n<\/li>\n<li>\n<p>Documentation completeness and audit findings<\/p>\n<\/li>\n<li>\n<p>Review effort, test duration, and maintenance burden<\/p>\n<\/li>\n<\/ul>\n<p>Segment the data by AI involvement only when the organization can identify that involvement consistently. A rise in deployment activity may coexist with slower human review or more remediation. Compare teams to their own historical workflow, account for work type and risk, and avoid attributing every change to AI adoption.<\/p>\n<p>Bridge Global&#8217;s article on <a href=\"https:\/\/www.bridge-global.com\/blog\/ai-for-software-development\/\">AI for software development<\/a> offers related context for evaluating AI across the lifecycle. The decision standard should remain simple: did AI reduce total time-to-safe-value without transferring cost into risk, review, or long-term maintenance?<\/p>\n<h2>A Recommended KPI Set and a 30-60-90 Day Rollout<\/h2>\n<p>Use a starter set that a CTO can defend:<\/p>\n<ul>\n<li>\n<p><strong>Throughput:<\/strong> Deployment frequency and change lead time<\/p>\n<\/li>\n<li>\n<p><strong>Stability:<\/strong> Change failure rate, failed-deployment recovery time, and deployment rework rate<\/p>\n<\/li>\n<li>\n<p><strong>Quality and risk:<\/strong> Escaped defects, vulnerability severity, relevant ISO quality characteristics, and audit findings<\/p>\n<\/li>\n<li>\n<p><strong>Flow:<\/strong> Review queue time, test duration, and approval delay<\/p>\n<\/li>\n<li>\n<p><strong>People:<\/strong> SPACE-informed developer experience and on-call burden<\/p>\n<\/li>\n<li>\n<p><strong>Outcomes:<\/strong> Customer or patient impact and benefits realization<\/p>\n<\/li>\n<\/ul>\n<p>During the first 30 days, write the metrics charter, define event boundaries, assign owners, and identify one delivery problem. During the next 60 days, instrument the source systems and publish a team-facing dashboard with transparent definitions. By 90 days, review trends, validate the data with engineering teams, add outcome measures, and remove metrics that don&#8217;t support decisions.<\/p>\n<p>Keep external reporting focused on reliable trends and business outcomes. Keep diagnostic detail, such as queue stages and service-level risk segmentation, available internally to the people who can act on it. For additional perspective on practical IT measurement, see Spark&#8217;s guide to <a href=\"https:\/\/tryspark.co\/i-13-kpi-piu-utilizzati-per-il-reparto-it\/\" target=\"_blank\" rel=\"noopener\">metriche chiave per IT<\/a>.<\/p>\n<p>Your metrics charter can be one page. State the business problem, the metric definitions, the paired guardrails, the decision owner, the reporting cadence, and the action triggered by a concerning trend. That document turns a dashboard from surveillance into an operating system for better engineering.<\/p>\n<hr \/>\n<p>Bridge Global helps healthtech, finance, SaaS, and other product teams connect delivery metrics with secure custom software development, AI-enabled engineering, quality practices, and measurable business outcomes. If your dashboard shows activity but not value, visit <a href=\"https:\/\/www.bridge-global.com\">Bridge Global<\/a> to discuss how to redesign the measurement and delivery system around safer, more reliable software.<\/p><!-- AddThis Advanced Settings generic via filter on the_content --><!-- AddThis Share Buttons generic via filter on the_content -->","protected":false},"excerpt":{"rendered":"<p>Most engineering dashboards are built on a comforting mistake: more data creates more visibility. It doesn&#039;t. A dashboard packed with commits, tickets, story points, pull requests, and lines of code can still miss the only question that matters to a &hellip;<!-- AddThis Advanced Settings generic via filter on get_the_excerpt --><!-- AddThis Share Buttons generic via filter on get_the_excerpt --><\/p>\n","protected":false},"author":165,"featured_media":58244,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[112],"tags":[1933,1934,1975,1976,1977],"class_list":["post-58245","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-custom-software-development","tag-dora-metrics","tag-developer-productivity","tag-software-engineering-metrics","tag-engineering-kpis","tag-ai-coding-measurement"],"featured_image_src":"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2026\/10\/software-engineering-metrics-digital-interface.jpg","author_info":{"display_name":"Upendra Jith","author_link":"https:\/\/www.bridge-global.com\/blog\/author\/upendrajith\/"},"_links":{"self":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/58245","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/users\/165"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/comments?post=58245"}],"version-history":[{"count":2,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/58245\/revisions"}],"predecessor-version":[{"id":58254,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/58245\/revisions\/58254"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media\/58244"}],"wp:attachment":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media?parent=58245"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/categories?post=58245"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/tags?post=58245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}