Peter Eysermans

Trust between the engineering team and business stakeholders is crucial. Asking for 6-months of non-feature work erodes that trust. Non-technical people become suspicious and think they are being tricked. The technical team must communicate with the business to educate them on the consequences of ignoring technical improvements. Start signalling possible

Structuring your development team is a crucial decision. Do you hire specialists or full-stack developers? The full-stack reality check * Full-stack is actually T-shaped. Every full-stack developer has their sweet spot, a technology where they truly excel. * It's about breadth, not depth. They possess broad knowledge across technologies, not encyclopedic expertise

Have you ever heard this from a stakeholder? "The engineering team keeps talking about technical debt. I don't understand what they mean, and all I get is vague technical explanations." Unclear requests to handle technical debt create a rift between stakeholders and engineering teams. The technical leader must bridge this

"You have a hard problem? Sarah will fix it!" As engineers gain experience and tenure, they inevitably face increasingly complex challenges. It's the nature of our field—the toughest problems land on the desks of our most seasoned professionals. While it's gratifying to hear, this praise can mask a hidden

I've previously discussed the consequences of technical debt. Let's explore an aspect that's often invisible to non-technical stakeholders: quality degradation. The 3 Steps of Quality Degradation 1. It starts small: adding a few lines to spaghetti code or postponing an update. 2. Non-technical stakeholders are unaware of the problem until

“Our product should be perfect, with zero bugs! Also, our budget is limited.” The truth is that quality isn't an exact science. Perfection comes at a cost. What to consider when determining the level of quality: 1. Industry context: Highly regulated sectors demand rigorous QA. For non-critical products, speed to

Mobile app development has unique challenges, particularly when publishing on the Google Play and Apple App stores. Recently, I encountered a situation highlighting the importance of foresight when creating a new app. The Challenge A client reached out because their Android app had been removed from the Google Play Store

As tech leaders, we often hear (or say), "We'll do it next quarter" regarding framework upgrades. But is this approach truly serving our teams and products? 🪄 The Illusion of the "Magical Next Quarter" Technical leaders recognize it all too well. Stakeholders push back on framework upgrades, seeing them as low-priority

I was astonished when I reviewed the CI process of a promising scale-up with a complex technological product and found these instant red flags: * GitHub actions that hadn't run for two years * A testing suite with more tests failing than succeeding * A passing build despite the failing test suite Despite

Why are they just sitting around and not helping? I’ve done most of the work, and now they’re overlooking critical bugs that need fixing. The technical founder of a promising startup was venting their frustration about the team’s lack of initiative. A newly launched feature had flaws