Policy Pain: Scaling Automated Governance Chapter 4

Several weeks passed, and the teams gave it their best effort to start implementing the actionable steps they’d discussed in their two days of retrospectives. They had been making great progress at first, but a recent outbreak in new policy enforcement and debate had significantly stalled Brysons’ effort to pull FIN and BAD products across the finish line. He had finally had enough.

“Damn it, Jennifer!” Bryson burst into Jennifer’s office, frustrated. “When are Janelle and the risk team going to stop with the neverending compliance theater? Every week there are new or updated policies. Our tech teams spend more time attempting to second-guess our compliance teams’ guesses about the potentially possible questions an auditor may ask. Does anyone know if any of these spitballs they throw at the wall stick? This week is the next act in the ongoing Shakespearean tragedy of our compliance play with BAD’s so-called ‘auditors.’”

Jennifer sat there for a second, collecting her thoughts. With a crooked smile, she replied, “‘Guessing the guesses’ of the potentially possible . . . can you make that statement any more confusing, Bryson?”

“I’ve got a specially designed soapbox for this one. I’ve been working on it my whole career here,” Bryson snapped back. “The initial success of our AutoGov solution seems to be fleeting. BAD is doing the usual big company stuff. I walk into these meetings and can’t tell if I’m at a Texas steer farm or work. There is so much cow manure being thrown around, I may as well retire now and become a rancher.”

Jennifer started to laugh. She couldn’t hold herself back. “Yippie Kay-Yah, big rig trucker!” 

Slightly annoyed, Bryson responded, “Funny, I see what you did there.”

After a small laugh from both of them, Jennifer responded, “I think we need another iteration of the AutoGov system. I hear more and more over-usage of the term policy. There are policies everywhere. Any rule someone else wants to force on another person has simply been titled a policy to garner internal political support. It’s a form of corporate gamesmanship, and the best way to address this is to bust this policy myth.”

This got Bryson’s attention. He became more focused on Jennifer’s words. She was making sense in a way that he agreed with, although he couldn’t figure out why. 

Jennifer continued, “I walked by Mira, Diego, and Owen’s desks the other day just to say Hi. The three of them were heatedly debating with Amelia about policy as code. I pulled up a chair and listened intently to them. Both Amelia and Diego were making some very interesting points. Diego showed Amelia how they used this O-P-Something tool to write policy as code. Amelia was visibly confused. She kept stating that what the three considered policy was not ‘actually policy.’”

Intently curious, Bryson said, “What do you mean ‘ . . . the policy is not actually policy?’”

Jumping back into her line of thought, Jennifer continued, “Amelia had all these printouts of the Secure Controls Framework.  From what I gathered, BAD is starting to use it. It somehow makes it easier to correlate or compare a company’s performance to different compliance and security frameworks. Don’t quote me on that description, but what I found most interesting is how our tech and compliance teams use the same terms with different meanings.”

Now on the edge of his seat, Bryson interjected again, “How so?!”

“You going to let me finish?” Jennifer playfully snipped. “Amelia pointed out that a policy is a high-level statement of intent, not a specific or low-level one. Mira, Diego, and Owen were very confused, because they defined a policy as fine-grained and not high-level. Diego’s confusion was obvious when he disagreed with Amelia’s policy definition. His mental model of policy was something to the effect of, ‘There must be at least two reviewers for a pull request.’ Amelia was adamant that what Diego saw as a policy was a procedure because, by the Secure Controls Framework definition, a procedure is a defined practice. After that conversation, I did some digging on my own. There was one graphic that spoke to me.”

Bryson piped up, “Spoke to you like the ghost of Juliette?” 

With a small grin, Jennifer replied, “No, more like an omniscient narrator. Here, check it out. This diagram pretty much says it all.” Bryson scooted closer to Jennifer’s desk as she turned one of her two screens toward him.

Bryson was focused on the layer-cake diagram. He was making interesting faces as he read Jennifer’s screen. “May I borrow your mouse?” Bryson asked. She slid it his way, and he quickly scrolled up and down the document. 

“Can you message me this link?” Bryson asked. She took control of the keyboard, copied the link, and pasted it as a direct message to Bryson on Smack Messenger.

