Continuing the thoughts from our piece from last week, we want to dig a little bit into the ways in which companies move from blind faith that a product can work to a more action-oriented approach. Building a product in technology is full of complexity and dependencies, which taken in aggregate can be far greater than any individual can fully grasp. This is true in many areas of engineering, but I think that advanced hardware and software products represent the frontier of human productivity, meriting greater attention.

Imagine the manager of a technology product, hardware or software. The product will take at least two years to complete to plan. For hardware that may mean two years before production can begin, for software that may mean two years before the product has all the features needed to be fully competitive, or it may mean two years before release to customers.

In the very early stages, this product can have some person planning it out at a very high level – an architect or senior manager. However, beyond some point, that master builder has to cede control at let the workers work. As the product progresses, course corrections become much harder. And since this product is at the cutting edge of capabilities, the leader has to make some ‘estimates’ (aka guesses) about what the team will be capable of. And not just the internal team, but outside partners as well. The product itself will have hundreds, or thousands, or modules. And these will all have their own set of dependencies. While modern engineering has made considerable progress in moving away from inflexible development models, the reality is that small changes at a low level can have an impact throughout the entire system. A delay in one part can stall, or even defeat other areas.

The people designing and managing the system need some framework for monitoring progress, gathering feedback and tackling problems as they arise. Here are a few such tools:

• A flexible approach to development. The software world has made much of its move away from ‘waterfall’ engineering towards ‘agile’ methods. The idea being that development should be iterative rather than a linear progression. In theory, this allows for changes and corrections. This helps, but the reality is that in many cases, no one at the start of the process can guarantee that the end product performs to expectations. To make interesting progress, there has to be some risk in the system, which limits the ability for agile changes in a product.
• Consensus planning. As much as we all hate design by committee in theory, in practice the best move is to gather as much input as possible as early as possible. Have meetings that dig several layers deep into the hierarchy, with every sub-group represented. The master builder lays out the plan, and then each constituency weighs in on their area. This surfaces areas of contention early in the process. Ultimately, it probably still makes sense to have one person make the final decisions, but then this person serves more as judge or referee than all-knowing prophet.
• Feed back loops that work. As noted in the last piece, on of the big problems for Tech managers is getting ground level truth, especially when that involves bad news. People working at the coal seam need to have no fear about raising problems and issues. There are many ways to achieve this. This can include regular update meetings (and who doesn’t love update meetings?); formal tracking systems; management teams that ‘walk the floor’ regularly. But ultimately the best way to achieve this is….
• Culture, culture, culture. People doing the actual day to day work need to be able communicate freely and the best way to ensure that is for them to work in a culture that encourages this. There is an ocean of literature on this subject, and building it is never easy. The trouble is that there needs to be a balance between fear and flexiblity. The manager who relies solely on fear and criticism will at some point get blindsided by some problem everyone was afraid to tell him about. The manager who relies solely on trusting employees to do the right thing will deliver a partial product, late.

What all of these have in common is the power of responsibility. The word ’empowered’ gets bandied about so much that it has lost most meaning. But if we had to sum up our philosophy of modern management techniques it would be give as much responsibility to people on the front lines as possible, give them awareness of the whole project and let them make their decisions with as little input required from above as possible. This is radically different from the command economy models that drive most management hieracrchies. The role of the manager should be not deciding every last detail, instead management needs to monitor, judge, communicate and coordinate. Of course, this turns out to be a lot more work than just bossing everyone around. But faith alone will not deliver products, that requires works.