fixed styling issues in the solution

docs/solutions/engineering-360/improve-lead-time.md

@@ -7,15 +7,15 @@ sidebar_position: 5
 
 Lead time for changes is a DORA metric that focuses how long it takes for a desired change to go from initial commit to being successfully deployed in production. Reducing lead time enables faster delivery of value to customers and quicker feedback loops for product teams to test their ideas. In theory (all other things being equal), this leads to higher quality software and increased business agility. By optimizing lead time, organizations can respond more rapidly to market demands.
 
-Lead time is made up of coding time, review time and then integration/deployment time. We'll dig into where a developer portal can help you across each of these categories.
+Lead time is made up of coding time, review time and then integration/deployment time. We will dig into where a developer portal can help you across each of these categories.
 
 ![Lead time for change](/img/solutions/engineering-360/lead-time-for-change.png)
 
 ## Improve coding time 
 
 While coding time is best optimized through stable and detailed requirements, a good development platform and AI enhanced developement tools, the data in the software catalog has a role to play.
 
-Port can enhance the detail on your tasks, through a task-assistance AI Agent
+Port can enhance the detail on your tasks, through a task-assistance AI Agent:
 
 - [Enrich task with AI](/guides/all/enrich-tasks-with-ai/)
 
@@ -24,7 +24,7 @@ Port can enhance the detail on your tasks, through a task-assistance AI Agent
 Review is typically the greatest bottleneck and contributor to long lead times. 
 Changes are still a pain to integrate. We want to protect production from risk, and make sure that the changes meet our standards and will be maintainable for the team in the future.
 
-There are a few ways that Port can help
+There are a few ways that Port can help:
 
 ### Chase PR reviewers
 
@@ -46,9 +46,9 @@ For this, it is useful to measure PR standards, to ensure teams are aligned on t
 
 To a developer looking at tens of Pull Requests that are awaiting their review, all may appear equal.
 However, many factors could influence what order they perform reviews, or how long they spend on each, for example:
-- How long the PR has been open
-- Whether the PR relates to a serious bug or customer escalation
-- Architectural complexity, or other risk factors around the related components that may affect the level of detail on the review
+- How long the PR has been open.
+- Whether the PR relates to a serious bug or customer escalation.
+- Architectural complexity, or other risk factors around the related components that may affect the level of detail on the review.
 - Criticality of the system, or whether the change relates to an important user flow.
 
 Adding this context can help developers prioritize their efforts better
@@ -64,7 +64,7 @@ It could be that there is simply too much to review. Perhaps with a mature devel
 ## Improve deployment time
 
 Once a pull request is merged, the change is integrated, but not yet in production.
-Often, the software needs to be rebuilt, deployed, promoted (once, twice, sometimes even thrice) and sometimes tested along the way. Many issues along the way can lead to deployments that take tens of minutes or even over an hour to complete. Environment preparation, cretion of requisite cloud infrastructure, flaky end-to-end tests, approvals and other factors can cause delays. 
+Often, the software needs to be rebuilt, deployed, promoted (once, twice, sometimes even thrice) and sometimes tested along the way. Many issues along the way can lead to deployments that take tens of minutes or even over an hour to complete. Environment preparation, creation of requisite cloud infrastructure, flaky end-to-end tests, approvals and other factors can cause delays. 
 
 It's worth tracking deployment times across pipelines and looking for outliers. Remember that slow deployments don't just affect lead time, but MTTR too, where fast deployments contribute to faster resolution to incidents that require code changes.
 

docs/solutions/engineering-360/measure-dora-metrics.md

@@ -11,6 +11,10 @@ DORA (DevOps Research and Assessment) metrics are four key measurements that ind
 
 ## Guides
 
+- [Create and track DORA metrics in your portal](/guides/all/create-and-track-dora-metrics-in-your-portal)
+- [Track deployments and incidents from JIRA](/guides/all/setup-dora-metrics-jira)
+- [Track deployments from GitLab merge requests or jobs](/guides/all/set-up-deployments-dora-gitlab)
+
 <iframe
   width="560"
   height="315"
@@ -20,7 +24,3 @@ DORA (DevOps Research and Assessment) metrics are four key measurements that ind
   allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"
   allowfullscreen
 ></iframe>
-
-- [Create and track DORA metrics in your portal](/guides/all/create-and-track-dora-metrics-in-your-portal)
-- [Track deployments and incidents from JIRA](/guides/all/setup-dora-metrics-jira)
-- [Track deployments from GitLab merge requests or jobs](/guides/all/set-up-deployments-dora-gitlab)

