Distributed Engineering – A Proposal

By nature, I’m a rather social individual.  Perhaps not on a face to face basis all the time but I definitely recognize the fact that I’m a single person trying to solve the world’s problems.  Pardon the analogy, but being a gamer as well, I can see that it takes 25 people and concentrated effort to accomplish goals in World of Warcraft.  That same analogy needs to be applied to Engineering and Policy development.

Current State – It takes one person to design a house and 100 people to build it.

The problem with this statement is that the weakness is not in the 100 people who build an item but in the person who designed it.  A good analogy is when you buy a new house from a company.  They have designed it with certain features in mind and they take the common denominator.  If you want your bathtub on the other side of the wall, they need to redraw everything and charge you 4x the price of the tub.  Not too logical.

Future State – It takes 1person to design, 100 people to modify and 100 people to build.

Now I bet you’re thinking this process takes longer.  In truth the extra time is on the middle man and you definitely need some constraints, otherwise the last 100 will have to learn new skill sets.  So here’s the plan.

  • Design a platform.  Using the house analogy, build your walls, windows and doors.
  • Design components.  Like lego blocks, all components (sinks for example) fit into pre-defined criteria; size being the major factor. Rooms are components.
  • Baseline the installation cost per component (TIME).
  • Associate a COST to each component.  No brainer here.  A sink is a sink but a marble sink is not an aluminum sink.
  • Associate a COMPLEXITY cost.  This is a little harder.  It should be a percentage of total cost.
  • Make the information available to buyers.  This information is hidden from buyers currently.  Sure, you can swap carpet for hardwood but you won’t know the cost until you’re already buying the house.  Clients want to mix and match.
  • Make client templates available for other clients.  Wouldn’t this be great?  You wouldn’t need to spend hours tinkering around.  You could take a look at what other people have done and see if it fits your needs.  This is also currently hidden.

A good example of a successful business model is car manufacturer websites.  You can customize from A to Z online and know going in to the vendor what the cost will be.  Our parents here the old tagline, “You can have it in any color you want, as long as it’s black”.  This is simply not an acceptable answer in today’s world.

Makes sense so far doesn’t it?  Now why don’t we apply the same set of rules to engineering and policy.  Instead of having one person decide on what’s best for everyone, let’s have a focal point.  Initiate discussions with clients to get a few ideas on what’s needed for change.

Example, a local printer policy.  Open the floor for opinions.  Some people will want everyone to have one, others think it’s a waste.  The middle layer will need to coordinate with the operations layer to get some numbers as well.   Let’s get some numbers going first; these are approximations.  A local printer costs 200$ to buy.  It costs about 500$ in anual support and is on a 1 to one basis.  A network printer costs about 2000$ to buy.  It costs about 3000$ in annual support and will support a group of people.

So, let’s look at some numbers for a group of 5000 people with a 4 year lifecycle, on a yearly basis

Everyone has a local printer:  Lifecycle cost = 250,000.  Support Cost = 2,500,000

No one has a local printer, network printer supports 50 people: Lifecycle cost = 50,000.  Support Cost = 300,000.

Both are extreme cases but you’re looking at 2.75 million vs 0.35 million dollars, almost 8x less money.  Remember, it’s not support who’s paying for this, it’s the clients.

Fine, so now we have numbers.  Let’s share those numbers with the clients.  Have your engineer moderate and channel the ideas.  Let them come up with a plan where a middle ground can be found.  If the community comes up with a final number where they are ready to accept the cost, then that’s the policy.  Bring it to the people who stamp decisions with the background that process provided.  In the end, your engineer had a role shaping the decision, crossing the Ts and dotting the Is, but it’s the group of people who came up with a decision and they are empowered.

That’s my goal for the next 12 months.  Empower everyone to be involved in decisions that affect everyone.