Tim's story: From the City of Philadelphia to Staff Engineer at Beam

We caught up with Tim, a Staff Engineer at Beam, to talk about his path into software - from civic hackathons and local government in Philadelphia, to Citizens Advice, to building the offline-first infrastructure behind Notes.

You had a pretty unusual route into engineering. How did it start?

I started out in local politics and community development in Philadelphia. Building software was really just a hobby at first. In 2011, I went to my first civic hackathon, where we built an app that let members of the public look up landlords to check whether they had back taxes owed, or violations on file.

Around that time, I got a job in local government - not an engineering role, but I saw pretty quickly that the technology gap in local government is really wide. There weren't many programmers who knew how to build solutions to the problems we were facing, so I found myself filling those gaps and leading technology projects. Eventually I was offered a role as Director of Civic Technology, and later Chief Data Officer.

What made you decide to try Beam?

I moved to the UK in 2019 and spent the next few years in the public and charity sector, including three years as Director of Technology at the national Citizens Advice office. In 2024 I was working as a consultant, and during that time I was getting up at 5:30 or 6am most days to work on personal coding and open source projects, partly because I wanted to stay close to how engineering was changing. As AI started to accelerate that change, I decided the best way to keep up was to be hands-on with it every day, so I moved back into an individual contributor role - a break from hiring, budgets and strategic planning, and a way to stay close to the technology itself.

I came across Beam through a Ruby on Rails Slack channel. I'd spent my whole career in public sector and charities, so I wasn't sure about a tech startup, but I had some great conversations with the team and decided to give it a go. I joined in May 2024, and honestly, I initially thought AI was overhyped but it's the thing I can't stop learning about now.

What should a new engineer joining Beam be excited about?

The problems we work on genuinely matter, and they affect people who are normally last in line to benefit from the latest technology. Because of the position Beam is in - existing relationships with public sector bodies, an established reputation, and the speed of a tech startup - we can get new capability into the hands of frontline workers fast. We've had new starters ship a feature that directly impacts frontline workers within their first few weeks.

A big part of that is how we think about the product engineer role. It's not a conveyor belt where engineers pick up a pre-defined ticket and implement it. Engineers are involved from the very start - looking at what users are telling us, what the strategic priorities are - and then they own a problem end-to-end, from first prototype through to measuring whether it actually moved the needle.

Can you give an example of that impact in practice?

When I joined, the top problem was that users - often in hospitals or buildings with poor Wi-Fi - were losing chunks of audio from their recordings because of network connectivity issues, which meant people started taking notes as a backup, undermining the whole point of the product.

I'd worked with local-first applications before, so I pitched an offline queue: audio stored in chunks on the user's device, only deleted once it's successfully uploaded. I worked with the rest of the engineering team to build it, and now if someone loses connectivity mid-recording, or their phone restarts, the recording is still there - they just reopen the app and it uploads. That entire category of problem disappeared. We later expanded it into a full offline mode with a team of five engineers.

One thing that stuck with me was that no matter how good your word error rate or your summarisation model is, AI only adds value when it contends with the operational realities of frontline work.

What makes Beam's engineering culture stand out?

The people are really talented, a lot of them with real frontline experience, which gives us a lot of empathy for our users. Beyond that, it comes back to that end-to-end ownership - the lines between engineering, product and design are pleasantly blurry, and it's actively encouraged for engineers to get involved in product and design work.

We're also big on shared responsibility. If something goes down, it's everyone's problem. I've seen eight of us jump on a call to help deal with an incident. Any engineer can propose infrastructure changes - we trust people to understand the infrastructure the way they understand the product.

What would you say to someone thinking about applying for an engineering role at Beam?

Do it. Our interview process is deliberately challenging - there's a live coding exercise and a system design exercise, but on the other side of that, you get real autonomy, the freedom to own problems end-to-end, a genuinely good group of people to work with, and the chance to do work that actually matters - without having to take a pay cut to do meaningful work, which is not something I could always say in the charity sector!

Interested in becoming an engineer at Beam? Check out our open roles here.

‍