Two people hold the same driving licence. One crammed the theory and drove for a few hours until the examiner was satisfied. The other has spent years on deliberate practice: working on their driving on purpose, reviewing near misses, and asking someone better to ride along. Nothing on the licence tells you which is which, and you would like to know before you get in the car.
For driving, a licence is the right instrument. A mistake is costly, strangers pay for it, and the test at least samples the real thing. Most professional work has none of those properties, yet building a team puts the same choice in front of you with far less to go on: people who studied to pass the test, or people who learned to deploy the skill. These activities compete for the same hours: a week of evenings spent preparing for the exam is a week not spent building and shipping something, and the paper only certifies the first. I favour the second group every time.
Agile, up close
Agile began in February 2001, when seventeen practitioners met at a ski lodge in Utah and wrote: We are uncovering better ways of developing software by doing it and helping others do it. A certification industry followed within a year or two. What exam preparation teaches is a framework’s vocabulary. Running a team needs judgement and the freedom to adapt within broad principles, and nobody studies for that in a weekend. Ron Jeffries, a signatory of the Manifesto, wrote in 2018 that Agile had become big business, and that applied poorly it brings more interference with developers, less time to do the work, higher pressure, and demands to “go faster”. The certification industry almost killed the Agile movement. It still might.
I have seen the result up close: ceremonies without thought, waste at every level. SAFe is the extreme case: Agile and SAFe are opposites, because SAFe dresses waterfall in Agile vocabulary and treats professionals as identical interchangeable cogs in a mindless machine. Investors and others unfamiliar with the field have long demanded to see frameworks, certifications, and badges in place, because they lack the craft, have to choose winners anyway, and mistake the badge for the ability.
I hold no Scrum or SAFe qualifications, on purpose, and I have never used them to decide who to work with. I have removed Scrum from teams I lead, dropped required ceremonies, and retired the Scrum Master role: turning it first into an agile coach, then removing it. I have done this more than once. The cost of not doing this shows from outside: zombie products that survive for years and literally sap the life of everyone who uses them. Most traditional banks’ online banking is the example I reach for, because the environments that produce such mediocre products are designed by consultants and certification providers to stifle creativity and performance.
English language, my own field
I work in language learning, where the pattern is plain. The company I work for, Wall Street English, sells the capability to effectively use English at work. Some providers in the field prefer to specialise in qualifications, because employers ask for them: when the people hiring cannot judge the skill themselves, paper is the only thing they can read, so a market grows to sell it. The difference shows up in one place: a meeting held in English.
The apprenticeship
The best model I know for learning to deploy a skill is the old craft apprenticeship. It had a goal, to become a master; a teacher who already had the skill; tasks of rising difficulty on real work; daily practice for years; and feedback from someone who could see the result. Even the qualification was real work. After several years with a master and a qualifying piece of work, the apprentice became a journeyman; to become a master he produced a masterpiece for the guild’s masters to approve. That is a sample of the work, judged by people who could do it, the opposite of a test about the work.
Guilds also gatekept. Sheilagh Ogilvie describes institutions that excluded competitors, manipulated markets, and blocked innovation, with exploited apprentices among their subjects. Let’s bring none of that back: what is worth keeping is the learning design.
Practice with a goal
AI sharpens the choice because no one can certify what is still being invented. David Pereira sees the Agile pattern starting to repeat around it. I do not think AI has had its Agile moment yet, and it may never do. The people who get good at it will be the ones practising deliberately. Ericsson, who developed the idea, separated deliberate practice from mere experience, and the word that matters is deliberate: a chosen goal, a plan for reaching it, work done every day, and a way of seeing whether it is working. Most of us have far more experience than practice.
Mine looks like this. I had not written code for decades and I am writing it now, on purpose, and doing it well: shift left, CI/CD, the full lifecycle, everything through the agent, resisting the pull back to the old way. I apply AI to planning, strategy, and reporting, and to my personal life too: trip planning, weekend ideas, a CRM that keeps me in touch with friends. I read a lot, try a lot, and work in the open with communities of people doing the same, because their feedback shortens the loop.
Evidence you can ask for
When you put a team together, look for evidence that someone learned to deploy the skill. Six things tell you most of it:
- A goal they chose, and can state in a sentence.
- A method they can describe, beyond a list of tools.
- Something they do every day, however small.
- Work they can show, ideally in the open.
- Feedback they sought, and what they changed because of it.
- Mistakes they can explain, and what they would do differently.
Look at work they have already done, and spend the conversation on what they built last month and what broke. For AI work, ask what they have shipped with it and what they stopped doing because of it. That is not the same as watching someone work in front of you or setting a live coding test, which is often useless. Look at side projects, open-source contributions, and anything you can see, touch, and use, and read the commit history over time.
What someone chooses to spend their hours on tells you more than the paper. Some people spend them getting better, others being seen to be good. Anyone can choose the first; the hours are the same either way.
Your own people
Send the people already on your team on a course and you buy hours spent studying to the test. Give them real work to deploy on, a teacher who has the skill, and feedback, and you have rebuilt the apprenticeship.
Who do you want in the room when the process fails: the person who passed the test, or the one who has been doing the work?
Leave a Reply