DEV Community: Brendan Devenney

One Year

Brendan Devenney — Wed, 01 Jul 2026 00:00:00 +0000

A year ago today, I started at Approov.

A hundred days in, I wrote about the transition: leaving management, the refreshing day-to-day feedback loop, the strange experience of relearning a craft I thought I'd lost. I stand by most of it. But a hundred days is enough to notice a change; it takes a year to understand it.

So here is what a year taught me that a hundred days couldn't.

The rust that mattered

At a hundred days I called myself rusty. I was. I reached for patterns that no longer fit and looked up syntax I once knew by heart.

I expected that to be the hard part. It wasn't.

The rust came off faster than I feared, and somewhere along the way I realised I'd been worried about the wrong thing entirely. The agentic era arrived in earnest this year, and it quietly rewrote the job description. The premium skill is no longer how fast you can produce code from memory. It's whether you can write a precise specification and make a strong architectural decision, then judge honestly whether what comes back is any good.

Those are not new skills for me. They are the exact skills that years of reviewing architecture and mentoring engineers had been sharpening the whole time.

The craft I sat down to relearn was not the craft that turned out to matter.

I spent years assuming management had pulled me away from engineering. It hadn't. It had been quietly preparing me for the version of engineering that was coming.

Charity Majors has a name for the shape of this: the engineer/manager pendulum. The idea that a healthy career swings between the two, rather than treating management as a one-way door you walk through once and never come back. I didn't choose when mine swung back. But it swung the right way, and the years spent on the other side weren't lost. They were compounding.

A secure transaction is a secure transaction

The work itself has been a homecoming of a different kind.

I spent years in payments. Now I work in mobile and API security. On paper those are different worlds, but the longer I sit with them the more they rhyme. Strip away the vocabulary and you find the same problem underneath: a secure transaction is a secure transaction. It has to go fast enough that the user never notices, and securely enough that there is never any danger. Get the balance wrong in either direction and you've failed.

There is one difference, though, and it changes everything.

In bank-to-bank payments you can largely trust both ends of the wire. Both sides are regulated, identified, accountable. In mobile security you can trust nothing. The client is in the hands of someone who may be actively trying to deceive you, running on a device you don't control, talking to an API that has no way of knowing, without help, whether the thing on the other end is your real app or a clever imitation of it.

Trust is the whole game. In payments you mostly start with it. In mobile security you have to earn it, every single request.

That single shift in assumption has been the most interesting thing I've learned all year.

Pulling in the same direction

For years I sat in a strange middle layer. I didn't fully understand the decisions being made above me, and I couldn't always explain to the people below me why we were doing what we were doing. I translated in both directions and was fluent in neither.

That layer is gone, and it might be the best part of the whole year. I pull in the same direction as the people next to me now. We talk, we decide, we build. When something needs heavier process we add it; otherwise we don't. It is the inversion of the corporate default, and a year in I'm convinced it's the right one. Not because process is bad, but because most of it is inertia wearing a calendar invite.

What surprised me is how well the scale-up instincts I thought I'd left behind have aged. Approov is maturing, adding the enterprise capabilities that bigger customers need, without losing the punch that makes a focused product company worth working for. You can see it in the open in something like the 3.6 release preview. Knowing how to grow up without slowing down turns out to be a rarer skill than I gave it credit for.

Predictable where it counts; fast everywhere else.

Full circle

I'd love to end this neatly. I can't, because I'm still figuring it out.

I can say with confidence that this was a good move, for my career and for my happiness. But I'd be lying if I said the ground feels stable. More than half of internet traffic is agentic now. Before long, more than half of the code will be too. I genuinely don't know what that makes an individual contributor in five years. I think about it most when I think about the junior engineers I'm responsible for. What exactly am I preparing them for?

I don't have the answer. But I have found something that feels like the right response to the uncertainty.

This year I became a placement host, mentoring students on their year in industry. That is precisely how I arrived here myself, years ago, when Approov was still CriticalBlue and I was the one who didn't know anything yet. Someone took a chance on a placement student and built him up. Now I get to do the same, and there is a symmetry to that I didn't go looking for and am very grateful to have found.

Maybe that's the answer to the agentic question, or at least the start of one. The tools will keep changing. What we owe the next person coming up behind us doesn't.

