DBA Value in the AI Era: Lessons from Rory Sutherland

There has been a lot of noise on LinkedIn this year about the state of the technology job market, and AI is taking most of the blame. Some of that is overblown. Some of it is not. A feed cannot tell you what caused every decision, but from mine there is no question that database professionals, DBAs in particular, are being caught in the disruption, and the uncertainty people are describing is real. Six months ago at SQLBits I took part in a panel asking whether AI would replace us. The answer then was a confident ‘not yet’. The question has not changed since, but the mood around feels like it has.

What interests me is not whether AI is to blame. It is how DBAs are responding when their jobs are threatened, because the response is failing, and behavioural science explains exactly why. If you are a DBA trying to prove your worth right now, I think you might be arguing the wrong case in the wrong language, and I want to show you a better one. Most of it comes from a book I read over the summer: Alchemy by Rory Sutherland.

One thing before we go further. Being made redundant is not a verdict on your competence. Excellent people lose jobs, and better communication cannot guarantee protection from a restructuring. But there is a useful question underneath all the provocation: does the business actually understand the value you already create? For most DBAs I have worked with, the honest answer is no, and that is fixable.

The rage bait, and the logical reply

You will have seen the posts. ‘DBAs affected by layoffs need to prove their worth.’ I am not saying they are deliberately written as click bait, but you know how it goes. They provoke a reaction, and the reaction from DBAs is entirely predictable. They do what they do best. They get logical.

Out come the numbers. CPU cycles saved. Licence costs cut by consolidating workloads onto a smaller VM. Storage reclaimed. Backups that completed every single night for four years. Query plans tuned from eleven seconds to forty milliseconds. It is all true and it is all admirable. It is also almost completely useless as an argument for keeping your job.

Here is the uncomfortable disonnected bit. Outside the DBA and IT bubble, nobody gives a damn about CPU cycles. Finance directors do not lie awake worrying about tempdb contention. The board does not have a line item for ‘things that did not go wrong’. When a DBA responds to ‘prove your worth’ with a spreadsheet of technical efficiencies, they are answering a human, emotional, political question with an engineering answer. And then wondering why it does not land.

What Rory Sutherland would say about the DBA’s problem

If you have not come across Rory Sutherland, he is the vice chairman of Ogilvy UK, something of a TikTok sensation, and the most entertaining thinker I know on the gap between how people actually behave and how we assume they behave. Alchemy is his argument that businesses are obsessed with logic, that logic is often the wrong tool, and that the most valuable ideas are frequently the ones that look irrational on a spreadsheet. His TED talk Life Lessons from an Ad Man is the twenty-minute version if you want a taster.

To be fair to the underlying research, Sutherland is an interpreter and practitioner of behavioural science rather than its inventor. Amos Tversky and Daniel Kahneman showed decades ago that presenting equivalent choices differently changes what people choose, in their work on decision framing. That does not make every executive irrational, and translating a technical result into plain English is not exploiting a bias. It simply reminds us that presentation is part of how decisions get made. Sutherland’s gift is making that usable.

Several of his ideas map almost perfectly onto the DBA’s situation. I will take them in turn.

1. The doorman fallacy

This is the one that should be pinned to the wall of every IT department going through a ‘cost optimisation’ exercise.

Sutherland describes a hotel that looks at its doorman and decides his job is opening doors. Doors can open themselves. So the doorman is replaced with an automatic door and the saving goes straight to the bottom line. Except the doorman was never really there to open doors. He hailed taxis, recognised regular guests, kept undesirables out, carried luggage, signalled that this was the kind of hotel that had a doorman. The hotel defined the role by its most visible, most automatable task and lost everything else.

Now read that paragraph again and replace ‘doorman’ with ‘DBA’. The visible task is running backups, applying patches, tuning the odd query. All of that can be automated, and a great deal of it already has been, well before large language models arrived. If that is how the business defines the role, the role is finished. But the DBA I have in mind was never really there to run backups. They were there to notice that the new release would lock the orders table on the first of the month. To push back on the vendor who wanted sysadmin on the production box. To know, from fifteen years of pattern-matching, that a particular wait type at a particular time of day meant the SAN was about to fall over. None of that appears in the job description, and none of it appears in the business case for replacing them.

The doorman fallacy is a measurement failure, which brings me to the next idea.

2. What gets mismeasured gets mismanaged

Everyone knows ‘what gets measured gets managed’. Sutherland’s sharper version is that what gets mismeasured gets mismanaged. Decision makers run on data, and data only ever records what happened. It has nothing to say about what did not happen.

