Secrets of the Cat Herder – Part I

How to be in control of the Development Team that your project depends upon

“Control your own destiny or someone else will.”
– Jack Welch

If you’ve spent any time as a Product Manager, Business Analyst or Product Owner, I’m certain that you have experienced frustration dealing with an Engineering team. I am here from “the other side” to help. I have spent the majority of my career on the technical side of software development, but also a significant portion in “business” roles such as Product Management. The purpose of this article is to let you in on the secrets I have learned from being on both sides; these secrets will help you assert control over your projects.

First, I should say that we1 don’t really mean to be frustrating – as a rule, we are trying to the best of our abilities to achieve what we believe to be the objective of our department. The problem is that we often have a different objective than you do. What is the Engineering team’s objective? Like the blind men and the elephant, you will almost certainly get different views on the topic from each Engineer.

As a business person, you might surmise that it is something like “spend a lot of time using cool new technologies to create a small amount of business functionality while staying gleefully unaware of business pressures”. Trust me, that’s not what any of us would write down.

Here’s the good news: the actual objective of Engineering is the exact same as what I assume yours to be: to efficiently (i.e., rapidly and cost-effectively) deliver valuable business functionality for Customers. How can I be so certain?

The essence of my analysis is based on the fact that the Engineering team must share the same objective as the overall company, which for most for-profit companies is to maximize profitability (although if the company is publicly-traded, it is more accurate to say “increase shareholder value”). To skip a few steps in the reasoning and cut to the chase, this is normally done by maximizing the valuable functionality delivered to the Customer; to restate for effect:

The primary purpose of Engineering is to efficiently create valuable functionality for Customers2.

Although they both might assume otherwise, you can see that the business people and the technical people share the same objective. So what’s the problem?3 The chief problem is that the Engineering team doesn’t know this yet.

Notice that the objective stated above doesn’t say anything about architecture, frameworks, languages, coding standards, testing approaches, etc. These are the things that Engineers love to focus their time on and things that the outside world assumes to be their primary objective. It’s not to say that these things are not important, but they are only important in so much as they help achieve the overall (and really, only) objective which is to provide value. A corollary of the above objective is the following:


The only Engineering activities that are worthwhile are those that lead to delivering value to the Customer.

I often talk about something I call the “Customer Membrane” – it’s the surface area where we exchange things with the Customer, such as the software we deliver, designs, requirements, feedback and usually some form of payment for the value that it is delivered. The Customer Membrane looks something like:

ricker 08242018aI propose that if something isn’t visible in the exchange at the Customer Membrane, then that “thing” is not particularly important. For example, if the team has decided to use an obscure programming language in the back-end of their cloud-based solution, this doesn’t matter to the Customer. So let me repeat this in bold print for emphasis:

The most important Engineering work is that which is obvious across the Customer Membrane.

You can use this fact to help keep the project team focused on those tasks that make a difference and not those that are really interesting to the Engineers, but not valuable to your Customer.

So how do you help the Engineers figure this out? I am a big believer that revolutions start in one of two ways – from the top down or from the bottom up. I suggest starting with the former since people at the top generally have the authority to start a revolution.4 Start by working with Engineering leadership to convey the above ideas (I will provide more supporting materials in the next article). Engineers are very logical and my experience is that when these ideas are explained clearly, it makes sense to them. At first, it goes against their natural instincts, but with repetition, the passage of time, some successes and the realization that they can still do great and interesting Engineering work, they will come around. I promise.

One of the most common objections to the message is that it prevents Engineering from doing “their thing”. Because they hear words like “value” and “functionality” and “Customers” and not a single technical term, they assume that there is no place for technology. One key thing that I’m not saying in this definition is this: “Engineering can no longer use new, interesting technologies and do challenging, innovative work.” Choosing to make the delivery of business functionality the primary focus does not prevent innovation and the application of cool technologies. However, it is very different than focusing first on picking shiny technologies and worrying later how they might be used to deliver on the business needs.5

Until Engineering leadership buys into the fact that their only objective is to efficiently deliver valuable functionality, it will be difficult for you to progress. Therefore, I encourage you to be persistent in delivering this message. If you can’t get support from the leadership, then go to Plan B, which is the grassroots Revolution. Try instead delivering the message only to the Engineering team working directly on your project. It’s a smaller group to sell the idea to and, if successful, they might be the wedge that helps you to convince the larger group. Either way, you need to do your best to get this message to percolating in the Engineering side of the company.

I’ll continue this discussion in my next article here, but in the meantime, I invite you to take a tour through my blog site at de-engineering – it covers the above concepts in more detail.

1 I normally self-identify as a techie.
2 Keeping in mind that the “Customer” can be an internal one.
3 Because there definitely is a problem!
4 Although you can’t authorize your way to a revolution, despite frequent attempts.
5 I suspect that many of you can identify with this type of environment. What you don’t realize as business people is that new technology is like catnip to us Engineers. When you don’t control the infusion of new technology, you create one of those crazy cat playgrounds where disorder rules supreme. The phrase “herding cats” did not get invented by accident (by the way, the original video that spawned the phrase can be seen here).