If you've been following The Adventures of Blink this summer, you've likely noticed a pattern developing as we approach Season 6. The past few posts have explored a deep organizational disconnect that plagues many businesses: namely, that Compliance and Governance is completely divorced from Engineering teams.
One of the core causes of this schism is that the two sides interpret things differently. Additionally, neither side has solid communications with the other, so the perspectives are never shared, except under duress.
I've seen this firsthand: someone from Ops shows up at a developer forum and proudly announces that "we've solved the entirety of Change Management": all developers just have to fill out these 3 forms every time they want to go to production, and attend the CAB meeting a week beforehand. Piece of cake, right? How awesome is that!
...The developers declare war. The "roundtable session" very nearly comes to physical blows.
Afterward, when the two sides have been broken up and returned to their own spaces, the conversation goes something like this:
Unison: "Can you believe those idiots?"
Dev: "It's like their goal is to ensure that nothing goes to Production, ever again!"
Ops: "How could they be so unreasonable about The Process? Those divas..."
Unison: "We're just trying to protect the company..."
These Parallel Conversations Show Us There's Hope
Notice the final line: Both sides want the same thing. They have aligned their goals, but not their methods... so half the battle is already won!
So... what's left to fix?
The Remaining Problem
- Both teams want their organization to be successful (we all like getting paid!)
- Both teams know that chaos in software engineering is a Bad Thing®. (Except for Chaos Monkeys, but... that's a blog post for another day! 😏)
- Both teams know that auditors want to see a Process that is defined and followed.
- (This may surprise you, but...) Neither team wants to sidestep the process.
The disconnect that needs to be solved comes down to Interpretation.
Audit Controls Are Always Up For Interpretation
Developers are used to things being airtight. We get requirements from our customer, spelled out with specifics. Our User Stories have Acceptance Criteria, and can't be closed until we meet them. Most of our life is spent dealing with the deterministic.
Audit Controls, though? They're written with a little vagueness. This is necessary because they have to be applied by many organizations with different tech stacks and different team structures. The statements made in the control are therefore generic, purposefully.
And that's the first place that the conversation falls apart
Governance teams (whose hands are probably "clean", technologically speaking) pore over these controls and craft an interpretation based on their knowledge, skills, and experience. But that knowledge, skills, and experience doesn't actually contain software development work... and the interpretation they create doesn't include optimizations for that world.
Developer teams, who have historically avoided compliance work because it wasn't directly tied to customer feature requests, feel ambushed when the Governance team shows up with their interpretation. Maybe they were asked to participate long, long ago and ignored it. Maybe they weren't asked. It's hard to say what happened, specifically- but either way, an interpretation of the Law shows up on the doorstep, already approved and rubber-stamped and implemented. But because it was created without developer context, it's clunky. It doesn't fit with their workflow. It creates friction for developers.
If it wasn't patently obvious, the real solution here is Collaborative Interpretation... both sides work together to map out the interpretation of the Law so that we can move forward. But... we gotta figure out how to do that without throwing fists.
Secret Sauce: Play to the Strengths
Governance is good at the "What". They can dissect the controls and get to the heart of what's important in them.
Development is good at the "How". They were born to innovate technical automation solutions to all sorts of mundane tasks.
So that's the trick: let the Governance side of the house figure out the intent of the controls, and work on communicating that to the Dev teams. Then watch as the Developer Magic figures out how to do that with automation.
In short? Audit controls aren't a mandate to be handed down to the Engineering org. They're a puzzle that we have to solve together!
It's going to take Trust
You've got two departments who speak different languages. Bridging this gap is going to require to you extend some trust to each other:
Devs need to understand that Governance is fighting for them. These folks sit with annoying, pedantic, humorless auditors so you don't have to. Show them a little gratitude... and in particular, arm them with the information it takes to be successful.
Governance needs to understand that Devs crave efficiency. Developers are used to creating efficient solutions to complex problems. Let them show you how to make the entire audit prep automatic... and continuous. Teach them the intent and extend a little trust, and they'll exceed your expectations.
Some Ground Rules for Teamwork
If your solution for a control involves a meeting, a form, or a spreadsheet, you're setting yourself up to feel the full ire of the Development organization. Agree not to have these items in your process except as a last resort.
Development is probably going to want "Compliance as Code". Do yourself a favor, follow that link and realize that it's not an outlandish concept... it's widely accepted. Hear each other out.
Don't encroach on each other's specialty. Remember: Governance == "Intent", Development == "Implementation". Approach conversations with Curiosity... does the Dev team understand the intent? Does Governance understand the automation plan?
Everyone comes prepared. The problem to be solved is an Audit Control... it's a known quantity. Governance can't move the goalposts by surprising everybody with a new control, and Development can't dredge up all the times they've felt ignored in the past. Come with focus, do the homework, be ready to solve a puzzle together.
The solution isn't "done" until both sides' goals are met. Compliance is a necessity; the auditors aren't going away. Development can't afford a bunch of friction in their daily work; revenues depend on it. You have to solve both sides of the equation, or you've solved nothing.
Thinking Win - Win
What does it look like for everyone to win?
Auditors get their "proof" without having to chase people down.
Developers go back to doing what they love: building features without feeling like the compliance department is the "Department of No."
The Business becomes faster, safer, and more resilient.
Conclusion: Realigning the Mission
Compliance and Development aren't supposed to be enemies, but they've allowed themselves to become so because they didn't stop to translate for each other. Without this critical partnership, the Law was misinterpreted, and the organization suffers.
Today, I'm challenging you to have some courage: the courage to listen, to empathize, and to forge a path together that helps us both achieve.
If you're brave enough... stick around. The Adventures of Blink is going to show you how!
Top comments (0)