Building ownership requires relinquishing control One of the most important components of effective technical leadership is providing teams the guidance that they need to completely own their products and processes. Ownership is possible only with a complete understanding of the team’s mission and their bounds of autonomy. It’s also the primary prerequisite for building a team that’s empowered and capable of improving itself. For higher-level leaders, the difference between guidance and control is subtle, and it’s surprisingly easy to find yourself on the wrong side of the line.

Enable mindset changes by forcing changes to behaviors Changing the way that we think about things is difficult. I’d hazard a guess that everyone has tried and failed at last once, even when imbued with great motivation to make a change. It’s relatively easy to decide that a change is needed, and it can even be easy to force our thoughts in a different direction for a short period of time, but somehow after a few short days or weeks we find ourselves right back where we started wondering where it all went wrong.

Getting started with a new ecosystem can be difficult. Using Nix makes the solution reproducible! I was recently following the setup guide for Rust and WebAssembly and found more surprises than I was expecting while setting up the development environment using a Nix Flake. As I’ve also been working towards a personal repository of Flake templates, I thought it might help others to detail the issues that I encountered and how I solved them.

Constraints don't always have to make things more difficult. What comes to mind when you hear the word constraint? Often, thoughts will immediately jump to the negative: a constraint as a barrier that makes it more difficult to accomplish a goal. This additional difficulty can end up being a significant source of complexity when trying to solve problems, sometimes to the point that avoiding constraints becomes a goal of its own.

The Advent of Code is an annual programming competition with a lot of interesting puzzles. While the competition is mostly about answering the questions as quickly as possible, I instead prefer to challenge myself to come up with low-latency solutions for each problem. Now that the 2023 edition of AOC is wrapped up, I thought it would be interesting to go into a bit of detail about some of the faster and more unique solutions that I came up with.

Global consistency comes at the cost of autonomy; be careful not to stifle what could be your most effective teams Earlier this week, I was discussing Platform Engineering with some other technical leaders. Someone suggested that one of the main benefits of an effective Platform was “reducing duplicate effort for developers”, to which another replied: I have worked for a company that forced all engineers to use the same shitty CI/CD system.

Weeks of coding can save you hours of planning Software engineering best practices emphasize and value the importance of iterative work. They encourage working in ways that give us opportunities to make decisions frequently and adapt to changing circumstances. These principles are nearly ubiquitous and seem necessary for successful engineering efforts at large scales, but the concept is sometimes taken to an extreme that can be unhelpful. While it’s almost always a good idea to maintain the ability to iterate quickly and change our minds, that doesn’t mean that one shouldn’t take time to think before they begin to act.

Simple is the opposite of complex, easy is the opposite of difficult I spend a lot of time thinking about complexity. I read an essay recently about complexity and cognitive load in software engineering that touches on a specific point that I think is important to the professional development of software: the difference between simplicity and ease. Like many engineers, I don’t enjoy working within overly complex systems. The cognitive load required to get anything done within such code bases is far greater than it should be.

Support your teams' decision making processes while giving them the space they need to function autonomously. Autonomy is an important element of highly effective teams. As a leader, there’s a difficult balance to be struck between helping your teams get things done and providing the space and freedom that they need to solve problems themselves and own their solutions. Concepts like go slow to move fast can be used to help with this, but even still the core problem remains: how can a leader help teams solve difficult problems without reducing their ability to function autonomously?