Builders, don’t give away your power!

I went to school for mechanical engineering and started my career building physical things. Diaper machines, actually. Aside from having funny stories to tell about how diapers are made, I learned that working with hardware is, actually, hard. Reviewing a design that will turn into an order for 20 copies of 10 million dollar machines is quite stressful. Missing even the smallest mistake can trigger unexpected waste and will certainly delay delivery. I made plenty of mistakes but loved working on large and powerful machines.

Building

Building a diaper machine is the only option. The secret sauce used to assemble a diaper is in the equipment. There is no real open market to purchase an off the shelf converter. If you want to sell diapers, you’ll need to engineer and manufacture your own machines.

Diaper machine builders maximize their power. The work these engineers are doing directly aligns with the product value proposition. They are making machines that produce the best diapers in the world. They are not working on designing lift trucks, or glue melting machines, or anything that does not directly contribute to building a diaper. By “directly contribute” I mean literally touching the raw materials as they are assembled.

Lease the forklift to deliver raw materials and buy the glue melter. Design and iterate on awesome spray tips for the glue guns.

Learning

After a few years, lots of earplugs, and some world travel, I left hardware for software. The seductive nature of iterating quickly, building with new technology, and learning new languages was irresistible. Software is fun, testing is easy, and the rest. Plus, I got to learn how to use vim.

Over time, I’ve realized that software builders, however, have a challenge that hardware builders do not. I’ve failed to meet the challenge many times.

Hardware people won’t have time or budget to design an extra mold, or extra buttons, or widget that doesn’t have a place in the final design. The consequences of straying from the goal are severe, in terms of cost and time, so hardware engineers learn to stay on track. They are comfortable with maximizing the value they are producing with the time and budget they have estimated (or been given).

The multipliers are large and real. You quickly learn that asking your boss to add a million dollars to the cost of a machine because I prefer titanium over aluminum is a waste of time. But (for software people) that final refactor for the perfect abstraction feels so good!

Focus

Staying focused in software is much more difficult. Mistakes, bugs, errors, and preference based choices are generally cheap and easy to undo. The consequences of a “meh, I’ll fix it later” attitude are likely not obvious to young engineers.

As a software community, we up the difficulty of staying focused by not training developers (builders) about how to buy software! We’re great at training, coaching, and leading builders to build. We’re not so great at aligning the collective energy (humans, budget, time) with our actual goals and avoiding distractions.

Just last week, I had a call with a small startup business that wanted to talk about their data management headaches. Two people from this company joined: a business person and the lead engineer. At the start of these types of calls, I like to understand what it is the company does for their customers. In short, why do people pay you to be in business? In this case, the business person said that they analyze MRI images with an AI engine to produce more accurate diagnosis for certain body parts and conditions. That’s pretty cool and customers are paying for it.

The reason for the call, as it turns out, is that the current, homegrown data solution, won’t scale up and is hard to maintain. The AI engine works great but they can’t get the data to it fast enough. You can see where I’m headed.

The lead engineer spent the rest of the call talking about how their data pipelines work, what languages they used to build them, and how hard it was to get where they are. I listened carefully and only asked one more question: “Is your secret sauce in the AI model or in all the other stuff you’ve built?”. My call notes ended with something like:

“focused on building software not aligned with customer outcome. check-in next month to see if attitude shifts. schedule one-on-one with business.”

The lead engineer had given away all his power by growing and funding an entire team around building a data management solution instead of amplifying their really awesome image processing technology. I’m thinking they tried to design and built a forklift to drop off a pallet of raw image data. No customer is buying his (crappy) forklift. Customers want the image processing technology.

Their lead engineer doesn’t know how to ask the procurement department to lease the forklift. What would happen if all that newly freed up investment helped deliver even better image processing?

Developers, don’t give away your power. Keep your energy focused on directly achieving business goals. It’s ok to buy software. It’s especially ok to not be an expert in things you can buy. The companies you buy from are better at it than you.

You get to focus on the part of the system that customers actually pay for. What’s more powerful than that?