The transformation - how the small team has been ready for this 🤸

We were wrong about which jobs AI would affect the most. And about which ones would rise up and be more needed than ever.

The usual prediction was that developers would be among the safest people in the technology herd. They understood the machinery. They could write code. They could explain APIs around the coffee table and were confidently sure that they were indispensable.

AI has changed that and not in the ways we were expecting.

Developers are still important but they are also, increasingly, the slowest gazelle in the herd - I'm sure you know that old saying about how you don't have to be the fastest gazelle to escape the lions, you only have to not be the slowest ...

That is not an insult to devs (and I will always be a programmer at heart). It is a description of the new operating environment we find ourselves in. AI can now produce code, tests, documentation, configuration and technical explanations at a speed that is uncomfortable for anyone who has spent years being the fastest person in the room.

The question is no longer whether AI can produce software. It is whether the software is correct, safe, maintainable, affordable, useful and actually what anyone asked for. Not to mention the completely different way we now look at the cost of software development processes.

That is where the supposedly replaceable roles become more important. The question is now about quality control and compliance.

Smaller teams have been ready for this for years 

This is especially true in small businesses, charities, non-profits and community organisations.

These teams have been designing new initiatives, running transformation projects and making late-night updates to get useful things in front of their staff, customers, donors and communities for a long, long time.

They often never had the budget for a development team. Sometimes they couldn't afford a proper developer at all. They had to make do with a local IT person, a generalist contractor or the technically inclined person from the next village who knew enough to be dangerous, but not so much that the invoice became frightening.

And yet, somehow, they got things done.

They learned how to explain what they needed. They learned how to keep a cheap IT solution focused on the actual work. They learned how to review what came back, identify the bits that were unusable and ask for the important parts to be fixed.

They had to be practical because there was no money for grand technical theatre or for constant rework and bug-fixing.

They had to keep people in control because nobody else was going to do it for them.

AI does not remove that way of working. It actually makes it faster.

The AI takes the bullet-point list of requirements and produces the first drafts in minutes. The small team can review it sooner, identify what is wrong and rework it before anyone has spent three weeks in a sprint.

These smaller organisations were made for this.

They already know that getting something produced is only the beginning. They know the first version will need checking. That it will have security issues they didn't have time to work into the requirements. They know constraints matter and that getting working code out is more important than ticking a governance check-box. They know that the person who understands the real impact of a new feature is often more important than the person who understands the tool that was used to build it.

QA is no longer the final inspection 

• Does this actually work?
• What happens if the user does something unexpected?
• Is this what the requirements actually said?
• Can we prove that it works?
• Is this secure? And can you prove it?
• Are there any privacy concerns here?
• Where is the data being stored and how are we controlling access to it?
• Who's doing the pen test?

Those questions have always mattered. AI makes them unavoidable.

An AI system can generate a large amount of output very quickly. It can also generate plausible rubbish at impressive speed. It can produce something that looks complete while quietly missing the important constraint, mishandling an edge case or making a confident mess of a sensitive workflow.

QA provides the governance and oversight that stops output from being mistaken for quality.

In a small organisation, this may not be a formal QA department. It might be the programme manager, operations lead, administrator or person who knows exactly how the service is supposed to work in real life.

The title matters less than the discipline.

• What did the system generate?
• What did it assume?
• What did it fail to consider?
• Can somebody else reproduce the result?
• Has the output been checked against the actual policy, requirement or promise made to the community?

The quality role is not disappearing. It is becoming the place where organisations decide whether fast output deserves to be trusted.

Platform teams have more work, not less 💪

AI increases the amount of software and technical material that can be produced. It increases the rate of change and that means the rate at which problems are created, too. It does not remove the need to run, secure, monitor, update and govern that material - it only makes it more important.

In larger organisations, platform teams are busier than ever. There are more tools to manage, more integrations to review, more model changes to monitor and more workflows being created by people who previously would not have been able to build them.

Small organisations face the same problem with fewer people and less room for mistakes.

