Product judgment. Systems thinking. Engineering accountability.
The leadership of a technology consultancy should be evaluated by how it reasons about problems, makes tradeoffs, manages delivery and tells the truth about what is known.
How do you evaluate the judgment behind a recommendation?
Follow a decision from the business need through its tradeoffs to the person accountable for the result. Ask what was considered, what remains uncertain and what would make the recommendation change.
Product judgment
Does the proposed capability solve a worthwhile problem for a specific user?
- Follow the reasoning into the record
- The user need, intended change, scope and the reason this is the next useful investment.
Systems thinking
Does the design fit the processes, information and dependencies it will have to live with?
- Follow the reasoning into the record
- System boundaries, alternatives, operating constraints and the assumptions behind the choice.
Engineering accountability
Who can demonstrate that the agreed result works and decide whether it is acceptable?
- Follow the reasoning into the record
- Responsibilities, acceptance evidence, unresolved limitations and the handover boundary.
Name the responsibility at each decision.
Leadership can connect product framing, business architecture and client decisions. That does not remove the need to identify the qualified engineering contribution required by the particular project.
Frame the requirement
Identify the business decision owner and the people who understand the users and operating process.
- Ask who can answer
- Who can resolve conflicting requirements and agree what is outside scope?
Select the approach
Identify who prepares the architecture and who reviews the technical, data and integration constraints.
- Ask who can answer
- Who can explain the alternatives and accept the implications of the chosen design?
Deliver and accept
Identify the engineering responsibilities and the client-side authority to accept the agreed result.
- Ask who can answer
- Who tests the important failure cases, and who decides whether the remaining limits are acceptable?
Operate and change
Agree who takes control, who supports the system and who authorizes changes after handover.
- Ask who can answer
- Who acts when behavior, dependencies or business requirements change?
Good judgment includes a reason to change course.
These are questions to apply to a proposed engagement, not accounts of past projects. A recommendation should remain accountable to its assumptions.
- The problem is not yet clear.
- Resolve the product and business requirement before treating a technology choice as the answer.
- The evidence does not support the design.
- Narrow, revise or stop the proposed work. Explain the failed assumption and the next decision it creates.
- Responsibility is still ambiguous.
- Name the required expertise, decision authority and acceptance owner before making a delivery commitment.
Open the questions for a first conversation
- Which part of this problem needs business judgment, and which part needs specialist engineering review?
- What is the strongest alternative to the recommendation?
- Which assumptions remain untested?
- Who will own the decision, the engineering and the acceptance of the result?
A point of view is a starting point for diligence.
Leadership visibility helps a buyer assess how a firm reasons. It should be considered alongside accurate background, relevant references, appropriate engineering expertise and technical evidence for the proposed work.
The full argument for leadership accountability
For CTO, CIO, CPO, COO
The perspective behind the work
Vikram Roy is the founder and Chief Architect of The Quiet Protocol, where he leads product strategy and system design. For the Marmation Review, he writes about software architecture, enterprise AI, integration, evaluation and the operational decisions that determine whether a system is ready for production.
Follow the reasoning
A useful recommendation connects a specific user need to the architecture, the delivery constraints and the evidence required to accept the result. Ask which alternatives were considered, what remains uncertain and what would make the recommendation change.
Product judgment identifies whether a capability is worth building. Systems thinking examines the processes, information and dependencies around it. Engineering accountability makes the acceptance criteria and operating responsibilities explicit.
Establish responsibility before delivery
For a proposed engagement, identify who frames the requirements, prepares and reviews the architecture, implements the system and accepts the result. Agree the engineering contribution required by the actual scope rather than inferring a team from a biography.
At handover, identify who controls the repository and infrastructure, who can authorize changes and who responds when a dependency or requirement changes. These responsibilities belong in the engagement agreement.
Evaluate the work, as well as the person
A public perspective helps a buyer assess judgment. References, relevant implementation evidence and qualified engineering review answer different questions. Request those for the work being commissioned.
Start with the Marmation Review and the engineering approach. Bring a difficult decision, and examine the assumptions and tradeoffs behind the proposed answer.