“I’m digging this, big time!” Bryson exclaimed. “This makes my inner product person happy. Putting my product hat on, the policy concept is like a product feature. Features, at their core, tend to be higher levels of a customer’s desire. This may get confusing with Control Objectives. In my frantic scrolling, I saw a control object talked about as something like an SOC control. I’m no expert in SOC, although from our last Type1 audit, the SOC ‘controls’ are more like mini-features of a big feature. The SOC is based upon something called the 5 Trust Services. I need to double-check with Amelia, but I’m betting this Standard vs. Guideline is simply saying something to the effect of ‘this control is either a hard must-have or a recommended should-have.’ Now, with this procedure, I see where Amelia is coming from. Over the past few months, I’ve been digging into that O-P-Something our engineerings are using. I think its real name is the Open Policy Agent (OPA). OPA checks that the data of something is what it’s supposed to be. Which seems to be the same as a procedure.”

Jennifer was digesting everything Bryson said. It seemed very logical. 

Bryson then cut off Jennifer’s line of thought. “In the vein of compliance and security being features of a product . . . let me see what I can do with this. Product Management may be a way to resolve my love of policy. If something genius comes out of it, maybe this week’s shenanigans can be the last act of this merger’s drama.”

“I’m holding you to it,” Jennifer stated.

After Jennifer’s comment, they focused on other hot topics that needed to be addressed. Jennifer and Bryson finished their meeting with three minutes to spare. As Bryson left, he asked Jennifer, “Would you like to be included in these meetings between our risk and tech teams?”

“No,” she replied, “I have enough reasons to keep busy. I think you got it from here. Just do me one favor. If this doesn’t seem like ‘a thing,’ let’s chat. Something deep inside me sees this as the basis of a real solution. It’s a first principles thing. That policy cake diagram seems to break the concept into its most fundamental constituent pieces.”

“Roger that, boss. Let me wrangle up the team. If you see me in Levis, dirt-kickers, and my Stetson, it means real work is getting done,” Bryson replied.

“Go get ’em, cowboy!” Jennifer said with a deep bellowing laugh as Bryson left her office.

Mira was laughing so hard she was crying. Tears were rolling down her face. Her laugh was so infectious that it kept the constant laughing momentum. Bryson was standing right there, at the front of the meeting room. He was dressed to the nines in his finest western outfit. He was wearing old, worn-out cowboy boots with plastic spurs he borrowed from his son’s previous Halloween costume. He kept true to his word with almost skin-tight Levi Strauss jeans and a cream-colored Stetson knock-off cowboy hat. Bryson even bought chewing tobacco for his back right pocket. On his way into the office, he plucked a long piece of grass from the front of the building to chew on.

Diego blurted out, “Do you follow Tumbleweed Tommy on social media? You could be his real-life manikin!” in between gaps of air and laughs.

The room was busting with genuine laughter at Bryson’s outfit. Many people from both companies were there. From FIN, there was Liana, Diego, Owen, and Amelia in addition to Bryson and Mira. From BAD, there was Jane, Brina, and Betty.

Jane had recently become a mentor for Amelia. As the Executive Vice President of Corporate
Compliance for BAD, this was an unusual meeting for Jane. Her organization is massive, almost the size of FIN. Jane would normally delegate this to her direct reports, although Jane turned Amelia onto the Secure Controls Framework. Amelia made sure Jane attended this meeting. Amelia needed Jane’s expertise to fill the areas she was still shaky in.

Brina and Betty were BAD’s versions of Owen and Diego. They’d worked as engineers at BAD for a long time and were as thick as thieves. While both were software engineers at heart, Betty had a knack and passion for software testing, while Brina had a knack for automation. They were notoriously referred to as “The Duo” because they had proved to BAD what happens when two 10x engineers partner in the best ways.

Bryson pointed at the large screen in the front of the room. There was a presentation titled “SCF as Code.”

“Now I’m regretting my outfit today. Take a deep breath, wipe the tears off your face, and let’s giddy up,” Bryson said as everyone in the meeting room made one last guttural laugh.

