Are You Circumventing Change?

DZone 's Guide to

Are You Circumventing Change?

A Zone Leader talks about creative approaches that can delay or even stop change from taking place, and the net result such actions have on a project.

· Agile Zone ·
Free Resource

Learn more about developing leadership traits.

I had two part-time jobs while I attended college.  The first was in the computer lab for the College of Business Administration.  The second was working as a sound engineer at a local recording studio.  I can't stress enough how important both of these jobs were for me — providing life lessons that were on par with the lessons I learned in earning my degree.

You may also like: How to Manage Cultural Change With DevOps

This article will talk about something I learned while working as a sound engineer.

Waiting for Helen

The job of a sound engineer is really kind of exciting.  You become the conduit for getting the ideas of an artist captured in a format that can be enjoyed by advocates of the production.  While every step in the process has significant value, to those utilizing the services of a recording studio — the final mix is often viewed as the most important aspect of the project.

After all of these years, the phrase "we need to wait for Helen" is still fresh in my memory.  Who was Helen?  After all of these years, I believe she was the piano player for some of the tracks that were recorded on the project.  She was not the leader, but we had to "wait for Helen" before we could start the final mix.


Because, to her companions on the project, she had that "critical ear" that had to be present to make the project a success.

We waited for Helen to arrive, while the studio clock ticked away.  She finally got into position and listened as the final mix transpired.  In the end, I walked away from the project a bit surprised — as she rarely spoke or provided much feedback during the final mix session.

When I think of this story, I think about the number of times a much-needed change is delayed for reasons that do not provide ample merit to justify the actions.

I Wasn't Notified — So You Must Wait

Similar to waiting for Helen, an unexpected change in direction can have a similar effect.

While working on a very large project, feature teams find themselves learning more about the needs being met than the stories, use cases or even sessions which some expert can reveal.  Often times this new information will reveal needs that should be met using a process or technology that has not been discussed before.

Perhaps an example might be the justification for a serverless function that can spin up immediately, perform some action and then shut down.  The best part about this approach is that a serverless function can scale up quickly to meet bursts in demand, while not having the financial impact on standard services which are continually running.

In order to prove out a serverless approach, feature teams often attempt a proof-of-concept to make sure the realities match the expectations.  This is exactly the approach our team encountered on a project last year.

When the information was communicated in a status update, someone from another team became surprised about not being involved with the serverless direction decision — making it clear that all activity needed to stop until he was fully up to speed on the situation and approved the direction.

Our team took this approach and we were able to get everyone on the same page. The delay from forcing the team to stop their progress caused features to be delayed.  

The Impact of These Actions

With respect to the case of waiting on Helen, we could have started the final mix and saved the project money — but were forced to wait until she was sitting in the room with us.  In fact, most projects lean on the studio staff during the final mix more than members of the project providing detailed feedback.  This is similar to how touring artists rarely get involved with the sound or the mix being presented to the audience.

In the serverless example, the technical architects arrived at the decision to start a proof-of-concept, when they realized the other options were not in the best interest of the client or solution.  As part of providing thought leadership with a consultancy, there are times when decisions are made — that will be communicated once they have been validated by technical and business staff.  

To try to get buy-in from every person impacted by the decision before the proof-of-concept is finished, would actually introduce delays similar to stopping development until someone is personally satisfied with the technical design.

In the end, there is an aspect of "control" at play with these examples.  I also believe there is an aspect of trying to circumvent change as well.


As it has been written so many times before, fighting change when the change is necessary is an anti-pattern that continues to cost projects from both a financial and delivery perspective. 

The best advice I can offer, after all of the examples I have seen since the recording studio days, is to stop, take a deep breath and make an effort to focus and listen to what is really happening.  In doing so, your mind will be in a better place to accept the thought process and experience of those who are trying very hard to make the project a success.

Have a really great day!

Further Reading

How to Shift Left: Four Tips to Change Team Culture

An Agile Transformation Strategy That Actually Works: Demand Change

Seeking Lasting Change? Look Beyond the Technical Process

agile, agile adoption, change, deadlines, delay

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}