9 posts tagged “culture”.
Throughout my career the one thing I've watched kill good products is a single word: resource.
Once a company calls its people resources, it starts treating them like resources. It adds them, rotates them, splits them across locations. The product is the first thing to suffer.
Yes, you want a team. The dynamic of that team decides far more than the org chart admits.
Read More →Our software craftsmanship group encourages new speakers to come and practise their talks.
One is coming up in August. At the start of every meetup we read aloud the code of conduct.
It can feel formal, but the repetition is the point. It sets the culture and reminds us who we want to be.
A question can be good and still land badly. The timing and the room decide.
Read More →A confident voice can ask a sharp question at the wrong moment and close a room down. In a meetup, the cost is one nervous speaker and a room that goes quiet. In a company, the same habit compounds, meeting after meeting, until the same few people decide what the team is allowed to say out loud.
You see the pattern at conferences first. The people who are confident keep speaking. The people finding their voice hold back. Over time the room narrows. The same voices return, the same ideas circulate, and the different takes never get a hearing.
Read More →I’ve seen non-developers build apps that would have taken engineers days, if not weeks.
Not just functional apps, but polished apps with rich functionality that bring joy to users. They meet real needs, and the attention to detail is unmatched.
Product people and domain experts can build good apps, and they build them fast.
So the question is: when does a vibe-coded app become a real product?
That is the question a lot of companies are about to face.
In many businesses, engineers are no longer the only people building the next prototype. Client managers, sales teams, product people and domain experts build it too, using tools like Lovable, Base44, Claude and other AI app builders.
And that is a good thing.
Read More →Last month, our company hackathon became a vivid illustration of a broader shift in how software gets built. Across teams, from sales to support, product to engineering, domain experts huddled around laptops, experimenting with AI powered platforms such as V0, Lovable and Bolt. Within hours, they'd fashioned interactive prototypes complete with navigation flows and validation rules, all without writing a single line of traditional code.
Although these early demos relied on mock data, the fact that non-engineers could conjure usable software unaided was striking.
As a full-stack engineer accustomed to crafting CRUD apps from the ground up, I found myself asking a new question: How might we empower these citizen developers to build more often, more securely, and with live data? Their deep problem domain knowledge meant they moved swiftly, iterated boldly and learned faster than any handoff-laden process could permit.
An isometric illustration of a futuristic highway under construction, where software engineers in hard hats are laying down glowing code-shaped road segments.
Over my two decades in software, I've discovered my highest leverage isn't in writing every screen or endpoint myself, but in architecting robust APIs, infrastructure and tooling so that others can deliver user value. In this two-part series, I'll share how engineers can transition from gatekeeping code to enabling creation at scale. In this first instalment, we'll explore the mindset shifts and guiding principles. Part 2 will dive into concrete patterns and architectural strategies for secure, sustainable enablement.
Read More →In my career, I have realised that the best companies celebrate each success in a genuine, informal way. They avoid contrived rituals that can feel like an artificial façade.
In these organisations, individuals willingly help colleagues reach shared goals.
Take Janet from my local Parkrun, for example.
Although she does not compete, she choose to find the time to cheer on each participant to achieve their goals... even on cold Saturday mornings.
Read More →Companies must be agile and respond quickly to changing customer needs in today's fast-paced and constantly evolving technology landscape. That's why DevOps practices that emphasise collaboration and communication between development and operations teams to deliver software rapidly, reliably, and at scale have become increasingly popular.
Shifting left, a core principle of DevOps can significantly benefit companies of all sizes. By empowering engineers to take on more operations responsibilities and promoting a culture of experimentation and innovation, companies can improve collaboration, increase reliability, and deliver high-quality software at scale.
In this post, I'll discuss how and why Cambridge University Press adopted a shift left culture.
Some organisations have great onboarding processes, others not so much.
Having experienced onboarding with many clients over the years, I want to share what a good onboarding process is for an engineer.
A good facilitator seamlessly keeps the flow of conversations fluent and relevant, encouraging people to engage and have equal participation while remaining impartial and patient.
It's a role similar to a conductor orchestrating a choir.
