Process, schmocess

Today I’m talking about two different kinds of Process. On the surface they’re very different, but both kinds exist to support you and protect you. They’re also similar because some people regard them as threats or compromises.

One kind of Process: the simple kind.

The first kind of Process constitutes the fundamental no-brainer routine stuff: backups, security, and versioning. It’s amazing, but maybe not so amazing, that a lot of small shops don’t have this covered. They’re busy and all available people-resources are focused on survival tasks like delivering applications that are already late. Nobody’s in charge of the infrastructure.

What could possibly go wrong? Lots of things. That’s why the routine stuff has to be routine. Create a simple backup schedule that everyone understands. Get a security audit done and follow through on its recommendations. Select and use a version control system, even if you aren’t sure you started with the right one. They’re not too hard to migrate later anyway.

The killer is when you take too long to move forward with the obvious things that have to get done anyway.

Make these support systems part of your everyday work! Assign someone to condense and review security logs every day. Require that code changes get checked into a dev branch by day’s end at least.

The point is not to give you more to do. It’s to give you less to think about. If you can, make these practices automatic. If you can’t, at least make them incredibly simple.

The other kind of Process: the complicated kind.

The other kind of Process is harder; it’s the highly practical but not so scientific discipline of organizing projects into tasks and making sure those tasks get done.

There are so many ways to do this, ranging from heavy approval-intensive methodologies to very informal self-organizing agile processes, but the most common by far is to have no discernible Process at all. Whatever appears to be most urgent is taken on next. Planning is speculative and not empirical. Schedule slips are handled by exhorting everyone to work harder and put in more overtime.

That’s not sustainable, and quite frankly it’s an easy way out for management. It spares them the pain of thinking too hard and taking emotional risks. (No, seriously.) And it dumps the very real costs of their poor decision-making on the line developers who are trying like heck to get things done.

Many volumes have been written on this kind of Process in software development, and they won’t fit here. But in summary I’m saying you need to develop a Process that actually works for you, and by “works” I don’t mean something that simply pushes people to “do more with less.” That’s not a process, that’s exploitation.

But here’s the thing.

I’ve worked with managers who resist both kinds of Process for the exact same reason: Process feels like it’s taking away their Control. “If I don’t personally merge everyone’s source changes,” they might say, “how do I know they’re doing it right?” Or, “If I allow my developers to self-organize, what if they don’t do it my way?”

To that I say, “Why hire smart people if you can make every decision yourself?”

Of course you need to control your department or your company. As the manager or owner, it’s your job to set a direction and reach goals. How does that not conflict with what I said about Process though?

You need Trust too.

People who need to Control things tend to have problems with Trust. I’m not sure why. But building that Trust is essential.

Probably the toughest client relationships I’ve had over the years were those in which everything was scrutinized, but nothing was transparent. So corporate decisions would take a long time, but I couldn’t figure out who was responsible or what kind of information they needed. Sometimes they’d want a detailed status report, but I couldn’t get anyone to spend a couple hours with me just to look over the code and talk about what doesn’t work.

This is where the two kinds of Process overlap and support each other, when you do it right. Use the simple safety of version control to let all the stakeholders see what you’re working on. Don’t make status reports–display status posters!

The tools and practices that make the development team work better together are the same as those that let management see what’s going on! You don’t have to choose between maintaining trust and getting the job done.

You do, however, have to choose between letting people do their best work and having detailed control over that work. Micromanaging knowledge workers is asking for failure. If you want the best outcome, you may have to give up a slice of authority in exchange for some of that trust.

It’s worth it.