Introduction
ALPACA Assessment started as an edtech spin-out from Trinity College Dublin. Its mission is to find dyslexia as early as possible, to give children the best chance of overcoming it and having the best education possible. It does this with a game-based literacy screener that children aged four to six play on iPads, which gives teachers evidence-based data to act on before a child has formally learned to read. ALPACA now screens around 60,000 primary-school children a year.
The work mattered to me personally. I had signs of dyslexia when I was very young, and my mum helped me overcome them by spending an inordinate amount of time with me. I know countless people who live with dyslexia, and the sooner it's identified, the sooner it can be supported. The earlier, the better. I've also worked as a rugby coach and a science teacher, and I've seen first-hand how learning difficulties can hold kids back. So when an opportunity to help appeared, I had to try.
The plan
My approved proposal was "Enhancing Early Literacy Screening Through AI-Driven Product Development and School Partnerships". The problem behind it is stark: around 85% of children aged four to six, in Ireland and internationally, are never assessed for early literacy difficulties. The goal was to democratise access to evidence-based screening in disadvantaged schools, in line with UN SDG 4 (Quality Education) and SDG 10 (Reduced Inequalities). I wrote three objectives with my named supervisor, Agata:
- Agile product leadership and cross-functional coordination: facilitate six weekly sprint stand-ups, keep a central dashboard and knowledge base, and share weekly progress reports.
- Community-centred onboarding and feedback: onboard schools, run three feedback sessions and interview at least ten educators, so teachers' voices shape the product.
- Systems-level impact assessment: interview two or three external experts and map our findings to SDG 4, ending with a scaling roadmap.
Going in, I expected a fairly structured placement. I'd have Agata as my supervisor, clear objectives, and my time split between product work and getting out to DEIS schools to talk to teachers in person. I'd even been granted a travel exception to visit schools around Ireland instead of going abroad. I pictured a lot of that summer being spent in classrooms, learning from teachers and bringing it back to the team.
What changed, and how I responded
A week before I started on 4 August, ALPACA had ten people. By the time I finished, it had five. Agata had left before my first day, so nobody at ALPACA owned the objectives I'd been approved on. Cathal, the engineer who knew the system best, was preparing to leave too. As people left, they took their systems with them. It also meant that, only a few weeks in, I was coaching, supervising, and some days leading the team.
The first week was weird. It was quite self-directed, probably out of necessity, and I had to find answers to my own questions by sifting through all the knowledge, software and tools ALPACA had on hand. I was nervous, because it felt like a lot of responsibility for someone just starting.
I like taking ownership, and it's something Laidlaw has always pushed: going above and beyond. With nobody owning my objectives, I looked for the problems that mattered most to the team and that I could actually fix. The handbook says "We don't expect or believe in perfection", and that what you gain most from is "being authentic, making a genuine effort to learn". That took the pressure off. I didn't need a perfect plan, I just needed to start somewhere useful.
Then my work changed halfway through. I was originally there to build a support tool that I'd use for the second half of the placement. At the start of week three, I was pulled onto ALPACA's main production to fix how classes moved into the new school year. The school visits I'd planned never got scheduled as production took over. But that didn't mean I was going to stop trying to help the teachers any way I could.
Instead, I supported them through our inbox. If a teacher hit a problem, I'd raise a ticket and direct the engineers on how to solve it, or go in and fix it myself if it was a quick coding fix. Sometimes the quickest way to help was to get on the phone and hold their hand through the steps. I spoke to about half a dozen teachers that way. One call stays with me. The teacher was literally in the middle of screening her whole class, and she was so stressed because she couldn't figure out how to use the tool. I stayed on the call and guided her through every step, and I could hear all the kids going mental in the background. It showed me how big the gap is between someone technical, like me, and the average person, and how important it is that tools like ALPACA are accessible and intuitive. With the workload, I extended my LiA and carried it on alongside college.
What I delivered
When I was given the reins to the customer support inbox, there was no system behind it. Problems were arriving by text, email and phone, and in HubSpot, tickets weren't being opened or closed, so tracking genuine issues was almost impossible. I saw it as the chance to own something end to end. I pulled every channel into one inbox so nothing could get lost, and then I built the system around it:
- An AI ticket triage tool. It takes HubSpot tickets and their assignees as input, triages the problem, assigns the right urgency level and suggests a possible solution. Before, an engineer had to sift through the codebase to figure out an issue. Now they can come in and tackle each problem one at a time, in priority order, and they fix tickets around 50% quicker, measured from ticket opened to ticket closed in HubSpot, before and after the tool.
- A working support inbox. Every teacher query now becomes a ticket that's tracked until it's resolved.
- Ticket procedures. There was no documentation and no release process. Now there's a written procedure for how a ticket is raised, triaged and handed to engineering.
- Slack for discussion, Jira for conclusions. I proposed one Slack thread per Jira issue. Duncan refined it, and the team landed on Slack for discussion, Jira for conclusions. Having my idea changed felt great, and it works for everyone.
I also ended up running customer support through back-to-school, the busiest week of the year. Wrong screeners were assigned, paid schools were seeing trial screens, and we had four or five API and database failures, all while classes were waiting to be screened. I was in an unusual position: the newest member of the team, but because I was bridging the commercial and technical sides, I was essentially leading the engineering team as a product owner, helping them prioritise which issues to solve.
Against the plan, I got closest to the first objective. It didn't look like the sprint stand-ups I'd planned, but the heart of it, coordinating a cross-functional team and keeping a shared knowledge base, is exactly what I did. The second objective, interviewing ten educators, became half a dozen phone calls and an inbox. That metric fell short, but the intent behind it survived: teachers' problems shaped what got fixed. I got furthest from the third. Production support displaced the expert interviews and the SDG mapping entirely.
Impact and what lasts
The community in need was teachers, and through them the children they teach. Each child is screened seven times, and at least two points are needed to measure growth. Senior infants get only three, so sometimes this is a child's only chance of early diagnosis. When the technology fails in front of a class, a child can miss that chance. Most of the teachers I spoke to weren't technical, and many were in DEIS schools with patchy iPads and wifi. I learned to stop explaining the system and start asking what their morning looked like.
My impact is mostly behind the scenes. Helping ALPACA stay efficient and get the best out of its people means it can focus on building a more intuitive tool that's accessible to even more teachers. Those teachers can then screen even more children, help shrink the gap, and support as many children as possible.
What lasts is the plumbing: the ticket process, the Slack routing, the triage tool, and Joe using all of it. At sign-off, Joe was grateful, and Devam said he'd miss the ops calls. I've stayed on at ALPACA in a lighter role, focused on high-leverage work. Joe has set a goal of 80–90% customer support automation by winter, and I've agreed to work towards it. The scaling roadmap and the school-partnership knowledge base from my proposal still don't exist.
What I learned
The moment I think about most is the merge at half ten on the evening of 20 August. Shikhar had 116,000 lines of code across 558 files in front of him and was worried: "gonna kill me tomorrow, maybe". I told him it was fine because our CTO had signed off, so the responsibility lay with him, not with us. At the time that felt like leadership. Looking back, it was me passing accountability up to someone who wasn't on the call. Shikhar stayed on because, as he put it, "I don't want anyone to work alone in the night." He was showing care; I was showing certainty. It taught me that leading under pressure isn't about having the answer. It's about staying in it with the people doing the work. During back-to-school, I stayed on as many late calls as I could until the fix was live, and checked in on whoever was doing the work.
The summer tested all three qualities from my PDP. Courage meant taking on an inbox with no system behind it and building one anyway. Communication meant translating between engineers and teachers, which was most of my job; the impromptu public speaking at the LEAD days helped, because when you've had enough reps of being thrown in the deep end, a chance to prepare feels like playing on easy mode. Work ethic meant staying until the back-to-school failures were fixed. At sign-off, Shikhar praised me for "diagnosing before escalating". But the quality that grew most is one I didn't list: prioritisation, the ability to stop a conversation and focus on the important things.
What I'd do differently
I'd renegotiate my objectives much earlier. In week one, with Agata gone, I should have sat down with Joe and rewritten them around what ALPACA actually needed. The work was valuable, but agreeing new objectives would have let it count for more, and let the Laidlaw team support me properly. Next time the plan changes in week one, my first call is to the guys in charge.
Areas for future development
- Enabler: the part of ALPACA I'm proudest of. The ticket process, the routing and the triage tool all exist so other people can do their best work. My PDP said a leader "removes obstacles", and that's what they do.
- Rapport builder: the team was distributed, with Shikhar, Devam and Duncan all remote and me in Dublin. I learned rapport looks different with each person. With Joe I was almost always solving; with Duncan I was always just listening.
- Unconditionality: separating the person from the problem is the one I'd still mark unfinished. First impressions matter to me, and a bad one is hard to shake, even when it's ambiguous. That's what I'll keep working on.
Conclusion
Before my LiA, I believed good leadership was creating a system for great people to do their best work. ALPACA reaffirmed it. A system isn't bureaucracy; it's how people understand what's going on, what's expected of them, and where they can make the most impact. The plan I was approved on didn't survive the summer, but the systems I built did, and they're still helping ALPACA's teachers screen children today. The next step is to build those systems myself rather than wait to be handed them: at ALPACA, in my final year at Trinity, and wherever I go next.