Bryson continued, “Jane and Amelia, I have taken to the Secure Controls Framework, or SCF as you call it. For those unaware of the SCF, it’s a comprehensive way to manage how a company maintains compliance across multiple security and compliance frameworks. I found their documentation very easy to read. I’m not an expert in this area, although the SCF folks made it fairly interesting.”

A semi-silent button-click noise was made and another slide appeared. Only two things were on this slide. First, the title. It was centered at the top of the slide and read, “The Misnomer: Policy As Code.” Second, the same layer-cake diagram Jennifer showed Bryson in their most recent one-on-one was directly below the title.

“It’s just like tech folks to redefine common terms for your means,” Bryson said with a joking smile. “All joking aside, we have a real problem here regarding policy. It’s an abused term that’s only used as a fighting word. Nowhere in the history of the word policy, based on my research going back to the 14th century, was it ever defined as ‘a proverbial term to assert one’s intentions over another.’ The policy is simply a way of management. We have a policy problem, and I see it as a product problem. If our customers value proper governance, then policy adherence, the correct type of policy, is my problem, and I’m here to conquer this Wild West.”

Watching the room, Bryson could tell that he had triggered some of the engineers. Mira looked like she wanted to interrupt Bryson, although she held off.

“Bryson, I’ve been doing policy as code since Diego was in diapers,” Betty abruptly blurted out. Mira grinned slightly, one of those ‘we got your back in a corner now’ type grins.

Betty continued, “The tools always change, but the fact of the matter never changes. We write our policies using the language-franca of the day, and the newest fancy policy engine management bought executes the policy code. We do this a lot with networking and infrastructure policies. I don’t think BAD could ever execute at scale without our policy as code.”

Bryson gently interrupted, “Networking and infrastructure procedures, you mean.”

“Procedures, where the hell did that come from? Did I misspeak? Policies. P.O.L.I.C.Y,” Betty passionately responded.

“Betty, I don’t think you understand what policy means,” Amelia butted in with.

Tension in the room was on the rise, quite a reversal from the laughter a few moments before. Bryson started to get a bit pale. Jane took notice as well. “I think we have a pants moment here,” Jane said after a few teasing moments.

“Pants, like Bryson’s hip-huggers?” Diego said in an attempt to lighten the mood.

“Yes-ish,” Jane replied. “We have a pants moment with policy word right now. Let me explain.”

The mood began to cool again. This situation was all too common since BAD and FIN merged. A thirty-minute meeting could have sixty or more very high and very low points. Both management teams found it hard to set an organizational thermostat.

“I’ll make this short so Billy the Kid can get us back on track. I studied abroad in college, in France, to be specific. I had several roommates from across Europe. They were German, British, Polish, Romanian, and French. One evening, there was an ‘all-white’ party where everyone was dressed in all-white clothes with no writing or anything on them. I had some white shirts and shoes, but I hadn’t packed any white pants.”

Everyone was intently listening to Jane at this point. Bill had even pulled a chair from the side of the room to listen to the story.

“It was mid-day, and I was back at our apartment. My two British roommates and I were enjoying a fresh baguette, brie, ham, and Bordeaux wine. I suddenly realized my pants situation, turned them, and asked, ‘Hey, do you need any white clothes for this evening? I don’t have any white pants. Want to go pants shopping?’”

Jane paused dramatically, then said, “Know what they said?”

Betty said, “Other than yes or no, I can’t imagine what else they’d say.”

Jane smiled, then continued, “They didn’t say anything at first. Both of them almost spit out their mouthfuls of wine and food. Their faces became confused. Then I became confused, knowing something was awry. I pointed at my pants and said, ‘Pants, white ones, like these, but white.”

“Both of them began to chuckle and laugh. ‘Trousers, you mean, you need white trousers.’ I now became confused. Then they enlightened me. Guess what pants mean in British English?”

The room was silent. Jane continued, “What we call underwear is what the British call pants. In my mind, I was going pants shopping, but they heard me ask to go underwear shopping.”

The room began to chuckle. “It was a humbling moment for me. From there on out, I learned a big lesson about communication. Even if we speak the same language and use the same words, we don’t always mean the same thing.”

“Bryson, I think we have a white pants situation here. Can you elaborate more on what you mean by ‘procedures’ and not ‘policy’?”

