Fix 'About us' links outside section

An earlier commit fixed some links within the 'About us' section - this
fixes links to 'About us' in other sections

src/staff-handbook/flexible-working.md

@@ -88,7 +88,7 @@ For example, 35 hours in 4 days, from 09:30 to 18:45.
 
 We are happy to discuss compressed hours for all roles but cannot guarantee this
 will always be an option. Arrangements must be
-[sustainable](/who-we-are/#work-at-a-sustainable-pace) for your wellbeing and
+[sustainable](/about-us/our-mission-values-and-principles/#work-at-a-sustainable-pace) for your wellbeing and
 productivity and the needs of the role.
 
 For working patterns with an equal number of hours every day, holiday allowance

src/staff-handbook/when-and-where-you-work.md

@@ -19,7 +19,7 @@ Most developers have maintenance responsibilities, which they do during their
 [support rotation](/work-we-do/supporting-services/#support-rota).
 
 We do our very best to
-[work at a sustainable pace](/who-we-are/#work-at-a-sustainable-pace). But
+[work at a sustainable pace](/about-us/our-mission-values-and-principles/#work-at-a-sustainable-pace). But
 sometimes, when we're approaching a firm deadline or a launch, or a client is
 having an emergency, we work longer hours than normal. From time to time,
 there's an emergency that means we have to work during unsociable hours to solve

src/user-research/choosing-and-using-research-methods.md

@@ -13,7 +13,7 @@ This guide lists our favourite books, articles and videos on the different resea
 
 ## Human centred research and design
 
-At dxw, we follow human centred design practices to [start with people and their needs](/who-we-are/#start-with-people-and-their-needs).
+At dxw, we follow human centred design practices to [start with people and their needs](/about-us/our-mission-values-and-principles/#start-with-people-and-their-needs).
 
 ### Recommended guidance
 

src/user-research/how-we-do-user-research.md

@@ -22,7 +22,7 @@ These are the things that user researchers usually do on projects, and the relev
 
    Researchers take part in project inception. We work with our team to clarify project goals and outcomes, review and make sense of existing evidence, understand what we need to learn through our research, and consider who will need to participate.
 
-   This helps teams to [start with people and their needs](/who-we-are/#start-with-people-and-their-needs).
+   This helps teams to [start with people and their needs](/about-us/our-mission-values-and-principles/#start-with-people-and-their-needs).
 
    [Setting up a project](/delivery-management/setting-up-a-new-project/) \
    [Creating and using research plans](/user-research/creating-and-using-research-plans/)
@@ -52,7 +52,7 @@ These are the things that user researchers usually do on projects, and the relev
 
    This is the most obvious and visible part of our work. We carefully prepare, schedule and carry out effective research activities. We give all our colleagues regular opportunities to take part in research. And we record what we do and how we do it, for each other, and for those who come after us.
 
-   This helps teams to embed regular research into their [agile practices](/who-we-are/#keep-an-agile-mindset).
+   This helps teams to embed regular research into their [agile practices](/about-us/our-mission-values-and-principles/#keep-an-agile-mindset).
 
    [Choosing and using research methods](/user-research/choosing-and-using-research-methods/) \
    [Writing and using discussion guides](/user-research/writing-and-using-discussion-guides/) \

src/work-we-do/sales.md

@@ -84,8 +84,8 @@ consider:
 - **Culture**
 
   We can work together with the client, the users and other stakeholders in ways
-  that support our [values](/who-we-are/#our-values) and
-  [principles](/who-we-are/#our-principles).
+  that support our [values](/about-us/our-mission-values-and-principles/#our-values) and
+  [principles](/about-us/our-mission-values-and-principles/#our-principles).
 
 ## Matching people to projects
 
@@ -138,8 +138,8 @@ By the end of this meeting, we should make sure that we understand:
 This meeting usually involves quite a bit of discussion about the project. In
 those discussions, we speak freely and openly, offering advice where appropriate
 and making any suggestions we might have. We always try to be as
-[helpful](/who-we-are/#helpful), [positive](/who-we-are/#positive) and
-[creative](/who-we-are/#curious) as we can.
+[helpful](/about-us/our-mission-values-and-principles/#helpful), [positive](/about-us/our-mission-values-and-principles/#positive) and
+[creative](/about-us/our-mission-values-and-principles/#curious) as we can.
 
 It's important that we use this meeting to find out the information that we need
 to write a good proposal. But it's just as important to prove our expertise, to

src/work-we-do/supporting-services.md

@@ -66,7 +66,7 @@ we said we'd do, we always respond to say so.
 ### Make a good impression
 
 In tickets as in all things, we are mindful of dxw's
-[values](/who-we-are/#our-values).
+[values](/about-us/our-mission-values-and-principles/#our-values).
 
 Many clients' only routine contact with us is via support tickets, so it's vital
 that their experience of the support system is a good one, and that they have a

src/work-we-do/tone-of-voice.md

@@ -34,7 +34,7 @@ your writing. But remember it’s just a guide.
 
 ## Overall tone of voice
 
-Our [values](/who-we-are/#our-values) should guide how we do things, and how we 
+Our [values](/about-us/our-mission-values-and-principles/#our-values) should guide how we do things, and how we
 communicate. So our writing should show dxw as:
 
 * helpful - we explain our work openly and clearly