If you've made a leap like this, out of management, into something new, or back to something you'd left, I'd love to hear how it landed for you. Reach out.

Rebuilding devenney.io with Claude and Cloudflare Pages

Brendan Devenney — Sun, 14 Jun 2026 00:00:00 +0000

Every few years, I rebuild this site.

This one happened over a weekend, between World Cup matches.

The pattern is consistent: new technology arrives, I wait until the guilt about the old stack becomes unbearable, and I redo the whole thing. The previous site was webpack and Handlebars, which tells you roughly how long it had been sitting there. I have been busy. I also jumped straight past whatever the intermediate era is supposed to be (pick your flavour of React framework) and landed directly in the Claude and Astro 6 era. I did manage to keep Tailwind, as I love that framework.

The honest context: most of this rewrite was done by Claude Code. The workflow was: write a spec, hand it to Claude, review the output, iterate. I contributed the judgment; Claude contributed the typing. That is a workflow you can fit between matches.

The reason I want to write about this is not the AI angle. It is the stack. Each technology I picked had the same criterion: does it remove a category of problem from my personal time, or add one? Every step closer to that answer being "remove" is a step closer to being able to focus on the things that are actually worth my time.

Astro

Astro is a static site framework with a simple idea: build once, serve flat files, no runtime. For a personal site it is the right default. Content collections give you typed and validated blog posts without a CMS. The island architecture means interactive pieces do not pull in JavaScript you do not need.

The previous stack was webpack and Handlebars. Getting a blog post onto the page required a build pipeline, a template, and enough manual wiring that I avoided touching it. The content schema for this blog is about as simple as it gets:

const blog = defineCollection({
  loader: glob({ pattern: '**/[^_]*.md', base: './src/content/blog' }),
  schema: z.object({
    title: z.string(),
    description: z.string().optional(),
    date: z.string(),
  }),
});

Write a markdown file, push, done. No templates, no build configuration to maintain.

One category of problem removed: I no longer have to think about the build system.

Cloudflare Pages

This is the part worth writing about.

Here is what deploying used to look like:

Build → S3 sync → CloudFront invalidate → check DNS → hope

Three AWS services, IAM policies that needed to be exactly right, and a mental overhead that meant I avoided shipping unless I had a good reason.

Cloudflare Pages is configured with two fields:

Build command: npm run build
Output dir: dist

That is the entire configuration. Every pull request gets a preview deployment automatically, so before merging anything I can click a URL and check it looks right. When I merge, CI has already confirmed there are no broken links and accessibility has not regressed. Cloudflare deploys the result. GitHub Actions tags the release. I do nothing else.

I have been running things on AWS for years and I know how to navigate it. But there is a real difference between infrastructure you can use and infrastructure that stays out of your way. One category of problem removed: I no longer have to think about deployment.

It is also free.

Lighthouse CI

Lighthouse is Google's tool for auditing accessibility, SEO, and performance. Running it in CI means any regression fails the build before it ships.

The configuration lives in .lighthouserc.json:

{
  "ci": {
    "collect": { "staticDistDir": "./dist" },
    "assert": {
      "assertions": {
        "categories:accessibility": ["error", { "minScore": 0.9 }],
        "categories:seo": ["error", { "minScore": 0.9 }]
      }
    },
    "upload": { "target": "temporary-public-storage" }
  }
}

The key detail for a statically built site: use staticDistDir rather than pointing Lighthouse at a live URL. Astro builds flat HTML files you can audit locally without a server. The upload block is optional but gives you a shareable report URL for every CI run at no cost.

It caught several accessibility issues I would not have noticed manually. One category of problem removed: quality regressions that used to slip through now do not.

Lychee

Lychee checks every link in the built site. It is one step in the CI workflow:

- name: Serve dist for link check
  run: npx --yes serve dist -l 4321 &

- name: Wait for server
  run: npx --yes wait-on http://localhost:4321 --timeout 15000

- name: Check links
  uses: lycheeverse/lychee-action@v2
  with:
    args: --verbose --no-progress --exclude 'linkedin\.com' http://localhost:4321/
    fail: true