Bryson took over and said, “Yes, let me skip forward one more slide. These aren’t my definitions. I took them from a part of SCF called Integrated Controls Management. On page 12, they clearly define policy and procedures. Let me read them for you.”

Turning his body toward the slide, Bryson began narrating, “The organization’s corporate leadership establishes policies or ‘management’s intent’ for cybersecurity and data protection requirements that are necessary to support the organization’s overall strategy and mission. Procedures (also known as Control Activities) establish the defined practices or steps that are performed in order to meet/implement standards and satisfy controls/control objectives.”

Turning back toward the table, Bryson continued, “Betty, based on this definition, what you refer to as Policy as Code is what the SCF considers a procedure. I find this distinction critical. It draws a clear delineation of responsibility and accountability. Management is responsible for establishing intent with policies, and non-management is responsible for defining practices, creating steps for those practices, and implementing these practices. I’ll hold off on the controls and control objectives for a second.”

Betty stared intently at the slide. Her eyes kept shifting from the slide to Bryson and back. She said, “I’m not saying I agree, but please, continue.”

Bryson picked up where he left off. “Have you all at least heard the terms ‘ISO,’ ‘NIST,’ or ‘SOC’?” Everyone was shaking their heads, Amelia more than others. “When you hear the controls or control objectives, compliance frameworks like that is what they mean. Let me now tie this all together.”

“At the highest level, management creates intent through a policy. For example, let’s say the policy is BAD must be proactive with its cybersecurity. This is very high-level, it expresses intent, although there isn’t much meat on the bone. So, let’s build it.

“The control objectives are the first step to building muscle behind the policy. For those who haven’t heard ‘SOC’ muttered before, SOC stands for Service Organization Controls. They have a large document called the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. This document has many controls that are expected. A control is a medium-level statement with more fine-grained intent, but it does not tell someone exactly how to do something, it simply is a finer-grained expectation.”

Bryson paused and looked around the room for anyone nodding off. Betty asked, “Can you give us an example of a control?”

“Yes, I have one near and dear to our heart,” Bryson continued. “Page 37 of the Trust
Services Criteria has the CC8.1 Change Management Control. The control states, ‘The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.’”

Owen interjected, “CC8.1 is about as useless to me as the policy is. It doesn’t tell me what to do.”

Bryson picked back up. “Owen, that’s correct. CC8.1 brings more specificity to our policy, but control objectives will not tell us exactly what we need to do. This is where folks like you, Diego, Mira, Liana, Betty, and Brina come in. Jane’s responsibility is to set the policy. Amelia’s responsibility is to determine what control objectives support the policy, and y’all determine what specific actions to take to support the control objectives.”

Mira busted in, chuckling, “Bryson, did I hear y’all in there? I’m starting to think corporate Bryson is the character you play, and cowboy Bryson is the real Bryson.” Mira’s comment broke the last of the tense mood in the room as everyone else had a chuckle.

With a smile, Bryson addressed Owen, “This is where standards and guidelines come into play. A standard is a requirement that supports the control objective, and a guideline is recommended guidance, although not mandatory. Owen, what is one thing, something not complicated . . . one requirement you would place upon your team that would, say, control the approval of software?”

“That’s easy, peer reviews,” Owen said.

“Great, peer reviews. How would you explicitly determine if a peer review was done?”

Owen didn’t hesitate, “Again, an easy one, we already do this without policy as code for the AutoGov system. We looked at who the reviewers were on the pull request. To use your terms, Bryson, we have two standards. First, the pull requester cannot be a reviewer. Second, there must be at least one reviewer. Regarding guidelines, we have many of those, but we mostly don’t follow them anyways. We only care about the hard stops.”

Bryson had a big smile on his face. “Owen, here is our pants situation. When you say policy as code, you mean procedure. If you refer back to the SCF definition of a procedure, you could write that piece to check if the requestor is not a reviewer; that is a procedure. It’s an implementation of your standard.”

Bryson got quiet and looked around the room. Everyone was looking intently at him as he asked, “Does this make sense?”

Amelia puffed up her cheeks with air, opened her eyes wide, put her hands on her head, then lifted them as if her brain was exploding. “Mind blown, Bryson,” Amelia said.

