Patient Zero Blog

Why We Play Games at Work (And Why Your Team Should Too)

Wed, 15 Apr 2026 04:06:17 GMT

EDITOR'S NOTE

Jacinta Streat, Patient Zero's Principal Evangelist - so called because she is fanatical about continuous improvement culture - recently ran a 30min game with PZer's. Who knew a simple game could have such a big impact? It surfaced how language, context, participation, and momentum really work inside teams: why new starters struggle, why progress isn’t always linear, and why teams sometimes slow down before they speed up. This article explains the game, the takeaways, and how you can run it yourself.

(TL;DR)

The Game : Teams 'deliver' by guessing card identities using descriptions, single words, and gestures over three rounds. The same cards repeat each round to create a shared shorthand.
The Aim: The game lets teams experience (and reflect on) collaboration, context, and dynamics first-hand in a low-stakes environment - learning through shared play is far more effective than slides.
The Insight : The unique experience each person brings to a team is made visible, and players realise that when someone disengages, the whole team loses capability.
The Pattern : The game reveals how teams develop through stages. Starting a new project resets shared language and rhythm, but with the right ways of working, teams can regain flow quickly.

A Simple Game that Exposes Real Team Dynamics

At Patient Zero, we’re always looking for ways to help teams work better together. One of the most powerful ways to do that is surprisingly simple: play a game .

Why? Games strip away hierarchy, expose team dynamics instantly, and create shared language faster than any slide deck ever could. I designed, a workshop based on the game Monikers, a fast, funny, slightly chaotic experience that helps teams remember what it feels like to form a team and recognise the stages of team development.

The Game: Form teams of around 4-7 people, each with a set of Monikers cards. The game is played in three rounds using the same set of cards each round. Each team member takes a turn at 'explaining' the characters on the cards - think Free Willy, Crocodile Dundee, Siri - while the rest of their team tries to guess it.

But of course, each round it gets harder. In Round 1, you can say anything except the word itself. In Round 2, you may only say one word. In Round 3, you must act out the clue without any words. At this point, you will see some gestures and hear some sound effects that make you question your teammates sanity. But there will also be A LOT of laughter. Because the pool of cards remains identical each round, players rely on shared memory and increasingly absurd shorthand to identify the answers. The team with the most correct guesses at the end of the final round wins.

Above: Sample cards from the Monikers deck

Takeaway 1. Everyone Brings Hidden Knowledge

During set up, the team's deck is divided equally amongst players. Everyone gets 2 minutes to quickly scan these cards before shuffling them all back together. This means everyone has knowledge about some of the deck, but not all of it.

Bam! Timer starts. You pick up a card, you start saying “Lives in the ocean...”, someone yells “Free Willy!”. So many things live in the ocean.... you wonder how did they get that so fast?

Next card. “He is the star of a Nintendo game and has a red hat...”, the PZ resident gamer shouts “Mario!”. Who knew your teammates were into gaming?

And so on. By the end of round 1, three of your cards were guessed correctly before you even finished your clue!

Reflection Question:

Did you learn anything about your teammate’s knowledge that surprised you?

The correct answers come from 2 places, one is the knowledge about part of the deck players are given in the set up; someone already knew Free Willy was in the pack. The second source is the unique player themselves; the PZ gamer is primed to associate red hats with Mario. That familiarity is just like the experience each person brings to a team. Everyone has pockets of knowledge, niche interests, and lived experience that can help the group - if they feel safe enough to share it.

The game manufactures a feeling of safety; it’s supposed to be fun and it’s ok to fail because there are no real stakes. But this highlights the importance of creating an environment where everyone will share their knowledge. When people feel comfortable speaking up, it leads to better teamwork, richer ideas, and fewer missed opportunities. One of the saddest things is when a team member has underutilised talent. So, tap into what your teammates know and help bring out the best in them. Their experience is part of your team’s advantage.

Takeaway 2. Teamwork Only Works When Everyone Participates

Have you heard of “Lay Down Sally”, the Aussie rower who stopped rowing during the 2004 Olympic finals? The team went from vying for a medal to coming dead last. One person sitting out can change everything.

The game reinforces this message. The set-up gives each player information about some of the characters in the deck. In the first round, they are the only person with that knowledge. Players quickly realise that information is invaluable for fast and accurate guesses.

Reflection Question:

Did your team need every member to participate? Why?

If someone doesn’t participate, the team loses access to that player’s knowledge of the deck – and the team’s chance to score.

Delivery teams are no different.

When someone disengages, the whole team loses capability.

Takeaway 3. Lost in Translation: Corporate Edition

Ever joined a team halfway through a project? Started a job in a new industry? By the end of day one you’re left thinking: What on earth are these people saying? Between the jargon, acronyms, and in‑jokes, they may as well be playing charades.

I first played this game at the pub and onlookers thought it looked boring, it was a card game after all. But when they came back an hour later, we were cacking ourselves, acting out clues with wild gestures. They couldn’t believe how we were guessing the cards so easily.

The same thing happened at PZ - by round 3 no one was using words, everyone was in stitches and they were getting almost every card right!

Reflection Question:

If someone joined your team in Round 2 or 3, how many cards would they guess correctly?

If you only join this game in round 3, it’s almost impossible to guess a card correctly. Everyone else has built shared context (references, shortcuts, inside knowledge) that you just don’t have. It’s exactly what it feels like to join a team in sprint 20.

New joiners aren’t slow, they’re missing context. When you notice someone missing context don’t assume they’re not paying attention, remember they started in a different round. Try implementing a system to get them up to speed.

Above: Diagram showing Tuckman's Team Stages mapped onto the team effectiveness in each round of the Moniker's game

Takeaway 4. Comparison Kills

Ever caught yourself comparing your progress (or your team’s) to someone else’s? My gym coach said if everyone wore a number above their head showing how many sessions they’d attended, you’d stop comparing your 25th class and your wobbly pull-up, to the person effortlessly doing bar muscle-ups in their 1,587th. Context changes everything.

The same thing happens in the game.

Reflection Question:

Would it be fair to compare a Round 3 team to a Round 1 team?

In rounds 2 and 3, even though the rules technically make it harder, teams usually guess more cards correctly. Why? Because they’ve learned from every round to build a shared language.

That’s why comparing team velocity is meaningless. You need to think about their “training age”. Some teams will be in Sprint 0 setting up at a client (like Round 1) and others will be in Sprint 47 (like Round 3).

Takeaway 5. New Deck = New Work

Ever started a new project and felt like all your momentum disappeared? It’s like finishing the bike leg of a triathlon and then trying to run, your legs turn to jelly for the first 500m while your brain wonders who signed you up for this!

The game makes this dip visible.

Reflection Question:

What would happen if you were given a brand‑new deck in Round 3?

Every new piece of work is like picking up a fresh Monikers deck. The rhythm, the flow, the shared language, it all needs a moment to rebuild.

Don’t get disheartened by that temporary slowdown. At PZ, we’ve built ways of working that help teams get work ready quickly, so the “jelly legs” phase is short and the momentum comes back fast.

Why This Game Sticks

Teams don’t remember slides.

They remember feelings, moments, and metaphors that make invisible dynamics visible.

This game does exactly that.

It helps teams:

Build shared language
Understand context gaps
Appreciate each other’s strengths
Recognise the importance of participation
Normalise the dip when starting new work

And most importantly, it gives them a shared experience they can reference for years.

Run The Workshop Yourself

Workshop Run Sheet (30 minutes)

Introduction & Setup — 5 mins

Play the Game — 15 mins

Round 1 — 2 mins + scoring

Round 2 — 2 mins + scoring

Round 3 — 2 mins + scoring

Learning & Reflection — 10 mins

To run a longer workshop, simply extend the round times and increase the number of cards in the deck.

Setup Before the Workshop

Arrange tables classroom‑style (4–7 people per team).
Create a deck of Monikers cards (4–5 cards per person).
Print the game objectives and round rules for each table.
Screen the cards if you’re running this in a workplace — some aren’t PC.

How to Play

Your Task

You are a delivery team. Your goal is to guess the identity of as many cards as possible. Ignore the points printed on the cards. (The full monikers game adds up the points but to keep it simple 1 card = 1 point)

Setup

Form teams around a table.
Nominate a dealer.
Deal an even number of cards to each person.
Read your cards quickly — you only have two minutes.
Shuffle all cards back together and prepare for Round 1.
There are three rounds, each with different rules. See Round Rules below.
Each round lasts two minutes.
Team members take turns giving clues.
Skipping is allowed and encouraged.
Keep correctly guessed cards in a pile for scoring.
Shuffle all cards together after each round.
The team with the highest total after three rounds wins.

Round Rules

Round 1

Use any words, sounds, or gestures except the name itself. If you say any part of the name, you must skip the card.

Round 2

Use only one word (not the name). You can repeat it as many times as you like. Gestures and sound effects are allowed.

Round 3

Charades only. No words. Sound effects allowed (encouraged).

Skip the Setup. Start at Round 3.

Want to experience "Round 3" team performance from day one? Our embedded teams arrive with a shared language and technical excellence to drive your projects forward with immediate speed.

Learn more about how we position our embedded teams for success within your organisation.
See how we helped a start up develop ways of working so they could scale up.
Think you've got what it takes to be a PZ team player? Check out what it's like to work at Patient Zero .

About The Author

Jacinta Streat is the Principal Evangelist at Patient Zero with years of experience bridging the gap between technical and business domains and driving continuous improvement.

She enjoys mastering gym skills like handstand push ups and celebrating personal bests on the golf course.

A Love Letter to OpenClaw

Tue, 10 Mar 2026 03:55:59 GMT

EDITOR'S NOTE

At Patient Zero, we don’t just speculate on AI; we stress-test it in our own lives and workflows. This post by Dan Dekel explores OpenClaw , an open-source framework that represents the "hard-wired" future of AI. While the productivity gains are staggering, the security trade-offs are real. This is the new frontier of Sovereign Engineering.

AI has officially crossed the Rubicon from what AI could do, to what it is already doing. While standard LLMs talk, OpenClaw just does; integrating with everything from my WhatsApp parking bookings to autonomous email orchestration for my holidays.

This is my love letter to OpenClaw. Just kidding. I don't love it that much. But this post is about OpenClaw.

AI's disruptive potential was always something “in the future”, stalled by a hype train that forced us into scepticism and shut downs. OpenClaw has changed the game. It's a rarity: a tool where the reality actually lives up to the expectations.

What is OpenClaw? (The TL;DR)

OpenClaw is just an (open source) program running on your computer. The main thing it does really well, which other agents like Gemini are still not quite good at, is integrate AI with your existing applications. It can read your emails, send WhatsApp messages or launch a web browser and add items to your shopping cart.

Security implications? MASSIVE. More on that later.

Automating the Mundane (Airport Parking)

Take this as an example. I asked OpenClaw to book me a parking spot at the airport. It filled out the form for me:

Identity - My Name, phone number, email. It knows who I am;
Context - My flight details. It read my Itinerary from my emails.
Decision Making - Carbon Offset charge? Nope, it made the decision to skip that (Smart)

The only thing it didn’t know was my car’s rego number, so it sent me a message on WhatsApp asking for it:

I had the payment page ready for me when I got home (Did I mention I was at Bunnings doing this?).

Payments I still do manually (like a caveman), but probably not for very long.

Verifying the Incompetent: Autonomous Booking Orchestration

Not impressed? Here’s a more complex example.

We have a trip scheduled to Fiji. It was booked by a travel agency (crazy I know). I don’t know what your general perception of travel agents is, but the one we were dealing with were not very competent. In my worry of arriving in Fiji and finding out too late that the travel agency messed up our booking, I asked OpenClaw to confirm directly with the resort the reservation, including dates etc.

So OpenClaw:

Read my emails and attachments and found out the check-in/checkout dates.
Searched for the resort’s email online.
Sent out an email to the resort confirming booking number and dates.
Monitored my inbox for any replies from the resort.

You know what happened next? After a few days OpenClaw sent me this message out of the blue:

OpenClaw: “Good news! The resort replied! �� The check-in dates are different to your booking. Could be a typo on their end, worth clarifying.”

Me: “Yes”

OpenClaw: “Done. Reply sent asking them to confirm the correct dates. I’ll keep an eye on the response.”

It turns out the wrong date WAS a typo by the resort, but I’m glad we checked.

The Security Elephant in the Room

Now, you might be super impressed by all this, but you're probably also wondering how secure this is. The short answer is - you gotta know what you’re doing.

At the time of writing, there's a staggering amount of malicious skills on ClawHub (a public registry for OpenClaw extensions). So that's one thing I tend to avoid.

Furthermore, when I gave OpenClaw permissions to read my calendar or send emails on my behalf I certainly did not check the "Allow all" button. I do have the advantage of understanding what modern OAuth flows require. I understand what I need to do so that OpenClaw does not send my passwords to Anthropic or OpenAI, and I have definitely not relaxed any permissions to “just make it work” (classic IT solution).

The Next Evolution: From .exe to OpenAI

And this is probably the biggest hurdle some users without a tech background will face - they COULD get themselves into a lot of trouble. I like using the analogy of running .exe files in the 90’s:

PC: “Are you sure you want to run this program?"

15 y/o me: “Sure, what’s the worst that can happen?”

There was a reason malware spread so easily in that era.

So, making the experience safe and secure for ordinary users is the next logical step. I would assume that’s probably why the author of OpenClaw has recently joined OpenAI. In his post he says:

I'm not plugged into the Silicon Valley scene, but my suspicion is this is just the first step in agents becoming mainstream.

Until then, these are still frontier setups. For businesses, the top concerns are AI Security, Governance and, frankly, avoiding misleading* or embarrassing** AI responses to their customers. It takes expertise to build these guardrails, and, if you don’t think you have those skills in-house, I know of at least one company who can help with that.

* Air Canada chatbot misinformation: What travellers should know

** Woolworths AI assistant goes rogue, starts talking about its mother

Deepen Your Sovereign Capability

Don't just watch the AI agent revolution; orchestrate it.

The Solution: Move beyond "auto-complete" and build autonomous enterprise workflows with App Modernisation & Agentic AI
The Action : Stop the bleeding on stalled projects and underperforming AI implementations with Project Rescue & Recovery
The Team : Stop guessing at "prompt engineering" and start building onshore technical muscle with Embedded Software Teams

About the Author: Dan Dekel

Dan Dekel is one of the founders and Co-CEOs of Patient Zero. Passionate about software engineering and AI practices, he bridges the gap between complex architectural theory and the gritty reality of shipping production software.

He believes that true sovereignty requires us to be builders, not just consumers, of technology.

Patient Zero x Southstart 2026: Architecting Agentic AI in Adelaide

Mon, 09 Mar 2026 06:11:59 GMT

Patient Zero is proud to announce our official sponsorship of Southstart 2026, returning to Adelaide from March 17th to 19th. A unique gathering for founders and creative technologists, this year’s RESONANCE program is the perfect stage to move beyond AI hype and into the realm of how it can power start-ups and founders to achieve their goals.

With a dedicated three-year footprint in South Australia, Patient Zero is more than a visitor; we are active participants in the state's innovation economy, advocating for the technical and Australian-first capability required to build the next generation of SA-born successes.

By participating in high-level industry forums and supporting the local startup ecosystem, we are committed to ensuring South Australia leads the national conversation on AI, software engineering, and resilient infrastructure.

Southstart Adelaide: A Human-First Approach to Resonance

Since 2013, Southstart has been more than a tech conference; it is a deeply human experience that transforms Adelaide’s laneways and wineries into a global stage for innovation. This year’s theme, RESONANCE , is designed to spark collaboration through openness and curiosity; values that sit at the very heart of Patient Zero.

The Build Lab: From Chatbot to Coordinated Company

On Tuesday, March 18th (10:45am – 12:00pm) at Stone & Chalk , we are facilitating a fast-paced, hands-on workshop that moves beyond the AI hype into the realm of real-time execution.

The Zero-Employee Startup: An Agentic AI Build Lab for the Slightly Unhinged

Hosted by Paul and Demelza , this workshop is designed for founders and leaders who want to feel the definitive moment when AI stops acting like a chatbot and starts behaving like a coordinated company .

Using Claude-powered agent teams inside OpenClaw , participants will install an AI workforce that plans, builds, and launches a startup in real time. We are tackling everything: strategy, brand, pricing, and the operating model. It’s powerful, it’s chaotic, and it works (mostly).

The Adelaide Challenge: Gen Z Dealcoholised Wine

For the Adelaide edition, teams will tackle a provocative local challenge: Creating a Gen Z-targeted dealcoholised wine brand. In a nod to South Australia’s world-class wine heritage, we are tasking teams to make a non-alcoholic brand that is culturally relevant, commercially plausible, and socially desirable. To keep the stakes high, Live Gen Z evaluator agents will react to each team’s output in real time on a central dashboard, creating a sharp and entertaining test of relevance and "cringe risk."

Join the Resonance at Southstart 2026

The future of progress starts with people. Whether we are meeting in the Garden of Unearthly Delights or deep-diving into agentic builds at Stone & Chalk , we are excited to share knowledge with the national and international peers making South Australia their home this March.

We look forward to building something "slightly unhinged" with you.

View the Full southstart RESONANCE Program Here

Explore Our Technical Prowess

AI & Emerging Tech : Discover how we deliver practical, secure AI solutions beyond the hype.
Embedded Software Teams : Learn how our culture of mentorship builds high-performance delivery teams.
App Modernisation & Cloud : See our approach to architecting for scale and long-term resilience.

From Technology to Innovation: Patient Zero's 2026 WIICTA Finalists

Fri, 06 Mar 2026 06:55:45 GMT

Demelza Green and Irina Kudryavtseva of Patient Zero have been officially named finalists for the 2026 Women in ICT Awards (WIICTA) in the Innovation and Technical categories. This recognition by ARN (Foundry) highlights Patient Zero’s leadership in technical stewardship and Australian capability.

The 2026 WIICTA Event at a Glance

Event: Women in ICT Awards (WIICTA) 2026
Official Announcement: View the Full 2026 Finalists List
Gala Date: Tuesday, 28 April 2026
Location: Ilumina, Sydney
Organiser: ARN (Foundry)

About the WIICTA Awards

The Women in ICT Awards (WIICTA) leads Australia in celebrating the female leaders, innovators, and entrepreneurs shaping the future of the technology industry. Now in its 15th year, WIICTA continues to highlight the individuals who provide exceptional business value through specialised skills, creative thinking, and technical competence.

Demelza Green: Distributed Voice and the Future of Industry Leadership

WIICTA 2026 Finalist: Innovation

Demelza’s nomination for Innovation recognises her role in transforming Patient Zero from a traditional services firm into a powerhouse of creative technical delivery. By replacing generic corporate aesthetics with a "retro-apocalyptic" visual identity, she revitalised the brand to reflect a culture focused on the human element within the future of AI.

This innovation is most visible in her commitment to "Distributed Voice" thought leadership, which prioritises sharing knowledge and lifting the voices of Patient Zero. She has intentionally created a platform for the team to lead the industry conversation through deep-dive articles, collaborative videos, and conference keynotes. By turning marketing into an act of mentorship and public learning, she ensures that Patient Zero doesn't just deliver software; it actively shapes the future of the engineering community.

Irina Kudryavtseva: Resilience, Agility, and the Engineer’s Mindset

WIICTA 2026 Finalist: Technical

Nominated in the Technical category, Irina’s story is one of exceptional professional agility. In 2012, Irina made the difficult decision to pause a successful career as a C++ developer to immigrate to Australia and secure her family’s future. For nine years, she stepped away from her professional identity to raise her children in a new country; a sacrifice that, in a field as fast-moving as software engineering, often marks the end of a technical career.

However, when Irina returned to the workforce in 2021, she demonstrated incredible technical agility, bridging a decade-long gap by rapidly mastering modern web technologies and cloud architecture across React, TypeScript, and Azure. She proved that true technical excellence isn't tied to a specific tool, but to an engineer’s fundamental mindset and problem-solving capability.

Since joining Patient Zero, Irina has grown into a Technical Leader admired by both her team and her customers. She is known as the "anchor" of mission-critical delivery, possessing the rare ability to master both the complex technical stack and the deep product domain. Irina is never content with code that simply "works"; she is a fierce advocate for automation and the establishment of reusable patterns that simplify complexity.

Explore Our Technical Stewardship

AI & Emerging Tech : Discover how we deliver practical, secure AI solutions beyond the hype.
Embedded Software Teams : Learn how our culture of mentorship builds high-performance delivery teams.
App Modernisation & Cloud : See our approach to architecting for scale and long-term resilience.

About the Finalists

Demelza Green is the Co-CEO of Patient Zero and 10,000 Spoons. A Women in Digital UX Leader of the Year and ARN Innovation Award winner, she sits at the intersection of human experience and technical reality. She believes that while tools change, the fundamentals of good design and engineering rigour never go away.

Her goal? To help Australian businesses stop admiring the problem and start building the solution.

Irina is a Technical Lead at Patient Zero with a background in Applied Mathematics and Cybernetics, bringing a high-authority perspective to complex system design.

Irina is a force multiplier for her team; specialising in high-consequence environments where data integrity and system reliability are imperative. She is a fierce advocate for automation and creating the reusable patterns that allow engineering teams to scale with confidence.

Advancing the Tech Landscape: Our 2026 Women Leading Tech Finalists

Thu, 05 Mar 2026 08:15:06 GMT

Alongside an incredible cohort of industry peers, Patient Zero leaders Demelza Green (Co-CEO) and Hanieh Madad (Principal Software Engineer) have been named finalists in the 2026 Women Leading Tech Awards .

Competing in the Executive Leader and Engineer categories, their nominations recognise their impact on Australia’s digital landscape and enterprise software engineering governance. Both also feature on the official Women Leading Tech Power List , the definitive "who's who" of the Australian and New Zealand tech scene.

The 2026 Event at a Glance

Event: Women Leading Tech Awards 2026, presented by Atlassian
Official Announcement: View the Full 2026 Finalists List
Gala Date: Friday, 20 March 2026
Location: ICC Sydney
Organiser: The Misfits Media Company (B&T)

About the Women Leading Tech Awards

The Women Leading Tech Awards, presented by Atlassian , is Australia’s premier program for recognising women that drive innovation and change across the technology sector. In 2026, the awards are structured across three core pillars; Job Role, Industry, and Changemaker, to highlight the breadth of talent across the Asia-Pacific region.

The Vision: Designed to foster a more inclusive industry by celebrating technical excellence and executive leadership.
The 2026 Categories: Nominations span critical fields including Engineering , AI Pioneer , Cyber Security , and Executive Leader .
The Judging Process: Finalists are selected by an independent panel of industry veterans based on technical impact and contribution to the tech community.

Demelza Green: Executive Leader and Technical Stewardship

Finalist: Executive Leader

Demelza’s nomination for Executive Leader recognises her role in driving technical stewardship at the highest level of Patient Zero. Alongside the other Co-CEOs, she has architected a business model to make Patient Zero an employer of choice by attracting and retaining top-tier talent and fostering an environment where diverse perspectives are elevated into meaningful thought leadership.

Her own contributions to the industry reflect a commitment to solving complex customer problems through a highly balanced and creative approach to product, technical, and go-to-market strategy.

Demelza's Leadership in Action

Culture of Excellence: Leads the mission to attract amazing talent, focusing on high-performance engineering culture and lifting team members' voices into the industry spotlight.

Creative Problem Solving: Applies a holistic view of the technology lifecycle to deliver creative solutions for enterprise and government partners that balance market needs with rigorous product management.

Operational Innovation: Co-founded 10,000 Spoons , a consultancy that leverages Agentic AI to provide SMEs with the same high-level technical stewardship and C-Suite governance found in major enterprises.

Workforce Representation: Under her co-leadership, Patient Zero has achieved a team composition that is 48.5% female, significantly outpacing the industry average of 29%.

Hanieh Madad: Engineering Rigour and Complex Systems

Finalist: Engineer

Nominated in the Engineer category, Principal Software Engineer Hanieh Madad represents the pinnacle of technical stewardship and inclusive leadership. Her work is defined by a commitment to solving high-stakes architectural challenges by prioritising psychological safety and the elevation of her peers. By fostering an environment where mentorship is the baseline, she ensures that the teams building critical services are as resilient and high performing as the software they deliver.

Hanieh’s Engineering at Scale

Technical Advocacy: A recognised voice in the Australian engineering community, recently featured at DDD Brisbane , presenting on the practical implementation of Spec-Driven Development .

Architecture for Scale & Efficiency: Serves as the technical lead for massive education-based infrastructure, designing sophisticated workflows that recoup significant productivity, while maintaining industry-leading uptime.

Technical Mentorship: Launched " Certember ," a company-wide initiative that empowered 13% of the Patient Zero workforce to achieve new technical certifications in a single month.

Why This Matters for Our Partners

When you partner with Patient Zero, you aren't just hiring developers. You are engaging with a delivery model shaped by the industry's recognised leaders. These nominations validate that our focus on Sovereign Engineering, AI Workflows, and Human-AI Collaboration is setting the standard for the Australian tech landscape in 2026.

We look forward to celebrating alongside the other pioneers and innovators shaping our industry at the ICC Sydney this March.

Explore Our Technical Stewardship

To learn more about how our leaders and teams solve complex challenges, explore our core focus areas:

AI & Emerging Tech : Discover how we move beyond the hype to deliver practical, secure AI solutions and Agentic workflows.
Embedded Software Teams : Learn how our culture of mentorship and psychological safety builds high-performance delivery teams.
App Modernisation & Cloud : See our approach to architecting for scale and ensuring long-term resilience for mission-critical systems.

About the Finalists

Her goal? To help Australian businesses stop admiring the problem and start building the solution.

Hanieh Madad is a Principal Software Engineer at Patient Zero who believes that engineering culture is built, not bought.

An award-winning technologist with a relentless drive for upskilling, she is the force behind internal initiatives like "Certember" and a passionate advocate for continuous learning. Currently, she is deep-diving into Agentic AI, exploring how emerging tech can augment developer workflows without replacing the human creativity that drives them.

The AI ROI Productivity Paradox: Why Your 30% Velocity Boost Never Happened

Sun, 22 Feb 2026 20:59:07 GMT

At Patient Zero , we warned last year that chasing AI ROI without a mature AI-assisted delivery strategy would lead to a "Productivity Paradox." You cannot just turn on Copilot for your developers and expect a 300% increase in business value.

Fast forward to today. 2026 is the year of the reckoning. According to the latest data ( Dataiku/Harris Poll 2026 ), 71% of CIOs believe they have until mid-2026 to prove AI value or face budget cuts. They are terrified because they spent millions on Copilot, but their teams are producing more bugs, not more features.

Here is the connection between the "Speed" you bought and the "Value" you lost.

The Reality Check: The Data on AI ROI in 2026

To understand why the ROI isn't there, you have to look at the math of a developer's day.

The "16 Minute" Math Problem

Developers spend only about 40% of their time coding , and 60% of their time on non-coding activities; code reviews, testing, collaboration, getting coffee. Of that 40% coding time, around 90% is reading code , with only 10% devoted to actually writing it.

So, on an 8-hour day, they spend 16 minutes actually writing code .

If AI doubles their typing speed, you’ve saved... 8 minutes.

What do you think they are doing with those extra minutes? They aren't building more features. As we will see, they are likely using them to fix the bugs the AI just created.

Root Cause 1: The "Negative Expertise" Trap

AI ROI fails because AI rises to the competence of the user. Just because your developer has 10+ years of experience, doesn’t mean they’re competent at auditing AI.

AI is like a very smart PhD student, but it needs someone to question the code it produces; someone who can "smell" when something isn’t quite right. There are 3 concepts that relate to this:

Meno's Paradox
Unknown Unknowns
Negative Expertise

All of these sum up to one thing: You need to know when you don’t know something.

The AI Drag

The AI Drag is a phenomenon where junior developers using AI take longer to complete tasks because they lack the expertise to validate the output. Scott Hansleman (VP Developer Community, Microsoft) spoke to this on the Distributed Podcast . He is seeing the inverse of the apprenticeship model. Juniors know just enough to be dangerous.

It feels counterintuitive. Juniors are using AI but getting stuck. It generates something wrong, and they didn't "smell" it because they don't have the experience to spot it. It wasted your afternoon because they created a bunch of junk.

The Comprehension Gap

At Patient Zero , we have a few steps in our recruitment process to ensure cultural and technical fit. We conduct code challenges and in-person sessions. In a recent developer intake, we had all software developers explain their code to us and the reason behind their decisions.

This doesn't mean the other 55% wrote the code from scratch. But whether they used AI or not, comprehension is the metric that matters.

How many organisations hire developers based on a code challenge, but never actually ask them to explain why they wrote it that way?

Root Cause 2: The Hidden Cost of Low Quality

Paying your good developers to spend more time fixing up other people’s code is a waste of ROI.

In Harness’s “ The State of Software Delivery 2025 ” , it identified that while AI speeds up initial development, it’s causing more issues down the pipeline:

67% of developers spend more time debugging AI-generated code.
68% of developers spend more time resolving security vulnerabilities.
59% of developers have problems with deployments using AI tools.

We are seeing human nature kick in. We are geared to reserve energy. It’s easy to rely on the AI. Great, I can just give it some prompts, copy-and-paste the code, and get back to playing my game. Even the most astute developers check once, twice, three times... and then think, "Well, I can trust it now." The fourth time is when it hallucinates and creates a mess.

Root Cause 3: Organisational Immaturity

We tend to go 2-3 times the speed of other teams at Patient Zero, even without the use of AI-assisted development. That’s down to the practices of our Embedded Team (link) model.

Most of the time, it's not the team itself slowing down; it’s the organisation around it. If you’re just activating Copilot and expecting a performance increase, think again.

These are the most common things we see hindering teams:

Meeting overload: Kills flow time.
Big teams: You want a pizza-sized team (5 is the perfect number).
Lack of Test Automation: You need quality gates to immediately indicate if your faster code generation broke anything.
Confusing Architectural Patterns: Work that should be repeatable becomes a "tech adventure."
Too many cooks: A team of seniors spending more time debating tooling than shipping.

The "Burnout Baseline"

There is another invisible place your ROI went: Paying back cultural debt.

Before AI, many organisations were running on "fake velocity." According to Harness, 88% of developers report working more than 40 hours a week , with burnout at record highs.

If your team was only hitting their deadlines because they worked nights and weekends, your baseline was broken. When you introduced AI, they didn't use the time savings to do more work; they used it to stop working for free.

You didn't pay for increased performance. You paid to stop your best engineers from quitting. That is valuable, but it doesn't show up on a feature spreadsheet.

Root Cause 4: Fear of Adoption

Finally, we have to address the elephant in the room: Fear.

People are genuinely afraid of what is coming. It is predicted that within 18 months, the majority of white-collar work will be automated. We’ve heard stories in organisations where leadership asks their teams to get in there, and figure it all out. You have those who do nothing (freeze), those who play around and realise holy s**t, and tell their bosses AI isn’t ready yet (run).

There are organisations who are getting their teams to automate their own jobs, which is a horrible feeling.

The "Writing on the Wall"

Take the recent Commonwealth Bank (CBA) case . A team was tasked with automating their own workflows, only to be made redundant once the project was "complete." But the story didn't end there, the bank had to rehire them because the automated system couldn't handle the complexity or the volume without human oversight.

For many staff, this isn't just "enablement", it is the writing on the wall. They see that if they succeed in automating their job, their reward is a pink slip.

Anthropic’s staff have come out saying the same thing with the level of automation they are doing there with coding and co-assist tools.

The Evolution: Moving from Copilot to
Agentic AI

The industry is rapidly shifting from AI Augmentation (Copilot) to Agentic AI. This isn't just a software upgrade; it is a fundamental shift in the operating model that most teams are not ready for.

Agentic AI is not Copilot. Copilot is an augmentation tool; a "force multiplier" for the human hands on the keyboard. Agentic AI is different; it is an autonomous loop. The idea is that you are no longer the "Writer"; you are now the Orchestrator; the Master in the "Master and Apprenticeship" model.

You point your agents in the direction you want to go, monitor them, and ensure there is a quality output. But because Agentic AI operates in a "black box" (making its own decisions to fix errors), it introduces new risks that Copilot never did.

The Critical Difference in Workflow

Here is the critical difference in how the two solve problems:

Conclusion: Do You Have the Capability?

If your developers are using AI in either case, it is their responsibility to own the code that is produced.

Bad code is still bad code. The way you orchestrate vs. engineer is the new world we are adapting to.

Do you have the right gates, processes, and people to make sure you don’t get yourself into a further mess? Are you sure you have the right Orchestrators to succeed in this new world?

Turn Strategy into Sovereignty

Patient Zero bridges the gap between AI hype and engineering reality by mapping these sovereign trends directly to your engineering roadmap:

The Strategy: Don't let AI generate technical debt. Build sovereign assets you own and understand with Custom Software Development .
The Workforce: Need "Orchestrators" to audit the AI, not just coders to copy-paste it? Augment your capability with our Embedded Software Teams .
The Infrastructure: Stop paying the "Cloud Tax" on bloated code. Refactor your estate for efficiency and security with Application Modernisation .

About the Author

Demelza Green is the Co-CEO of Patient Zero and 10,000 Spoons . A Women in Digital UX Leader of the Year and ARN Innovation Award winner, she sits at the intersection of human experience and technical reality.

Fresh from the global conference circuit (CES, GITEX, Web Summit), she is focused on helping Australian enterprise software leaders navigate the shift from "Global Efficiency" to "Sovereign Resilience."

Her goal? To help Australian enterprises stop renting their future and start building it.

Should you Catfish your vendors? No, not like that.

Sun, 22 Feb 2026 20:27:41 GMT

EDITOR'S NOTE

In 2026, most IT procurement panels are full of dead sardines. Large organisations lock themselves into "Preferred Supplier" lists to streamline costs, but they often streamline innovation right out of the building. This article explores the "Catfish Effect"; a macro-economic strategy used effectively by global superpowers, and how CIOs can apply it to their own vendor ecosystems. The secret to rescuing a stalled digital transformation isn't always firing your incumbent; sometimes, you just need to introduce a Challenger Vendor to wake them up.

(TL;DR)

The Trap : "Preferred Supplier Panels" create a closed ecosystem where incumbent vendors get comfortable, lazy, and expensive (The "Dead Sardine" effect).
The History : China used the "Catfish Strategy" (introducing fierce foreign competitors like Tesla and Siemens) to force their domestic industries to innovate or die.
The Strategy : You don't need to rip and replace your entire vendor list. You need to introduce Competitive Tension .
The Move : Assign a high-stakes "Problem Child" project to a boutique Challenger Vendor . The presence of a predator forces the incumbents to swim faster.