The non-obvious thing: Lychee cannot resolve root-relative links (like /blog/ or /rss.xml) from static HTML files directly. The fix is to serve dist/ on a local port first and point Lychee at the running server. Two extra steps, but it means broken links fail the build.

One category of problem removed: I no longer ship broken links without noticing.

The full flow, from writing to live: open a PR, CI runs lint and type check and Lighthouse and Lychee, Cloudflare Pages builds a preview, I check it looks right, I merge. Cloudflare deploys. GitHub Actions tags the release. That is it.

Every step in this stack was chosen because it removed something from my mental overhead. Personal time is finite. I would rather spend mine watching Scotland win the world cup.

The source is on GitHub.

100 Days

Brendan Devenney — Sun, 26 Oct 2025 00:00:00 +0000

A hundred days ago, I left management.

That wasn't how it felt at the time; I'd just been made redundant after several years in leadership.

But when the dust settled, I realised this was something I'd been quietly wanting for a while: a return to building things myself.

I've tried to be open about how this transition has been good for me. Friends in similar positions have found the insight useful - either to inform a decision or to temper expectations once it's made.

So what are the big differences 100 days in?

The feedback loop is refreshing

The feedback loop in management plays out over quarters or years. A conversation you have with a direct report has immediate impact, but the feedback comes far down the line. Someone applies for a promotion and gets it because you gave them good advice; or someone resigns because they have been quietly harbouring negative feelings due to a decision you made.

In a traditional engineering role, the feedback loop is day-to-day. You write unit tests that intentionally fail, you code your feature change until those tests pass, and you ship it for review. The code either works or it doesn't. If you missed something, it pops when it hits production. Even then your response is obvious: return to the start of the loop.

Scale-up habits die hard

Years in fintech and management shape you in subtle ways. You start to think exclusively in terms of frameworks, alignment, and stakeholders. Every task becomes a project, every project needs a doc, and every decision requires a meeting.

Some of that remains necessary in a focused product company. There is still compliance and customers expect a stable service. These things should remain consistent. Predictable is powerful.

But when you return to a more focused, specialised engineering organisation, you see how much of the corporate framework is just inertia. How often we mistake coordination for progress.

Here, we talk, we decide, we build. If it needs heavy process then we implement it. Efficiency is the default, process is case-by-case. It's an inversion of the corporate approach.

Relearning the craft

Coming back to hands-on engineering after years in leadership has been humbling. I was, and am, rusty. I reach for patterns that don't quite fit anymore. I look up syntax I once knew instinctively.

But I'm also sharper in other ways. Years of reviewing architecture and mentoring engineers have rewired how I think about design and clarity. The output might be slower, but the intent is stronger.

And the best part is the camaraderie. I bring context; my teammates bring modern fluency and technical depth. Together, we meet in the middle. They make me faster; I help them see the bigger picture. It's a better loop than I expected.

Ego and perspective

Stepping down from "Head of Engineering" to "Staff Engineer" looks like a demotion on paper. And yes, it messes with your identity for a bit.

There's a part of you that misses being in every conversation, influencing strategy, managing people. But then you start delivering again - and you realise how much lighter it feels to just do the work.

I'm not delegating problems anymore. I'm solving them. My code runs. And I still get to mentor, guide, and shape decisions - just without the meetings, frameworks, and dotted lines.

Rediscovering impact

One thing I've learned at Approov is that focus scales. You can be lean and still serious. You can be efficient and still ambitious. You can do meaningful work without fifty people in the room.

When something breaks, you fix it. When something works, you build on it. Things happen for a reason, rather than everything happening because it's prescribed by the internal literature.

You can literally see your impact in the metrics, the customer attitude, and the day-to-day operations. Your perspective shifts toward what customers actually care about. These combine to prove the viability of a product without the need for an internal committee.

It's energising.

The pendulum swings

Charity Majors has discussed the Engineer/Manager Pendulum for many years. As sage as her wisdom is, it's often hard to relate until you've lived it.

This experience has proven to me that careers aren't linear. They oscillate. You take a position of leadership for influence and people skills. You make individual contributions for clarity and sharpness. Neither of those is actually tied to a role.

Both skill sets are valid. Both skill sets matter.

In conclusion

To my friends who were made redundant from leadership roles or are simply considering a change of pace: I know that shift can feel like failure. But it isn't. It's a recalibration.

