The Tyranny of Process Worship Within IT | Hacker News Reader

The Tyranny of Process Worship Within IT

ciopedia.com

42 pointsHume6219 comments

I think a distinction needs to be made between actual process and codified process. The former always exists, and the only question is whether it is working or not. The latter is endemic to large organizations with disaffected and mediocre management and employees, which is what Netflix is actively fighting against.

However the tone of this piece and the original Netflix manifesto does not acknowledge this distinction. I think this shows a bias that is driven by product-oriented software engineers and creatives. "If the product is great then who cares how we got there?" Well that's certainly a valid viewpoint, however it shortchanges great management. Great management is not done by simply hiring the best people and turning them loose on a project. That works in a startup where everyone knows each other and so any two people can notify each other of relevant issues. It doesn't work in larger organizations where individuals have a much narrower slice of responsibility and thus lower visibility on the whole actual process going on.

I've worked with some people who take a process-oriented approach and were very talented at getting the best work out of their employees. For these people it's no more about rigid codified processes than it is about a relentless focus on product. Instead, the goal is to understand at a high level what all the various stakeholders are doing, where their individual bottlenecks are, and determining a process that maximizes everyone's productivity. People like this are incredibly valuable, because let's face it, management is much harder than programming to do well because you are not a domain expert in anything, instead you have to figure out how to help all the different domain experts operate efficiently.

I realize none of this is news to the folks at Netflix, but I think the way the manifesto is written de-emphasizes these facts to the point that the inexperienced or low-level programmer may miss the forest for the trees, which incidentally is exactly what the problem with bad actual process is.

Codified process help to increase efficiency by remembering the best way you solved the same problem before. This is extremely useful when you are repeating problems, but it stands in the way when you keep doing new things. The real question is not process and group productivity vs individual productivity, but how fluid your problems are.

When a random customer calls the help desk ask "Is it plugged in?" aka say "Please unplug it wait 5 seconds and then plug it back in."

When the head of R&D calls ask "How can I be of assistance?"

Yes they do that. Additionally I think in a codified process it's probably more important to write down why the process is there and what problem it attempts to mitigate/solve. Then when the problem has been solved in some other way the process should be removed.

(Written) Processes seem to be the same sort of thing as code commenting.

Thanks for the comments. I should have made a better distinction between actual and codified process. My thoughts were toward codified, which, as you state, are endemic in larger organizations, and seem to build on themselves over the years, good and bad, until less and less actual progress toward the ultimate goals of the organization is accomplished. Process is delivered, rather than products...

Although I did not agree with everything in the Netflix deck, I was impressed by the "bias" toward great people rather than great process, which seems to me, to be a fresh take on it. There will always be necessary processes and there are certainly many great process best practices to draw from, but I do think we should all be CONSTANTLY QUESTIONING what is in place, asking ourselves if it is serving us or we serving it, and making changes as needed. It is my experience that this happens rarely in large organizations. There simply isn't the political will to take it on...

In the corporate world it's definitely a fresh take, and that alone is worth a lot.

The problem here is that everybody thinks that they're talented superstars, and they don't need to have to worry about rolling back a version, or testing, or any of those other dreaded bits of 'process'. Which is another way of saying, "putting some steps in place to cope when you inevitably screw up."

This piece sounds like it's written by some cowboy who wants to move fast, and be all agile and light. These people are also nominally nowhere to be found at 4am when their undocumented change brings down the production server farm, and then I have to get up and fix it... which is all kinds of fun.

The fundamental problem is that most shops are organized with 'IT', 'Operations', and 'Development' all being very separate camps. There's no mutual respect, and plenty of blame, so massive piles of process get created as a means of defense for the Ops and IT guys, who get screamed at every time there's a problem that hits the customers.

There's a really good talk on why this is bad from the Velocity conference, here: http://velocityconference.blip.tv/file/2284377

Thanks for the comment. no, I'm actually not even talking about the process of building software, (as I stated in the post), and am anything but a "cowboy". I'm talking about all the dozens of other processes that add zero value to the product, that are put in place with the best of intentions, and add all kinds of cost....things like spending 30 minutes a day tracking time for every meeting attended against an activity/project, multiple processes taking weeks for acquiring a server, weeks spent in generating documents that are not even looked at by others, etc... hopefully that makes sense.

There is only one process in IT which I worship:

  USER      PID     COMMAND
  root      1       /sbin/init

excellent t-shirt idea

I think we need to create an approval process for processes so that we can slow down the creation of processes.

Was that comment approved????

"We should focus on what people get done, not how many hours or days are worked. Just as we don’t have a 9-5 day policy, we don’t need a vacation policy."

While I admire the sentiment, it's rather anti-family.

Can you elaborate?

That sort of policy encourages people to work very long hours to out-compete their coworkers. And don't tell me that there is no competition working for a place where adequate work is rewarded with a "generous severance package."

You pay for that sort of thing long term with burnt out employees and broken families.

Vacation and the 9 to 5 policy encourages people to compete with each other without going overboard and ruining their lives. Whether that's good or bad for you, their employer, is something that you need to consider.

We have a similar policy where I work. There are certainly people who work harder, or who take less vacation than they would like. But from what I've seen, most of these people are either workaholics, or underperformers who probably shouldn't be working here anyway. I suspect most of these people would be working long hours regardless of the work hours or vacation policy.

For the rest of us, the freedom is tremendously valuable, and we have fantastic work-life balance.

I couldn't disagree more -- what could be more pro-family than being able to come in to the office for face time 10~3, and get shit done on your own schedule?

What could be more pro-family than not having to count vacation days, being able to spend time with your kids instead of reading HN and 'looking busy' when you don't have a pile of work?

I voted this up immediately after reading the title.

Reply on news.ycombinator.com