When the Guardians Guard Themselves: Parallels Between UK Policing and Software Development

I’ve recently become interested in UK policing (and its widespread failures). In particular, many YouTube videos on Auditing (of police and security staff behaviours). Also known as e.g. First Amendment Auditing in the USA. I’m interested not least because of the parallels I’ve come to see between poor UK policing and the parlous performance of the software development industry.

We don’t often think of police officers and software developers in the same breath. One wears a uniform and carries the power of the state; the other wears hoodies and carries the power to shape our digital lives. Yet scratch beneath the surface, and you’ll find uncomfortable parallels in how both professions can drift from their stated purpose.

Caveat: In those instances where police are well-informed and competent, I commend them for their professionalism and contribution, and thank them sincerely for their service. Sadly this seems rarer than the ill-informed and incompetent.

The Parallels

UK Policing	Software Development
Claimed Expertise Without Competence
Officers don’t know the laws they enforce	Developers don’t understand security, privacy law, or accessibility requirements
Can’t de-escalate. Contaminate crime scenes, lose evidence	Write insecure code, break production, create unmaintainable systems
Ignorant of social dynamics in situations they police	Ignorant of social dynamics in systems they build, and the way they build them
Rely on intimidation rather than skill	Rely on cargo-culting from e.g. Stack Overflow rather than understanding
Lack of Training and Education
Minimal training, no ongoing professional development	Brief bootcamps or degrees followed by on-the-job fumbling
Resist learning about law, psychology, de-escalation	Resist learning beyond their immediate tech stack
Promote based on time served, not demonstrated competence	Promote based on political skill, not technical excellence
‘Learn on the job’ means repeating the same mistakes	‘Self-taught’ often means learning bad practices
Management Through Psychological Violence
Fear: Implicit threat of arrest, detention, violence	Fear: Constant anxiety about firing, PIPs, being ‘managed out’
Obligation: ‘You’re required to comply with us’	Obligation: Unreasonable demands framed as professional duty
Guilt: ‘If you’ve done nothing wrong, why won’t you cooperate?’	Guilt: ‘You’re letting the team down’ for having boundaries
Shame: Public stop and search, handcuffs in front of neighbours	Shame: Public callouts in standups, humiliating code reviews
Abandonment of Service
Supposed to serve public, actually control, belittle and intimidate	Supposed to support teams, actually extract, undermine and pressure
Citizens avoid police rather than seeking help	Developers manage managers rather than being helped by them
‘Protect and serve’ is mythology	‘We remove blockers’ is mythology
Leadership Vacuum
Chief Constables ‘shocked’ by scandals everyone saw coming	CTOs ‘shocked’ by toxic cultures flagged in every exit interview
Good at career advancement, bad at actual leadership	Good at TED talks and earnings calls, bad at building teams and thus products
Commission reports that gather dust	Commission surveys they ignore
Asleep at wheel for responsibilities, awake for their careers	Talk about ‘psychological safety’ while heedlessly maintaining fear cultures
Accountability Vacuum
Complaints process investigates itself, finds no wrongdoing	HR protects company, not employees; toxic managers stay employed
Officers face minimal consequences for misconduct	Managers face no consequences for destroying team morale
System protects its own	Institution may settle; individuals remain untouchable
Selectively Applied Rules
Police delete data, access systems improperly, investigate themselves favourably, breach GDPR	Management ignores estimates, violates work-life balance, exempts itself from processes
Axt as if rules for civilians don’t apply to officers	Rules for developers don’t apply to managers
Ego and Authority
Cannot handle challenges to authority; uniform becomes argument	Cannot handle challenges to decisions; title becomes argument
Question an officer → arrested for obstruction	Question a manager → labelled insubordinate or ‘not a team player’
Professional identity wrapped up in being right	Cannot admit error without existential threat to self-image
Insulation From Consequences
Officer never sees trauma of wrongful arrest	Manager never see the depression/burnout they cause
Victims carry the damage; officer continues career	Developers carry the damage; manager moves to next role
No feedback loop connecting actions to harm	Promoted away before consequences manifest
Institutional Self-Service
Protects reputation over serving public	Maintains management hierarchy over building good software
Scandals prompt PR, not reform	Problems prompt ‘initiatives’ that never materialise
People’s rights seen as obstacles	Developer wellbeing seen as obstacle
Systematic Trampling of Rights
Stop and search, false arrests, violations of liberty, assaults	Privacy violations, dark patterns, algorithmic discrimination
‘Necessary for public safety’ justifies rights violations	‘Necessary for business model’ justifies rights violations
Public has no recourse; police investigate themselves	Users have no recourse; arbitration clauses, no transparency
The Victims Have No Choice
Can’t opt out of policing, can’t fire police	Can’t easily leave job (mortgage, work visa, market conditions)
Power asymmetry enables coercive model	Power asymmetry enables coercive model
Compliance or escalating consequences	Compliance or unemployment

The Expertise Paradox

UK policing has faced persistent criticism over officers who seem remarkably uninformed about the very laws they are charged with enforcing. We’ve seen arrests for ‘non-crime hate incidents’ that chill free speech, wrongful detentions based on misunderstandings of legislation, and officers confidently citing powers they simply don’t possess.

But the knowledge gap runs deeper than just legal ignorance. Police often demonstrate stunning obliviousness to the social dynamics of the situations they wade into. They treat mental health crises as compliance problems. They escalate situations that required de-escalation. They fail to recognise how their mere presence, their tone, their body language transforms a situation. They reduce complex human problems—domestic disputes, neighbourhood conflicts, community tensions—to simple matters of law enforcement, ignoring the interpersonal relationships, power dynamics, and social contexts that actually drive these situations. And blithely ignore that they’re there to serve the public.

Software development displays the same dual failure. Developers ship features without understanding privacy law, accessibility requirements, or basic security principles. But they’re equally ignorant of the social dimensions of what and how they build—how systems affect human behaviour, relationships, and social structures. And how their toxic behavious influence the social dynamic of society at large.

But here’s the thing: they’re often not even competent at the narrow technical domain in which they claim expertise.

Police officers who don’t know the law also frequently don’t know proper enforcement tactics. They can’t de-escalate. They don’t know how to interview witnesses properly. They contaminate crime scenes. They lose evidence. They can’t write coherent reports. They misuse the powers they do have. They rely on intimidation rather than skill. The incompetence isn’t just about the legal framework—it extends to the basic craft of policing itself.

Watch body camera footage of UK police interactions and you’ll see officers who:

• Don’t know when they have the power to search and when they don’t
• Can’t articulate the legal basis for their actions when challenged
• Escalate situations through their own ineptitude and ego
• Make unlawful arrests because they’re ignorant of the threshold for arrest
• Confuse personal offence with criminal offence
• Apply powers they don’t understand and/or don’t have to situations they’ve misread

This isn’t ‘good at tactics but bad at law’ or ‘good at law but bad at social dynamics’. It’s incompetence compounded by incompetence, wrapped in the authority of the uniform.

Software developers display the same layered incompetence:

