Decision making

Our decision making process is designed to be democratic, but efficient. Fundamentally you should feel that you have autonomy to make the best choices for your circumstances. Oftentimes though, we do need to make choices as a group to ensure that there is some consistency in the way that we're approaching projects and that teams are able to onboard to different projects without friction.

The DX tech decision making process

In DX, there tends to be a lot of consistency between our projects. We do a lot of work with CMS platforms and a lot of frontend development. We use a reasonably narrow set of tools and tech stacks. A result of this consistency is that there can be benefits to documenting standard approaches to common problems. If you’ve got a concept that you think should be standardised, then here’s an outline of the process we should follow.

Step 0: do we even need to formalise this?

Remember the agile manifesto: Individuals and interactions over processes and tools.

Processes do have value, but we mustn't constrain our ability to do what’s right in individual contexts.

When faced with a decision that needs to be made, consider the scope of that choice. Does it just affect your project or does it set a direction that will be felt more widely across the department?

Some things that we should standardise: coding standards frameworks, our choice of local development tool, a standard format for tickets, our frontend development toolstack.

Some things that we should avoid standardising: mandating of specific libraries, APIs or modules to use, ideas or approaches without precedent or that are untested and unproven, niche concepts that are unlikely to be regularly re-used.

Step 1: Create an RFC

A request for comment (RFC) is a short document that describes the decision we are trying to make and provides a constrained list of available options.

The RFC should initially be shared with an engineering manager for a first review. List of EM’s:

Dan James
John Ennew
Mark West
Pete Cooper
Rohan Sootarsing

Step 2: Circulate for approval

The RFC now needs to be shared in the #dx_tech Slack channel for feedback.

Feedback should be constructive and delivered with the aim of taking us closer to agreeing on a decision. At this stage a consensus may become clear. If so a decision can be reached and you may skip to step 4.

Step 3: (optional) Discussion

If a clear consensus is not reached with a written RFC then we should use one of our weekly tech talk tracks to discuss the matter in more depth.

Step 4: Decision

Once a clear consensus is reached the RFC becomes a DX policy. The decision should be recorded in this handbook.