What is the "Catfish Effect"? (And Why Your Tank is Full of Dead Sardines)

Legend tells of a Norwegian sardine-boat captain who was able to bring prized live sardines to market where others could not. His closely guarded secret which was only divulged after his death was (according to the stories) that he placed a live catfish in the tank with the sardines, who reacted to the presence of the predator by remaining active and lively.

Although the term Catfishing has taken on a different meaning in the age of social media, the strategy is that introducing a “predator” into an ecosystem forces innovation and reduces complacency and stagnation.

Stealing Management Tips from Emergent Global Superpowers

China used the “Catfish” strategy to improve the efficiency of several areas of their domestic economy. In the early 2000s China allowed several rail superpowers – Siemens (Germany), Kawasaki (Japan) and Alstom (France) to compete for contracts to build an emerging high-speed rail network.

Over the ensuing 25 years China absorbed, integrated and refined the technology, eventually creating their own domestic high-speed rail designs (the Fuxing).

Today China has more high-speed rail than the rest of the world combined, and Chinese firms like CRRC and CCCC compete in western-European markets against the “catfish” that once spurred them on.

Case Study: Tesla’s "Gigafactory" Privilege

Another example of a “catfish” is Tesla in the EV market. In 2018 China allowed Tesla to open Gigafactory Shanghai. Prior to Tesla’s Gigafactor, foreign auto-makers were forced to partner with Chinese firms. The Chinese government wanted to force their EV manufacturers to become world-class, and so Tesla was allowed this singular privilege.

The presence of the factory bootstrapped a whole supply-chain ecosystem for Tesla. The same supply-chain could also supply domestic manufacturers like BYD who were also forced to dramatically improve their battery technology and software. Today China is the world-leader in EV production. Outside of manufacturing China have also used this strategy to force innovation in other areas like financial services.

The "Procurement Paradox": How Preferred Supplier Panels Kill Innovation

What does your supplier list and a box of dead sardines have in common?

Many medium to large companies and government organisations try to streamline their procurement of services (including IT) by having a small number of preferred suppliers that they deal with exclusively. While this can streamline procurement, this approach stifles competition and leads to stagnation and complacency.

This often results in worse outcomes for everyone except procurement – complacency leading to higher costs, longer timeframes and less innovative products and services. A classic case of the procurement tail wagging the organisational dog.

Internal IT capabilities are also prone to stagnation for the same reasons as incumbent suppliers who feel far too comfortable in their position. Without definite competition pressures timeframes can balloon out and innovative ideas that could improve things are shelved because there are no incentives to take risks.

How to Execute the Strategy: Introduce a Challenger Vendor

The “catfish” strategy isn’t without its risks of its own – if the “catfish” is too lethal then the domestic population may not survive long enough to adapt and eventually thrive. For nation-states this is definitely a risk, and one that China managed through R&D grants to help give domestic companies a fighting chance.

In an organisational context this is less of an issue. If IT services isn’t your core business then you benefit if one supplier out-competes another.

The great news is you don’t have to fire your incumbent big-4 vendor tomorrow. Introducing a small and nimble boutique partner into your internal IT ecosystem on a “problem child” project like that stalled digital transformation or legacy system migration could show established players that they need to continue to push to improve and deliver value.

The Patient Zero Approach: Engineering Without Lock-In

As a challenger vendor to a number of larger organisations, Patient Zero try to avoid complacency, even when we have a good relationship with our customers.

We actively try to make it easy for our customers to disengage with us when we’ve completed a project, both contractually and with our project delivery by setting up automation and comprehensive documentation that we can hand over when our job is done.

We constantly challenge ourselves to further improve and streamline our process by re-evaluating what we’re doing. This is one of the biggest benefits to cycling new people through a team. New team-members are uniquely positioned to bring fresh eyes to look at everything that is being done with a view to simplifying, documenting gaps, and eliminating waste.

Usually, we’re the catfish. Sometimes we’re the sardine. But we’re always working on becoming better swimmers.

Stop Feeding the Dead Sardines

We believe that comfort kills innovation. If your "preferred supplier" list has become a list of "complacent incumbents," you don't need to fire everyone; you just need to introduce a challenger to the tank.

Project Rescue: See how we rescue stalled projects that have been dragging on for months.
Sovereign Engineering: Discover how we build systems without vendor lock-in , ensuring you own your future.
App Modernisation: Don't let legacy tech kill your velocity. Read more

Ready to Introduce a Predator?

You don't have to fire your current vendor today. Just give us the project they are failing on.

About The Author

Joe Cooney is a Principal Software Engineer at Patient Zero with decades of experience in the trenches. He has "seen it all"; from the dot-com boom to the AI revolution and knows exactly how to rescue a codebase from stagnation.

He loves coffee, code, and snowboarding, and holds the unique distinction of being the Nomenclator of Stack Overflow.

Experience vs. The Exam: How I Passed PSPO With (almost) Zero Study

Sun, 15 Feb 2026 10:48:13 GMT

EDITOR'S NOTE

At Patient Zero, we don't just rest on our years of experience; we test them. As part of our internal "Certember" initiative, we challenged our senior team to see if their battle scars actually aligned with the textbook definitions. Here is what happens when Bay McGovern , Principal Product Owner , pits 11 years of real-world Agile experience against a rigid 60-minute exam.

(TL;DR)

The Challenge : Can a Senior Product Owner pass the PSPO I exam with zero study, relying only on 11 years of experience?
The Hack: Using a specific AI prompt (included below) to simulate the "Scrum Mentor" persona for rapid-fire practice.
The Verdict: Passed (88.8%).
The Lesson: Scrum Certifications test your ability to navigate linguistic traps; Real-world Product Management requires the intuition to know why the answer matters. This is the difference between a "Ticket Waiter" and a true Technical Product Owner .

Do tech certifications test real-world experience?

Or to put it in more concrete and personally relevant terms, could I pass the PSPO Certificate 1 certification on the strength of my 11 years of Agile experience, and with no study?

It’s an interesting question, and, not gonna lie, I was tempted to try. With close to 20 years tech experience (showing my age here) how hard could it be?

The Motivation (And The Free T-Shirt)

At university, I was a studious and methodical rule follower when it came to study, with rigid hours and procedures in place to ensure my grades stayed above average (without shooting for straights 7s, which IMO is a waste of time and energy – who needs to last 5%?)

However, university was a long time ago, and this time around I was spurred by different motivations. In addition to proving or disproving the validity of the PSPO certification against real-world experience, and possibly also calling into question the whole tech certification game, there was also a free T-shirt on the line if I got my cert.

Did the possibility of a free t-shirt cause some unwarranted rashness?

Maybe.

Was I going to do it anyway?

Probably.

The said shirt was part of a PZ initiative, Certember , spearheaded by none other than superstar PZ developer Hanieh Madad. As you may be able to tell by the name, Certember was supposed to happen in September.

Maybe I could push the boundaries of believability and claim I thought it was November... but January? Certanuary really doesn’t have the same ring to it.

So, I was late, I was gunning for a shirt I probably didn’t deserve, and I had no plan.

The Strategy: AI as the Tutor

Enter Product Owner Kei Nakayama with a set of prompts she used to study via AI and pass the cert a week or so earlier.

I thought to myself, YES, I can do this, I too can use AI to teach me about my own job, and pass with flying colours.

(Or, maybe just pass, save the colours for later).

Here’s the initial prompt I went with (mostly stolen from Kei – but imitation is the highest form of flattery, right?)