You're not going backwards. You're rediscovering what brought you here. Sharpening the old tools to augment everything you learned at cruise altitude. You will be better for your experience.

A hundred days in, I can say it plainly: I should have done this sooner.

On Mental Health as a Manager

Brendan Devenney — Tue, 25 Oct 2022 00:00:00 +0000

I'm in the very privileged position of having a work environment which fosters personal growth. A generous budget combined with paid learning days provides opportunities which would otherwise be impossible. So, given I stepped into a management position 18 months ago, these resources should clearly be dedicated to management courses - right? Project management, promoting synergy, reading social cues to manipulate your team into productivity. These are the skills you need to thrive as a manager by corporate standards, and we work with really big banks so it's a no brainer.

Don't worry, what you're currently thinking is correct: that's complete nonsense.

Yes, we have to care about timelines, deadlines, capacity, velocity, and everything else which keeps a project moving forward. I know this is a bit of a hot take in the management world, but messing those things up is low-risk. You missed the deadline, the customer is angry... so what? It's not the end of the world; the sun is still going to rise tomorrow. But then what should we be focusing on as managers? In my opinion this is quite obvious: as managers of people, we should be focusing on people skills rather than management skills.

Let me capture a little bit of that journey - hopefully it inspires you to do the same.

Mental Health First Aid

When I took my first steps into management, my biggest fear was not being able to help my team with the mental wellbeing issues which plague the engineering world: stress, anxiety, and burnout. While it's important to remember that a manager is not solely responsible for the mental wellbeing of their team, you cannot avoid the fact that managers often have the most insight into an individual's life. You are, through one-to-ones and daily interactions, perfectly positioned to notice the warning signs of poor mental wellbeing. In addition to that, you are likely to be the first port of call for any employee who needs to voice their problems (be those personal or professional).

Are you ready to handle those situations? I wasn't.

My first goal was to give myself the skillset required to deal with a team member in crisis. Your team looks to you not for micromanagement and deadlines, but for guidance and support. Technical guidance is easy, translating product requirements takes time, but providing emotional support requires care. When someone is in crisis you need to handle the situation correctly; a misplaced comment or a bad assumption can turn an individual's situation from bad to worse. Becoming a certified Mental Health First Aider (MHFA), if nothing else, gives you concrete evidence that you have this skillset.

Understanding Mental Health

So you're a people manager with an MHFA qualification. You can help to triage a team member's emotional crisis. That's fantastic, but there's no ignoring the fact that this individual fell into crisis in your charge. Please don't get me wrong; by no means am I suggesting that you can protect your team members from poor mental health in all cases. However, it goes without saying that it is your responsibility as their leader to safeguard them from the professional factors which can contribute to a crisis.

The next step for me was to build a deeper understanding of how the human mind works. This ranged from the factors which affect wellbeing to the long-term treatment of diagnosed mental health conditions. Unfortunately, this is not something you can learn from a two-day workshop. The only option is real study.

I set myself the goal of achieving a college certificate related to mental health, and the course I settled on was Understanding Mental Health (Level 3). This provided a strong foundation of mental wellbeing awareness, an overview of the most prevalent mental health conditions in today's society, and a deep dive into the support systems, treatment plans, and interventions which exist to combat these conditions.

The outcome? I now feel confident that I can identify the early warning signs of poor mental wellbeing - and that I can empathise with an individual who is undergoing treatment for such a condition.

What's next?

Unfortunately, I don't yet know my next step on this learning journey. The only way to really solidify all of this knowledge is to apply it in the real world, and of course I hope that this never happens. Perhaps you have a good suggestion for me here? I would love to hear your thoughts on what forms of personal growth have worked well for you as a people manager - so please reach out!

1,000 Days

Brendan Devenney — Mon, 21 Feb 2022 00:00:00 +0000

One thousand days is a long time.

Life has changed immeasurably for everyone on the planet. As some of you know, I decided to go for the grand slam of life changing events as a global pandemic clearly wasn't enough for me. For once, I'm going to take the path of least resistance and list what hasn't changed:

I work at Form3.

I'm not going to sit here and tell you it's because everything is perfect here - it's absolutely not - but a wise woman once told me, "it doesn't have to be perfect, son, it just has to be worth it." Hopefully there's something useful in this article whether you're going through similar turbulence or simply need something to read with your coffee.

