It's about maturity

Process is what you get when your people are infantile

The reason for rules and regulations—for all “process”, really—is to compensate for immaturity.

In the tech world there is agile and waterfall, kanban and scrum, standups and retros and refining sessions and huddles and postmortems. And the belief is that these things are necessary for the organization to function.

But the point of agile is to work iteratively and to adapt as you go. Put the customer first. Embrace humility.

I can’t speak for others, but I was doing this long before there was an Agile Manifesto. I signed it not because it taught me something new, but because it confirmed something I already knew well.

But the Manifesto was not process. It was a statement of priorities, and you either live them or you don’t. It isn’t do this, not that. It is prefer this over that. Everything is contingent, as always.

Mature developers adopted the manifesto immediately if they weren’t already doing it, or, as I did, found confirmation in it for what they had been doing for years.

But immature developers struggled. And so for them, process was invented: Agile with a capital A. And in so doing, much of what was important in the manifesto was lost. Not everything translates, as any translator can tell you. Rules are meant to be broken.

This led naturally to the Anti-Agile Manifesto some years later.

We don’t need no stinkin’ sprints

I don’t need to go to a standup to be able to do my job well. I don’t need to go to a bitch session (er, retro) to hear children whine about how they didn’t get their way. That’s an utter waste of my time and just interferes with getting the work done.

Get five adults in a retro and you hear this: “I’m good. You good? Ah, we’re all good? Great. See you next retro.” Nice: the thirty-second retro.

Adults clean up after themselves. Or better, don’t make a mess in the first place.

After every retro I hear people talk about how great it was to get that stuff out and how things will improve now. And then nothing ever does. I can’t think of a single retro I’ve been to where things changed as a result.

But then the point of a retro is not to find ways to improve. That’s the excuse. The point is to let people vent so the pressure to improve is relieved and we can continue with BAU—business as usual.

It’s not truly about changing. It’s about avoiding change.

I don’t need an enforced “huddle” or a “refining session” to figure out how to best write the code. I know how to do it, and if I’m unsure, then I know who to go to to get good advice. Maybe I don’t need any. But if I have a huddle, then the participants feel bound to change something if only to feel that they contributed.

It’s similar to when I send something to my boss for their approval. I always include something a bit off and not terribly important so they have something to reject. If I did not, then they would reject something important because they had to be seen as “managing”.

That’s some insane shit. If you don’t need help, don’t ask for it. Because you’ll get it.

Adults do the right thing without effort

The nature of a mature human, sometimes called an “adult”, is that they do the right thing without having to be forced to do so, or even having to force themselves.

I was reading an essay by my favorite philosopher recently that addressed this topic.

The philosopher said:

To an adult, doing the wrong thing is literally inconceivable. It just doesn’t even come up.

When you sit down to dinner, do you have to exert discipline to keep yourself from picking up the fork (or chopstick) and stabbing yourself in the eye with it? If so, please seek professional help immediately.

But to nearly all of us, it never even occurs to us to stab ourselves in the eye with a fork. We don’t need any willpower at all to avoid it because we know it will hurt, and probably maim us. It just doesn’t even come up.

The adult worker does the right thing without having to exert will or self-discipline. Not being an infant, the adult is not ruled by impulse. There are no foolish urges to resist. Doing the wrong thing—and we all know right from wrong—just doesn’t even come up.

So mature developers act with humility. They understand what they know and what they don’t know (and they are always open to better their understanding).

If they don’t know what they’re doing, they don’t just wing it. They seek help from someone who does know.

Which is not to say that they blindly follow advice. They have their own minds and they make their own decisions, but never out of arrogance or obstinacy. Shown a better way, they adopt it immediately. They keep their eyes on the objective.

It’s not a battle of egos because the adult has no ego. Egos are for infants.

The best size for a team is one

Teams are another example. Teams are an artificial construct for working with immature people in order to assign a single parental figure to a group. Ironically, the manager is often equally immature if not more so.

After all, immaturity is rampant. Just look around.

The lie is that teams are necessary for collaboration. What nonsense.

I have spent much of my career working solo, but a significant amount stuck on this or that team. I got much more work done working solo. But working “solo” doesn’t mean that I was working alone. Coding is, in the end, a social activity.

I still had to collaborate with others. Obviously! I could not get my work done otherwise. I had to work with designers, UX engineers, lawyers, testers, back end developers, etc. If I didn’t, I would fail at the task.

But I didn’t need to be on a “team” with them to do so.

The truth is that being on a team only made it more difficult. As the teams were almost always determined arbitrarily and not modified even when situations changed, I more often than not needed help from people not on my team.

Most of the time it is like this: Take the number of people you have, divide by the ideal team size, and that’s the number of teams you need. What the teams are for is irrelevant (though we usually pretend otherwise).

Having to work with people not on my team often meant that they gave my needs much lower priority, if they cared at all. In some instances, I actually had to work around them as they became roadblocks. I think most devs have had this experience.

A good indicator that teams are really for socializing rather than getting work done is that they often have silly names. I once worked on a team called the Wu-Tang Clan. I kid you not. (I promptly christened myself the Ol’ Dirty Bastard.)

Good name, but I would have preferred A Tribe Called Quest. It’s utterly tribal, after all.

