Almost every software proposal arrives with senior people on it. The bios are impressive, the experience is real, the names anchor the sale. And then the engagement starts, and the senior people are not the ones doing the work. Sometimes they appear at status meetings; sometimes they sign off on key designs; mostly the day-to-day decisions are being made by someone several levels below the proposal. This is so common it has become normal. It is also the single largest driver of the gap between what a buyer paid for and what the build actually delivered, because the level of person who makes the decisions on the build is the level the outcome reflects, and "senior" on the proposal is not the same as senior on the work.
This piece is a perspective on what senior actually means in a software engagement, and how to tell which kind of senior is being deployed. The argument is opinionated. We have a stake, BY BANKS deploys senior engineers on the actual work as a deliberate model, so the argument tilts toward how we engage. We are not arguing that all proposals are misleading or that junior engineers cannot do excellent work; both are false. We are arguing that "senior" has four observable properties that distinguish exercised seniority from represented seniority; that those properties are testable in selection in ways the typical proposal review does not test for; and that the gap between senior shown and senior deployed is the most expensive part of selecting badly because it is the part the buyer cannot see without asking the right questions. The selection processes that get this right are the ones that test for deployed seniority specifically, not just credentials.
The audience for this analysis is buyers comparing software proposals where senior leadership is named on each: founders, CIOs, CTOs, procurement leads, transformation owners. The useful diagnostic question is not "who are the senior people on this proposal" but "for each of the four properties of deployed seniority, can the senior named demonstrate it specifically, on a recent piece of work, or are they representing seniority that other people will exercise".
The Same Four Properties, Two Ways They Appear
Below are four observable properties of senior judgement in a software engagement. Toggle between "senior shown" (how the property appears when seniority is represented but not exercised) and "senior deployed" (how the property appears when seniority is actually on the work). Tap any property to see what deployed seniority looks like there, how to test for it in selection, and what the mismatch costs when it is missing.
Senior shown versus senior deployed: four observable properties
Toggle the view, tap any property to see how to test for it
Why Deployed Seniority Is the Selection Question, Not Credentials
The reason deployed seniority is the question that decides outcome is that engineering judgement is exercised in real time, not delegated by signature. When a build hits the first piece of regulated context that the proposal did not anticipate, the question is whether the person on the work recognises it as such and constrains the design around it, or whether the same person needs to escalate to find that out. When a discovery turns up a dependency that changes the shape of the build, the question is whether the person sitting in discovery sees the implication and adjusts the scope, or whether they report it up and wait. When the operation under the build runs differently from how the proposal assumed, the question is whether the person at the keyboard recognises that the design needs to flex, or whether they ship what was specified. In every case, the level of seniority that is actually on the work is the level at which the answer happens. Seniority that is shown but not deployed is seniority in the wrong place to act on the moments that decide the outcome.
The UAE market makes this economically concrete. Senior leadership and architecture roles in the UAE command material salaries, the Cooper Fitch UAE Salary Guide 2024 lists Solutions Architect roles at approximately AED 432,000 to AED 588,000 annually and CTO/CIO roles at approximately AED 912,000 to AED 1,188,000 annually. Those figures reflect what the market pays to genuinely deploy that level of judgement on the work. A proposal whose senior people are named on the cover sheet and not actually on the build is, in effect, selling the buyer the credential of those people without the cost of deploying them, and asking the buyer to pay for the credential without recognising that what is being delivered is the work of people who command materially lower rates. The economics of the proposal stops making sense once that gap is visible; it makes sense only while the assumption is that the senior names will be doing the work.
This is why the failure is structural rather than dishonest. Most partners that name senior people on a proposal are not lying about who works there; the people exist and are senior. What they are not always doing is committing those people to this specific build, and the proposal rarely makes the difference explicit because doing so makes the proposal weaker. Buyers can require the difference to be explicit, and the partners that hold up under that requirement are the ones who deploy seniority deliberately. The selection that does this well is the selection that surfaces the gap before signing.
The shift in one observation
"Senior on the proposal" is the easiest claim in the procurement process to make and the hardest to test, which is why the recurring failure is buyers accepting it on faith. The four properties of deployed seniority are observable, testable, and rarely tested. The gap between senior shown and senior deployed is the most expensive thing the buyer does not check in selection.
Where the Credentials-Only Selection Breaks
Approval rather than decision
The senior approves designs they did not author and lack the depth to challenge. The technical decision quality is the junior's, with senior cover; the build inherits the limit of the actual decision-maker rather than the seniority on the proposal.
Failure modes encountered first time
Without deployed pattern recognition, the build walks into failures the senior would have recognised on the brief. The buyer paid for the depth that prevents them and got the cost of discovering them in production.
Discovery becomes process, not judgement
If the senior is not in discovery making real-time calls on dependencies and exposures, discovery becomes a templated process producing predictable outputs. The cheapest place to deploy judgement was skipped, and the unknowns surface as build cost.
Regulated context handled generically
Without deployed regulatory judgement, a regulated build is handled generically, with over-claiming on the proposal and supervisory exposure on the system. The senior credentials on the cover sheet did not translate into the discipline the build actually needed.
The Cost of Senior, in Plain Terms
Senior Shown vs Senior Deployed: Side by Side
| Property | Senior shown | Senior deployed |
|---|---|---|
| Decision authority | Signs off decisions made by others | Makes technical and architectural decisions on the work |
| Career depth | Years in the bio | Pattern recognition exercised in real time |
| Scoping | Named as leading discovery | Actually in discovery, shaping its output |
| Regulated judgement | Frameworks mentioned | Precise about the line and self-limiting in claims |
| What the buyer paid for | The credential | The judgement, in the moments it is exercised |
The senior person on the proposal and the senior person on the build are often different people. The four properties of deployed seniority are observable in selection if the buyer asks the right questions, and the buyers that ask are buying judgement; the buyers that do not are buying credentials and discovering the work was done by someone else.
What Testing for Deployed Seniority Looks Like
The pattern in selections that get this right is recognisable. The proposal's senior names are confirmed as the people on this build, specifically and in writing, with their time commitment quantified rather than left to "as needed". Each of the four properties is tested directly: a specific recent decision the senior made and how; a description of failure modes from past experience that would apply here; a walk-through of what discovery would look like for this situation, not generically; a description of the boundary between software and licensed-entity responsibility on a specific regulated decision. The answers are evaluated for specificity, not polish; a serious senior is precise about people, decisions, failure modes, and boundaries, an unserious one talks about teams, processes, best practices, and generalities. The economics are checked: if the senior named on the proposal will actually be deployed at the level the proposal suggests, the proposal price should reflect what the market pays for that level of person on a build, not what it pays for someone several levels below. None of this is adversarial; it is the basic procurement discipline of confirming that what is being bought is what is being delivered.
How This Sits With BY BANKS, Honestly
We have a clear stake in this argument and it is fair to state it openly. BY BANKS engages by deploying senior engineers on the actual work as a deliberate model, the embedded-senior model the perspectives library has described repeatedly. We are arguing for criteria we are strong on, and we lose proposals where the buyer accepts the senior-shown framing on faith because the credential reads as comprehensive. We accept that and continue to argue for testing deployed seniority directly because the alternative, telling buyers what they want to hear, would put them in the situation this article is about.
The boundary stays clear throughout. BY BANKS is an independent software engineering company based in the UAE. We design and build software and hand it over. We do not provide recruitment, staffing, payroll, or employment services. We are not a regulated entity in any sector we serve, we do not act for or on behalf of any UAE authority, and we are not affiliated with or endorsed by any authority. On any engagement, the buyer owns its hiring, employment, procurement, contracting, commercial, regulatory, and compliance decisions and their legal implications. The accountable party leads and owns those obligations; we provide engineering capability at the level we say we do, on the work we say we do.
Where This Analysis Is Useful
The conversations where this perspective is most useful tend to be at three moments: a buyer comparing proposals whose senior names all look impressive and unsure how to distinguish between them; a CIO whose previous engagement produced disappointing technical decisions despite a strong proposal; or a procurement lead trying to set evaluation criteria that test for seniority in operation rather than seniority on paper. The honest answer is usually the same: senior shown and senior deployed are different things, the difference is testable in selection if it is treated as a discrete criterion, and the buyers that test for it are buying the judgement the proposal claimed rather than the credential the cover sheet showed.
For broader related work, see our perspective on how to choose a software engineering partner, our perspective on when to use an embedded engineer, an agency, or a perm hire, and our perspective on the perm versus contract shift. The applied work sits across our operational platforms and technical consultancy capabilities. Get in touch if a 45-minute conversation about a specific selection would be useful.
Frequently Asked Questions
The model is that senior engineers are on the work. We engage mid and junior engineers where the work genuinely benefits from their level, never to make the decisions a senior should make. The seniority on the proposal and the seniority on the build are deliberately the same people; that is the model, and we price accordingly. Other partners run different models, which can be appropriate for other shapes of work. The argument is for honest matching, not for one model.
They are summarised from the Cooper Fitch UAE Salary Guide 2024 as published, specifically Solutions Architect roles at approximately AED 432,000 to AED 588,000 annually (AED 36,000 to AED 49,000 monthly) and CTO/CIO roles at approximately AED 912,000 to AED 1,188,000 annually (AED 76,000 to AED 99,000 monthly). They are point-in-time figures from 2024; the authoritative current data is whatever Cooper Fitch publishes in its latest guide. They are used here as market-cost context, not as a salary benchmark or hiring advice.
No. Mid and junior engineers do excellent work every day on builds where their level is appropriate. The argument is about matching: senior judgement is exercised in real time on the decisions that decide outcome, and a junior making those decisions does not have the depth to do so, regardless of how capable they are at the level they are. The mismatch is the cost; the seniority itself is not the only thing that matters.
By asking about past situations rather than current ones. A specific decision the senior made on a recent build, named or anonymised. A failure mode they have seen and how they designed against it. A discovery they led and what surfaced. A regulated boundary they held and how. None of these requires the buyer to disclose anything sensitive; all of them surface deployed seniority if it is present. Anonymised specifics are usually enough to distinguish.
Then the test confirms what the proposal claims, and the selection is sound on this criterion. The four properties are testable as much in the positive as the negative; partners that deploy seniority well welcome the questions because the questions surface the depth they are deliberately offering. The same questions distinguish between partners that have the depth and partners that do not, which is the point.
"Senior" in a software engagement has two meanings, the credential shown on the proposal and the judgement exercised on the work, and the gap between them is the most expensive part of a poorly tested selection. Four observable properties distinguish deployed seniority from represented seniority: decision authority, depth of context, scoping and de-risking, and regulatory and architectural judgement. Each is testable in selection by asking for specifics rather than accepting generalities, and the partners that hold up under the test are the ones deploying seniority deliberately. The UAE market makes the economics concrete: the Cooper Fitch UAE Salary Guide 2024 figures for Solutions Architect and CTO/CIO roles reflect what the market pays for genuine deployment of that level of judgement, and a proposal that prices senior names without committing them is, in effect, asking the buyer to pay for the credential while delivering the work at a lower level. The selections that get this right are the ones that buy judgement rather than credentials.
This article reflects our perspective on deployed seniority in software engagements. Figures cited (Solutions Architect annual salary range of approximately AED 432,000 to AED 588,000; CTO/CIO annual salary range of approximately AED 912,000 to AED 1,188,000) are drawn from the Cooper Fitch UAE Salary Guide 2024 as published; they are 2024 point-in-time figures and the authoritative current data is whatever Cooper Fitch publishes in its latest guide. The four-property model and its descriptions are an observational evaluation aid rather than a methodology, assessment framework, or scoring rubric, and represent no specific engagement or person. BY BANKS is an independent software engineering company; we design and build software and hand it over, we do not provide recruitment, staffing, payroll, or employment services, we are not a regulated entity in any sector we serve, and we are not affiliated with or endorsed by any authority. On any engagement, the buyer owns its hiring, employment, procurement, contracting, commercial, regulatory, and compliance decisions and responsibility for their implications. This article is not hiring, employment, procurement, regulatory, or legal advice; buyers should obtain qualified advice for their specific circumstances. Public sources used in this piece are listed on our Sources and Data page.
Ready to Build Something?
If this resonated, let's talk about how we can apply these ideas to your business.
Start a Conversation