Day Zero

The most interesting thing about my arrival at Form3 was the onboarding process. It was handled almost entirely by our People Lead who had been at the company for approximately a month. To this day, I have no idea how she managed to spin so many plates at once without dropping them all in spectacular fashion. What I do know is that it's a good indicator of how young the company was: our onboarding, background checks, right to work, equipment procurement, travel advice, office access, and so much more were handled by one person who barely had time to settle in herself.

If you have any Agile certifications, look away now - it gets worse.

Every day we had an Engineering stand-up. Yes, an Engineering stand-up with a capital 'e'. The whole business function. At first it was almost a full page on Zoom... then it was a page and a bit. At about this point we quickly realised that what we were doing was nonsensical. Can you imagine fifty engineers giving their daily updates in fifteen minutes? I know some people who would be apoplectically angry about this, and they'd be right - it doesn't work.

Perhaps worst of all from a human perspective was how this translated to on-call. Spoiler: not well. Being on-call meant you were on-call for the entire platform. That's great when the platform is small but the stress grows exponentially with the number of microservices.

Architecting perfectly for scale is impossible - adapting is key.

Growing Up

Within a few months of me joining the company, we were in a whirlwind of change. The teams which already existed - Euro, Platform, UK - were given complete autonomy over their ways of working. The on-call rota was chunked up in a similar way to ensure that: a) engineers were on-call only for their area of expertise; b) engineers could call in expertise if the incident appeared to be caused by an adjacent team's service; and c) the average workload of an on-call shift was stable.

The impact was immediate. We were working faster than ever due to the new focus; quality of life changes for on-call were being prioritised due to the increased frequency of shifts; and teams were adapting ways of working which suited their people, projects and workload.

Autonomy is powerful in the hands of the right people.

One thing of note here is that we did not enforce a framework on the teams. The only standing meeting was our tech town hall for knowledge sharing. At this growth breakpoint most companies go all-in on Agile or SAFe without really thinking it through. You end up with a bunch of Scrum meetings in your calendar which the teams join and tolerate like robots. Don't get me wrong, all of the above are good solutions to the right problem. The important thing is that they aren't a silver bullet for scaling problems. You have to understand which problems you have, which solutions to try, and which solutions simply aren't working.

Fix real problems before presumed ones.

Gateways and Grandmothers

The worst thing about software engineering for me has always been trying to explain what I do. Imagine sitting down to have a coffee with an eighty year old woman, telling her what you're going to be building for the next few years, being met with a completely blank stare, then hearing a confused, "oh... that's nice, son." The things I have worked on in my life simply aren't relatable to the average person: nobody knows what an API is, let alone why it needs to be secured; clouds are fluffy things in the sky; and tracing is a thing you do with a pencil.

I cannot tell you how nice it was to be able to sit her down and say, "when someone transfers money to their friend, it's handled by the thing I made." To see genuine understanding in those wise old eyes. To have her finally believe that I'm making the world a better place. My career has always felt a bit like the maths problems you get in school; when a problem is academic or speculative, it doesn't feel so real.

Having real-world impact is motivating.

People-People

One thing which fascinates me about Form3 is the People Team. As you transition from a scale-up to a well established company, there are so many factors pulling in so many different directions. Most of these, despite being necessary, are undesirable as an employee: compliance, information security, legal, offboarding, post-mortems, regulations. In my experience this is where a company's claim to be "people-centric" falls to pieces. This has not been the case at Form3.

Our People Team are somehow capable of simultaneously doing everything an established business has to do and caring about our people. Based on meeting them I can only assume this is sheer stubbornness and refusal to compromise. Whatever the reason, it's a beautiful thing (just like my RH Mereo 220).

We call organisations "companies" for a reason: it's all about the people.

Onwards

I would love to wrap this up with a paragraph about where Form3 is heading. You know what, though? I really don't know and I love that; I trust that our ethos will keep us right whatever happens. So, in summary:

Architecting perfectly for scale is impossible - adapting is key.
Autonomy is powerful in the hands of the right people.
Fix real problems before presumed ones.
Having real-world impact is motivating.
We call organisations "companies" for a reason: it's all about the people.