We’re all here for the same reason: to deliver the best outcome we possibly can, in the most meaningful way.
We typically work within massive organisations. To be able to make a difference, we avoid getting spread too thinly, by focussing on an achievable and narrow goal that will deliver concrete value as soon as possible.
At the same time, we never lose sight of the fact we’re working within complex ecosystems. It’s all too easy to work hard to improve something locally, when the overall effect on the organisation is negligible (or even counterproductive). To avoid this, we’re careful to frame what we do within the wider context of the organisation.
Likewise, we design solutions that are inspiring - keeping an eye on the bigger picture. But we consider ideas that can be validated quickly in the real world. We think big, start small.
We are not precious. Reaching the best outcome for our client always matters more to us than the way we get there; if we really have to choose, we will build the right product over building the product right.
More often than not, reaching a positive outcome does require us to ship technically robust code. But we are careful to avoid getting ourselves into a “build trap” or feature factory, where we deliver feature after feature without clear understanding of the outcome. This is why we invest time in uncovering the right problem to solve, not just doing what the client asked: we deliver outcomes over features.
To ensure our products deliver value, we work hard to connect user needs to business requirements. We respect our clients' existing knowledge of their users, but we challenge using evidence.
Being driven by user needs does not make us blind to (possibly conflicting) business needs. We recognise that organisations have constraints and other goals beyond making the best possible product for their users. We seek to balance these needs to reach a great outcome for our clients.
By doing so, we bring users and organisations together.
Technology isn’t the answer to every problem, but every successful software project is built on rock-solid technical foundations.
Having fewer lines of code is desirable – it’s easier to maintain and understand – but we have seen examples where developers go too far, creating extremely terse programmes that have a very low line count, but are incredibly difficult to decipher. We want less code, but not at the cost of clarity.
We keep the software we build as simple as possible, from the code we write to the technologies / libraries we recommend. However, an uncompromising pursuit of simplicity can risk the wider context being overlooked. The simplest thing that could possibly work for you or your team might not be the simplest approach for the rest of your team or the other teams you work with. We strive for simplicity, but always consider how our choices will impact the simplicity of the overall system.
We drive technical innovation and thinking about new technologies, tools and practices for the benefit of our clients. At the same time, we only introduce new technologies when it makes sense for the client, considering the entire lifecycle of the technology. We are careful not to treat client engagements as opportunities to learn a new technology; when we identify technology that we believe will bring real value to a client, we take a responsible approach to introducing it, ensuring relevant measures are in place to prove it not only works as intended, but can prove increased value to the client.
While we recognise the importance of leadership and a technical leadership role on a team, we also recognise that we are all experts in our profession. Taking autonomy and responsibility away from the team can destroy cohesion within the group and is a recipe for disaster. It is therefore important that the team collectively owns the technical solution and the delivery of any system. This value also mitigates the risk of any single individual putting a project at risk when moving on.
Software delivers little to no value unless it is deployed and running in production, with real users using it. We therefore need to understand how the production environments work, what monitoring is in place and how our software is deployed to production. By understanding the existing processes for monitoring and maintaining software in production, we can ensure that we deliver value to our customers and avoid problems at what is traditionally the most stressful time of a project.
We value the use of rigorous software development techniques that provide fast feedback and assurance that our code works in the way we expect it to. Where others may rely on wishful thinking and assumptions, we strive to prove our design theories are correct using pragmatic, lightweight tests.
In our wider development processes, from design onwards, we apply the same rigour. We focus on testing assumptions early. We design with substance, focussing on function over form, continuously verifying if we are building the right product, guided by qualitative and quantitative research. This helps teams make informed decisions instead of gut feel
Everything we do is delivered with a healthy dose of pragmatism. This does not mean that we will sacrifice our other values for expediency, but it does mean we avoid hard and fast rules that offer little return for disproportionate cost.
Above all, we’re a company of grown-ups – and this is borne out in how we work with our clients.
First impressions count. We care much more about what we deliver to clients, than what it looks like we’re delivering – but it takes time to gain trust, and we want every engagement to demonstrate how great what we do is.
It’s not about literally wearing shiny shoes each day; it’s about remembering that impressions count. We remain aware of the impression we give to others when representing Equal Experts – whether they be our immediate clients, wider stakeholders, or suppliers from other consultancies. And we avoid doing anything that may appear to be wasteful.
Respect is so incredibly important – it’s the most basic, fundamental aspect of any healthy relationship. We never forget this.
We respect the now: the client team and environment, EE colleagues and other suppliers.
We respect the past: our previous clients, past methods (eg. Waterfall), the history of projects before our time.
We respect the future: our client’s vision, and our leaving legacy.
We’re not interested in filling seats for the sake of it – we’d rather not have people billing at all, than have them just “doing the hours”.
However, it’s our responsibility to be valuable – not our client’s. So we look at the wider context of everything we do to ensure we’re really adding value. If we ever realise we are not, we will flag it and find a way to do something useful (and if we can’t, we take a grown-up attitude to leaving the engagement – in a way that’s mutually agreed).
When working with a client we seek to ‘feel their pain’. Only by genuinely understanding a problem can we help to eliminate it.
Once we do feel the pain, we focus on putting things right. We seek to do the right thing by our clients not just because it’s the right thing to do – acting with integrity is the best way to continue our success and provide real value.