Hands Off! How to Release Product Faster

What are the three biggest impediments, or roadblocks, to fast product cycles, especially in the cloud?

1. Incomplete Testing. If you are not 100% confident that your testing covers every known use case, you will be fearful of releasing. Actually, fear of the risk of deployment often is the "canary in the coal mine" sign that your testing is incomplete. The other sign is infrequent releases, defined in the Internet era as less frequently than every few days.
2. Manual Testing: If you cannot push a button - or better yet, without pushing a button at all - get a complete test run, then testing will take human involvement, which is expensive, but also will take time. Worse, your engineers, the people making the actual changes, cannot get quick feedback.
3. Hands On: Who has to sign off on each change? How many people does it have to go through?

In this article, we will explore the phenomenon of "Hands-On". It is not quite micro-management, as much as micro-architecting. (disclaimer:

Does the following sound familiar?

1. Smart engineer comes up with an idea to improve your product. The improvement is relatively narrowly defined. It only affects the part of the product she is working on, or perhaps only one other area.
2. Engineer is excited, since what makes engineers happy is building new things and making existing things better.
3. Engineer plans out, begins implementation. If it affects one other part of the product, she coordinates with the engineer working on the other part.
4. Engineer even discusses it in the hallway with chief architect, who thinks it is a pretty good idea, or at least is neutral, sees no major issues.
5. VP or Director finds out about change, gets upset about not being "in the loop", and the idea is quashed. Engineer is beaten down.
6. Next good idea engineer has is left behind, unless it is big enough to make it worth the overhead of discussing with Director, having a "planning meeting", and "scheduling it into the product."

I have seen this in many companies, even those with pretty good management, but especially in companies in which key executives come from large company on-premise software firms.

What is the problem with this scenario?

Peter Druker defines knowledge workers as those with a large amount of independence. If I am a manager or engineer, I have a large amount of independence to make decisions and implement changes. You can tell me to do it or not, but you cannot stop me short of removing me from my role. Just like the state's power to enforce laws ultimately rests on its exclusive access to force - you cannot stop a determined jaywalker or thief or murderer unless you have a willingness and an ability to use force - so your ability to manage a determined engineer ultimately rests on your ability to terminate him or her.

Engineers love that independence; they live for it. They take pride in small improvements and great pride in great improvements. Since great improvements are relatively infrequent, it is the small, "look what I just did", changes that provide the emotional fuel for engineers.

Fortunately, it rarely is the great improvements that make material differences in company, but rather most often it is the accumulation of those small changes. However, quashing small changes - micro-architecting - acts like a shipping container hanging from the tail of an F-35: don't expect to reach Mach 1 with that kind of serious drag.

Since many Directors and VPs of engineering often are engineers themselves, what is it that causes them to engage in practices that they (should) know leads to slower development cycles, higher costs and disheartened engineers?

There are three key reasons:

1. Many Directors and VPs of engineering actually are not former engineers, but rather former project managers. Unfortunately, few project managers are good project managers. Instead they are people who are used to tracking activities in Microsoft Project or Excel, and compensated on the detail of their tracking. Negative incentives and lack of understanding create the project manager vs engineer tension that is exacerbated when a project manager who never really got engineering becomes a senior engineering manager.
2. The very detail-oriented mindset and skills that enabled an engineer to find and make those small, but cumulatively valuable, changes are the very skills that hinder a senior engineering manager. This is not unique to engineers, although it is particularly common. Indeed, business schools were invented to help engineers become good general managers.
3. Many senior technology executives in cloud companies - which really are services companies - have their backgrounds in software, i.e. product, companies. The services mindset requires constant interaction with customers, constant on-the-spot improvement, constant responsible decision-making. Engineering for services requires the same mindset. It is a difficult shift that few executives successfully make.

How do you tell if you are hindered by micro-architecting or even micro-management?

Find a small change you have wanted to make for a while, one that affects but a small area of your product. Better yet, find a problem affecting that one area of your product and find the solution. Work with the 1-2 engineers impacted, and find a small, simple, elegant solution.

Now ask them to implement it as soon as possible. Their answer will be one of the following:

• "I would love to, but I have no time; I simply am too busy." This is a sign of either weak engineers - good engineers love fitting in small changes that make everything better - or weak testing, since even a small change takes too much effort (labour time, not necessarily calendar time) to validate. See our article on automated testing.
• "Sure, consider it done." You are in great shape.
• "I think it is great, but I need to get sign-off from the Director/VP, and we need to schedule it in, and figure out which product release." This is a flashing red light.

If your manager/executive is too hands on, not only will it take much longer to get things approved, but more importantly, people will feel, why bother, since they always have to satisfy that one person. You will lose the independent and smart engineers' drive to innovate.

On the other hand, do you not need to track what engineers do, give them direction? Sure you do. Give them overall direction, but give them room to grow.

Where have I seen this? I see some degree of it at almost every company, because it just is human nature. Remember, though, that most of the time it is not the sign of a bad manager, just part of the growth process of companies and executives. Fortunately, I have not had a bad case in several years.

Summary

If your people cannot independently find, test and implement small improvement in your product, you never can expect to move at the speed of an F-35. Somewhere out there, some competitor is working with independently-motivated engineers who are making changes. They are looking at you like a nice, fat juicy hamburger lunch.

When you are ready to turn around and eat your competitors for breakfast, lunch and dinner, call us.