If you’re a software engineer, you need to be familiar with Clean Architecture. As software evolves and changes, without a solid design approach, your codebase will quickly become a mess and every new feature addition risky and error-prone. You need direction, a system, a philosophy. You need an architecture that allows you to introduce changes confidently and with less friction. Enter Clean Architecture. It’s a design philosophy that introduces dependency rules to decouple components based on their purpose/concern. Discovering Clean Architecture was a revelation for me and transformed how I’ve been coding since. For a comprehensive introduction with an example implementation in Go, check out my updated blog post here: pkritiotis.io/clean-architec….

Staying technical as an Engineering Manager - the struggle, the need, the meaning and thoughts on approaching it. This is a topic I keep coming back to. Not a framework, more of a personal essay on where I’m at today after a few years of wrestling with it pkritiotis.io/staying-techni…

One of the most powerful patterns I’ve used in distributed systems is the outbox pattern. The outbox pattern ensures at-least-once guaranteed delivery of messages after a database operation. It’s a simple pattern, but its implementation poses a few challenges for developers. Check out my post for an introduction and the challenges of implementation: pkritiotis.io/outbox-pattern… And my sample implementation in Go: github.com/pkritiotis/go-out…

Even if your team enforces rigid, questionable rules, don't go your own way and be a reckless cowboy. You're part of a team. Your team's success is your success. Break the rules and nothing will work—Not even your way. Help your team. Work with them. Challenge the rules, but stick to them while they're in place. Show why you disagree, and back it up with data. Hear the other side of the story. Reach an agreement. Often there's a reason that a 'dumb' rule is there. And if it's truly dumb, you'll have more success persuading your team by working with them, not against them.

I first encountered the Change Curve a few years ago during my training as a new Engineering Manager. Learning about the stages has been invaluable, helping me adapt my actions based on the team's state: • Denial → Listen, explain, and empathize • Resistance/Doubt → Encourage exploring different perspectives • Acceptance → Acknowledge and support • Commitment → Celebrate and plan ahead Change is inevitable, and even if it seems negative, you should try to make the best of it. Embrace it, and it can lead to hidden opportunities.

Standups are not policing meetings. They are feedback meetings. Their real value lies in: • Spotting and addressing blockers • Progress awareness • Clearing up any confusion • Aligning priorities Regular standups are crucial for team alignment and smooth, efficient progress

The CrowdStrike incident is a strong reminder that systems fragile by design are at the mercy of Murphy’s Law: if something can go wrong, it eventually will. It was only a matter of time. What's scary is we don’t know how many other important systems are just as fragile and haven't failed yet. Very few knew what CrowdStrike was three days ago. As long as there is a possibility for failure, it will likely happen again. Our only hope is to minimize the impact. To be honest, I was surprised to learn that a third-party software update could cause such a big problem for an OS. I’m not an expert in this domain, but I'm sure there are trade-offs in design choices. General-purpose software including OSes, can't be perfect for all situations. The CrowdStrike event makes us question the choice for critical systems that can't afford to fail. Fixing the process that led to this issue is the first step, but it won't solve everything. The problem lies in the design. We must learn from this incident and be more cautious with software design, especially for high-impact, critical systems.

Staying strictly fixated on any Agile framework and enforcing written-in-stone rules is inefficient. Avoid common pitfalls by embracing the Agile philosophy over framework rigidity, and adapt it to fit your needs. Read more in my latest blog post: pkritiotis.io/agile-philosop…

The value of improving areas that reduce the cognitive load of the team is often underestimated. - Automate long manual processes and mundane and error-prone tasks. - Reduce uncertainty through documentation, tests, validation processes. - Build utilities that simplify your team's workflow and boost its productivity. All of the above can have outstanding results for enabling a smooth execution and stability.

The most influential tool that has completely transformed my learning is Zettelkasten. This personal knowledge management (PKM) system helps me organize my thoughts and knowledge. I discovered Zettelkasten 5 years ago and have seen mind-blowing improvements in: • Knowledge retention & understanding • Connecting information • Idea generation • Thought clarity If you're serious about learning, a PKM is a game-changer. It doesn't have to be complicated or strict. If you don't use one, you need to.

Naming in software is tough, but there are some real gems out there. One of my favorites is @martinfowler's Strangler Fig Pattern. The metaphor is brilliant: a strangler fig (new system) grows around its host (legacy system), gradually replacing it and eventually taking over.

Middle management in engineering is a tough job, one of the toughest. You’re the bridge between your team and the higher-ups, balancing both worlds. With Superiors: • Secure fair team workloads and timelines. • Push for quality of life improvements for your team. • Advocate for interesting projects that could provide growth opportunities for your team. • Cover and justify your team’s missed goals and mistakes. With Your Team: • Absorb pressure without stressing your team out. • Balance demands with a practical approach. • Keep them motivated, even when delivering tough decisions. Mastering this balancing act is challenging but incredibly rewarding!

1. Alignment Make sure that your team members know what success looks like. Every person has their individual role responsibilities but they also need to understand team goals. Have regular discussions about roles and expectations during your 1:1s.