docs/solutions/engineering-360/more-engineering-metrics.md

@@ -26,7 +26,7 @@ To reduce it to bullet points:
 - CFR tells you how risky your changes are.
 - MTBF tells you how often you fail.
 
-This is a great example of how port makes it trivial to calculate arbitrary engineering metrics over the rich data in the catalog. Balancing metrics like these are key. After all, a service with a very low MTTR could even be the greatest contributor to the number of incidents and aggregate downtime.
+This is a great example of how Port makes it trivial to calculate arbitrary engineering metrics over the rich data in the catalog. Balancing metrics like these are key. After all, a service with a very low MTTR could even be the greatest contributor to the number of incidents and aggregate downtime.
 
 - [Track and show MTBF for services](/guides/all/track-and-show-mtbf-for-services/)
 

docs/solutions/engineering-360/overview.md

@@ -12,7 +12,7 @@ Engineering leadership and platform engineers face a critical question: Where sh
 ## The journey
 
 Engineering360 is about avoiding the trap of perfectionism when it comes to analysis, and instead optimizing towards immediate measurement, insights and improvement regardless of the maturity of your Development Platform. 
-In the paragraphs below, we'll explore a tried and tested formula for initiating a culture of continuous improvement, in multiple cycles of measurement and improvement.
+In the paragraphs below, we will explore a tried and tested formula for initiating a culture of continuous improvement, in multiple cycles of measurement and improvement.
 
 ### Surveys
 
@@ -27,11 +27,13 @@ During these formative periods, qualitative data from surveys often serves as th
 Don't just make the developer survey yet another administrative task. With the right approach, you can make your developer survey a seminal moment for your new Platform initiative, and communicate the "why" behind it.
 To maximize the impact of your developer survey, involve senior leadership in its rollout, create open channels for feedback, and ensure high participation through reminders and visible engagement. Share anonymized results and insights with the team to demonstrate that their input is valued and leads to meaningful action.
 
-You'll learn more about surveys in the next part of the solution, [surveys](/solutions/engineering-360/surveys).
+You will learn more about surveys in the next part of the solution, [surveys](/solutions/engineering-360/surveys).
 
 ### DORA metrics
 
-DORA (DevOps Research and Assessment) metrics are a set of key performance indicators that help engineering organizations measure and improve their software delivery performance. The four core DORA metrics are:
+DORA (DevOps Research and Assessment) metrics are a set of key performance indicators that help engineering organizations measure and improve their software delivery performance.  
+
+The four core DORA metrics are:
 
 - **Deployment Frequency:** How often your team successfully releases to production.
 - **Lead Time for Changes:** The time it takes for a code commit to reach production.
@@ -40,7 +42,7 @@ DORA (DevOps Research and Assessment) metrics are a set of key performance indic
 
 By tracking these metrics, engineering teams gain a data-driven understanding of their delivery process, identify bottlenecks, and benchmark their performance against industry standards. DORA metrics are widely recognized as a standard for measuring DevOps and engineering effectiveness, helping organizations focus on both speed and stability.
 
-You'll learn more about [DORA metrics](/solutions/engineering-360/measure-dora-metrics) later in this solution.
+You will learn more about [DORA metrics](/solutions/engineering-360/measure-dora-metrics) later in this solution.
 
 ### More engineering metrics and improvement inititatives
 
@@ -52,4 +54,4 @@ Another customer was able to identify Tribes with a materially faster time to 10
 
 Port's flexible data model and managed relations create unique opportunities for measuring sophisticated engineering metrics. Unlike traditional tools that are limited to predefined metrics or siloed data sources, Port can normalize and connect data from across your entire engineering ecosystem. This enables tracking of custom metrics that matter specifically to your organization - whether that's measuring cross-team dependencies, tracking technical debt across multiple repositories, or analyzing the impact of architectural decisions on delivery speed. The managed relations between entities allow for multi-dimensional analysis, helping you understand not just what's happening, but where and why. For example, you could analyze deployment frequency not just by team, but by service type, technology stack, or business domain. This deeper insight helps engineering leaders make more informed decisions about where to focus improvement efforts.
 
-You'll learn more about [measuring arbitrary engineering metrics](/solutions/engineering-360/more-engineering-metrics) later in this solution.
+You will learn more about [measuring arbitrary engineering metrics](/solutions/engineering-360/more-engineering-metrics) later in this solution.

docs/solutions/engineering-360/reduce-mttr.md