Meanwhile, I had to attend a daily stand up in which the members of my team would tell me all sorts of things utterly irrelevant to my task. Frankly, I had no interest at all.

And then I would be expected to do the same to them. What a complete waste of time.

Occasionally, I was able to get a team to agree to asynchronous standups online. This was much better because we would each read only those reports that were relevant to ourselves, but the parent, er, product owner and the BA could keep up with what we were doing. And it was all in writing. Heh.

Virtually everything of value I have ever done in the collaboration sphere was done in one-on-one conversations, realtime or asynchronous, with another key player. The efficiency of teams is similar to that of meetings: very low. And everyone knows it.

The truth is that teams exist for only two reasons: 1) to give management types a number of “reports”, which reflects, they believe, their status in the company, and 2) for social purposes for those who evidently don’t get enough socializing in outside of work. For anyone who just wants to get the work done and then head off to their real life, they are an onerous waste of time.

My ideal job is one in which I focus on getting the word done and nothing else exactly when it needs doing, and then go play. Maybe I can get it done in three hours. Maybe it takes thirteen hours. Well, I am versatile and adaptable. But all this inefficiency at work is just wasting my life, and I haven’t any to spare.

Processes are not panacea

Another big mistake I see with reliance on process is the belief, usually subconscious, that they are some sort of panacea. A great example is pair programming.

I have nothing against pair programming in the right circumstance, but there are few developers with whom I would pair well and few situations in which it would help either of us.

For some other developers, pair programming is great, and I strongly encourage them to do it.

But why do people continually presume that what is good for them must be good for others? How does “I love pair programming” become “Everyone should do it”?

I continue to see organizations demanding that all their devs pair program, sometimes even all the time.

Aces in their places

I am a firm believer in something an old boss said to me repeatedly back when I was manufacturing burgers for a living. He said:

Always put your aces in their places.

He meant that we should put our crew people in the places where they worked best. I thought we should do more cross-training and save the “aces in their places” for times of high volume. But maybe that’s just me.

I have reflected on this aphorism much over the decades (thanks, Gary). There is so much more to it than scheduling burger flippers at a McDonald’s.

What it really means is that Karl Marx was right (as he so often was):

From each according to his ability, to each according to his needs.

Ow

Put another way, there is no such thing as a panacea, no one size fits all. Each of us is unique with unique talents, wants, and needs. So any system that tries to fit us in the same cookie-cutter boxes is Procrustean: we must be mutilated to fit.

And this mutilation comes at great cost, not only to our productivity and the quality of our work, but to our happiness and sense of self worth. Worse, this loss of self-worth just feeds back into the cycle, making it seem as if more process is needed.

And so we continue to hammer away at the broken glass thinking that this will eventually repair the window. It’s insanity.

The medium may be the massage, but the process definitely is the problem.

The right way to work

If you can’t find truly mature workers, psychologically and emotionally, then find workers with great potential.

People with humility. People willing and eager to learn. People who are open-minded and adaptable, who aren’t afraid to fail, whose egos are already secure. In short, all the qualities of a great learner.

Then nurture those individuals. Teach them. Guide them.

Week One: every new employee should be greeted by a coach who asks a series of questions: Where do you see yourself in six months? A year? Five years? Twenty years? And, most importantly, how can we help you to achieve that?

Irrespective of whether it benefits the company directly or not.

Why would a company support an employee if by doing so the employee leaves the company?

Simple: because it is the right thing to do. Did you miss the part above where I said that the measure of an adult is always doing the right thing? Companies can be infants, too, and most often are.

Do the right thing by all your employees, whether it benefits you directly or not, and you will build astonishing loyalty. And those who leave will become your greatest advocates and ambassadors. They will recruit for you.

And if their goal was something you can use, then even if they leave, they will almost certainly come back to you eventually, bringing new skills, knowledge, and insights. Check in on former employees regularly and do what you can to help them.

There is a name for this in social psychology. It’s called reciprocity, and it is more powerful than you can imagine.

Reciprocity means the same thing as karma, really: what goes around, comes around. Karma (in the modern sense) is real. Nothing mystical about it.

Keep it ad hoc

Finally, when it’s time to get the job done, inventory your workforce and decide who might need to be involved. Contact them to explain what you have in mind and get their reactions and suggestions.

Once you know who will be involved, figure out the order in which they will be needed. When person A finishes this, then it will be time for person B to start that. Decide which parts depend on other parts and must be done serially, and which parts can be done in parallel.

Now get the starting group together and have a quick discussion to work out any kinks. A quick discussion. Then it’s aces in their places and off they go. They are mature workers, so if person A needs help from person B, then person A will seek out person B without having to be told.

Members of the group will come and go as they are needed. As soon as one member completes their task, they are freed up to go work on another task with other people.

This means plenty of collaboration and coordination, but it happens organically in a self-organizing fashion because everyone is working toward the same goal and no one has their ego involved. It’s not a competition. It’s just a relaxed way to work with other competent and conscientious people.

Of course, there will always be people at different stages of maturity. So take those less mature and pair them up with a mature mentor. Someone that can guide them until they are ready to guide themself.

As always, there’s much more to this, but I’ll leave it there for now.

In sum, maturity beats process any day. The more mature your workers, the less process you will need. So focus on building maturity, and stop obsessing about process. You won’t regret it.