Who we are
dxw is an independent digital agency that works with the public and third sectors.
Since 2008, we’ve worked in partnership with our clients to improve people’s lives by designing, building, operating, and improving digital public services. We support the public sector teams we work with to build their own digital capability and take an iterative user-centred approach to service design.
The challenge facing the public sector today is a significant one. There’s more pressure than ever to deliver online services quickly and save money. It’s a huge job and, in addition to talented in-house teams, the sector needs expert suppliers who share their values and understand how to work with them.
We want people’s experience of public services to be positive and seamless. That means creating great services that are accessible to everyone. Our approach is to add value early and often, rapidly researching, testing, learning, and delivering on time. Wherever we can, we work in the open, sharing our code, and what we’ve learned.
Our aim is to help the public sector make the most of the opportunities digital offers to make services better for the people who depend on them. And, ultimately, to free up more resources for essential front line services like education, health and social care, housing, welfare, and policing.
We think that it’s very important to have a talented team if we’re going to succeed. But just as important as raw talent is our ability to work well together. These are the values that we aspire to, and help each other to achieve.
We are helpful, useful and expert. We give practical and pragmatic advice to each other, and to our clients.
We are positive, cheerful and supportive. Even in crisis, we stay optimistic. We assume good faith and offer constructive challenge.
We are reliable, consistent and committed. We make every effort to live up to each others’ expectations, and to exceed the expectations of our clients.
We are honest, trustworthy and straightforward. We give plain-spoken, frank, accurate feedback and advice, and we never mislead or obscure the issue at hand.
We are curious, diverse and creative. We help each other to learn and improve and we’re sensitive to each others’ needs. We love technology and finding new ways to solve problems.
We are determined, discerning and motivated. We believe in high standards, we enjoy doing things properly, and we’re loath to settle for less.
These principles help us live up to our values, and guide our behaviour and decision making in all the things we do at dxw.
Start with people and their needs
At dxw we want to create public services that work well for everyone who depends on them.
We start by understanding the different people who will use and be affected by a service. Wherever possible we work with them to design and test the things they will use.
We actively consider the intended and unintended consequences of our work on people, communities and the planet.
Keep an agile mindset
At dxw, we think that agile is a mindset that’s accepting of change, curious about trying new approaches to make things better, and values careful planning in short chunks.
We think that the Agile Manifesto contains a lot of wisdom, but we don’t follow the industry of methodologies, training and certifications that has grown up around it. We think agile is something you learn to be, not something that you learn to do.
We recognise the importance of compliance and governance, so we build those activities into each step.
Work at a sustainable pace
At dxw, we work at a sustainable pace. We estimate work and schedule it conservatively, and set realistic expectations with clients about the pace of delivery.
This doesn’t mean that we don’t work hard. Being productive is a vital part of maintaining the trust that our clients give us, and it’s important not to let them down.
Balance openness and confidentiality
dxw believes it’s best to be open about what we’re doing. We encourage our clients to do the same, as does the service manual. We talk, blog and write about what we’re doing, and we are open about as much as we can.
At dxw, we release code, publish our contracts and things like this Playbook and talk with people about what we’re up to because we believe that we’ll ultimately have more opportunities to work, grow and improve than if we kept everything to ourselves.
However, there are some things that we must keep private.
- Our clients trust us to host content that is not public, like upcoming announcements and discussions made as part of formulating new policy. This is not our information to be open about, and it’s very important to keep it confidential.
- We also hold some personal data about and/or on behalf of our clients. We never share any of this data, including contact details. See also: data protection.
- We are sometimes sent documents that are protectively marked, and we have a scheme of our own. Information in these documents is confidential.
- Information about work that is currently being procured (whether we are bidding or not) and any other information that could damage the commercial interests of a client or supplier
Diversity and inclusion statement
At dxw, we value people and want them to feel free to be themselves.
We embrace each other’s differences, in gender, religion, beliefs, ethnicity, disability, age, sexual orientation, neurotype, nationality, and identity. We are diverse - like the people we build, design, and create for.
Amazing things happen when we collaborate together. We work in the open and believe everyone’s voices should be heard.
We recognise individual needs and aim to provide a work environment that is accessible, welcoming, and empowering for all. We want everyone to feel supported and included in our wider community.
Our values are more than just words on a page - it’s about constant action and holding ourselves to account.
We’re committed to being transparent with our diversity information and regularly assessing the impact of all our policies and practices.
Thank you for being you - it makes us better.
Reduce our impact on the environment
At dxw we are working to become a more environmentally sustainable company.
We are focusing on three main areas to reduce our impact:
- In our offices we recycle waste where possible. We are switching to environmentally friendly office supplies and refreshments, and changing to renewable energy suppliers.
- We are aware that the digital services we provide have a significant environmental impact. We are finding ways to reduce our contribution by building our products efficiently and using renewable energy for hosting.
- Whenever possible we travel by public transport, and we often work remotely to reduce the need for travel. Due to client needs this isn’t always possible but we’re investigating how to offset our carbon footprint.
Our Advisory Council
dxw does not have external investors or shareholders. To help keep us honest, we are very lucky to have a voluntary Advisory Council, made up of a small group of senior figures, who meet quarterly to discuss and provide guidance on our strategy, business plan and other topics related to company health and progression. The group have a wealth of experience of public and private sector work, as well as being friends of dxw that share our values.
This Playbook is our reference for who we are and the way we do things. Something canonical that tells us what the current “right way” to do things is.
If you’re a current or potential client, this Playbook is also for you. To help you understand us and how we can work together.
We continually update the principles and guides in our Playbook. Because we’re always exploring better ways to get things done. What’s written here is the way we do things now. Until we find something better, and write that down.
This Playbook was originally inspired by Thoughtbot’s excellent playbook. Thanks, Thoughtbot!
Updating the Playbook
This Playbook is a collaborative effort. Anyone at dxw can and should edit it. So if you spot something that’s wrong, feel free to hop in and correct it.
But remember that this Playbook is the result of our conversations about how we should do things, not a substitute for one. So don’t make changes unless they reflect our shared agreement about how things are going to be done.
This document is also public, because there is very little about our process that cannot be open. But there will be some things that should be private. So don’t forget that changes here get published to the world.
To update the Playbook, follow the guide to Contributing to the Playbook and use dxw Tone of voice.
The work we do
Most of our projects are to research, design , build and support digital services for the public sector and organisations focused on work for ‘public good’. Broadly speaking, they are usually transactional services (making payments, bookings, reporting things or informational services (corporate websites, campaigns, intranets). Sometimes they’re a bit of both.
In so doing, we try to make sure that the organisations we’re working with will be able to operate their new services well and sustainably. This sometimes involves work that an agency might not normally do, like advising an organisation’s leaders on how their teams could be restructured, or on what their digital strategy could be.
With the development of dxw digital’s strategy team, we are increasingly targeting more strategy-shaped opportunities, to help our clients prepare for, or improve the delivery of digital projects.
We also help clients host some of the services that we build, and by selling subscription-based products that are related to the rest of our work.
We bid on opportunities through a range of channels.
Some of our opportunities arrive directly, often via email, as a result of recommendations, word-of-mouth or through our active engagement and networking in the digital and public sector community.
We also take on work that is received for existing services via helpdesk tickets.
Most of the larger opportunities we bid on arrive via more formal channels like public sector framework agreements such as the Digital Marketplace.
When any opportunity arrives, we record it in our CRM tool, Hubspot. This happens automatically for opportunities published on the Digital Marketplace Outcomes and Specialists framework. Other opportunities are entered individually into Hubspot if they arrive to a specific person.
We record as much information as we can about opportunities when they arrive. An opportunity should be described in enough detail that someone else in the team could pick it up and work on it if needs be. That means that we always record a sensible name, the details of the organisation and where possible, we associate the opportunity to the Hubspot contact and company record of the person we’re talking to. If they have provided any documents, we upload those into Hubspot as well.
Opportunities go through several stages during their life, to show whether we’re waiting for more information, waiting for a meeting, writing a proposal and so on. For opportunities that we’re bidding on via the Digital Marketplace, our process mirrors the timelines buyers publish in alignment with these standard procurement rules.
When the process ends, a lead will either be won or lost.
Screening potential projects
At dxw our mission is to help create public services that improve people’s lives. Whether we achieve this depends a lot on the work we choose to do. We encourage an open and honest discussion about which work we take on. And we actively seek different perspectives, both inside and outside of dxw.
To decide whether a potential project is ethical and supports our mission, we consider:
The work is beneficial to the public, the client and dxw.
We can produce a great result within the likely constraints.
Matching people to projects
We understand that members of staff may have ethical, religious or other concerns about working on a particular project. If you do have concerns about a project, please raise them with your line manager or head of profession.
Clients aren’t always able to talk about their budgets, but we do need to know. If they absolutely can’t tell us, we do our best to estimate at what it probably is, based on the information we have.
Where we don’t think we could do what the client needs within their budget, we explore alternative options with them that are more affordable. Sometimes this works out, sometimes not. That’s ok. Where it does, it tends to be because we’ve made a good case that it’s better to have a small feature set that works really well than a large one that’s slightly disappointing.
Where clients have a larger budget than we think they need, we say that too. This usually means explaining why we’re able to do the work for less than they thought. We also think about what extra things we could do to improve their chances of success and suggest extra work they could do.
Where a budget is disclosed that’s more than we think is necessary, we usually propose a piece of work that uses that budget fully. But we’re always open, and tell them that we’ve done this, and that we’d be delivering more than the minimum. And we’re always happy to win a smaller bit of work than the client thought they’d need. We try to structure these proposals so that the extra work is easy to remove.
Wherever possible, we meet prospective clients before writing a proposal. This is because face-to-face conversation is the most efficient way to communicate, and the projects we bid for are often complex. Sometimes, this meeting is the way we qualify an opportunity.
By the end of this meeting, we should make sure that we understand:
- Who the client’s users are
- The user needs the client is trying to meet
- Their current vision for how those needs will be met
- Any notable technical requirements
- What the project’s budget and deadlines are
- How many suppliers are likely to be bidding
- When they need to receive our proposal by
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, positive and creative 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 deliver value early and to leave the client with a positive first impression.
Proposals and tenders
If the project is being tendered via a fixed process (such as the Digital Marketplace, ) we’ll respond by following the process that the client requests.
Bid writing is a team sport at dxw, so it’s important to involve the potential delivery team in the planning, writing and reviewing of the bid. This is important as it helps to set the team up for a successful pitch (if we need to do one) and eventual delivery if we win the work.
Whilst the process tends to be similar, not all opportunities are exactly the same, for example, sometimes we’ll be provided will a form to complete, and other times we’ll have more flexibility on the format of our proposal.
If we’re writing a proposal following our own format, we often start from a proposal template. The main things we’ll often need to write are:
- A description of the project’s background. How did they get to the point they’re at now?
- A description of the client’s vision. What are they trying to do?
- An initial set of user needs. How does the client believe their service or project will make things better for these people?
- Details of how we’ll approach the work
- A proposed team to do the work, their roles and profiles.
- How many sprints we estimate we will we need to deliver the work.
- A timeline for when we expect the sprints and other work will happen.
- A cost for the work.
There are lots of examples of these proposals that anyone at dxw can read if they like.
When we win work, we mark it as Won in Hubspot. We amend the budget, closing date and services sold if necessary. We write to the client to thank them and ask them for a convenient time to meet and talk about how and when we’ll start the work. We talk to the scheduling team and add the project’s sprints and other work to our scheduling tool 10000ft, so that the team can see who’s working on what. And we talk to the finance team so that invoices can be created as drafts in our finance system Xero, so we don’t forget to bill them.
We don’t always win work we bid for, particularly when it is run via a competitive tendering process, such as on the Digital Outcomes and Specialists framework.
When we lose work, we mark it as Lost in Hubspot. We write to the client to thank them for their interest and ask them for any feedback they might have. We usually also say that we’d be happy to talk about any future work they might have. We record the main reason we didn’t win the work in Hubspot along with the detailed feedback.
We do our best to incorporate this feedback into future bids.
Some opportunities, upon review with the team or following discussions with the client, turn out not to be dxw-shaped things. This could be for lots of reasons - capacity, capability, location and so on. This is okay. When this happens, we update the client as soon as we can, explaining the reasons for our decision. We mark these opportunities as No bid in Hubspot, recording the main reason we made this decision, along with any context.
One of the things our clients value most is responsiveness. Many will be under pressure to get things done quickly, and will be expected by their colleagues and managers to know what is going on at any given time, and to manage us effectively. If we’re not quick to respond to their queries, questions and concerns, we reduce their ability to maintain the confidence of their colleagues.
So, when we are on sprints, we endeavour to respond to our client quickly. It’s not always possible to resolve a problem or get an answer quickly, but that shouldn’t stop us from acknowledging a message or giving regular updates. As with tickets, being responsive to a query is just as important as giving a definitive answer.
When we get enquiries for clients who are not currently sprinting, we still answer as quickly as we can - but clients who are sprinting come first.
We also expect most communication with clients to happen with the project’s delivery lead. We don’t hide anyone on the team from the client, and they are free to ask questions of whomever they wish. But if you’re a developer and you get a question that’s really for a delivery lead to answer, refer the client on. This will help to keep you productive, and will help the client understand who on the dxw team does what.
Progress in every sprint
Delivering projects in an agile way requires trust between everyone involved in delivery. Clients must have confidence in us for the process to work. One of the quickest ways to lose confidence is to finish sprints with little to show for the effort we’ve made. In all of our work, we maintain a clear relationship between sprints and their associated costs, and visible, tangible changes to the service we’re working on.
This means that we structure work so that visible progress and supporting back-end work happens side-by-side. We don’t work on back-end or supporting code first, and then bolt front-ends on later. We make sure that what we’re doing is visible to our clients as early as possible. This helps us to maintain trust, and gives us more opportunities to learn what works and what doesn’t by involving users of the service in testing.
We involve clients in every aspect of our work. Projects work best when everyone involved feels part of the same team. So, other than the internal retro, there’s no aspect of our process that we do without client involvement.
In particular, we should go out of our way to involve clients when decisions are being made about design, user needs, or strategy (among other things). We’re not here to make decisions for our clients: we’re here to help them to make good decisions themselves. So we shouldn’t make decisions about important things without them.
This isn’t to say that we require clients to participate in everything. Clients and projects have varying needs, so this aspect of the process is flexible. But we always make the option of involvement available. If they want to join daily standups as well as participate in sprint planning, they can.
The structure of a project
At dxw we follow the Government Service Manual and our projects move through discovery, alpha, beta, live and retirement phases.
One change to our approach is the addition of an Inception phase at the start of a project, before discovery. We think this phase is necessary to set up a single team with our clients, establish ways of working, and get everyone behind a shared vision and goals for the project.
At a high level, we believe the purpose of each phase is:
Inception: Establish a single, multi-disciplinary team with the client. Bring everyone together for a kick-off session to agree principles for how we’ll work together. Run a roadmapping workshop to define a set of goals and vision for the project. The roadmap also clearly defines dependencies and risks, and a list of things to learn or prove to form the basis of a user research plan.
Discovery: Carry out research to define users and understand their needs. Document findings, user needs and user journeys. Sometimes this phase also involves conducting technical discovery work to look at different technologies and solutions that might meet users’ needs.
Alpha: Translate user needs into prototypes. Test prototypes with users and iterate them based on feedback. We also use the alpha phase to carry out technical spikes and experiments, and to make initial technology and service design decisions.
Beta: Build a working version of the service, based on what we learnt in alpha. Carry out regular usability testing of the service with users, and launch a minimum viable product. Make plans for supporting the service and continue iterating it.
Live: Operate the service, carry out regular user research and continue to iterate it. If new user needs are identified, we develop the service and launch new features to meet them.
Retirement: Work out how user needs will be met without your service. Provide help and guidance, archiving, and links to other services. Don’t leave people in the lurch; never let a link die.
We don’t always do all these phases for every client. Often, we’ll only be involved in a couple. But we can help with all or any of them, depending on our clients’ needs.
We break down projects into two-week sprints. Throughout a project we maintain a product backlog, refine user stories based on what we learn and carry out development work to meet the user needs that have been identified.
Every project, client and team is different. But, there are some common approaches we take to all projects.
On the first day of a sprint we facilitate a planning session and finish sprints with a show and tell and retrospective. These sessions involve the whole team, including developers, user researchers, designers and delivery leads, as well as the product owner and other members of the client team.
Every morning a delivery lead facilitates a standup. Standups last 5-10 minutes and are for the team to discuss what they’re working on that day and whether there are any problems or dependencies affecting them. If the team is not co-located with a client, standups happen over a video-call.
During the sprints a delivery lead will share a week note, usually on a Friday, with everyone involved or interested in the project. The note will include a brief summary of what the team have done that week, what is planned for the following week and highlight blockers, dependencies or things the team is thinking about too.
At the end of each sprint the team run a show and tell. This is an opportunity for the team to show the work they have done on that sprint and allows people involved in the project to see what has been achieved. We work in an open and transparent way so encourage anyone interested in the project to attend the show and tell and ask questions.
Sprints begin with a planning session, where the whole team (dxw and the client) review and prioritise the stories in the backlog. Working together, we discuss the stories that we are prioritising for the current sprint, ensuring that they are well-formed and understood by everyone in the team.
Often this involves writing new stories and updating existing ones, but we try to avoid this becoming the main purpose of the meeting. In our experience, sprint planning is much more useful when the stories are written in advance.
During this session, developers discuss the effort required to finish each story. We discuss effort so we know whether we have a reasonable amount of stories to work on and we’re confident as a team that we can get through the stories in the backlog. Sometimes we will estimate stories. We do this based on complexity, not the time we think it will take to finish it.
Once estimated, stories are prioritised by the client and put into the backlog for the sprint. Developers also advise the rest of the team at this point if there are any technical dependencies the client should be aware of. By the end of the session, the full team should be confident about the goal of the sprint and what is going to be worked on.
Inspect and adapt our work
At the end of every sprint, a delivery lead facilitates a retrospective where the team discuss how the sprint went. We talk about what went well, what didn’t, and what we can do to to improve how we work for the next sprint. These sessions are attended by all the people involved in delivering the sprint along with the client team. We use retros to make sure we acknowledge and continue to do the things that are working well, and also commit to change anything that can be improved.
Focus on user needs
At regular intervals the team look through the sprint backlog to re-prioritise and update stories, based on things we’ve learned during delivery and from user research. Stories that are no longer needed are deleted, stories that may be needed later or are blocked are put on hold (we call this the icebox) and all other stories are re-prioritised for future sprints.
We have regular user research playback sessions to ensure the whole team is involved in understanding user needs, feedback from user testing and what iterations means for the users.
We document development work that needs to be completed by writing user stories.
A user story is a succinct explanation of some work that will be done in order to meet the needs of a particular kind of user. They are usually structured into a sentence, of the form:
As a [kind of user], so that I can [meet a need], I want [a feature in the product]
Breaking everything down into user stories allows us to be confident that everything we develop is meeting user needs. By using this story format, we directly associate a feature or piece of functionality we’re building with the group of users who want it and the needs that they have.
We keep lists of stories in Trello. We use user needs to create the title of a story, by rearranging it to reflect the new state of the system after the work is complete. For example:
As an administrator, so that I can ensure I don’t publish defamatory comments, I want to be able to review and approve comments before they are shown.
Might have a title of:
Administrators can review and approve comments before they are shown
Each user story will also contain a list of acceptance criteria. Acceptance criteria are a collection of statements about the functionality of the service which must be true in order for the story to be considered “done”.
For more information about writing good stories, we recommend reading User Stories Applied by Mike Cohn. There is a copy of this book in the dxw library.
Lifecycle of a story
There are several states that a story has to go through in order to be deployed to production. We use Trello and physical story boards to keep track of which stage a given story is in.
- In progress: A developer has started working on the story, making changes to the product to ensure that each acceptance criterion is met
- Awaiting review: The developer has finished the story and is ready for a second developer to review the technical aspects of the story in a pull request
- Code review: The story is being reviewed by the second developer who leaves feedback if the pull request is not ready to be merged and needs further work
- dxw/client review: The two developers have finished the review and the story has been merged and pushed to staging. It is ready for a delivery lead and the client to review against its acceptance criteria
- Accepted: The client has accepted the story and it’s ready to deploy to production
- Done: The story has been deployed to production
“The delivery manager sets the team up for successful delivery. They remove obstacles, or blockers to progress, constantly helping the team become more self organising. They enable the work a team does rather than impose how it’s done.” –Government Digital Service
At dxw, delivery leads ensure that sprints go smoothly and that the team remain productive. They are generally the client’s first and main point of contact, and are responsible for ensuring that we deliver good work.
Throughout a sprint, delivery leads ensure that agreed process is followed, organising and facilitating discussions as required. They run sprint planning and retrospective sessions. They run daily standups with the dxw and client teams to keep everyone informed and to discuss and resolve any blockers.
Outside of these sessions and standups, they maintain regular communication with the client and the delivery team to respond quickly to challenges as they arise. If priorities change during a sprint, the delivery lead works with the client to understand and plan for the impact of the change.
Hosting and supporting services
GovPress is dxw’s hosting platform which hosts the WordPress websites we build for the public sector.
We built GovPress because our clients were frequently asking us for secure, scalable and highly available hosting, but didn’t have enough budget to be able to build an appropriate hosting platform for their service. This is fair enough, because they shouldn’t have to. We built GovPress to meet this need, and it is now used by most of our clients.
We offer managed hosting and support for WordPress websites, as well as blogging and campaigns platforms, through the G-Cloud framework, configured to our client’s branding requirements, all on our GovPress hosting platform.
You can read more about GovPress at www.govpress.com.
We also offer support for services that aren’t built in WordPress. We are able to host and support services with our tailored support plan for cloud applications, even if your service isn’t hosted with us.
The dxw Technical Operations team build, manage and run GovPress, as well as provide first-line support.
We use Zendesk to manage support requests. Any incidents, requests for us to fix a problem or make a change to a site must come to us via Zendesk as a ticket. We use tickets to manage requests in order to:
- Keep track of all the things we need to do, and what state they’re in, for us and our clients
- Have a record of the changes we’re asked to make
- Ensure that we only accept change requests from people who are authorised
- Generate data about how much staff time is spent on each client’s issues.
If a client asks us to do something in person, on the phone or via email, we ask them to visit the dxw Zendesk, and submit a ticket there. This is so that:
- We can keep track of the issue from report to solution, and ensure that it’s assigned to the right person;
- We don’t risk misunderstanding the problem by writing it down based on a verbal explanation
- We can formally track the changes that people ask for, by documenting them in tickets that we can look at later if we need to
For these reasons, we do not do any work on a client website or service unless we are working during scheduled development time or on a relevant ticket. We think this is really important.
We work on tickets by having a developer on support according to a rota. Developers are assigned to support for one week at a time and work on tickets for the whole week. If there is a ticket they need another developer to help with, this work is scheduled.
Client experience (AKA: ticket principles)
Clients expect us to deal with their issues promptly. But they understand that this isn’t always possible. They are generally forgiving of the fact that we’re sometimes busy, and they understand that some issues are complex and require long investigations.
The thing most clients value above all else is being kept informed of what is going on. The first quality of a good ticket experience is responsiveness: we keep clients informed of what we’re doing, even if there hasn’t been much progress.
Stick to your commitments
It’s really important that we do what we say we’ll do, and don’t promise things we can’t deliver. If we’re unable to deal with a ticket in good time and leave an update saying we’ll work on it tomorrow, we must meet that commitment.
It is doubly bad to fail to meet a commitment and not say anything about it. Responsiveness is always the priority. So if for some reason we couldn’t do what 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.
Most clients’ routine contact with us is via support tickets, so it’s vital that our clients’ experience of the support system is a good one, and also that they have a positive experience with us personally.
We are always considerate, and think about what style of response is best. For example, technical clients may appreciate short, information-dense responses, while non-technical clients might perceive that style as rude or dismissive.
- We are personable, friendly and helpful
- If things look like they’re going to get difficult or the client seems unhappy, we are honest and assume good faith
- If we screw something up, we take responsibility and apologise. If the client seems very upset, we let a delivery lead know.
- If we do become annoyed or frustrated by a ticket, we respond later or speak to a delivery lead about reassigning it.
Of course, every client would like us to go the extra mile to solve their problem. But they also understand that to do that for them would mean bad service for another client - or that we never get to their issue, because we’re too busy gold-plating the solution to someone else’s.
While we do everything we can to make sure the client is happy with our solution, we are also mindful of what’s practical. We don’t do serious bits of development work on tickets, or trial new approaches. We don’t play with new tools or sink hours into interesting bugs. We set those things aside, and do them later.
The main purpose of a ticket is to take some action that solves the problem, as quickly as possible. Generally speaking, we do the most time-efficient thing that we can. Of several potential solutions that solve the problem, assuming none is a bad one, we do the one which can be implemented the most quickly.
Deciding what to work on
Developers on support are free to work on whichever tickets they are assigned to and think is most important. But there are some important things to bear in mind.
We all have limited time. We try to spend it wisely. All other things being equal, it is better to spend half an hour solving each of four tickets than to spend two hours on one issue.
The priority of tickets is important, and we must be biased towards dealing with more urgent tickets before less urgent ones.
Each ticket’s priority should be reviewed regularly: whenever we update a ticket, we check the priority to make sure it’s still right.
It’s important that we don’t make changes unless we thoroughly understand what we’re being asked to do, and are confident that the client understands and has approved of the implications of the change.
Replicate the bug
If the issue is a bug, we replicate the behaviour the client has reported before working on a fix. It’s important that we can reliably and repeatably create the conditions necessary for the bug to arise before we start working on it. If we don’t do this, we can’t tell whether we’ve fixed the problem.
Ensure the client has understood and approved the change
When presented with a problem, clients don’t always ask us to do the most appropriate thing to fix it. Sometimes we can think of a better solution. Sometimes the change the client asks for has some implication that they haven’t considered.
Our helpdesk service is advisory, so we’re not afraid to suggest alternative approaches and ideas if we have them - including where there’s a better solution, but at a cost. We always give options when we can.
Clients can use the support service to ask for help with any aspect of the service we provide, including help with using the admin panel and advice on getting the best out of their site.
But there are some limitations. Under the support service, we do not:
- Add any new functionality requiring anything beyond extremely trivial development. This does not generally include installing plugins: checking and installing plugins is allowed
- Alter the source code of a plugin or library maintained by a third party
- Do things that the client can do for themselves in the WordPress administration area. In this situation, help them by letting them know the steps to take to achieve whatever they’re trying to do.
- Other than by prior arrangement, communicate on the client’s behalf with the operators of third-party services that the site uses
- Install a plugin that fails an inspection
- Do research to identify plugins to solve a particular problem. It’s fine to recommend something that we already know of, but in this situation, we usually ask the client to do some searches on the WordPress Directory and suggest one, which we can then check and install.
- Fix complex problems that come up after a plugin or WordPress core update is applied. Exactly what constitutes a complex problem is at our discretion. But if we’ve spent a couple of hours on an update-related bug and it’s still not fixed, we’re probably dealing with one.
- From time to time, we may make an exception to these restrictions. If you think that might be appropriate, ask a delivery lead. In all the above cases, we can offer to quote for the required work.
Charging for ticket work
If you decide that a ticket asks for work to be done which falls outside this scope, then the work is chargeable. In this situation, we reassign the ticket to a delivery lead or someone from the client services team with an explanation.
It is good to try to think of alternative approaches that we could do under our support service before taking this step - seek advice if you’re unsure.
The person you assign the ticket to will then treat it as a lead, and contact the client to make a plan.
Sharing our expertise
We all go to work-related events and conferences, sometimes for work and sometimes in our personal time. No matter what capacity you’re attending an event in, you are a representative of dxw. What you say and do will influence the way people think about the company. It’s important that you make a positive impression.
We encourage everyone to network and talk about dxw’s work. Remember to tell people if we’re hiring and point them to our careers page on the dxw website.
Speaking at events
Speaking at events is a great opportunity to represent dxw.
If it’s an event around your personal speciality (front-end development, sysops, UX etc), feel free to stick to any personal branding, slide format, or talk style you might have already developed. At the start of your talk however, please introduce yourself as being from dxw, talk about what the company does, and what you do here.
If it’s an event more around dxw’s focus (public sector events, dxw projects, public-sector specific topic etc) you should use dxw’s branding and slide templates. Introduce the company in full and what your role is.
It takes time to prepare talks that work well. If you need help or advice please ask for it in the #dxw-marketing channel on Slack.
It’s also good to blog after the event, to share the content or to talk about your experience and what you learned.
If you need time to be set aside to prepare or follow up a talk, talk to your delivery lead and see what’s possible.
At dxw, we encourage people to blog regularly. Both on the dxw blog, and on personal and community blogs.
We blog because we want to share what we’re doing and what we’re learning with the public sector digital community. We work in the open and are keen to share our knowledge, express our values and get people thinking about how to improve services for the public sector.
When we’re hiring, we also want potential new staff to be able to to get to know us beforehand.
When we blog we use the dxw tone of voice.
We record ideas for blog posts and the schedule for publishing on a Trello board. This is managed by the marketing team, who can offer you help and advice on ideas and support with writing if you need it. They will also manage the final sign off and publishing of posts. Get in touch through the #dxw-marketing channel on Slack.
The marketing team run dxw’s official Twitter account.
When we tweet we use the dxw tone of voice.
We encourage people to work openly and to tweet about the work they’re doing, their learning and ideas from their own accounts. You should be careful not to share any confidential information and check that people are content before using any pictures of them. Remember that you are representing dxw whether or not you identify yourself as working here in your Twitter profile.
Managing your day to day work
Our working hours are 10:00-18:00, Monday to Friday. Some people work different hours by arrangement. Anyone is free to do that as long as their hours of work don’t make it hard for other people to get things done. For example, many people arrive earlier than 10:00 and leave earlier, which is generally fine.
Each team has a short standup every morning, where we each tell the whole team about a single thing we will get done that day. If you think you’re going to be late, you should let everyone know in the project Slack channel.
Most developers have maintenance responsibilities, which they do during their support rotation.
We do our very best to 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 the problem. Neither of these happen very often, but they are a normal part of life at dxw.
Sending emails or posting in Slack outside of working hours can be a good way to get things off your mind, but it can create an unintended sense of urgency for the people who receive your message. Try to avoid creating that urgency when it’s not necessary. For example, by specifically saying that you don’t expect an immediate response.
Unless they are actually urgent, you can ignore messages you receive outside of working hours and handle them when you are back at work.
Monday to Thursday
Client facing: We charge clients “time and materials” for the work we do, based on a per person day rate. We generally schedule team members to work on particular projects for a whole sprint at a time, and track and bill that time in half days and whole days. Delivery leads work with the finance team to track and invoice the time of the team; having regularly patterned working helps the process to run as smoothly as possible, without confusion and without taking more time than needed. Any working arrangement needs to make it straightforward to track, report and invoice for your time.
When working on a project we work as a single multi-disciplinary team. We’re often working on phases of projects where there’s a lot of unknowns and a lot of learning, so we use agile approaches and strongly favour being able to work together on problems. That’s often easier when co-located, particularly when working with clients, pairing, or participating in workshops. Any working arrangement needs to support active synchronous collaboration with the team.
Internal facing: Internal facing roles, in which time is not billable to a client, have a more regularly structured five day working week. Everybody is encouraged to take part in Friday work, at least occasionally.
We regularly come back together as a team to work on our own projects and processes, normally each Friday. These dxw days are important for us to maintain our strong culture and identity, separate from the clients we work for. Our sprints start on a Wednesday and end on the Tuesday two weeks later.
Working from home
Generally, we work either at our office or at client sites. But it’s usually fine to work from home from time to time, or in order to complete a specific task. If you’re working apart from your team, it is essential that you remain contactable and productive, and the onus is on you to be especially communicative.
Reporting your time
Everyone who works on a client project at dxw is responsible for reporting the time they spend on projects. We usually work with our clients on a time and materials basis, so it’s important we can accurately track and report how our time is spent on client projects.
We use 10,000ft to schedule our work, which helps us to forecast our capacity over future weeks and months in a reliable way.
We track our time at the same level of granularity that we bill it – for almost everyone in the team, that’s half days or whole days.
What to do when reporting your time
When reporting our time, we follow these guidelines:
- If what was scheduled matches reality, simply confirm this time.
- If you worked on a named project (client or internal including “dxw Support”), that differs from the schedule, record your time as that.
- If you worked on something else, leave the time blank or zero out what you were scheduled to work on.
- If you were away on planned leave, confirm your time as “Out of office”.
- If you were off sick, record your time as “Sick”.
- If you had unplanned leave, record your time as “Out of office”.
- If you were away due to a regular day off, as part of your working pattern, leave the time blank or zero out what you were scheduled to work on.
If you’re not doing client work, then unless you’re working on one of a handful of named internal projects or support, you don’t need to record your time against any other piece of work – the assumption is you’re doing valuable work, whether it’s learning, helping with recruitment or improving our tooling and processes, and we don’t need itemised time tracking to justify that.
We’ve set up the platform, so that it understands individual team members’ working patterns. This means the team don’t need to worry about entering in their non working days.
Our delivery leads lend a helping hand when delivery team members aren’t sure how to record their time – they’ve been doing this for a long while and have a well developed sense for it.
Getting things you need
Anytime you need to order something, notice a problem in the office (e.g. a broken chair or dripping tap) or you need some help with your laptop or the printer - there is a Slack channel for it. If in doubt, please speak to the Commercial Operations team and they’ll point you in the right direction.
#help-facilities #help-purchasing #help-travel #help-techsupport
From time to time, some of us spend our own money at work. Most often, this is things like:
- Train fares for unexpected travel
- Refreshments purchased for meetings with clients
- Stationery/materials, especially for workshops or events
dxw will always pay expenses which are:
- Necessary: We only expense things we need in order to be able to complete our work
- Proportionate: The total expense should be proportionate to the work at hand. In general, we try to avoid spending lots of money. For example, unless you have a good reason, don’t get a cab to a meeting when you could get a train.
Wherever possible, it’s best to check that expenses can be reclaimed before incurring them.
We manage expenses using Xero. For more information about how to do this, see the guide on claiming expenses
Calendars and documents
We use Google Apps for Work to manage calendars, write and share documents. There is a dxw folder where we share most of the things we write. If you can’t see it when you log in to Google Drive, you’ll need to ask someone else to send you the link, and then click “Add to drive”.
When we write new things, we try to save them in a sensible folder within the existing structure.
Internal tech support
If you experience problems with the office printers, wi-fi, video conference set-up, Macs etc… You may send a message in the #help-techsupport Slack channel.
Using a personal device at work
Most of us use at least one personal device as part of our work, because it’s more convenient than carrying lots of devices around. However, no one is obligated to use a personal device for work. If you need a dxw-provided phone, tablet or other device, please ask for one.
Anyone who does use a personal device must take reasonable care to ensure that it cannot compromise dxw’s security. This includes implementing prudent security measures, being mindful that your personal devices could be targeted as part of an attack on dxw or its clients. For example, you might receive an email to your personal email address designed to trick you into revealing a work-related password.
Exactly what security measures are prudent may vary depending on the device and what you’re using it for. Some good practice examples are:
- Configuring screens to lock after a period of inactivity
- Ensuring that work-related data on the device is regularly backed up
- Encrypting storage
- Using good passwords and changing defaults
- Avoiding connecting devices to untrustworthy networks (internet cafes, security conferences, unencrypted (open) wifi networks, etc)
- Disposing of your device securely when you no longer need it
If you need to use a personal device but cannot take these sorts of measures, you should get permission first.
Report a lost or stolen device used for work
Submit an urgent ticket by sending an email to email@example.com stating which work device was lost or stolen and when the incident had occurred.
Our support staff will be immediately notified, at any time of day.
Though dxw doesn’t control much personal data, our clients generally do. And some of it may be held on sites that we host. Everyone at dxw has a responsibility to keep that data safe, and process it in accordance with the data protection principles.
In particular, we:
- Only process personal data as part of work on the service that we’re contracted to provide to a client
- Don’t access personal data unless we need to in order to do our jobs: don’t read people’s personal data or private communications without good reason
- We do not ever disclose people’s personal data to anyone outside dxw unless specifically instructed, and are satisfied that it is legal to do so
If you have any questions about data protection, talk to Harry.
Protective marking scheme
Some information that we have is confidential. We use a protective marking scheme so that everyone understands how to handle this material, and who they’re allowed to disclose it to. All of the documents and data we hold will fall into one of the categories below.
- Management-in-Confidence: internal documents whose circulation within dxw needs to be restricted.
- Company Confidential: information owned by dxw which would be of value to those outside the company, such as competitors, and whose loss or theft would potentially damage the company.
- Client Confidential or Commercial in Confidence: information owned by dxw or its clients, which needs to remain confidential between dxw and the client.
- Unclassified: information, which would not be of significant commercial value to those outside dxw.
Some of our clients also have protective marking schemes. For example, all central government bodies will apply the Government Protective Marking System (GPMS). If you are in possession of materials that are protectively marked using other schemes, treat them as company confidential.
We take care to handle all data carefully, but when information is protectively marked, extra requirements apply.
Because we value openness highly, we take care not to over-classify information. We don’t protectively mark information unless there is a good reason to keep it confidential.
This category is used only for dxw’s most confidential information. For example, employment records, salary details and company strategy documents.
Do not share any information with this marking with any person, whether internal or external to dxw.
- Must be clearly labelled or described as “Management-in-confidence”
- When printed
- Stored only in a locked container
- Transported only via courier, recorded delivery or personally by dxw staff
- Destroyed by cross-cut shredding when no longer required
- When digital
- Stored in an encrypted format
- Communicated only when encrypted or via an encrypted connection, unless emailed from one dxw.com address to another
This category is used for information which should not be communicated outside dxw. For example, details about how we operate security controls or internal discussions about client work.
Exactly the same controls apply to this information as detailed under Management-in-confidence, with the exception that Company Confidential information can be shared within dxw as required.
Client Confidential or Commercial in Confidence
This category is used for information which is disclosed to a limited group of people external to dxw, or which is unclassified information we have received from clients. For example, dxw proposals, presentations for pitches or planning documents.
Unless otherwise specified, all unclassified information we receive from clients falls into this category.
- Must be clearly labelled or described as “Client Confidential” or “Commercial in Confidence”
- When printed:
- Stored out of sight
- Destroyed by cross-cut shredding when no longer required
- When digital:
- Stored in an encrypted format when on exchangeable media or a mobile device
As a rule of thumb, label a document as Client Confidential if it mostly contains the client’s confidential information, or Commercial in Confidence if it mostly contains dxw’s.
Anything not captured by the sections above is unclassified. Examples are external marketing material, general emails and letters.
Beyond a general duty to treat information carefully, unclassified information is not subject to any specific restrictions.
Twitter handle - if you’re comfortable to share
Mobile - if you’re comfortable to share
www.dxw.com :: 0345 2577520 :: @dxw :: creating better digital public services
If you require an out of office message on your email account please send your request to firstname.lastname@example.org with the subject title Email Autoresponder which must include start date, the contact details for another member of the team for any urgent queries, and return date to be added to our mail server.
Note: please use Helvetica or Arial as the font in your emails.
Your pay, pension and other benefits
All perks and benefits are available to the dxw team after the successful passing of their probationary period.
Changes to your details
Please tell us promptly if your name, address, telephone number, next of kin details or banking details change.
Cost of living raise
dxw will institute a cost of living raise each year on 1st April. The percentage will be set by the CPI Index as of 1st April each year.
- If you have passed your probation, you will receive your raise in the April payroll.
- For those team members who joined prior to 1st April of that year, but haven’t yet passed probation, you will receive your raise in the month you successfully complete it and it will be the same percentage as of 1st April CPI that year.
- If you joined on or after 1st April (that year), you will not be eligible for a cost of living raise until the following April.
- If you are leaving during April you will not receive the cost of living raise.
dxw provides a pension which is operated by Aviva. Once you have passed your 3 month check in, you will be auto enrolled into the scheme, receive details by post of the necessary employer/employee contributions and have the option to set your percentage or opt out.
dxw will match any contribution up to 5%.
Your contribution will be relief at source, with 0.8 deducted from your monthly salary and the additional 0.2 added from tax relief.
For more details on Relief at Source, please visit the Aviva website.
If you want to take time off:
Discuss the dates with your team and delivery lead
This gives them a chance to manage any impact it might have on the wider team and the project.
Request the holiday through BreatheHR
We use BreatheHR to track who’s off and when, so we can plan for it. Your line manager can then see and approve your request.
Add your holiday to your Google calendar
If someone is trying to find out where you are, or when you’re available, the first thing they’ll check is your calendar.
When you are on a client project, you may also need to add your holiday to a shared or team calendar. Check with your delivery lead.
Your line manager will normally approve requests that are for 10 days or less and made at least 4 weeks in advance. Anything longer or requested with less notice will need to be managed to understand its impact on client, team or personal work.
When your planned leave has been approved, update the schedule in 10,000ft to reflect this. This helps us to look ahead and is recorded as “Out of office”. Each member of our delivery team uses the tool to record the days they work on client projects on a weekly basis.
There is more information about dxw’s holiday arrangements in your contract of employment.
TOIL (Time off in lieu)
Where possible we try to keep a sustainable pace of work and avoid working outside normal hours; occasionally this might not be possible.
How is TOIL calculated?
TOIL (time off in lieu) is awarded when you work over and above your contracted working hours continuously for a period of time or when you attend/travel to an event outside of your contracted working hours. TOIL should be agreed with your delivery lead or line manager ahead of doing the extra work.
We encourage you to use your TOIL within the two weeks of extra work or event attended as it’s meant to be for resting and making up for working at a sustainable pace. We know this may not be feasible in every case so please speak to your Line Manager or a member of the HR team if you have any questions.
There are two options of how to use your TOIL, you can calculate the amount of hours you have accrued (ie half a day) and take it off at once or take a couple of hours a day spread over a period of time. Planning when you’ll take TOIL is important, particularly if you’re working on a billable project so please speak to your Delivery Lead before doing any overtime and arrange when you’ll be able to take the time back.
How to request TOIL?
Using BreatheHR similar to the way that you request holiday there is a TOIL drop down, please write a note as to why you are requesting the leave and this will be approved by a member of the HR team. Please note this will not deduct from your holiday allowance shown on your BreatheHR dashboard.
If you are sick, you must let us know by 10:00, or as soon as is reasonably practical. Do not come to the office. If you come to the office when sick, you may be sent home again.
If you’re sick but able to work, you can work from home. Everyone at dxw should have a laptop, and should generally take it home with them in case it’s needed. If you’re sick and at home but don’t have your laptop, it can be couriered to you.
When you return to work, you must check that your sickness has been correctly recorded in BreatheHR, and update it if necessary. If you’re sick for more than a week, you’ll also need to provide a fit note.
If you’re sick on more than 10 occasions or for more than 10 days over a 12-month period, we’ll invite you to an absence meeting to discuss your situation. We may agree with you an action plan and/or a review period. We may seek medical advice. Should your attendance fail to improve after a three-month period, we will invite you to a further absence meeting to discuss your situation. In this meeting we will also give consideration to your possible dismissal.
We’ll also invite you to an absence meeting if you’re off sick for more than three weeks on a single occasion. In addition to the above, we will seek to support your return to work and discuss with you any temporary or permanent adjustments which may assist you. If you are unable to return to work in your current role we will consider if there is a suitable alternative role. If we are unable to reach an agreement that will permit you to return to work, we will give consideration to your possible dismissal.
We will always only consider dismissal after we have exhausted all other reasonable options.
If you need to take compassionate leave, let your line manager and a member of the HR team know, so we can support you in the right way. If you are on a project, we can then work with your delivery lead to manage the impact on the team.
To record the compassionate leave in BreatheHR, choose Other as the Type of Leave, and choose Compassionate as the Reason.
While many terms around parental leave are gendered, gender is not a factor in what leave you are entitled to. What matters is whether or not you are pregnant.
If you’re pregnant
If you’re pregnant, you’ll probably be entitled to Statutory Maternity Leave (SML) and Statutory Maternity Pay (SMP), which is funded by the government. They will pay you 90% of your normal salary for the first six weeks of your leave.
Assuming you are entitled to SMP (almost everyone is), dxw will also pay you 90% of your salary for the second six weeks of your leave. This contribution is called Occupational Maternity Pay (OMP). Taken together, this means that you’ll have twelve weeks of leave on 90% of your normal salary.
To be eligible for OMP, on returning to work you will need to stay at dxw for at least three months full time (or proportionately longer if working part-time). If you decide not to, you will have to repay any OMP you received.
When you know you are pregnant please do tell us as soon as possible, so we can check that your working arrangements are safe for you and also ensure you are paid for time off for antenatal appointments.
If you’re not pregnant
If your partner is pregnant, you are adopting, or you are having a baby through surrogacy, you’ll probably be eligible for Statutory Paternity Leave (SPL) and Statutory Paternity Pay (SPP). SPL may be taken for one or two consecutive weeks, between the date of birth and 56 days afterwards. SPP is £145.18 per week.
If you qualify for SPL and SPP, dxw will instead pay you your normal salary for three weeks of paternity leave. If you want to take more than three weeks of leave you can use shared parental leave.
Shared parental leave
If you’re having a baby, adopting a child, or having a baby through surrogacy, you may be eligible for Shared Parental Leave and Pay. If you’re interested in taking this up, please talk to the People Manager.
Keep in touch (KIT) days
You have 10 paid KIT days to take during your parental leave if you wish to come in for departmental meetings, events or just to spend some time in the office.
Any bank holidays that you miss while on parental leave will be added to your holiday entitlement when you return to work.
The Government closed the Childcare Vouchers scheme to new entrants on 4th October 2018. This means we are no longer able to add new members to the voucher scheme with Busy Bees.
The government has introduced new ways to help parents with childcare costs which you access directly: https://www.gov.uk/get-tax-free-childcare
For more information, please speak to the People Manager.
Our policy is informed by the way we work and the way we charge clients for our time.
Client facing: Any working arrangement needs to allow you to participate in most Fridays and be around for the important start-of- and end-of-sprint ceremonies.
Internal facing: Working arrangements for these roles are slightly more flexible as the delivery needs listed above are not relevant.
Part time working
The normal working pattern is 5 days per week, Monday–Friday.
Client facing: We’re happy to talk about a 4-day week, on the basis of a fortnightly pattern to accommodate our Monday–Thursday billing week and attending some Fridays. It may be possible for some roles to work a 3 day week due to the nature of the role potentially not being full-time on a single project, this would be dependent on a number of contextual factors and discussion with the team. We’re unable to support a 3-day (or fewer) week for all other roles due to the overheads for scheduling.
Internal facing: We’re happy to talk about part time working for any number of days, dependent on the role.
Part time hours spread over 5 days, e.g. working 21 hours across a full week, or roughly 4 hours a day, may be possible for internal facing roles after discussion, but is likely a no for client facing roles.
Salary and holiday allowances (including bank holidays) will be prorated for part time roles.
For example, when working a 4 day week, the pro rata leave allowance will be 20 days per year of annual leave and 6.5 bank holiday days, giving a total leave allowance of 26.5 days. Bank holidays that don’t fall on a non-working day must be booked as annual leave.
Core and non-core hours
Everybody is expected to work seven hours a day. Normal office hours are 10am–6pm.
If you’d prefer to start a little earlier and finish a little earlier (say 9am–5pm), this is definitely OK and can happen without any formal discussion for all roles.
If you’d prefer your working hours to start after 10am or finish before 5pm (still keeping to seven hours), we’re happy to discuss this and either might be possible. The impact of this would be less for internal facing roles than for client facing roles, but both would require a discussion.
Salary and holiday allowances would remain the same.
Compressed hours involves working your full hours in fewer days. For example: 35 hours in 4 days, 9.30am–6.45pm.
We don’t offer compressed hours for client-facing roles due to the complications for the way we bill our time and present our services to clients.
We are happy to have a discussion about compressed hours for internal-facing roles but cannot guarantee this would be an option.
35 hours in 3 days, for example, is a no across all roles. It goes against our encouragement of sustainable pace.
For working patterns with the same number of hours each day, holiday allowance can be treated the same as for part-time roles. For working patterns with varied hours, the annual allowance for both holiday and bank holidays should be counted in hours (231 hours per year) and bank holidays that fall on working days must be booked as leave.
Generally, we work either at our office or at client sites.
We’re happy to support working from home from a logistical or well-being related perspective. While we don’t support fully-remote roles (legacy arrangements being the exception), we can look at anything from 1–3 days per week following a discussion.
If you need to work from home for a one-off thing then that doesn’t require contractual arrangement – just talk about it with your team before the day, make sure you note it in your calendar and include it in your standup note that day.
Requesting a change of working arrangement
If you would like to discuss a change to the standard working pattern, you can either speak to your Head-of directly, or, contact the People Team to facilitate and support this conversation by phone, email, slack or in one of our bi-weekly HR surgeries. In this initial conversation, we will discuss your request, look at the impact on the team and your work, agree the best time for this arrangement to begin and how it will be communicated to those necessary.
If you have an alternative working arrangement, you should make sure it’s reflected in your calendar so the rest of the team can be confident in knowing when you are and aren’t around.
If you have a grievance about your employment or a complaint about another member of staff, talk to the Managing Director as soon as possible.
The first step is to discuss the problem to see if it can be quickly resolved.
If this discussion does not satisfactorily resolve the problem, you should put details of your grievance in writing and send it to the Managing Director. They will arrange a meeting to discuss the matter, at which you may be accompanied by a colleague or trade union official. Following this discussion the Managing Director will provide a written response.
If you disagree with this response or the matter remains unresolved, you may appeal by respond in writing. A further meeting will be arranged and the Managing Director will again respond in writing. This decision will be final.
If you do something that we feel constitutes misconduct, or your performance in your job has been poor, we’ll talk to you about it. Hopefully, there’s just been some misunderstanding, or some problem that’s easy to solve and won’t recur. Formal action will not be taken without careful investigation of the facts.
If we feel it’s appropriate, we may verbally warn you, explaining what has been unacceptable and what you need to do to improve your conduct or performance.
If your conduct or performance fails to improve following a verbal warning, or if the matter is serious enough that a verbal warning is not appropriate, we may hold a disciplinary meeting at which you may be accompanied or represented by a colleague or trade union official. Following this meeting, we may:
- Conclude that no misconduct has taken place, or that there is no poor performance
- Issue you with a written warning, which will explain:
- The nature of the misconduct or poor performance
- The change to your behaviour or performance that you need to make
- The time within which the change needs to be made
- The consequences of not making the change (for example, dismissal)
- In cases of gross misconduct, dismiss you without notice
If you disagree with the outcome of this hearing, you may appeal against the decision. You must do this in writing. If you do so, your appeal and the circumstances of your case will be reviewed by a member of staff who has not been involved in your case before. That member of staff and the Managing Director will then meet to discuss your case, and will either uphold the outcome or schedule another disciplinary meeting. dxw’s decision following that meeting will be final.
Supporting your development and wellbeing
People manager and HR surgeries
The bi-weekly HR surgeries are there to give an opportunity for members of the team to discuss matters they might not feel able to raise with buddies/delivery leads/line managers or that are specialist to the HR function in dxw.
The list is not exhaustive but some topics might include:
- Parental Leave
- Occupational health issues
- Contractual matters
- Working patterns/locations
- Training and career progression
- Stress management
- Interpersonal issues
- Grievance and disciplinary matters
- Facilitation/scheduling of conversations with Directors/heads-of, such as Salary Reviews
Bookable slots are available on Wednesdays and Fridays at 11am but the People Manager’s door is always open.
Line management at dxw is not about hierarchy, it’s about providing professional guidance and support.
Line managers ensure that team members are clear about their roles and responsibilities at dxw, and how well they are doing at achieving them.
Individuals should be proactive in taking responsibility for their own development, but line managers will provide advice and support to help team members meet their agreed short and long term goals.
HR support line managers with advice and guidance on recruitment, onboarding, probation, performance, sickness and any other specialist knowledge.
You can find out who your line manager is in BreatheHR on the summary section of your profile page.
Line management principles
Communication is a two-way process and it is important to check understanding and confidence, and value the other person in decision-making. Explaining the task and its objectives clearly means people know what’s expected of them and the part they play. It empowers them to take responsibility and own how they approach the work.
Recognise achievement and celebrate success
A simple ‘thank you’ shows someone that what they have done is appreciated, and is hugely motivating. Celebrating major, and minor, achievements is an important part of our culture at dxw. It builds team spirit and morale.
Guard our values
Lead by example. The actions and behaviours of line managers must always demonstrate our dxw values. We should always hold ourselves accountable to our values, and encourage the same in all of our colleagues, including those we line manage.
Continuous constructive feedback
Find out how each of your team members prefers to receive feedback, and develop an approach which reflects that. Ongoing positive and constructive feedback is essential if someone is to feel valued, learn from their experiences and become better at what they do.
Being honest means telling the truth and being consistent in what you say and who you say it to. Telling things as they are, while being sensitive to the situation and individual, ensures that people know where they stand and will help to build mutual trust and respect.
Line managers look out for the health and wellbeing of the team. They are responsible for carrying out dxw’s duty of care to its people.
One-to-ones with your line manager
For your manager to help you with your personal and professional development, your wellbeing, and to build a trusting relationship between the two of you.
These meetings are about you; ideally you will feel happy driving the meeting. If you’re not confident doing this, or are unsure how best to approach it, your manager will help you to get there.
Agenda and topics
Coming to your 1:1s with a list of things you’d like to discuss will help you make the most of the time. Some things you might find productive to talk about include:
- Your career and growth goals: Don’t assume your manager knows all your aspirations. Bring them up in your 1:1s. Your manager understands you won’t work for them forever and they want you to have a happy, fulfilling career — whatever that means to you. Tip: if you want to talk about your long-term goals but feel uneasy about it, ask your manager to do the same.
- Team improvement: Have an idea that will help your team to work better? Use your manager as a sounding board to help you refine and implement your suggestion.
- Self improvement: Got a specific thing you’d like some help, coaching or feedback on? A technical skill or a soft skill? Your 1:1 is the place to bring it up. Remember that you can use the 1:1s that fall between career progression reviews to discuss any of the proficiencies you’re currently trying to level up on.
- Personal issues: Anything going on outside of work that’s affecting your wellbeing? Physical or mental illness, bereavement, family issues, stress? The more you can tell your manager, the more they can try to help, and make accommodations for you at work.
- Interpersonal issues: Having problems with a coworker? Your manager can help mediate or coach you through how to deal with the issue.
- Retrospection: If at any time you feel like your 1:1s aren’t particularly productive or helpful, or you’d like to change something about them, don’t hesitate to bring this up with your manager.
1:1s should happen at least once per fortnight. Where possible they’ll be face-to-face, either in the office or out for a walk, or a coffee. Where that’s not possible, remote is perfectly fine. There’ll always be a Google Meet link in the calendar invite.
If you need to reschedule your 1:1, let your manager know at the earliest opportunity.
An hour or so, at least once every two weeks, is a good standard to aim for. If you meet weekly, a little shorter is fine.
Here’s a template for helping to prepare for a 1:1, and making notes during it. Feel free to make a copy and alter it according to your own needs.
Here’s a great article on 7 ways to prepare for an effective one-on-one meeting with your manager.
Personal learning and development allowance
We have an annual allowance of £750 and up to 4 days per person, to be used for a range of professional and personal development activities like workshops, short courses or conferences. dxw pays for the event ticket, travel, and accommodation, but you will need to cover your own costs for food, drink and supplementary equipment.
You should discuss your training plan with your line manager, they will help you identify potential areas for development and support you to find suitable events or training.
You may also use the allowance to attend a non role based conference or event focused on improving your health and wellbeing. You will receive two days off for this, and can top up the time from your annual leave allowance.
Attending conferences and events that are not related to your role, is a taxable benefit. As your employer, we will make the declaration, HMRC will then adjust your tax code accordingly to collect the tax via PAYE.
How it works
The allowance will be available to everyone once they have completed their probation period, within the dxw financial year which runs from the start of July to end June. It will be pro-rata for staff who work part-time. If you don’t spend your allowance within the financial year, it cannot be carried over. We will start afresh each year, as part of our annual budgeting cycle. Your allowance is counted as being spent at the time of purchase rather than at time of use; for example, if you buy a conference ticket in May for an event in July the same year, the deduction will be made to the budget for the financial year that May falls within.
Any events (paid, free, speaking, etc) you attend should be logged in BreatheHR as a training request. If they do require payment, please include weblinks and an estimate of the ticket, accommodation and travel costs (up to the maximum of £750, though you are welcome to pay the difference for more expensive events). This helps manage the annual budget and will give you a great view of what you have attended in the year.
It’s ok for members of the team to go together, but we need to ensure that training days have the lowest impact on client work, so there may be times we need to consider whether your request is possible. Our Director of Delivery will help with prioritisation in those circumstances.
We know that lots of training isn’t paid for, and involves things like coaching and mentoring, learning from colleagues, being an active part of networks, and other self-directed learning. We will encourage and support people who want to use unbilled days for different types of professional development.
If appropriate, it’d be great if you would talk about your experiences in a blog post or bikeshed - sharing good events and useful training will give others the opportunity to attend.
At the end of each financial year we will review our financial position with the intention of increasing the annual allowance.
If you have any questions, please contact the HR team.
Private Slack channels
We encourage everyone at dxw to be open about their identities and the challenges they experience at work, but sometimes we want to only talk to people whose experiences more closely resemble our own. To enable that, we have created a number of private channels:
- #identity-lgbtqia-plus (contact a member of @identity-lgbtqia-plus-admins to join)
- #identity-gender-minority (contact a member of @identity-gender-minority-admins to join)
Anyone can create a new one by creating the private channel, creating a user group with at least one volunteer (or asking a Slack admin to do it for you), and adding it to this list. It’s probably a good idea to share that you’ve created it in #general.
The membership of those channels is also private to protect those people, and members of a channel are expected to keep everything in those channels private.
We don’t police membership of these channels, and trust everyone to be honest about their identities. Don’t invite anyone without first asking them if they want to be invited.
If there is a book relevant to your work that you would like to read, make a request through the #help-purchasing slack channel and the Bus Ops team will buy it for the library.
Cycle to work scheme
dxw operates a cycle-to-work scheme, which may allow you to purchase a bicycle at reduced cost. If you would like to take this up, please register on the cycle scheme website
dxw provides eyecare for the team via a voucher system run by ASE Corporate Eyecare Ltd and Boots.
Details of what the wellbeing voucher offers can be found here: Eyecare for Wellbeing.
Apply for a wellbeing eyecare voucher
Backpack and other personal equipment
dxw will pay for the equipment needed to enable you to work comfortably and safely. dxw also offers a budget of £25 towards a work backpack. Use the help-purchasing Slack channel to request any equipment you need, or talk to anyone in business operations if you are unsure if a purchase will be covered.
When you join dxw you will be assigned a helper. This person will work closely with you for at least your first 4 months. They will do a similar job to you, help you meet members of the wider team, catch up with you on at least a 3/6/12 week basis to ensure you are receiving everything you need, and will NEVER get bored of your questions!
If you feel that you’re not getting as much time with your helper as you’d like, please speak to the People Manager.
As a helper, you will be vital in ensuring you have the regular catch ups - if you are finding it hard to schedule them, please do talk to Bus Ops.
For more information on being a helper, please see the checklist or speak to the People Manager.
Once you have passed your 4 month probation, we would like you to choose a buddy within the company to support you.
We recommend this person doesn’t work directly with you, someone in a different role and that you don’t work closely with on projects, as this will give you a second pair of ears and a whole new set of experiences to draw on.
This is not mandatory, just recommended and similarly not everyone may wish to be a buddy - don’t be afraid to ask or say no. It can be reciprocal but doesn’t have to be. Also, if you feel that a change of buddy would benefit you for whatever reason or that you’re no longer able to be a buddy, this should also not be an awkward situation. If you have any concerns, have a chat with the People Manager.
The buddy system is there to help us all improve, to make sure we’re doing the right kind of work and to check that we’re dealing with practical problems we’re facing. It’s not line management, so it’s not the right place to talk about holiday, salary, sickness, absence or anything disciplinary. If you need to talk about those things, talk to the People Manager.
If you want to know more about how the buddy system works, how often to meet and suggested discussion topics, see the buddy crib sheet. This shouldn’t be a huge time commitment, ideally just a pleasant Friday meet up.
Your delivery lead (for those on client work)
There will be opportunities within the delivery team to raise any issues or concerns you might have e.g. retrospectives or planning sessions. As well as this, or if you’d prefer to talk one on one, the delivery lead working on the project will be available to provide support and guidance.
Directors & heads-of
All members of the Directors and heads-of team are here to help answer any questions you might have. Your own Director and/or Head-of profession or location is there to provide support on matters relating to dxw and your career with us, as well as profession specific questions. Similarly, they are here if you need to escalate any job-related concerns.
Our Managing Director, Dave
At dxw, all doors are open if you need to raise a concern or just have a chat - this includes our MD. Dave is always available to discuss any questions you have about the company and its future. Equally, if you feel you need to escalate anything to him, don’t hesitate to get in touch. Dave’s diary is open and you can see it on Google Calendar. If you would like to schedule some time with him, please feel free to book something.
Hiring new people
We use Workable for recruitment, to help us stay organised and keep in touch with candidates.
Each candidate moves through a number of stages before being offered a job or declined: a screening interview via Skype or phone, an interview and a work day. The work day includes another interview.
We feel strongly that it’s important to be respectful of candidates’ time and interest in us, and that their attention is valuable. So we do our best to be responsive, human and open. It’s particularly important to give unsuccessful candidates good, thorough feedback about why we haven’t made them an offer.
Before we decide to advertise a new job, we write a job description. This helps us make sure we all agree on what we need, and helps candidates to know if their skills are a good fit for the job. A good job description has three parts:
- A description of what the person in this job will do
- A list of their responsibilities
- A list of the skills, experience and personal qualities they will need to be good at their job
There are lots of job descriptions on the website if you need inspiration. It’s important for them to be declarative (“The person with this job will…”) and as objective as possible. Throughout the rest of the process, we’ll use this document to decide what questions to ask in interviews, and to fix activities for the work day. The skills and personal qualities need to be things that we can have a go at understanding by asking questions and observing a candidate’s behaviour.
How we find people
The first way we find people is through our networks. We look for people we know. Everyone who is willing tweets about the job and shares it on Facebook and other social networks.
The second way we find people is by advertising. We advertise jobs on Stack Overflow, GitHub, WorkInStartups and Unicorn Hunt. Not all jobs go on all of these boards - we pick whatever seems most appropriate for the job.
The third way we find people is by making sure we’re regularly blogging about what we’re doing, and being open about our culture, work and process. We accept general applications from people who are interested in dxw but who don’t fit an open job.
All applications arrive via Workable. We review these applications as a team to decide who to take forward.
An application review is a very quick process. We look at the information given by the candidate and decide if it is likely that the applicant has the skills, experience and personal qualities that we need. If it is likely, we progress them to the next stage.
The purpose of the screening is to:
- Introduce ourselves and explain a little more about the job and life at dxw
- Talk to the candidate about their experience and explore why they are interested in the job
- Decide whether you think they are quite likely to have the experience and personal qualities that we are looking for
- Get an idea of the candidate’s salary expectation
Try to keep the conversation quite high-level, and avoid going into too much technical detail. This part of the process is more about experience and personal qualities than about skills. So look for whether this person:
- has an interest in our mission
- shares our values
- has experience working in human-centred and agile ways
If you can find out how they heard about the job, that’s useful for us to know.
Many people feel self-conscious when asking questions about salary, but it’s very important - and this is one of the few situations in daily life where people expect the question and are not put off by it. If you’re not sure how to broach the topic, leave it to the end. When you’re about to finish the call, you can say something like:
“Thanks for talking to me. Before we finish, please could you give me an idea of the salary you’d like?”
If the candidate suggests a number that is unexpectedly high or low, it’s also worth asking what they are paid in their current role.
We avoid making any commitments during this call. Near the end, we explain that we’ll be in touch soon. Don’t offer an interview there and then: that’s something we agree as a team.
After the call, you can talk about the candidate with the team if you wish, or just make a decision. If you think it’s quite likely that they have the skills, experience and personal qualities that we need, you should take them through to an interview.
Candidates who have a successful screen will be offered an interview. This is an hour long with two members of the team.
Before going to an interview, make sure you have:
- Set aside enough time for the interview. You should leave half an hour each side in case the candidate is early or the interview goes long.
- Read the job description
- Read the candidate’s CV
- Read the questions for the interview, and thought about whether they are the right things to ask
dxw interviews are informal. They are a semi-structured conversation, rather than a Q&A. We do not recite the list of questions or keep verbose notes on replies. The questions are there to ensure that you don’t forget to cover important ground, and as a prompt when the conversation naturally dries up.
Start with a couple of questions, and then allow the conversation to evolve naturally. Ask questions about things they say, and try to go into more detail on the points that you think will help you to assess their skills, experience and personal qualities. Keep the job description in mind: this should always be your frame of reference.
At the end of the interview, always ask the candidate if there’s anything they would like to ask you. If they have questions, answer them honestly. If they ask about salary at this stage, or have a concern or question about the job that you don’t feel comfortable addressing, tell the candidate we’ll get back to them and make a note for an appropriate colleague to call them.
When everything’s done, we thank the candidate for their time and then return to the office and discuss the interview. As soon as possible, we put a thorough update on Workable. This update should include the good things and bad things about the candidate, a recommendation on whether to take them forward, and a rationale for that recommendation. It is very important that this update is detailed enough for us to understand what happened and why, long after everyone involved has forgotten all about it.
If you think the candidate is very likely to have the skills, experience and personal qualities we need, you should take them through to a work day.
The work day interview is exactly the same as the first interview, but with different members of the team and different questions. Usually, it happens in the first hour of the work day.
TODO. This section to cover:
- Principles for a good work day
- Preparing a work day activity
- Letting the candidate know if they need to bring anything and how much time we’ll need
- Making sure there is a printed or emailed explanation for what they need to do
- Discussing the results
- Offer if we are sure they are right
Offer, joining and probation
TODO. This section to cover:
- Salary negotiation, notice periods and start date
- Eligibility to work in the UK, documentation that we need
- Background check
- Starters checklist
- The probation period, meeting and expectations
- …more things.
dxw is proud to offer return to work opportunities for experienced hires who are looking to re-enter the workplace after an extended period of time away.
We’re running a pilot to begin with to see how this works for us and the people joining us. We’ll start by taking on one or two people for 3 to 6 months - depending on the role and circumstances. There’s potential to become a permanent member of the team at the end of the placement, but this isn’t guaranteed.
Initially this opportunity will only be offered within our London team, with a view to including our Leeds office as the team there grows.
Who supports you?
You will be supported by our people team from the point of application.
If you’re invited into our recruitment process, it will consist of a one hour interview followed by a collaborative activity with the team which will be sent to you 24 hours in advance so you have time to prepare.
The interview will be an informal, semi-structured conversation where there will be the opportunity for us to learn more about you and your experience and, just as importantly, for you to get a feel for what it’s like to work at dxw.
If you join us, you’ll be continuously supported by our people team, a line manager and a mentor within the same field. You‘ll have regular check ins with the team where you can speak openly about anything that’s on your mind.
Client facing role
For client-facing roles we’ll start billing your time back to the client when we feel the time is right. This will be something we discuss openly during the recruitment process and through your regular check ins.
Internal facing roles
We’re also offering internal facing roles, for example, in our busy commercial and marketing teams who also support our sister company, Tradecraft. These roles are not billed back to our clients.
If you think this might be for you, please apply through our jobs page.
At dxw, we believe that great teams need great leaders.
Whether or not they are in a formal management role, leaders at dxw are guided by these principles.
Set an example
Leaders at dxw demonstrate our values in everything we do. We set high standards of behaviour and inspire both colleagues and clients to do the same.
We demonstrate fairness, integrity, and resilience, and build trust with our actions.
Look after people
Leaders at dxw promote the wellbeing of individuals, teams and communities. We encourage a supportive culture and inclusive working arrangements. We prioritise 1:1 time with people to listen and understand their particular needs.
We support and defend colleagues in difficult situations. We identify and deal with poor performance and bad behaviour.
Leaders at dxw welcome responsibility and accountability. We’re proactive, pick up things that need doing without being asked and push to finish the job in hand.
We’re the first to admit mistakes, apologise when wrong and learn for next time.
Deliver for clients
Leaders at dxw understand how to deliver value for each client and create the conditions for dxw to do brilliant work. We are not afraid to challenge clients or ask difficult questions.
We think commercially and push dxw to grow and strengthen as a business.
Leaders at dxw communicate clearly and concisely through the right channel. We question any decisions, goals or explanations that are vague or ambiguous and work to clarify them.
We’re open, honest and straightforward in what we say and write. And we provide specific, understandable and useful feedback.
Make good decisions
Leaders at dxw use evidence and judgement to make good decisions. We know that timely decisions are important, so we don’t procrastinate or fudge. We commit to collective decisions, particularly when we originally disagreed.
We consult broadly, seek out contrary opinions, and listen to quieter voices. We make sure we can explain our decisions, with context, rationale and evidence.
Point the way
Leaders at dxw share an inspiring vision for the future of dxw, and each individual’s part in it.
On client and dxw projects, we make sure that colleagues understand the outcomes we want to achieve and the value that they will create.
Build the future
Leaders at dxw hire great people. We actively look for the widest range of candidates to strengthen our diversity.
We encourage our colleagues to learn, develop new skills, and pursue their career aspirations, whether at dxw or elsewhere. And we give people opportunity and responsibility at the right pace for them.
We continually improve dxw capability, and the effectiveness and efficiency of our delivery. We try out new approaches and technologies and give others the time and space to do the same.
We create the conditions and in-house capability our clients need to deliver and keep improving great services.
Strategy team principles
The strategy team apply these principles to our work.
Bring people together to make the right decisions
We facilitate activities to help organisations make good decisions, prioritise and create the momemtum for change.
Focus on impact and sustainable change
We’re here to create significant long-term change. We won’t get involved if we don’t believe that’s possible.
Question the brief
Before starting delivery we interrogate the brief to make sure it is clear, realistic and provides the foundation for delivery teams to start work.
Meet organisational goals as well as user needs
We help organisations clarify their goals and set up the right measures to track performance and progress. So they can deliver better services for the people who need them.
Use methods that work
We use established methods where we can, or develop new ones where we need to.
Create the conditions to deliver
We set up teams to deliver and keep improving once we’re gone.
Delivery management principles
Delivery leads at dxw are guided by these principles.
We encourage calmness and patience, we ensure all voices are heard in a fair way and we’re always proactive to get stuff done.
We have the autonomy to lead and to say no, we’re responsible for empowering delivery teams to do great things and we coach others to get the best from them.
Show strength & resilience
We protect the team so they can focus, we remove blockers and distraction and we provide context and see the bigger picture.
Enable, empower & encourage
We create space for the team to deliver and individuals to thrive, we build up trust with the team, our clients and our stakeholders to support decision making and progress and we’re always supportive and demonstrate positivity, with a focus on delivery.
Prioritise learning & improving
We actively learn from what we do and take responsibility to ensure that learning feeds back into what we do next and we stand by our ability to facilitate communication and constructive conversation.
Product management principles
Product managers at dxw follow these principles.
Set the destination, don’t chart the course
Product managers help empower multidisciplinary teams by refining and articulating the problem the team is trying to solve, and the outcomes they‘re trying to produce.
Communicating the vision and goals for a project through a clear and well-maintained roadmap is a core part of product management.
Define and defend scope
Getting agreement from everyone involved is crucial to successful delivery.
Product managers should set the direction at the start of a project, and continue to articulate, communicate and defend the scope throughout, so that the team can focus on delivering.
Convert insight into action
User research helps inform our objectives, goals, and priorities by telling us more about the problems users are having with the current state, or the needs they have for something different.
Product managers need to be able to balance user research insights with constraints like time, capacity, and strategic objectives to prioritise the next most important thing.
Product managers help the team to work together, across disciplines, to identify potential solutions before choosing a way forward.
Have a service mindset
Product managers recognise that a digital product is often not the whole solution to a problem, and that the people operating a new service day to day are users too.
We think about the processes and systems around a product, including how those might change.
Communicate clearly how short term outcomes contribute to long term goals
Product managers need to own and articulate a vision that is consistent and meaningful to everyone with an interest in the project, from the delivery team all the way through to the most senior stakeholders, and users.
Be present, collaborative, and consistent
Being available to the team to discuss the unexpected and share in the decision making is central to building empowered and protected teams.
Product managers should regularly and actively communicate, review and defend our decisions - especially the unplanned or unexpected ones.
Maintain a focus on outcomes
In the midst of delivery, key dates can loom large, and teams can be diverted onto things which seem urgent but aren‘t important.
Product managers must help teams and stakeholders remain focused on outcomes over outputs, facilitating discussion and making space for reflection.
Lead without authority
Product managers shouldn‘t be bottlenecks. Product managers and delivery leads work together to build skilled multidisciplinary teams and create the space in which those disciplines can do their best work.
Product managers are open to new tools, techniques and approaches, working with teams to find what works.
Take blame, give credit away
Good product managers leave their ego at the door, taking negative feedback on board whilst ensuring the team are rightly recognised for their work and achievements.
Being kind is more important than being right - it‘s a good rule of thumb to enter every conversation without assuming that you already know most, or best.
Strong opinions, softly held
Product managers make the best decisions based on the available information with confidence, staying open to the possibility that things could change when more information is available in the future.
Product managers communicate the trade-offs they’re making and the rationale for their decisions so that teams can understand how a decision was reached, even when they don’t agree.
Set clear priorities
Product managers work with the team, stakeholders and users to define priorities, and ensure these are clear.
Product managers facilitate and work with service designers and business analysts to work out key metrics and goals for the product and work with the team to define roadmaps to achieve these goals.
Hat tip to Ross Ferguson for inspiring several of these principles.
At dxw, we believe in making decisions based on evidenced user needs. As user researchers, we help multidisciplinary teams learn about users and recognise the value of user research. There is no single right way of doing this, but as a team, we need to stay unified in the way we approach, do, and talk about research.
User research principles
Our principles are not rules. They guide our work, keep us improving as a team, and working with, not for our clients.
Help teams understand people
Researchers at dxw help our teams build a deep understanding of the people who use our services. We know that‘s the best way to create public services that work well for the people who need them.
We are facilitators, not gatekeepers. We actively involve our colleagues and clients in research. And openly share what we do, how we do it and why it‘s important.
Find the truth. Tell the truth
Researchers at dxw create strong evidence and reliable answers so our teams can act with confidence. We are bold and focus on what‘s most important.
We know we can learn things that are unexpected and challenging. So we communicate clearly and sensitively to help everyone make the best decision.
(Credit to the great Dana Chisnell and the United States Digital Service for this one)
Take ethics seriously
Researchers at dxw know that the safety and trust of participants is our responsibility. We think about the ethics of our research at every step. From how we recruit participants and get their informed consent, through how we store and use the data we collect, to how we share our findings.
Be methodical, but not rigid
Researchers at dxw know that the quality of our findings depends on the quality of our methods. We use tried and tested methods, and take time to reflect and continually improve our practice.
But we also understand that context is important. So we use the best approach for the question at hand and adapt our ways of working to fit the client and the project.
Learn, share and adapt
Researchers at dxw work in an agile way. We do research and analysis in small batches so we can continuously share and adapt to what we learn.
Make research inclusive
Researchers at dxw know how important it is that public services work for all the people who need to use them. We help teams understand the needs of all their users, and do research activities that everyone can participate in.
Build on existing evidence
Researchers at dxw help clients build on the knowledge and data they already have. We combine existing knowledge, poorly understood data and new research into a coherent picture.
Accept and admit constraints
Researchers at dxw do the best research we can within the constraints we have. We acknowledge and share the limits of our research and our findings. And we advocate for more research when it‘s needed to achieve the project outcomes.
User research guidance
The Playbook includes detailed guidance on how we do user research at dxw.
The guide starts with the user research workflow, which describes the things that user researchers usually do on projects, and then provides further guidance and links to resources for specific topics.
Design team principles
Designers at dxw follow these principles:
Democratise the design process
Take into account, and value highly, the input of others in the design process. While we are ultimately responsible for design in a delivery team, we don’t work in isolation.
Value clarity in everything we do
Use plain language in interfaces, writing and conversation.
Overlap with other disciplines
Work closely with people that have different skills to you, in the knowledge that different perspectives make our decisions stronger and elevate our work.
Never go missing. Our teammates always understand what we’re doing and why, because we’re all aiming for the same outcome.
Know we are not the user
Do not assume to know how users of our services think or act. We acknowledge that things such as genetics, upbringing, religious and geographical culture, and past experiences make us all different. We work closely with our user researchers to gain understanding and insight about the people that use the things we design. “One accurate measurement is worth more than a thousand expert opinions.” ~ Grace Hopper
Know that being open about our work, and helping others to understand our decisions and why we make them, benefits everybody.
Be tolerant, understanding, empathetic and compassionate. Look for opportunities to help and care for others. Putting people at the centre of everything will help you be a better designer.
Understand that when people ask questions and give feedback it is to make something better. If we can not articulate our decisions then we may not have made the best choice.
Always ask questions and seek the truth; when we understand the problem we can solve it. When things seem muddy take a step back and try and find the original intent or gaps in understanding. “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” ~ Albert Einstein
Always assume the best intent
We are passionate about what we do, but we are a team. When you have difficult conversations or feedback we should always assume that it is coming from a good place.
When we talk about our work and why we do what we do, do not just state the facts. Inject some humanity into it; turn it into a story with a beginning, a middle, and an end.
Development team principles
Solve real user needs
Good code starts with understanding, and is rooted in the real world. We work in multi-disciplinary teams, but you’re not just there to churn out code. Get involved in the research and design. Understand the needs of the users and the constraints of the organisations we’re working with.
Ultimately, it’s about the user and their needs, not about technology. Sometimes software is not the answer.
Own your code, but collaborate
Having the opportunity to see a piece of work through to completion is a great way to get stuff done, and for developers to grow. Take ownership of your work to get it all the way through our development process to being used by users.
Ownership gets stuff done, but collaboration makes it better. So involve the rest of your team in your work: agree approaches, highlight tradeoffs and seek out reviews. Get all your code reviewed by another developer to help us ship better quality code, get the opportunity to learn new skills, and increase the shared knowledge of our products. Request feedback, ask questions and discuss code, but ultimately the author is responsible for making changes.
Security is a user need
Sometimes the simplest or easiest solution is not the most secure, and we fight for our user’s safety and security, even when a client doesn’t agree.
Use simple, conventional technology
By default, use straightforward technology and conventional approaches. The services we built have to be maintained and iterated on by small, and sometimes less experienced, teams. Keeping things simple ensures that is as painless as possible.
Vary from convention only on the domain specific stuff, where it adds the most value.
Build for quality and consistency
Think about those who come after us. We build high quality systems with the lowest possible maintenance burden. We write tests, use linters, follow standards and conventions, and document our decisions. The things we build should be set to thrive after we leave.
Improve with each iteration
Always leave the codebase in a slightly better place than when you found it. Look for opportunities to refactor difficult code, to improve documentation, or to extract shared functionality.
Communicate clearly and frequently
Help our future selves and others by recording the reasons for our actions. Explain the changes you’re making to code through your commit messages and pull requests. Explain the decisions you’re making about technology through architecture decision records. Explain the tradeoffs you’re making in planning and show and tells.
Use straightforward language, even when you’re dealing with complex technical issues. Prefer to write it down over speaking it out, to ensure a lasting record.
Be humble, supportive and open minded
Assume other people on your team know things you don’t. Feel comfortable saying “I don’t know”.
Assume you know things other people on your team don’t, but be prepared to be wrong. Ask questions rather than giving instructions. Share your opinions and experience openly with your team.
Question the obvious and test our assumptions. Listen to the client and the users and their experiences.
Be non-judgemental – assume everyone did the best they could at the time, with what they knew and the resources available.
Always learning. Always teaching
Technology never stops, and the amount to know even for our limited stack is huge, so we must learn and share. We teach each other through peer mentoring, pairing and reviews.
Share what you learn on a project with the whole team so we can reuse knowledge across projects. Encourage others in their learning.
Do the smallest amount of good work
We aspire to regularly ship good code, and deliver it to the users as often as possible. Delivering impact fast by shipping something real has a big impact on the morale of the team and happiness of our clients and users.
Where you can, do less and deliver it sooner. Break down work into smaller pieces. Descope anything that isn’t critical for a first version. Do a minimum slice that works for some of your users. Anything to reduce the time between get started on something and delivering it to users.
Work at a pace that suits the project. Hacky is sometimes fine. If you’re working on prototypes then do only what you need to answer your questions. Sometimes, if you’re working on critical production systems, you’ll have to go slower. When that’s the case, it’s even more important to break down the work into the smallest reasonable chunks, to demonstrate progress, to make reviewing the changes as easy as possible, and to prove your assumptions.
Work in the open
Be open by default. Code should be public unless there’s a good reason otherwise. Changes to open source libraries should be contributed back to the project. Dashboards should be public wherever reasonable.
The way we’re working should also be open to our clients. Work being done should be represented in Trello boards that everyone can see. Communication should be done in public Slack channels rather than direct messages. Openly communicating about our work allows clients to see how we’re doing, and what needs their attention, and gives everyone in the team context for the work being done and decisions being made.
Technical Operations team principles
Learn don’t blame
Things/Mistakes happen, treat it as a learning experience rather than finding blame.
Documentation is the first step to automation
For most tasks you need to understand it enough to document it before you can begin to automate it.
Don’t be a keeper of secrets
Everyone should be replaceable in respects to knowledge. It’s everyone’s responsibility to share what they know (eg. Pairing)
No heroics - Don’t internalise problems
Situations occur where there is pressure to deliver/maintain/fix, it’s a team effort, not always the same person’s job.
Be helpful not obstructive. It’s easy to get frustrated by things in time sensitive situations – don’t!
We are the team that enables and encourages dxw to achieve its mission(s) and uphold its values.
Commercial operations team principles
Things we do:
We deliver the dxw business plan. In particular, we recruit the best people to meet our mission, manage our finances to allow sustainable growth, and track performance of objectives to measure ourselves.
We are the front door for staff and clients. We help, support and enable dxw to meet its mission and uphold its values. We do this by being empathetic and put people over process.
As commercial experts we take the burden away from our delivery teams, and make sure our people, as well as our suppliers get paid, whilst also ensuring our clients pay us on time.
The unit of delivery is always the team, so we ensure staff wellbeing by providing a safe and inclusive environment. We also support our people to thrive in all stages of their careers, ensuring they have chance to continually learn, as well as excellent facilities and the right tools to enable them to succeed in their careers.
We ensure dxw is compliant with all the relevant company and employment regulations, ensuring we have ISO 27001 accreditation, abide by GDPR guidelines and insurance.
Commercial and business operations can be thankless, but to manage expectations we remain resilient and take responsibility for our work by effectively communicating about what we do and why we do it.
Empathetic to our users / staff / suppliers / clients.
Support each other to support the team.
Commercial accuracy and responsibility.
We are balanced, organised and resilient.
People over process, to maintain our unique, small-company, culture.
We are proud of what we do and are confident enough to talk about it.
We manage expectations by taking responsibility for our work and communicating what we do and why.
We are the company values.
Sales and marketing
Sales and marketing team principles
The sales and marketing teams at dxw follow these principles:
Start from solid foundations
We work with potential and current clients to understand their needs and how we can deliver value - seeking out opportunities for mutual growth.
We support our clients to make the right buying decisions, ensuring we focus on positive outcomes for users and making the most of the resources available.
We work closely with our delivery team so we can be open with clients about who will be available to do the work and realistic delivery timescales.
Build positive relationships
We work in partnership with our clients, and are open and transparent at all times.
We remain responsible and accountable to both our delivery teams and clients, ensuring that we represent them in the right way and can deliver on our commitments.
We give our clients the opportunity and platform to talk openly about their experience of working with us. We listen to what they’re telling us - about what’s going well and what we need to do differently - and constantly work to improve things.
Find the right work
We welcome new opportunities, and actively seek input from the dxw team to help us decide whether an opportunity is ‘dxw shaped’.
We consider the ethical implications of the work - does it help to create better digital public services that make people’s lives better?
We will only take on work that’s a good fit for the team - that won’t put us under undue strain, where our team will be safe and we can have a positive relationship with our client.
Show the work and the team
We’re an active part of the digital and tech community that’s working to build better public services.
We talk openly about what we’re doing and why, what we’re learning along the way and share our ideas and expertise. We blog all the time.
Have a clear voice
Whenever we communicate - online or face-to-face - we’re always clear, to the point, friendly, and professional. You can rely on us to say it like it is.
We champion the things that matter to us and our clients. We’re bold and pragmatic and seek to influence change for the better in the way public services are created and delivered.
Communicate with a purpose
When we communicate, it’s to explain what we’re doing and the impact of our work so our clients and potential clients understand our areas of expertise and how we can help them.
We’re open about our values and the way we work in dxw digital. We give our team members a voice because we’re proud of our diverse and inclusive culture.