@@ -11,11 +11,12 @@ MTTR is influenced by several factors including incident detection time, diagnos
 
 ![MTTR breakdown](/img/solutions/engineering-360/mttr.png)
 
-Remember, the best solution is to prevent and reduce the impact of incidents. Take a look at our [incident management](/solutions/incident-management/prevent-and-minimize-incidents) solution for more.
+Remember, the best solution is to prevent and reduce the impact of incidents. Take a look at our [incident management](/solutions/incident-management/prevent-and-minimize-incidents) solution for more information.
 
 ## Improve incident detection
 
-The faster an incident is detected, the sooner teams can begin working on resolution. Port can help streamline incident detection in several ways:
+The faster an incident is detected, the sooner teams can begin working on resolution.  
+Port can help streamline incident detection in several ways:
 
 - [Create JIRA issue from a NewRelic alert](/guides/all/create-jira-issue-from-newrelic/)
 - [Create a Pagerduty incident from a NewRelic alert](/guides/all/create-pagerduty-incident-from-newrelic-alert/)

docs/solutions/engineering-360/surveys.md

@@ -32,9 +32,9 @@ Alternatively, you can leverage third-party solutions for the survey front-end,
 
 Our most mature customers don't just poll developers periodically, they find the right moments to capture meaningful feedback from developers.
 
-- Ask a new developer for feedback on onboarding after they open their 10th PR
-- Ask the incident team for feedback after an incident is complete
-- Ask a team lead for feedback on an initiative after a service moves up a level in a scorecard
+- Ask a new developer for feedback on onboarding after they open their 10th PR.
+- Ask the incident team for feedback after an incident is complete.
+- Ask a team lead for feedback on an initiative after a service moves up a level in a scorecard.
 
 Because Port observes and maintains a real-time audit history on your engineering data, you can leverage [automations to trigger survey participation](/actions-and-automations/define-automations/) in these moments.
 
@@ -43,19 +43,19 @@ Because Port observes and maintains a real-time audit history on your engineerin
 
 Don't allow surveys to become another "task" for your developers. Here are some techniques from customers who have made the sending of a survey into a more seminal moment:
 
-1. Ask the most senior leadership available (CEO, CTO, VP Engineering) to send out the developer survey, highlighting it's value and the cultural, process and technology changes they hope to discover and drive
-1. Open a separate channel for unstructured, raw feedback and invite engineers to regularly share thoughts, feedback and impressions there
-1. Drive completion of the survey with periodic reminders and later, nudges to engineering managers in charge of participants who have not yet completed it
-1. Show back a dashboard with anonymised summaries of responses, sharing insights with the broader engineering team
-1. Have senior engineering leaders share personal takes and insights from the survey, demonstrating engagement with the data and showing an appreciation for the time taken by their teams
+1. Ask the most senior leadership available (CEO, CTO, VP Engineering) to send out the developer survey, highlighting it's value and the cultural, process and technology changes they hope to discover and drive.
+2. Open a separate channel for unstructured, raw feedback and invite engineers to regularly share thoughts, feedback and impressions there.
+3. Drive completion of the survey with periodic reminders and later, nudges to engineering managers in charge of participants who have not yet completed it.
+4. Show back a dashboard with anonymised summaries of responses, sharing insights with the broader engineering team.
+5. Have senior engineering leaders share personal takes and insights from the survey, demonstrating engagement with the data and showing an appreciation for the time taken by their teams.
 
 ## Review results
 
 ### How to turn survey pain into action
 
 1. **Analyze survey results:** Look for patterns in the feedback. Are developers frustrated by slow CI pipelines, unclear ownership, flaky environments, or lack of documentation? Prioritize issues that are both high-impact and feasible to address.
 2. **Define a scorecard:** Use Port's scorecards to translate the pain point into measurable criteria. For example, if "unclear ownership" is a top complaint, create a scorecard that checks for ownership metadata on all services and components.
-3. **Set up an improvement initiative:** Announce the focus area to the team, explain why it was chosen, and outline the steps you'll take to address it. Make the initiative visible—track progress in Port, share updates, and celebrate wins as improvements are made.
+3. **Set up an improvement initiative:** Announce the focus area to the team, explain why it was chosen, and outline the steps you will take to address it. Make the initiative visible—track progress in Port, share updates, and celebrate wins as improvements are made.
 
 :::tip Example: Turning survey feedback into a scorecard
 If your survey reveals that developers struggle to find the right code owners for services, create a "Ownership Clarity" scorecard. This scorecard could check that every service in your catalog has an assigned owner, and that ownership information is up to date.