What's this all about then?

I've always had a background thread running in my head about ideas that would make good blog post topics but never acted on it. I wrote a bit on my personal site back when I was doing open-source development work which ended with a whimper of a post about "committing to focus". I guess I committed pretty hard since that was 12 years ago.
I decided to start another site specifically on topics related to Software Engineering Management to share my thoughts and experience on various topics. This is that.
In keeping with the times, it's available online or you can subscribe and get it in your email. It also publishes to RSS if that's more your jam.
Why Chaotic-Good Engineering Management?
Chaotic Good is the Right Alignment for an Engineering Manager (At least in growth companies)
I've spent my career in growing companies. I've watched software organizations grow from a single, small, easily coordinated team led by a single founder to a multiple product multiple department Organization with VPs and Directors and matrixed org charts.
When companies are growing, it almost becomes a cliché to say "what got us here won't get us there". In other words, it's important to throw out things that stop working or aren't going to work. Recognizing what those are is a bit of an art but it gets easier with experience.
'Alignment'?
I confess, I've never really played Dungeons and Dragons, which is rare for someone in this field, but the concept of 'alignment' is a useful one. If you're familiar with the concept you can skip ahead. Otherwise, read on...
There are 9 main 'alignments' in D&D consisting of two axes. "Law vs. Chaos" and "Good vs. Evil" with a 'Neutral' third option on both.

With that out of the way, let me explain myself some more...
Why 'Good'?
It should go without saying that your alignment should be 'good' but I'm sure we've all worked with and/or for people who are probably more on the neutral to evil end of the spectrum. Think the social climbers and political wranglers who take credit for other people's work, throw their colleagues under the bus with upper management or otherwise do things that put themselves ahead of their team or the business.
We're not trying to be that, you and I. We want to do what's right by our teams while making the business successful in the process. We do that with the confidence that, social climbers and political schemers be damned, our contributions will shine through and we'll be recognized and rewarded for the outcomes we produce. In some orgs we might not get promoted as fast or as often, but we sleep soundly at night.
Why 'Chaotic'?
'Chaos' is generally an undesirable state for a team, organization or company. I'm not advocating chaos. I am, however, arguing that the other end of the good spectrum, 'lawful good', is the wrong way to be in a growing org.
As your company grows, you will tend to accumulate rules for doing things. Often those rules are there for, let's be generous and call them 'boundary testing employees'. These employees need to be explicitly told "no, you can't stay at the Ritz-Carleton on the company dime when visiting another office". Oftentimes someone will do it, be scolded for it, and voila now you have a rule written down somewhere that says 'no booking 5 star hotels'.
Sometimes you'll find those rules get in the way of doing the right thing. One small example I'm fairly consistent on is not requiring my team members to log official PTO for minor "maintenance of life" activities like dentist appointments or taking their pets to the vet. Since these jobs usually have some unpaid overtime I prefer we interact as adults and focus on outcomes rather than time-behind-keyboard. And I'd rather they keep their time off for actual relaxing and recharging. It also demonstrates trust and prioritizes autonomy. Is it technically breaking the rules? Probably. Do I care? Not really.
The point, however, is not that breaking rules is fun, or that we're breaking them for the sake of it. We break rules when only when they get in the way of doing the right thing.
One fellow chaotic-good leader I worked with was fond of saying "don't be the reason a policy is created!" to his team. I've adopted that saying as well as it really encapsulates the chaotic-good ethos. You're saying to your team, "look, I trust your judgment and I trust you not to take things too far. Do good work and stay out of trouble." It gives teams autonomy without letting them off the hook for accountability.
Change the Rules If They're Not Useful
Sometimes is not prudent to break the rules, even when they're in the way. If you feel like your HR mandated performance review process is too heavyweight or is counterproductive in some way, I would not suggest that you just skip it or go rogue and run some entirely different process. That won't end well for you in most companies. You can, however, gather data and feedback and advocate for changes to the process. You can usually gently push the boundaries of a system like that and turn it into positive change. The successful 'chaotic good' manager knows how much they can get away with.
Do I hate process and structure?
On the contrary. Process and structure are necessary as you grow. Software teams of a few people at the beginning are easy to keep aligned. Your 'planning process' can literally be someone announcing "I'm going to redesign the user preferences page, everyone stay away from it for a day or two, I'll let you know when I'm done." But once you have more than a handful of people that breaks down and you need to add structure and coordination. A ticketing system, teams, product managers, designers, and managers to help coordinate it all.
What I do hate is unnecessary process. Process that provides no value, or worse, gets in the way and starts hindering or even preventing good outcomes. Finding the right balance is what it's all about.
So, welcome, fellow traveller, I hope you find these ruminations on software engineering management useful.
Alignment Chart image credit: Schützenpanzer - Own work, CC0, Link
"Welcome" by WaywardShinobi is licensed under CC BY-SA 2.0.