Brina, who had been quiet during the full meeting, said, “How you explained it connects some dots. No one has ever laid out a policy like this for me. You just demonstrated how to tie the actions we take to the management-speak. Regardless of whether I agree with the policy or even understand what SOC is, I see how I can play a significant part in this by determining the procedure we implement. For the longest time, I always thought Amelia was supposed to tell us what procedure to create. Do you see it the same way?”

Amelia responded, “Brina, we couldn’t be more on the same page now. I don’t have the expertise in your area to determine what a procedure should be. Bryson, I like how it helps me determine the correct questions to ask folks like Brina, Betty, and Mira. In my experience, we don’t know what the procedure is or should be, so it requires collaboration. Based on how you’ve framed this, we now have a way to determine the right questions to ask and what procedures to create.”

In normal Betty fashion, she grumbled, “I’m still not in full agreement. Do you realize how long we’ve used the term policy as code? Are we going to stop calling things policy as code now? Are we creating an additional pants situation with the word procedure?”

Diego butted in, “What about SCF as code?!”

Bryson took back control of the conversation. “I want to bomb the concept of policy as code, but there is a large industry that’s been around long enough with marketers that would fight me tooth and nail. We need to bring more of the right people into the policy conversation. The act of ‘policy-fying’ things should be not just top-down but also bottom-up. Tools like the policy engine you use are key, and stuff like that O.P.Something is good, but insufficient at a higher level.”

“We need to do two things. First, we must intentionally tie what we do, like the pull request review, to the high-level management intent. Second, we must create a clear picture for everyone in the chain, from management to hands-on-keys and everyone in between, with how all of this fits together. Whether we decide to do more with SCF is a future decision. I’ll argue that the definitions and relationships the SCF created with policy, control objectives, standards, guidelines, and procedures are foundational. These should be the only color pants BAD wears.”

Jane said, “Funny, I see what you did there, Bryson. This helps me a lot. I think there are conversations I can have at my level to drive the definitions you all come up with. Speaking of being more intentful, something has always grinded my gears. It’s also the bane of my existence; DLFTP, Distorted Logic from the Past.” 

Turning to Liana, Jane said, “Liana, were you part of that recent patch management and CVE management issue?”

“Umph, unfortunately so,” Liana replied.

“I thought so,” replied Jane. “I was told about your passionate plea to stop the dumb foolery. Although, I think you used a different f-word.”

A little red and slightly embarrassed, Liana replied, “Yes, I did. I believe everyone except that old stodgy change manager BAD has agreed. After all, he was the only one who claimed to understand that one stupid line about change management scheduling. He couldn’t give us any solid reason why that existed except, ‘That’s how it’s always been, and if you don’t comply with it, you’ll increase the risk exponentially.’”

Jane jumped back in, “Let’s not single him out alone, there is a group of folks at BAD that feel that way. Between those couple of meetings regarding changes to patches and CVEs, I dug a little deeper into why he and a few others feel that way. It came down to two simple things, and both are fears. After all, everyone wants to do their job the best. First, the increasing rate of changes and complexity left them unable to map things out in their head mentally. Second, because they have lost the mental map, they feel the risk is high only because they cannot answer questions they are accountable to answer. It’s very human to push back when you feel cornered, and boy, did they feel cornered.”

Liana asked, “How so? Was it because they saw the impending meteor of extinction?”

“Liana,” Jane responded, “let’s tone down the name-calling. They felt cornered because, like all in a similar position, they were asked to make decisions without any information. This is why that third full day was spent on observability. I heard that word several times for the tech teams, but until that day, I never understood how the tech sense of observability and our risk management interlinked.”

The room fell silent for a second. Everyone was visibly processing what Jane just said.

“Jane, I’m confused,” Diego said. “What is DLTP?”

Liana laughed, “Diego, it’s DLFTP, Distorted Logic from the Past. It’s when a decision was made some long time ago, most likely as a response to something legit back then, but the situation has changed. Yet we keep doing it even if the reason we do it is no longer relevant.  It’s just distorted logic from the past.”

Diego quipped, “Oh, you mean most of the stuff we must do as an engineering team?”

Mira laughed a little louder than she expected, a couple of folks in the room turned to look at her. “I’m going to start tagging some of my meetings as DLFTP!”

