From hex, EPROMs and parking meters to payments, EV charging and 10,000 connected terminals
From November 2006 to April 2017, I worked at Cale Access UK, now Flowbird. I joined as a Field Service Engineer and progressed through senior third-line engineering, technical support management and operations management.
That sounds like a fairly tidy career path. The reality was considerably messier, much more hands-on and probably one of the best technical educations I could have had.
For years, I thought I had spent a decade working in parking. Looking back, I actually spent ten years making things talk to other things.
When Programming Involved a UV Lamp
Some of my earliest work involved the Cale 5005, which I programmed directly in hex using EPROMs. There was no cloud deployment, instant rollback or handy undo button. If I got something wrong, the chip came out, went under a UV light to erase it, and then I tried again.
We’ve come a little way since then. 🤓
I worked across equipment including the 1001, MP101, MP102, MP104 and the full CWT range. Behind the user interface were bespoke industrial micro-PCs, DOS-based systems, PLCs, PCB-level electronics, servos, gears, springs and relays.
Some days I was writing or changing code. Other days I had a soldering iron or multimeter in my hand, diagnosing an electronic or mechanical fault and trying not to blow myself up.
The interesting question was never really which layer owned the problem. It was simply: what needs to change to make this thing work?
Payments Changed, but the User Just Wanted to Pay
Payment technology changed dramatically during those ten years. I worked on Chip & PIN, PCI DSS 1.1, EMV Level 2 hardware integration, contactless payments, MIFARE, DESFire and later mobile-wallet payment terminals supporting Apple Pay and Google Pay.
I was knee-deep in payment vendors, test cards and approval criteria, working through everything required to get new payment modules operating properly on Cale equipment. There would often be someone arriving with a formidable collection of cards and test scenarios, ready to find every possible way our equipment could fail. Then we fixed what failed.
For Ipswich, I built a bespoke top-up card and integrated e-purse solution using a dual MIFARE/DESFire card. It was the first implementation of that combination on Cale equipment.
The technology underneath could become incredibly complicated. The customer requirement never was:
Let me pay easily and get on with my day.
That difference between complexity underneath and simplicity at the surface has stayed with me ever since.
Ten Years of UX Before I Really Called It UX
My users were rarely sitting comfortably at desks. They were standing in car parks, often in the rain, trying to understand a machine they might never have used before.
They didn’t care which terminal, payment service, network or back-office system was involved. They wanted to park, pay and continue with their day. If they had to understand the technology underneath, we had designed the experience badly.
One of the projects I’m proudest of was the Check-In / Check-Out parking system in Tunbridge Wells. I was the UI Design Lead, shaping the experience presented to the person using it.
The principle was deliberately simple:
Arrive and check in. Leave and check out. Let the technology handle the complexity.
The collaboration went on to win a British Parking Association technology award. That mattered because it recognised more than the equipment. It recognised the experience we had created around it.
Behind that simple journey sat payment hardware, communications, compliance, back-office processing and plenty of operational complexity. The customer shouldn’t have to see any of it.
Sometimes the Integration Was a Relay
One project in Bury St Edmunds involved integrating an MP104 parking terminal with an electric vehicle charging post. The solution itself was wonderfully simple: the customer paid for their parking time, and a relay activated the charging post for the corresponding period.
It was an early Cale integration of parking payment and EV charging, several years before that combination began appearing more widely.
That project taught me something I’ve never forgotten:
The best solution isn’t necessarily the most technically impressive one. It’s the one that solves the problem.
Sometimes that means an elaborate system. Sometimes it means putting a simple relay in exactly the right place.
Sometimes You Build the Missing Piece
Another long-running problem involved integration between Thales and ICA pay-on-foot technology. The systems weren’t playing nicely together, so I created a COM-to-DREG splitter to resolve the issue.
The solution was used across the 2000, 3000 and 4000 ranges and rolled out across Germany and the UK within months. It became part of the working technology rather than remaining a one-off fix. Rewrote the support .exe and translated it to English.
Again, the important part wasn’t really the splitter. It was identifying the awkward point between two systems and building the missing piece between them.
From Code to Cogs
Not every integration involved software. I programmed PLCs and bespoke industrial micro-PCs, often working with DOS-based systems. I configured and troubleshot networks, set up WatchGuard firewalls and completed a fair chunk of the Cisco CCNA training.
I didn’t finish the CCNA. Halfway through, the course content changed and my ADHD brain promptly wandered off somewhere else. 😂
But I was still doing the work.
I also built integrations with speed shutters (scary things, thats all i can say), gates and barriers of different sizes and from different manufacturers. Sometimes the requirement was incredibly literal: take a payment or recognise an event, then make this enormous physical thing open.
I wired two-way communications and upgrade modules, fault-found electronics and worked with the physical control systems needed to make the whole service operate. Sometimes that meant changing the code. Sometimes it was the electronics, network or mechanical system.
Occasionally, it was the concrete.
When the Network Didn’t Exist, I Built It
Connectivity was another substantial part of the job. I was AT&T Cat5 trained and certified, Excel Cat5e certified, polished and terminated fibre, and worked on fibre runs of around two kilometres.
In 2009, two buildings needed connecting and had a clear line of sight between them, so I built a wireless bridge using directional Yagi antennas.
That’s the part I had almost forgotten when I first started writing this. If the network didn’t exist, we built the network. If two systems didn’t integrate, we built the integration. If the barrier didn’t talk to the terminal, we made them talk.
If that required code, a soldering iron, a multimeter, fibre, network cable, relay or directional antenna, that was what we used.
Apparently “full stack” meant something slightly different when part of your stack was buried underneath a car park.
Getting Stuck In
For all the technology, I was never particularly interested in standing at the side and pointing at things. If an induction loop needed cutting into the ground for a barrier, I would cut the loop. If the groundworks needed sorting, I helped sort them. On more than one occasion, I spent a few hours on the jackhammer myself.
That experience mattered when I later started managing people.
I’ve never been comfortable asking someone to do something I wouldn’t be prepared to do myself. That doesn’t mean a manager should take the tools out of everybody else’s hands or try to do every job personally. It means understanding what you are asking of people, respecting the work involved and being willing to get stuck in when it’s needed.
That attitude has steered me pretty well ever since.
Then There Was Scale
Eventually, the work stopped being about individual terminals. I ran a connected estate of around 10,000 parking terminals across the UK for a client.
The estate relied on a mixture of SIM and cellular connections, satellite, microwave and Wi-Fi links, and conventional network infrastructure. Thousands of physical devices distributed around the country ultimately had to behave like one operational service.
Alongside that, I looked after the internal technology behind the business. That included the on-premises server environment, Active Directory, Exchange, networks, remote support, documentation and supporting the staff and field engineers who relied on it all. I later supported the move towards Office 365 too.
One minute, I could be working on a payment experience or solving a terminal integration problem. The next, a member of staff couldn’t access something, an engineer needed help in the field, a firewall needed configuring or a server required attention.
The user didn’t care which part was broken. They just knew the service wasn’t working.
That is still one of the most useful operational lessons I’ve learned.
The Annual Parkex Pilgrimage
Always a team effort! Those ten years also included the annual pilgrimage to Parkex. Each year, we were surrounded by the wider parking industry, demonstrating what we had built, talking to customers and suppliers, and seeing new technologies arrive.
It gave me another view of the complete technology lifecycle. The work wasn’t finished when something functioned on a test bench. It needed to be understood by customers, demonstrated publicly, installed in the real world, supported by engineers and kept running operationally.
Somewhere along the way, I was offered a role with Cale Access AB in Sweden. I didn’t take it, but looking back, it’s a nice reminder of how far I had travelled from arriving as a field engineer.
A thank you to a certain person (you know who you are), that provided Vodka and slush puppy’s at the end of events. When ya knacked and closing down. Was a fun way to end these events.
Mistakes Were Definitely Made
I don’t want to polish the story so much that it stops being true. Mistakes were made.
Things broke, ideas didn’t always work the first time and, occasionally, something I had built behaved in a way it absolutely wasn’t supposed to. But we fixed things quickly, worked out what had gone wrong and learned from it.
That’s engineering.
As I gained experience, I also mentored two or three apprentices coming through Cale. That mattered to me because I had learned so much by getting stuck in myself.
I had programmed terminals, cut loops into concrete, integrated barriers, connected buildings, supported engineers and followed integration problems through every layer of the technology. Passing some of that knowledge on became another important part of the job.
A Great Job, With Difficult Parts
I don’t want to rewrite those ten years as either a perfect adventure or a long grievance. It was a great job, but there was pain in it too.
The role grew far beyond any tidy job description. At times I carried too much, stayed longer than I probably should have and wasn’t always rewarded in proportion to the responsibility. There were difficult days, mistakes and pressures that I wouldn’t pretend away.
But I was also given an extraordinary opportunity to learn. I could follow a problem from the user interface through the payment system, network, server, electronics and mechanics, and sometimes all the way down into the concrete beneath the machine.
I was trusted to get stuck in, work things out and make them better. I met good people, mentored apprentices and probably gained several careers’ worth of experience inside one company. The salary, sadly, didn’t appear to work on the same multiplier. 😂
And if any of the people I worked with during those years ever come across this, thank you. I genuinely loved working alongside you and learned something from everyone, whether we were building something new, fixing something that had gone wrong or simply finding a way through another difficult day. The technology shaped my career, but so did you all.
Both sides of the story are true. I can recognise where it hurt, where I should perhaps have moved on sooner and where things could have been better, while still looking back with real affection for the work, the people and the adventures we had.
It wasn’t perfect. It was formative. And I’m genuinely grateful for those ten years.
Fast Forward to Now
The tools look completely different. At FYER, I spend my time thinking about business processes, Microsoft 365, automation, APIs, systems integration and agentic operations.
The shutters and barriers have largely been replaced by workflows and business systems. EPROMs have become cloud platforms, and a relay might now be an API call.
There’s another substantial chapter between Cale and FYER, but that deserves a story of its own. For now, the strange thing is realising that the instinct underneath everything has barely changed:
Find the awkward bit. Understand the process. Connect the things that weren’t designed to work together. Make the complicated bit disappear for the person using it.
For a long time, I thought I had spent ten years working in parking technology. I think I actually spent ten years learning how to make things talk to each other.
Turns out I’m still doing it. I just have slightly better tools now, and thankfully considerably fewer UV lamps. 🤓