They write insecure code riddled with vulnerabilities. They hardcode credentials in version control. They build systems that fall over under minimal load. They create race conditions. They ignore error handling. They produce spaghetti code that no one, including themselves, can maintain six months later. They don’t understand the frameworks they use. They cargo-cult solutions from e.g. Stack Overflow without comprehending what the code does. They break production regularly because they never learnt proper testing or deployment practices.

This isn’t ‘good at coding but bad at privacy law’ or ‘good at algorithms but bad at social dynamics’. They’re not good at the core technical skills either. They’ve just learnt enough to be dangerous, enough to be employed, but no where near enough to be regarded as competent.

The ‘expertise paradox’ is that there’s no expertise at all—just hubris, institutional protection, and the complexity of the domain preventing outsiders from easily recognising the incompetence.

In both cases, we see professionals granted significant power whilst being dangerously incompetent in their supposed area of expertise and dangerously ignorant of the broader context in which that alleged expertise must operate. And no one within these systems seems to care.

The Training Vacuum: Learning Nothing and Proud of It

What’s striking about both ‘professions’ is not just the incompetence, but the systematic failure to address it through training and education—and often, the active resistance to learning.

UK Policing’s Training Failures

Police training in the UK is notoriously brief and inadequate. New officers receive initial training that focuses heavily on powers of arrest and use of force, with minimal attention to de-escalation, mental health awareness, or the actual laws they’ll be enforcing. Once on the job, ongoing professional development is sporadic at best.

But worse than the lack of formal training is the cultural resistance to education. Officers who try to learn more about mental health, community relations, or even the finer points of law are often viewed with suspicion by colleagues. ‘Street smarts’ are valued over book learning. Experience (even if it’s years of repeating the same mistakes) is prized over education. The officer who quotes case law or suggests evidence-based practices risks being labelled a ‘college boy’ or not a ‘real cop’.

Promotion is based largely on time served and political navigation, not demonstrated competence or continued learning. There’s no requirement for ongoing education in law, psychology, or social dynamics. An officer can go an entire career without seriously updating their knowledge or skills, just repeating whatever they learnt (or failed to learn) in their initial training.

The result: officers who are confidently incompetent, who’ve internalised bad practices as ‘the way things are done’, and who actively resist new information that might challenge their behaviours and self-image as experienced professionals.

Software Development’s Training Failures

Tech loves to tout its meritocracy and culture of learning, but the reality is quite different. Many developers enter the field through:

• Bootcamps that teach just enough to get hired but not enough to be at all competent
• Computer science degrees that focus on theory whilst ignoring practical software engineering
• Self-teaching that often means copying patterns without understanding them
• On-the-job learning that frequently means absorbing the bad practices of whoever happens to be senior

Once employed, the expectation is that developers will ‘keep up’ with new technologies on their own time. But what does this look like in practice? Skimming blog posts. Watching conference talks at 2x speed. Trying whatever framework is currently trendy without understanding why. The learning is shallow, scattered, and driven more by CV-building than actual competence development. And rarely if ever budgeted, paid for.

Formal training? Most companies provide minimal budget for it, and even when they do, developers often don’t use it because they’re too busy meeting deadlines to take time for learning. Mentorship? The senior developers are too busy (or too incompetent themselves) to mentor effectively. Code review as education? Often devolves into nitpicking or ritual humiliation rather than genuine knowledge transfer. Aside: In fifty years I’ve never met a single senior developer that understood software development in the round.

And like police officers, many developers actively resist deeper learning:

• ‘I don’t need to understand how databases work; I just use an ORM’
• ‘I don’t need to learn security; that’s the security team’s job’
• ‘I don’t need to understand algorithms; I can just Google it’
• ‘I don’t need to read documentation; I’ll just try things until something works’
• ‘I don;t need to understand people, I don’t work with people’

This isn’t framed as ignorance—it’s framed as pragmatism, as ‘shipping’ rather than ‘gold-plating’. The developer who wants to actually understand what they’re doing, who reads academic papers, who studies fundamentals, risks being seen as slow, perfectionistic, or not ‘agile’ enough.

Promotion often has little to do with actual technical competence and everything to do with visibility, political skill, and being friends with the right people. You can be deeply incompetent but still advance if you’re good at talking about your work, taking credit for others’ efforts, and avoiding blame when things go wrong.

The result: swathes of developers who are confidently incompetent, who’ve internalised cargo-culted practices as ‘best practices’, and who actively resist deeper learning that might reveal how much they don’t know.

The Shared Resistance to Growth

Both professions share several toxic attitudes towards learning:

‘Experience is all that matters’: Years in the role are treated as proof of competence, even when those years were spent repeating the same mistakes or stagnating. The experienced incompetent is given more authority than the well-educated newcomer.

‘Real work vs. theory’: Both professions valorise ‘practical’ knowledge over ‘theoretical’ understanding, as if the two were opposed rather than complementary. Police dismiss academic research on effective policing. Developers dismiss computer science and psychology fundamentals. Both claim they’re too busy doing real work to learn how to do it better.

‘If it ain’t broke, don’t fix it’: Except it is broken. Systems are failing, people are being harmed, but because the professional isn’t personally experiencing the consequences, they see no need to improve. The police officer’s methods work fine (for them, sod the public or society at large). The developer’s code works fine (until it doesn’t, but they’ll be at a different company by then).

‘Learning is for juniors’: Once you’ve reached a certain level, both professions treat continued learning as beneath you. You’re supposed to know everything already. Admitting you need to learn something new is admitting you’re not as senior as you claim.

‘Too busy to learn’: Both professions create such dysfunctional, high-pressure environments that there’s never time for learning. Police are too busy responding to calls. Developers are too busy delivering sprints. The system is unintentionally designed to prevent the very learning that might fix the system (POSIWID).

The Institutional Enablement

Both institutions enable, even force, this resistance to learning:

Police forces don’t mandate ongoing education. They don’t assess whether officers actually know the law. They don’t measure competence; they measure activity (arrests, tickets, responses). An incompetent officer who generates numbers is valued over a competent one who doesn’t.

Tech companies don’t mandate ongoing education. They don’t assess whether developers actually understand what they’re doing. They don’t measure quality and needs met; they measure velocity (features shipped, story points completed, commits made). An incompetent developer who ships quickly is valued over a competent one who ships slowly because they’re doing things right.

Both institutions have created cultures where learning is discouraged, ignorance is protected, and incompetence is rewarded as long as it produces the metrics leadership say they care about.

The Compounding Problem

This lack of training and resistance to education compounds every other problem:

• Incompetent officers remain incompetent, becoming senior incompetent officers who role model and train the next generation in their incompetence
• Incompetent developers remain incompetent, becoming senior incompetent developers who set technical direction and review others’ code
• Officers who don’t understand the law continue violating rights, because they never learnt what rights people have, or even the very concept of rights
• Developers who don’t understand security continue shipping vulnerabilities, because they never learnt what secure code looks like
• Police who never learnt de-escalation continue escalating situations
• Developers who never learnt proper system design continue building unmaintainable systems