Again, the room broke out into a series of chuckles.

“Joking aside,” Mira replied, “this makes sense. As an outcome of this meeting, I was part of the security and engineering co-op teams. We focused on observability and automating rollback.”

Turning toward Diego and Owen, Michlled continued, “It wasn’t a short journey but there was a clear path. We simply took monitoring and rollback approaches we used for our apps and applied them to the infrastructure. We found ways to make some of the infrastructure ephemeral, although there are a lot of cared-for servers with names like Fuffy and Boe. Due to their pet-like nature, we treated their updates like we do with long-running business transactions.”

Owen interrupted, “You used a saga pattern?” 

“Yes,” Mira replied, “We took the perspective of a saga pattern, but more specifically we focused on compensating transactions.” Mira had got the full attention of Betty and Brina now.

Amelia said, “This sounds neat, but you may lose the rest of us. Between the geek-speak, Bryson the Cowboy, and this mental picture of our infrastructure team dressed as Vikings, I think BAD is chumming the air with creative chemicals.”

Turning toward Amelia, Mira responding, “That’s a good call, I can take this offline later. But you all came up with two things that seem to fit here with this discussion. First, the concept of drivers and contributors, and Bryson close your ears, “policy as code” has worked very well. Second, the fact that you added expiration dates to the policies was freakin amazing. I’m starting to see where these all came from with the distorted logic from the past.”

Bryson stepped in, “This all sounds good, but it seems we are rabbit-holing.”

Jane leaned forward with her elbows on the table, “Bryson, I don’t think we are. Give them about ten minutes to talk about this. I think this can be a good addition to your recommendation here with the SCF principles.”

Leaning against a ledge in front of the room, next to the big screen, Bryson said, “Ok, let’s time box this, ten minutes.”

“Amelia, your turn. Tell everyone more about the drivers, contributors, and expiration dates,” Jane said as she and everyone gave their full attention to Amelia.

“Of course,” Amelia said gleefully. This was a very large confidence boost for Amelia. In addition to the wealth of knowledge she gained from listening to Jane speak at their mentoring sessions, Janelle noticed a marked difference in how Amelia carried herself and interacted with others. Regardless of the seemingly bottomless culture issues that abounded from the merger, Janelle and Jane’s focus on growing talent to start and heal wounds was bearing initial fruit.

“Let me start with the expiration dates. It is so stupidly simple that I’m not sure why we didn’t start with it. Every . . . Bryson, ear muffs . . . policy we had or any new ones created were given a dead-by-date. The DbD. Each policy was given an owner and a DbD. The owner is responsible for ensuring that the policy is still relevant when the dead-by date comes up. They cannot just say, ‘Yes, it’s still relevant.’ The owner must justify in no more than one page or less why it’s relevant. Also, they cannot point to the previous justification and use that as their current justification. Although this seems very bureaucratic, it’s designed to create accountability and continuously improve our white-pants policies. So far, we’ve seen how it’s shifted the job duties. The owners of the policies spend almost no time checking off checkboxes. They spend all their time focusing on which checkboxes are the most important. Many on the risk and security  team appreciated this change-up as they now feel they are being used for their security skills and problem-solving ability, not just being someone who reviews files, checks check-boxes, and signs forms.”

Mira spoke up, “I’ll make it quick. Because of the dead-by-date, we eliminated a ginormous amount of policies. This made it easier to manage the automation as well. Bryson, it’s almost like what your team does when they create the product roadmap. If you think of a policy as a feature, the policy must have clear and credible business context supported by data.”

Bryson’s face got that epiphany-like look on it. In his head, he was re-validating that every software system behavior, beyond what the end-users experience, must be treated the same way.

Amelia continued, “Mira, thanks for sharing that. That simple thing made us way more effective.” Looking at Jane, Amelia said, “One quick thought, we need to figure out a good stick-and-carrot approach. Even though this just started to work, we all know how things go, and eventually, it may stop getting focus.”

Jane responded, “Janelle and I have discussed making this part of the team’s business goals and objectives, in addition to other carrot-like awards. We plan to pull that team back into a room for approval.”

“What is this,” interrupted Diego. “Management is now seeking the approval of their subordinates? In this industry? Has hell frozen over?”

