Managing

The point of management is to take a group of people and get something done.

The difficulty of management is that you can’t just do it yourself. You might know how to do it, you might only have a vague idea, or you might even be entirely clueless. But even if you do know, which is obviously better, you still don’t have the time to go it alone.

The trick to management is to 'enable' other people to do the work for you. The catch is that you don’t want them going off rogue. The tradeoff is that the more you try to control them, the worse they will behave. So, there is this fine touch needed to steer them in the right direction, but then let them go off and do the work they need to. 

You need to treat them like they are the fingers on your own hand. You know what you want to pick up, they each position themselves to make that possible. 

To enable someone you have to put them in the right place, at the right time, with the right tools. Everyone’s different, everyone is unique. You need to draw a wide box for them to operate, but you also need to know when they’ve strayed out of bounds. You can’t crush their confidence, but you don’t want them overloaded with arrogance or hubris either. They’re all different types of chess pieces that you need to fit into the right places to be successful.

You can’t ever push them under a bus, even if they aren’t working out. Everyone else will see that and be affected by it. You need patience, guidance, and it requires a lot of effort.

Some people see management as the road to advancement. Others see it as an inevitable bump away from their past. Either way, a good manager enables the people under them, a bad one is an obstacle to be avoided as much as possible. So, in a real sense, if your people are avoiding you they are sending you a strong message.

Sometimes people think that management is just running around spouting out a lot of orders. That’s the opposite of effective management. It’s just an annoying person causing trouble. The real skill is listening. You have to hear what blocks people, what tires them out, what diminishes their confidence. You have to understand the larger picture, the context playing out from above. You have to know what their boxes are, but you don’t always have to fully understand the specifics of each item in them. When you don’t understand you have no choice but to listen to your people and trust them. If you do understand, and they are rogue, you have to gently guide them back on course. Either way, it isn’t for you to layout each and every detail of their assignments, only those cross-cutting items that absolutely need to be in place in order to ensure that the bigger goals are also met. You coordinate and protect, you don’t interfere and punish. 

If you understand this then people will want to work for you. If you don’t get it then you are on your own, no matter how many people are below you. The choice is yours.

Friction

In software development, ‘friction’ is any and everything that keeps you from moving swiftly to getting your work ‘fully completed’. It’s worth understanding that the job is not done until it’s out there, being used smoothly by a bunch of people. Coding it is a start. Testing it is better. Releasing it is great, but it’s still not done until it’s been running correctly for long enough that it won’t end up showing up back in the shop needing repairs.

Along the way, there are literally millions of little things that get in your way and slow you down. Things that are unspecified, or awkward, or require you to remember a lot of trivial stuff. The problems can be neglect, or ambiguity, or lack of exposure. It doesn’t matter what it is, or whether other people think that it is normal and acceptable, only that it has resulted in you slowing down a bit.

In some cases, particularly with methodologies and ‘controls’, the friction is actually deliberate. Someone, somewhere, wants you to slow down. Sometimes they have extremely good reasons for this. Sometimes it is just a random accident of the dysfunction in your organization. Most often, there is nothing you can do about the larger systemic friction. You just have to live with it.

But there are lots of smaller, closer to home, areas where you can and should eliminate friction. You should always leave a little bit of extra time, so you can remove one or two small issues a week. If you keep that up over the long haul, things will gradually get a lot better.

If it’s awkward to find the stuff you are looking for, you can invest some time in organizing it, or acquiring better-searching tools, and learning how to use them properly.

If it’s repetitive actions, you can automate them with scripts, or cute little GUI widgets to trigger larger actions.

If it’s volatility coming directly from the domain, you can spend time to learn more about the domain and talk with as many people as possible. In all domains, some issues are intrinsically dynamic. It’s a huge mistake to try and treat these statically.

These things are all in your control. You can spend time improving on them. Even if they are little, they add up quickly.

If the issue is not enough time, you need to learn to add a bit of slack in your estimates. Oddly, if you get ahead of the ball and reduce a lot of friction, you’ll find that you’ve caught up and often have more time than you need. The mistake is getting behind in the game, and then digging the hole deeper and deeper by just trying to ignore all of the little problems around you.

Stop digging, apologize for being late and fix a small issue or two.

Data Flow

I like to write this post every few years. People generally skim over it, and then ignore what I am saying. So I’ll probably end up writing it a few dozen more times, then give up completely.

There is one major trick to keeping everything sane while building a big system:

Forget about the code. 

Just ignore it. 

The problem isn’t the code, it isn’t ever the code.

It’s the data. 

If the data flows around the organization in a clean organized matter, then the code is just the secondary issue about the small translations needed as it moves about.

That is, if the data is good, then any problems with the code are both obvious and easily fixable.

If the data is bad or incomplete, the entire stability and trustworthiness of the system is busted. Collecting megabytes of useless data is an epic waste of time. There is no foundation for the work.

Also, stepping back and viewing the entire charade as just data flowing around from place to place is extraordinarily simpler than trying to grok millions of lines of code. Mostly, we collect some data from the outside and combine it with data collected from people in the middle of their problems. That’s it. 

You should never be writing code to retroactively repair data. That is if the data doesn’t exist, or it is ambiguous, or it’s stored in a broken format, that is the real problem. Patching that with flaky code is not a real solution. Fixing the data is. 

If you understand how the data needs to be structured to store it properly, and you honor that knowledge in the code as it moves around, then everything else is a thousand times easier. It’s code you need to write to move it here, or there. It’s code you need to write to translate it into another format. It’s code you need to write to combine some of it together to craft derived data. That’s pretty much it.

Then you can spend your creative energies on building up enough sophistication to really help people solve their real problems.

What Should Have Happened ...

 The first thing to do is admit that it went wrong.

The next thing is to figure out what should have happened instead.

With the two outcomes, there will be a bunch of points in time where things deviated from the desired path. Find all of them, list all of them out.

In some cases, an earlier deviation invalidates some of the later ones. That is, if it had not initially deviated, then some later deviation would never have occurred and is rendered moot.

That leaves you with a list of ‘critical’ deviations. They are independent, or at least mostly independent enough that they all matter. 

Keep in mind that a bunch of concurrent small problems can interact together to create much larger ones. If one or more of the deviations was a ‘perfect storm’, then you need to list out all of the other contributing littler deviations.

With a final list of significant deviations, you can roughly assign a weight and fixing costs to them. 

An earlier deviation might actually have very little weight, it might just be more of an annoyance. But it still should be documented as ‘contributing’. 

There might be some deviations whose real cost is far too high to realistically fix them. The only solution for those is to put in place controls or mitigations to reduce their effect next time. But they should be noted as expected. 

So now you have:

• What went wrong.

• What should have happened instead.

• A full list of everything significant, including breakdowns of lesser contributions.

• A list of alternatives and a list of mitigations. Including the approx weights and costs of each.

The only thing left to do is march through the list and fix things.