The expertise paradox isn’t just that there’s no expertise—it’s that both professions have created cultures that actively prevent expertise from developing. They’ve built institutions where ignorance is acceptable, learning is optional, and incompetence can flourish for entire careers as long as it produces compliance and velocity.

You can’t fix incompetence if you won’t acknowledge it exists. And you can’t acknowledge incompetence if your professional identity depends on being the expert. So both professions remain trapped: incompetent practitioners who resist the learning that might make them competent, protected by institutions that value activity over ability and metrics over mastery.

Management Through Violence: Fear, Obligation, Guilt, and Shame

But perhaps the most damning parallel lies in how both institutions actually operate day-to-day. Both policing and software management have abandoned any pretence of service, support, or genuine help. Instead, they’ve embraced management through what can only be called psychological violence: fear, obligation, guilt, and shame.

UK Policing’s Coercive Model

Modern UK policing has largely abandoned community policing, problem-solving, and service. Instead, it operates through intimidation and coercion.

Fear: The implicit (and sometimes explicit) threat of violence underlies every police interaction. Comply or face escalation. Cooperation isn’t requested; compliance is demanded. The message is clear: we have the power to arrest you, detain you, search you, and there’s very little you can do about it. Even when you’ve done nothing wrong, the fear of what police could do shapes the interaction.

Obligation: Police frame their authority as an obligation you owe them. You’re obligated to answer questions. Obligated to provide identification. Obligated to explain yourself. Obligated to submit to searches. The framing is never ‘we’re here to help’, it’s ‘you’re required to comply with us’. Refusal to submit to demands you’re not legally required to comply with is treated as suspicious, obstructive, hostile, or grounds for escalation.

Guilt: Even innocent interactions with police are designed to make you feel you’ve done something wrong. ‘Why are you nervous?’ ‘What are you hiding?’ ‘If you’ve done nothing wrong, why won’t you cooperate?’ The assumption is guilt; you must prove innocence. The interaction itself becomes evidence that you’re probably up to something.

Shame: Stop and search in public. Handcuffs in front of your neighbours. Being questioned loudly where others can hear. The public nature of police actions creates shame by design. It’s a form of social punishment that occurs before any determination of guilt, and continues to affect you even when you’re released without charge.

This isn’t service. This isn’t helping. This is control through coercion, compliance through intimidation. The person being policed isn’t a citizen to be served; they’re a potential threat to be managed, a suspect to be controlled.

Software Management’s Parallel Coercive Model

Look at how most software development teams are actually managed, and you’ll see the exact same dynamics replicated with eerie precision.

Fear: Management by threat is endemic in tech, despite all the talk of ‘psychological safety’ and ‘blameless post-mortems’.

Fear of being fired. Not just the formal ‘performance improvement plan’ (which everyone knows is a documented path to termination), but the constant low-grade anxiety about redundancies, stack-ranking, ‘right-sizing’, or simply being deemed ‘not a culture fit’. Fear permeates daily work.

Fear of speaking up in meetings. Say something wrong and you’ll be judged as not smart enough. Challenge a decision and you’re ‘not a team player’. Ask for clarification and you reveal you don’t understand. So you stay quiet and nod along.

Fear of pushing back on impossible deadlines. Question the estimate and you’re ‘not showing ownership’. Refuse to work weekends and you’re ‘not passionate enough’. Warn that quality will suffer and you’re ‘being negative’. So you say nothing and start working evenings.

Fear of admitting you don’t understand something. The tech industry worships the myth of the 10x developer who intuits everything. Admitting ignorance marks you as lesser. So people spend hours Googling in private rather than asking the senior engineer for ten minutes of their time.

Fear of reporting problems. Found a major security flaw? Better think carefully about whether raising it will make you look bad for not catching it earlier, or make your team look bad for writing it, or make management angry about the delay in shipping. Sometimes it’s safer to say nothing and hope someone else finds it.

Fear of your code being reviewed. Not the constructive fear of healthy peer review, but the dread of ritual humiliation. Will the senior developer use your pull request to demonstrate their superiority? Will your architectural choices be questioned in ways that make you look incompetent? Will this be used against you in performance reviews?

Fear of being ‘managed out’. Once management decides you’re not working out, there’s no real process, no real recourse. They’ll make your life miserable until you quit, or they’ll find a reason to let you go. Even in the UK. And everyone around you will watch it happen and learn the lesson: don’t become a target.

The fear isn’t occasional. It’s ambient. It shapes every decision, every interaction, every email. Just as citizens learn to fear police encounters, developers learn to fear management’s gaze.

Obligation: Just as police frame authority as obligation, tech management frames unreasonable demands as professional duties. The language is careful—they can’t legally compel you—but the social and economic pressure creates the same effect.

You’re obligated to work evenings and weekends when deadlines loom. Deadlines that were set without your input, that were impossible from the start, that ignore your warnings about feasibility. But now they’re deadlines, and failing to meet them reflects poorly on you, not on the manager who set them.

Obligated to be ‘team players‘. Which means accepting dysfunction without complaint. The broken deployment process that wastes hours? Work around it; fixing it isn’t your responsibility. The terrible decisions made by the architect? Implement them anyway; it’s not your place to question. The manager’s pet feature that makes no sense? Build it; they’re the decision-maker.

Obligated to ‘take ownership’. Which means accepting blame for failures whilst credit flows upward to management. The project failed because of fundamental resourcing issues? Doesn’t matter; you owned it, you failed. The system went down because of infrastructure problems you warned about? You should have been more insistent, should have escalated better, should have found a workaround.

Obligated to ‘be passionate’. Which means accepting below-market compensation because ‘you believe in the mission’. Which means volunteering for extra work to ‘show initiative’. Which means pretending that writing CRUD apps for a marketing company is fulfilling your life’s purpose.

Obligated to ‘be culture fits’. Which means conforming to whatever behavioural norms the dominant group has established. The bro culture that makes crude jokes? Laugh along or be excluded. The workaholic culture where presence equals productivity? Stay late even when you’ve finished. The aggressive culture where loudest voice wins? Either get loud or get ignored. The nerfing culture where everyone is busy (literally) nerfing each other all day every day. And bugger the disruption.

Obligated to participate in the charade. Agile ceremonies that accomplish nothing but must be attended. OKRs that everyone knows are fiction but must be written. Performance reviews that bear no relationship to actual work but must be taken seriously. ‘All-hands’ meetings that communicate nothing but attendance is tracked. The obligation isn’t to do productive work; it’s to perform participation in management’s theatrical production.

R.D. Laing’s profound psychological observation perfectly captures the intricate dance of corporate survival:

“They are playing a game. They are playing at not playing a game. If I show them I see they are, I shall break the rules and they will punish me. I must play their game, of not seeing I see the game.”

The framing is never ‘we’re asking for your voluntary extra effort and will compensate and appreciate you accordingly’. It’s ‘this is what’s expected; this is what professionals do; this is what commitment looks like’. The obligation is presumed, not negotiated. And failing to meet these obligations has consequences—subtle, unwritten, but very real.

