Renewal requires opening yourself up to new ways of thinking and feeling.
― Deborah Day
In my last post in this series, I made the bold (and perhaps surprising) claim that the Business part of the software company and the Engineering part of the software company actually share the exact same objective. That objective is this:
The primary purpose of Engineering is to efficiently create valuable functionality for Customers.
The problem turns out to be that the Engineering group isn’t aware of this. More accurately, the Engineering team often believes that their objective is something completely different [1]. They might believe that their job is to use the most modern technology to address the requirements given to them by “The Business”. Or they might think their job is to create the “cleanest” code to ensure maintainability (which is to say that their code is the equivalent of art and they can look at it with pride, like a poet looking at their own poetry). They might think their job is to migrate the company’s product to “cloud” technology as rapidly as possible, whether the business folks have asked for it or not [2].
If you haven’t done so yet, please do review the Introductory Series for a full coverage of this issue. As stated there and in the previous post in this series, the objective of Engineering and, in fact, the entire company (assuming that you are a software company and not a group building software within a non-software company) is to efficiently create valuable functionality for Customers. So what do you do if the Engineers haven’t figured this out yet?
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 [3]. Start by working with Engineering leadership to convey the ideas from the Introductory Series. In the near future, I will be adding a slide deck that you can use (and modify as you see fit) to convey this message. I will also be adding some video materials to help you in your mission. Another option is simply to send them to this site to discover it for themselves. 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 is preventing 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.”. If you ask anyone who has worked with me in an Engineering role, they will tell you they have never been short of challenging work and have lots of opportunities to use state-of-the-art technologies. Choosing to make the primary focus the delivery of business functionality does not prevent innovation and the application of cool technologies. However, it is very different than focusing first on picking shiny technologies, playing with them for a while and worrying much later how they might be used to deliver on the business needs [4].
Until the 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. Try to find an insider who “gets” it and have them try to convert others. 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 on the idea and, if successful, this might be the wedge that helps you to convince the larger group. Either way, you need to do your best to get this message starting to percolate in the Engineering side of the company.
Once you have conveyed that message, even if you don’t get 100% buy-in, you need to stubbornly operate based on the principles outlined in the Introductory Series and focus on delivering valuable functionality. You need to combat efforts to build technology for technology sake. The next post will help you do just that.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] This is the subtlest of subtle Monty Python references. As a geek, I am required to inject one of these every 5,000 words or less.
[2] Technically, “The Cloud” is just someone else’s computer.
[3] Although you can’t authorize your way to a revolution, despite frequent attempts.
[4] 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).
Leave a Reply