Powered by MDX

How we consistently deliver 10x results

YOUR TEAM

Engage one of our teams for a minimum of 3 months to deliver a substantial piece of work. To maximise efficiency the team must be given sufficient authority to work autonomously with minimal external dependencies. We do not hire out individual developers. We do not hire "rock-star" or "prima donna" engineers that don't work well in a team

Team structure

A team consists of 4-8 developers. Each team will include both a team leader and a client liaison role - these may be part-time roles depending on the nature of the work. All code is peer-reviewed by fellow team members and there will be coverage within the team to ensure continuing delivery despite unforeseen events such as illness or injury. Developers generally do not interact with the client

Dynamic, complex, uncertain

Our people thrive in a constantly-changing environment with a high degree of uncertainty and much complexity. Therefore work is broken down into small pieces where delivery and quality can be constantly measured. Attempting to specify work in detail in advance is futile

Engineer autonomy

Our people are highly intelligent and experienced. We therefore trust our engineers to make the right decisions (within the team environment) and don't dictate how tasks are to be done or the tools to be used

Engineering principles

We are guided by a set of good practices that have stood the test of time including: testability, maintainability, integrity, well-defined external integration and ethics. We won't build dangerous or poor quality code just because that's what the client wants. We are also acutely aware of the commercial trade-offs that need to be made; delivery is the goal, not perfection

Engineer satisfaction

People work best doing things they are both passionate about and good at. Since quality engineers are in high demand we make every effort to match engineer characteristics to the project and to minimise the risk of dissatisfaction and burn-out. This results in the personnel of a team changing over time as we manage the work an individual engineer is doing

Orderly development

People are poor at multitasking and task-switching. We therefore operate in a way to minimise fire fighting and maximise flow by planning work in small time-boxed amounts (typically 2 - 4 weeks) and then make every effort to adhere to that plan

Chores

Relentless delivery leads to technical debt and code rot. Our teams deliberately set aside time to improve engineering efficiency and refactor existing code which yields substantial long term benefits at the expense of some short-term cost