Guilt: Tech management weaponises guilt with surgical precision.

Missed a deadline? You let the team down. Never mind that the deadline was arbitrary, the requirements kept changing, or you were understaffed. You failed your teammates. They’re working late because of you. They’re stressed because of you. Look at their faces in the standup—that disappointment is your fault.

Need to take holiday? You’re abandoning your teammates during a critical time. Sure, the company offers ‘unlimited holiday’, but taking more than two weeks a year marks you as not sufficiently dedicated. And taking holiday during a sprint? During a launch? During literally any time because there’s always something critical? You’re making everyone else pick up your slack. Don’t you care about the team?

Can’t work weekends? You’re not committed enough. Your teammates are sacrificing their personal time. Are you really okay with being the person who cares less? Who tries less? Who wants it less? What does that say about you?

Pointed out a problem with the project? You’re being negative. You’re not a ‘solutions person’. You’re bringing down morale. Why are you so focused on what’s wrong instead of what’s right? Can’t you see we’re all trying our best here? Your negativity is toxic.

Insisted on doing things properly? You’re slowing everyone down. You’re letting perfect be the enemy of good. You’re not being pragmatic. Your obsession with quality and folks’ needs is blocking the team from shipping. Do you value your principles more than your teammates’ success?

Asked for the resources to do the job right? You’re not being scrappy enough. You’re making excuses. Real engineers make things work with whatever they have. Why can’t you figure it out like everyone else? Are you just not as capable as you claimed to be?

Refused to implement a bad idea? You’re not trusting your manager’s judgement. You’re being insubordinate. You’re letting your ego get in the way. Who are you to question decisions made by people with more experience, more context, more responsibility? Maybe you’re not senior enough for this role after all.

The guilt is constant and multidirectional. Guilty for not working enough. Guilty for complaining about work. Guilty for having boundaries. Guilty for not having more impact. Guilty for being stressed. Guilty for making others stressed. Guilty for not being grateful enough for the opportunity. Guilty for expecting more from the opportunity.

And here’s the mechanism that makes it so effective: the guilt is socially reinforced. It’s not just your manager making you feel guilty—it’s other developers who’ve internalised the same guilt and will judge you for not carrying your share. It’s the colleague who humble-brags about working all weekend. It’s the teammate who sighs heavily when you leave at 5pm. It’s the developer who casually mentions they haven’t taken holiday in two years. They’re not just victims of the system; they’ve become enforcers of it.

Shame: Public humiliation is a standard management tool, dressed up in the language of ‘transparency’ and ‘accountability’.

Being called out in stand-ups for missing estimates. Not privately, where it could be handled constructively, but in front of the entire team. ‘So your task was supposed to be done Tuesday, and here we are on Thursday…?’ The implication hangs in the air. Everyone’s eyes on you. Everyone noting that you failed.

Having your code torn apart in reviews that are less about improving quality and more about establishing dominance hierarchies. The senior developer who doesn’t just point out issues but does so with contempt. ‘I don’t understand how anyone could think this was acceptable.’ ‘Did you even test this?’ ‘This is exactly what I warned about in the architecture review, but apparently no one was listening.’ It’s not feedback; it’s ritual degradation, performed publicly to establish who matters and who doesn’t.

Being made an example of when projects fail. The post-mortem that’s supposedly ‘blameless’ but somehow keeps coming back to your decisions. The retrospective where your mistakes get documented in bullet points on a screen everyone can see. The all-hands where leadership explains what went wrong and everyone in the company knows it was your team, your module, your code.

Being compared unfavourably to other developers. ‘Why is it taking you three days when Sarah did something similar in one?’ ‘The other team already shipped this feature.’ ‘I’m not seeing the same velocity from you that I see from the rest of the squad.’ The comparison is the point. You’re not just failing; you’re failing relative to others, and everyone can see it.

Being excluded from important meetings or decisions as visible punishment. You raised concerns about the architecture? Suddenly you’re not invited to the architecture meetings anymore. You pushed back on a deadline? You’re no longer consulted on scheduling. You questioned the product direction? The product meetings happen without you. The exclusion is public—everyone sees you’re no longer in the room—and the message is clear: dissent has consequences.

Having your mistakes become teaching moments. ‘Let me tell you about something that happened recently…’ followed by a thinly-veiled description of your error, presented to the team, the department, sometimes the company as a cautionary tale. Anonymised just enough to be deniable, specific enough that everyone knows exactly who they’re talking about.

Being stack-ranked. Your performance quantified, compared, ordered. Your value to the company expressed as a number or a position on a list. And often, these rankings aren’t confidential—they’re discussed in calibration sessions with multiple managers, shared with skip-levels, sometimes leaked to the team. You’re not just being judged; you’re being publicly graded like a schoolchild, and everyone gets to see whether you’re honours roll or remedial.

Just as public police interactions create social shame designed to punish before any determination of guilt, public management actions in tech create professional shame designed to control behaviour. The punishment isn’t just the consequence; it’s the public nature of it. It’s the fact that your peers watched it happen. That they’ll remember. That it becomes part of your reputation within the company.

And like police interactions, the shame persists beyond the incident. Long after the standup where you were called out, people remember you as ‘the person who missed that deadline’. Long after the code review humiliation, you’re ‘the person who writes bad code’. The shame becomes identity.

The Abdication of Support

What’s missing from both is any genuine commitment to support, service, or help.

Police are supposed to serve the public. The phrase ‘protect and serve’ (USA) is literally part of the mythology. But in practice, when’s the last time you had an interaction with police that felt like service? When did they help you solve a problem, support you through difficulty, or make you feel safer? For most people, especially those in marginalised communities, police interactions are dangers to be avoided, not resources to be utilised.

Police aren’t there to help you. They’re there to manage you, control you, extract compliance from you. And if you have a problem—if you’ve been victimised, if you need help—their response is often to treat you as the problem. Reporting a crime? They’ll question whether you’re telling the truth. Been assaulted? They’ll ask what you were wearing, whether you’d been drinking. And wave you off. Need help with a mental health crisis? They’ll treat it as a threat scenario. The institution has abandoned the service model entirely in favour of the control model.

Managers in tech are supposed to support their teams. Remove blockers. Provide resources. Shield teams from unreasonable demands. Develop people’s skills. Create environments where good work can happen. This is what management books say. This is what management training teaches. This is what managers claim in their self-evaluations.

But in practice, how many developers feel genuinely supported by their management?

Management doesn’t remove blockers—they are blockers. They create process overhead, demand status updates, insist on meetings, and then wonder why development is slow. When you point out actual blockers—slow CI/CD, poor tooling, inadequate infrastructure—they tell you to work around it. They’ll spend weeks debating whether to approve a £500/month tool that would save the team hours daily, but they won’t hesitate to demand the team work weekends to hit an arbitrary deadline.

Management doesn’t provide resources—they starve teams and demand miracles. Understaffed by design, because ‘doing more with less’ is a management virtue. Don’t have enough people? Just work more efficiently. Don’t have the right skills on the team? Just figure it out. Need training? Here’s an O’Reilly subscription; teach yourself on your own time. Need equipment? Use your personal laptop; we’ll give you a small stipend. Need infrastructure? Make do with what we have; there’s no budget for improvements.

