Comment by edoceo
12 hours ago
I had a role, we got a new CTO. This man could not stop wiggling things. Almost from day one. Not just small things but larger things too (let's migrate to a new issue tracker/wiki thing (back when Redmine was popular)). Flipping staff to new focus (eg: moved a help-desk staff to top NetAdmin, replacing Cisco Certified guy, which caused some havoc during an audit). What a mess, just had to put his fingerprint on everything!
Another time we got bought, merged into a new company, their CTO was our new CTO. In one of the initial meetings said "things won't change much" and, naturally, we didn't believe. She moved slow on all the things, methodical. Spent some time with each component team. It was months before we started making changes to better mesh with the new company. Very little chaos. Still admire that management style.
I think there's a middle ground. I used to be intensely critical of "doing things just to do things." The more perspective I get, the more I realize that, in a situation where things are not going right by whatever criteria you use to determine that (outside scope here), you need to make changes.
The right way to make those changes, or at least one way and I don't know a better one, is to perturb the system and see how it responds. This is necessarily risky and uncomfortable, and choosing the right things to perturb and the magnitude of those peturbations is a very, very tricky skill.
But ultimately if you're dealing with an opaque system, which most companies are, and you want to make it a more transparent system that can change, that risk and discomfort are necessary side effects.
This is of course very situational, and the methodical method is by far preferred, but if you'll permit a metaphor: you get dropped into an unfamiliar cockpit, and the controls are labeled in some foreign language. The plane is crashing, or at least you don't know if it is. What do you do? You wiggle things and hope that, in doing so, you don't crash, and you take very careful note of what happens.
> But ultimately if you're dealing with an opaque system, which most companies are,
While most companies have elements that are hard to see clearly [1], I would hope 95% of what the company is doing would be transparent to the CEO.
The CEO should easily be able to tell which divisions/projects are profitable, which are on track to hit their goals, how those goals combine into a coherent strategy, which areas are getting the most complaints and refunds, and so on.
[1] intangible concepts like 'innovation' and 'culture' for example
If you can figure out how to turn the "should" in that sentence into "can" then you'll die wealthy. Tracking goals and turning them into a coherent strategy is a major unsolved problem in software engineering.
We accept best-effort from CTOs, but that leads to an industry that is a bit like a comet with a few success stories and a huge burning tail of leadership where they have limited to no ability to understand whether they are on track to achieve their goals and those goals don't come together into a coherent strategy. There is a strong argument that many of the success stories are only good relative to companies that failed even worse than they did and we all had to pick one of these bug-ridden software packages.
It is a lot like the era of the manufacturing industry before the statisticians moved in around WWII. We haven't managed a similar moment in software yet.
You can never understand complex adaptive systems to anywhere near 95%, and leaders believing that they can—that the map is the territory—leads to some pretty bad dynamics.
1 reply →
Sadly at many companies that's really not true. The CEO has direct visibility into direct reports and those metrics, but those don't necessarily clearly indicate what changes to the system would do. Largely because they're descriptive, not predictive, in my limited experience. They also tend to be lagging or current indicators, so they tell you what policy was doing last quarter. If those metrics are trending badly, you can't just demand "move X number up" and expect any success.
This might be appropriate in some cases, but it's important to consider that you have a finite amount of social capital as a new leader. Once people get sick of poorly thought-out changes it can be hard to keep changing things and get buy-in, and talented employees (who almost always have someone asking to hire them) can be the first to leave.
I'm a fan of Chesterton's Fence [1]. Put effort into understanding the organization and why it's architected the way it is before making changes.
[1] https://www.lesswrong.com/w/chesterton-s-fence
A great philosophy for anyone who is pretending to know what they're doing that will still result in the plane crashing because you need to know how to fly a plane to fly a plane, and you need to know how to run a business to run a business.
On the other hand, because you've run business A, doesn't mean you have a clue how business B is actually working. I've seen that one more than a few times too.
Sometimes the plane is going to crash and the best you can do is a soft landing.