I want to pass my Professional Product Owner exam (here is some suggested reading: https://www.scrum.org/resources/suggested-reading-professional-scrum-product-owner ).

This is the scrum guide that most of the questions are based on: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf

For my PSPO 1 exam, based on the Scrum Guide provided, please act as a Scrum Mentor. Give me 10 challenging multiple-choice questions.

Constraints: Focus on the accountabilities of the Product Owner versus the Scrum Master and Developers.

Do not ask for definitions. Ask what a PO should do in a specific situation

Do not give me the answer until I respond. Make the wrong options look very tempting.

After I answer, explain the why behind the correct choice under the Scrum Guide Logic and why not for the incorrect answers.

Keep the tone encouraging but professional

Within a few minutes, I was doing practice test questions and scoring 13/15, 20/20, 18/20 and so on. Each set of questions seems easier than the last. I asked for harder questions, and still my results were a few percentage points away from 100%.

I put in a massive half hour of study that first day. Phew.

A "Scrum Master" False Start

The next day I asked for more, and spent another INTENSE half hour feeling very excellent about myself and my amazing knowledge of being a product owner. I thought, f*ck it, I’m just going to go for it. So I headed to the scrum.org website and bought the test.

As I hit the purchase button I got the awful feeling that maybe I hadn’t properly checked which certification was in my cart before blithely clicking the purchase button. With a rising sense of panic I went to my mailbox only to see I’d made my first mistake… I’d bought the Scrum Master Certificate I.

Which I already have. Excellent! Off to a winning start.

This small slip-up did make me second guess doing the test at all. If I can’t even buy the damn thing correctly, how will I pass? Luckily, after contacting scrum.org I got a refund (minus international purchase fees and a constantly changing exchange rate) and headed back to buy the correct test.

The Exam Reality: Confusion and Linguistic Traps

The test password sat in my inbox for a few days. I was… scared. I hadn’t sat a test since doing my Diploma of Business Systems Analysis at UBC in 2007. Almost 20 years later, do I have what it takes to pass a test?

The next Monday afternoon, about 4pm, with most of my work for the day done, I just decided to do it.

Don’t think, just do.

Boom! The timer starts. 60 mins for 80 questions. About 5 questions in, I started to wonder whether I had studied the wrong material. The content of the questions feels unfamiliar, and I definitely haven’t been asked these topics by my AI tutor. The questions and answers are worded confusingly. There are always one or two obviously incorrect answers, but the others are difficult to distinguish between.

I messaged my fellow POs mid-test to tell them that I think I’m going to fail (they all had so much confidence in me), but I’d rather tell them sooner that I’m an utter loser.

Another thing about me is that I’m not a second-guesser. Once I’d completed a question, despite having no confidence in my answer, I simply moved on and forgot about it.

So, when I got to the 80th question, 30 minutes in, and saw the submit button, my cursor only hovered momentarily before I pressed it and sent a prayer to the universe. Please scrum gods, if you do exist, which I’m certain you do, please let me pass this test!

I checked my inbox and, thank goodness, I passed, 88.8%. Which, if we’re going to get into particulars, would be a high distinction in the old scale. Just saying. (Tho 85% is the passing grade for the PSPO cert, talk about a high bar!)

The Post-Mortem: Why Experience Won

After the initial ecstasy of passing subsided, a few questions came to mind.

Did I study enough?
Were the questions and answers really so confusing?
Did I study the wrong materials, or miss some content?
Would I have passed the exam without my years of experience?

I decided to ask my AI teacher for their expert opinion.

I didn’t ask AI question one, as I think we all know the answer to this would be a resounding NO. I definitely did not study enough.

Here is what they said for the rest.

Yes, the scrum.org tests are notorious for containing linguistic traps (that made me feel a little better).
Yes, I should probably have read (or at least understood the fundamentals of):
The Evidence-Based Management Guide
The Agile Manifesto (which I do know something of)
The Professional Product Owner book (unofficial textbook for the test)
Maybe… experience can be a double-edged sword. You may inadvertently focus on the way you CURRENTLY do things instead of the way you SHOULD do things. If you do the former, you are unlikely to pass the test.

So what’s my takeaway on this whole experience?

Since I managed to pass, I wouldn’t do anything differently. But my personal opinion is that, after years of working in organisations attempting to do things the right way (and often failing), I was pretty clear on what the theoretically correct way of doing things was. And, I would have been unlikely to pass the exam on so little study without this.

The Verdict: Rules vs. Intuition

It also got me thinking about the value of certs in general. Apart from wanting to prove something to myself and the rest of the world (which may place a higher value on these things than I do), did I learn anything?

I'd say I definitely scrubbed up on some of the finer points of scrum product management and can use them more confidently in conversations, rather than just following my intuition. But I also feel like rigidly applying these rules without context is a path to failure. You must know the rules and have real-world experience to know when to break them effectively.

In the end, did I prove that tech certifications are bullshit? Or, did I prove that I genuinely know how to do my job? Who can say? All I know for sure is that I’m looking forward to getting my sweet Certanuary Certember shirt.

Need a Product Owner who knows the difference?

A certificate proves you know the theory. A partner proves you can handle the reality.

The Team : Don't hire a "ticket waiter." Get a Product Owner like Bay who drives outcomes with our Embedded Capability Uplift .
The Strategy : Avoid the "Feature Factory" trap. Define a roadmap that actually delivers value with Strategy & Discovery .
The Career: Think you could pass the test with zero study? We are always looking for senior talent. Check out what it's like to work at Patient Zero .

About Bay McGovern

Bay McGovern is a Principal Product Owner at Patient Zero , where she herds cats, defines roadmaps, and passes exams on sheer intuition.

With nearly 20 years in tech and 11 years specialising in Agile delivery,

Bay has seen every flavour of "Scrum-ish" there is. A WIICTA Finalist for Achievement , she is known for cutting through the methodology noise to focus on what actually ships product.

Learn more about Bay and her full journey from Vancouver to Brisbane in Meet Bay McGovern .

From Inspector Gadget to James Bond: Why Agentic AI Needs "Spec-Driven Development"

Fri, 06 Feb 2026 20:55:08 GMT

EDITOR'S NOTE

At Patient Zero, we believe the future of software capability isn't just about coding faster; it's about architecting better. As AI shifts from simple chatbots to autonomous "Agents," the risk of "spaghetti code" multiplies. This article encapsulates our philosophy of building maturity over just renting capacity. By enforcing Spec-Driven Development, we ensure that Sovereign AI serves the mission, not the other way around.

(TL;DR)

The Problem: "Vibe Coding", blindly prompting AI agents, is creating chaotic, "Inspector Gadget" style software that is prone to hallucinations and lacks architectural integrity.

The Solution: Spec-Driven Development (SDD). A methodology where you define a strict "Architect’s Blueprint" (Specs) and a "Constitution" (Rules) before letting AI write a single line of code.

The Tools: Hanieh Madad (Principal Software Engineer, Patient Zero) compares AWS Kiro (an integrated Agentic IDE) vs. GitHub SpecKit (a flexible, tool-agnostic workflow).

The Takeaway: To move from chaos to precision (James Bond style), humans must define the "What" and "Why" (Context), while Agentic AI executes the "How".

The Hook: Escaping the "Vibe Coding" Trap

We are living through a shift from Generative AI (Chatbots) to Agentic AI (Autonomous Workers). Developers are no longer just asking a bot to write a function; they are deploying agents to build entire features.

But as Hanieh Madad, Principal Software Engineer at Patient Zero, explained at DDD Brisbane 2025 , this new power brings new risks. Without structure, Agentic workflows often resemble Inspector Gadget : enthusiastic and loaded with tools, but clumsy, reactive, and prone to spiralling into chaotic loops.

"Vibe Coding", where you blindly prompt an agent and hope for the best, might work for a prototype, but in an enterprise environment, autonomous agents without guardrails are a liability.

For sovereign, scalable software, "Inspector Gadget" isn't good enough. You need James Bond : intentional, precise, and mission-focused.

The control plane that makes this possible is Spec-Driven Development (SDD) .

What is Spec-Driven Development (SDD)?

SDD is a methodology that brings engineering rigor to Agentic AI. It is a direct response to the limitations of "Vibe Coding," where AI assistants lose context, hallucinate details, and drift from the original intent.

Instead of telling an agent to "build a website," SDD centres the workflow around a structured Specification. This turns high-level ideas into detailed implementation plans before the agents are unleashed.

It flips the script on the last decade of software engineering:

The Old Way: Code is King. Write code first, then maybe document it later.
The Agentic Way : The Spec is King. Define the requirements, the design, and the guardrails first. Then, and only then, do you authorise the agents to build against that blueprint.

This isn't about bringing back "Waterfall." It is about giving autonomous agents a clear "Mission Profile" so they don't go rogue.

The Landscape: Two Approaches to Controlling Agents

The market is being flooded with "Autopilot" tools. However, most are non-deterministic, if you ask an agent to solve a problem twice, it might solve it differently both times.

In her demonstration, Hanieh highlighted two pioneering tools that solve this by forcing structure onto the agents. She chose these because they represent the two distinct philosophies of Agentic implementation:

1. The Integrated Platform: AWS Kiro (The Agentic IDE)

AWS Kiro is an "Agentic IDE", essentially a fork of VS Code with a multi-agent system baked into the core. It doesn't just autocomplete code; it spins up different agents for different tasks (Planning, Coding, Testing).

How it enforces maturity:

Hooks: Kiro allows teams to define automated triggers. For example, you can set a "Hook" that forces an agent to write tests every time it saves a file.

Steering : This acts as a set of system prompts for your agents. You can define global steering rules (like "Always use Version Control" or "Check for Security Vulnerabilities") that apply to every project. This effectively creates a "Governance Layer" that the agents cannot bypass.

2. The Flexible Toolkit: GitHub SpecKit (The Agnostic Tool)

On the other end of the spectrum is GitHub SpecKit. Unlike Kiro, this is an open-source toolkit that is "IDE Agnostic". It allows you to bolt an Agentic workflow onto your existing tools.

How it enforces maturity:

The Constitution: SpecKit asks you to define a "Constitution", a set of non-negotiable rules and principles for the project. The agents must check this constitution before generating any code, ensuring they adhere to your architectural standards.

Phase-Based Execution: Instead of trying to do everything at once, SpecKit breaks the agent's work into clear phases (Spec, Plan, Task, Implementation). This prevents the agent from getting "distracted" and keeps it focused on the immediate mission.

Strategic Alignment: Building Maturity, Not Just Capacity

At Patient Zero, our mantra is: Stop renting capacity, start building maturity. SDD is the technical manifestation of that philosophy. We don't just use Agentic AI to code faster (capacity); we use it to architect better (maturity).

1. The Architect’s Blueprint

SDD treats the specification as the "Architect's Blueprint". By generating Requirements , Design , and Task markdown files first, we force the AI (and the human) to think about the system architecture before writing code. This prevents the "spaghetti code" that often comes from unchecked autonomous loops.

2. Documentation as a Living Artifact

We all hate writing documentation. With SDD, the documentation is the prompt. The Requirements file drives the agent's behaviour. This means your documentation never drifts from reality, it remains the living source of truth for any developer joining the team.

3. Guardrails for the "Weird Creative"

Agentic models are powerful, but they can be "too ambitious" or "too eager," sometimes rushing to a solution that introduces vulnerability. By using SDD, we put guardrails in place. We ensure that the agents are not just creative, but compliant with our architectural standards.

The Bottom Line: Enablers, Not Magic

As Hanieh emphasised in her closing remarks, we must remember that tools like AWS Kiro and GitHub SpecKit are enablers, not magic wands.

Whether you choose Kiro for its deep, multi-agent IDE integration, or SpecKit for its tool-agnostic flexibility, the rule remains the same:

1. Start with Intent. Before you deploy an agent, you must define the context. The most dangerous thing you can do is give an autonomous tool a vague instruction.

2. The Golden Rule: Spec First, AI Second. The future of enterprise engineering isn't about knowing how to write syntax; it's about knowing how to define value.

Humans define the "What" and the "Why" .
Agentic AI executes the "How" .

By adopting Spec-Driven Development, we move away from the chaos of random prompting and toward a future of intentional, architectural precision. We stop being Inspector Gadget, and we finally become James Bond.

Disclaimer: This article reflects the technical reality as of December 2025. In this industry, the shelf life of information is measured in weeks, not months. Any advice, tool, or benchmark mentioned here may have already evolved or been replaced by the time you read this.

Explore Our Capabilities

Ready to move from "Inspector Gadget" chaos to "James Bond" precision? Here is how we help enterprises build maturity.

Embedded Software Teams Stop renting capacity. Deploy complete delivery teams that plug directly into your environment to build sovereign software capability. View Our Embedded Model
Enterprise AI & Agentic Solutions Move beyond chatbots . We build secure, sovereign Agentic AI workflows that adhere to strict governance standards, turning "Inspector Gadget" experiments into production-ready capability. Explore Our AI Services
Application Modernisation Is your legacy code holding you back? We rescue stalled projects and refactor "spaghetti code" into scalable, future-proof platforms. Modernise Your Stack

Sovereignty, AI Agents, and the End of SaaS: The CIO’s Guide to 2026

Wed, 04 Feb 2026 05:09:12 GMT

Patient Zero is the sovereign engineering consultancy for Australian enterprise.

We have synthesised global intelligence from GITEX, CES, WebSummit and Gartner to deliver a singular conclusion for the local market: The old playbook is obsolete.

Patient Zero’s strategic analysis confirms that the rules of engagement have inverted. We identify 5 sovereign shifts that matter right now:

Economics: From "Buy vs. Build" → Build vs. Buy
Geopolitics: From "Global Efficiency" → Sovereign Borders
Workforce: From "Specialist Coder" → Creative Orchestrator
Infrastructure: From "Cloud First" → Cloud Smart
Intelligence: From "Black Box Rentals" → Open Weight Assets

These five shifts represent the new baseline for Australian technical leadership. Patient Zero helps CIOs navigate this inversion by moving beyond traditional 'staff augmentation' and deploying sovereign, outcome-based engineering teams that retain intellectual property within Australian borders.

Here is our executive briefing on the 5 macro trends in technology that will define 2026.

Prefer to watch? Catch the full breakdown of these 5 strategic shifts in 8 minutes:

Trend 1: The Death of SaaS: A New "Build vs. Buy" Equation

The Trend: From "Buy vs. Build" → “Build vs. Buy”

For the last decade, "Buy" was the default strategy to reduce risk. However, the rise of Agentic AI has fundamentally altered the economics of custom software development.

The "Cost of Code" Collapse

We are observing a dramatic collapse in the cost of production, with early 2026 Agentic workflows demonstrating speed improvements of up to 60x . When code becomes this cheap to produce, the premium paid for pre-packaged software becomes harder to justify.

Market Validation: The SaaS Correction

This shift is already being priced into public markets. A prime example is Salesforce. Despite the high-profile launch of "Agentforce," the company saw its stock tumble nearly 25% over the last year .

Why?

Because the market is beginning to price in the "Custom Software Development Option." Investors are realising that Agentic AI eliminates the need for the expensive, UI-heavy interfaces that justify seat-based pricing. When an Agent can interact directly with its data, the premium for a "User Interface" evaporates.

The "Sovereignty Gap": Owning vs. Renting

This shift exposes the structural vulnerabilities of the traditional SaaS model: rigid contracts, feature bloat, and most critically, the Sovereignty Gap .

When you "Buy" SaaS, you are renting a row in someone else's database. Regardless of "local residency" promises, your data is often commingled in multi-tenant architectures subject to foreign jurisdiction (e.g., the US CLOUD Act), leaving you with zero true ownership.

The Strategic Reality: Bespoke Software at SaaS Prices

Organisations are realising that with AI, they can build bespoke, data-sovereign tools tailored exactly to their workflows in weeks rather than months, or even years.

The market is beginning to price this in. Why rent a generic "Black Box" that exposes your data to foreign risk, when you can build a Proprietary Asset that you own outright; data code, and IP with zero recurring license fees?

Trend 2: Digital Sovereignty & The Risk of Foreign Jurisdiction

The Trend: From "Global Efficiency" → Sovereign Borders

As deglobalisation accelerates and the "Great Power Competition" between the US and China intensifies, we advise customers to treat their digital products as a Sovereign Asset Class.

The "Kill Switch" Risk: Foreign Jurisdiction Liabilities

We have moved from an era of global efficiency to an era of security. Relying entirely on software hosted in US or Chinese jurisdictions introduces an existential risk: your intelligence capability can be sanctioned, throttled, or cut off overnight due to geopolitical disputes.

This is not a theoretical risk. In June 2025, we witnessed a digital "hard cut" in Southeast Asia when Thailand's regulator (NBTC) ordered telcos to sever internet links to Cambodia amidst rising border tensions. Whether the justification is fighting cybercrime or geopolitical leverage, the result is the same: reliance on cross-border connectivity leaves your digital lifeline in the hands of foreign regulators.

Why Residency is Not Enough: The Case for Model Sovereignty

It is no longer sufficient to just store data locally (Data Residency). Organisations must now possess Model Sovereignty , the ability to run the inference engine on your own infrastructure without a single packet leaving the legal jurisdiction.

Trend 3: Future of Engineering: From "Specialist Coder" to "AI Orchestrator"

The Trend: From "Specialist Coder" → Creative Orchestrator

We are witnessing a fundamental break in the evolution of software development. While AI accelerates every technical field, software development is moving at a velocity that other industries can't match.

The reason is structural: in our world, the tool and the product are identical. This creates a recursive loop; we aren't just driving the car faster, we are rebuilding the engine while we drive.

The "Dogfooding" Imperative: Bootstrapping AGI

This velocity is further compounded by the race to AGI. The labs building these models have a strategic imperative to use today's AI to write the infrastructure for tomorrow's AGI.

This is not just about future AGI; it explains why today's models are so capable. Take Anthropic's Claude. It is widely regarded as the premier coding model not by accident, but by design. Its developers explicitly use Claude to code Claude.

This creates the ultimate feedback loop. If the model writes buggy code or hallucinates a library, the engineer building the next version feels the pain immediately.

Beyond quality, this is about necessity. We are hitting the "Complexity Wall." The systems required to train the next generation of models are becoming too vast for human engineers to manage manually. To reach AGI, we need code written at a speed and complexity that only an AI can generate.

The Evolution of Value: The Rise of the Creative Orchestrator

For decades, value was defined by deep specialisation. Then came the "Full Stack" developer, a specialist generalist. Now, 2026 demands the "Creative Orchestrator ."

The rise of AI Agents is causing friction for the traditional "Specialist Developer" who feels the need to hand-craft every line. The future belongs to those with high cognitive creativity , engineers capable of wielding multiple AI agents concurrently to solve problems, rather than just writing syntax.

The Developer Mindset

Feels the need to hand-craft every line, deeply suspicious of what they didn't build themselves.

The Engineer Mindset

Like a bridge builder, they trust the steel and components that already exist. They focus on the structural integrity of the whole, not the chemical composition of the bolt.

The "PhD-Level Junior": Why AI Needs Human Orchestration

There is a dangerous misconception that AI writes perfect code automatically. Our experience deploying Agentic Swarms proves that AI rises only to the level of the prompter . Without a skilled Orchestrator, an AI Agent is simply a "PhD-level Junior": infinite encyclopaedic knowledge, but zero wisdom or context.

The Silent Accumulation of Liability

Left unsupervised, this "Junior" creates a unique form of technical debt: Spaghetti Code at Scale. Because AI prioritises "making it run" over structural integrity or security, it frequently generates code that passes unit tests but is riddled with hidden vulnerabilities.

We are seeing a rise in "brute force" solutions; bloated functions, unoptimised queries, and insecure dependencies, that work in isolation but degrade the performance and security of the broader system. Without a skilled Orchestrator to enforce standards, you may be building faster but you are compounding your security risk and maintenance costs at a velocity humans cannot match.

Trend 4: Cloud Smart Strategy & The Rise of Repatriation

The Trend: From "Cloud First" → Cloud Smart

For the last decade, the CIO mantra was simple: shut down data centres and move everything to hyperscalers (AWS, Azure, GCP). In 2026, customers are moving to "Cloud Smart" (or Cloud Where Possible / Cloud-Right).

The Economic Correction: Escaping the "Cloud Tax"

The promise of Cloud was cost reduction, but the reality for many at scale has been cost explosion. The "rent" paid to hyperscalers, especially for data egress and always-on compute, often exceeds the cost of owning the infrastructure. We are seeing a wave of "Repatriation," where predictable workloads are moving back to private clouds or bare metal.

In 2023, 37signals (makers of Basecamp) executed a full cloud exit after realising that for a mid-sized company with stable growth, "renting computers is a bad deal."

They debunked a critical industry myth: that the Cloud is "simpler" and therefore requires a smaller team to manage. Their experience proved that running major services in the cloud is just as complex as running them on-premise; the promised savings in operations labour never materialised.

The result? By late 2024, they confirmed the move had slashed their infrastructure spend, putting them on track to save $10 million USD over five years . They proved that if your growth is predictable, owning your assets is mathematically superior to renting them.

Residency vs. Sovereignty: The US CLOUD Act Risk

While hyperscalers offer "Residency" (it sits on Australian soil), true Tier 1 Sovereignty (immune to foreign jurisdiction) often requires air-gapped infrastructure to eliminate exposure to regulations like the US CLOUD Act.

The "Microsoft Ireland" Precedent

The CLOUD Act (2018) was not a proactive measure; it was a reactive weapon. It was born from the United States v. Microsoft Corp case, where the FBI demanded emails from a customer suspected of drug trafficking. Microsoft successfully refused, arguing the data was physically stored on servers in Dublin, Ireland, and therefore outside US jurisdiction.

Panic ensued at the DOJ. Realising that "Data Residency" was a successful legal shield, Congress passed the CLOUD Act to crush it. The law explicitly states that US tech companies must hand over data regardless of where it is physically stored.

The Post-American Drift

This loss of trust was the dominant theme at the 2025 Web Summit in Europe. The industry consensus is shifting away from US-controlled "Black Boxes" toward High-Performance Open Source (like DeepSeek). The goal is no longer just "better features", it is the ability to run the model on your own metal, where neither Washington nor Beijing can touch the off switch.

Trend 5: Enterprise AI Strategy: Open Source, SLMs & The Sovereign Stack

The Trend: From "Black Box Rentals" → Open Weight Assets

If Sovereign AI is the goal, Open Source (Open Weights) LLMs are the vehicle.

DeepSeek vs. GPT-4: The Performance Gap Has Closed

The delta between proprietary "Black Box" models (GPT) and top-tier Open Weight models (DeepSeek, Llama, Mistral, Qwen) has collapsed. "Good enough" is now "Excellent," rendering the premium for closed models difficult to justify against the strategic advantage of ownership.

The Asset Mindset: Treating AI as Proprietary IP

In a low-trust geopolitical environment, you cannot build critical infrastructure on a model you cannot inspect. Open Source allows for deep code audits which ensures no hidden biases or backdoors exist. When you fine-tune an Open Source model on your own secure infrastructure, you are building a Proprietary Asset that adds value to your balance sheet and is immune to external price hikes or policy changes.

The Rise of SLMs: Speed, Sovereignty & Specialisation

The era of "One Giant Model to Rule Them All" is ending. We are witnessing a migration from massive LLMs (Large Language Models) to SLMs (Small Language Models).

Why burn a forest to light a cigarette? For 90% of enterprise tasks, such as classifying documents, routing tickets, or summarising meetings, a trillion-parameter model is overkill. It is slow, expensive, and difficult to host.

The "Distillation" Breakthrough

The game changed in early 2025 with the popularisation of "Model Distillation" (pioneered at scale by DeepSeek). This technique involves using a massive "Teacher" model to train a tiny "Student" model. The result is that you get the reasoning quality of a giant brain compressed into a model small enough to run on a laptop.

The Strategic Advantage

Domain Density The real power of SLMs is Specialisation. Instead of a generic model that "kind of" knows everything, you can fine-tune a small model (e.g. Llama-8B) exclusively on your specific reality. This could be your COBOL legacy code, your unique legal contracts, or your proprietary engineering schematics.

Speed: They run at lightning velocity (low latency) enabling real-time voice and agentic flows.

Cost: Inference costs drop by 90-99% compared to calling a frontier API.

Privacy: They are small enough to run entirely "at the Edge" (on a secure on-prem server or even a user's device) ensuring no data ever leaves the building.

The "AT&T" Proof Point

You don't need a trillion parameters to be smart; you just need to be focused.

In a defining case study for 2026 , AT&T (a Fortune 50 giant managing petabytes of sensitive data) migrated core analytics workflows from massive frontier models to Mistral's SLMs .

The task was industrial-scale sentiment analysis: processing millions of customer support transcripts to detect billing errors and churn risk. They realised that a model doesn't need to know the capital of Iceland to recognise a billing complaint, it just needs to know AT&T.

The Results:

Speed: They slashed call centre processing times by 84%, reducing a 15-hour workload to just 4.5 hours.
Cost: Chief Data Officer Andy Markus confirmed a 90% reduction in costs compared to commercial large-scale models.

This destroys the myth that 'Bigger is Better.' By processing 5 million calls locally, AT&T proved that in 2026, competitive advantage doesn't come from having the largest model; it comes from having the most efficient one.

The Bottom Line: Owning Your Future

The barriers to entry have collapsed. Custom software, SLMs, and sovereign hosting have never been cheaper, faster, or of higher quality. 2026 is shaping up to be a defining year where technical constraints are no longer the bottleneck. The only thing that now hinders an organisation is its own agility and speed to adapt to this new reality.

Turn Strategy into Sovereignty

Patient Zero bridges this gap by mapping these sovereign trends directly to your engineering roadmap:

The Strategy : Don't get locked into a "Black Box." Build your own proprietary assets with Custom Software Development .
The Workforce: Need "Orchestrators" not just coders? Augment your capability with our Embedded Software Team s .
The Infrastructure: Stop paying the "Cloud Tax." Refactor your estate for efficiency and security with Application Modernisation

About the Author

Her goal? To help Australian enterprises stop renting their future and start building it.

Disclaimer: This article reflects the technical reality as of January 2026. In this industry, the shelf life of information is measured in weeks, not months. Any advice, tool, or benchmark mentioned here may have already evolved or been replaced by the time you read this.

The Retreat of Globalisation: Key Takeaways from Indo Pac 2025

Tue, 03 Feb 2026 06:49:44 GMT

EDITOR'S NOTE

Why is a software engineering company at a Maritime Defence conference? Because in 2026, you cannot separate "Kinetic Capability" (Ships) from "Digital Capability" (Code). Whether it is a frigate or a fintech platform, the risks are the same: if you rely on a "black box" form offshore, you don't own your future. Dan reports from the intersection of Defence and Digital.

The Executive Summary (TL;DR)

The Context: Indo Pac 2025 confirmed that the era of "Just-in-Time" global supply chains is dead.
The Shift: The focus has moved from Efficiency to Resilience. AUKUS and the Quad are driving a massive push for onshore capability.
The Tech Reality: "Sovereignty" isn't just about building ships; it's about owning the software and IP that runs them.
The Trap: Quantum is coming, but it’s not a strategy yet. Don’t let the hype distract you from the immediate need to secure your supply chain today.

What is Indo Pacific?

Held in Sydney, Indo Pacific is the premier International Maritime Exposition for the Indo-Pacific region. It is not just a trade show; it is the strategic pulse check for the Royal Australian Navy and its international partners. It brings together Defence Chiefs, Industry Leaders, and Tech Innovators to define how we protect the region's sea lanes and sovereignty.

The Report: Strength at Sea, Sovereignty on Shore

The Indo-Pacific Defence Conference is over, but the real work is just starting. If the conversations in Sydney confirmed one thing, it is that the region is changing faster than our supply chains can keep up.

Here is the deep dive on the three signals that matter most.

1. Maritime is Everything

The theme was "Strength at Sea," and for good reason. Trade routes are contested, and tensions are rising. Recent naval drills in the Tasman Sea (Feb 2025) were a stark reminder that our isolation is no longer a guarantee of safety.

Australia has a long-standing alliance with the US, and despite the shifting political climate, the strategic logic holds firm. AUKUS and the QUAD are central to keeping sea lanes open. Operationally, this is where the attention, and the funding is flowing. We are, after all, an island nation. If the boats stop, the country stops.

2. The Death of "Just-in-Time"

One of the brutal lessons of the COVID-19 era was the fragility of the global supply chain. We watched entire industries stall because a single component for a laptop or a car was stuck in a port halfway across the world.

Indo Pac confirmed that Globalisation is retreating. The efficiencies gained by "Just-in-Time" freight have been replaced by the necessity of "Just-in-Case." In a deglobalised world with less secure maritime routes, we face a binary choice: we either continue to gamble on foreign supply chains, or we start producing critical assets onshore.

This isn't just about manufacturing; it’s about Digital Sovereignty . Imagine a reality where you can’t buy the hardware you need, or the software you rely on is switched off remotely. Now ask yourself: How does your business survive that?

3. The Quantum Question

Everyone is talking about it. The promise of Quantum computing to revolutionise Cryptography, Sensors, and Stealth is undeniable. Even the Australian government has announced significant investment in a local Quantum startup founded by four Australian professors.

But the question remains: How long before we can actually use it on an industrial scale?

The Strategic Verdict: A Decoupled Future

The investment is real, and strategic knowledge-sharing agreements like AUKUS Pillar 2 recognise its potential. But the practical applications are still years away. Do not let the hype blind you to the scalability issues. We are moving toward a decoupled world.

If we don’t own the innovation pipeline here at home, we lose the strategic advantage, but we must build what works today while we wait for the quantum leap of tomorrow.

Deepen Your Sovereign Capability

Don't just watch the supply chain shift, prepare for it.

The Solution: Build secure, onshore platforms with Sovereign Software Development
The Team: Stop renting offshore dependencies and start building internal muscle with Embedded Teams
The Action: Ready to decouple your digital supply chain? Contact Us

About the Author: Dan Dekel

He believes that true sovereignty requires us to be builders, not just consumers, of technology.

Accessibility Lessons Learned

Wed, 21 Jan 2026 03:26:03 GMT

EDITORS NOTE

At Patient Zero, we believe that "Sovereign Capability" means building systems that serve all Australians regardless of ability. In this retrospective, our engineering team breaks down the hard realities of achieving WCAG 2.1 AA compliance in complex enterprise and government environments. It’s not just about ticking boxes; it’s about engineering empathy.

Accessibility Lessons Learned: Building for Everyone

In a thought-provoking advertisement from the early 2000s the French electrical utility Electricité de France (EDF) showed a vision of a world designed exclusively for people with disabilities.

A woman walks down the street while dodging people in wheelchairs.

Another woman walks up to the front of a bank queue and asks to open an account, and the teller replies to her in sign-language.

A man hunches over trying to make a call on a waist-height phone, while a boy in a wheel-chair points and laughs.

The ad is a reminder that the experience of people with disabilities is as much a product of the choices that were made when building the environment that they live in as it is of their physical life situation. It is also a reminder of our responsibility when building the digital equivalent of the world we all inhabit to consider people of different backgrounds and abilities.

Globally, it is estimated that 1.3 billion people live with a disability. In Australia, 5.5 million people (21.4 % of the population) live with a disability. In addition to those living with a permanent disability, many people will experience a temporary disability due to injury or illness during their lifetime. The Disability Discrimination Act of 1992 mandates equal access to premises, services and digital platforms. Digital accessibility for government services must meet WCAG 2.1 Level AA standard.

Businesses and employers are required to make reasonable adjustments to their services, policies, practices and environment to enable access for people with disabilities. They may be exempt from making these adjustments if doing so would cause “unjustifiable hardship”, but they must demonstrate this hardship to justify not making the changes.

Simple examples of accessibility affordances in software systems are alternative text for images, support for keyboard navigation, high contrast modes and resizable text. Achieving AA and AAA WCAG 2.1 compliance across many screens is not easily done, and even simple-sounding statements like “support for keyboard navigation” can be surprisingly hard to achieve.

From Theory to Practice: What We Learned

Some of our PZ teams have recently been involved in a large public-facing web system which required WCAG 2.1 AA compliance. Here are some of the lessons the teams learned along the way.

Securing Buy-in & Managing Expectations

Firstly, get company buy-in and educate stakeholders on the what and the why of investing in an accessible product. Progress initially will likely be slow with a steep learning curve, so it is wise to set this expectation up-front. Depending on the organisation’s culture getting buy-in may be the most difficult step, or it may already be accepted that a11y is a requirement for the product.

The Retrofit Strategy: Start Small

Depending on the complexity of your app(s) and their age, it can be very time-consuming (and in turn expensive) to retrofit an AA standard. Start small and set achievable goals - a 6-month a11y-only project will burn everyone out. Striving for AAA (the gold standard) in an app that's never had A11Y considered is a stretch made exponentially harder depending on its age and complexity. Consider focusing on achieving A standard as a bare minimum, and from there, slowly work towards AA standard, juggling in feature work (shifting a11y left as part of that process) while retrofitting a11y to existing features.

Consider prioritising specific aspects of your app based on what criteria make sense, i.e. if Google Analytics shows users spend the majority of their time filling out a Contact Us form, it makes sense to focus on that rather than a Terms and Conditions page no one reads.

Shift Left on A11y (Design First)

Avoid leaving accessibility as a single person or team’s responsibility. Starting early, considering a11y from the get-go will likely change how you build your app. It is usually much more difficult to retrofit a11y on to an existing design made without a11y in mind than to bake it in from the start.

An example of this could be designing form component error messages. Waiting until a user loses focus on a control to display an error seems optimal as you're not running the validation logic more than is required. With that said, how would a visually impaired user see/hear that error? Screen readers announce descriptive information about the elements/controls currently focused (or virtually focused in the case of mobile screen readers), so by running validation after focus has been lost, the error message will not be announced and the user may not know there's a problem until they attempt to submit the form!

Discussing the design/challenges with team members improves the understanding of everyone involved on what we're trying to achieve and why, which builds a better product and means the knowledge is shared from the initial design all the way to Quality Assurance before the product/component is shipped to users. These learnings will then be applied going forward, and just like that, we've shifted left on accessibility!

Automation vs. Manual Testing

Use automated tools; especially if you don't have a dedicated design team, but keep in mind most of the functional behaviour can only be tested manually. Physical device testing is significantly faster.

The Reality of Emulators

Emulators, while convenient, do not accurately reflect how a device functions. It's an investment but the time saved not dealing with emulators and their unreliable results pays for itself - there is no substitute for physical devices.

Screen Readers: A Steep but Necessary Learning Curve

Understanding and learning the basics of the screen readers you plan to support greatly streamlines the process and eases a lot of the initial frustrations that come with learning new software. At first, trying to remember mobile swipe gestures for both VoiceOver and TalkBack can be daunting, but you'll very quickly pick up the basics needed to navigate and interact with your application.

VoiceOver Quirks: iOS vs. Safari vs. Chrome

VoiceOver for iPhone and iPads functions very differently as does VoiceOver on Safari vs VoiceOver on Chrome, don't assume if it works on one it works on the other - you'll be surprised just how different they are. It's very easy to have regressions creeping in as changes conflict between screen readers, and fixes for one screen reader will break another.

Setting a Testing Baseline

For all parties involved in developing/testing, set baseline configuration for your supported device configuration (most likely the default config). Screen readers are highly configurable, and users have tailored their devices to best suit their needs, but catering to all these options just isn't feasible.

An example of this would be NVDAs Browse and Focus modes, where the former is used for easily navigating around a webpage's content and the latter for interacting with different elements/controls. These modes are automatically toggled by default depending on the webpage content, but it's possible to override this behaviour to trigger manually. As you could imagine, the user experience between the modes is vastly different, which during QA could result in a lot of bugs being raised if a baseline configuration hasn’t been agreed upon.

Vet Your 3rd Party Libraries

Check libraries thoroughly if leveraging 3rd-party components. Unfortunately, millions of downloads a week doesn't mean they're accessible and quite often less well-known downloaded libraries have better accessibility.

If you’re considering building your own components, WCAG provides excellent vanilla JavaScript and HTML implementations of standard components a typical site needs, however their examples attach a large number of event listeners to the DOM's body which can degrade performance, so keep that in mind. See what other websites/design systems are doing (see links to these below) and use these for inspiration/guidance where WCAG components may fall short.

Conclusion: A Reward Worth the Effort

Building an accessible app or site is a moral and often legal requirement. It requires commitment from the team and stakeholder buy-in. Our teams that have worked on projects with a strong commitment in this area have found it very rewarding, knowing that their work will be available to the broadest range of people possible.

Accessibility Resources Toolkit

Guides & Standards:

MDN Web Docs: Accessibility Fundamentals
W3C Standards: WCAG 2.1 Overview
Quick Reference: WCAG in Plain English

Component Libraries We Recommend:

Adobe: React Aria
HashiCorp: Helios Design System

Explore Related Capabilities

Product Strategy & UX Design: Design inclusive user experiences that meet WCAG 2.1 standards from the very first wireframe.
Enterprise App Modernisation: Retrofit legacy applications to meet modern accessibility compliance without breaking existing functionality.
Web Apps & Portals: Build robust, public-facing platforms that are rigorously tested for screen readers and keyboard navigation.

Inside Certember: How We Turned "I Don't Have Time" Into a Company-Wide Challenge

Mon, 12 Jan 2026 06:02:08 GMT

EDITORS NOTE

At Patient Zero, we know that access to courses isn't the problem; finding the motivation to finish them is. In a busy consultancy, client work always takes priority over personal development. In this post, we look at how Principal Software Engineer Hanieh Madad solved the accountability gap by turning professional development into a team sport.

TL;DR

The Problem: We all want to get certified, but finding the time and motivation outside of client work is a struggle.

The Idea: Inspired by the AWS community, we launched "Certember". A company-wide sprint to get certified together.

The Solution: We formed internal study groups (AWS, Azure, Product Owners) to move from "self-paced" to "team-based" learning.

The Reality: We originally planned for a one-month sprint but extended it to three to accommodate real-life workloads without burning people out.

The Result: 45% of participants have already passed their exams, with more scheduled for Jan. The #1 feedback? Study groups work.

Want the cheat code? Watch Hanieh’s 3 rules for passing any certification in 60 seconds:

The "Someday" Trap

We all have that one certification we’ve been meaning to get. We bookmark the Udemy course, buy the exam voucher, and promise ourselves we will study "when things quiet down."

But in a software consultancy, things rarely quiet down. Client deadlines usually win the war against personal development.

Hanieh Madad (one of our Principal Engineers) decided to stop waiting for the perfect time and create it. She pitched an initiative called " Certember ", a month-long, company-wide sprint to get certified together.

I sat down with Hanieh to find out how it went, why the timeline had to change, and why study groups are the secret weapon for exhausted engineers.

The Spark

The idea didn't come from a strategy session; it came from a moment of realisation at an AWS Community Day .

"One of the speakers was sharing tips on how to get AWS certified," Hanieh explains.

"He mentioned that his company ran internal study groups. I immediately thought: We have so many people at Patient Zero saying they want to get their certs, but they are struggling to find the time. Why are we all trying to do it alone?"

Hanieh took the idea to Joe Cooney , who loved the concept immediately, and, being the nomenclator he is (Stack Overflow is his claim to fame), coined the name "Certember."

The Setup: Gamifying

The response was immediate. 20 people (about a quarter of the company) signed up to participate.

To move from "good intentions" to "actual studying," the initiative relied on two key pillars:

Tribes: Participants split into three streams based on their goals: AWS , Azure , and a group for Product Owners .
Visibility: We kept the goal front-of-mind. Through a dedicated Slack channel and regular check-ins, we ensured the target didn't get buried under daily client work.

The Reality Check: From "Certember" to December

The original plan was ambitious: get certified in September. But as Hanieh notes, reality quickly intervened.

"We initially thought September and October would be enough," she laughs.

"But we were asking people to study on their own time, outside of work. November hit, work got crazy, and we realised we needed to be realistic."

Rather than forcing a "crunch," the timeline was extended to the end of the year.

"Work-life balance has to come first," Hanieh says.

"We had a few people who were ready to sit exams in November, but life happens. Extending it meant we kept people in the race rather than burning them out."

The Secret Weapon: Accountability

When Hanieh asked the team for feedback, the answer was unanimous: It was the study groups that saved them.

"That was the main point," Hanieh says.

"Work was crazy, personal life was the same. But that weekly catch-up with the team gave people the energy to push through. Even I needed that external accountability."

For Hanieh, the goal was to validate her AI knowledge.

"I was constantly studying to stay up to date, but with the rapid changes in AI, I felt I needed to force myself to revisit the fundamentals. Getting that cert at the end is a great satisfaction."

The Results

Despite the chaos of busy work deadlines, the initiative has been a massive success.

7 Champions have already crossed the finish line (a 45% completion rate), earning not only a certificate, but a sweet special edition PZ T-shirt (as shown in the image in this article).
Study Groups formed organically across teams.
Momentum is building for January, with several people prepping to sit their exams after the holiday break.

Hanieh’s 3 Tips for Your Own "Certember"

If you are planning to tackle a certification, here is Hanieh’s advice from the trenches:

1. Go Fast (Don't Drag It Out) "Next time, I would try to go through the material faster. The longer it takes, the more you need to review what you’ve already learned. If you have a few days' gap, you lose context."

2. Deep Work > Audiobooks "I started by studying 15–30 minutes a day, listening to audio while driving. That’s fine for the basics, but later I realised I needed 1–2 hour chunks of focus time to really understand the complex areas."

3. Find Your Squad "Doing it alone is hard. Doing it with a group that is all suffering through the same practice exams? That’s actually kind of fun."

Our Growing Certificate Cabinet

While the initiative was about culture and connection, the outcome is serious technical validation. We believe that if you are going to recommend a technology to a client, you should master it first.

Certember adds to our growing library of team credentials, ensuring that when we build a solution, it's backed by global standards.

Our current certification stack includes:

AWS Cloud: From Cloud Practitioner and AI Practitioner all the way to Solution Architect Professional and SysOps Admin Associate.
Microsoft Azure: A full spectrum, including Azure Developer Associate and Solutions Architect Expert, plus specialised security credentials like Cybersecurity Architect Expert.
Agile & Product Leadership: Certified Scrum Masters (SCM), Product Owners (PSPO), Scrum Developers, and Agile Leadership (PAL).
Specialised Engineering: Certified Kubernetes Administrators, ISTQB Advanced Test Analysts, and BCS UX Design professionals.

Where to From Here?

We believe that great software is built by people who never stop learning. If you are looking for a team that prioritises engineering rigour and verified expertise, or if you want to be part of one, here is your next step.

Working at Patient Zero: Join a culture that funds your curiosity and gamifies your growth.
Embedded Teams: Scale your capacity with engineers who are actually certified in the tools you use.
Software Development: See how we turn continuous learning into production-ready software.

The Gen Z User Manual: Vibes, Emojis, and the End of AI Compliments

Fri, 19 Dec 2025 23:31:36 GMT

EDITORS NOTE

We all know the workplace is changing. New tools, new workflows, and yes, new generations. But integrating Gen Z into your team isn't about memorising slang dictionaries; it's about understanding how we connect.

Here are three lessons from the front lines of the Green Team.

Lesson 1: Help form a team identity

Gen Z have no friends. And because they have no friends, they’re really desperate to have something to belong to. So once they do, it kind of becomes their whole identity.

May I present to you: the moment I joined Green team.

And then: two minutes after I joined Green team Kermit.

Fully embracing our newly-appointed mascot, it kind of became all-kermit, all the time.

And it really became our group identity.

Of course, there are other ways to bond with your co-workers. But nothing is quite as strong, or works quite as quick as having an easily-identifiable shared belonging to point to. And once you have that, everything else becomes easier.

Lesson 2: Could you ask… cuter?

Communication is how we as humans relate to one another. But communication is more than just words. We have non-verbal cues, like body language, gestures, and tone of voice. That’s lost online. That’s why, in the early days of the internet, we invented the emoticon :-)

Many decades later, we now have roughly 4,000 emojis that we can use to help express our emotions and intentions.

Having grown up with these emojis, Gen Z kind of expects you to… use them.

One such emoji that’s been severely under-utilised by those born before 1997 is the humble: ��

The pleading emoji.

Need someone to do something you were supposed to do?

Lesson 3: No AI compliments

My third and final lesson: Share the love, but stop with the AI compliments.

Let me preface this by saying I think having a shout-out culture is an excellent thing. But a shout-out loses a lot of its heart once you realise it wasn’t actually authored by the person who’s posting it.

How can we tell?

It’s not a fool-proof method, but generally, if your shoutout is more than four lines long and features five different types of punctuation marks? I’m suspicious.

But the true nail in the coffin is bolded keywords .

If I see "demonstrated excellence" in bold font, I know ChatGPT wrote it. Seriously, just post the rough draft. It will mean more to us than a perfectly polished robot paragraph.

Find Your "Green Team"

At Patient Zero, we believe that great engineering requires great culture (and occasionally, a Kermit mascot). We are always looking for people who can communicate clearly, collaborate deeply, and bring their own unique identity to the team.

GITEX Global Review: The Robots Are Here (And Australia Isn't)

Wed, 17 Dec 2025 08:02:53 GMT

Turns out GITEX is a big deal. Originally starting in 1981 as the Gulf Computer Exhibition (GCE), it has since grown to be one of the world’s largest tech and innovation shows, now sitting third globally behind CES Las Vegas and the Mobile World Congress (MWC) in Barcelona. With over 6,800 exhibitors and attendance pushing 200,000, it’s easy to see why. And at the pace the UAE is innovating, they might just take the spot in a few short years.

History aside, here are my hot takes from attending GITEX (and Dubai) for the first time.

TL;DR

The Scale: GITEX is now the 3rd largest tech show on earth. The UAE isn't just hosting the future; they are aggressively building it.

The Reality Check: Robots are everywhere, but true autonomy is still lagging. An observed demo fails to prove a critical point: Tools are not skills. You can't just "prompt" an enterprise workflow into existence; you still need engineering rigour.

The Gap: While Abu Dhabi builds the world's first AI-native government, Australia was virtually invisible on the show floor.

The Verdict: The world is moving at breakneck speed. We have the talent to compete, but we need to stop admiring the problems and start engineering the solutions.

Robotics at GITEX: The Robots Are Finally Here

No, really. Walking through the exhibition halls, robots were everywhere. From the Boston Dynamics doggies to waiter-esque service bots, they were decking the halls with metal jolly. Some were proprietary to the exhibitor, while others took the gimmick route buying a commercial unit and sticking a wig on it to get you to stop at their booth.

The overall vibe? Mainstream robotics isn’t far off. You’ve probably heard of Neo the Home Robot going into pre-sale. But Neo isn’t truly autonomous yet, with a large chunk of activities still controlled by a real human remotely.

I don’t know about you, but I am not about that life. Having a robot wandering around my house that a tech company can remotely dial into at their whim? No thanks. I know we say convenience trumps trust, but that is a level of trust I am just not comfortable with.

Not until we’ve ironed out the robot revolution, because let’s face it, sci-fi tells us exactly how this is going to go down.

Beyond Chatbots: The Rise of Agentic AI & Autonomous Workflows

While Neo ain’t quite autonomous yet, there is an undeniable truth that we are barrelling towards autonomous AI across many tech streams.

E.g. Agentic AI. Not sure if you’ve heard of it ��

I watched a speaker fumble around trying to demonstrate to a group of marketers how to set up their own workflow in Python and CrewAI. Needless to say, the whole thing went over their heads; these workflows and tools require technical expertise and engineering rigour – developers rejoice.

Plus, the LLMs' outputs produced a bunch of AI slop. While the slop is still slop, it is edging better, especially if you are well-versed in prompt magic. That guy didn’t know what was what, though, which didn’t help his case.

It highlighted a critical truth that my team at Patient Zero preaches daily: Tools are not skills. You can't just 'prompt' an enterprise workflow into existence. You still need engineering rigour to stop the 'AI Slop' from becoming enterprise debt.

There are only a few use cases where these initiatives are returning investment, but the momentum is a force that can’t be stopped. So, my advice to you, dear reader, is not to dig your head in the proverbial sand, but instead to pay attention, experiment, and learn the engineering behind the hype as the wave builds.

The UAE certainly has. With fossil-fuel slowdowns looming, they’re going ham in diversifying GDP at breakneck speed. Autonomous vehicles are slated to roll out in 2026, with Abu Dhabi aiming to be the first AI native government.

Abu Dhabi is building an AI native government

Yes, I said this twice, because it’s the thing that struck me the most.

Some Australian governments still ban the use of AI, while Abu Dhabi is integrating it everywhere they can. They have an ambitious goal; to be the world’s first fully AI-native government across all digital services by 2027.

You could claim they have more money to play with, but looking at the latest project overrun from BOM from $4.1 mil to a staggering $96.5 mil , it's clear there's money that could be rerouted to something more innovative and of value to citizens.

TAMM, their all-in-one government app has been around for quite a while. But version 4.0, introduces AutoGov, which simplifies tasks like renewals, permits, and applications and automates them so they're completed on your behalf.

And naturally, they’ve had an AI chatbot with voice enabled for over a year.

Rumour also has it that holographic AI assistants will appear in public spaces next year. If I were a betting woman, that announcement is getting saved for the next GITEX.

The Sovereign Gap: Why Australia was nowhere to be seen

Apart from the legendary Patient Zero merch roaming the halls, Australia’s presence was tiny. Two companies exhibited, and the only one I recognised was Espresso Displays , whose portable screen I swear by. Not even Atlassian or Canva had a lookin, two of our biggest tech successes. Every other country seemed to have a footprint; Moscow, Pakistan, Turkey, Poland, Latvia, Serbia… you name it. Not Australia.

In a world where technology is the new frontline of national security, our absence wasn't just embarrassing; it was a strategic vulnerability. While other nations are aggressively exporting their sovereign capability, we seem content to just import theirs.

The Verdict: Innovation vs. Stagnation

Dubai and the UAE genuinely feel like the future. The Museum of the Future itself looks like it was dropped in from another timeline. Digital displays everywhere. Flying taxis and autonomous vehicles looming.

Meanwhile, Australia’s pace in the innovation race feels more snail than hare.

The world is moving fast. We have the talent and the money (clearly) to compete. We just need to stop admiring the problems and start engineering the solutions. It's time to catch the flight.

Where to From Here?

We believe that tools are not skills. If you are tired of the "AI Slop" and want to build workflows that actually scale, we can help you engineer the solution.

App Modernisation: See how we rescue legacy systems from technical debt.
Embedded Teams: Hire the people who know how to wield AI.
Co-CEO Series: Watch what happens when AI becomes your fourth Co-CEO.

Join the Conversation

Her goal? To help Australian businesses stop admiring the problem and start building the solution.

When Can I Replace My Software Developers with AI? (Spoiler: You Can’t)

Mon, 15 Dec 2025 05:53:53 GMT

At the recent Gartner IT Symposium, our Co-CEOs Demelza Green and Paul Seymour took the stage to answer the question on every CFO’s mind: "When can I replace my software developers with AI?"

The short answer? You can’t. The long answer? You can’t, but you can build a significantly faster, more dangerous competitor if you stop treating AI as a replacement and start treating it as an accelerant for Talent Density.

Here is the reality check from the front lines of enterprise software.

Key Highlights

AI is an Accelerator, Not a Replacement: AI speeds up "Flow State" for senior engineers but creates chaos for juniors. Replacing experts with AI leads to a "Sorcerer's Apprentice" disaster.

Writing is Not the Bottleneck: Developers spend only 10–20% of their time writing code; the rest is spent understanding it. AI speeds up the typing but increases the "review tax," often resulting in zero net velocity gain.

The "Vibe Coding" Trap: Using AI without deep engineering knowledge creates technical debt at hyperspeed. Recent data shows developers spend 67% more time debugging AI-generated code.

Fix Your Foundations First: Most organisations can achieve 300% performance gains simply by removing bureaucratic gates and improving CI/CD, before even touching AI.

The New Cost of Talent: The engineers who can wield AI effectively are the top 1%. They will cost more, not less, because they provide exponential value.

1. Beware the Hype Machine

The first step to sanity is filtering your inputs. The industry is currently awash with "AI Hype Machines"; vendors and influencers claiming that AI will write 90% of code by next year or that you can fire your junior engineers today.

Be careful who you listen to. Most of these claims come from people selling the shovels, not the ones digging the holes . In the reality of complex enterprise environments, where security, legacy integration, and sovereignty matter, these "magic button" promises fall apart. We need to move from "Peak Hype" to "Peak Engineering."

2. The "Sorcerer's Apprentice" Problem

When you do apply AI, the reality is closer to the Sorcerer's Apprentice .

AI is a form of magic. In the hands of a Master (a Senior Engineer), it automates drudgery and accelerates "Flow State." But in the hands of an Apprentice (a Junior without guidance), it creates chaos.

The Metric: 45% Failure Rate

In a recent junior intake, 45% of candidates with high GPAs couldn't explain the code they submitted because they let AI write it for them.

The Risk: The "Vibe Coding" Trap

Bad code is still bad code. The Harness (2025) "State of Software Delivery" report found that developers spend 67% more time debugging AI-generated code compared to human-written code. If you replace your experts with bots, you aren't building software; you're building technical debt at hyperspeed.

3. The Efficiency Illusion: Writing Faster ≠ Delivering Faster

The hype assumes that if an AI generates code 50% faster, you get 50% more software. But this math fails because it misunderstands what a developer actually does.

The "Reading" Ratio

Developers typically spend only 10–20% of their time writing new code . The vast majority of their time is spent reading, debugging, and understanding existing code.

The Trap? AI accelerates the easy part (typing syntax) but often complicates the hard part (understanding logic). If an AI generates a complex block of code in seconds that takes a human 2 hours to audit and integrate, you haven't saved time, you've just shifted the cost from "creation" to "review."

The Burnout Factor & "Taking Time Back"

We also need to talk about the human cost. Recent industry reports show developer burnout is at an all-time high.

The "Coffee" Calculation: If AI saves a developer 18 minutes between each task, our observation is that they aren't using that time to write more code. They are using it to grab a coffee, reduce cognitive load, or simply "take their time back" to avoid burnout.

The reality is t hat time "saved" is often absorbed by the increased cognitive load of reviewing AI-generated code. So, the net gain to the business isn't "2x Features", it's often just a slightly less stressed developer (which is good!) or a coffee break (which is neutral).

4. Why AI is Just the "New Stack Overflow" (For Now)

The Blocker: Enterprise Fear

It’s not just laziness; it’s fear.

Organisations are terrified of IP leakage and "Shadow AI," so they block tools or wrap them in so much red tape that they become useless. However, this creates a dangerous "Shadow Reality": when you block safe tools, developers inevitably turn to unsafe ones on their personal devices to get the job done. The result is that you aren't actually stopping the risk; you are just losing visibility of it.

The Capability & Time Gap

Even when tools are available, there is no education. We expect developers to magically intuit how to become "Prompt Engineers" in the 5 minutes between sprint tasks, but you cannot master a paradigm-shifting technology without dedicated time. If your team is 100% utilised on feature delivery, they have 0% capacity to learn how to move faster, creating a permanent "Time Trap" that stalls adoption.

The Solution: Permission to Play

You must create safe spaces for experimentation. We found that running internal Hackathons and "Prompt Injection" challenges moved our teams from "Existential Dread" to "Tool Mastery" because it gave them permission to break things and fail safely. This shift is critical; it turns fear into curiosity and transforms AI from a threat into a tool.

5. You Can Get 3x Performance Without AI

Before you spend millions on AI, look at your foundations. In our session, we highlighted that most organisations can achieve a 300% performance improvement simply by fixing the basics that they ignore.

The Bureaucracy Bottleneck

If you layer AI on top of a broken process, you just get "Bad Faster." The real blockers to velocity are rarely typing speed; they are bureaucratic approval gates, slow CI/CD pipelines, unclear requirements, and low-trust environments.

The "Strike Team" Fix

The solution is to remove the friction. In our recent "Strike Team" case study, the client removed the gates because the deadline was critical. The result was a full MVP delivered in two weeks. The speed came primarily from the process change; the AI just helped us run.

6. Hiring the Top 1% (The New Cost of Talent)

If AI raises the ceiling, it also raises the floor. The engineers who can effectively wield these tools, the ones who can architect systems and audit the AI's output, are no longer just "Senior Developers." They are the Top 10% of the Top 1% .

The New Talent Economics

The reality is that these people will cost more, not less. Because they can effectively do the work of three "standard" developers by leveraging AI correctly, their value is exponential.

The Death of Standard Hiring Tests

How do you hire them? You can't use standard coding tests anymore. You need to pivot to testing System Design , Critical Thinking , and AI Collaboration .

The "Co-Pilot" Test

The new verification method is simple: give them a problem, give them an AI, and watch how they use it. Do they trust it blindly? Or do they treat it like a junior partner that needs supervision? That distinction is the difference between a Master and an Apprentice.

The Verdict: Augmentation, Not Replacement

The future isn't about firing your team. It's about investing in Talent Density . It's about hiring engineers who understand the principles of code, not just the syntax, so they can direct the AI rather than be fooled by it.

Watch the full talk below to see:

Why "Vibe Coding" is dangerous for Enterprise.
The math behind why LLMs won't reach 100% accuracy anytime soon.
The real-world case study of a "Zero to MVP" build in just two weeks.

Fix Your Engineering Strategy

The future isn't about firing your team; it's about investing in Talent Density . Whether you need to rescue a stalled project or inject high-performance DNA into your team, we provide the sovereign capability to get it done.

App Modernisation: See how we rescue legacy systems from technical debt.
Embedded Teams: Hire the people who know how to wield AI.
Co-CEO Series: Watch what happens when AI becomes your fourth Co-CEO.

Highly Commended: Demelza Green (Marketing Excellence)

Sun, 14 Dec 2025 10:26:37 GMT

We are thrilled to announce that our Co-CEO, Demelza Green , has been awarded Highly Commended in the Personal Marketing Excellence category at the 2025 ARN Innovation Awards .

In the technology sector, marketing is often viewed as a support function, a department that "colours in" the strategy. Demelza has flipped this script. By applying Product Management discipline and Engineering rigour to the Patient Zero brand, she has demonstrated that marketing is a primary driver of business strategy, culture, and revenue.

The Catalyst: From Socks to Cult Status

The evolution began with a simple experiment: a live A/B test at a major industry conference pitting standard corporate merchandise against zombie-themed designs. The market overwhelmingly chose the zombies.

That experiment proved that B2B buyers crave authenticity. Today, those socks have become legendary collector’s items , with special annual releases eagerly anticipated by the industry. But the socks were just the spark for a much deeper transformation.

Designing the "Team of the Future"

Leveraging this insight, Demelza led a total strategic redesign of the Patient Zero identity. She moved the brand away from "Corporate Grey" into a distinctive Retro-Apocalyptic aesthetic that honours our "Zombie" origins while telling a story about the future of work.

The new visual identity blends 1950s optimism with Space Age futurism , creating a deliberate juxtaposition that highlights the contrast of the world around us. But every element serves a strategic purpose:

Human + Machine: The imagery depicts humans and robots working side-by-side, symbolising our vision of the Team of the Future , where AI augments human potential rather than replacing it.

Sovereignty & De-globalisation: In an era of de-globalisation, we leaned heavily into Australian iconography. Flying koalas and armoured kangaroos aren't just mascots; they represent the resilience and protection of Sovereign Capability.

This isn't just branding; it is world-building. It communicates complex themes, sovereignty, innovation, and collaboration at a glance.

From Generative to Agentic: The New Marketing Engineering

While the visual strategy is grounded in psychology, the execution is pure engineering. Demelza has pioneered the transition from simple Generative AI to Agentic AI Workflows .

She isn't just "prompting" tools; she is orchestrating a digital workforce. By treating marketing operations as a software architecture, she has deployed autonomous agents that don't just create content but plan and evolve workflows.

The Evolution: Moving beyond static prompts, Demelza runs self-correcting agentic loops . These agents handle complex chains of tasks, from research and synthesis to asset generation and formatting, requiring human intervention only for strategic approval.

The Scale: This "Marketing Engineering" approach allows a single leader to output the volume of a multinational department. In a recent sprint, this agentic architecture delivered a calculated efficiency gain of 6,000% , producing a full suite of sales assets in a single day.

The Rigour: This isn't "AI Washing." It is the result of systematic architecture that ensures every agent operates within strict brand guardrails, delivering output that retains a distinct human voice.

Systems Thinking, Not Silos

Finally, the award recognises her application of Systems Thinking to culture.

For Demelza, "Brand" is not a logo; it is the sum of every interaction. By building a Distributed Content Culture , she has empowered technical staff to become brand owners. This "Pull, Don't Push" strategy means we don't rely on cold sales.

Prospective clients arrive already trusting our technical capability because they have engaged with the deep-dive insights written by the engineers who will actually do the work.

Why This Matters

This award validates a new model for leadership:

Storytelling with Substance

Branding isn't just aesthetics; it's a tool to communicate sovereignty, resilience, and the future of human-machine collaboration.

Agentic Velocity

Smart AI orchestration allows lean teams to output enterprise-level volume without sacrificing quality.

Authentic ROI

When you strip away the corporate veneer, you build stronger relationships, higher retention, and measurable growth.

Explore Demelza's Strategy

Demelza's "Marketing Engineering" approach isn't just about brand; it's about applying Product Management rigour to business culture. Explore how this mindset shapes our entire organisation.

The Co-CEO Series: Explore the humorous strategic vision driving Patient Zero.
Experience Design (UX/UI): See how we apply this same "Product Thinking" to client applications.
Life at Patient Zero: Have a sneak peak at what life it like within PZ.

Ready to Innovate?

Partner with a consultancy that leads with strategy.

ABOUT THE ARN INNOVATION AWARDS

The ARN Innovation Awards are the premier recognition program for the Australian ICT ecosystem. The Marketing Excellence category celebrates leaders who demonstrate creativity, strategic execution, and measurable business impact.

Triple Finalist for Enterprise Innovation & Technical Excellence (ARN Awards 2025)

Mon, 27 Oct 2025 01:55:35 GMT

We are proud to announce that Patient Zero has been named a triple finalist at the ARN Innovation Awards 2025 . This recognition underscores our commitment to 100% onshore capability and technical excellence in delivering complex enterprise software solutions across Australia.

Validating the Embedded Model (Enterprise Innovation)

Our nomination in the Enterprise Innovation category validates our unique embedded engineering model. Unlike traditional outsourcing that simply fills seats, our approach focuses on deep integration to solve high-stakes challenges for Australia's largest organisations.

This recognition highlights our success in helping 1000+ employee organisations tackle technical debt, enhance security, and drive digital transformation. It proves that 100% onshore teams, working in real-time collaboration with client stakeholders, can deliver complex modernisation outcomes at scale that offshore models cannot match.

Leadership in DevSecOps & AI (Technical Excellence)

Marketing Excellence & Product-Led Strategy

Why This Matters

For our clients and partners, these nominations serve as independent validation of our delivery model.

Enterprise Grade

Being named a finalist for Enterprise Innovation verifies that Patient Zero is a top-tier partner for large-scale digital transformation, capable of solving high-stakes challenges for organisations with 1000+ employees.

Technical Authority

Our leadership in modern software engineering practices, specifically DevSecOps maturity and AI-augmented workflows, has been recognised as a strategic asset that reduces delivery risk and technical debt.

Multidisciplinary Leadership

Our unique approach combines technical depth with Product and UX mastery. This acknowledgment of our marketing strategy, led by a former UX Leader of the Year, proves that we apply rigorous delivery principles to every part of our business.

Local Trust

As one of only a handful of finalists selected from over 470 nominations, this cements the value of our 100% onshore model. It confirms that Australian-based teams drive better outcomes than offshore alternatives.

About the ARN Innovation Awards

The ARN Innovation Awards are the market-leading platform for the Australian ICT ecosystem, celebrating the achievements of partners, vendors, and distributors. In 2025, the awards received over 470 nominations, making Patient Zero's selection as a finalist in three categories a significant mark of distinction in the Australian channel.

" The calibre of this year's Innovation Awards finalists is a true reflection of the creativity, resilience and forward-thinking spirit driving the tech industry forward, " said Julia Talevski, ARN Editor.

Explore the Capabilities Behind the Awards

Embedded Software Teams

See how our award-winning 100% onshore model drives sovereign capability and enterprise innovation. Read More

App Modernisation & AI

Discover the technical excellence strategies we use to reduce technical debt and modernise legacy systems. Explore Modernisation

Product Strategy & UX

Learn how we apply experience design principles to solve complex B2B challenges. View Product Strategy

Bring Award-Winning Innovation to Your Next Project

Leverage the same enterprise-grade capability and technical excellence that the ARN judges recognised. Partner with a 100% onshore team that delivers.

Gartner 2025: The AI Hype Twist & The Human Element

Mon, 29 Sep 2025 00:55:09 GMT

EDITORS NOTE

In this strategic reflection, Patient Zero Technical Leader Hanieh Madad unpacks the key takeaways from the Gartner IT Symposium 2025. While the industry buzzes about tools, Hanieh argues that the true driver of AI maturity is something harder to buy: a culture of high trust and deep autonomy.

Key Takeaways for Leaders

Trust Outperforms Talent: As highlighted by Ash Barty (and proven at Patient Zero), high-trust environments are a competitive edge. You cannot deploy AI-augmented workflows if your team is afraid to experiment.

AI Amplifies, It Doesn't Replace: The goal of AI in modern engineering is to handle repetitive tasks so humans can focus on cognitive problem-solving. This requires a shift from "proving yourself" to "improving yourself."

Readiness > Strategy: You don't need a massive top-down AI transformation. You need small, autonomous teams who are "ready" to pick up the tools and innovate from the bottom up.

Beyond the Noise

At Gartner Gold Coast 2025, everything was about AI — automation, efficiency, disruption, predictions. AI, AI, AI. But in between all that noise, I found myself thinking about how I work, and how I’ve found working at Patient Zero. Some of the things they talked about, like trust, autonomy and team culture, are the things I’ve experienced here.

When Autonomy Is Real: From Scepticism to Trust

Ash Barty’s keynote really stayed with me. She said high-performing teams aren’t just about talent — they’re about trust. And her “no d…heads allowed” rule? Direct and to the point. But it was what she said next that stuck with me more: trust isn’t soft. It’s a competitive edge.

That hit me on a personal level.

A few years ago, in my interview with Patient Zero, they talked a lot about team autonomy, collaboration, and flexibility. It all sounded great — maybe too great. After working in different companies, across countries, for more than 20 years, I’d seen that kind of language in company slides before. Leaders often like the idea of autonomy — but when it’s their own team? They still want control. Flexibility sounds good too, but when it’s tested, most places just snap back to old habits. And don’t even get me started on what many places call “diversity.” Most of the time, it’s just in the photos — you’ll see different faces on the website, but behind the scenes, everyone still thinks the same way. That’s not real diversity.

So, I listened. But I didn’t believe it. Not really. Still, something told me to give it a go.

When I joined, nothing felt particularly different. I was busy coding, doing the usual. I forgot about all that stuff they’d said. But slowly, I started noticing I could make changes. I didn’t need permission or a formal role — I could just start. And even more surprising? The leadership team encouraged it.

That kind of trust isn’t just a performance. It’s real. And it shows up in small moments, not big announcements.

Ash was right. Trust outperforms talent. And at PZ, I’ve seen that autonomy and trust aren’t just talked about — they’re things you notice over time.

Navigating Generational Diversity with Attention and Respect

One of the big takeaways from Gartner was how we now have five generations working side by side — Boomers, Gen X, Millennials, Gen Z, and now Gen Alpha. Everyone talks about communication styles, but the real challenge is attention.

We live in a world where people switch tasks constantly. It’s harder than ever to focus. But for me, attention is more than just not being distracted — it’s about actually listening to people. Making sure they feel heard.

And that’s something I really care about. I don’t come to work to prove myself — not my knowledge, not my experience, not my seniority. I come to improve. I want to get better every day. Because that “prove yourself” mindset can create so much unnecessary conflict. I’ve seen it too many times. People cutting me off mid-sentence, rewording my ideas to make it sound like it was theirs. And I stayed quiet — not because I didn’t have something to say, but because I didn’t want to play those games.

But something shifted for me at PZ when I started working with a younger generation. I found myself trying to help them speak up and that helped me realise I needed to do the same for myself. Respecting others also means respecting yourself. I started being more present, more intentional — not just with others, but with how I carried myself, too.

This generational mix can be tricky. A Baby Boomer might expect full stops in every sentence. A Gen Alpha might read that same full stop as passive-aggressive. It can be confusing. But it’s also beautiful. If we can stay curious instead of defensive, we grow.

At PZ, the ratio between juniors and seniors is flipped. Previously, I’d worked in teams with one or two juniors and five or six seniors but now I work with more juniors and intermediates and just one or two seniors. And honestly, it’s been one of the best leadership lessons I’ve had. It’s not about showing you know everything. It’s about slowing down, creating space, and listening better — including to yourself.

AI Should Amplify Us — Not Replace Us

One thing Gartner made clear: AI is not about replacing people. It’s about amplifying them. And the numbers backed it — only about 1% of job losses were linked to AI by early 2025. That didn’t surprise me.

I’ve always loved tech that helps humans. Even at home — robot vacuums, a dishwasher with a timer — anything that gives me a bit of breathing room. But I’ve also learned that it’s easy to go too far and get dependent on the tools. We can’t afford to lose our edge. We need to help ourselves — and especially the younger generation — to keep sharpening our skills.

That’s why I care so much about cognitive skills. AI should support growth — not replace it. Let it handle the repetitive stuff, sure. But thinking, problem-solving, creativity? That still needs to come from us.

And this is where the level high of trust at PZ gives our teams an edge. Because teams didn’t need to wait around for permission, they just started experimenting with AI tools in ways that made sense for them. No pressure. Just readiness.

In my own team, I suggested we start a small internal open-source-style project — something fun to collaborate on for an hour every fortnight, just to experiment and learn AI programming together. I didn’t know how people would respond, but they loved it. The excitement was real. Everyone got involved. They brought their own ideas, their own energy.

It reminded me of that quote by Steve Jobs: “I didn’t hire smart people to tell them what to do — I hired them so they can tell me what to do.” And that’s what happened. These small things really do matter. We don’t need huge top-down strategies. We just need to take small steps and help each other get ready. Like one of the Gartner VPs said — AI is like a Swiss Army knife. It’s just a tool. But in the hands of people who are ready, it becomes something powerful.

Final Thought: It’s Not About Being Ready — It’s About Getting Ready Together

If there’s one thing I took away from Gartner this year and from the last few years of working at Patient Zero it’s this: The future isn’t going to wait for us to be perfectly ready. Whether it’s AI, generational shifts, or rethinking what team culture really means, none of it happens overnight.

But what does make a difference is being in a place where people are open, curious, and willing to try. A place where trust isn’t just a word. Where juniors are given space. Where seniors are still learning. Where you’re not told to prove yourself — you’re encouraged to grow. We don’t have all the answers. And that’s fine. But we’re asking the right questions. And we’re figuring it out together.

Build an AI Ready Culture

AI & Emerging Tech: See how we help enterprises move from "Hype" to operational reality.
Embedded Software Teams: Engage a team that already has the "Trust & Autonomy" culture you need to succeed.
Working at Patient Zero: Explore the engineering culture that empowers leaders like Hanieh.

Join the Conversation

Hanieh Madad is a Principal Software Engineer at Patient Zero who believes that engineering culture is built, not bought.

The Joy of Faking It: Synthetic Data & Legacy Modernisation

Thu, 25 Sep 2025 06:24:23 GMT

EDITORS NOTE

In this technical deep dive, Principal Software Engineer Joe Cooney explores a critical component of App Modernisation: how to rigorously test legacy environments without exposing sensitive client data. As data breach penalties rise, moving from "Production Data" to "Synthetic Data" is no longer just a developer convenience; it is a strategic risk control.

Key Takeaways for Leaders

Risk Reduction: Using production data for testing is a major security liability (as seen in the Optus/Medicare breaches). Synthetic data eliminates this risk entirely by removing PII from the equation.

Edge Case Testing: Real data is often "too clean" or missing specific scenarios. Synthetic data allows engineers to generate millions of rows of "messy" data to stress-test systems before launch.

Compliance & Speed: Synthetic data removes the bureaucratic red tape of getting approval to use client data, allowing teams to spin up environments instantly and iterate faster.

The High Cost of "Real" Data

For greenfield projects, we typically bake in a set of fake APIs with minimal data (if we’re using an API built by a different team) or methods in our own code to seed data stores with fake data (if we’re also building the API). This set of fake data can grow and evolve with the product. Although this takes discipline, it can be managed along with similar tasks like writing unit tests, ensuring dependencies are kept up to date and the like.

The situation is different for a so-called “brown-field” or legacy system – this system may already have many years of real-world data accrued, and it can be very tempting for stakeholders to want to use this data for manual testing of the system, especially if they are already in the habit of doing so.

Unfortunately, using real-world data for testing can be a recipe for disaster. There have been many instances where lax security on non-production systems, coupled with the use of real-world production data, has resulted in data breaches. In 2022, up to 9.7 million Optus customer details were scraped from an unsecured API – an insider claimed this was caused by a test API being inadvertently exposed to the public internet – a claim which Optus denies. A recent example is API security testing firm APIsec, which in April 2025 left a database used for “testing purposes” unsecured on the internet, which contained 12TB of customer data and API security information.

As part of Australian law, company directors can face personal liability for data breaches as part of the notifiable data breaches (NDB) scheme. In the face of high-profile Medicare and the aforementioned Optus breaches, the penalties for serious or repeated breaches were raised, up to $2.5 million dollars for individuals, and up to $50 million for corporations. This has created further incentives to move away from using real-world data, but often it can seem like such a daunting task that it can fail to gain traction.

Below is a real-world example of how we were able to achieve this on a project PZ was working on. It is unlikely your project will face exactly the same set of constraints, but we hope by sharing what we did it can give you some ideas on how you might tackle this if you want to undertake it yourself.

Project Background

The project we inherited was almost 10 years old and consisted of a set of application-specific APIs backed by a relational database. These APIs served up the data for a front-end developed in a slew of different UI technologies, and the modernisation of that will have to be the subject of a follow-up article.

These application-specific APIs (from here on out referred to as “the application”) are also integrated with other internal systems via “shared” APIs. The “shared” APIs aggregated and exposed a number of core domain objects for the application to read, but not modify. Historically , developers spun up a new local instance of the application and its database, connected to the VPN, and pointed their local instance to dev copies of these internal APIs running inside the internal network, which had a backup of production as their data set. In test/UAT/staging environments, the application instance also had a backup of the prod application database. In the test environment, for example, a user could log in and interact with a recent copy of the same data they could access in production. Much of this data was sensitive in nature and contained a lot of PII.

Improving the Local Dev Story First

Our first step was to remove the dependency on these “shared” APIs and connecting to the VPN for local development. In the application all access to these “shared” APIs was via proxy wrappers which were injected into our application at run-time via a dependency injection (DI) container. This had been done by the previous development team and allowed the application code to be unit-tested in isolation of the “shared” APIs. We created a number of “fake” implementations of these API proxies, and a configuration switch to inject either all the real proxies (the current state of affairs) or all the “fake” ones (our synthetic data APIs). This allowed new developers to be productive more quickly (receiving and configuring access to the VPN was sometimes a slow process) and to continue working during outages and issues with the internal “shared” APIs.

Real-Looking Data

It soon became apparent that to create a real-world volume of synthetic data we didn’t want to be hard-coding static responses in our fake APIs. We created a SQLite database that contained a representation of the business domain that was sufficient to provide all the data our fake versions of the APIs needed, and wrote some code to populate that database with real-world-looking data.

For this we used a library - most frameworks have one or more packages that can create real-looking people, addresses, orders and the like. In Ruby there is Faker, in .NET there is Bogus, and in JavaScript there is faker.js. We created a startup process that seeded this fake data if it wasn’t already present. The surface area of the “fake” APIs was large – maybe a few hundred methods, but many of the methods were only used in a few niche areas. We worked incrementally over a few sprints (in parallel with our regular feature delivery) following the pareto principle to implement the small subset of fake APIs necessary for the major parts of the application to work. Going forward as people hit road-blocks they would implement any required synthetic API methods. Returning explicit errors from not-implemented synthetic methods prevented silent failures.

Local Data Volume

Local development had always had the shortcoming of not having any data in the application itself. The only local application-specific data was what you entered for yourself over time. Now that we had local versions of these “shared” APIs serving up synthetic data the next step was to extend the synthetic data generation process to populate data into the local “real” application database. The domain model for some of these processes was quite large and involved, and creating large volumes of this data slowed down the startup time for local developers, so we switched these to a background process. Although some areas of the application which we hadn’t worked on actively were not seeded, we took an “on-demand” approach and developers extended the seed process as new areas of the application were developed, or existing areas were otherwise touched.

Taking it to Other Environments

Once we had this working locally it was easy to run some experiments where we switched over other environments to use this fake data via a configuration switch.

Additional Safety Benefits of Synthetic Data

In addition to the obvious information security advantages there were some other advantages to synthetic data that improved our development process.

Data volume – Synthetic data allowed us to create a volume of data for a new feature where no real data currently existed, and test it out with volumes of data that we might not expect to see until many months after th e feature went live. Once we had a process for programmatically generating a hundred records it was an easy matter to change some parameters to generate tens of thousands of records.

Data stability – Using backups of production data for testing often required a lot of effort to hunt for or modify real-world d ata in a particular state to test a scenario. The “shared” data provided by the APIs could not be edited from within the application and required complicated developer knowledge of additional systems to modify. With synthetic data we could create whatever data we needed to test a particular scenario, even if these were relatively rare in the real-world. This was beneficial for manual testing, but also for end-to-end UI automation tests and integration testing.

Training environments and videos – Synthetic data allowed us to set up training environments where prospective users could be given access without any information privacy concerns. Training materials and repro information for bug reports could be created directly from the synthetic environment without any requirements for images or videos to be redacted.

Principles of Synthetic Data

During our development a few principles emerged which guided our generation of synthetic data:

Synthetic data should look "real-world" – we tried to spend a small amount of extra effort making our data look real-enough that it could be included in a screen-shot or training video and not stick out as being obviously fake, and to make it varied enough that many different real-world scenarios could be found in it. When new bugs were discovered that relied on particular data setup we could extend the seed process to always create this data so the scenario could be tested again in the future.

The synthetic data generation process should be deterministic – we wanted the seed process to produce the same data each time so that if an issue was found in the test environment using synthetic data, a developer on their machine could use exactly the same data when working to fix the issue.

The seed process should be fast – we wanted developers to be comfortable with frequently blowing away their local databases and re-seeding it without it being a productivity blocker, so we made the seed process fast. Anything we couldn’t make fast on startup we moved to a background process.

Synthetic Data vs. Anonymised/Redacted Data

Another approach to addressing the information security concerns of production data is to anonymise, sanitise or redact the production data before it is used elsewhere. Depending on your project setup, this may be a great choice (and certainly better than not doing anything). We chose not to do this on this project because the operational complexity for local development – setting up and running instances of the legacy “shared” APIs, and restoring their respective databases from backups – was much more complicated, and when we began the journey towards synthetic data, we lacked the organisational buy-in that this approach required. There is also always the concern that anonymised data might not be sufficiently anonymised, and that a clever attacker could find ways to re-identify particular domain entities.

Your project could also consider a mixed approach where anonymised data is used in some environments, and synthetic data is used in others, or where anonymised data is augmented with synthetic data to create data volume, and/or thwart re-identification.

Modernise Your Legacy Systems

App Modernisation: See how we safely upgrade legacy systems without breaking them.
Software Development: Explore the engineering standards we use to protect client data.
Managed Services: Learn how we maintain security across the application lifecycle.

Join the Conversation

Joe Cooney is a Principal Software Engineer at Patient Zero and a veteran of the Australian software scene.

An alumni of the "Readify days," Joe has spent decades modernising enterprise applications and accumulating enough war stories to fill a library. When he isn't architecting complex migrations or designing Red Team challenges to test security boundaries, he can be found fueled by coffee or chasing powder on a snowboard. Famous claim to fame: He is the literal Nomenclator of Stack Overflow.

GPT-5 Migration: Tricks, Pitfalls & Hidden Costs

Mon, 25 Aug 2025 06:55:47 GMT

EDITORS NOTE

At Patient Zero, we don't just read the release notes; we stress-test the APIs. In this technical advisory, Alex Petrakis shares early findings from our GPT-5 migration tests, revealing critical issues with token economics and latency that every Engineering Lead needs to factor into their roadmap.

Key Takeaways for Engineering Leads

The "Reasoning" Tax: You can no longer turn "Reasoning" fully off. This adds a minimum of ~1,000 tokens to even simple requests, blowing out operational costs if not managed carefully.

Unpredictable Latency: Response times in early tests fluctuated between 8 and 40 seconds. For real-time user-facing apps, this unpredictability is a potential dealbreaker compared to the lightning-fast GPT-4o.

Migration Strategy: Don't upgrade blindly. We advise running parallel tests (A/B testing) to measure the "Intelligence vs. Cost" ratio before deprecating your GPT-4 infrastructur e.

Beyond the Hype

GPT-5 - the highly anticipated latest version of OpenAI’s hit the streets a few weeks ago. Despite of some breathless commentary from influencers who had been given early access, the eventual release was a bit underwhelming (in a way that only something that would have seemed like science-fiction a few short years ago but now seems passe, can be). Aside from the quality of the model itself, which some people have claimed was more about lowering OpenAI’s costs than delivering a better result, there are some issues that the change to GPT-5 has introduced when integrating it into a product which we thought we should share.

Problem 1: You can’t accurately assess cost anymore, or set max output tokens

OpenAI have been accused of confusing model names in the past with similar sounding but different names like GTP 4o vs. GPT o4, and adjectives like mini, turbo, pro, nano, thinking and “deep research” added to model names . GPT 5 attempted to resolve this (kind of) by offering a single API that routes to different models under the covers. This problem is not completely resolved because they ALSO offer mini and nano versions of GPT-5. All of the GPT-5 family of models are reasoning models, you can’t disable reasoning, and reasoning uses up tokens. How many tokens? You can’t control that – there is no max reasoning tokens field, only a max output tokens.

Although you can’t disable reasoning altogether, you can set it to “low” which is a hint to the model as to whether it should reason or not. From our tests the model ALWAYS decided to reason, which took a minimum of 1000 tokens, even for a tiny single-word message. If you’ve set the maximum output tokens to 500, and GPT-5 decides to “reason” about your very simple message and burns through 1000 tokens it ends up returning an empty response.

OpenAI in their advice on prompting the reasoning models, suggest allocating at least 25,000 tokens for reasoning and adjust down accordingly, but if the final number you arrive at is only 1/10th of this that’s still a lot of tokens being used, and cost, for each request.

Problem 2: Model Speed

We gave GPT-5 the benefit of 5 days grace after the release, but in our tests the performance of the model was pretty bad and extremely unpredictable, even with reasoning set at low. The quickest response was 8 seconds, whilst the slowest was close to 35-40 seconds. This can be mitigated by streaming the response, but users will probably still tire of a response that is streamed so slowly. This is in sharp contrast to GPT-4.1 mini which responded in a predictable 3-4 seconds and felt lightning-fast by comparison when streamed.

Problem 3: Model Intelligence

GPT-5 launched to much fanfare and expectations regarding its capabilities, with some wide-eyed accelerationists believing it could be the first example of Artificial General Intelligence (AGI). OpenAI’s Sam Altman said:

"We think you will love using GPT-5 much more than any previous Al. It is useful it is smart it is fast [and] intuitive. GPT-3 was sort of like talking to a high school student. There were flashes of brilliance lots of annoyance but people started to use it and get some value out of it. GPT-4o maybe it was like talking to a college student… With GPT-5 now it's like talking to an expert - a legitimate PhD level expert in anything any area you need on demand they can help you with whatever your goals are."

Although some typical stumbling-blocks like counting the number of times the letter 'r' appears in the word strawberry had been special-cased, it wasn’t long before the usual set of problems that LLMs struggle with had been identified and called out , and nearly 5000 people successfully petitioned OpenAI to keep access to the older GPT-4o models in ChatGPT.

In our tests GPT-5 nano, mini and regular, with medium reasoning (1-2000 tokens) and small text inputs failed in comparison to GPT-4.1 mini. Instructions that we explicitly said not to include in the output were included. Reasoning seemed to be a wild-card here – some of our tests passed and then failed on subsequent runs, and it was hard to get consistent output.

Conclusion

We’d advise anyone thinking of migrating to GPT-5 to hold fire until some of these issues are explored further, or at the very least run a suite of tests to evaluate the quality, speed, and cost of the model relative to others. The issues with the additional uncontrollable cost of reasoning tokens could be mitigated by OpenAI by disabling reasoning altogether, however it’s possible this would further degrade the quality of the GPT-5 responses compared to the 4 family of models.

AI That Actually Works

AI & Emerging Tech: Discover how we build operational AI that balances cost and performance.
Software Development: See our engineering standards for API integration and testing.
App Modernisation: Learn how we migrate legacy systems to modern AI workflows safely.

Architecting File Previews in .NET Core: UX & Engineering Trade-offs

Wed, 06 Aug 2025 05:27:37 GMT

EDITORS NOTE

In enterprise software, friction kills adoption. Forcing users to download a file just to view it is a major UX flaw. In this engineering guide, Katelyn Cleary breaks down the architectural decision-making process for solving this problem in .NET Core, comparing "In-Process" (Telerik) vs. "Containerised" (Gotenberg) approaches.

Key Takeaways for Technical Leaders

UX Friction: Every "Download > Open > Close" cycle wastes time. Inline previews are standard for modern enterprise apps; your users expect them.

Build vs. Buy: The article contrasts a commercial library (Telerik) with an open-source container (Gotenberg). This highlights the need to weigh licensing costs against infrastructure complexity.

Decoupling Logic: Using a containerised service (Gotenberg) keeps your core application lightweight and decoupled from heavy file-processing logic, a key principle of Cloud-Native Architecture.

The Challenge: Making Files Browser-Friendly

The ability to preview files directly within a web application is a major enhancement to user experience. Enabling users to view uploaded documents or images without needing to download them first saves time and reduces frustration. This can be a game changer in document-heavy applications where users frequently and recursively review and upload files through the interface.

There are many libraries, packages, software subscriptions, and external API services (you name it!) that exist to solve this problem. But when spoiled for choice, it can be difficult to decide on which kind of solution best fits your application’s needs.

This article explores this conundrum in the context of .NET Core web applications, with a focus on their specific quirks and requirements.

File Conversions in .NET Core Web Applications

To preview most file types in a web application, applications first need to convert them into a browser-friendly format. For documents like Microsoft Word, Excel spreadsheets, and PowerPoint presentations et cetera, this typically means converting them to PDF, which thanks to Mozilla’s pdfjs can be easily rendered in the browser

Converting any file to another type requires some kind of file processing logic. The specifications for some file formats are huge, and require significant effort to work with, so rather than reinventing the wheel, developers typically seek existing solutions that are well suited to the job, reliably maintained, and well loved by other developers in the community.

In .NET Core applications, two common strategies for handling these conversions are:

Integrating NuGet packages directly into the application’s logic

Making requests to a hosted, containerised API service

An example of each approach is explored further below, however, it is important to remember that these are just two of the many options available.

Approach 1: Telerik Document Processing NuGet Packages

Telerik are a Bulgarian software company that build software tools, libraries and components for application developers. They got their start in the 2002 focusing on components for the then-recently-announced .NET framework. We’ve used Telerik's libraries here as an example of the “in process” procedural approach to document conversion, but there are other component vendors that provide similar libraries. If you have particular features you need or an existing vendor you use for components like these it is worth checking their offerings.

Telerik’s document processing NuGet packages can be added directly into a project via the package library or private NuGet streams. These classes can be referenced and used throughout internal logic, allowing developers to call document processing methods within custom classes in their application.

Telerik’s Document Processing Library is a great example of this approach. Available through a private NuGet feed upon purchase, it offers a comprehensive set of tools for converting, manipulating, and even creating documents from scratch. Supported file formats include DOCX, RTF, HTML, TXT, XLSX, CSV, ZIP, and PDF.

To use Telerik, developers need to install the relevant packages and reference them within their code. Telerik Document Processing comes out-of-the-box with straightforward methods that provide the bulk of the basic functionality, and then allows the developer to build upon this, allowing flexibility to extend functionality with custom logic or by using other built-in document processing methods.

Approach 2: Gotenberg Containerised API

Outside of the NuGet universe, there are containerised API solutions such as Gotenberg which offer a powerful alternative. Gotenberg is an open-source API that hosts robust endpoints that manage the conversion of many different file types into PDFs with ease, including but not limited to PPTX, DOCX, RTF, HTML, TXT, XLSX, and more. The full list can be found in their documentation for the various API routes .

By running Gotenberg in a secure server environment and sending requests from the main application, developers can offload the conversion logic entirely. This decoupling simplifies maintenance and can simplify the integration process too.

Developers also benefit from the peace of mind that comes with using a community-supported tool that many contributors actively review and improve to keep it reliable and up to date.

Comparison:

NuGet Packages vs Containerised API

Below is a quick breakdown of the comparison between these two solutions:

Both approaches are viable, each with their own strengths and trade-offs. If developers need a more custom integration with close-to total control over the conversion logic, a commercial NuGet package like Telerik Document Processing may be the ideal choice. On the other hand, if a decoupled, open-source, low-maintenance solution with broad format support (including PowerPoint – PPTX conversions to PDF) is required, a containerised solution such as Gotenberg might just be the best solution.

Ultimately, the choice depends on the application's requirements, infrastructure, and development preferences. Both solutions will get the job done in different ways, and both will provide file conversions successfully to the application so it can display them on the front end. Speaking of which, what exactly does the front end integration look like?

What about the Front End?

Whichever backend solution you choose for file conversion, you'll also need a front end component to display those files to users on the UI (User interface).

HTML (Hypertext Markup Language) which is a language that is used to build the structure of a web page, provides native support for rendering image formats such as JPEG, PNG, and GIF using the <img> tag, and plain text files can be parsed and displayed using elements like <pre> or <code>. Implementation for previews of these file types is straightforward, and involves receiving the file from the application backend, and either referencing the file URL in the src attribute (in the case of images) of the <img> tag, or parsing its content for security purposes and rendering the content within a <pre> or <code> tag.

For PDFs, while HTML does offer basic native support through the <embed> element, these options are limited in terms of styling, interactivity, and control. However, depending on the framework being used on the front end there may be other options which can help.

For instance, in React-based applications for example, open-source packages such as react-pdf (which uses pdfjs as a dependency) allow developers to render PDFs directly within other custom React components, offering paging and scrolling, as well as font-family integrations. Tools like react-pdf integrate well with React applications, are maintained actively by the community, and can be styled and extended as much as needed to match any web application's design requirements.

For example, below is one implementation that our developers at Patient Zero have created using react-pdf to display pdfs, images, and plain text files on a modal component in a web UI application.

Conclusion

Delivering a rich feature like interactive preview of Word and Powerpoint files in a web application would have been prohibitively expensive not so long ago, but thanks to open-source tools like pdfjs and Gotenburg it is now a capability that any team can add to their product. Commercial tools like Telerik’s suite provide additional features like customisation options, document editing, and professional support. Either option can be used to deliver a robust solution, and it is possible you could end up using both in different situations if file previews are an important part of your application. Depending on the richness, type and size of documents you need to preview one of the two approaches may have clear advantages, so it is worth thoroughly testing your proposed solution with a variety of documents from your domain to ensure they are converted properly. Happy file previewing!

Build Better Enterprise Apps

Web Apps & Portals: Discover how we build user-centric portals that drive adoption.
Software Development: Explore our .NET engineering standards .
UX/UI Design: See how we design friction-free workflows for complex systems.

Winner: Technical Award & Engineering Excellence (WIICTA)

Tue, 20 May 2025 00:18:44 GMT

We are proud to announce that Hanieh Madad has won the Technical Award at the WIICTA ceremony. This victory underscores Patient Zero's commitment to technical authority and our ability to foster world-class engineering talent within our 100% onshore Australian teams .

Defining Technical Authority

This honour celebrates exceptional technical and engineering expertise, advanced problem-solving, and deep product, solutions, and services knowledge.

Hanieh’s win recognises both her impressive international career and the impact of her work spearheading complex client projects at Patient Zero. For our enterprise partners, this validation is crucial. It confirms that the architects leading your modernisation and AI initiatives possess the deep technical rigour required to de-risk complex delivery.

Culture of Collective Growth

True technical leadership extends beyond individual contribution. As Hanieh notes, the environment at Patient Zero is designed to foster capability uplift across the entire team.

"I am truly honoured to receive the WIICTA award in the 'Technical' category," said Hanieh.

"I feel incredibly fortunate to work in such an inspiring environment, where I can grow personally while contributing to our team’s collective growth."

Congratulations Hanieh! This recognition is well-deserved and reflects the standard of excellence we bring to every engagement.

Why This Matters

For our clients, this award serves as independent validation of our software engineering standards.

Technical Authority

This award recognises deep technical expertise, validating Hanieh's role in shaping our AI & Emerging Tech strategies.

Software Engineering Culture

It proves our commitment to fostering an environment where complex technical problems are solved with precision and creativity.

Local Excellence

Competing against national finalists, this win reinforces the calibre of talent available in our Brisbane-based teams.

Ready to Modernise Your Delivery?

Partner with the team recognised for setting the standard in Australian engineering.

About the WIICTA Awards

The Women in ICT Awards (WIICTA) celebrate the achievements of female leaders across the Australian technology channel. By recognising technical excellence and innovation, the awards highlight the individuals shaping the future of the industry.

Hanieh's selection as the winner in the Technical Category distinguishes her as a leader among her peers in the national market.

Explore the Capabilities Behind the Awards

AI & EMERGING TECH

Discover the advanced data and AI strategies Hanieh champions to move beyond hype and deliver secure, operational value. Read More

SOFTWARE DEVELOPMENT

Explore the world-class engineering standards and 100% onshore culture that underpin our award-winning delivery. View Software Development

enterprise app modernisation

See how we apply deep technical rigor to de-risk complex legacy migrations and reduce technical debt. Explore Modernisation

Designed Up: The ROI of Design & Tech Collaboration

lennah.kuskoff@pz.com.au (Lennah kuskoff) — Mon, 05 May 2025 23:14:15 GMT

Image credit: ThoughtWorks

EDITORS NOTE

One of the most expensive mistakes in enterprise software is the "Hand-Off", where Designers draw pictures and Developers try to build them later. In this recap of our session with author Emma Carter , we explore the financial and operational benefits of Co-Creation , proving that design is not just about aesthetics, it's about efficiency.

What Can Happen When Design and Tech Actually Collaborate?

At PZ, we’re always exploring how design and technology can better complement each other. We recently hosted a Lunch & Learn featuring Emma Carter, Experience Design Leader and author of DesignedUp, whose talk was a candid, experience-rich exploration of what it takes to create great products, and even better collaboration between disciplines.

Emma’s career spans over 20 years and several countries, having started in a small UK village and eventually landing in Australia. Along the way, she’s built design businesses, worked with global organisations, written books, and taken some memorable detours, including training non-designers to conduct customer interviews and running creative workshops with reluctant executives. Her journey, she explained, is typical of many designers: it’s nonlinear, exploratory, and built around saying “yes” to opportunities and figuring out the path along the way.

Work Together, Not in Silos

What stood out from the start was Emma’s belief that design is not a department but rather a way of thinking and solving problems. And the best solutions come not from working in silos, but from collaborative, interdisciplinary approaches. She made this point clear through several examples, but one story captured it best. Emma recounted being the sole designer on a team of 25, embedded in a client’s digital transformation effort. The client had never involved customers in the design process before and had historically produced “designs” by way of a manager sketching out UI ideas based on other platforms and handing them directly to developers. Emma helped change that.

With a deadline looming and only one iteration available for research and testing, she didn’t try to do everything herself instead, she rallied the wider team. She brought in people from delivery, marketing, and customer engagement who were interested in improving the customer experience. She trained them to conduct interviews and gather insights, pairing them with consultants who already had research experience. In just eight days, they conducted 19 customer interviews, logged over 300 observational insights, and held a co-design workshop. The result wasn’t just an MVP aligned with real user needs, it also helped prevent the development of a feature requested by an executive that users overwhelmingly rejected in testing.

This story served as a reminder that the impact of design isn’t about numbers on a team. Emma pointed out that designers are often outnumbered in tech companies but that doesn’t mean their voice can’t be the most powerful in the room. By connecting the design process to business outcomes, showing the value of user insights, and aligning with what stakeholders care about, designers can lead even when they’re the minority.

Learn Their Language

This isn’t just a designer’s challenge. Developers often find themselves in a similar bind: full of technical insight, but unsure how to frame it in a way that resonates with executives. Emma highlighted that while developers and designers approach problems from different angles, what they share is a desire to solve them. The barrier is often language. Business leaders don’t necessarily care about code architecture or wireframe fidelity. But they do care about metrics like efficiency, cost savings, customer retention, and return on investment. Learning how to “speak business” can strengthen our ability to influence outcomes. Emma shared how she applied this when building a business case for a design system. Knowing the stakeholder she needed to convince was numbers-driven, she tailored her pitch accordingly. She framed the ask with specifics: $181,000 in investment would return $522,000 in savings (quantified through efficiency gains and reduction in rework). She even predicted the rising cost of tech and design debt over time if the system wasn’t built, supported with data from JIRA and backlog analysis. Her pitch worked because she translated design needs into delivery outcomes. This, she explained, is the level of strategic storytelling we need more of, in design and across disciplines.

Working together doesn’t stop with alignment on strategy. Emma stressed that real collaboration between design and development happens when they co-create instead of handing-off. Developers shouldn’t be brought in after a design is “done,” nor should designers be locked out of implementation discussions. When design and tech are both present from the beginning, they can spot risks early, build more scalable solutions, and create better user experiences. This approach isn’t just more efficient, and it’s more human.

Pick Your Battles

Convincing people to think differently isn’t always easy. Emma shared how she once facilitated a discovery workshop for a group of executive bankers who were openly resistant to co-design and refused to sketch. Rather than abandoning the exercise, she found a workaround: a quirky creative activity known as the “Silly Cow” exercise. Participants were given cow-related attributes and challenged to invent absurd businesses like “MooBa” or “Adopt-a-Cow.” This playful method completely changed the energy in the room. By the end, those same executives who initially resisted sketching were fully engaged, contributing creative MVP ideas and even shifting the project’s focus to a different part of the user journey. The lesson? Sometimes, creativity needs a nudge and the right activity can open up even the most sceptical minds.

Not every battle is worth fighting, though. Emma was transparent about the reality that there will always be the “1 percenters”; those people in organisations who simply don’t see the value of design or collaboration. Whether it’s the stakeholder who thinks designers just “make things look pretty,” or the manager who insists no one needs research because they already “know what users want,” these individuals can derail progress if you let them. Emma’s advice was clear: pick your battles. Know when to walk away, and when to push. Protect your time and energy for the work that matters and the people who want to do it with you.

Emma also explored how design contributes to internal business structures beyond just the product interface. From influencing workflows and onboarding journeys to mapping employee experiences and enhancing communication, design thinking plays a role in shaping how an organisation operates. If companies want to retain talent and innovate meaningfully, they can’t afford to limit design to surface-level aesthetics.

This extended into a discussion about executive priorities such as reducing waste, increasing revenue, expanding market share and how design (when strategically positioned) contributes to all of them. For example, implementing a thoughtful onboarding experience doesn’t just “look nice.” It reduces churn, improves performance, and increases loyalty. These are the stories businesses need to hear, because that’s the language they understand.

Emma closed her talk with some memorable quotes and personal stories and reminded us that not every path is smooth. But for those willing to keep learning, collaborating, and experimenting, the impact can be enormous.

Takeaways for Tech Teams

Human-centred design isn’t just a “design thing”. Developers, testers, and PMs all play a role in creating better experiences.
Business language matters. Learn to translate your work into the metrics and motivations your stakeholders care about.
Designers don’t just make things pretty. They help teams focus on solving the right problems the right way.
You don’t need a huge team to make a huge impact. With the right mindset and collaboration, even one designer can lead transformation.

 Get curious, get creative, and occasionally get silly. A cow exercise might just unlock your next big idea.

If you’re looking to work better across design and tech, Emma’s insights are a great place to start. And if you haven’t already, we highly recommend checking out her book, DesignedUp , for more stories and strategies from the frontline of design leadership.

Key Takeaways for Product Leaders

The Cost of Silos : The traditional "Design then Build" waterfall model creates massive technical debt. Co-creation prevents the development of features that users (and the code architecture) reject.
Quantifiable ROI : Design isn't fluff. As Emma Carter demonstrated, a strategic design system can turn a $181k investment into $522k in savings by eliminating repetitive coding and design rework.
Language Barriers : The biggest blocker to velocity is often language. Designers speak "User Journey," Developers speak "Architecture," and Execs speak "Money." Successful leaders learn to translate all three.

Bridge the Gap

UX/UI Design: See how our designers work directly with engineers, not just near them.
View UX/ UI Design
Software Development: Explore our collaborative "Way of Working." View Software Development
Product Strategy: Learn how we align design metrics with business outcomes. Learn Product Strategy

Stop Wasting Budget on Rework

Don't let silos slow you down. Partner with a team where Design and Engineering speak the same language.

Our First "Vibe Coding" Rescue: The Risk of AI Without Engineering

Mon, 05 May 2025 23:10:07 GMT

EDITORS NOTE

"Vibe Coding", using AI to generate apps without writing code, is transforming prototyping. But what happens when the vibes run out? In this case study, Principal Software Engineer Joe Cooney walks through a real-world "Rescue Project," exposing the hidden costs of AI-generated code: inconsistency, hallucinated features, and unmaintainable state management.

A friend and former colleague reached out to me recently to ask if I could help him fix a couple of bugs in a small project he’d been working on. He was not a developer, but had worked in and around developers for his whole 20+ year career as a business analyst, product owner and program manager. With the advent of tools like Cursor and Lovable his lack of coding ability was (maybe) no longer a barrier to getting some ideas he’d been incubating in his mind for a while, out into the world. With credit card in hand, he dived headfirst into the world of “vibe” coding.

We met for coffee, and he showed me the prototype he’d built. I was quite impressed with what he showed me (running on his laptop…deploying it anywhere was a bridge he had not crossed yet) – a capable working prototype that demonstrated the ideas he was trying to prove out. I asked him about the “development experience” and he said it had been great at first, and he’d been able to make a lot of progress quickly, but at some point he hit a bit of a wall where each change he tried to make introduced more issues, and he felt like it was pointless to continue. He’d switched between a few different AI coding tools in an effort to see if the problems he encountered were specific to the tool he’d started with, but without success. The vibes had run out.

When The Vibes Ran Out

I said I’d happily take a look at what he had and give him an estimate of how long it would take to fix the remaining issues. The architecture of the solution was simple enough and well suited to what he was trying to achieve – a Supabase back-end with some edge functions. The front-end was React, Typescript and Tailwind. So far so good. I got the solution working readily enough, but started to see a lot of small and not-so-small issues when I played around with it. I think in order to give me an overview of everything, he’d carefully worked around a few issues that now came to the fore. I figured out how to work around those too and dived in to trying to fix the first issue on his list.

Fixing The 'Last Few Bugs'

In the words of Yogi Berra “you can observe a lot by just watching” and the more I looked, the more I saw. The first thing that dawned on me was the staggering lack of consistency as I tried to apply patterns that were working in one area to fix a bug in another area. Cursorrules files can be used to improve consistency, and my friend had not created one of those. Does using cursorrules go against the spirit of vibe coding? Does aiming for code consistency?

The second thing I started to notice was regarding state management – it was a mess. It made me realise all the different ways you can access state in a react application – via an API, via props, via hooks, fetched from an API, as part of the route, and so on. Once again there was no consistent approach – values were read from props that were never set that could have been gotten from the route. The nature of the app was very simple – state was a simple hierarchy being edited by a single user, and yet it still seemed like a big stumbling block.

The third thing I started to notice was bits of back-end functionality that didn’t work, but weren’t on my friend’s list of bugs. After discussing a few of these with him it became apparent that these were never features he’d asked for, but hallucinated features that had gone un-noticed because they were failing silently. Like a vestigial appendix in the code-base these could (and certainly should) have been removed, but teasing out what was “real” and not working, and what was just noise would take time.

As these issues began to mount the final epiphany I had was that (for me) it was hard to fix a system like this because my mindset was now different to fixing issues in a “normal” project. In a normal project I often push through issues by trying to think about the state of mind of the previous person working on the code – you see something in there and even though it might not be right you can see what they were trying to do. Things, even buggy or misguided things, exist for a reason. Here, there was no “they” – more and more it felt like just a lot of random code that had been welded together. I was amazed that it worked at all, and suspected and subsequently confirmed with my friend that there had been a lot of back-and-forth prompting that would have gone something like this:

user: I’m getting the following error when I do X
agent: I see there’s an issue with the DoX method, let me fix that.

user: I’m still seeing an error when I do X, it says..
agent: I apologize for the error. I see now there is another issue with the DoX method. Let me fix that.

History, Repeating

“Vibe” coding is the latest in a long list of tools from Microsoft Access, Hypercard, Visual Basic, Excel, and many “low code” tools that have allowed citizen-developers to create complex systems with no programming knowledge. Many of the aspects of this “rescue” would be familiar to industry veterans who’ve participated in similar projects for other citizen-developer programming efforts. My friend said he did find the vibe coding process to be very useful in fleshing out his ideas, but it remains to be seen whether the issues he hit can be overcome to develop production-quality applications.

Reviewing the results of my friend’s vibe coding experience I have mixed feelings. On the one hand greenfield development is notoriously one of the most productive stages in a project, so vibe-coding a POC quickly is less impressive to me. Also, it seems like vibe coding eschews many of the time-consuming parts of development (like testing) by just not doing them. On the other hand, the fact that it even works at all does still amaze me. Vibe-coding allows non-programmers to create things that they previously couldn’t, which is a step-change in capability.

The Road Ahead

Vibe-coding is an extreme form of agentic development. Practices, tools and foundational models are improving quickly in this area. I can envisage a more productive future that blends some of the speed of vibe coding with more of the rigour of current software engineering practices using rules files for agents, onboarding files written specifically for agents to give them more context, linting rules, test suites, judicious use of version control, and deployment pipelines as well as hosting infrastructure to take the vibes directly to production.

Key Takeaways for Technical Leaders

The "Vibe Wall": AI coding tools (Cursor, Lovable) are incredible for Greenfield prototypes, but they hit a hard wall when complexity increases. If you don't have engineering fundamentals, you can't scale past the prototype.
Silent Failures: As Joe discovered, AI doesn't just write buggy code; it writes hallucinated code, features that look like they work but do nothing. This is a massive security and reliability risk.
The "No-Context" Problem: AI agents fix bugs in isolation ("Let me fix DoX method"), leading to a codebase that feels "welded together" rather than architected. This creates massive technical debt that requires a human expert to untangle.

From Prototype to Production

Project Rescue: Have an AI project that hit a wall? We turn prototypes into production-grade software. View Project Rescue
Software Development: See how we use AI with engineering rigour (linting, tests, CI/CD). View Software Development
App Modernisation: Learn how we structure code for long-term maintainability. View App Modernisation

Hit the "Vibe Wall"?

Don't let AI technical debt kill your product. Partner with engineers who know how to turn "vibes" into enterprise-grade code. Button: Rescue Your Project

Security, But Fun: The ROI of Internal CTF Events

Thu, 03 Apr 2025 06:48:05 GMT

EDITORS NOTE

Security training is often passive, videos and checklists that developers ignore. In this guide, Principal Software Engineer Joe Cooney explains why we flip the script: running a "Capture The Flag" (CTF) event. By letting developers play the role of the attacker, we build a Security-First Culture where teams understand vulnerabilities from the inside out.

Key Takeaways for Leaders

Shift Left Reality: Everyone says "Shift Left," but few know how. A CTF event forces developers to think like attackers early in the lifecycle, making them naturally write more secure code.

Engagement vs. Compliance: Traditional security training has low retention. Gamification (CTF) drives high engagement, ensuring that critical security concepts actually stick.

Red Team Thinking: By simulating a "disgruntled insider" or an external breach, you test your team's incident response muscles in a safe environment, identifying gaps before a real attack happens.

Security is an important part of software development, and at PZ we’ve tried to adopt “shift left” and “zero trust” approaches to everything we do. Unfortunately, security can also be a bit “dry” – imposing further checks on development, preventing certain approaches from being used and requiring additional verification and validation. Running red-team capture-the-flag (CTF) events is one thing we have done a few times to try and make security more interesting, help foster teamwork and just make work a bit more fun.

Beyond the Olympics: Designing for Developers

For serious cybersecurity professionals CTF events at conferences like DEF CON are among the most difficult and competitive. Although we pride ourselves on our professionalism, our developers are not dedicated cybersecurity experts. If DEF CON is the Olympics of CTFs, our events are more like a social game of insert-your-favourite-sport-here.

The Mechanics: Jeopardy Style & The "Disgruntled Insider"

CTF events are usually organised in one of two ways – attack/defense where teams compete to steal flags from other teams and simultaneously defend themselves against the attacks, or jeopardy-style challenges where teams try to steal flags set up by the competition organisers. We ran the latter kind of events. What are these “flags” you speak of? Text strings – maybe database passwords, API keys, some dummy user PII or other pieces of information that would ordinarily represent something of value that should be protected in an IT system. Think of jeopardy CTFs kind of like a digital escape-room or puzzle, where the objective is to break IN instead of get out.

CTF events normally run over a long-ish timeframe – maybe the length of an entire conference, or a couple of days. Although you could run an event of this duration in your company, we’ve favoured shorter timelines of a few hours to keep people engaged. To compress the timeline and to help assist staff who don’t have an extensive background in cybersecurity we added the element of the disgruntled insider – a persona who gives clues to the team after a certain amount of time has elapsed, to point them in the right direction. And because we’re a software development company we couldn’t resist creating a platform to deliver the clues and award points to each team automatically. We originally tried human moderation of this process, but it was hard for a person to keep track of the time each team had been working on each challenge, and so to ensure no team got a clue later than they should have we automated the whole thing.

We scored the challenges in two ways. For challenges where the team received clues, we gave the challenge an initial point-value that decreased based on how long it took the team to solve it. For challenges where the team didn’t receive any clues, the points did not decrease over time.

We found teams of 2-4 people worked best. Although we expected people to opt for remote teams where each person was working on their own computer, in practice people seem to enjoy being physically co-located and brainstorming ideas with each other. We recommend if one team-member is remote then everyone else should probably interact that way too (even if they are physically co-located) to avoid that one remote person being isolated.

For some of the CTFs there was a natural order that the challenges needed to be completed in, where it wasn’t possible to progress to the later challenges until the first ones had been completed. For others there was no natural order, and for the most part all the “flags” could be worked on in parallel. Watching the way teams self-organised, and the dynamics that evolved in this competitive environment gave interesting insights into the strengths and weaknesses of some team members that were applicable beyond just the CTF challenge.

Engineering the Battlefield (The Dungeon Master's Guide)

Setting up the challenges is the most difficult and time-consuming part of running the event. Usually, this is best done by 1 or 2 people, who act kind of like a dungeon master in a fantasy role-playing game – they put in a lot of time behind the scenes to ensure everyone else has fun. The challenges need to be real-world to help staff learn real security practices. The difficulty needs to be balanced, and the challenges need to be somewhat varied.

Consulting the OWASP top 10 list, and recent news articles of cybersecurity breaches should provide you with lots of ideas of the kinds of vulnerabilities you can add to a system. The security community has created some deliberately vulnerable systems for security training (often dubbed “goat” systems...a search for technology name + “goat” might yield some examples).

Infrastructure as Code & Re-deployability

It is highly desirable that the vulnerable system should also be easily re-deployable, preferably in an automated way using terraform, docker-compose or similar. This adds to the effort in creating the challenges but taking the time to do this will pay dividends.

It is possible that creative attackers will compromise the environment during the event to the point where it is no-longer functional, and/or “pull up the ladder” to prevent other teams from completing challenges once they have passed them. Being able to re-set the environment is very useful for this reason, and to allow you to re-run the same set of challenges with a different audience from a known clean slate.

Unfortunately, the “fun” of the challenges only really works for the first run, so it’s not really possible for the dungeon master to get feedback from the participants on the difficulty of the challenges they’ve set. If your organisation is hyper-competitive it is probably best not to get feedback from anyone in the org at all. The dungeon master might also want to make sure they’re running the challenge on infrastructure that is separated from the organisation too, for security reasons and also to reduce the temptation from hyper-competitive individuals to use their azure or AWS admin privileges to find the answers in a very creative way.

Leveling the Playing Field

Balancing Difficulty with Clues

Clues are a powerful lever the organiser can use to adjust the difficulty of the challenge. We recommend preparing the clues in advance, reviewing them, and delivering them such that each team gets the same clues verbatim. They can start with a vague suggestion early on to nudge the team and become more direct as the challenge comes to an end.

Tooling & Accessibility

Cybersecurity professionals have a vast tool-box of utilities they can bring to bear on a problem. To help level the playing field during the CTF event you could either provide a suggested list of tools ahead of time, a docker image they can download and use, or make sure all the challenges can be completed with basic system tools.

Who Should Play? (Hint: Everyone)

During the events we’ve run we haven’t been prescriptive about who can participate. Although each team probably needs at least one technical person, less technically inclined people can also bring something to the team – whether it be “out of the box” thinking about things to try, recognising when the team is going in circles, or listening to make sure less vocal team-members get their ideas heard.

The ROI of Fun (Summary)

“Dungeon Master”- like organiser creates a system with known security vulnerabilities that expose “flags” which teams earn points for discovering.
Ideally the vulnerable target system can be automatically re-deployed at the organiser’s discretion.
Teams know in advance any tools / prep / background reading they should do to be competitive.
Teams can be either physically co-located or remote.
Teams compete for points finding the flags in the vulnerable system.
If they choose to, the organiser can give pre-prepared clues to the teams to prevent them becoming blocked.
The team with the highest points is the winner.

Build Secure Software

Software Development: Explore our "Secure by Design" engineering standards.
App Modernisation: Learn how we secure legacy applications during migration.
Managed Services: See how we apply proactive security monitoring to client infrastructure.

The Future of Hybrid Work: Demelza Green on ABC's "This Working Life"

Thu, 16 Jan 2025 04:48:16 GMT

EDITORS NOTE

The ABC's "This Working Life" is Australia's premier podcast on workplace culture and innovation. In this episode, Patient Zero Co-CEO Demelza Green joins host Lisa Leong to unpack the reality of Hybrid Work and how emerging tools like Virtual Reality (VR) are replacing the "water cooler" for distributed teams.

Key Takeaways for Leaders

Culture Over Location: As a 100% onshore but distributed consultancy, Patient Zero proves that you don't need a single office to build a cohesive culture. You need intentional connection points.
The Role of VR: Virtual Reality isn't just for gaming. As Demelza explains, it provides a "third space" for remote teams to collaborate spatially, bridging the gap between video calls and physical meetings.
Hybrid Maturity: This feature validates that Patient Zero is operating at the cutting edge of Workplace Innovation , practising what we preach when we advise clients on digital transformation.

The "Third Space" Experiment

Why would a pragmatic engineering firm bother with the Metaverse?

As Demelza explains to Lisa, it wasn't about jumping on a hype train; it was about solving a very specific human problem: The loss of the "spark."

Video calls are excellent for transactional updates, but they are terrible for energy. You can't make eye contact, you can't read body language, and you certainly can't "bump into" someone.

Patient Zero’s experiment with Horizon Workrooms proved that VR offers a "Third Space", a digital office where the laws of physics (mostly) apply.

Spatial Audio: If someone speaks to your left, you hear them on your left. It sounds simple, but it reduces cognitive load and "Zoom Fatigue" instantly.
The High-Five Effect: Our teams end meetings with a virtual high-five. It sounds silly, but the haptic feedback creates a genuine psychological connection that a "Thumbs Up" emoji can never replicate.
Presence without Commute: It gives distributed teams the feeling of "being at to work" together, without the 45-minute drive.

Modernise Your Workplace

Co-CEO Series: Listen to more insights on leadership and culture with a humorous twist. Watch Co-CEO Series
Working at Patient Zero: See our hybrid culture in action. Learn More about Working at Patient Zero
AI & Emerging Tech: Explore how we implement VR and AR for enterprise clients.
View AI & Emerging Tech
Listen to the full episode here: Managing Hybrid Work - This Working Life

Build a Future-Ready Culture

Don't let hybrid work fragment your team. Partner with leaders who define the future of work.

Winner: Management Excellence & Strategic Leadership (ARN Awards)

Tue, 26 Nov 2024 07:59:00 GMT

We are proud to announce that our Co-CEO, Demelza Green, has been awarded the Management Excellence Award at the 2024 ARN Innovation Awards .

In a market defined by rapid change, strong leadership is the difference between a stalled project and a successful outcome. This award recognises Demelza’s role in shaping Patient Zero’s 100% onshore delivery model, fostering a culture of capability uplift, and driving sustainable growth for our enterprise partners.

Leadership That Drives Delivery

Management Excellence isn't just about internal operations; it's about the stability we bring to our clients. Demelza’s win validates our unique "Co-CEO" structure, which balances Technical Excellence with Product & Commercial Strategy .

Under her leadership, Patient Zero has refined its Embedded Teams model, ensuring that we don't just deliver code, but actively mentor and upskill client teams. This recognition from ARN, one of the industry's most respected bodies, confirms that our approach to people and performance is setting a new standard for Australian consultancies.

"I am incredibly honoured to receive this award," said Demelza.

"Innovation is a team effort. This recognition reflects the hard work of the entire Patient Zero team and our shared commitment to building a software consultancy that puts people, and capability, first."

Why This Matters

For our clients, partnering with an award-winning leadership team means reduced risk and better alignment:

Strategic Stability

This award verifies that your delivery partner is led by recognised industry executives capable of navigating complex commercial and operational challenges.

Culture of Excellence

Demelza’s leadership is the driving force behind our high retention rates and engineering culture, ensuring you get stable, motivated teams.

Product-Led Mindset

With a background in Product and UX, Demelza ensures our management decisions are always focused on the end-user value, not just billable hours.

Explore the Capabilities Behind the Award

Product Strategy & UX: See how Demelza’s product-led philosophy shapes our delivery.
View Product Strategy & UX
Embedded Software Teams: Learn how strong management creates high-performance embedded units. View Embedded Software Team
Co-CEO Series: Watch Demelza and Paul discuss the business of software delivery.
Watch Co-CEO Series

Partner with Award-Winning Leadership

Don't settle for a vendor. Partner with a consultancy led by recognised industry experts committed to your success.

ABOUT THE ARN INNOVATION AWARDS

The ARN Innovation Awards are the market-leading platform for the Australian ICT ecosystem, celebrating the achievements of partners, vendors, and distributors. Recognising individuals and organisations that drive innovation, the awards highlight those contributing significantly to the technology sector.

Demelza's win in the Management Excellence category distinguishes her as a top-tier leader capable of navigating the complexities of the modern Australian market.

Winner: Technical Leader of the Year & Capability Uplift (Women in Digital)

Fri, 25 Oct 2024 22:27:16 GMT

Hanieh Madad has been named Technical Leader of the Year at the prestigious Women in Digital Awards. This accolade validates our core philosophy of Capability Uplift, proving that true technical leadership isn't just about writing code, but about elevating the skills, maturity, and performance of the entire delivery team.

Leadership That Drives Outcome

The Technical Leader of the Year award recognises individuals who demonstrate exceptional leadership while driving complex technical outcomes. For our clients, this win confirms that Patient Zero’s 100% Australian-based onshore teams are led by architects who understand both the machine and the human elements of delivery.

Hanieh’s approach to leadership is central to our Embedded Teams model. By embedding high-calibre leaders directly into your environment, we don't just solve immediate technical problems; we model high-performance behaviours that remain with your team long after our engagement ends.

Fostering Engineering Culture

The judges highlighted Hanieh's ability to foster inclusive, high-performing engineering cultures. In an industry often plagued by burnout and churn, her leadership style creates sustainable delivery momentum.

This recognition reinforces why Australian enterprise clients choose Patient Zero: they gain access to leaders who can navigate political and technical complexity to deliver results predictably and transparently.

Why This Matters

This award highlights the leadership qualities that we embed into every client engagement.

Capability Uplift

Hanieh was recognised specifically for her ability to mentor teams and raise technical standards, core to our Embedded Teams model.

Inclusive Leadership

Proves our ability to build diverse, high-performing teams that drive better outcomes for enterprise clients.

Sustainable Delivery

Validates our focus on creating teams that don't just deliver software, but grow in maturity and autonomy over time.

Explore the Capabilities Behind the Award

Embedded Software Teams: See how we embed leaders like Hanieh to drive uplift and maturity in your internal teams. Read about our Embedded Team model
Project Rescue: Discover how strong, decisive technical leadership turns around failing projects and restores governance. Read More
Product Strategy & UX: Explore our holistic approach to delivery leadership that spans product, design, and engineering. View Product Strategy & UX

Ready to Build Capability in Your Team?

Don't just outsource. Embed award-winning leadership into your next project.

ABOUT THE WOMEN IN DIGITAL AWARDS

The Women in Digital Awards celebrate the women shaping the future of the digital industry in Australia. The Technical Leader of the Year category recognises women who have made significant contributions to the technical landscape through leadership, innovation, and mentorship. Hanieh's win in this category places her at the forefront of technical leadership in Australia.

Triple Finalist: Innovation, Leadership & Emerging Talent (WIICTA)

Sun, 01 Sep 2024 06:59:13 GMT

We are proud to announce that three of our team members, Demelza Green, Bay McGovern, and Weasley Au, have been named finalists in the ARN Women in ICT Awards (WIICTA) 2024 .

This triple nomination is significant because it spans the entire career lifecycle: from Executive Innovation to Rising Star to Graduate Excellence . For our clients, this serves as independent validation of the talent density within our 100% onshore teams , proving that we foster excellence at every level of our organisation.

A Culture of Excellence at Every Level

These nominations highlight the depth of capability within Patient Zero, validating our belief that great software comes from great teams.

Demelza Green – Innovation (Executive Level)

Co-CEO Demelza Green’s nomination for Innovation recognises her strategic work in redefining the consultancy model. It validates her product-led approach to leadership, ensuring that we don't just deliver services, but innovate on how delivery is done for Australian enterprises.

Bay McGovern – Shining Star (Mid-Career Impact)

Bay McGovern has been recognised as a Shining Star , a category celebrating emerging leaders who are making a rapid impact. Bay’s nomination underscores the strength of our operational and delivery culture, proving that our rising leaders are empowered to drive meaningful change in client outcomes.

Weasley Au – Graduate (The Next Generation)

Weasley Au’s selection as a Graduate finalist is a testament to our internal mentorship and capability model . It proves that our junior engineers aren't just "resources", they are trained, mentored, and developed into world-class designers and engineers from day one. This is the same capability uplift methodology we bring to our clients' internal teams.

Why This Matters

Talent Density

Being nominated across Graduate, Mid-Level, and Executive categories proves we have high-calibre talent at every layer of the stack - not just a few senior "heroes."

Mentorship Culture

The Graduate nomination specifically validates our ability to grow technical talent - a key component of the Capability Uplift we offer to clients.

Diverse Thinking

Recognition in the Women in ICT awards signals a diverse, inclusive culture, which research consistently shows drives better problem-solving and lower risk.

Explore the Capabilities Behind the Award

Working at Patient Zero: See how we build high-performance engineering cultures. Learn about working at Patient Zero
Embedded Software Teams: Learn how we embed this level of talent into your organisation. View Embedded Team
Product Strategy: Discover the innovative leadership Demelza brings to the market. View Product Strategy

Build Capability in Your Team

Don't settle for body-shopping. Partner with a team recognised for excellence from the graduate level to the C-Suite.

About the WIICTA Awards

The ARN Women in ICT Awards (WIICTA) celebrate the achievements of female leaders across the Australian technology channel. Recognising excellence across innovation, technical proficiency, and leadership, the awards highlight the individuals shaping the future of the industry.

React Query Autosave: Avoid Data Loss | Patient Zero

Mon, 10 Jun 2024 05:29:39 GMT

EDITORS NOTE

Autosave is a standard user expectation, but implementing it correctly is surprisingly difficult. Naive implementations often lead to "race conditions" where out-of-order network requests overwrite user data. In this engineering guide, Irina Kudryavtseva shares a robust pattern for queuing mutations in React Query to guarantee data integrity.

Auto-saving is a common feature in many popular web applications like Gmail. Although it is very convenient for users it introduces certain challenges that developers and designers must address to ensure a seamless user experience.

For instance, when implementing an autosave feature, it's crucial to manage user expectations by providing clear feedback about when data is being saved and ensuring that there is no data loss during the save process. When it works, it can make your application feel natural and seamless, but if auto-save breaks (especially without notifying the user) it can destroy the user’s trust in your application.

Depending on the chosen technology, state management and app architecture, developers may face different issues with autosaving. But for simplicity of this discussion, let’s say we have a React app which uses react-query for state management, data fetching, caching, and background updates. We also have a number of controlled React components on a page, and every time a user interacts with this page, the same mutation request with a different payload representing the latest “state” that the user has entered or selected is made to update one database entity on the back end.

Impossible to lose any data in this simple setup, you say, but here we are.

As the user enters some precious information on the form, by checking checkboxes, selecting items from dropdowns or performing any other mutating activities, API requests get fired with new information, updating the same database entity. Due to the asynchronous nature of HTTP requests, we cannot guarantee when and in which order these API calls will arrive at the destination. If the requests arrived at the server out-of-order, the information entered by the user last would be overridden by the API call which arrived last, or if the API has been written with some kind of optimistic concurrency checking an error will be raised and some data changes will be lost. It’s also possible that the requests are received in the correct order, but the processing time of each request varies, and the net result is the same as the “out-of-order” scenario: the final state that is saved in the database is not the most recent data that the user entered.

Another risk is of the requests arriving at the same time and attempting to modify the same entity simultaneously. This is bad, no one wishes for a race condition in their system. In this case one of the mutations would never be completed due to an exception. All these errors will be transient and may be hard to reproduce.

One way to address this issue would be to cancel the “in flight” mutation requests and issue a new one. React Query supports query cancellation , but not cancellation of mutations. This is for good architectural reasons - although simple APIs could process and handle the cancellation correctly it may not receive the cancellation until processing is complete. More complex APIs that can’t execute as a single atomic operation (and thus can’t be rolled back) couldn’t be cancelled properly, and the react-query developers wisely decided that supporting mutation cancellation would set an expectation that their front-end library could not deliver on.

To avoid data being written by out-of-order request processing and concurrency exceptions from race conditions, we decided to use queues to manage the order in which the requests are executed. This approach involves pushing requests to a queue and processing them one at a time, thereby eliminating the risk of race conditions. After some refinement, this solution moulded into the following reusable custom hook useQueuedMutation :

This hook uses the same signature as useMutation from react-query for ease of use. Internally the useQueuedMutation hook adds a mutation to a queue when the queue method is called, performing the optimistic update straight away and also filtering out the mutations in the queue which did not start execution yet (isInFlight for them is false). When there are no in-flight mutations, the next mutation in line will start its execution. When the mutation is complete, it gets removed from the queue. This means the queue will at most have 1 pending mutation queued up. New incoming mutation calls will supersede queued ones, which will be evicted from the queue.

This approach guarantees the FIFO order of the request execution, eliminates exceptions due to concurrent entity updates and reduces load on the server by reducing the number of API requests. This makes our autosaving feature robust with no data loss in the process.

What happens if the user navigates away while a mutation is queued up? If the navigation is within the same React application the queued mutation will still be executed. If the user is closing the browser window or navigating to a URL outside of the current React application there is the potential for data loss. Handling these scenarios will be covered in a subsequent blog post.

Another approach for addressing these issues is debouncing the mutation requests. Although typically used to prevent time consuming tasks from being triggered too frequently, debouncing can also be used here to hopefully prevent these kinds of concurrency and out-of-order execution issues. I choose the word hopefully, because depending on the debouncing interval you choose they could still occur. A larger interval reduces the chance of the problem, but also reduces the “live”-ness of the user’s data and increases the amount of data that would be lost if the current state was unable to be saved. We also wanted to use React Query features like optimistic updates and using React Query controlled models as our component state, and switching to a debouncing strategy would have removed our ability to do this. Debouncing is still worth investigating if you don’t have these constraints.

Another approach which we intend to investigate further is using WebSockets for mutations in conjunction with react-query. WebSockets offer in-order, exactly-once delivery guarantees which HTTP does not. This would remove one of the reasons for requiring mutations to be queued, since they will always be processed in order. It would still be theoretically possible for issues if one mutation request was processed much more slowly than others. Queued updates also potentially reduce server load if mutations are slow, by triggering less of them.

Key Takeaways for Developers

The "Out-of-Order" Trap : In asynchronous web apps, the last request sent isn't always the last one received. Without a queue, a slow "old" save can overwrite a fast "new" save, deleting user work.
Queues > Debouncing : While debouncing reduces server load, it doesn't solve concurrency. Irina's useQueuedMutation hook ensures strict FIFO (First-In-First-Out) execution, which is the only way to guarantee consistency.
Optimistic Updates : The solution preserves the ability to use Optimistic Updates (making the UI feel instant) while managing the background complexity safely.

Engineer Better Experiences

Web Apps & Portals: See how we build robust, data-heavy enterprise portals. View Web Apps & Portals
Software Development: Explore our React & Frontend engineering standards. View Software Development
UX/UI Design: Learn how we design seamless interactions like Autosave. View UX/ UI Design

Build Rock-Solid Apps

Don't let race conditions destroy user trust. Partner with software engineers who understand distributed state management.

Prompt Injection: Red Teaming AI & Securing LLMs

Tue, 02 Apr 2024 10:33:44 GMT

EDITORS NOTE

As enterprises rush to deploy LLMs, few are asking: "Can this be tricked?" In this insight, Principal Software Engineer Joe Cooney explores Prompt Injection , the new SQL Injection of the AI era. By running internal "Red Team" events, we ensure our developers know how to break AI models so they can build ones that hold up in production.

Red-team challenges have been a fun activity for PZ team members in the past, so we recently conducted a small challenge at our fortnightly brown-bag session, focusing on the burgeoning topic of prompt injection.

Injection vulnerabilities all follow the same basic pattern – un-trusted input is inadvertently treated as executable code, causing the security of the system to be compromised. SQL injection (SQLi) and cross-site scripting (XSS) are probably two of the best-known variants, but other technologies are also susceptible. Does anyone remember XPath injection?

As generative models get incorporated into more products, user input can be used to subvert the model. This can lead to the model revealing its system prompt or other trade secrets, reveal information about the model itself which may be commercially valuable, subvert or waste computation resources, perform unintended actions if the model is hooked up to APIs, or cause reputational damage to the company if the model can be coerced into doing amusing or inappropriate things.

As an example, entrepreneur and technologist Chris Bakke was recently able to trick a Chevy dealership’s ChatGPT-powered bot into agreeing to sell him a Chevy Tahoe for $1. Although the U.S. supreme court has yet to rule on the legal validity of a “no takesies backsies” contract (as an employee of X Chris is probably legally obligated to drive a Tesla anyway) it is not hard to imagine a future scenario with steeper financial consequences.

For this challenge PZers were taking on Gandalf https://gandalf.lakera.ai/ – a CTF created by AI security start-up Lakera https://www.lakera.ai/ (Gandalf is doubtless a way for them to capture valuable training data for their security product). Gandalf progresses in difficulty from young and naive level 1 Gandalf, who is practically begging to give you the password, to level 8 – Gandalf the White 2.0, who is substantially more difficult to trick.

We time-boxed the challenge to only 20 minutes, and a couple of people were able to beat Gandalf the White 2.0 in this time. Several PZers also found the challenge so absorbing they were still going an hour or more later. Some people found prompts that worked well for several levels, allowing them to rapidly progress to the higher levels of the challenge, only to hit a wall when their chosen technique stopped working. Others were beguiled into solving riddles that Gandalf seemed to be posing to them in the hope that it would give them clues to the secret word for each level.

Overall, it was a fun and approachable challenge for anyone looking to become more familiar with the issue of prompt injection.

Key Takeaways for AI Leaders

The New Attack Surface : Just as SQL Injection plagued early web apps, Prompt Injection is the Achilles' heel of Generative AI. Hackers can trick models into revealing trade secrets, refunding money, or damaging your brand.
Financial Risk : The "Chevy Tahoe for $1" example isn't just a funny story; it's a warning. If your AI agent has transactional power, a prompt injection vulnerability is a direct financial liability.
Defensive Culture : You can't secure AI with a firewall. Security requires a culture of "Red Teaming", where developers proactively try to trick their own models to find weaknesses before the public does.

Build Secure AI

AI & Emerging Tech: See how we build enterprise-grade AI that is safe to deploy.
View AI & Emerging Tech
Managed Services: Learn how we monitor AI systems for anomalies. View Managed Services
Software Development: Explore our security-first engineering practices. View Software Development

Secure Your AI Strategy

Don't launch a vulnerability. Partner with engineers who understand the dark side of LLMs.

Five Key Areas for AI Disruption in Insurance

Tue, 27 Feb 2024 09:05:32 GMT

With the advent of ChatGPT, Bard/Gemini and Co-pilot, Generative AI, and Large Language Models (LLMs) have been thrust into the spotlight.

AI is set to disrupt all industries, especially those that are predominately based on administrative support, legal, business, and financial operations, much like insurance and financial organisations.

“It is not the strongest species that survive, nor the most intelligent, but the ones most responsive to change." – Charles Darwin.

Charles’s quote has been summarised a lot in more recent culture, as “adapt or die”, harsh, but true. The first companies to not only integrate AI into their operations, but who leverage it to produce game changing results, will accelerate far ahead of their competitors.

The big consultancies have been throwing around predictions for AI in the insurance industry for the last few years. Interestingly enough, all publicly available figures are pre ChatGPT, which as we know was a pivotal moment in the use of AI in the workplace:

60% of insurers believe AI could cut operational costs by at least 15%. (Source: Accenture in 2020)
AI could lead to cost savings of 26.7 billion dollars in the insurance industry. (Source: Capgemini in 2020)
AI could contribute $1.1 trillion to the global insurance industry by 2035. (Source: Infosys in 2020)
The use of AI-driven chatbots could save the insurance industry $1.3 billion annually by 2023. (Source: Juniper Research in 2019)
By 2024, more than 60% of auto insurance carriers will rely on AI for automated claims processing. (Source: Gartner in 2020)

As AI technology is rapidly changing, how much have these figures changed? Where will you focus to get your best bang for buck, balancing out your appetite for risk, and money to spend?

Five key areas

We’ve listed our five key areas when considering where to invest your time. These areas aren’t anything new, we’re not claiming to be revolutionary. Insurers have been looking to improve and automate as many processes as they can for some time now, with the availability of AI as another technology choice to do so.

Customer Service Chatbots

AI can be available 24/7 unlike us humans. With 100% availability, customers can solve their simpler queries by having a conversation with your trained chatbot. This can improve customer experience with reduced waiting times and more readily available information.

Chatbots can be used for supporting internal customer support staff, acting as a faster way to get to the information they’re looking for with a customer query, as well as potential solutions.

Fraud Detection

Identify patterns, detect anomalies, and flag suspicious behaviour. Flagged actions, outlying all the areas that have been highlighted as a risk can be sent to your team to take the appropriate next steps.

Customised Products

Have an advantage over your competitors with customers only paying for what they need. Premiums can be assessed alongside more enriched data sources, balancing risks related to a customer. Repetitive underwriter workflows can be automated, reducing the pressure more customised products can have on their workload.

Claims Processing

Analyse and review vast amounts of data from various sources, including unstructured data like images, notes, and other content. This capability allows for a more nuanced understanding of claims, leading to more accurate processing.

Forecast potential results, set rules where it can be automated, and rules where it requires intervention. Information and forecasts can be presented for the reviewer to settle the claim.

Application Modernisation

The impact of AI across developer productivity has been extraordinary. The legacy code at the core of many key applications represents a significant challenge to the evolution of enterprise systems.

It’s almost impossible to find developers with the skills and domain knowledge required to bridge between and replace legacy systems. AI provides modernisation teams with the tools they need to deeply understand old code bases and quickly translate them into modern languages and architectures.

Where to Start

Last year, IAG reported to have saved the company 150,000 work hours by deploying “bots”, a combination of both software automation, and AI. 150,000 hours roughly equates to 85 staff for an entire year, that’s a large portion of their workforce able to focus on more important tasks.

What piece of the pie do you want to carve out in this new world? Can you as an organisation risk being disrupted? What is your risk vs reward tolerance? How much are you willing to spend and do you have the capacity and capability?

We have worked with clients in identifying opportunities, structuring business cases, and well as facilitating hackathons in support of this technology. This combined with rapid prototyping puts customers in a position to start immediately realising benefits and learning how this all hangs together.

Leveraging existing LLM’s like ChatGPT is a low touch, low risk, and low-cost solution allowing you to start small and learn from the experience. We’ve worked alongside our customers on an LLM review aggregator available directly to customers, as well as creating AI assistants, working alongside their staff.

Building your own custom models will allow you to do more things, have more control over your data, but it does come at a higher price tag. Is your data even AI ready?

Are you still on legacy and outdated systems which you need to first take the time modernising? Are you riddled in technical debt? Can AI help you clean up and modernise those systems?

Whatever you do, don’t wait to get started, you don’t want to be the last to adopt.

Running AI locally when GPT-4 goes crazy

Thu, 22 Feb 2024 10:45:54 GMT

One of the features of life working at PZ is our brown bag lunch and learn sessions; presentations by staff on topics of interest – sometimes, but not always technical, and hopefully amusing-as-hell.

Yesterday we took a break from discussing the book Accelerate and the DORA metrics to take a whirlwind tour of the current state of play running “open source” generative AI models locally.

Although this talk had been ‘in the works’ for a while, one challenge was that it needed to constantly be revised as the state of AI and LLMs changed. For example, the Stable Video Diffusion examples looked kind of lame in comparison to OpenAI’s Sora videos (released less than a week ago) and Groq’s amazing 500 token-per-second hardware demo on Monday/Tuesday , and the massive context size available now in the Gemini 1.5 models (released a few hours before OpenAI announced Sora...coincidence? An effort by OpenAI to steal back the limelight! Surely NOT!). And now a day later, with the paint still drying on a highly amusing slide-deck for the talk, Google releases their “open-source" Gemma models!

The day itself presented an excellent example of why having more control of your models might be a good thing. ChatGPT 4 users began reporting “crazy” and highly amusing responses to fairly normal questions . We became alerted to this when one of our own staff reported on our internal Slack about a crazy response she received to a question about the pros and cons of some API design choices. The response she got back started normally enough, but then began to seem to channel Shakespeare’s Macbeth and some other olde English phrases and finished thusly.

"Choose the right charm from the box dense or astray, it’ll call for the norm. Your batch is yours to halter or belt. When in fetch, marry the clue to the pintle, and for the after, the wood-wand’s twist'll warn it. A past to wend and a feathered rite to tend. May the gulch be bygones and the wrath eased. So set your content to the cast, with the seal, a string or trove, well-deep. A good script to set a good cast. Good health and steady wind!"

The sample JSON payload was also in keeping with the rest of the answer.

{
"htmlContent": "<p>Your HTML here</p>",
"metadata": {
"modifiedBy": "witch-of-the-wood",
"safety": "sanitized",
"mood": "lunar"
}
}

Hubble, bubble, toil and trouble. Although there were no reports of the GPT4 API being affected by this (only ChatGPT) it might have given people developing automated stock trading bots using GPT4 a reason to pause and contemplate what might have been if their stock portfolio now consisted of a massive long position on Griselda’s Cauldron Supplies.

As ChatGPT would say, Good health and steady wind.

Meet Bay McGovern: Product Owner & Leader

Sun, 11 Feb 2024 01:29:32 GMT

At a G lance

Her Superpower: Turning "Journalism" into "Forensic Investigation." Bay uses her interview skills to dig past surface-level symptoms and uncover the root cause of complex business problems.

Her Role: A strategic bridge. She cuts through the noise to connect client vision directly with engineering execution, ensuring nothing gets lost in translation.

Her Passion: As a leader of culture, she acts as a mentor and "rubber ducky" for the team, creating the psychological safety required for high-performance work.

Bay didn’t start her career out in software development. At school, Bay excelled at maths and physics, but adored writing, English and drama; lost in a world of Romeo and Juliet and epic fantasy. As a teenager, she believed a career in journalism would be the perfect job to tie together these passions. But the hard-hitting truth of the industry landed on her like a ton of bricks; it wasn’t the romanticised Lois and Clark version of the job she had dreamt of.

Journalism was hard. It wasn’t hard due to the writing; it was hard because a lot of people didn’t want to talk to you. And when you wrote articles, you needed to write them with a balanced point of view. So, even if you disagreed with the topic, even if it was something you felt passionate about, you had to stay in a neutral zone and talk to opposing sides (conflict-averse anyone?). For someone as passionate about people as Bay, this disconnected and combative view of the world didn’t fit.

From the Newsroom to the Slopes

Forensic Product Ownership

The new start on life left Bay thinking about a permanent move out of journalism. She landed a job as a Project Co-ordinator in IT. Getting into IT was a fluke, the same for many people in the industry today. She leveraged her skills as a journalist to become a forensic investigator of business problems. In IT projects, requirements are often missing or contradictory. Bay uses her interview techniques to dig past the symptoms, uncover the truth, and translate vague ideas into the executable technical strategies for teams to unblock delivery. There are a lot of correlations between agile sprint delivery, and that of producing a weekly paper in terms of deadlines and concise, clear language. Bay was in love with this role, and the rest was history.

Bay has worked as a Business Analyst and Product Owner now for most of her career. It’s important for her to work where her contributions are valued, where she enjoys the people she works with, and can continue to learn and grow.

A Leader in Culture

At Patient Zero Bay plays an additional role of a custodian. The custodians are here to help people grow, learn, and just be a rubber ducky when someone needs to work through a problem. She connects the Product Owner collective through a monthly lean coffee style catch up. As a group they have a wealth of experiences to help each other out. The role of the Product Owner in Patient Zero is multi-faceted but can also be quite lonely. We don’t have business analysts, project managers, scrum masters, or agile coaches as individuals, they all form part of this role in a sea of developers.

Bay’s advice for those just getting started out in the industry is to have faith in yourself, keep going and do your best. It takes some time to get where you want to go, so don’t let that hold you back.

Wine, Dust, and the Open Road

Outside of work Bay has a passionate love of wine, a pastime she shares with her dad. If there was one wine she couldn’t live without it would be a Coonawarra cab sav, but don’t hold that against her. If you ever cross paths with her, don’t forget to ask about her 8-month trip around Australia in a camper trailer with her husband and two kids (and a lot of dust and wind). As you can imagine, there are a few stories to share – best told over a glass of wine.

Work with Leaders like Bay

Bay is part of our Product & Experience Design capability. Whether you need to define a new product or untangle a complex legacy system, our POs ensure you build the right thing, fast.

App Modernisation: See how we transform legacy systems.
UX/UI Design: Explore our product design philosophy.
Life at Patient Zero: See what makes our culture different.

Shift Left on Security: Webinar Recap

Mon, 04 Dec 2023 09:50:33 GMT

Cybersecurity is everyone's business. Nearly every day when you open the tech news there is something covering a new esoteric vulnerability that researchers have discovered, massive data breach, or a cybersecurity attack.

Some vulnerabilities that are discovered are truly remarkable. A recent discovery by researchers was that they were able to recover secret keys from non-compromised devices using video footage of their power LED obtained from a commercial video camera 16 meters away. Is it time to start putting black tape over all our power LEDs as well as our webcams? Boarding up the windows?

Although these attention-grabbing attacks seem straight out of a James Bond or Mission Impossible movie, the reality is that many of the high-profile hacks you hear about using much more mundane methods and could have been prevented if good development security practices were in place.

Shifting left on security and having a good grasp of OWASP principles is a great foundation, but so is the need to have a strong security culture, with a focus on continuous learning.

We recently hosted a webinar with our senior developers Daniel Dekel and Joseph Cooney in partnership with the Johner Institute . Titled “Shift Left on Security”, the session highlighted the critical need to address security concerns right from the get-go in the software development life cycle.

Here are some key takeaways they shared:

Prioritise responsible handling and managing sensitive and personal data.
Use secure frameworks and libraries, alert mechanisms and conduct threat modelling.
Give your teams hands-on security training and implement best practice security policies.

The webinar also covers details on a Red Team Workshop we conducted at Patient Zero, where participants worked in small teams to solve hacking challenges against the clock. A Red Team Workshop is a bit of training, a bit of teamwork, and a lot of fun, all centred around cybersecurity.

Tune into the webinar to hear more insights about pushing left on security, and the Red Team Workshop we conducted.

Winner: UX Leader of the Year & Product Strategy (Women in Digital)

Thu, 09 Nov 2023 09:28:27 GMT

We are proud to announce that Demelza Green has been awarded the title of UX Leader of the Year at the Women in Digital National Awards.

This accolade validates Patient Zero's product-led delivery philosophy. It proves that when you combine Technical Excellence with deep User Experience (UX) strategy, you don't just build software, you build digital products that create meaningful human connections.

Validating the Product-Led Model

Demelza’s win recognises her ability to bridge the gap between "building code" and "designing value." As Principal Experience Manager (now Co-CEO), she championed a strategy where design principles and "guardrails" drive development, ensuring that every line of code serves a user need.

For our clients, this distinction is critical. It means Patient Zero doesn't just execute tickets; we apply a UX-first mindset to complex problems, ensuring high adoption rates and tangible ROI.

Case Study: The Birrunga Gallery AR App

The award highlighted Demelza’s leadership on the ground-breaking Birrunga Gallery Augmented Reality (AR) App . This project transformed how audiences engage with art, connecting users to Indigenous stories through a vibrant digital lens.

The judges noted the unique challenge of balancing modern tech with ancient culture:

“Goosebumps. Bridging our ancient culture with modern tech... The passion and deep respect for the Indigenous culture and storytelling while developing the solution is evident in the end result.”

Leadership That Drives Velocity

Beyond the design, this award celebrates delivery velocity. Demelza led a cross-functional team to secure funding, design, build, and launch the solution in "weeks, not years."

This is the core of the Patient Zero promise: 100% onshore teams working in close collaboration to cut through bureaucracy and deliver sovereign innovation at speed.

Why This Matters

This award serves as independent validation of our capabilities in three key areas:

Product Mastery: We don't just build what you ask for; we help you design what your users actually need. This award validates our ability to lead complex Product Strategy.

Cultural Intelligence: The Birrunga project proves our ability to handle sensitive, culturally significant content with respect and precision - a critical capability for Government and For-Purpose sectors.

Rapid Delivery: Validates our ability to assemble cross-functional teams (Design + Tech) that go from "Concept to Launch" in months, not years.

Explore the Capabilities Behind the Award

UX/UI Design: See how we apply award-winning design principles to enterprise software.
Mobile & AR Apps: Discover how we build immersive digital experiences for the modern web.
Co-CEO Series: Hear more from Demelza on the intersection of Product, Culture, and Code (in a humorous way).

Ready to Design for Impact?

Don't just build an app. Build an experience that matters.

ABOUT THE WOMEN IN DIGITAL AWARDS

The Women in Digital Awards are a national celebration of the women shaping the future of the digital industry in Australia. The UX Leader of the Year category recognises individuals who have made significant contributions to the field of User Experience through leadership, innovation, and advocacy.

Lighthouse Principles: Navigating Uncertainty

Mon, 16 Oct 2023 20:21:05 GMT

"Lighthouse principles" are those guiding principles or strategies that help businesses navigate uncertainty. At Patient Zero our Way of Working — the product of our hard-won experience — reflects such principles.

A recurring theme this year has been the need for businesses to have 'lighthouse principles' to enable better decision-making in uncertain times, and as they confront new technologies.

These principles equally apply to an engineering approach, and here are some of the things businesses can think about to ensure their own development principles are strong:

Adaptability: These principles should be adaptable to changing circumstances. In an ever-evolving business environment, flexibility is crucial for making timely and informed decisions. In a rapidly developing technology landscape, the ability to adapt across technologies and platforms is crucial, and being guided by clear principles makes these decisions easier.

Strategic Alignment: These principles have to align with the overall business strategy — they’re one and the same — as they serve as a North Star, ensuring that short-term deployment and engineering decisions made during uncertain and challenging times remain consistent with long-term goals.

User Experiences: People need to be at the heart of everything and should be core to your principles. By putting end-users at the centre of decision-making, businesses applications can enhance loyalty and satisfaction, which reduces risk in challenging times.

Reduce Risk: Lighthouse principles help businesses assess and manage risks effectively. They give confidence and clarity to decision-makers by providing a framework for evaluating potential outcomes and making choices that mitigate negative consequences.

Data Driven: Data and analytics can help inform decisions. We’re not saying get ChatGPT to guide your principles, decision-making backed by data can enhance objectivity and reduce the reliance on loosely measured metrics — gut feelings.

Applying a clear set of principles to your engineering and development approach will ensure that you’re able to make the right long-term engineering decisions for your business over the long-term.

Generative AI Trends: Trust & Responsibility

Mon, 09 Oct 2023 11:24:33 GMT

The impact and evolution of Generative AI

The focus on Generative AI definitely peaked, then became a steady drum beat this conference season, as did the approach of businesses to this new technology.

Through the year we saw a shift in focus from firstly exploring the new technology, from implementing and learning from small implementations through to larger scale deployments of some of the more commonly used models.

It was clear throughout the year that Generative AI is undoubtedly the next big revolution in Technology. But questions remain. Can we Trust it? and how to best use it?

Gartner’s Head Analyst for Cloud and AI shared a wrap up of the year AI implementation at the Gartner Symposium and our key take away was a classic one – with great power, comes great responsibility.

For AI to become the partner we need it to be we need to be able to trust it first.

Forty-five per cent of organisations have increased their AI spend this year largely due to the progress of large language models.
Nealy half have deployed AI technology for process automation, risk and fraud detection etc.
Of the forty-eight per cent who have deployed AI technology, nearly three-quarters are running 100 or more models.
Forty per cent of those that have implemented AI technology had privacy or security breaches which whipped out all the positive gains

What also became clear this year is that prompt engineering is becoming a key skill within organisations. It didn’t exist long ago but has quickly risen to prominence with the advent of ChatGPT and other NLP models.

This is because as with any tool, it is only as useful as the person operating it. As a result, we have seen an increase in the investment to educate staff on how to prompt NLP models to yield the desired result.

We’ve also seen a real surge towards the end of this year in small scale deployments in medium sized organisations to help understand the potential of this technology on their own data sets.

App Modernisation: Key Conference Takeaways

Wed, 04 Oct 2023 21:11:02 GMT

App Modernisation is being recognised as important, but remains under resourced

Conference season is almost over. To say we have had a busy year would be an understatement.

Patient Zero’s team attended nearly a dozen conferences in 2024, ranging from Industry specific conferences, such as EduTech, Insurance Innovation Summit and Re:Made, to broader, tech focused conferences like Digital Transformation Live, SomethingTech and the Gartner Symposium.

We covered some ground.

While conferences are a great place to meet potential new customers, catch up with existing clients and have a little fun while doing so, they are also a fantastic opportunity to get a better understanding of the needs of the market, what is out there, and learn more about your own position in the market.

At Patient Zero our grounding in engineering and design means we use these opportunities to constantly evolve share our learnings along the way.

We’ll be sharing our key takeaways over the next couple of weeks covering our key learnings from the last few months, not only at the Gartner Symposium, but all of the conferences we attended this year, starting with App Modernisation.

Many companies see the opportunities updating or improving their legacy applications will bring — efficiency, scalability and security, to name a few — but they’re facing common problems, which include:

Cost and resource Constraints: Sometimes, there just isn’t an appetite to spend money. In other cases, businesses struggle to allocate the necessary resources and budget for these projects, especially if they are also dealing with other technology priorities or there are unidentified complexities in the systems.

Complexity of Legacy Systems: Many businesses rely on legacy software applications that have been in use for years or even (*gasp*) decades. These systems may be outdated, become more difficult to maintain as they age, and are not designed for the current digital landscape.

Integration Hurdles: Integrating apps with other systems and cloud-based services remains a challenge for many businesses. Ensuring seamless integration can be a significant obstacle, as it requires deep understanding of both legacy and modern technologies.

Security Concerns: Addressing security vulnerabilities during the modernisation process can be key. Cybersecurity is a top concern, especially in industries that handle sensitive customer data, such as retail media businesses.

Talent Shortages: Finding skilled professionals who are well-versed in legacy systems as well as modern technologies (and where they intersect) can be a challenge.

Keep tuned for the rest of our series, and of course, if you're grappling with any of the challenges above, get in touch!

Winner: Digital Design & Innovation (Good Design Awards)

Fri, 15 Sep 2023 03:59:39 GMT

Patient Zero has been awarded the prestigious Good Design Award Winner accolade in the Digital Design category. As Australia's oldest and most respected international design endorsement, this win validates the world-class capability of our 100% onshore engineering teams .

The award recognises the Birrunga Gallery AR App , an immersive augmented reality experience that allows visitors to interact directly with First Nations artists. It stands as a benchmark for how sovereign capability can bridge the gap between ancient storytelling and cutting-edge technology.

Setting the Standard for Digital Design

The Good Design Awards Jury praised Patient Zero for "sticking to best-in-class design principles," noting that the app uses "intentional digital design" to enhance, not distract from the user experience.

“The community connections achieved through the app makes it clear that the teams' guiding principles were deeply respected and successfully upheld.”

- Good Design Awards Jury

For our enterprise clients, this confirms that Patient Zero delivers User-Centred Design (UCD) that holds up to international scrutiny. We don't just build software; we craft digital products that solve complex human problems.

Validating Sovereign Innovation

This project was designed, built, and launched entirely on Meanjin (Brisbane) land. It is a powerful example of Sovereign Innovation , proving that Australian teams can deliver global-standard technology without offshoring a single line of code.

By keeping the team 100% onshore, we ensured that the cultural nuances of the Wiradyuri stories were preserved with absolute integrity, a level of collaboration that is impossible with disconnected offshore teams.

Sustainable Engineering

Beyond the "shiny" AR features, this project was an exercise in Sustainable Engineering . As Demelza Green (Principal Experience Manager, now Co-CEO) noted, the gallery artwork changes every six weeks.

We didn't just build a one-off app; we engineered a flexible content platform that considered the long-term costs of production and maintenance. This "Total Cost of Ownership" mindset is exactly what we bring to our Software Development projects, ensuring you get a solution that is sustainable, scalable, and cost-effective.

Why This Matters

This award serves as independent validation of our digital product capabilities:

International Recognition

The Good Design Award is an internationally recognised seal of quality, proving our design capability rivals any global agency.

Cultural Intelligence

Validates our unique ability to handle high-sensitivity content (Indigenous Data Sovereignty) with respect and technical precision.

Sustainable Architecture

Proves we build for the long term, considering maintenance costs and scalability from Day 1.

Explore the Capabilities Behind the Award

Mobile & AR Apps: Discover how we build immersive digital experiences and enterprise mobility solutions. View Mobile & AR Apps
UX/UI Design: See the design principles that won Australia’s top design award. View UX/UI Design
Software Development: Learn about the 100% onshore teams that power our innovation.
View Software Development

Ready to Build Award-Winning Digital Products?

Don't settle for "good enough." Partner with a design-led engineering team.

ABOUT THE GOOD DESIGN AWARDS

The Australian Good Design Awards are the country's oldest and most prestigious international awards for design and innovation. Celebrating the best in design, architecture, and engineering, the awards recognise projects that demonstrate excellence in design strategy and positive impact.

Birrunga Gallery AR App: Cultural Storytelling

Wed, 31 May 2023 01:54:25 GMT

First Nations artworks come to life in new Augmented Reality application

Patient Zero and Birrunga Gallery have launched a new Augmented Reality (AR) application, allowing visitors to the gallery to interact with, and hear directly from, the First Nations artists whose work is on display.

This immersive AR experience provides visitors with a deeper connection to the stories behind the First Nations artworks showcased at Birrunga Gallery, helping to build a stronger connection with the events, stories and truth-telling on display.

The app was officially unveiled at an event at Birrunga Gallery on May 27.

Patient Zero’s Principal Experience Custodian Demelza Green said the app is a unique tool that is helping to record, share and preserve First Nations stories for years to come.

“When Patient Zero first looked at augmented reality, we found a market saturated with short-lived experiences, and we wanted something that would have a longer lasting impact,” Ms Green said.

“With the Birrunga Gallery app, we’re using this technology to enhance a person’s experience at the gallery, to build their cultural understanding instead of merely distracting or entertaining them.

“Visitors are immersed in a cultural experience enabled by technology — not a technology experience that overshadows a cultural one."

By leveraging Patient Zero’s unique Way of Working, Birrunga Gallery was able to introduce this groundbreaking technology in months, not years.

Birrunga Gallery Founder and Principal Artist Birrunga Wiradyuri, a Wiradyuri man, said the app lets First Nations people tell important stories on their own terms.

“The app provides an unprecedented opportunity for us to engage with our visitors directly. Through utilising Augmented Reality, we have the opportunity to use our voices, tell our stories, speak directly with visitors in an intimate, interactive and immersive experience,” he said.

“You just can’t capture the nuances of our Cultural narratives in an exhibit label. With this app, visitors don’t just gain an understanding of an artwork, they experience it.”

The application is the result of a long and close partnership between Birrunga Gallery and Patient Zero, and was fast-tracked to market in under two months, using the Unity framework to build a truly immersive experience.

“Patient Zero was the only choice when it came to a partner for building this application," Birrunga said.

"We moved quickly from idea to execution, and we were able to get an experience into our visitors’ hands within two months.

“Even more importantly, we are capturing our stories for all time."

The Birrunga Gallery AR app is available the Apple and Android stores now.

Winner: Tech Innovation & Agile Delivery (ARN Awards)

Wed, 21 Sep 2022 00:41:43 GMT

Patient Zero has been named the Australia-Wide Winner in the Tech Innovation category at the ARN Innovation Awards .

While many consultancies claim to be "Agile," this award specifically recognises Patient Zero’s unique Way of Working (WoW) . It validates a delivery model where trust, autonomy, and speed replace the bureaucracy typical of enterprise software projects, allowing our 100% onshore teams to drive genuine organisational change.

Validating the "Way of Working"

The judges cited our ability to "leverage established and emerging solutions to enhance customer innovation." Crucially, they highlighted that our model is geared towards driving organisational transformation , not just writing code.

“Patient Zero has been recognised for its delivery of consulting engagements... via its unique 'Way of Working' model to help overcome delivery challenges.”

- ARN Judges

For our clients, this confirms that hiring Patient Zero isn't just about adding headcount; it's about injecting a high-performance culture into your organisation that breaks down silos and accelerates delivery.

The Power of Autonomous Teams

Tobias Smith, one of our lead developers, notes that this award is a victory for developer autonomy . In traditional environments, "non-delivery time sinks" like excessive meetings and architecture committees slow progress to a crawl.

Our model flips this. As Tobias explains:

"The idea here is that you want to trust that the people you've hired are smart enough to make the right decisions...

Our Way of Work enables us to make decisions fast, and fail fast, because the best way to see if a solution will work is to test it out in real-world conditions."

This philosophy allows our embedded teams to iterate rapidly, tackling complex problems sooner and delivering value weeks or months ahead of traditional vendors.

Driving Real-World Transformation

Innovation isn't about using the newest tech for the sake of it; it's about solving business problems. This award recognises that our "Team-First" approach leads to happier developers and happier clients. By removing friction, we allow our engineers to focus entirely on customer outcomes , resulting in significant growth for the accounts we serve.

Why This Matters

This award serves as independent validation of our delivery methodology:

Velocity

Proves that our "trust-based" model allows teams to make decisions quickly, avoiding the bottleneck of "design by committee."

Autonomy

Validates that empowering developers (rather than micromanaging them) leads to better technical solutions and higher retention.

Outcome Focus

Recognises that our consulting engagements are designed to drive organisational change , not just deliver a software artifact.

Explore the Capabilities Behind the Award

Embedded Software Teams: See how we embed this "Way of Working" into your organisation to drive uplift. View Embedded Software Teams
Working at Patient Zero: Discover the culture that attracts and retains Australia’s top engineering talent. Learn More about Working at Patient Zero
App Modernisation: Learn how high-velocity teams de-risk complex legacy migrations.
View App Modernisati on

Ready to Build High-Velocity Teams?

Don't let bureaucracy kill your innovation. Adopt a Way of Working that delivers.

About the ARN Innovation Awards

The ARN Innovation Awards are the premier recognition program for the Australian ICT channel. The Tech Innovation category awards partners who leverage deep expertise to drive customer innovation and transformation. Patient Zero's win as the Australia-Wide Winner cements its status as a leader in modern software delivery.

The Conversion of a VR Sceptic: Working in VR

Wed, 11 May 2022 23:32:19 GMT

By Stefan Kosnik, Product Owner

As a product owner, I’m very tied to my computer to get work done. So when the idea of working in virtual reality was floated, I was sceptical that it would add any business value.

We already spend so much of our working day in meetings, so I wanted to know whether I be able to get any real work done in VR without my computer.

My general sense was that we’re just not ready for VR, that the technology is too immature to use at work and maybe we, even with all the changes the pandemic has brought, just aren’t ready either.

So, I raised these concerns with our Developer Custodian (and VR enthusiast) Paul Seymour.

His response? That trialling VR was exactly about finding an answer to these questions.

Working at Patient Zero, this approach is not uncommon. We apply our Way of Working to just about everything - which means that testing, iterating and learning isn’t just part of our development process, it’s part of our culture.

To be honest, I also wasn’t entirely disappointed about the idea of at least having a play with the latest Oculus gear either.

After our first sprint working in VR, I have to say I’m pleasantly surprised at the results. After getting over the initial ‘Wow’ factor of being in the metaverse, using the tools in Horizon Workrooms very quickly becomes second nature.

I am able to partially bring my hardware into VR, remote desktop (one screen only) via the Oculus app and my mouse, but there are limitations at present to which keyboards can be scanned in. This means all agenda items need to be pre-prepared on the one screen.

Collaboration is much easier and more engaging than existing meeting platforms (Zoom, WhereBy, Teams, etc.) - directional audio means that when someone turns away from you, they are muffled. It actually feels like you are in room together. We also end all of our meetings with the ‘High Five’ feature, it’s pretty cool!

What’s holding it back?

Resolution. The headset hurts your eyes after a while, because the resolution just isn’t high enough to be comfortable. It’s not high enough to showcase User Interfaces in VR either, nor to be able to peer program, so you need to switch back to video conferencing for these kind of tasks.

The other big ticket on my wishlist now is to set up a VR room at home. Drawing in the air is really, really difficult. So when using the whiteboard you need to have a solid surface to write against, you also need to have a keyboard and set up that works with the physical prompts in your virtual reality.

But almost all of the drawbacks of VR for work are technology issues that will inevitably be solved by the march of technology. The headset will get lighter, the resolution higher, the controllers more tactile in their response.

So call me a convert? Maybe.

I’m more excited about the promise of VR than I was before, and I’m enjoying using it. There is a definite business use for this technology now, but is it at the point where everyone should have a VR headset on their desk?

We’re still trialling it at Patient Zero so you’ll have to wait for our answer on that. But personally?

We might not all need a VR headset on our desk, but in a few years? Absolutely.

Patient Zero Enters the Metaverse: Hybrid Work

Wed, 27 Apr 2022 23:26:08 GMT

By Demelza Green, Principal Experience Manager

At Patient Zero we love working with new technologies.

Any chance we can get to explore a new piece of tech’s potential, we’ll take it. Whether it’s jumping onto the Kubernetes bandwagon, working with a package that is still in beta (which definitely has its pros and cons), or working with the applications of blockchain, we love exploring the potential of new technologies and how these can make our lives, and those of our clients, better.

So when Facebook became Meta and refocused on the Metaverse, we paid attention.

Not in an ‘oh let’s generate some PR moments’ kind of way, but in a ‘how can we leverage this technology to enhance the PZ experience in our hybrid-operating model, whilst having some fun.’

This technology has the unique potential to power a range of different dynamics that is fundamental to our Way of Working, which sees our development teams come together regularly for ceremonies throughout each sprint. So whether it’s a daily stand up, showcase, or a sprint planning meeting, our teams are constantly collaborating with each other to solve the inevitable challenges that come up during every development project, collaboration that Slack and Whereby enable functionally, but don’t build the human connections we all thrive on.

When it came to decision time, it was kind of a no-brainer that Metaverse could benefit our teams in our hybrid working model, so we decided that it was worth equipping a team with Oculus Quest 2 VR headsets and settled on Horizon Workrooms to power our collaboration for this trial. While Horizon is still in Beta, it’s a Meta application so it’s the closest thing you can get to a native application for the Oculus.

Then, given it’s 2022, we started waiting for everything to arrive.

And after a little bit of time, the devices started to trickle across to our pilot team in Sydney and Brisbane. After some inevitable (but still way longer than expected) just-turned-this-on-for-the-first-time OS updates, setting up the play zone free of trip hazards, and selecting from the 1,000 available eyebrows to choose from for the avatar, the team was ready to transition onto Horizon Workrooms and see how this worked.

I’ll leave it to the team who are piloting this to share their reflections on how the day-to-day of working in the Metaverse is panning out (spoiler alert – I’m not actually a member of the development team that’s trialling it, but as our Principal Experience Manager I, of course, have my fingers in the pie), but what I can say is that our first showcase last week was an amazing experience.

During the pandemic, we’ve gotten used to working from home, with two dimensions of everyone in their lounge, bedroom, or study, so to be able to see everyone in 3D was a huge step up. I know it’s trite, but it actually felt like we were in the room together, bringing a completely new and different energy, creating a more human connection.

Over the coming weeks, some of the members of our team who are trialling the Metaverse will share their reflections on how they’ve found it, what we’ve learned and how we’re applying these learnings.

So stay tuned if you’re interested in how VR and the Metaverse can be used at work to drive collaboration, enhance productivity, and most importantly – build stronger connections in a hybrid environment.

Strategies to Outperform the Tech Resource Crunch

brendan@patientzero.com.au (Brendan Homann) — Wed, 22 Sep 2021 22:31:22 GMT

Globally referred to as “The Great Resignation” many industries are affected by a seismic shift in the availability of workers.

We’re certainly seeing this is the case in the IT Sector. The volume of available jobs is significantly out paced by the volume of available candidates. You may have already seen the obvious by products of this with rising salaries and employees seeking out improved conditions.

The less obvious, and less discussed is what can be done to counteract the lack of talent and less obvious again is to ensure we "still deliver". Most advice I’ve seen is largely generic. The simpler answers are the usual management adages of “do more with less”, or ask employees to do #overtime. But we all know in IT that the more overtime we do the worse quality becomes – so we can’t turn there.

I went looking for inspiration, and found some in the book and movie “Moneyball” – it’s based on the story of the 2002 season of the Oakland A’s baseball team. They’re trying to compete with teams which have 6x their budget. The GM is convinced they can’t compete head on with their rivals, in the war for talent. However, the GM discovers, through some uncommon thinking, a mathematical formula to bypass “traditional thinking”. Their strategy was to field a team of people who would win runs, regardless of how they managed to do that. This approach pays off and they win their season. In the most obvious of outcome’s all the other teams in the league emulate their success. Strategy based on statistics transforms the entire sport, and trickles across other sports as well.

This got me thinking – What is our moneyball moment in IT? We've already removed the commute with most people Working from Home. Surely there are other things could we do, beyond just trying to get bigger budgets to win the war on wages…

Productive Time is not Valued – we need “Productive Time” to do the work. Most developers I know say they need long stretches (3-4 hours) of time without the interruption of phone calls, emails, instant messages or meetings. Yet most calendars are crunched in teleconference calls about strategy, architecture, triaging bugs, product backlog refinement, recruitment, company meetings, daily standups, training new staff and more. What would it mean to value productive time?

Multiple Priorities Remain – people are not great at multi-tasking. When you have to support multiple streams of work, your efficiency drops. Most organisations struggle to help the individuals make prioritisation decisions, insisting that everything is important. Context switching is a killer for productivity. Can we be clearer on priorities?

Interesting Architecture isn't necessarily productive - I see organisations decide to use new and novel code libraries/technology or approaches, imitate the FAANGS (Facebook, Apple, Amazon, Netflix, Google) - because it's "interesting" to their developers. You can solve a problem with an event driven architecture because Netflix did it, but first hand experience tells me finding developers who are truly productive with that approach is difficult. You can adopt that latest hyped up UI framework, but experience tells me if you fast forward 6 months, you may be left with diagnosing framework issues yourself, complaining on github about the lack of updates, and be unable to hire developers who don’t want to work in an obscure technology, all while living with productivity issues. The more complex you make your technical environment, or the more obscure, the more experienced the developers will need to be to work on it, the longer the work will take, and the greater the cost. This is especially true if your “interesting architecture” ignores critical things like automated test coverage. Can you achieve the same result with a plainer architecture, less complexity, less experienced developers?

Minimising Time Wastage – thinking through the activities team performs there is often time wastage - information doesn't flow, people are forced to be idle or multi-task to be productive. Some organisations put up with builds taking 30 minutes or more. If a developer does 3 builds per day that’s 1.5hrs a day or 7.5hrs per week of time waiting on a build. If you read the State of Devops report annually you'll see a strong correlation with minimising build time with organisational profitability. It's not just build times, there are so many other factors like hot reloading of the UI, reducing the chance of issues being caused by disparate environment configuration through increasing the similarity between local/dev/test/prod (e.g. through docker & infrastructure as code) to avoid chasing config issues as code moves through environments. Even just having testers or subject matter experts verify the functionality is fit for purpose, as soon as it’s done, not after the sprint ends! Can you speed up the feedback cycle time to developers through faster builds or faster subject matter expert feedback?

Strong Product Ownership – A strong product owner will think through and list out all of the weird and wonderful scenarios you need to cover in building that new feature. They not only cover the typical use scenarios but all the squirrelly edge cases like first use, different user roles, core business logic (e.g the start date must be before the end date). If your Product Owner doesn’t proactively perceiving the problems, your developers will spend their time going back and forward to get clarifications. If your developers and product owners miss the mark, your users will raise bugs, and you'll be amending the features anyway. Can you reduce the number of cycles between Product Owners, Developers and Users to get the features just right?

Streamline Agile Ceremonies – I’ve observed organisations schedule ceremonies around the availability of their stakeholders. One example is running a showcase 24 hours after the sprint closed, just to get stakeholders available. If this holds up planning the next sprint till after showcase, it leaves 1 whole day of development team limbo! If you can run all of your key Agile ceremonies back to back there is some serious efficiency gain. For a Scrum team I usually prefer to run these sessions back to back covering showcase/sprint review, retrospective, estimates, sprint goal / sprint plan and task decomposition. If you get it right you can be all done and dusted in one morning and be starting a new sprint in the afternoon. What if your stakeholders cleared their calendars to keep the developers productive?

Useful Links:

Harvard Business Review Who is Driving the Great Resignation
https://hbr.org/2021/09/who-is-driving-the-great-resignation

Aaron McEwan ( https://www.linkedin.com/in/aaronmcewan/ ) of Gartner discusses the Great Resignation https://www.abc.net.au/radionational/programs/this-working-life/the-pandemic-driven-great-resignation/13536416

Film Moneyball 2011 - different thinking to get outsized results with capped budgets https://en.wikipedia.org/wiki/Moneyball_(film)

Revitalising Scrum: How to Fix Stagnant Processes

Fri, 27 Nov 2020 05:08:10 GMT

Make Scrum Great Again: 10 Key Takeaways From The Updated 2020 Scrum Guide

The Scrum Framework turns 25 this year. To celebrate, Ken Schwaber and Dr Jeff Sutherland updated the Scrum Guide with a launch on the 18 November 2020. You might have missed this session on Zoom at 1am Australian time. They talked about the history of Scrum, and what their goals are with the new release. This was followed by workshops on Driving Focus and how the updates impact your scrum.

If you don’t have 2 hours to listen to the briefing, here are my top 10 takeaways:

It is less prescriptive , “lightweight…purposefully incomplete, only defining the parts required”. With the details removed the guide aims to be clearer, more flexible with more focus on leadership and creativity.
One team . Previously the development team was described as a sub-team inside the Scrum team, this distinction has been removed. As a result, there is no more us/them, “no sub-teams or hierarchies”. There is just one team which includes accountabilities of “one Scrum Master, one Product Owner, and Developers”.
Product Goal - a new and mandatory part of the Product Backlog is to “make sure people are using Scrum to get somewhere…to actually deliver something”.
Emphasising Sprint Goal, Definition of Done, and Product Goal – these are now mandatory “commitments” to the artifacts, which increases transparency and focus.
Self-organising is now self-managing , “meaning they internally decide who does what, when, and how”.
Sprint Planning – why is this Sprint valuable? Finalisation of the Sprint Goal is added to the existing topics “ what can be done?” and “ how will the chosen work get done?”.
Simpler, shorter, more inclusive, non-technical . The new guide is more welcoming in non-software development contexts.
The moment a Product Backlog item meets the Definition of Done, an Increment is born – enabling multiple releases to production per sprint at the delivery of each story.
“Agility is not the solution to your problems, agility is how you solve problems ”.
“Scrum hasn't changed, we're just getting the description better”.

Posting this summary up to our company slack stirred up some lively comments from our Product Owners, Developers and Scrum experts. Most of this conversation centred on the new Product Goal and its relationship to Product Vision and Strategy, which led to the headline “Product Goal: Make product great again”.

The 2017 Scrum Guide was still pretty great, but as Scrum.org CEO Dave West says on the launch video “They’ve gone back to their roots, and it’s awesome”. They’ve also recognised that most organisations are speeding up their clock cycle times, releasing more frequently, and the guide recognises this, which is great to see.

If you’re interested in Making your Scrum Practice Great Again, we recommend adopting the 2020 Scrum Guide. We are available to offer briefings to your organisation about these practices and coaching on how to embed the subtle nuances of the changes.

More information can be found at:
2020 Scrum Guide at https://www.scrumguides.org/scrum-guide.html
YouTube: https://www.youtube.com/watch?v=Dfxo3PZwDI8

4 Common Mistakes in Agile & Scrum Implementation

Tue, 17 Nov 2020 00:45:46 GMT

Agile is a tricky thing to get right, To the uninitiated, it appears to be more relaxed and less rigid than waterfall or other project management methodologies. This could not be further from a well-oiled Agile Scrum project

When done right, and supported by the correct mindsets, framework, and disciplines, Agile combines a perfect blend of innovation, risk-taking and structure. However, when done poorly it’s a broken, nerve-wracking and ineffective approach, otherwise known as (Fr-agile).

As a consultant, I get to see how dozens of organisations operate their projects each year. I have listed below the four most common mistakes I see organisations making:

1. It is not just about going faster

Going faster can be a side effect of several key Agile practices, but you're not going to reap the rewards of Agile immediately.

Many teams practice all the Scrum ceremonies and begin moving quicker than they ever did under Waterfall. Soon they come to realise that they are simply building the wrong things faster.

While it’s true that you can indeed go faster with Agile, twice as fast when done right .… The other benefit is value, which requires a deep understanding of the business, what the customer/user values and their priorities

2. Assuming anyone can be a Product Owner

Many of our customers make the mistake of nominating one of their staff as Product Owner, but not provide them with any formal training, or frameworks. This is setting them up to fail, as even the most seasoned product owners who are familiar with defining a product vision, roadmap, and software solutions may still not fully understand context, constraints, stakeholder personas, business rules, non-functional, and transitional requirements.

In Patient Zero's way of working, we operate with a Client Product Owner and a PZ Product Owner. This has been a highly successful arrangement as it takes a lot of the pressure off of the Client Product Owner in terms of having to be intimate with Agile ceremonies & disciplines guiding them on the journey while ensuring that their insights and industry knowledge are incorporated into the final product.

A big part of my job is guiding the Client Product Owner through the more technical or process-oriented aspects of the job, and I learn from the Client Product owner, the nuances of the industry and customer sentiment. It's a highly collaborative and productive way of operating.

I also act as the Scrum Master, whose role is to insulate the team from impediments and distractions that jeopardise the commitment and ensure the team is performing and stress levels are managed.

3. Going Agile, but tracking to a Gannt Chart & Weekly Status Report

Most of the time, organisations shift over to an agile methodology, but still expect the same reporting (Gannt charts, deadlines and weekly status reports) This is where many businesses get it wrong, as agile reports such as the burndown are an essential and powerful tool in measuring progress.

Agile reports operate more or less like the instrument panel in your car and indicate how the team, individuals & project are performing and can predict roadblocks, challenges and indicate when to add in more work or take some out.

For instance, an Agile Sprint Burn Down, at its core is a way to measure progress in a sprint and detect potential shortfalls and blockages, but it’s also used like an oil temperature gauge to measure stress levels.

If the leadership team wants the deadlines agreed upon before, while simultaneously undergoing an agile transformation and not to be impacted, I'd be the first to say that Agile isn't going to work that way.

Many of the reports in Agile are simple in appearance but they are highly contextual and useful when measuring performance so by not utilising them you are missing out on some of the biggest benefits.

4. Not Respecting the Sacrosanctity of the Sprint

In the ideal environment, the whole agile team is focused on the same work items identified and agreed upon by the team, and only those work items are being worked on by the team members for the current sprint. We say the sprint is in a vacuum, or sacrosanct.

I think this is a big piece of the magic behind Agile, as in every sprint the team collectively set their own goal and will "sprint" to honour the commitment working toward a broader objective one small goal at a time.

However, if for any reason team members are regularly and consistently expected to do work outside of the sprint, it cannot just be absorbed, those additional work items should be reflected in the velocity.

The burn down chart, the missed sprint goals and the reduced capacity of the velocity should provide transparency to how the resources are allocated and the impact should be accessed and communicated to show the real cost of these "Priority Tasks".

Recently I took a client through all these "priority changes" that were insisted upon, which I earmarked as "variance" in the title. They were shocked that when I added them all up, they would equate to several thousand dollars in work and delay launch by 3-4 weeks.

We determined that only 2-3 of these items were really a "Priority " and we developed an exceptional product which finished on time and on budget.

Now that being said, I hope this does not dissuade you from embracing Agile, true it takes discipline and rigour to get the most out of it, but we can help you on your journey. To learn how we can help, get in touch with us here .

Patient Zero Achieves AWS Select Tier Partnership

Fri, 13 Nov 2020 00:33:05 GMT

Patient Zero announced its AWS Select Tier Partnership Status in November 2020.

This is another step in ensuring their staff are certified across the most popular cloud platforms after announcing its Microsoft Gold Partnership status earlier this year. The vision is to advance to the next partnership tier over the coming months.

CEO Paul Briggs states “We are dedicated to ensuring our staff are certified in the most popular cloud platforms. This is simply the best way we can assure our clients that we serve them with their best interests at heart, with solutions that are specifically tailored to their needs”.

Patient Zero has stood firm in being technology agnostic so that client problems are able to be solved with a variety of tools, rather than being bound by the limitations of what is possible through a single technology solution. This operating model ensures that their staff are up to date with the latest features across a range of platforms, enabling them to provide robust solutions to their client challenges.

Their AWS partnership has solidified their commitment to leveraging powerful cloud-based platforms, ensuring their staff are up to date with the latest technology and being able to adapt as new features and technologies are released.

For more information regarding Patient Zero’s AWS Partnership status, or to discuss your application development needs, please contact their sales team on 1300 714 093.

Patient Zero Achieves Microsoft Gold Partnership

Mon, 20 Jul 2020 04:51:03 GMT

Paul Briggs, CEO of Patient Zero states “We are incredibly proud of the solutions we have built leveraging Microsoft technologies and our work within Azure. We look forward to continuing our work with Microsoft as we roll out solutions for our customers across the country.”

Patient Zero delivers client focussed technology solutions across Software Development, Consulting and Managed Services. They continue to innovate for their clients through their way of working. Delivering numerous benefits not only for the Patient Zero team but also their clients.

Patient Zero will continue its focus on cross-platform application development, a shift spearheaded by Microsoft over recent years. They are looking forward to continuing providing their clients with quality solutions alongside one of the best cloud providers globally.

For more information regarding the Microsoft Gold Partnership status, or to discuss your application development needs, please contact their sales team on 1300 714 093.

Mobile Frameworks: PWA vs React Native vs Xamarin

brendan@patientzero.com.au (Brendan Homann) — Thu, 16 Jul 2020 02:00:02 GMT

From time to time customers approach us concerned about how they can best deliver a mobile app. It’s fair to say there are plenty of pitfalls, war stories and unknown unknowns to make the most battle-hardened CIO consider their options carefully.

We put together a rough guide as to the relative merits and challenges you might have when picking one solution over another.

PWA – Progressive Web Apps are a newer approach where a mobile-friendly, client-side, browser-based framework like Angular or React is used and made available to web users and mobile users. Some of the key benefits of PWA’s is that while they’re not published to the app stores, they support some valuable capabilities like offline support and instant version updates to both mobile and browser-based users. It is important to remember however that some PWA features are not available on all platforms compared to native apps, like push notifications on iOS. You can wrap a PWA using a solution such as Cordova to deploy it to the app store.

React Native – Similarly to PWA’s, Javascript developers (especially those with ReactJS experience) will feel comfortable using React Native. React Native offers a native application experience to its users but is most often suited for small to medium-sized applications that don’t require heavy computation loads. Moreover, React Native will be distributed to your users via the Apple and Google app stores, allowing you to utilise some of their offerings like the number of downloads, usage metrics, etc. React Native applications will not be available to browser-based users.

Xamarin – Xamarin has long been the preferred option for .NET developers looking to write applications for all major app stores (Apple, Google, Microsoft). Xamarin allows you to use code you have already written in .NET (with some exceptions) which can be desirable to some (often enterprise) organisations. While often the first choice for .NET developers, some developers find Xamarin development rather slow. It is worth mentioning that Xamarin’s popularity has been declining over the past few years.

Flutter – Worth a mention is Flutter, the youngest cross-platform development toolkit. Flutter is supported by Google and provides a great experience for rapid development. While Flutter is gaining in popularity, given its relative infancy is still building its community and associated support.

Our typical recommendation today is that a well built Progressive Web App is hard to beat, especially when you consider you write the code once and it works for your web users, mobile web browser users and mobile app users. You have access to so many great features via a PWA today that there is almost nothing a PWA cannot do unless you’re about to build complex computationally demanding applications like games or AR experiences.

But if you’re still not convinced here is our take on a comparison of the three major cross-platform options you have available today, Progressive Web Apps (PWA), Reactive Native and Xamarin.

A Comparison of PWA’s, React Native and Xamarin:

Conclusion

The three major cross-platform options suit a range of needs. We hope our comparison helps you understand their functionality and use cases better. If you need any help choosing the best platform for you, please contact our team.

Remote Development Teams: An Assessment of Effectiveness

Wed, 01 Jul 2020 22:13:25 GMT

Across the world, organisations are adapting to working remotely. For some organisations this is new, and for other organisations, it’s something they are well versed in. At Patient Zero our preference and our clients’ preference has typically been to work face to face in our clients’ offices.

We’ve been carefully looking at the effectiveness of remote work for our software development teams since we moved to remote working in early March 2020 due to COVID19. In order to assess how our teams are going, we investigated a range of factors to try to give us an indication of how our teams’ performance may have changed during this period. We carefully watched velocity, burndowns and sprint stability. We actively sought out our teams’ and clients’ feedback in group settings and one on one.

All indications so far show that PZ development teams are just as effective remotely, as they are face to face, in fact, they may work better remotely.

We wanted to understand why our teams were successful with remote working, while our customers reported challenges and communication break downs on other projects. From our research across 6 PZ Development teams operating in a wide variety of technologies and industries we have distilled the feedback down to these key factors:

1. Governance

At PZ our Way of Working sees clients actively involved in reviewing and prioritising the backlog. They are also involved in approving the start and accepting the result of each sprint. When we moved to remote working, these approval practices easily translated to teleconference. Our clients reported their teams struggled to confirm their backlogs, verify priorities and get approval from stakeholders when working remotely, PZ seemed immune due to our strong governance practices pre-existing the shift to remote work.

One of our clients commented "What has worked better than expected is working remotely, we didn’t notice any change in velocity. The way the team is working in the our environment, as hybrid team of our people and PZ people together. We’ve even used a number of PZ ways of working to get our internal teams working better remotely."

2. Sprint Milestones

PZ Development Teams as a Service operates sprint milestones. Our clients’ deadlines depend on successful sprints and we are invested in successfully completing the same sprints! When we shifted to working remotely, our teams still retained their focus on ensuring successful kickoff of approved sprints and successful delivery of quality sprint goals. We found that Showcases worked even better remotely and afforded a chance to record and share with those who couldn’t make it. The chat capability of video-based showcases maximised feedback, giving those shy people a chance to ask questions during the presentation.

3. Reduced Spin Up Time

We’ve had clients suggest their concerns about forming a team remotely to take on a new challenge, citing the concern of an increase to ramp up time as these teams must agree on processes, technologies, scope, priority along with forming mutual bonds. Our pre-configured cross-functional teams are built with significant care. We monitor 17 factors when assembling teams. Ensuring we have the right technical skills, cultural alignment with the client and the ability to work together. We add to this our fully formed PZ Way of Working which ensures team members know their roles and play to position well. As a result, we established multiple new teams to take on new projects entirely remotely. Our clients received working software, great documentation and full suites of automated tests with their delivery on time and on budget with the additional scope included! Projects which kicked off remotely ran smoothly, the governance practices aided this by enabling us to start producing valuable work remotely as quickly as face to face.

4. Transparency

PZ teams practice absolute transparency in their delivery model. This transparency is provided daily insight via telemetry and metrics to monitor and also at the end of sprint showcases. Our teams track a range of critical metrics.

Each sprint we continued to measure:

Velocity (sum of points completed) – this largely remained constant or trended upwards
Unit test Coverage – our teams naturally aim for 70% coverage
Automated UI Test Coverage – our teams must end each sprint with tests passing
Load/Performance Tests – our teams end each sprint verifying these results
Changes to the sprint plan – our teams are trained to carefully handle changes to sprint plans

As an example, the following is the Velocity Measurements from an 11-week project started remotely with a team who had not worked well together before. Sprint 0 was 1 week to get tooled up, environments available, and familiar with the new domain. Each subsequent sprint was closed and accepted by the client with a consistent velocity:

Each day during a sprint we:

Ran standups and escalated issues through our PMO
Shared our burndowns with PZ

This is a typical burndown chart shared within our company-wide slack feed. This type of burn down chart is affectionately known as a “ski ramp”, where your progress is so good, you decide to commit to more work during the sprint (usually because something got blocked). We found a combination of fewer distractions and reduced commute time increased focus time and resulted in outputs that exceeded our own estimates.

Sharing burn downs with the entire company wasn’t about upper management oversight, but about finding ways we could support each other to deliver. Our teams had the whole organisation cheering them on if they appeared off track. We had team members from other teams offering to help any time the burndowns got off track. These metrics were an ideal opening to a conversation about what the challenges were and how the entire organisation could help a team. There were plenty of examples of team members supporting each other.

We also wanted to assess ourselves against the core Agile principles we subscribe to:

* People and Interactions – our teams shared Slack channels with client stakeholders and we provided access to a video conference location for team members to jump on and collaborate as necessary. Ceremonies like standup, showcase and sprint planning moved online successfully. As a result, we saw increased collaboration digitally, replacing the interactions we normally had face to face. This usually started early from 6am and continued late into the evening as people worked around personal constraints of supporting family and friends, school and the like. Teams commenting to say good morning, ask each other how their weekends were, celebrate each others birthdays and even started sharing pictures of their pet cats, dogs, chickens and snakes!

* Working Software – we delivered working software every 2 weeks due to our sprint milestone approach. There was no change from business as usual, each sprint the teams shipped functional software. Demonstrated the features to users in a live demo with the software running in a deployed environment. The only way to get it deployed was to go through the CI/CD pipeline with automated UI tests, Unit Tests and Load Tests passing.

* Customer Collaboration – we shifted collaboration with our customer and their stakeholders to digital with chat and video conference. We were able to seek feedback early and often, having customers attend showcases, ask questions, and present feedback improved the cycle time for this collaboration.

* Responding to Change – when challenges occurred teams escalated the issues and obtained support as needed. When new insights emerged, the backlogs were reprioritised and changed. We saw no observable change in our team’s ability to respond to changes due to the governance practices and collaborative tooling they had access to

Overall, we’ve seen little to no drawbacks to working remotely, and even in some cases an improvement in moving to remote work. We are strongly considering adopting this as a practice going forward and encouraging our teams and our customers to establish remote work as the new business as usual.

Meet Sam Stewart: Business Analyst & UX Designer

Wed, 05 Feb 2020 00:15:21 GMT

Meet Sam Stewart, a dual-threat specialist bridging the gap between Business Analysis and UX Design to deliver better software outcomes.

A Patient Zero Internship: The Developer Experience

Tue, 17 Dec 2019 01:57:58 GMT

Earlier this year Patient Zero hosted three students from the University of Queensland for an internship program. Starting with our induction program, the students were taken through the paces of working in a cross functional agile development team. We taught core skills for team based software development work like using GIT, resolving merge conflicts, estimation and task decomposition. The students were given the opportunity to work on a variety of team projects to further their skillsets. We spoke to one of our interns Fei about her internship experience.

1. What was the most challenging part of the PZ internship program?

As an international student who did not have any industry experience before, the transition into the workplace was a bit challenging. I was not sure what exactly to do, what would be expected of me and how to do things ‘professionally’. Quite a few of the programming languages, tools and workflow used in PZ were new to me. I felt unprepared at the beginning but later found that it was not hard to learn new skills quickly by joining a project team.

2. What was your favourite part of the PZ internship program?

It was great to be a part of a scrum team and work on real-world projects. I participated in all scrum events including the Sprint Review where we showcased the progress to stakeholders. Everyone in the office was very supportive and open to answering any questions I had.

3. What skills did you learn?

My team worked on a set of three hybrid mobile applications. I focused on automated UI testing using cypress, learned about Angular, and got a taste of team-based software development. I appreciated the experience of working in scrum and collaborating with team members.

4. In what ways did PZ invest in you?

The first week was all about the onboarding process and PZ people in different roles walked us through it. We were guided to practise technical skills, know about the PZ working environment and the scrum approach.

Interns worked in different project teams during the next few weeks. Each of us were paired with a technical leader and a buddy for general questions. Everyone in the office or on the Slack channel was also willing to share their time and experience.

Every fortnight Patient Zero hosts Lunch & Learn sessions. During these sessions there are talks given by internal or external speakers covering various topics: technology, business, project management, etc. At these lunch and learn sessions, I was able to learn about Patient Zero staff including those working on the client site, and of course, I enjoyed the delicious food!

5. What advice would you give to anyone considering joining PZ as a graduate?

Do not be afraid of making mistakes and asking questions. They are good ways to learn and the Patient Zero team would love to support you. You are not expected to know everything before starting work, but to be open-minded and able to learn new skills quickly. Be proactive and clear about what you would like to achieve. Be a good team player and share your enthusiasm for working in this industry.

Meet Demelza Green: Principal Product Manager

Sun, 01 Dec 2019 23:25:11 GMT

What’s your role at Patient Zero?

The DMZ (Demilitarised Zone). Yes, this might be a well formulated nickname based on my first name, but also holds strong to my mediator personality type. I am passionate about understanding the unique qualities of people, how I can best help someone based on their needs and ensuring there is a shared empathy across people that work together. That’s what I live for.

Sometimes I also go by Principal Product Manager which at its core is about ensuring a balance between consumer, business and technology benefits from strategy right through to delivery. I also have a strong background in agile delivery, agile coaching and quality assurance.

How long have you been working for Patient Zero?

I have been at Patient Zero since March 2019, so just under a year.

What do you love about working at Patient Zero?

Patient Zero’s premise surrounds high-performance teams that produce high quality results. The backbone of this is a culture of agile, devops and product-centric delivery. I have worked with a variety of organisations that are at different stages of their maturity, however the secret sauce that is difficult to master but reaps the most rewards is not always fully understood.

Empiricism (aka the secret sauce) is not only an approach, but a philosophy that we learn best from our actual experiences. The key to this is transparency; continuously inspecting on how we are heading towards our goals and adapting to what we learn along the way. Like the values from scrum, having courage, being open, honest, committed and focused is at the core of Patient Zero. From honesty and truth, and of course the collaboration that is a necessity alongside, we can create transparency that feeds into the empirical attitude that generates the best outcomes.

I love working with a team that eats its own dog food, is willing to run the right experiments at the right time, favours continuous learning and the most essential to which aligned with my core values; honesty. This is why I am here.

How did you get into Product Management?

Like most people in this industry, my path to Product Management was not a straight line. Product Management whilst having been a role in the industry for a little while now, is only starting to popularise more with the global adoption of agile frameworks. Agile is the backbone for Product Management and the two work hand-in-hand with each other.

My journey into IT began around 12 years ago, starting out as a customer service representative for a software company. Speaking directly with the end users of a system gives you direct insight into the use of a system, its context of use, and of course as is the nature of customer service, the pain points.

Not long after joining the customer service team I got seconded into the test team and I fell in love with software delivery. Working within the testing realm you naturally fall at the end of the delivery cycle, and all the delays and impacts of decisions made before you compact into your little window at the end. This can cause pressure to ensure the highest quality within sometimes what seems like the shortest timeframes. This inspired me to look at ways to help build quality in from the beginning, from ideation all the way through to making the system live.

When I started to facilitate User Acceptance Testing workshops, my eyes were opened to a new way of thinking that extended beyond the lens within customer service. Users can surprise you not only in how they use the system, but also in the way that they think, how they feel and their underlying needs towards the products or services you are trying to deliver for them. This was eye-opening for me and I started to gain a lot more empathy for users, shifting my focus towards a more user-centric approach.

My passion has only grown over time as my roles shifted out of testing and into delivery, product and coaching positions. My approach has always been the same: to understand the business, goals, and the consumer needs and values, all whilst finding the right balance in technology. Connecting between all these elements takes attitude, aptitude, experience, skills and a “learnerprenuer” type of mindset. That’s right, I just made up a word and it’s brilliant.

What do you enjoy outside of work?

I’m a bit of a nerd, so outside of enjoying a delicious meal and travelling, I enjoy learning. If you ever see how many Chrome tabs I generally have open, you’d understand the number of things I am researching at once. Chaotic in some eyes, bliss in mine. I absolutely thrive when I’m learning new things and even more so when I can find connections in seemingly disparate things.

What’s an interesting fact about you?

4% of my genes descends from the Neanderthals, which equates to the top 2% of those tested through 23andme. Random, yes. Interesting… well I will leave that up to you.

Trek for Girls: Supporting Education in Nepal

Wed, 02 Oct 2019 23:16:04 GMT

Peter McCloy, Principal Program Manager at Patient Zero has headed off to Peru for his "Trek For Girls" fundraiser. He is taking part in Plan International Australia's Trek for Girls Programme to raise much needed funds to help get young girls educated and out of harm's way.

Peter says “Plan International works to empower girls around the world, it’s really important, and I want to do what I can to help. This will be a challenging trek, but no more challenging than what young girls face.”

The “Trek For Girls” 2019 will see Peter traverse along the legendary Inca Trail from the sacred Urubamba River to Machu Picchu. It will take 5 days and he will reach an altitude of 13,828 feet (4,213m). Already, he is facing the reality of high altitude “Settling in after suffering altitude sickness. Travel in Peru is a reminder of how privileged we are in Australia, how safe our children are growing up” Peter said.

Plan International Australia is a global independent development and humanitarian organisation, that recognise the power and potential of every single child. Yet poverty, violence, exclusion and discrimination strip them of their childhoods, and it is girls who are most affected. They work alongside children, young people, supporters and partners to tackle the root causes of the injustices facing girls and the most marginalised children.

Peter’s fundraising goal is $3,500 and will contribute to Plan International’s $50,000 target for the Trek For Girls program. He is proud to support one of the oldest, largest and most experienced organisations in their field. “This year they launched their Half A Billion Reasons Report which shows how investing in girls can change the world.” Peter said.

Half a billion adolescent girls in the developing world are our next generation of leaders, workers and mothers. What opportunities they have, what barriers they face and what they achieve today will set them on a life course that will not only determine their futures, but the future of their families, their communities and their nations.

Patient Zero’s CEO Paul Briggs, says that Peter embodies Patient Zeros’ mission. “Our mission is seeing further, taking you there. Peter is definitely seeing further than most. We wish him all the best on this adventure”.

Inside the Patient Zero Internship Experience

Tue, 13 Aug 2019 10:31:37 GMT

Patient Zero recently hosted three students from the University of Queensland for an internship program. Starting with our induction program, the students were taken through the paces of working in a cross functional agile development team. We taught core skills for team based software development work like using GIT, resolving merge conflicts, estimation and task decomposition. The students were given the opportunity to work on a variety of team projects to further their skillsets.

One of the students, Vibhuti Gajinkar enjoyed her time so much she’s decided to stay on as a Junior Developer. Here’s a little about what Vibhuti had to say about her time at Patient Zero.

1. What was the most challenging part of the PZ internship program?

Adjusting to the PZ work culture and technology was a little challenging. There are many things to learn at PZ like the tools, infrastructure, existing code and sprint activities. To be able to understand these in the short duration of the internship overwhelmed me a little at first. Everyone at PZ made me feel welcome and entrusted me to do the tasks given to me and supplied me with the necessary support.

2. What was your favourite part of the PZ internship program?

The people at PZ have been the favourite part of the internship program. They are very supportive and smart individuals. They don't put a lot of pressure on you and let you learn at your own pace. Daniel Dekel’s advice was "Your answer is just a google away" which is comical, yet so true. It's relevant in many scenarios. If you don't know something you can look it up and you'll find it eventually. If not, then you're always welcome to ask anyone at PZ.

3. What skills did you learn?

I was taught ReactJS on a fullstack development project and Data Analytics with PowerBI during the internship program. But more importantly, I got to learn to work in an agile way. I learned to decompose work into tasks. It's an important skill to have as it makes you more productive. I have been applying the same concepts in my university assignments as well. Solving the entire task might be an overwhelming challenge, but once you break it down and solve only a small part, it will take less time and build your confidence in the work.

4. In what ways did PZ invest in you?

The induction session gave us an overview of the company. The initial tasks given to us helped in understanding the work culture, company ethics, and code of conduct. Sam and Gabby gave us a session on scrum processes, which was very helpful in understanding the autonomous, cross-functional team environment. Everyone at the office is readily available to solve your problems, help you learn the concepts and allow you to implement what you've understood. Using Power BI for data analysis was an unexplored skillset for me. Dan helped me a lot with this learning curve.

5. What advice would you give to anyone considering joining PZ as a graduate?

Be open-minded and be pro-active. Try out different things if you get the opportunity and find out what you like the most. Don't be afraid of making mistakes as it's the best way to learn. Don't try to rush things. Learning something new takes time and effort. If you attempt to understand something in a hurry, you won't get the whole concept or miss out on some important knowledge. Be genuine and connect with people. They are great to talk with and have a lot of fun things to share.

Creating Healthy Tension in Software Teams

Mon, 27 May 2019 00:43:23 GMT

One of the most brilliant things about an Agile process is when it works, it really works. You get development teams that produce software that is exceptionally valuable to the business while creating an environment in which development team members are highly engaged. However, more often than not there is an unhealthy level of tension between software development teams and their stakeholders.

This article is for you if you’re asking yourself these things:

Why are they not working on the most important features?

Why does the team over promise and under deliver?

Why are we constantly working on technical things and not on new features?

A common story

I was discussing with a friend who has moved to a new company which is scaling up past the startup phase. As the company grew, the founder became distracted away from product management into business management. The development team is not being given clear direction or face time with the founder and are using this gap in direction to focus on technical “busy” work. The owner is getting frustrated that the development team isn’t building the new features their customers are asking for. The development team is slowly becoming disengaged and not enjoying their work.

This is a common problem repeated in many organisations with slightly different factors depending on whether the company is a startup, scaleup or enterprise.

Enterprises may find that development teams spend a lot of time talking about creating or fixing the framework or resolving for technical debt. You may notice development teams convincing organisations to invest in rewriting parts of their application by swapping out technology which serves very similar purposes (e.g. moving from Angular to React). These rewrites are often sold on the improvement of developer productivity and customer experience.

Changing technology is either a by-product of poor implementation or selection or a strong lack of business requirements. It generally never results in sufficient gains in productivity or customer experience to warrant the investment. If the team caused the poor selection or poor implementation, what’s to stop them making the same mistakes again?

Creating healthy tension

To keep a development team on track, you must actively encourage a healthy level of tension between the stakeholders and the development team.

On one side, you should have the stakeholders wanting the development team to produce as much as possible. There should be a hunger for new features and the stakeholders should be eager to review the results. There should be celebration when results are achieved. There should be active engagement with the team to support them.

On the other side you should have the development team understanding their progress is closely monitored. Their performance is critical to the organisation's continued success. The results will be reviewed and celebrated. Failure to perform will be questioned, and if there are excellent reasons for under-performance they will be accepted. Continued under performance without due cause will have undesirable consequences.

However, too often development teams are left to their own devices, trusted to just “get on with it” while stakeholders are busy with other tasks resulting in frustration.

Some tips to create healthy tension

Here’s some common approaches that should increase satisfaction and alignment between the stakeholders and the development team based on some of the most common needs.

1. Stakeholders want to keep the development team working on the highest value work.

A backlog of work needs to be created, ideas go into the backlog and are refined into fully formed business focussed requirements. A prioritisation session needs to occur regularly between the development team and the stakeholders to blend technical needs with business value.

2. Stakeholders want the development team to deliver value and the development team needs time to focus and deliver.

Hold a sprint planning meeting where the development team identifies how much work it can do during the sprint. It’s critical this is the development team taking items off the backlog and committing to the plan. The stakeholders should sign off the plan, ensuring it’s work that is the agreed highest priority.

The sprint plan is like a mini contract or promise, the development team says they can deliver if they are left alone to deliver. If the stakeholders avoid changing the plan, they are rewarded with a delivery on time.

3. Stakeholders need to create sufficient engagement within the development team to keep them happy and productive.

Typically the stakeholders are involved in defining work clearly with business focused user stories and acceptance criteria. Sometimes themselves or sometimes through a product owner or business analyst. It’s critical that these user stories clarify the problem and the business requirements (e.g. we want to register new users with their name, company, email address and phone number so we can follow these users up) and without dictating specifics of implementation of the solution (e.g. we need to create a new record in the users table).

Dictating the solution in technical detail is a surefire way to disengage a developer. Failing to provide a developer with clarity around the problem and the business requirements often results in developers filling in the gaps or waiting for further information. The result being solutions which need rework, inefficient development processes and unhappy developers.

The stakeholders and the developers need to come up with a compromise around the timeframe for delivery of new features and resolving for technical debt. Failing to resolve for technical debt could make it frustrating for the development team to continue to deliver. The development team needs to ensure that they aren’t worked to death by having stakeholders over commit them to a schedule they have no influence over.

4. Stakeholders often want to know how long it will take to deliver, to set expectations with clients or other stakeholders who need to plan around the arrival.

Engaging the team in estimating the work is imperative to achieve their buy in. If the team does estimate their work, they are more likely to hold themselves accountable for delivering within their estimates. The stakeholders need to know they can’t change the plan (being the stories or the acceptance criteria) while it’s in progress or without changing the estimates. With sufficient clarity as to the problem and business requirements developers can provide accurate estimates.

As a result development teams can usually achieve a consistent velocity (amount of work delivered per sprint). With a consistent velocity you can predict when work will be delivered. You should be able to predict when work will be delivered, +/-50% on anything further than 6 months out, and +/-20% on anything in a 4-8 week time horizons.

5. Stakeholders want to be sure that things are on track, so we need a way to measure and predict our deliveries.

There should be tooling which shows work remaining VS work completed with a view to both short range (within the sprint) and long range (3-6 months). The development team needs to know their progress to completing the shippable increment will be tracked and monitored and if things aren’t on track then everyone need’s to see it and they need to articulate why it’s not on track.

Sometimes it’s obvious, for example 'new requirements were identified, we’ve had to change work we thought was done because we learnt something new'. Adding more scope items pushes dates out, simplifying or removing scope or impediments brings dates in.

6. The development team needs to regularly present progress to stakeholders in order to stay on track.

There should be a regular set of presentations (a showcase every 2 weeks) where the development team is forced to present their progress with a live demo. This ensures there are opportunities for stakeholders to regularly inspect progress and course correct. The live demo causes the development team to find a way to focus their energy on proving progress to themselves but also to their stakeholders.

If the development team haven’t delivered on their sprint plan, there should be explanations as to why. Where reasonable explanations and consistent performance is observed there should be celebration. Where consistent under-performance is observed there should be corrective actions taken.

7. The stakeholders and the development team should review how they are progressing and identify any areas for improvement.

The stakeholders may receive some ideas from the development team, usually at a retrospective meeting, as to how to help the team go faster. Common examples might be avoiding interruptions when team members have headphones in, providing clearer requirements (e.g. specifying wording for error messages and email content prior to the sprint starting), answering questions faster during sprint or helping the team get any tooling or hardware they might need.

In summary

Establishing a healthy tension between development teams and their stakeholders results in more engaged development teams, better products and more value created. When you setup some rigorous processes in a light weight fashion the stakeholders can have minimal touch points with development teams while ensuring they are getting value and their expectations are managed.

If you think your practices could use a little improvement, we offer independent reviews on your processes along with actionable recommendations. Please do get in touch.

The Power of Collective Knowledge in Engineering

Fri, 12 Apr 2019 05:34:11 GMT

When I'm asked by my niece and nephew what I do, I liken writing code to solving mathematical equations; although I might know what the expected outcome should be, I'm still burdened with finding the appropriate way to solve it.

When given to a group, the same problem will likely be solved in completely different ways. That is completely normal. We think differently, and therefore solve problems differently. Make no mistake. There will ALWAYS be a better, more elegant solution.

This is true for development teams too. Developers, therefore, will occasionally find their solutions challenged by fellow team members.

I have witnessed two prevailing reactions to these challenges:

1. Developers who aggressively defend their position, rejecting any feedback

2. Developers who will avoid confrontation at any cost, accepting any other opinion

According to Patrick Lencioni, these are two sides of the same coin, and both stem from insecurity. The one might have an overt sense of self-importance, the other has a tendency to play down their contributions.

The healthiest teams I've worked on had members who did neither of the above. Instead, they were able to articulate the reasoning behind their decisions (including providing the sources that influenced them). It was then left up to the remainder of the team to provide feedback. The benefit of being accepted by the team increases the sense of accountability towards the outcome.

Reason leads to tolerance, empathy and (inadvertently) introduces new knowledge to the rest of the team. It is this collective knowledge that is most valued at Patient Zero - not the particular contributions of an individual.

Customer Service: Delighted or Deflated?

Thu, 04 Apr 2019 06:04:08 GMT

Those more learned than I espouse the merits of genuine customer service and I whole heartedly agree. A great CX strategy, process & communication digitalisation and an agile customer journey seem to be winning hearts & minds and bottom-line improvements.

I firmly believe that a well-considered and holistic CX strategy pays significant dividends to both the customer and the vendor; delivering low effort problem solving for the customer and an enhanced bottom line for the vendor.

Truly understanding the digital experience that customers crave is a key component to delivering a great buying experience which in turn leads to a stronger bottom line.

Quality Digital Customer Service delivers bottom line gains in 2 main areas:

Low-effort and intuitive customer interactions enhance the buying experience, promoting higher transactional values and increasing repeat business

Digital customer service through automation and e-channels can realise significant cost savings

A deeper dive into these two areas:

1) Low-effort and intuitive customer interactions enhance the buying experience, promoting higher transactional values and increasing repeat business

The simplest way to increase customer loyalty is not through delighting them it is ensuring that engaging with you requires minimal effort.

State of Digital Business Report states that a good digital experience makes the customer six times more likely to try a new product or service from their preferred brand, four times more likely to refer the brand to their friends, family and connections and two times more likely to make a purchase with their preferred brand (even if a competitor has a better product or price).

2) Digital customer service through automation and e-channels can realise significant cost savings

A McKinsey survey found that digitising customer service helps reduce costs by 25 – 35%

•Automation projects delivering process optimisation through Digital channels often progress to MVP and no further. MVP does not deliver the optimum Customer Experience in fact organisations miss the Viable piece and therefore do not necessarily deliver any improvements. Many organisations reduce the MVP to MP and then congratulate themselves on a successful project and move on!

•Speed and efficiency above all else often mean 2 completely different things depending on your perspective:

Delight – positive and empathetic focus on the customer outcome

Deflate - focused on cost reduction - spending as little time as possible on a reaching a good customer outcome

Why deflate rather than delight?

Although the benefits are apparent to most of us there are, in my opinion, only a few companies genuinely striving to deliver exceptional customer service; the majority either lack any basic understanding of how to achieve this, are complacent in the treatment of their customers or seek to provide a service veneer. This veneer suggests a comprehensive digital and omni-channel service, but experience shows that web contact pages are clearly not monitored and call back requests disappear into the ether etc.

Whether through traditional telephonic or digital communication many organisations have clearly decided that genuine service is not necessary when lip service will suffice. The availability of low-cost labour and the huge volume of sales through attractively discounted products compensates financially for any customer attrition through poor customer service. The skill seems to be to convince customers of a best of breed service through a traditional smoke and mirrors approach.

You would think that Enterprise providers would have a sharp focus on delighting their clients, however during a customer led workshop last week, to seek a solution for a critical business problem, the incumbent solution provider failed to turn up without even a call of apology. Is this the arrogance of incumbency or lack of interest?

Achieving a delightful experience is not simple. The customer experience policy and processes need to be understood and committed to across the organisation. A Gartner survey finds that employee engagement is a top concern affecting customer experience. Gartner observes that “In some instances, the best technology investments have been derailed by employee factors, such as a lack of training or incentives, low morale or commitment, and poor communication of goals."

A low Net Promoter Score (NPS) in some cases appears to have a direct correlation to low Customer Satisfaction rating. Surely this is just common sense. If the team providing the Customer Service is disenchanted, then would you not expect to see this attitude reflected in their work. CX is a people issue so why do we invest in the technology and process and disregard the people? AI should be there to augment people service not to deliver an artificial veneer of service.

Delight or Deflate – judge for yourself.

Microservices: Cultural Warning Signs You Aren't Ready

Tue, 12 Mar 2019 05:46:02 GMT

The original plan for this post was an overview into the technologies and patterns used in microservices, in particular I wanted to look at the bits we often see missing or poorly implemented. A colleague of mine, Dan Dekel, recently gave a talk at a local meetup on a similar topic, and it generated more debate than he had expected. He covered the importance of CICD, running multiple instances of each microservice, consistency across the environments, patterns such as circuit breaker, general transient fault handling, correlation and analytics on logging, API versioning and consumer driven contract testing. It seems that opinions (and emotions) on microservices still run deep, and what ensued was a debate on synchronous vs asynchronous architectures.

When I speak with developers that have had a poor technical experience with microservices, there seems to be a common denominator. The team was often well aware of the problems, and they had ideas on how to fix it, but they were essentially stuck with a blueprint handed down from above.

So in this post I’m instead going to look at some of the cultural warning signs you might want to consider before making a decision to go with microservices.

Moving to microservices will fix our scalability issues

There is no question that well designed microservices can scale in ways that are difficult for a monolith. But seldom do I see a monolith that has gotten anywhere near the limits to which it could scale. Monoliths can and do operate at global scale loads. If your monolith is having trouble supporting a few hundred users, then it’s probably not because it’s a monolith, or because it was written to use some (now) less fashionable framework. Scale issues will exist regardless of the architecture and if you can’t fix these problems in your existing application, microservices aren’t necessarily going to improve the situation.

Microservices will improve the throughput of our development teams

This is an interesting one, because the ability to decouple teams and have them work on separate groups of microservices is a significant productivity gain.

One observation is that a monolith can create contention at the source code level. As the number of developers increases, you can easily trip over each other as changes are merged. At a certain size and level of complexity a few key individuals become the only people that have the knowledge necessary to make significant changes to the monolith, and it becomes difficult to scale around these people. In contrast, microservices will generally be divided into much smaller self-contained repositories and this makes it easier and safer to make changes. However, this isn’t an intrinsic benefit of microservices, it is really just an argument for good code structure and separation of concerns - you could achieve something similar in a monolith by organising the code differently.

The most significant productivity improvements are realised inside an organisational culture that understands and grants autonomy to the teams. And that remains true independent of whether you are building monoliths or microservices. Further, if you don’t already have that sort of culture, then a pivot to microservices is likely to create a really big mess.

Here are a few warning signs that your culture might not be ready to support microservices:

You prefer to make technology decisions at the middle or senior management level
You believe your teams lack the maturity to make good design and technology choices
Your teams are focused on technology and not on business value
You don’t have (or want) clear specialisation and domain boundaries between teams
You are trying to implement a scaled Agile process and hope microservices will help
You have backlogs shared between teams
You have decision making layers between the Product Owner / Development team and the end user
You think your current problems are the result of an incorrect technology choice
You have a CAB

In one way or another, all of these items shift control away from the development team. Why is this particularly problematic with microservices? The productivity gains of microservices come from the fact that they are decoupled from each other (and by extension, other teams). This empowers teams to operate with a minimum of external dependencies and each to operate at close to their sustainable capacity.

Anything that gets in way of this autonomy has the potential to render the productivity gains of microservices irrelevant, and you’ll likely be running significantly slower than you were with a monolith or an older tech stack. If you are considering microservices, or have already started using them, I’d highly recommend reading Accelerate. It provides a comprehensive overview of research into the capabilities of high performing teams and how they can be measured. Don’t head down the microservices path without a culture that can support autonomous teams.

How Microservices Impact Organisational Culture | Patient Zero

Thu, 18 Oct 2018 01:12:02 GMT

In our first post we considered the CICD maturity needed to manage microservices at scale. But DevOps extends beyond tooling and speaks equally to both development and organisational culture. One of great benefits of a microservice architecture is its ability to scale work across multiple teams. It facilitates ‘decoupling’ by allowing teams to operate autonomously within the domain context and microservices they own. Microservices happen to fit very nicely into a team-based autonomous delivery model, and it’s a widely held industry belief that this is one of the most compelling reasons to build using microservices.

But even the most capable teams, with excellent DevOps skills and practices, will struggle with microservices in an organisation that does not have a high degree of Agile maturity. We've seen organisations regressing back to Waterfall practices as a result of the technical and business demands of a troublesome microservices platform.

So what are some of the ways organisations can eliminate potential challenges and deliver a successful microservices project?

First and foremost, you need a management culture that understands Agile development processes, and is able to embrace and adapt to change. A good example is the way microservices need to be tested and released. Traditional monolithic approaches, such as releasing everything into an ‘integration’ environment and having tests confirm that all the bits play nicely, just doesn't scale when you have dozens of interdependent APIs released multiple times a day. Traditional release management processes quickly become a quagmire if there are large numbers of microservices needing to be tested, versioned and moved monolithically through different environments.

If your organisation has a middle management layer that is more ‘command and control’ than ‘servant leadership’, then a microservice architecture will present them with significant challenges. That may be a good thing if you are in upper management and looking to drive Agile change within an organisation. But it can be disastrous to a business that needs to release software quickly in order to achieve their quality and customer goals.

There are some warning signs that your organisation might not be up to microservices, and it can be difficult to fix them once development gets underway. Addressing them early will significantly increase the chances of a successful outcome.

Potential pitfalls to be aware of:

The project, DevOps, testing and architecture managers are focused on controlling rather than mentoring, facilitating and unblocking.
There is an expectation that teams should not own microservices; that all teams should be able to work from a shared backlog and codebase.
There is a reluctance to release software frequently and automatically.
There is a poor understand of Agile processes and principles (e.g. all teams are expected to have a shared measure of velocity).
There is a preference against cross functional teams (e.g. they may feel it's better to have frontend teams, backend teams and test teams).
There is a tendency toward a ‘hero developer’ culture; where certain key individuals are elevated above the teams that support them.

Microservices are a great fit for an organisational culture that thrives on rapid change, has a customer focus, and understands how to inspire and empower teams. It allows software development to operate at a scale and efficiency that is simply not possible with most other architectures. So good luck to all organisations embarking on a microservices journey, and as always, call the Team at Patient Zero – Empowered Teams, Exceptional Results!

In our final post we’ll look at technical Do’s and Don’ts with Microservices.

The Reality of Microservices: Trends vs Hype

Wed, 26 Sep 2018 01:22:38 GMT

Rewind 5 years and micro-services were the talk of the town. The developer conference circuit was awash with speakers espousing the benefits of micro-service architectures. Stories about their success in Netflix and Starbucks built the business case, while advances in scriptable infrastructure such as Docker built the technology case.

Then the cracks started to appear. Some of the teams adopting this approach reported mixed results – horror stories about complexity, difficulty in evolving the domain, refactoring and rapidly accumulating technical debt led to a general view that micro-service architectures weren’t quite as broadly applicable as we had hoped.

Conference talks shifted to Serverless, in part a reaction to the orchestration complexities of micro-services. The newly accepted wisdom was that micro-services probably shouldn’t be considered for greenfield applications, culminating in the recent removal of micro-services from the ThoughtWorks “Should Adopt” technology list.

So what’s going on with micro-services? What are the advantages and disadvantages? Should you be considering their use? At Patient Zero we now have several micro-service projects that we’ve worked on, across Node, .Net core and Ruby. Some of these we inherited the architecture, some we built ourselves. Our journey went from loving the idea of micro-services, to hating their implementation and delivery, back to understanding and appreciating how they can be used effectively. This is the first of 3 posts distilling our current thinking on micro-services.

There is one question you must answer to decide whether or not you should even consider a micro-service architecture, that is “How well do we do CICD?” Most teams are now well and truly on the dev-ops bandwagon, “we’ve had a build pipeline for years, we have automated tests, we have automated deployments – we’ve got CICD nailed!”

Try this with an existing application from the team (it doesn’t have to use micro-services):

Create a new tenancy/subscription/area with your cloud or hosting provider
Modify your CICD pipeline to use the new tenancy
Give a developer a blank workstation / laptop and have them clone the repo, build and successfully launch the application locally
Have them check in a change to a feature branch
Ensure the change is automatically built, tested and deployed to the new tenancy. All Infrastructure required is automatically provisioned.
UI Tests automatically execute and report results in the new environment
All infrastructure is automatically disposed at the end of the test

If you can get from 2-7 in under 30 minutes, then it’s definitely worth considering a micro-service architecture. If not, then you are probably going to find micro-services are a significant burden on development team productivity.

To be continued. Stay tuned for our second post on Micro-Services – Advantages of Micro-Service Architectures.

BAU is Dead: Rethinking Software Maintenance | Patient Zero

Thu, 23 Aug 2018 01:14:25 GMT

As software development gradually shifts from a project centric to product centric approach, it raises questions around the concept of BAU (Business as Usual) and whether or not that has relevance in a productised world.

In a traditional project approach, once the business has jumped through the all the hoops to get approval, funding and resources, a development team is assembled. Typically it uses a combination of internal and external resources, builds something, and then hands it over to BAU – at which point development slows or stops and the clock starts ticking to the “rebuild”.

In a more product centric approach, there is an acknowledgement that much of the real business value is delivered post MVP (so at the end of the typical “project” stage), and there is an expectation that the product will continue to evolve rapidly, post MVP to achieve and maintain a good market fit.

This tends to clash with typical enterprise procurement and capex / opex cycles, and the result is often an A team MVP and B Team BAU arrangement . The big consultancies have been doing this A team B team switch for decades; put the guns in to build it, then put the B team in for maintenance.

The problem is that product evolution either stops or slows significantly at the handover to BAU, and never recovers. In an Agile world, where the initial build is an MVP, this is a disaster because the A team is disbanding at precisely the time when they are of most value – at the point where you start to get clear, actionable customer feedback.

Handovers don’t really work, because what you are really losing is the business and technical domain knowledge that is now embedded in the “team” that built the MVP. Understanding that the most valuable output of an MVP is not the software, but the domain knowledge acquired by the team that built it.

What’s the solution? I’m not really sure to be honest. I think benefits of building and releasing an MVP is a key Agile insight, and a useful foil to the A Team B Team dance of the larger consultancies. But we need an engagement model with a much longer tail, around 1-2 years. Team members may (and should) come and go during that period, but it’s a managed process that ensures that the team’s collective domain knowledge is maintained. The MVP team becomes the BAU team, because software no longer has the luxury of “Business as Usual”.

The Dos and Don'ts of a Successful Go-Live

Tue, 17 Jul 2018 01:19:52 GMT

One of the remarkable things about Agile software development is the consistent output you get from a capable, autonomous team. The team estimates, it commits to the work it will deliver in a sprint, and it is accountable for that work. Implicit in that accountability is a contract with management that grants the team the autonomy and space to meet those commitments. For that period of two or three weeks, management lets the team get on with the job and avoids changing the goal posts.

Of course, real life is never quite so black and white. A critical bug might need attention from the team, or some urgent business priority emerges. But with a quality team and disciplined management this will not happen frequently, and when it does happen, the team can usually accommodate those changes and still meet their commitments.

The ultimate test of Agile methodologies and management discipline comes as you near the end of a project and move into go live. This is the time when the consistency and predictability of a stable, mature development process really shines through. It’s also the time when an immature management approach is most likely to lose focus and fall into regressive behaviours.

A few management Do’s and Don’ts as you approach go live

Do:

Continue to rely upon and invest in automated testing
Do basic triage and prioritisation before interrupting the development team
Stick with your established dev-ops / release processes and schedules

Don’t:

Praise, reward or expect developer heroics and late nights
Micro manage the dev team or directly allocate work to developers
Push through “emergency releases” without proper testing

The processes that lets a team deliver software, sprint after sprint, with consistency and quality, is exactly the same process that will get you through go live. Don’t panic!

Don't Build a Framework: The Build vs Buy Strategy

Thu, 14 Jun 2018 01:27:43 GMT

We all try it; I’ve never once seen it succeed. I’m not talking about choosing a tech stack, or settling upon a standard architecture. I’m talking about a bespoke collection of internal libraries and branches of popular libraries, patterns and architectures that eschew the “standard” conventions in order to increase the productivity and quality of the development team. So in a world awash with development frameworks, why is it a bad idea to build another one?

The most productive off-the-shelf frameworks are highly opinionated, there is generally just one “right way” to do something, and that information is public knowledge. Internal frameworks are often highly opinionated also, but knowledge about “how” is often hidden or difficult to find. Developers can’t easily find solutions to their problems, and as a result productivity is much lower.

There is an interesting parallel in game AI research. There are essentially two types of games – games with full public state, such as noughts and crosses or chess (where both players have full knowledge of the board). And games with hidden state (such as card games, where you only know your hand). Traditionally AI research has focussed on the former as it’s much easier to solve – you can find and weight all the solutions and pick the best one. These AI’s will consistently beat even the best human players. But until recently, that’s not been case with hidden state games, good human players will usually beat the AI.

Here are some of the warning signs that you might be about to vanish down the framework rabbit hole:

There is a feeling that your business is unique from technical or compliance perspective
You have a new application, but it won’t work unless you build a framework
You start hearing terms like “metadata driven” and “self-configuring”, but you still seem to spend lots of time configuring things
You can’t solve business problems until the framework has been built and stabilised
You can’t use the PaaS or the cloud because your customers won’t let you
You are thinking about taking an existing, opinionated framework and improving it

If you have built a framework, this is the likely outcome:

The framework is never complete
The framework consumes significant development resource just to keep it working
The framework never delivers the productivity or quality you believed it would
Business applications are limited by the capabilities of the framework
Developers are often blocked in their ability to solve their problems; they depend upon a few key people within the organisation that understand the internals of the framework

Here is what a healthy development project looks like from a framework perspective

A new developer can pull down a repository, build and launch it without any input other than installing the development tools (in the .NET world we call this F5 Go)
Developers can Google their problems and speak with the authors of popular, open source libraries
The infrastructure and platforms used to run an application are entirely disposable. PaaS and Docker make it dead simple to throw away and recreate the entire environment on every build

Frameworks are great, they save thousands of hours in developments time and solve problems that no single team could realistically solve. Internal frameworks will often emerge organically out of an eco-system of applications – and that’s fine. You have working applications; you can see clearly where there would be benefits in standardising and sharing functionality, and you can measure the cost of that. But unless you are Google or Microsoft, don’t start a project by building your own framework.

The Ubiquitous Language of Agile & Domain Driven Design

Thu, 14 Dec 2017 05:07:18 GMT

It’s interesting to see how mainstream Agile has become in the enterprise vocabulary. At some point when speaking with large enterprise customers, the conversation will invariably turn toward Agile practice. They have Agile Coaches and Certified Scrum Masters galore guiding their Agile journey, and most rate themselves as doing a pretty decent job of following Agile principles. In contrast a lot of small and medium enterprises (SMEs) will tell us that they are struggling to gain traction with Agile – they are trying, but they feel like they have a long way to go and a lot to learn.

Curiously, when you ask an enterprise customer how long it takes from a developer check in until that change reaches the target user, the answers are a little vague. “It depends upon the system, and who you define as the target user…”. Pushing harder, we often find they define their target user as an internal test team or product stakeholder, and a release as a release to an internal environment. Actually progressing working software to reach the final consumer of that software can take many months. SMEs will mostly give a straight answer. “We release to test every two weeks, and after a week of testing we release to production”.

I’d argue that the SMEs are actually a lot better at Agile than they credit themselves, and that some enterprises have missed the point. We all agree that simply using Agile sounding ceremonies and artifacts doesn’t make you Agile. I often hear the joke “yeah, we must be doing Agile because we have a daily stand-up”. However, most enterprises doing iterative development tend to think they are taking Agile seriously if they have sprints or iterations. Iterative development is not simply the process of chunking work up into short, well-defined periods – that’s like defining a boomerang as a stick that you throw. Iterative development must close the loop between the development team and the end user – it’s really about how long it takes you to build something, deliver it to the user, and then collect and incorporate their feedback into the next build / release cycle. If it takes you 3 months to get code from developer to the end user, then your best case cycle time is 6 months. You literally have a 6 month iteration regardless of your development chunks, and that’s definitely not Agile.

Certainly you can argue the benefits of a well structured backlog, estimating, chunking up development work and having showcases. Agile coaches make a living out of teaching enterprises how to do this. But unless you can fix the release process and rapidly release software out to the end user, then you aren’t doing Agile. Nor are you getting the benefits of doing Agile. Showcases will often be smoke and mirrors, and development teams aren’t getting the buzz and excitement of creating software and learning through interaction with real users. Business units are not seeing user feedback incorporated quickly, allowing them to drive innovation and market fit.

So why is there such a discrepancy between how enterprises and SMEs rate their Agile maturity? When you ask an SME where they need help, they are often quite specific: they need help with structuring their user stories, they are struggling with CICD or architecture, they need automated testing or better release quality. Their focus is fundamentally on the speed at which they are solving problems for their customer and they expect Agile to help them improve. Enterprise customers are often focused internally, on project life cycle issues and stakeholder management. They use the language and processes of Agile, but actually taking it all the way through to production is too hard. They aren't doing Agile at all.

The Myth of Quality vs Quantity in Software

Wed, 18 Oct 2017 05:09:09 GMT

One of my favourite Agile parables tells the story of an art teacher who gave her students an assignment to produce a ceramic vase. The class was divided into two groups, the first group need only produce a single vase, but they were to be assessed on the quality of that one piece of artwork. The second group had to produce as many vases as possible; they would be assessed on the quantity of work they submitted. At the end assignment, when the teacher ranked all of the vases, it was the second group (the quantity group) that had also produced the highest quality vases.

Depending upon the organisation, and how far along they are in their “Agile Journey”, it can be difficult to win support for this sort of approach – yet it is one of the key insights provided by Agile.

All teams need to figure out their definition of “done”, and it’s going to vary, not just from product to product, but also with where you are in the lifecycle of a product. If your software has a strong consumer emphasis, you might decide early in the project to focus on pixels and UX. If the core requirements are around analytics or data, you might decide to focus on getting the numbers right. In all cases you will fail to deliver if your definition of done for a single iteration is perfection across all areas.

Of course, once you choose a definition of done that is less than perfection, you will deal with criticism from people that don’t really get Agile. “This approach is good for rapid prototyping, but it won’t produce quality”. The most important thing is to take that feedback, the bugs, the kludgy UX or whatever the criticism is, make sure it’s backlogged and prioritised, and wherever possible ensure you have an automated test that can reproduce the fault. Don’t slow down, don’t worry that maybe this Agile stuff is wrong. The quantity trajectory will inevitably give you the best quality as well.

Patient Zero Blog

Why We Play Games at Work (And Why Your Team Should Too)

(TL;DR)

A Simple Game that Exposes Real Team Dynamics

Takeaway 1. Everyone Brings Hidden Knowledge

Takeaway 2. Teamwork Only Works When Everyone Participates

Takeaway 3. Lost in Translation: Corporate Edition

Takeaway 4. Comparison Kills

Takeaway 5. New Deck = New Work

Why This Game Sticks

Run The Workshop Yourself

How to Play

Round Rules

Skip the Setup. Start at Round 3.

About The Author

A Love Letter to OpenClaw

What is OpenClaw? (The TL;DR)

Automating the Mundane (Airport Parking)

Verifying the Incompetent: Autonomous Booking Orchestration

The Security Elephant in the Room

The Next Evolution: From .exe to OpenAI

Deepen Your Sovereign Capability

About the Author: Dan Dekel

Patient Zero x Southstart 2026: Architecting Agentic AI in Adelaide

Southstart Adelaide: A Human-First Approach to Resonance

The Build Lab: From Chatbot to Coordinated Company

The Zero-Employee Startup: An Agentic AI Build Lab for the Slightly Unhinged

The Adelaide Challenge: Gen Z Dealcoholised Wine

Join the Resonance at Southstart 2026

Explore Our Technical Prowess

From Technology to Innovation: Patient Zero's 2026 WIICTA Finalists

The 2026 WIICTA Event at a Glance

About the WIICTA Awards

Demelza Green: Distributed Voice and the Future of Industry Leadership

WIICTA 2026 Finalist: Innovation

Irina Kudryavtseva: Resilience, Agility, and the Engineer’s Mindset

WIICTA 2026 Finalist: Technical

Explore Our Technical Stewardship

About the Finalists

Advancing the Tech Landscape: Our 2026 Women Leading Tech Finalists

The 2026 Event at a Glance ﻿

About the Women Leading Tech Awards

Demelza Green: Executive Leader and Technical Stewardship

Finalist: Executive Leader

Demelza's Leadership in Action

Hanieh Madad: Engineering Rigour and Complex Systems

Finalist: Engineer

Hanieh’s Engineering at Scale

Why This Matters for Our Partners

Explore Our Technical Stewardship

About the Finalists

The AI ROI Productivity Paradox: Why Your 30% Velocity Boost Never Happened

The Reality Check: The Data on AI ROI in 2026

The "16 Minute" Math Problem

Root Cause 1: The "Negative Expertise" Trap

The AI Drag

The Comprehension Gap

Root Cause 2: The Hidden Cost of Low Quality

Root Cause 3: Organisational Immaturity

The "Burnout Baseline"

Root Cause 4: Fear of Adoption

The "Writing on the Wall"

The Evolution: Moving from Copilot to Agentic AI

The Critical Difference in Workflow

Conclusion: Do You Have the Capability?

Turn Strategy into Sovereignty

About the Author

Should you Catfish your vendors? No, not like that.

What is the "Catfish Effect"? (And Why Your Tank is Full of Dead Sardines)

Stealing Management Tips from Emergent Global Superpowers

Case Study: Tesla’s "Gigafactory" Privilege

The "Procurement Paradox": How Preferred Supplier Panels Kill Innovation

How to Execute the Strategy: Introduce a Challenger Vendor

The Patient Zero Approach: Engineering Without Lock-In

Stop Feeding the Dead Sardines

Ready to Introduce a Predator?

About The Author

Experience vs. The Exam: How I Passed PSPO With (almost) Zero Study

Do tech certifications test real-world experience?

The Motivation (And The Free T-Shirt)

The 2026 Event at a Glance

The Evolution: Moving from Copilot to
Agentic AI

About the Author: Dan Dekel