There are new permissions, new data flows, new usage limits and new costs. Someone still needs to know which tools are approved, where information is going, who owns the workflow and what happens when a service changes its terms.

AI can accelerate development. It can also accelerate platform sprawl.

Someone still has to keep the lights on.

Business analysts are translating for a new kind of worker 

A business analyst has always helped translate between what people need and what systems can do. 

That job becomes even more valuable when one of the people doing the implementation is an AI system.

AI is very good at following clear instructions. It is much less good at resolving vague human expectations that were never written down because everybody supposedly knew what they meant.

The BA helps turn:

“Make this easier for the team”

into something more useful:

• What does easier mean?

• Which team?

• Which part of the process?

• What must remain human?

• What data can be used?

• What must never be changed?

• What counts as success?

• What happens when the answer is uncertain?

• Who approves the result?

Small teams often carry this knowledge in their heads because they have never had the budget to document everything properly. AI makes it worthwhile to get that knowledge out into the open.

Good requirements give AI something it can action. Good constraints stop it from wandering into places where it should not be.

An AI that understands the desired outcome but not the boundaries is not helpful. It is an enthusiastic intern with access to production.

And the AI also comes with some unexpected benefit for the BA team. They do not need to convince the AI that new change is valid or to help them understand why - the AI will gladly accept all requests and work within the constraints we've learned to provide it. 

This is a touch-paper for the BA team in a well integrated AI development process 🔥

Project managers are managing change at machine speed

Project managers are also taking on more responsibility, not less.

AI creates a strange mixture of acceleration and instability. Teams can move faster, but the target can move too. A workflow that looked sensible last month may need to change because a model, tool, cost, policy or business assumption has changed.

Project managers are helping teams decide:

• what should be built;

• what should not be built;

• what needs human approval;

• which dependencies matter;

• how changes will be tested;

• who owns the result;

• what evidence is needed before release;

• when to stop adding clever features.

This is familiar territory for small organisations. They have always had to balance ambition against available time, money and people.

AI gives them more capability, but it does not give them more hours in the day or more tolerance for confusion.

The project manager is often the person who notices that the project is producing a lot of activity but not necessarily a lot of value.

AI is very good at generating momentum. It is not responsible for deciding whether everyone is running in the right direction.

Developers are still essential

The point is not that developers are finished and I honestly believe that good developers are more important than ever.

The point is that developers are no longer the only people who can produce technical output. They are also no longer guaranteed to be the fastest people doing it.

The developer who only hand-codes will find that AI can now do much of that work faster. 

The developer who understands systems, security, architecture, trade-offs and operational consequences becomes more valuable.

The best developers will work with AI as a force multiplier. They will also accept that their code needs to be challenged, tested and constrained by other disciplines. As they always did! 

Bad developers will be pushing out vibe-coded nonsense that will break if someone even farts near the wifi router.

None of this is new.

QA has always stopped developers from breaking production.

Business analysts have always stopped them from building the wrong thing.

Project managers have always stopped them from disappearing into a technically fascinating side quest that nobody funded.

Platform teams have always stopped them from treating production like a personal sandbox.

Now those same roles are doing the same work for AI-generated output.

The only difference is that the output arrives faster.

The work has been redistributed

AI has not simply removed work from technology teams.

It has redistributed responsibility.

The people who define quality, requirements, constraints, governance, platform safety and delivery discipline are now more important because AI increases the amount of output that needs to be managed.

Small teams, charities and non-profits may have less money than large organisations, but they often have exactly the habits this new environment demands.

They know how to work with imperfect tools.

They know how to review before trusting.

They know how to make practical progress without confusing technical complexity for value.

They know what it's like to trust your new project to someone who works with things you have no understanding of, trusting that they'll come back with what you need.

AI gives them a faster first draft, a quicker route to rework and a chance to turn hard-won practical knowledge into repeatable systems.

The in-demand skill is no longer just producing something.

It is knowing whether something should exist, whether it meets the requirement, whether it is safe to use and whether the organisation can live with it six months from now.