Management doesn’t shield teams from unreasonable demands—they transmit unreasonable demands and then pressure teams to accept them. The CEO wants a feature by end of quarter? Make it happen. Sales promised something that doesn’t exist? Build it. The deadline is impossible? Not with that attitude. The requirements keep changing? Be agile. The scope keeps expanding? Adjust. Management’s job has become playing telephone between executive fantasy and developer reality, and always, always the pressure flows downward.

Management doesn’t develop people’s skills—they exploit the skills people already have. Training budget? Only if it’s directly applicable to the current sprint. Time for learning? Only if you do it outside work hours. Mentorship? That’s the senior developer’s problem, except they’re too busy hitting deadlines to actually mentor. Career development? Here’s a list of competencies you need to demonstrate; figure out how to demonstrate them whilst also shipping features. Management is extraction, not cultivation.

Management doesn’t create environments where good work can happen—they create environments where frantic work happens. The goal isn’t good, it’s fast. The metric isn’t quality, it’s velocity. The pressure isn’t sustainable, it’s constant. They’ve created systems that burn people out and then blamed the people for burning out. ‘We need to talk about your wellbeing’ really means ‘you’re not keeping up the pace, and that’s a you problem’.

Most developers feel like management is something to be managed—people to be kept happy with status updates, to be shielded from bad news, to be navigated carefully. You learn to tell managers what they want to hear, not what’s actually happening. You learn to translate their demands into something actually achievable and let them think they got what they asked for. You learn to work around them, not with them. And then one day you wake up in Russia.

When’s the last time a developer said ‘I’m so glad I can go to my manager for help with this problem?’ More often you hear: ‘Don’t tell my manager about this problem; they’ll just make it worse’. The manager isn’t a resource; they’re a risk.

Both institutions have replaced support with control, service with compliance, help with coercion.

And crucially: both institutions defend this transformation by claiming it’s necessary. Police claim they can’t coddle criminals; they need to maintain authority. Management claims they can’t coddle developers; they need to maintain accountability. Both are really saying the same thing: we can’t do our jobs if we have to actually care about the people we have power over. Better to just intimidate them into compliance.

The Internal Mirror

And here’s where it gets truly dark: both institutions use the exact same coercive model internally, on their own people.

Police officers themselves are managed through fear, obligation, guilt, and shame. Speak up about misconduct? You’re a grass, you’ve broken the blue line, you’ll be ostracised. Question orders? You’re insubordinate. Fail to meet arrest quotas? You’re not pulling your weight. Show weakness? You’re not cop material. The same psychological violence police inflict externally is inflicted internally to maintain the culture. Officers learn to fear their own colleagues and superiors as much as civilians fear officers. Cop is as cop does.

Software developers are managed through fear, obligation, guilt, and shame, and they internalise it to the point where they enforce it on each other. The developer who works weekends makes everyone else feel guilty for having boundaries. The developer who never asks for help makes everyone else feel ashamed for needing help. The developer who accepts every unreasonable deadline makes everyone else look uncommitted by comparison. Management doesn’t even need to apply much pressure—developers do it to themselves and each other.

Both institutions create cultures where the abused become abusers, where the victims of coercion become the enforcers of it. You survive by submitting, and then you justify your submission by demanding others submit too. Otherwise, you’d have to face that you didn’t have to submit—that you had choices, and you chose compliance. Better to make compliance seem like the only option, for everyone.

The Toll

The psychological impact is severe in both cases.

People who’ve been policed through fear, obligation, guilt, and shame don’t feel safer—they feel threatened by the very institution that claims to protect them. They avoid police rather than seeking their help. They teach their children to fear police rather than trust them. Communities become antagonistic to the police, and police respond with even more aggressive control tactics. The spiral continues.

Developers managed through fear, obligation, guilt, and shame don’t produce better work—they produce compliant mediocrity and eventually burn out. They learn to hide problems rather than surface them. They optimise for looking productive rather than being effective. They keep their heads down, collect paycheques, and count the days to either leaving or being made redundant.

The talented ones—the ones with options—leave. They walk into the office one Monday and realise they can’t do this anymore, that their mental health is worth more than the paycheque. They quit, sometimes without another job lined up, because anything is better than this. (Been there, many times, myself).

The ones who stay either burn out or adapt. Burnout looks like depression, anxiety, exhaustion. It looks like going through the motions. It looks like not caring anymore because caring hurts too much. It looks like disengagement, cynicism, the slow death of professional pride.

Adaptation looks like becoming the same kind of coercive manager who abused them. They learn that guilt, fear, obligation, and shame are effective management tools. They’ve been on the receiving end; they know how well it works. When they get promoted, they perpetuate the cycle. The abused become abusers. The spiral continues.

Why This Happens

Both institutions have embraced coercive models because they’re easier than actually being good at the job.

Real policing—community engagement, problem-solving, de-escalation, earning trust—requires skill, patience, and emotional intelligence. It requires treating people as people. It requires admitting you don’t have all the answers. It requires building relationships over time. It’s hard. It’s exhausting. It requires abilities many officers don’t have and training most forces don’t provide.

It’s so much easier to just rely on the implicit threat of state violence. Walk in with authority, demand compliance, and if they don’t comply, escalate. It works, in the sense that you get compliance. People submit. You can tell yourself you’re doing your job. And you never have to develop the harder, more human skills that real policing requires.

Real management—developing people, building trust, creating clarity, removing obstacles, fostering genuine collaboration—requires skill, patience, and emotional intelligence. It requires treating developers as humans with context, constraints, and expertise you might lack. It requires admitting you don’t have all the answers. It requires building relationships, understanding what motivates each person, creating environments where different people can thrive. It’s hard. It’s exhausting. It requires abilities many managers don’t have and training most companies don’t provide.

It’s so much easier to just rely on the implicit threat of employment insecurity. Demand deliverables, set deadlines, and if people can’t meet them, apply pressure through fear, obligation, guilt, and shame. It works, in the sense that you get compliance. People submit. They work nights and weekends. They keep their objections to themselves. You can show your superiors that you’re ‘getting results’. And you never have to develop the harder, more human skills that real management requires.

Both institutions attract people who are drawn to having power over others but lack the competence or inclination to exercise that power responsibly. And both institutions protect those people, allowing them to continue using coercion as a substitute for capability.

The Victims

In both cases, the people subjected to this coercive control have limited recourse.

If police treat you poorly, you can’t fire them. You can’t choose different police. You can’t opt out of the system. You’re subject to their power whether you consent or not. Your only options are compliance or escalating consequences. You can file a complaint, but the police investigate themselves. You can sue, but qualified immunity protects officers. You can try to avoid police entirely, but that’s not really an option for most people. You’re trapped in the power relationship.

If management treats you poorly, you can try to leave, but you need the job. And in tech, despite the mythology of abundant opportunities, the reality is more constrained. You might have a mortgage, family obligations, visa requirements. The job market might be soft. You might be at a senior level where opportunities are scarce. You might be in a specialised field with few employers.

And even if you can leave—what makes you think the next place will be better? Every developer has stories about toxic management. It’s not a bad company; it’s the industry. The next job will likely be the same coercive model with different faces. So you endure. You comply. You internalise the guilt and shame. You live with the fear and obligation. You stay because the alternative is uncertainty and potential poverty.

In both cases, the power asymmetry means the coercive model works—not because it’s effective at achieving stated goals (safer communities, better software, more successful products), but because the victims have no choice but to submit to it.

The ultimate parallel: both institutions claim to serve (the public, the business) whilst actually serving themselves. And they maintain their power not through competence or service, but through the systematic application of fear, obligation, guilt, and shame to those unfortunate enough to fall under their authority.

The Systematic Trampling of Rights

This coercive management culture doesn’t just make developers miserable—it creates the conditions for systematic rights violations against users.

When developers work in environments of fear, when they’re constantly guilted about deadlines, when they’re shamed for pushing back, when their entire employment hinges on compliance—they stop caring about user rights. They can’t afford to.

The developer who knows the feature violates privacy but ships it anyway because questioning it would make them a target. The team that implements dark patterns because management demands ‘conversion optimisation’ and refusing would be ‘not being a team player’. The engineer who sees the security flaw but says nothing because raising it would mean admitting their code has problems. The architect who designs invasive surveillance features because their manager’s promotion depends on hitting engagement metrics.

This is how rights get trampled: not primarily through malice, but through organisations that manage their people so coercively that ethical concerns become luxury goods no one can afford.

Just as police officers subject to coercive internal cultures become more likely to violate civilian rights (because they’ve learnt that might makes right, that questioning orders has consequences, that covering for colleagues is survival), developers subject to coercive management become more likely to build rights-violating products (because they’ve learnt that objecting has consequences, that deadline pressure justifies cutting corners, that going along is survival).

The internal culture of psychological violence produces external consequences of actual harm.

The Leadership Vacuum – A Fish Rots From the Head

If front-line failures reveal the expertise paradox, leadership failures reveal something worse: institutional rot from the top down.

UK policing’s problems don’t stop with constables on the beat. Chief Constables and senior officers preside over forces where misconduct flourishes, yet seem perpetually surprised when scandals emerge. They speak at conferences about ‘lessons learnt’ from the same mistakes that keep recurring. They commission reports that gather dust. They announce reform initiatives that never quite materialise.

These senior officers are masters of looking busy whilst accomplishing nothing. They’re skilled at navigating political pressure, managing their own reputations, and securing the next career move. What they’re not skilled at is actually reforming their organisations or supporting their officers in doing better work.

When Sarah Everard was murdered by a serving Metropolitan Police officer, senior leadership expressed shock—despite years of warnings about the force’s culture. When strip-search scandals emerge, when stop-and-search data shows persistent racial bias, when officers are caught in WhatsApp groups sharing racist and misogynistic content, senior officers act surprised. Every. Single. Time.

They knew. Everyone knew. The culture was visible to anyone who bothered to look. But looking would have required acknowledging the problem, and acknowledging the problem would have required fixing it, and fixing it would have been hard work that might not pay off before their next career move. So they looked away.

The pattern is clear: asleep at the wheel when it comes to their actual responsibilities, wide awake when it comes to their own careers.

Tech Leadership’s Parallel Failure

Tech executives and engineering managers display remarkably similar characteristics. They’re excellent at:

• Delivering quarterly earnings calls that move stock prices
• Pivoting to whatever is trendy (mobile! cloud! AI! crypto! AI again!)
• Acquiring and then destroying smaller competitors
• Giving TED talks about innovation and ‘changing the world’
• Collecting compensation packages that would make Victorian robber barons blush
• Talking about ‘growth mindset’ and ‘psychological safety’ in all-hands whilst running organisations based on fear

What they’re not excellent at:

• Actually supporting the developers who work for them
• Creating sustainable work environments
• Addressing the toxic management culture everyone complains about in exit interviews
• Building organisations where technical excellence matters more than political skills
• Taking responsibility when things go wrong (that’s what VPs are for)
• Protecting their teams from unreasonable demands (they’re usually the source of them)

Engineering VPs and CTOs talk endlessly about ‘building great engineering cultures’ whilst presiding over teams that are demoralised, burnt out, and haemorrhaging senior talent. They commission surveys on developer happiness, get back results showing pervasive problems, and then… do nothing. Or worse, they blame the developers for not being resilient enough, passionate enough, committed enough.

They’ll implement ‘wellness programmes’ and ‘mental health days’ whilst maintaining the exact management practices that destroy mental health in the first place. They’ll talk about ‘work-life balance’ whilst promoting the managers who demand weekend work. They’ll claim to value ‘technical excellence’ whilst rewarding the developers who ship fast and break things. They’ll say they want ‘honest feedback’ whilst retaliating against people who provide it.

When toxic managers are finally too obvious to ignore, leadership acts shocked. ‘We had no idea this was happening.’ Really? In an organisation where people work closely together, where exit interviews consistently mention the same problems, where team surveys flag the same issues quarter after quarter? They knew. They just didn’t care enough to do anything about it.

Like Chief Constables, they’ve mastered the art of looking like leaders whilst failing at actual leadership:

• They give great interviews about engineering excellence whilst presiding over codebases held together with duct tape and prayer
• They talk about diversity and inclusion whilst their hiring and promotion practices perpetuate homogeneity
• They champion ‘blameless post-mortems’ whilst running organisations where blame flows freely and downward
• They praise ‘innovative thinking’ whilst punishing anyone who suggests doing things differently
• They mandate ‘psychological safety’ training whilst maintaining fear-based management cultures
• They implement tools to measure developer productivity whilst ignoring that what they’re measuring is performance under duress, not actual productivity

Both police leadership and tech leadership have perfected a particular kind of wilful blindness: they structure their days, their metrics, and their attention so they can plausibly claim not to have known about problems that were obvious to everyone below them.

They create layers of middle management to insulate themselves from ground truth. They measure what makes them look good rather than what would reveal problems. They attend conferences and talk about best practices whilst their own organisations violate those practices systematically. They commission studies and ignore the findings. They announce initiatives that never materialise into actual change.

And when disasters inevitably occur, both groups deploy the same playbook: express shock, promise to ‘take this seriously’, announce an investigation or review, wait for the news cycle to move on. Real accountability never arrives. Real change never happens. And six months later, a nearly identical scandal emerges.

The fish, as they say, rots from the head.

The Managerial Class That Shouldn’t Exist

Management is a cargo-culted idea

Here’s an uncomfortable truth: most managers in tech shouldn’t be managers. They don’t have the skills for it. They don’t have the temperament for it. They often don’t even want to do it—they just want the title and the pay.

Tech has created a system where the only path to higher compensation and status is through management. You can be a brilliant individual contributor, but there’s a ceiling. To break through, you need to manage people. So developers become managers not because they want to support and develop people, but because they want to advance their careers.

This is like making every police officer who wants a pay rise become a sergeant, regardless of whether they have any skill at leadership, training, or managing others. You’d get exactly what we have: an incompetent management layer that uses coercion to compensate for lack of actual management ability.

The senior developer who was great at coding becomes a manager and suddenly they’re terrible at their job. But they can’t admit it, because admitting it would mean giving up the salary and status. So they fake it. They copy what they’ve seen other managers do. And what have they seen? Fear, obligation, guilt, and shame. It works, in the sense that people comply. So they do more of it.

The industry has created a management class that’s incentivised to extract value from developers whilst providing minimal support, that’s promoted based on their ability to ‘drive results’ (make people work harder) rather than their ability to create environments where good work happens naturally.

And at the executive level? They’re even more divorced from the actual work, even more focused on metrics that have nothing to do with actual software quality or developer wellbeing, even more skilled at protecting their own positions whilst claiming ignorance about obvious problems.

Both institutions have leadership that’s asleep at the wheel—or worse, wide awake and choosing to look away because fixing the problems would threaten their own positions.

The Accountability Vacuum

When UK police officers break the rules, the consequences are often… minimal. The complaints process is labyrinthine. Internal investigations frequently find ‘no case to answer’. Officers who lie, abuse their position, or even commit crimes sometimes receive brief suspensions or early retirement with full pensions. The system protects its own.

Managers in tech operate in a remarkably similar accountability vacuum. Toxic manager destroying team morale? HR will ‘coach’ them whilst the team members who complained start looking for new jobs. Manager creating hostile work environment? Maybe they get moved to a different team to ruin. Manager discrimination in hiring or promotion? Company settles quietly, manager stays employed.

Individual developers face consequences for technical failures—missed deadlines, production bugs, security breaches. But managers face almost no consequences for management failures—toxic cultures, burnt-out teams, discrimination, retaliation.

Both professions have constructed moats around individual accountability. The institution may occasionally face consequences, but the individuals within it remain largely untouchable.

Rules for Thee, Not for Me

Perhaps nothing illustrates institutional rot quite like selectively applied rules.

UK police have been caught deleting data they’re required to retain, accessing systems for personal reasons, and investigating their own misconduct in ways that would never pass muster if applied to civilians. The rules apply to everyone except those who enforce them.

In software development organisations, this manifests everywhere:

• Management demands accurate estimates from developers, then ignores those estimates and commits to different timelines with stakeholders
• Management preaches ‘work-life balance’ whilst expecting developers to work weekends and answer messages at night
• Management talks about ‘psychological safety’ whilst maintaining fear-based cultures
• Management demands ‘accountability’ from developers whilst facing none themselves
• Management institutes ‘no blame’ policies whilst systematically blaming developers for systemic failures
• Management requires developers to follow processes that management itself ignores when convenient
• Management demands detailed documentation from developers whilst providing none about their own decisions
• Executives talk about ‘shared sacrifice’ during lean times whilst protecting their bonuses and share grants

The rules, it seems, are for managing other people (the hoi poloi)

The Ego Problem

UK policing has a well-documented problem with officers who cannot handle challenges to their authority. Question an officer’s legal basis for action, and you might find yourself arrested for ‘obstructing police’ or ‘causing harassment, alarm, or distress’. The uniform becomes the argument.

Management in tech has the same ego problem:

The manager who cannot accept that their technical understanding is outdated. They made technical decisions ten years ago; they must still be the technical expert. Challenge their understanding and you’re ‘not respecting experience’.

The manager who cannot handle being questioned in meetings. They’ve decided on a direction; questioning it is insubordination, not legitimate technical discourse.

The manager who takes any pushback as personal disrespect. You’re not disagreeing with the plan; you’re disrespecting them.

The manager whose ego is so wrapped up in being right that they’d rather see projects fail than admit error. Admitting the architecture they championed is flawed would mean admitting they were wrong, which is existentially threatening.

The manager who confuses authority with correctness. ‘Because I’m the manager’ becomes the argument, just as ‘because I’m the police’ becomes the argument.

In both cases, professional identity becomes so intertwined with being right that being wrong becomes unthinkable. And in both cases, this ego protects the professional from recognising how their actions harm others.

The Insulation From Consequences

Police officers rarely experience the downstream effects of their errors. The person wrongly arrested carries the trauma; the officer faces no consequence and therefore learns nothing. The system provides no feedback loop.

Managers are similarly insulated from their mistakes:

The toxic manager who destroys team morale? They don’t see the depression, the anxiety, the family stress their employees experience. They just see that people aren’t performing well, which confirms that more pressure is needed.

The manager who sets impossible deadlines? They don’t work the weekends. They don’t experience the burnout. They just see the feature shipped (barely, and full of bugs), and conclude that pressure works.

The manager who drives away senior talent? They’re not the ones trying to work with the depleted team. They’ve moved to a different role by the time the consequences manifest.

The manager who creates hostile work environments? They don’t experience the hostility. They’re at the top of the local hierarchy. For them, the environment is fine.

Both professions can rise through the ranks whilst leaving damage in their wake, never forced to confront the human cost of their professional negligence. The rights they’ve trampled remain abstractions; the people whose lives they’ve damaged remain invisible.

The Institutional Capture

Perhaps the deepest parallel is this: both institutions increasingly serve their own interests rather than their stated purpose.

UK policing often seems more concerned with protecting its reputation than protecting the public. Criticism is met with defensive briefings, not reform. Scandals prompt PR campaigns, not cultural change. Rights are seen as obstacles to institutional effectiveness rather than constraints on institutional power.

Software organisations have undergone similar capture. What began as a field dedicated to building useful tools has become increasingly focused on:

• Extracting maximum value from developers’ labour (longer hours, more pressure, less support)
• Maintaining management’s power and status (hierarchy for its own sake)
• Protecting the organisation from accountability (binding arbitration, NDAs, forced rankings that justify redundancies)
• Prioritising management comfort over developer wellbeing or product quality
• Building empires rather than effective teams

The mission statement says one thing; the incentive structure points elsewhere. And in both cases, the people whose rights are being trampled are treated as resources to be extracted from, not humans deserving of dignity and respect.

Management talks about ‘our greatest asset is our people’ whilst treating people as disposable. They talk about ‘innovation’ whilst punishing anyone who suggests doing things differently. They talk about ‘excellence’ whilst rewarding political skills over technical competence. They talk about ‘values’ whilst managing through fear, obligation, guilt, and shame.

The stated purpose is building great software. The actual purpose is maintaining the management hierarchy that extracts value from developers whilst insulating itself from accountability.

What Makes These Parallels Possible?

These aren’t coincidences. They emerge from similar structural conditions:

Complexity as a shield: Both law and code are sufficiently complex that outsiders can’t easily evaluate professional competence. This opacity creates space for incompetence to hide—and for coercive management to go unchallenged.

Professional closure: Both fields have successfully convinced society that only their members can judge their work. Challenge a police officer’s behaviour? You’re not qualified. Question a technical or management decision? You don’t understand the business context.