A DBA’s whole value proposition is things not happening. No outage. No data loss. No ransomware encrypting the backups. No 3am call. You address a capacity issue before the system stops. You repair a broken backup chain. You remove a dependency that would make recovery impossible. Then everyone has an uneventful Tuesday. The better you are at the job, the fewer events there are to point to. You have spent years making yourself invisible to the business, and then the business looks at the data and says: ‘We have not had a P1 in six months. Why are we paying Gethyn to manage this for us?’

I have heard almost exactly those words. The absence of incidents was read as evidence that the role was unnecessary, when it was actually evidence that the role was being done well. That is mismeasurement, and in a tight year, mismeasurement becomes a redundancy. To be clear, a quiet month does not prove the DBA prevented a catastrophe. It means the absence of incidents tells an incomplete story, and if we only ever report the incidents, we hand the business an incomplete account of the service.

Compare that to a DBA I worked alongside for years. Good bloke, great skills. He used to enjoy it when things broke, and I understood why. There is something genuinely rewarding about diagnosing a problem under pressure and getting a business moving again. When something broke, he fixed it, and for about a fortnight afterwards everyone in the building knew what he was for. The same executives who could not care less about CPU cycles cared enormously when the business could not take orders and profit was draining out of the door. Being seen to fix the fire is worth more, politically, than quietly preventing a hundred of them.

That is a horrible incentive. I am not suggesting you let things break. I am suggesting you fix the measurement so that prevention becomes visible.

3. Psycho-logic beats logic

Sutherland’s central idea is that humans do not run on logic. They run on what he calls psycho-logic: a set of mental rules that evolved to work well enough in an uncertain world, and which often look irrational if you only examine the spreadsheet. His recurring example is the Eurostar. The logical solution to a slow train journey is to spend a fortune making the train faster. The psycho-logical solution is to put wifi and good coffee on it so nobody minds the time. One costs billions and the other costs almost nothing, and the second one improves the experience more.

DBAs are trained to find the logical solution. We measure, we diagnose, we optimise. That is a fantastic way to run a database and a terrible way to run an argument with a human being who is deciding whether to keep you.

Think about what the decision maker actually feels. Not ‘how many cycles has this person saved?’ but ‘if I keep this person and something goes wrong anyway, do I look foolish? If I let them go and something goes wrong, do I look foolish? Which is the bigger risk to me?’ That is the psycho-logic. Loss aversion, reputational risk, the fear of being the person who made the call. Your argument has to speak to that, not to the hardware.

4. Nobody gets fired for being logical

One of Sutherland’s most quotable observations is that it is easy to be fired for being illogical and almost impossible to be fired for being logical, even when logic produces a bad result. This explains most corporate decision making, including a great deal of the layoffs we are seeing.

Cutting headcount is logical. It produces a number. The number goes in a deck. If the cut turns out to be a disaster eighteen months later, the person who made it can point to the spreadsheet and say the decision was sound on the information available. ‘Keep the DBA because of the things they stop from happening’ is not a spreadsheet. It is a judgement call, and judgement calls are dangerous to make in an organisation that punishes being wrong more than it rewards being right.

If you want to survive that environment, you have to give the decision maker a logical-looking reason to do the sensible thing. You have to make keeping you the defensible choice.

5. Costly signalling and reassurance

Sutherland spends a lot of time on signalling: the idea that an expensive, visible commitment carries information precisely because it is expensive. The brand that spends on a big advertising campaign is signalling that it expects to be around long enough to recoup it. The restaurant with the lavish fit-out is signalling confidence in its food.

Part of what a DBA, or an external specialist like me, provides is reassurance. Not just the outcome but the knowledge that someone competent is watching. That has a real value, and it is a value people are willing to pay for in every other domain. Nobody questions paying for insurance in the year the house does not burn down. Nobody cancels the smoke alarm contract because there has been no fire. The reason they do question the DBA is that nobody has framed the role as insurance. It has been framed as maintenance, and maintenance is a cost to be reduced.

6. The countdown display: reduce uncertainty, not just downtime

One of Sutherland’s favourite examples is the countdown display on a railway platform. In a TED interview he explains that knowing when the train will arrive transforms the experience of waiting, even though the train does not travel a second faster. The display does not change the service. It gives people information they can act on.

Now think about a database incident. The technical team is making progress, and the rest of the business hears nothing. Nobody can tell customers what is happening. Nobody knows whether to start the manual workaround. Senior managers keep interrupting because they need something to say upwards, and every interruption slows the fix. A short, dependable update is the countdown display:

