We’re primarily driven by meeting 7digital’s goals and objectives

  • Everything we do should be driven by clear business goals and objectives. Where they are lacking we should go and find them.
  • We expect business needs to be provided as problems that need solving with clear expectations and measurables without prejudice towards the implementation.

Release Early and Often; Fail Early and LOUDLY!

  • It’s essential we can respond quickly to changing business requirements. The best measure of our effectiveness in doing so is via frequent predictable releases through a steady rhythm of working. Things need to be easy to change (maintainable) and delivered at a sustainable pace.
  • It’s far more preferable to get something in production as soon as possible and develop iteratively based on feedback than to get bogged down in speculative analysis or a fear of not making all the right decisions up front (be that regarding technology choices or requirements).
  • Failures are expected, and welcome. When projects fail, we learn about other routes that might work. When software fails, it tells us about invalid assumptions we’ve made. The earlier and louder the failure, the more valuable that information is.

The best solutions come from everyone working together

  • We do our best work when we work closely and collaboratively - within teams and across organisational disciplines.
  • As much as we all have our specialities the most effective outcomes come from great collaboration and teamwork and rarely from deference to authority.
  • We actively encourage a culture of healthy conflict and disagreement, but we also expect everyone to respect each other’s differences, to be looking to get the best out of each other and - when the consensus is against us - to work towards the chosen solution as if it was our own.

We prefer to solve problems that people haven’t solved before

  • We prefer to use things that are already there. When faced with a challenge we should first be looking for - and evaluating - prior knowledge and implementations , whether that be internally, via open source software or 3rd party vendors.
  • When we can solve problems using other people’s tools or software, we have a preference for things which are already used, already known, or already written … in that order.

We prefer not to do the same thing twice

  • Repetitive manual tasks are cumbersome and prone to human error. If something needs to be done twice it should probably be automated.
  • To aid this goal, when making choices we should lean towards those technologies that lend themselves to automation. These technologies often share characteristics such as having an API; being drivable from a CLI; not having licensing complications that require manual interactions; choosing to ask other services for information frequently rather than storing it internally.
  • However, we’re aware of the desire to abstract solutions too early, in order to solve superficially similar problems with the same tool. We know this is both attractive and dangerous!

We make and use things which are discoverable and accessible by design

  • Our applications and services, and information about their states, should be easily discoverable and accessible by services such as diagnostics, monitoring, other collaborating services, and the human eyeball.
  • We should all work towards and comply with common shared standards, whether that be internal ones or industry best practice. Where those standards don’t exist we discover and implement them.
  • We prefer 3rd-party technologies which are easily discoverable by design and best comply with our shared standards.

We are mindful of failure

  • All our applications need to be resilient, robust and secure. To achieve this we should be preoccupied with all the ways our services can fail and design them in a manner that means they degrade gracefully, we’re alerted as soon as something is wrong and can quickly diagnose and rectify problems.
  • We resist oversimplification and the urge to write off small problems as “business as usual”.
  • We encourage a just culture where people can feel safe to report adverse events and near misses without fear of punitive action.
  • We’re mindful of all the possible ways that our services could be exploited and have security front of mind with everything we do.

We don’t like inappropriate intimacy

  • Applications or services should not have intimate knowledge about the innards of anything else.
  • If one service fails this should not indirectly affect any of our other services.
  • Tight coupling via unnecessary dependencies also causes business friction and slows us down.


Wednesday, May 11, 2016 - 04:20

Today marks the beginning of the Technical Academy Tour as Academy Coordinator, Miles Pool, VP Technology, Paul Shannon and later, former apprentice, Mia Filisch head out across the UK to talk about our Technical Academy.


Continuous learning has always been part of the culture at 7digital and the Technical Academy allowed us to focus those ideas and start hiring apprentices. Changing the team entry requirements and providing a defined period of training allowed us to attract people from more diverse backgrounds and has increased the proportion of female developers in our team; it’s also strengthened the culture of learning and knowledge sharing at every level.

Emma-Ashley Liles
Monday, April 4, 2016 - 13:48

Since I started at 7digital I’ve loved our belief in continuous improvement. Throughout our history as a company we have had a number of influential women working in various parts of organisation yet I knew there was more we could do to improve the diversity of our tech team.


Tuesday, February 16, 2016 - 18:30

Here at 7digital, we see the relationship between the customer and the developer as one of the most important aspects of software development. We treat software development as more of a craft than an engineering discipline. Craftsmen back in the day would have constant communication with their customers, receiving regular visits from their customer to discuss progress and alterations as the item takes shape.


Over the last twenty years, the agile software movement and extreme programming in particular has championed this with its short iterations, customer showcases and active customer participation in the creation of features.


Tuesday, December 1, 2015 - 20:10

7digital software developer Mia Filisch attended the October 28th Velocity conference in Amsterdam. She was kind enough to share her account of the core takeaways here with us. She found that the core recurring theme around security was enough to inspire some internal knowledge sharing sessions she has already started scheming on. The diversity of insights led to a productive and informative conference. See below for her notes.


Key takeaways from specific sessions: