Release Is Both a Noun and a Verb

Recently, I attended a well run gathering of Banking and Finance technology professionals at Charlotte’s Packard Place incubator. PayCLT is a great organization which has a mission of bolstering the network and knowledge of Charlotte’s payments technology professional community and they’ve been doing it well for over five years.

The speaker for this session was Doug Hartsema, a founding partner of The Hartsema Group, a small consulting company that specializes in formulating customer advisory councils for large financial customers, such as commercial banks. These commercial customers have an ingrained business interest and are usually CFOs or payment executives from medium-size through large corporate customers. They rely on the banks for business to business payments, treasury services, and other wholesale banking processes that are critical to their daily operations.

In order to drive the discussion, Doug brought some interesting quotes and anecdotes from these sessions that will probably ring true to many banking and finance technology professionals:

“The implementation of the change seems more important than the change itself.”

“Easy gets done. Hard gets deferred.”

“Please don’t ever make me tell you your systems are down.”

My personal favorite, “Banks think implementation is complete when the service is set up. The implementation isn’t complete until I’ve received the value of the service.”

With the current book on my nightstand, “Project to Product” by Mik Kirsten, this quote also reminds me of something that roots back to the Banking industries over-reliance on the project management methodology and heavily siloed organizations, “Don’t confuse the fact that the word release is both a noun and a verb.”

Next to keeping production systems operating, managed IT change is ever present in corporate IT. In their daily activities, technology teams rally around and obsess over the activities, budgets, and risks related to planned technology change (and the hue of red, yellow, or green associated). These planned IT changes are managed like a project with start and end dates, people and technology resources, managed risks, an allocated budget, and perhaps most detrimentally, a stringent change control process. IT teams often wholly focus on the visible details that seem to indicate readiness for production traffic, while often completely losing sight of the business value contained within the features that make up the release itself. IT teams are obsessed with the verb-ness of a software release, and completely miss what matters to customers, the value within that collection of features and fixes making up the release. This is the noun-ness of the word release, and contains the important business value that should directly correlate to your teams reason for existence.

Overly siloed organizations, such as release management or infrastructure teams, often have no visibility or appreciation for the actual collection of features in the release. These features are designed to better serve internal employees or external customers, and it requires empathy to ensure this business value is understood. Focus on the business value of the product must be present in all work surrounding this change. There is a lack of awareness for the noun-ness of the release, the collection of valuable features meant to serve internal and external customers by solving a business problem, or improving a business process.

I’m reminded of the famous Winston Churchill quote, “Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.”

Here are 3 ways in which enterprise IT leaders can counter this pernicious phenomena:

Organize

Organized teams more tightly around the technology products they support, as is the core tenet of Dr. Kersten’s book, “Project to Product.” Use the tools of physical proximity, daily routines, and organizational hierarchy to enforce the product mindset.

Teams that sit together, work together, and play together share goals and team culture. Use the tool of physical proximity, which in some organizations can more quickly and easily be manipulated, to support your goals. If you have a critical team member that’s contributing a majority of their time each day to your product, insist they be seated near the product/feature teams. The closer the better, within space constraints. If it’s not at the same table, place them in a nearby room or floor. If not in the same building or city, at least get them in the same time zone!

Daily activities such as daily scrums, or other routines like staff meetings help form habits and build a positive culture. Individuals witnessing their teammates taking accountability to get work done on time and with quality build strong teams. If teams are not physically working together, if they rely on a virtual structure, or if they are not in the same organizational structure, you can use the tool of routines to help build a culture of accountability. Insist that team members critical to the end-to-end delivery of your technology product be present and engaged in these routines. As a leader, ensure you are regularly participating in these routines to enforce their importance and effectiveness.

For more virtualized teams, or those that may be reluctant to participating in routines, the reporting structure becomes critical. For team members contributing to your product, carefully consider who is setting day-to-day direction and defining team culture. The larger and more siloed the enterprise, the more challenging this may prove, but do not underestimate the value. Yes, release (verb) activities, risks, and budgets should be controlled with something that looks like a project, but it must be based on the foundation of the business value contained within your technology product.

Not every role type will benefit from this type of organization, but anyone who has the majority of their daily tasks supporting your products change activity deserve to be with (physically, virtually, or organizationally) team members rallied around the same business problem. Without this organization, overly siloed and specialized teams may benefit from a specialization of labor, but suffer from a lack of awareness of real business problems and mission.

Reward

Reward team members based on business results. Individual formal performance goals, regular coaching sessions, and incentive compensation must be tied to business results and need frequent reinforcement. For internal systems this may prove challenging, but seek a proxy metric that relates to revenue or cost. Ensure your team is rooted in this business value and maintains empathy for their users. As a leader, you must gear the foundation of your team to the value in your technology product and the changes and improvements contained within the software release(noun). When system change happens, it doesn’t end with the first customer transaction; as a leader, monitor the business results produced by your release (noun), and share them with your team constantly.

Rewarding and encouraging is a desirable leadership behavior, but it’s not terribly measurable beyond the binary fact of whether a manager exhibits these behaviors or not. For a much more scientific approach to measuring business value focus, see chapter 9 of “Project to Product.” This seminal work on transitioning enterprises to a product mindset clearly documents the different aspect of measuring the effectiveness of an organization’s focus on product-based value stream delivery.

Shout

Shout your business purpose from the rooftop, and radiate this mission to everyone touched by your team, even those not engaged on a daily basis. Promote internal usage of your software by your team and their friends and family if possible. Dog-fooding can be a great way to build empathy, and get quality feedback from those closest to the inner-workings of your product. Explain and share the business purpose of your technology product in multiple settings including staff meetings, town-halls, digital communication, or other opportunities to communicate widely with those supporting your team or even broadly within your enterprise. A network engineer who is physically and organizationally distant from your team deserves to appreciate the business problem they are helping to solve by enabling packets carrying your customer traffic.

I suspect you will find, as I have, that this focus on business value will lead to higher functioning teams. It will also make your team and your company a better and more desirable place to work as measured by employee net-promoter-score. Seeing teammates high-five not just when software goes out the door, but a few weeks later when the business results are made clear, may prove to be one of the most rewarding things you do. I know it was for me.