Weak external accountability: Neither profession faces robust external oversight. Police complaints boards are often staffed by former officers. Corporate management faces minimal external accountability for how they treat employees.

Misaligned incentives: Police are judged on arrests and crime statistics, not on whether justice was served or communities feel safer. Managers are judged on delivered features and met deadlines, not on whether they’ve created sustainable, healthy, effective teams.

Leadership that optimises for self-preservation: Both fields promote people who are good at managing up and protecting the institution, not people who are good at the actual job. Chief Constables and CTOs rise by avoiding scandal, not by fixing problems.

The pretence that social dynamics don’t matter: Both institutions operate as if human behaviour, relationships, and social structures are irrelevant to their work. This makes it impossible to address problems that are fundamentally social in nature—like toxic cultures built on fear, obligation, guilt, and shame.

Power without responsibility: Both institutions wield enormous power over people’s lives—police through the monopoly on legitimate force, management through control of employment and therefore economic survival. But both have successfully avoided commensurate responsibility for how that power is used.

The normalisation of psychological violence: Both have operated long enough that managing through fear, obligation, guilt, and shame has become ‘just how things are done’. People no longer recognise it as violence; they think it’s normal management.

Economic dependence: Just as you can’t opt out of policing, most developers can’t opt out of employment. This captive population allows coercive practices to persist because the victims have nowhere else to go.

A Way Forward?

Acknowledging these parallels isn’t counsel for despair. It’s a call for structural reform in both fields:

Real accountability: Individual professionals must face meaningful consequences for abusing their power. Toxic managers need to face actual consequences, not just ‘coaching’. The protection of incompetent, abusive management needs to end.

External oversight: Both professions need robust oversight from outside their own ranks. Just as police need civilian oversight with real teeth, tech companies need independent channels for reporting management abuse—not HR departments that protect the company.

Realigned incentives: Stop measuring and rewarding the wrong things. Managers should be evaluated on team health, retention of top talent, and sustainable delivery—not just shipped features. Police should be evaluated on community trust and safety, not arrest numbers.

Cultural change: Both fields need to rebuild professional cultures that prize service over self-interest, support over coercion, development over extraction. This means explicitly rejecting management through fear, obligation, guilt, and shame.

Mandatory, ongoing training: Real training in the actual skills needed for the job. For police: law, de-escalation, mental health, social dynamics. For managers: actual management skills, emotional intelligence, team development. Not one-off workshops, but continuous professional development that’s evaluated and required.

Leadership accountability: Senior officers and executives must face consequences when they preside over toxic cultures. Being ‘shocked’ when problems surface should not be a defence—it should be an indictment.

End the promotion trap: Create viable career paths for individual contributors that offer similar compensation and status to management roles. Stop forcing people into management positions they’re not suited for.

Reject the mythology: Stop pretending that fear-based management ‘gets results’. It gets compliance and burnout. Stop pretending that technical skill is all that matters. Stop pretending social dynamics don’t exist. Stop pretending that ‘experience’ equals competence when that experience is just years of repeating the same mistakes.

Acknowledge the social dimension: Both fields must stop pretending that human relationships, power dynamics, and social structures are irrelevant to their work. You cannot build healthy organisations whilst pretending humans aren’t social beings.

Ground truth mechanisms: Create channels that force leadership to confront what’s actually happening, not what they want to believe is happening. Anonymous surveys that actually get read and acted on. Exit interviews that are taken seriously. Skip-levels that are genuinely candid.

Union power: Developers need collective bargaining power to push back against coercive management. Individual developers can be crushed; organised labour can negotiate.

Professionalisation that means something: Both fields need to develop what it actually means to be a professional—not just having a job title, but having genuine expertise backed by continuous education, ethical standards that are enforced, and accountability for failures.

The parallel exists because the problem is structural, not individual. Good people in bad systems still produce bad outcomes.

Until we reckon with the ways both UK policing and software development have become institutions that serve themselves rather than the people they claim to serve, we’ll continue to see the same patterns: incompetence masquerading as expertise, power exercised without constraint, psychological violence normalised as standard practice, leadership that’s asleep at the wheel—or worse, wide awake and choosing to look away—and a systematic trampling of human dignity in service of institutional convenience.

The first step in fixing a system is acknowledging it’s broken. The second step is acknowledging that all systems are, at their core, systems of human relationships. The third step is acknowledging that management through fear, obligation, guilt, and shame is violence, and it needs to stop. The fourth step is acknowledging that neither profession has the expertise it claims, and that without serious, ongoing training and education, that won’t change.

In both cases, we’re long overdue for that honesty.

And one idea I propose: Make it a criminal offense to misrepresent one’s authority or statutory powers to e.g. the general public.

---

Further Reading

Ashworth, A., & Zedner, L. (2014). Preventive justice. Oxford University Press.

Bradford, B., Milani, J., & Jackson, J. (2017). Identity, legitimacy and ‘making sense’ of police use of force. Policing: An International Journal, 40(3), 614–627. https://doi.org/10.1108/PIJPSM-06-2016-0085

Burnham, D. (1996). The rise of the computer state. Random House.

Eubanks, V. (2018). Automating inequality: How high-tech tools profile, police, and punish the poor. St. Martin’s Press.

Gilliom, J., & Monahan, T. (2013). SuperVision: An introduction to the surveillance society. University of Chicago Press.

Her Majesty’s Inspectorate of Constabulary and Fire & Rescue Services. (2022). An inspection of vetting, misconduct, and misogyny in the police service. HMICFRS.

Home Office. (2023). Police workforce, England and Wales: 31 March 2023. Home Office.

Independent Office for Police Conduct. (2022). Annual report and statement of accounts 2021-22. IOPC.

Loader, I., & Sparks, R. (2011). Public criminology? Routledge.

Lyon, D. (2018). The culture of surveillance: Watching as a way of life. Polity Press.

Maslach, C., & Leiter, M. P. (2016). Understanding the burnout experience: Recent research and its implications for psychiatry. World Psychiatry, 15(2), 103–111. https://doi.org/10.1002/wps.20311

Newburn, T. (2015). Literature review: Police integrity and corruption. Her Majesty’s Inspectorate of Constabulary.

Noble, S. U. (2018). Algorithms of oppression: How search engines reinforce racism. New York University Press.

O’Neil, C. (2016). Weapons of math destruction: How big data increases inequality and threatens democracy. Crown.

Reiner, R. (2010). The politics of the police (4th ed.). Oxford University Press.

Schein, E. H. (2010). Organizational culture and leadership (4th ed.). Jossey-Bass.

Schradie, J. (2019). The revolution that wasn’t: How digital activism favors conservatives. Harvard University Press.

Waddington, P. A. J. (1999). Police (canteen) sub-culture: An appreciation. British Journal of Criminology, 39(2), 287–309. https://doi.org/10.1093/bjc/39.2.287

Zuboff, S. (2019). The age of surveillance capitalism: The fight for a human future at the new frontier of power. Profile Books.