I'm kind of a black sheep in management circles (in software), because I instinctively resist anything that means more process. I suppose that some combination of my general skepticism toward authority, and not being a Type-A, are partially responsible for this. But it's also experiential, because I've seen over and over again that more process doesn't result in better outcomes.
What I've struggled with for some years is understanding how to account for success if process isn't the winning thing. Recently, I've noticed that there are themes that influence decision making and operational direction. These are decidedly harder to codify and communicate, which may be why translating my instinct into institutional action has been so hard for most of my career.
It's a work in progress, but there are some things I can write down that are independent I think of any specific industry.
- Focus on outcomes. A lot of processes do not serve outcomes, they only provide structure. When you start to look at every action and whether or not it really benefits the outcome, it's amazing how many things just fall away as unimportant. If the outcomes aren't clear, then they need to be better defined so you're not just throwing crap at the wall to see what sticks.
- Use delivery as a constraint. This helps you focus. If you're doing thing that you don't need to deliver the thing, maybe you don't have to do them at all.
- Momentum over status quo. It's shocking how often people will double down and defend "we've always done it that way," even though the trajectory that isn't that shows how you don't need the old way. This theme is a way to foster innovation, which by definition is not doing the same shit over and over.
There are some software specific things too...
- Bias toward working software. The best way to get over assumptions and complexity is to just build working things, as fast and simply as possible. I'm always surprised by the desire to fight this. I don't think you have to work in the field very long to know that the more you try to account for All The Things up front, the more wrong you are. If you try to get the first 80% right without spending 80% of your time on the last 20%, the outcomes are better.
- Don't be dependent on the world as you know it. Everyone works in an enterprise that has baggage, and it's hard to change. When you look for solutions that don't require you to commit to the legacy you're working in, everything is easier, faster and has an eye toward the future. Another way to look at it is, don't bolt on the thing you need to build to what already exists. Look for ways to build it in a way that it could be plugged in anywhere.
- Observability isn't optional. If you can't measure all the things, you don't know if what you have is viable. Software people get hung up on how well the hardware works, which isn't useful because in a cloud world, scale is easy. Measure how fast your thing responds to requests, how long it takes to work with other services, how often it does certain things, when it fires off business events.
- Performance is a feature. If it needs to perform at a certain level, you need to design for that outcome. It's easy to build something that sucks in terms of performance, so understand up front what your objectives are here.
Again, these are themes, directives, ways to do stuff. They are not really processes, the go-to thing that managers tend to lean into. Stop that.