The BAD Culture: Scaling Automated Governance Chapter 1

“I quit!”

Mira was livid. Her words sent shockwaves across the room. “I can’t do this!” She slammed her laptop closed and quickly stood up. 

Mira spun around. Tears were in her eyes and she was flush with frustration. “Bryson, we talked about all of this! Everything we accomplished is unwinding. This merger just sucked the life out of all of our progress. Nothing we say goes anywhere with the new combined leadership team. I’m done hitting my head against this immovable wall.”

It was true. Not just six months ago, everyone was popping champagne bottles, celebrating the possibility of merging with the well-established and highly regarded Boston Atlantic Dividends (BAD) company. 

FIN had been courted by BAD board members and the leadership team for over a year. They were impressed with the incredible digital financial products that FIN had developed. They were rewriting the user-friendly face of finance. Boston Atlantic Dividends was desperate for a fresh new brand, and the new FIN name and industry enthusiasm would be a much-needed shot in the arm for the old firm. 

On the FIN side, the acquisition was equally attractive. They had hit a wall in their growth. They were looking for an acquisition that would allow them to expand into new global markets. Boston Atlantic Dividends offered a sure-proof way to get there with their global footprint and years of expertise managing large commercial accounts. 

The BAD leadership team was eager to adopt FIN’s more agile and high-velocity ways of working. BAD needed help, badly. Similar to FIN, they were burdened with heavy compliance requirements and audit findings. But unlike FIN, they had not adopted automated governance to remove the manual toil and labor. Instead, they had adopted complex and rigid processes to comply with security and audit requirements. Gates formed and queues of work filled up. Projects often ground to a halt, waiting on external, manual processes to be completed. 

When BAD leadership heard of FIN’s automated governance approach—and the open-source tool they used and extended to enable it—they couldn’t wait to take advantage of it. They assured FIN that they would expedite adoption and embrace the FIN culture. Sadly, those promises had fallen flat. The honeymoon ended when the BAD team had difficulty getting their automated governance tool to scale to handle their code antiquities. BAD teams became defensive and quickly pivoted to finding fault in FIN’s approach. Even worse, the BAD culture started infecting FIN teams. Pessimism and frustration began to rise.

Cora sighed so loudly that even Mira jumped. Cora caught herself and was a little embarrassed but also relieved. Mira was still in the room. “Mira, I understand what you are feeling. I feel the same, and I suspect we are all struggling to come to terms with this merger. I don’t think any of us could have predicted how far behind BAD’s technology would be.”

Cora was right. She felt as if she was reliving the early days of the governance transformation FIN experienced. Cora was not new to this game. In her twenty-three years in the financial industry managing teams of technology teams, one thing was constant: resistance to change. Early in her career, she took a hard-headed approach to dealing with naysayers. But as her career matured, she adopted a more diplomatic approach. Cora learned how to play the game by changing the rules of the game in favor of her teams. 

The early discovery meetings and presentations from the BAD technology teams had all been positive and encouraging. They used the right words and were enthusiastic about embracing FIN’s technology. But after the merger, the integration efforts revealed a completely different story. Instead of being progressive in their practices, the truth was revealed that BAD was still very traditional in their approach. Their waterfalls had waterfalls and their silos had silos. Product releases were eighteen-month-long projects plagued with operational issues, deep technical debt, and debilitating turf wars. The results were products that were decades behind the times and impossible to use. 

The FIN technical teams saw opportunities for improvement and moved in quickly to help. However, they were stunned by how rigid the BAD structures were, and their attempts to influence change were met with formidable resistance. FIN teams slowly stopped their efforts out of sheer exhaustion. As they regrouped, they were met with an offensive attack. The new BAD leadership team that had joined FIN leadership commissioned an audit to ensure the new FIN teams were “compliant” with BAD policy. Suddenly the DevOps evangelists were now on defense.

Mira was still exasperated. “Cora, this is about more than just the technology at this point. How are we supposed to work together on a solution if half of the team doesn’t value collaboration?”

A few of the executives who came from BAD shifted in their chairs. Some were clearly offended by Mira’s claims, while others seemed personally hurt. After an uncomfortable pause, one of them spoke up. 

“Doesn’t value collaboration? What do you mean?” Priya asked.

Mira was eager to elaborate. “In the first few weeks after the BAD execs joined the FIN senior leadership team, just when we were beginning to make some technical progress, they started imposing all these new rules on the engineers. All of a sudden, we weren’t allowed to talk to each other outside of specified times. Now every conversation has to be booked on a calendar. We can’t schedule anything on the designated no-meeting days on Wednesdays or Fridays. Developers can’t be invited to meetings before 10 a.m. or after 3 p.m. or at lunchtime. It’s ridiculous! They expect my team to sit at their desks silently all day with their heads down delivering lines of code like robots!” At this point, she knew she was only fueling the fire of the tense “us vs. them” mentality in the room, but it felt good to vent.