Order entry remains unavailable. We have isolated the affected component and are testing the recovery step. We do not yet have a reliable restoration time. The next update will be at 10.30.

No invented promise. A clear statement of impact, current action and the next communication point. The same thinking applies before anything breaks. Tell service owners what has been tested, which recovery assumptions remain untested and what decisions they would face during an interruption. A completed restore test and an understood recovery plan provide two different kinds of reassurance, and both are part of the service. Reducing avoidable uncertainty is DBA work, and it is work the business can see.

7. Consistency beats the average

In an Ogilvy interview, Sutherland makes the point that people prefer a consistently satisfactory experience to one that is sometimes excellent and sometimes dreadful. The variance is what they remember.

Suppose a management report takes an average of twelve minutes to refresh. That sounds fine until you discover it occasionally takes ninety minutes, and that one of those occasions was the morning of the board meeting. The average misses the only part the finance director remembers. Or an overnight process that usually finishes comfortably before the working day, but once a month overlaps with the first customer transactions. Those exceptions shape how the entire service is perceived.

So report the behaviour that affects the business: deadlines met, variability, the slowest relevant periods and the experience at peak demand. Choose those measures with the service owner over a representative period, and resist improving a headline average while the painful exceptions go untouched. A DBA who makes the platform predictable creates value even when there is no dramatic saving and no impressive before-and-after screenshot. Predictability is what lets a business make commitments.

‘Doing more with less’ is the wrong frame too

It is worth stepping back from the DBA for a moment, because the same mismeasurement is driving the wider AI story.

The organisations I see doing genuinely impressive things with AI are not the ones making sweeping cuts and trying to do more with less. They are doing more with what they have. The same people, empowered by the tools, delivering more work, more value and, this is the word that matters, more growth. Not savings. Not CPU cycles. Growth. Savings are nice, and in a business under pressure they are necessary, but no business ever grew into something significant by cutting.

Let me give two examples without divulging too much. My very first client when I started the business back in 2007 was an insurance company. Small in headcount, enormous in what they delivered. Even then they were doing with 400 staff what larger insurers could only dream of doing with 4,000. They embraced AI before AI was fashionable, and when large language models arrived, and then small language models, they baked them into workflows rather than announcing a headcount reduction. I have worked with them several times over the years. They still have around 400 staff. Revenue, I am told, has increased significantly. That is an observation from a client relationship rather than an audited comparison, and it does not isolate AI’s contribution. But it illustrates the ambition I find useful: same people, more output.

The second example is from the last eighteen months helping a large Microsoft training partners with Copilot rollouts, mostly for very large organisations in North America. The pattern is identical. The organisations treating AI as a way to remove people get a compliance exercise and a lot of quiet resistance. The ones treating it as a way to make their existing people more capable are the ones gaining real traction. People lean in when the tool is for them rather than instead of them.

For a DBA, that means the time automation releases is capacity, and its value depends entirely on what happens next. Use it to close recovery weaknesses, support a new customer-facing service, fix the data quality problem everyone complains about, or remove a constraint on growth. Good data platform planning should be weighing all of those outcomes, not just the headcount line. And the organisations that get this right are the ones that understand the doorman fallacy instinctively. They do not define a role by its most automatable task.

Is the DBA dead? The old one, maybe

I am not going to pretend nothing is changing. Human beings resist change, and technology people have been slightly insulated from it over my career. Things went online, the internet arrived, data became a big deal, and each time we were the ones delivering the change to everyone else. Now it feels like we are on the receiving end. That is uncomfortable for some, maybe many, but it is not the same as being replaced.

The version of the DBA who spends all day poring over code and indexes is probably finished. The machines can take a lot of the hard yards. Brent Ozar has described the result as DBAs becoming middle managers, directing a workforce of tools and agents they never recruited and trying to get an acceptable result out of them, in a job they never signed up for. His piece, When You Work with AI, You’re a Middle Manager, captures the frustration honestly, and I recognise the discomfort. If you built your professional identity around being the person who could diagnose the hard problem or write the awkward query, handing part of that over feels like a loss. People also have reasonable concerns about being made responsible for output they have no time to validate.

Brent is not wrong that the job has changed. I would, perhaps,  put it more positively. If you do that job properly, you stop being the person who tunes queries and become the person who shapes how the business uses its data: choosing worthwhile problems, defining acceptable results, testing assumptions and connecting technical decisions to business priorities. That is a far more valuable position, and it is one AI cannot easily take from you, because it depends on judgement, context and relationships rather than execution.