People started chuckling, and Jane responded, “The days of command and control are over. Even as you all find new ways of working together, my peers and I must do the same. One lesson that some, not all, at BAD have learned from our peers at FIN is how to support your efforts better. This is not to say that the inmates will be running the asylum. We’ve figured out a better way to manage these days using trust instead of commands and control.”

Bryson said, “It’s been almost five minutes, we have five more left.”

“Ok, drivers and contributors,” Amelia said. “Drivers are responsible for setting policy direction, and contributors help refine and adapt policies based on their expertise and experience. Bryson, relating all this to SCF, executive management will drive policy—the high level—while their teams, the middle managers, contribute by refining and adapting the policies into control objectives. Now middle management drives the control objectives, and their teams are contributors. Based on the SCF definition of standards, guidelines, and policies, their teams refine the control objectives by identifying what should be done to implement them. These teams create the procedures that implement the control objectives.”

The room once again fell silent. Looking around, you could tell everyone was starting to connect the dots.

Continuing, Amelia pointed out, “I just realized one thing. What the teams call policy owners
are procedure owners. We have dead-by-dates at the procedure level using the SCF terms. So the driver of the procedures is, again using new terms, the procedure owners. We can extend the idea of owners and dead-by-dates to the control objectives and even the policies, again a new definition. This would not only drive clarity from the top-down, and vice versa, on what is being done and why, but it also drives clarity for who is responsible. For example, if Mira and Liana are working procedures for a SOC control objective, the owner of those specific controls are the people Mira and Liana work with to answer questions.”

Jane spoke up, “Amelia, that is an awesome insight. I’m amazed at how simple this stuff is once we’ve talked about it.”

Amelia responded, “Well, I think it’s more of a clear path, not a short journey. We have initial success, but we need to get everyone else on board.”

Bryson interjected, “You know what this sounds like. Drivers and contributors are my ranch hands!” He put his two thumbs behind his belt buckle. The room busts out with laughter.

Bryson turned, looked at the clock, and said, “OK, times up. We only have a few minutes left in this meeting. We got to where I wanted to be, even though I grazed in a different pasture than I expected.”

With the sound of a click again, a new presentation slide popped up that said, “Next Steps.”

Bryson continued, “Jane, if you support what you’ve seen today, I’d like to write this into a formal proposal. I’d like Janelle and your approval for the approach. We will then go to market internally using the SCF as the basis for classifying our policy approach. Based on the conversation about dead-by-dates, drivers, and contributors, I will work with Amelia to add those specifics. The SCF gives us a good foundation, although the clarity around who and why those three things give us is lacking.”

Bryson paused and looked around the room, implicitly opening the floor to any questions.

“Bryson, I think it’s time we mosey on out of here,” Betty said with a grin. “It’s almost lunchtime.”

Looking at Betty, then to the rest of the room, Bryson said, “Sounds good, let’s call this a day.”

As everyone was putting away their laptops, Mira asked Owen and Diego to sit next to her, Betty, and Brina.

Turning toward them all, Mira shared a thought which had been in her mind most of the meeting. “The AutoGov solution has the start of some of this, but not all. What do you four think about a small hackathon? I’ve had dreams of graph databases listening to everyone today. This is similar to a knowledge management problem I had to build a solution for years ago. Would you all be up for prototyping a solution that manages all this SCF stuff, dead-by-dates, and drivers?”

“Let’s do it,” Brina responded. 

Owen commented, “Me too.” 

Diego spoke up and said, “Me three. Let’s InnerSource a solution!”

Conclusion

Scaling Automated Governance isn’t easy. It requires trust, collaboration, planning, and flexibility. As our group of friends from FIN learned, the work begins with people. Breaking down silos is not just about empathetically joining teams together, but about challenging the status quo, adopting new ways of working, and flexing innovative approaches to deliver outcomes faster, better, safer, and happier.

We hope you enjoyed this short story and that it will inspire you to explore some new ideas that will help you create, use, and scale governance in a deliberate and business empowering way that helps deliver on your organization objectives.

Thank you for reading our serialized short story. You can also download the full story in the Fall 2023 DevOps Enterprise Journal.

- 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

• 
•