Doug, a notoriously ornery senior engineering manager from BAD, leaned back in his chair. He’d had enough of Mira’s ranting. “I’m sure your team benefited from the additional structure,” he scoffed. “When we first moved into your offices, I constantly heard you all chatting and making tons of noise across the floor. It seemed like everyone was always goofing off and never getting any actual work done!”

“Goofing off? Those conversations you heard were our collaborative brainstorming sessions and ensemble programming time,” Mira snapped back. “My team is used to ad hoc collaboration. It helps keep us moving when we get stuck and makes us better at solving problems. When we were told we couldn’t do that anymore, our progress slowed significantly!”

It was true that the FIN teams were working in an open-office environment, and the engineers rarely held structured meetings. Whenever someone felt stumped trying to solve a problem, they would just turn their chair around and shout out for assistance from anyone who might be available. This approach had always been effective for them before. Now, most of Mira’s team complained that the new meeting rules from BAD felt stiff and unnatural.

Doug had his own list of grievances. His managers who had recently moved onto the floor from BAD had lobbied complaints against Mira and her team to the executives, citing their lack of focus and constant chatter, which only subjected them to more scrutiny from the higher-ups.

Priya hadn’t wanted things to escalate to this point when she’d asked her question, so she tried to defuse the situation. “I think there is a real misunderstanding here. Those rules for limiting meeting times weren’t meant as a retaliation or punishment for Mira’s team being chatty,” she explained. “All of our teams have been following those guidelines for months. It was part of an action planning session we did last year when we collected feedback from our engineering teams. BAD’s developers told us they were spending way too much time in meetings and never had enough uninterrupted hands-on-keyboard time to focus. These new guidelines have really helped them! We’ve received tons of positive feedback from devs ever since we made those changes.”

“I’ve always empowered my team to decline or reschedule meetings that are getting in the way of deadlines,” Mira continued, indignant. “For example, our ensemble programming sessions are always optional, but most of our engineers find them so valuable that we almost always have our whole team participating. Even our project manager enjoyed attending sometimes—that is, until we had to cancel those sessions because we couldn’t fit them into the approved meeting time windows. And besides, hands-on-keyboard time has never been a problem for us. It doesn’t matter how much more time you give us at our desks; more than half of our open development tickets are impeded waiting on other teams that we depend on. BAD teams!”

“Of course she’s blaming us.” Doug rolled his eyes. “Well, if you’re waiting on my team to get work done, abolishing our no-meeting blocks isn’t going to make things go any faster. That will only slow us down more!”

Doug had a point. His team’s ever-growing backlog had only gotten worse after BAD had merged with FIN. Now, more teams were depending on them than ever before, and his engineers were working as hard as they could to fulfill requests. Their turnaround time was a bit higher than it had been a few months ago, sure, but it was still much better than it had been before the no-meeting blocks were introduced.

“The meeting-free blocks are important for teams across the company and have a largely positive impact, as Doug can attest,” Priya tried to mediate. “The entire extended FIN leadership team agreed to roll them out after seeing the feedback we’d gathered from BAD. However, I do understand your frustration, Mira. As long as your team is respectful of those constraints when scheduling meetings with folks from outside of your team, you’re welcome to use the focus blocks for collaboration sessions. I think we can all agree that you should have the autonomy to establish those kinds of team-level norms. Just make sure those meetings remain optional so that anyone on your team who would prefer the independent hands-on-keyboard time can take it. Does that sound like a fair approach?”

“I . . . I think that might actually work,” Mira replied tentatively, as she started to walk back to her chair. “I’m not sure, but I’m willing to give it a shot.”

Cora sighed again as Mira sat back down, but this time she expressed a small sense of relief. They were getting somewhere.

Actionable Guidance

Establish a foundation of trust and good rapport within a team rather than trying to push through friction to find a solution.

Establish ground rules such that participants in a working session acknowledge and agree that everyone involved is operating with the best intentions toward the goal of success.

Stay tuned for the next exciting chapter…

- About The Authors

Jason Cox

Jason Cox is a champion of DevOps practices, promoting new technologies and better ways of working. His goal is to help businsses and organizations deliver more value, inspiration and experiences to our diverse human family across the globe better, faster, safer, and happier. He currently leads SRE teams at Disney and is the coauthor of the book Investments Unlimited. He resides in Los Angeles with his wife and their children.

Follow Jason on Social Media

• 
• 

Sean D. Mack

Christina Yakomin

Senior Cloud Architect at Vanguard

Brian Scott

Brian Scott is a seasoned technologist with over 25 years of experience in DevOps, SRE, and managing technical operations at scale in Cloud & Infrastructure. His career includes impactful roles at MySpace, OpenTable, and The Walt Disney Company. Currently, as a Principal Architect at Adobe, Brian supports engineering teams with technology, cloud, and AI governance and adoption while assisting senior leadership in solving enterprise-wide challenges and breaking down technical barriers.

John Willis

John Willis has worked in the IT management industry for more than 35 years and is a prolific author, including "Deming's Journey to Profound Knowledge" and "The DevOps Handbook." He is researching DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Previously he was an Evangelist at Docker Inc., VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell), and VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.

Follow John on Social Media

• 
•