Ever found yourself in a meeting where your brilliant idea fell flat, not because it wasn't good, but because of how you presented it? I have, more times than I care to admit. Ever wondered why some people’s ideas tend to be accepted more than yours? If might simply come down to how you start your pitch.

There's a concept in outdoor adventure circles called "Type 2 Fun." Unlike Type 1 Fun (immediately enjoyable activities), Type 2 Fun is often not fun at all while you're doing it but becomes enjoyable in retrospect.

I discovered this firsthand during my first half-marathon. Mile 10 was pure agony—legs burning, lungs screaming, mind begging me to stop. Nothing about that moment felt "fun." Yet crossing the finish line delivered a satisfaction that immediate pleasures rarely provide. Looking back, that gruelling experience transformed into one of my proudest memories.

This paradox perfectly describes the reality of engineering leadership in startups.

As an engineering leader, mentioning that you track lines of code (LOC) is often met with immediate pushback. "We deliver so much more value that producing code!” "Lines of code don't measure quality!" "You'll incentivize bloated code!" "The best engineers delete code!" “Outcomes over outputs!”. All valid comments in some contexts, but they miss a crucial point: quantitative metrics, when used appropriately alongside qualitative data, provide valuable insights into team performance and health.

Cross-functional teams have become the backbone of modern product companies, bringing together product managers, engineers, and designers to tackle complex customer problems. But while these teams promise better decisions and greater autonomy, many organizations struggle with fundamental questions: How should teams be structured? What problems should each team own? How do you ensure they maintain long-term customer focus rather than getting lost in feature delivery? Team Charters offer a powerful solution to these challenges, providing teams with clarity of purpose and the foundation for true customer obsession.

It can be hard to know where to start when defining a strong organisational culture for a product business. One thing is for sure though, great product and tech businesses all share on thing in common: a culture that seeks to achieve product, engineering and operational excellence for its customers. Depending on what your teams do, these customers may be internal or external, but the goal is still the same: ensuring customer success.

In DevOps, the two-person rule is a widely adopted practice for ensuring accuracy and safety in critical operations. However, Software engineering teams arent the only ones applying similar techniques - what if we could take this inspiration to further improve the two-person rule? Enter Shisa Kanko, a Japanese technique that’s been used to enhance protocols in all parts of Japanese life.

Last week the world celebrated International Women’s Day and over the week many female leaders shared powerful stories. One pleasing change I've seen over the past few years is a shift from a focus on Equality to Equity for Women in the workforce. Where once quotas were a big discussion point, we’re actually talking about the real stuff – how workplace culture and sexism tends to just make it challenging for females to succeed to the same levels as men.

Following the WannaCry Ransomeware attack in 2017, Windows stopped supporting the SMB1 protocol – and along with it Windows hosts’ previous primary broadcast discovery mechanism. Since then, Linux hosts have mostly gone dark when it comes to sharing discoverable network shares with Windows network clients. However, Windows supports the Web Service Discovery (WSD) protocol. Ubuntu has added support for WSDD – and now you can easily do the same for any Linux distribution that supports Python.

Engineering teams practicing DevOps strive to improve the way they build, ship and operate their software while avoiding customer impacting outages. Parts of this problem can be solved through automation that reviews and monitors your codebase before and after release, taking action before a human operator even investigates an event. One of the hardest parts of reducing system outages completely is that software still involves human, and human involvement always brings its own set of challenges.

For the past few weeks I’ve been battling to get my Linux instances to access file shares on my Windows 10 instances over the network. Whether it was Ubuntu, Fedora, or RedHat, the recent upgrades to Windows 10 left my Windows shares inaccessible via Samba. Troubleshooting was difficult as I had nothing to go on exception really ambiguous messages via the syslog (“Failed to mount Windows share: Connection timed out”). After some trial and error it all came down to an undocumented change in how Windows 10 supports the SMB protocol.