Systems Produce As Designed! Part Deux

I’ve had a few people reach out for conversation from an older post Systems Produce As Designed and this is the follow up post that was requested. Before we start, thank you to you all who did reach out to discuss as it was really fun conversation!

Pulling on the thread from the Systems Produce As Designed post. Here is the main example we used provided by Ben from HiredThought.

In that post, I shared a bunch of the different approaches people had for solving the above problem that were all quite interesting. Most people liked Option 2 below. And I understand why. But as I touched on briefly in the last post, it has some issues. More on that in a minute.

The one I eventually liked after thinking through it was Option 1.

But not the way it is laid out. Option 1 and Option 2 both have the same problem. They make the assumption that all 5 projects must be done. And that all of the features in all 5 projects must be done and are accurate. I did talk about this in the last post. Now that we are caught up, let me expand on this.

If we took the approach of completing a little bit of each project/product each week and then asked questions.

• What do we keep?
• What do we trash?
• Is there something new we learned we should focus on?
• Should we invest another week in all of these?
• Is something actually done?
• Did something grow?

Depending on how you answer those questions, and probably more, you may end up with only 3 products or projects to complete.

Or it could turn into this with somethings done, somethings canceled, something grew.

Or check out all the learning we had. And all of the potential dysfunction in our system we discovered.

When we take the approach of a little of each product, project, idea, risk or assumption. Then doing a little bit of it and looking at what we have. We increase our ability to steer towards what we really need. The organization as a whole needs to change to allow for this benefit.

We no longer can say:

“Here are all of the projects or products you must build. We spent the last 3 months or so coming up with how it should look and behave. Here is the allocated funds for all of them, and here is your deadline. Now go deliver faster.”

Only to find out in the end that we didn’t need ~80% of what was demanded and the corners that we cut to make the deadline cause the product to, for lack of a better term, suck. And be loathed by our customers and users. But hey, we made the deadline right?

Working with agility, and providing the ability to steer, demands that you trust the brilliant people that you bring into the organization to discover, create, deliver and gather feedback on the solutions to your customers and users problems. Predetermining what must be done, how it must look and feel, who is going to do what and scattering the work across your divisional silos, with or without the support of frameworks, is going to lead to an unhappy place for all involved.