Paul Blay

Painful Vibe coding with Codex

October 15, 2025

Use of LLMs I’ve been using LLMs for a while, primarily as a buddy that can help me with ideation or noticing gaps in my thinking. I rarely use the LLM output directly because it never feels complete or authentic. For written word, I find it can generate pretty generic wording with little impact or personality. Anything I do take directly, I’ll rework pretty heavily - and it’s just a judgement of whether doing the rework is more efficient than just starting from scratch.

Aligning Teams With Outcomes - A Product Application

By Paul Blay in outcomes, metrics

October 13, 2025

From experience I know that great ideas are only as valuable as their applications in the real world. I’ve used OKRs and Outcome framing for quite a while, so it’s about time to showcase a real world example - what it did for us and what we learned. I’ll present this in the classic STAR format like I’m trying to answer an interview question… because that’s what I’ve been spending time doing recently.

Beyond memory tests: Designing interviews for assessing competence

By Paul Blay in people

October 8, 2025

I chose the old photo banner art (Photo by Debby Hudson on unsplash) because most of my recent interviews have felt more like a memory test than a competency test. “Tell me about a time a family member gave you some advice, what was it and how did your life change as a result? Did you send them a thank you card? What was on the card?” Yikes, I don’t remember!

A Policy for AI-enhanced software development

By Paul Blay in delivery, people

October 7, 2025

The DORA research group at Google recently came out with an AI capabilities model and capability number 1 is to have a “Clear and communicated AI stance”. Given my experience so far talking to other leaders and on the ground, here’s my proposal for what an effective AI stance could look like: Core Philosophy LLMs should amplify engineering cognition, not automate it This means… Human Ownership: Engineers must remain the authors and owners of production logic.

Introducing the OKR ScoreCard

By Paul Blay in outcomes

April 5, 2021

So let’s assume we’re using OKRs now. We’ve come up with some Objectives and tried to find meaningful measures for our Key Results that we think will help us ensure we’re going in the right direction. It’s important to remind ourselves that OKRs are just a tool. Using an ORK framework doesn’t necessarily ensure that we’re getting any tangible benefits over any other approach. For example, the next two OKR examples for our imaginary TownTalk ™ product both provide an objective and measurable KRs against it, but do both really unlock the same value?

The agility Challenge for Embedded Software

By Paul Blay in embedded, delivery

December 2, 2020

If you’ve ever worked for a business that has it’s core focus in the embedded software space, I suspect you are more likely to have had to tolerate software development practices from 20 years ago. If you’ve read many books on Agile software development, DevOps or other modern practices, you may also have noticed that they almost all talk about software that targets a server or website, possibly a PC. But unless you’re reading a very different library to me, you’ll not have seen much talk about embedded software.

Focus on outcomes with OKRs

By Paul Blay in outcomes

November 17, 2020

If you’re interested in a way to tap into your team or companies creative potential, generating alignment and delivering tangible value, then OKRs should be your first port of call. I was fortunate enough to have met, and worked closely with Ragan McGill while I was at DisplayLink. Ragan had experienced both effective and underwhelming use of OKRs in his career and gave a set of training on how to ensure that they are well formed and deliver on their potential.

7 Practical Steps To Increase Accountability In Agile Teams

By Paul Blay in delivery, people

August 17, 2020

Individual and team accountability is critical for any high functioning team, I believe that this is often a concern for senior management, especially when considering an agile transformation, and can be difficult to attain. At the points in my career that I have seen senior management push back on the adoption of agile methodologies, the main areas of contention has been around the feeling of losing “control” over the delivery roadmap.

Complexity as a Software metric

By Paul Blay in metrics

July 20, 2020

I’ve never been completely sold on Cyclomatic Complexity as a metric, it maps to linearly independent paths through code which may be useful to get an indication on the level of testing an application needs, assuming code coverage is not available (another metric that needs to be treated with caution), but how much value is that? Most applications are multi threaded and do not run in a linear fashion, I’d argue that there’s considerably more value in measuring the readability of code in order to allow people to understand what it does and how to change it.

The ugly side of no surprises management

By Paul Blay in people

January 5, 2019

I get it… I think… “No Surprises” management is intended to ensure that people aren’t hiding bad news from their colleagues (let’s face it, usually their boss or some other superior) so that we’re not horribly surprised at the last minute that, for example, our project is 6 months late. Boom! Instant high-functioning team! Everyone feels safe and surprises never happen…. Or at least, god help you if they still do happen, because I was very clear that I don’t like surprises!