It’s about trust and communication: How my company moved past gridlock to embrace change

By Earl M. Furfine

Earl Furfine

There is a very interesting culture clash occurring in IT. On one hand, there is the old school, “Waterfall” approach to IT: Do the work that needs to be done and “pay your dues.” On the other, there is Agile, where feelings matter and inclusion in decision making is critical.

I grew up on the Waterfall approach to technology, but have since embraced the Agile method of development. In implementing Agile at my company, I struggled to have my younger staff understand that while the methodology reduces the amount of upfront planning needed on the whole, it does not mean that you don’t plan. I also struggled with having my more senior staff embrace the fact that you don’t need to figure absolutely everything out — it is OK to move forward with as much information as you have.

What I saw happening during my company’s transition to Agile was unexpected. I had expected the leadership to spend the time to learn and embrace the new way of doing things. I had expected the staff who knew Agile to “manage upward” and help teach the senior staff how things can move forward without using the exact method they were familiar with. What I had hoped for was a veritable merging of old and new. A great new world of “we can all work on this together and find a way forward.” What happened was complete gridlock. It progressed into hurt feelings, bruised egos, finger pointing and blame. So, what happened?

Wanted: A new kind of manager

Today’s technology manager needs to be functionally strong, technically proficient and socially adept. We had very strong functional experts who did not understand or embrace the new technical way of doing things. We had individuals strong in project management. We had individuals outstanding in technical design, problem solving and development who did not understand the functional requirements and had to accept they needed direct guidance.

What we were lacking was someone who understood functionally what the goal of the Agile system was, had the leadership qualities to allow the staff to determine how it should be done — with the understanding that Agile allows errors to be made and corrected early on — and was adept enough to communicate frequently, clearly, concisely and kindly.

So how did this problem get resolved?

First, we brought in a project manager who could bridge the gap between functional knowledge and the technical approach. This was the greatest gap we had to address, and we saw results immediately. Second, we brought in a senior executive to help coach both the technical leads and the executives on more effective ways of communication. The technical leads need a voice, and the functional experts need a conduit to teach the other team members, not just to dictate. Third, we adjusted some individuals so that they could capitalize on their strengths and get their weaknesses supported. Lastly, we began including the customer in the planning process even more so than before. This gave customers ownership, as well as an understanding of why things sometimes take longer than anticipated.

What became most apparent is that delegation, small teams, trust building and communication are the cornerstones of any successful project.

Earl M. Furfine, CPA, PMP, CITP is an endurance racer, serial entrepreneur and IT professional. He speaks on a variety of program management efficiency topics as well as the connection between endurance racing and large-scale IT program management. Contact us at

Leave a Reply