Some words of warning. I would be wary of any career strategy built solely on being faster at producing a particular technical artefact, because that is precisely the ground the machines are taking. I would be equally wary of pretending that communication can compensate for weak engineering. The role needs both.

There is a parallel with the ‘coding is dead’ argument. Yes, the machines can churn out code faster than a human from a blank page, and the protests that it is not quite as good are mostly beside the point, because it is no longer economical for a person to do that work by hand. But generating code was never the valuable bit. Knowing what to build, why, and what will break when you do was the valuable bit. Same with databases.

A behavioural playbook for the DBA who needs to prove their worth

Enough diagnosis. Here is what I would actually do, drawn directly from Sutherland’s thinking.

Frame everything around the business service

A DBA reports that a query now uses fewer logical reads, less CPU and completes in two seconds instead of twenty. Keep those numbers. Then establish what the query supports. If it sits behind a customer-service screen, the conversation is about how quickly colleagues can help customers. If it runs once overnight with hours to spare, the same improvement may mean nothing operationally. Context determines commercial importance.

Take an illustrative case: a screen used 3,000 times a day, each use eighteen seconds faster. That removes fifteen hours of accumulated waiting across those interactions. It does not automatically save fifteen paid hours, because people were doing something else while they waited and other constraints remain. The next step is to check whether calls got shorter, queues reduced or staff handled more work. The technical measurement establishes what changed. The service measurement establishes why it mattered. A finance director may care about reduced CPU if it produces a demonstrable cut in the infrastructure bill. An operations director cares about predictable processing on the busiest day of the month. Find the decision each of them needs to make, then bring the evidence that helps them make it. This is where SQL Server performance work stops being an IT activity and becomes a business conversation.

Make prevention visible, honestly

Sutherland’s emphasis on perceived value raises an uncomfortable possibility: useful work gets undervalued simply because nobody can see it. There is research behind that. Ryan Buell and Michael Norton found that making service effort visible increased how much people valued the result, which they called The Labor Illusion. Their experiments were about online services, not database teams, so applying it here is an inference. It is a sensible one.

So keep a record. Every time an alert you built, a job you automated or a check you ran caught something before it reached production, log it: the condition detected, the action taken, the evidence, the business service affected and what remains unresolved. An entry might read:

A scheduled recovery exercise exposed a missing dependency in the order-processing recovery procedure. We corrected the procedure and completed a repeat test successfully. The application owner validated the agreed order-processing checks.

Notice what that entry does not say. It does not say ‘a £500,000 outage prevented’, because that would require evidence we do not possess. We know what failed in the exercise and what improved afterwards. We do not know that a production incident would have happened next Tuesday. An alert that found a dangerous condition is evidence of detection and intervention, not a countable outage avoided. Make the quiet work visible without manufacturing drama, because the moment a sceptical finance director catches one inflated number, every other number on the page is worthless. The objective is an accurate picture of the service, published monthly, to your manager and their manager. You are fixing the mismeasurement at source.

Translate into the decision maker’s psycho-logic

Stop talking about efficiency and start talking about risk, reputation and regret. ‘If this had happened during month-end close, finance would have missed the reporting deadline’ is a sentence an executive feels in their stomach. ‘I reduced logical reads by 60 percent’ is not. Every technical win has a business consequence. Lead with the consequence.

Reframe the role as insurance, not maintenance

Maintenance is a cost. Insurance is a premium that sensible people pay. When you describe what you do, describe the risks you carry on behalf of the business: data loss, ransomware recovery, regulatory exposure, the vendor change that would have taken the platform down. The reassurance you provide is a product. Price it that way in your own head, and the business will start to as well.

Change the comparison being made

When someone puts a DBA’s salary next to the subscription price of an AI tool, the options have been defined far too narrowly. The business does not need a DBA. It needs a service: performance, recoverability, access control, safe change and someone accountable when it goes wrong. Different combinations of people, platforms, suppliers and automation can provide that, and the comparison should be between those combinations, with the same service expectations and the same evidence requirements on each side.

A tool can draft a script in thirty seconds. The work still includes deciding whether the script solves the right problem, checking its effects, testing it and living with the consequences of deploying it. Those activities have a cost wherever they sit. Removing a DBA post usually transfers the work to developers, infrastructure or an external provider rather than eliminating it. Sometimes that is the right call. A smaller estate, better automation or a managed service can genuinely change the staffing requirement, and a credible argument acknowledges that. But ‘can AI produce this SQL?’ is a narrow question. ‘How should we deliver this database service effectively?’ is the one the business should be answering, and it is the one Sutherland would ask. Improve the question, and the answer improves with it.

