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 want to be responsible for business outcomes – not for making organisations feel like they are more agile. Agile is simply a means to an end.

While we value the XP practices in particular, we do not mandate any specific practice in our deliveries; we want to avoid ‘cargo cult’ agile, where people blindly follow a practice for the sake of it. Instead, we seek to always pay attention to what a given practice is really trying to achieve. No practice is so important that it can not be questioned and adapted to meet the desired outcome.

Context is king when it comes to choosing which agile practices to apply in a given delivery. This is an area where our experience makes a real difference, because the less prescriptive we are, the more disciplined we must be. We have sufficient mastery of agile practices to choose wisely which will work best in a given situation.

Whichever blend of practices we use, we use short feedback cycles to either constantly improve and iterate towards a shared definition of success with the client – or ‘fail fast’, minimising the investment required to determine a given approach will not work.

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.

While we are always agents of change within our client organisations, our engagements vary hugely in nature, and evolve over time.

Sometimes we appear early in a timeframe and are there to disrupt with exploratory visionary work. Sometimes we come in late, to support and evolve an existing service. We are aware of where our engagement stands in the lifecycle so we can behave appropriately.

Ideally, we seek to turn ideas into scalable products and implement long-lasting changes that can be handed over to the client (acting as Pioneers, Settlers and Town Planners, to borrow the metaphor written about by Simon Wardley)

Above all, we like getting things done. Practical innovation is much more important to us (and our clients) than academic or abstract ‘thought-leadership’; leading-edge, not bleeding-edge is often the most effective route to creating new value.

We don’t pretend to know all the answers – but we are confident in our ability to find them.

We do not hire very experienced people because they know everything; it’s because they are better at knowing how and where to look for the answers. We trade on our ability to learn and share knowledge, rather than protecting or ‘guarding’ it. At its core, Equal Experts is a haven where this sharing happens freely and happily, between like-minded practitioners.

The inquisitiveness of youth is a great thing. People who can retain this mindset throughout their career – so it can be combined with experience – are where the real value lies. It’s this quality we look for when inviting new people to join our network.

No matter how good we think we are, we want to be part of an even better team.

Teams are greater than the sum of their parts. High performing teams will always outperform individuals, no matter how much of a “superstar” they may be.

All people at EE have something to contribute. No matter what role they play in an EE team, they have an equal say in how to go about the delivery. Our Tech Leads and Delivery Leads are there to provide support and leadership when needed; not to dictate every single decision.

This means that every team member is accountable and responsible for the delivery, as part of the team – and we all behave accordingly.

Although it’s always nice to gain recognition for EE, we’re paid to ensure we achieve our client’s goals – not further our own agenda. We are part of the client’s overall delivery group, not the other way round.

We do not brag about EE and our own contribution louder than we brag about the overall delivery success of the client. For all that we do, it is just that – a contribution.