I did not set out to become someone who builds software. I set out to work in schools. Extensive experience in secondary schools — in classrooms, in pastoral roles, in improvement work — kept surfacing the same gap: the tools schools needed did not exist, and waiting for someone else to build them did not work. The building came later, when it became clear that the observation and improvement problems visible in practice were not going to be solved by another generic proforma.
There is a quiet assumption that runs through education technology — that the people who understand software should build the tools and the people who understand schools should use them. This division seems reasonable until you look at what it produces. It produces observation tools designed by developers who have never observed a lesson. It produces data dashboards designed by analysts who have never sat in a pupil support meeting trying to make sense of why a young person's attendance has dropped sharply in the space of a term. It produces feedback forms designed by UX researchers who have never had to give a colleague developmental feedback about their questioning while maintaining a professional relationship that has to survive the conversation.
The people building the tools do not understand the problem. And the people who understand the problem are not building the tools. That gap — between domain expertise and technical capability — is where most edtech fails, and it is the gap that I think needs closing.
The problem with building from the outside
Years in schools mean using a lot of education software. Tracking systems. Behaviour management platforms. Observation proformas in Word documents and Google Forms and bespoke school apps that someone's nephew built over a summer. Data dashboards that could tell you a pupil's standardised score to two decimal places but could not tell you that the same pupil had become withdrawn over the term. They built what they were asked to build, and in most cases they built it competently. The problem was not the engineering. The problem was the specification.
When a developer who has never taught builds an observation tool, they build what makes sense to a developer: a form with fields. Subject. Teacher. Date. Rating. Comments. Maybe a few checkboxes. Save. Export. The form captures the fact that an observation happened. It does not capture what the observer saw, because the developer does not know what observers see. They do not know that the difference between open and closed questioning matters. They do not know that wait time of three seconds versus one second changes the entire dynamic of a classroom exchange. They do not know that "feedback" as a checkbox conceals a universe of variation — from the task-specific, process-focused feedback that Hattie and Timperley's research says changes learning, to the "well done, brilliant" that has zero measurable impact but accounts for nearly half of all feedback observed in most schools.
The developer does not know this because they have never stood in a classroom and watched it happen. They have never sat at the back of a room and noticed that the teacher asks six closed questions to the same three pupils in the first ten minutes, then asks one genuinely open question to nobody in particular in the last five. They have never circulated during independent work and noticed that the pupils at the front are thinking and the pupils at the back are copying from the textbook without understanding a word of it. They have never had to decide, in the moment, whether what they are seeing is effective differentiation or the absence of it — and then tried to record that distinction on a proforma that has a single box marked "Differentiation."
The specification was wrong because the person writing it did not have the domain knowledge to know what mattered. And the developer, reasonably, built what they were told to build.
What domain expertise gives you
When I started building Learning Lens, I did not begin with the technology. I began with the taxonomy.
Fifty-nine teaching practices, across eleven categories, each grounded in a specific body of research — Rosenshine's Principles, Hattie's effect sizes, Black and Wiliam's formative assessment, Alexander's dialogic teaching, the EEF's guidance on metacognition, feedback, and literacy. Every practice in that taxonomy is there because I have seen it in a classroom — or, more pointedly, because I have noticed its absence. Every qualifier that sits beneath each practice — the descriptive sub-tags that distinguish between genuine inquiry and closed recall, between cold calling and hands-up only, between productive struggle and unproductive frustration — exists because I have watched enough lessons to know that the distinction matters and that losing it in a generic checkbox renders the observation data meaningless.
A developer could not have written that taxonomy. Not because developers are incapable of research — many are more technically rigorous than most teachers — but because the taxonomy is not a product of research alone. It is a product of research interpreted through the experience of having sat in hundreds of classrooms and having seen what those research constructs look like when they are being enacted by a real teacher, in a real school, with real children, under real pressure. The research tells you that wait time of three or more seconds improves the quality of pupil responses. The classroom experience tells you that most teachers wait less than a second, that the ones who do wait often signal it verbally ("take a moment to think"), and that the ones who do not wait often answer their own question before anyone else can. Those are the qualifiers. They came from the research and the classroom together. Neither source alone would have produced them.
This is what domain expertise gives you. Not just knowledge of the subject matter, but knowledge of the context in which the subject matter operates. Schools are not generic organisations. Classrooms are not generic spaces. Teaching is not a generic activity that can be captured in a generic form. The specificity of the tool has to match the specificity of the work, and the only people who understand the specificity of the work are the people who do it.
The accidental technologist
The mythology around teacher-directors and practitioner-entrepreneurs can be misleading. I did not have a moment of revelation in the shower. I did not quit my job to pursue a startup dream. I did not learn to code in a bootcamp and emerge, twelve weeks later, ready to disrupt education. What happened was slower, messier, and more accidental than any of those narratives suggest.
I had a problem. The observation tools I was using produced impressions rather than evidence. The data systems I had access to could not connect what happened in a classroom to what happened in a pupil's attainment, attendance, or wellbeing. The improvement plans I was contributing to cited observation evidence that was, if I am honest, not really evidence at all — it was a collection of paragraphs, written by different people, using different frameworks, describing different things, none of which could be aggregated into anything resembling a pattern.
I started trying to fix this with spreadsheets. Then with more sophisticated spreadsheets. Then with spreadsheets that were so complex they had become, without my quite realising it, a kind of primitive application. At some point — and I cannot pinpoint exactly when — the spreadsheet became code, and the code became a prototype, and the prototype became something that other people could use. The transition was not a career change. It was a gradual accumulation of capability driven by a persistent inability to find a tool that did what I needed.
I think this is the right way for practitioners to build things. Not by becoming developers first and then looking for a problem to solve, but by having a problem that is deep enough and persistent enough that the only way to solve it is to learn how to build. The problem drives the learning, not the other way around. And the product that emerges from that process carries the domain knowledge in its architecture — not as a feature bolted on after the fact, but as the foundation that everything else is built upon.
What teachers know that developers do not
There are things I know from being a teacher that have shaped every design decision in Learning Lens, and that no amount of user research or stakeholder interviews would have surfaced. These are not insights. They are instincts — the kind of tacit knowledge that Eraut (2000) describes as embedded in professional practice but rarely articulated.
I know that an observer in a classroom does not want to look at a screen. They want to watch the lesson. The tool has to be something you glance at, tap, and look away from — an instrument you operate by feel rather than a form you fill in by reading. This shaped the entire capture interface — designed to be operated by feel rather than read by eye. The interaction model is closer to a musical instrument or a sports analyst's coding panel than it is to a web form. A developer would have built a form. I built a mixing desk.
I know that the feedback conversation after an observation is the moment that matters, and that the observation tool must serve that conversation rather than replace it. Learning Lens does not tell the teacher what to do. It tells the observer what they saw, described in specific, research-grounded terms, and leaves the conversation to the humans. A developer might have been tempted to build an AI feedback generator. I know from experience that a teacher who receives computer-generated feedback about their practice will reject it on principle, regardless of how accurate it is — because teaching is personal, and feedback about teaching must come from a person.
I know that school leaders do not need more data. They need better data. They need data that connects — observation evidence that can be read alongside attainment patterns, attendance trends, and pastoral concerns held in the school's existing systems — so that the improvement plan can be built from a coherent picture rather than from fragments. This shaped the product architecture: Learning Lens is the classroom observation evidence layer. It does not replace the MIS or pastoral databases; it gives leaders structured practice evidence that those other conversations can use.
I know that teachers fear observation because observation has historically been done to them rather than for them. The design of the tool — the emphasis on descriptive evidence rather than grades, the qualifier sub-tags that capture specificity rather than judgement, the analytics that show department-level patterns rather than individual teacher rankings — is a deliberate attempt to build a system that treats teachers as professionals whose practice is worth understanding in detail, not as employees whose performance needs rating.
None of this came from a product roadmap or a design sprint. It came from years of being the person in the classroom, and then the person at the back of the classroom, and then the person trying to make sense of what happened in the classroom in a way that would help the school get better.
The case for practitioners building
I am not suggesting that every teacher should learn to code, or that domain expertise alone is sufficient to build good software. It is not. The technical challenges of building a secure, performant, accessible web application are real, and dismissing them would be as foolish as dismissing the domain knowledge that informs the design. What I am suggesting is that the balance is wrong. The education technology market is dominated by products built from the outside — by companies that hire teachers as consultants rather than as architects, that conduct user research rather than building from lived experience, and that treat the classroom as a market rather than as a place where something profoundly important and profoundly complex happens every day.
The consequence is a market full of tools that are technically competent and pedagogically shallow. Tools that capture data without understanding what the data means. Tools that produce reports without understanding who reads them or what they need. Tools that treat teaching as a process to be optimised rather than a practice to be understood. The technical quality is often high. The educational quality is often not.
The correction is not to replace developers with teachers. It is to put teachers in the position of designing the thing — of defining what the tool captures, how it captures it, what the data means, and how it connects to the work that schools do. The technical implementation can be shared, learned, supported, delegated. The domain knowledge cannot. It is the product of years of practice, and it is the thing that separates a tool that works from a tool that matters.
I built Learning Lens because I had a problem and because, eventually, I learned enough to build the solution. But the thing that makes the product what it is — the qualifier taxonomy grounded in Rosenshine and Hattie and Wiliam, the observation lenses aligned to school improvement priorities, the evidence trail that connects what happens in a classroom to the material a Standards and Quality report has to stand on — that is not code. That is teaching, compressed into a data model and an interface.
If I could go back to the student teacher at Moray House who was told his questioning could be stronger, I would not hand him a piece of software. I would hand him the research that explains what strong questioning looks like, the observation framework that helps him see it in others' practice, and the professional learning pathway that helps him develop it in his own. All of which, it turned out, needed to be built. So I built it.
I think more teachers should.
Jamie Scobie writes from extensive experience in Scottish secondary education, including pastoral care, data for improvement, and school self-evaluation. This blog is an independent publication: he writes in a personal capacity as the creator of Learning Lens, writing about classroom observation, teaching evidence, and education policy. He speaks here only for himself and for Learning Lens, not for any employer or other organisation. He holds an MSt from Cambridge (Distinction) and a Masters from Stirling.