Give them a logical reason to make the illogical-looking decision

Remember that your manager needs cover. If they want to keep you, they need a sentence they can put in a deck. Give it to them. A one-page summary of detected risks, demonstrated improvements and the specific exposures that would be unmanaged without the role is exactly that. You are not just arguing for yourself. You are making it safe for someone else to argue for you.

Sweat the small stuff: run experiments

Sutherland’s talk Sweat the Small Stuff challenges the assumption that a big problem needs an expensive solution. You do not need a transformation programme. Pick one frustrating business process. Establish a baseline. Agree what improvement would matter. Test a bounded change through the proper controls, then review the result with the people affected. Maybe it is a recurring data request, or developers waiting days for a usable test environment, or a weekly database report that no service owner can understand.

For AI-assisted work in particular, measure the whole task: preparation, checking, correction and rework, not just the thirty seconds of generation. Compare the time and quality of producing a reviewed runbook with and without AI assistance. Test whether a one-page service report actually helps a business owner decide faster. Let the result decide the next step. A disappointing trial is useful information, provided you controlled the scope and the cost.

Lean into the middle management, properly

If the job is now managing tools and agents, be excellent at that and visible doing it. Set the standards the automation runs to. Own the governance around what AI is allowed to touch in production. Be the person the business asks before it lets a Copilot agent anywhere near the data. That is not a demotion from engineering. It is the role the organisation most needs filled and least understands.

Use the tools yourself, loudly

The most dangerous position is to be the person resisting AI in a business that has decided to adopt it. The strongest position is to be the person who used it to do three times as much and can show the receipts. Doing more with what you have applies to you as an individual as much as to the organisation.

A monthly DBA value report someone might actually read

All of the above collapses into one artefact: a single page, once a month, discussed with a person who owns an important business service. Five elements.

• Service and priority: the business process supported and what matters to its owner.
• Observed result: what changed, the baseline, and the period measured.
• Business consequence: the effect on cost, capacity, customer experience, deadlines or recovery capability.
• Confidence and limits: what is demonstrated, what is estimated and what is still uncertain.
• Next decision: the improvement, experiment or investment that needs agreement.

A recovery entry might read:

The database restore stage completed in 42 minutes in this month’s exercise, compared with 94 minutes previously. It met the agreed 60-minute target for that stage. Application validation and external dependencies were outside the exercise. The next step is an end-to-end service recovery rehearsal.

A useful result with an honest boundary, and a decision at the end of it. A performance entry might show the billing process met its deadline every working day following a change that removed a recurring delay. A cost entry might show an actual reduction in the infrastructure bill, kept strictly separate from estimated future spend avoided and staff time released. Resist filling the page with activity counts. Twenty closed tickets might be excellent work or twenty symptoms of the same unresolved problem. The report exists to show what improved, what remains exposed and where attention should go next.

Leaders have a responsibility here too

If you manage technology teams, create room for this conversation before the budget review or the redundancy exercise, not during it. Ask what makes the quiet months possible. Ask which business ambitions are constrained by the current data platform. Ask what the team could improve if repetitive work took less time.

Reward prevention as well as firefighting. Give people an incentive to share knowledge, automate and remove dependencies on themselves, because right now the incentive runs the other way. Otherwise you build a culture in which the person who fixes the outage gets the recognition and the person who stopped ten of them gets the redundancy letter. DBAs can make their contribution easier to understand. Leaders should make the effort to understand it.

Food for thought

The DBA’s instinct, when threatened, is to reach for logic. That instinct is exactly what makes a great DBA and exactly what makes a weak case for keeping one. Rory Sutherland’s point is not that logic is wrong. It is that humans do not make decisions with it, and if you want a human to make a decision in your favour, you need to speak the language they actually use.

Keep the technical evidence. Connect it to a consequence someone recognises. Explain the uncertainty honestly. Frame yourself as insurance. Make it safe for someone to keep you. Then propose the next worthwhile improvement. Start with one business service and one conversation, and you may learn as much about where to create value as about how to explain the value that was already there. The illogical and the irrational, it turns out, can still be a very good answer.

Get the evidence before you need it

If you are a DBA, or the person who manages one, and you cannot currently put a number on the risks your platform is carrying, that is the gap to close first. A SQL Server health check gives you independent, written evidence of what is being prevented and what is still exposed, in language the board understands. Have a look at how the SQL Server health check works, or get in touch and we will talk it through.