Know Your Team. Know Your Work.
Working with an external engineering team should not mean losing visibility into the people, decisions or effort behind the work.
KNOW WHO IS WORKING WITH YOU
The people assigned to your engagement and their responsibilities should be clear. If additional capability needs to be hired or brought in, we tell you rather than presenting it as already available.
ACCESS THE PEOPLE RESPONSIBLE
Questions should not have to travel through layers of account management before reaching someone who can make a decision. Delivery and engineering responsibility remain accessible during the engagement.
SEE THE WORK AS IT MOVES
Priorities, work in progress, completed work, issues, testing and releases should remain visible. Where the engagement is effort-based, the customer should also be able to understand where that engineering effort is being spent.
KNOW WHEN SOMETHING CHANGES
People leave. Requirements change. Estimates move. Technical assumptions can turn out to be wrong. We communicate material changes rather than allowing the customer to discover them later.
Visibility isn't a reporting exercise. It gives both teams the information needed to make decisions while there is still time to make them.
Commitments We Can Stand Behind
Trust becomes more useful when it translates into things a customer can actually expect from us. These are commitments we believe should be visible in the way an engagement is run.
SCOPE BEFORE COMMITMENT
We document what we understand we are delivering, the important assumptions and known exclusions before committing to the corresponding work.
NO HIDDEN STAFFING
If required capability is not currently available and needs to be hired or sourced, we say so. We don't present future availability as current capacity.
MATERIAL TEAM CHANGES ARE COMMUNICATED
People can change during an engagement. When a material change affects the agreed team or responsibility, the customer should know.
OUR DEFECTS ARE OUR RESPONSIBILITY
If delivered software fails because of an implementation defect attributable to our work, we take responsibility for correcting it in accordance with the agreed warranty terms.
YOUR WORK SHOULD NOT BE HELD HOSTAGE
Code, documentation, credentials and other project assets are handled according to agreed ownership and access arrangements so the customer's ability to continue the work does not depend on withholding them.
ESCALATION REACHES SOMEONE WHO CAN ACT
When a delivery issue requires escalation, the customer should have access to someone with the authority to address it.
AI Doesn't Remove Human Responsibility
WHEN OUR PEOPLE USE AI
CUSTOMER INFORMATION IS NOT INPUT MATERIAL BY DEFAULT
Access to customer code, data, credentials, documents or other confidential information does not automatically mean it can be submitted to an AI tool. Its use must follow the security, confidentiality and contractual requirements of the engagement.
GENERATED DOESN'T MEAN APPROVED
AI-generated code, tests, documentation or analysis remains subject to appropriate engineering review and validation before becoming part of customer work.
THE ENGINEER REMAINS ACCOUNTABLE
An engineer cannot transfer responsibility for an implementation decision to the model or tool that assisted them.
WHEN WE BUILD AI FOR CUSTOMERS
ACCESS SHOULD HAVE BOUNDARIES
An AI system should only have access to the information, tools and actions appropriate to what it is expected to do.
AUTONOMY SHOULD MATCH THE RISK
Not every decision should be delegated to an agent. Human approval, escalation or other controls should remain where the consequence warrants them.
AI OUTPUT NEEDS TO BE TESTED DIFFERENTLY
AI behaviour can be probabilistic. Evaluation, monitoring, failure handling and appropriate human oversight therefore become part of the engineering problem.
Customer First Doesn't Always Mean Yes
SOMETIMES THE SMALLER SOLUTION IS ENOUGH
If an existing product, platform or simpler implementation can solve the requirement, custom development should not be the automatic answer.
SOMETIMES WE SHOULD CHALLENGE THE REQUIREMENT
A requested feature or technology can add cost and complexity without adding equivalent value. We should be willing to question it.
SOMETIMES EXISTING SOFTWARE SHOULD STAY
Newer does not automatically mean better. Software that continues to serve its purpose should not be replaced simply to create a modernisation project.
SOMETIMES AI ISN'T THE ANSWER
Automation, conventional software or a better process may solve the problem more reliably or economically than adding AI.
SOMETIMES WE SHOULD SAY WE'RE NOT THE RIGHT TEAM
If a requirement depends on capability we cannot responsibly provide, the customer is better served by knowing that before the engagement begins.