On Working and Blogging

I created this blog a little more than 2 years ago, when I was on parental leave to take care of my second child. Unlike my firstborn, this little one would eat and sleep well without any major drama which gave me enough time to do other things besides household chores. A year later  I went back to work, in a new department and a new role, and I realized that my urge to write had reduced significantly.

Here are some reasons why.

Needing distance to reflect

While on parental leave, I had the time and the necessary distance to think about what had happened throughout my short career. I was no longer in the middle of events, so I had a clearer picture of what went right and what went wrong. The blogs were my retrospectives of what I had learned and observed over the years. Going back to work meant that I experienced new things, but I no longer had that clarity of completed outcomes that I could document. So nowadays, since things I hold to be true one day I might find irrelevant the next, it is very hard for me to write down my lessons learned.

Working when work is over

During the work hours, most of the time I am executing tasks that require a reaction from my side. There are things that simply need to be done, emails to be answered and meetings to attend. Not that there is no value in these things, but it rarely feels like creative work. So, when – finally – office hours are over, I find the peace and quiet to do all the creative and interesting stuff around my project that I don’t have time for during the day. Especially now that the work laptop is always on my desk, it just seems more natural to do actual work than to create content of my own.

There is life after work

Being at home and taking care of the kids is a lot of work but it is not “work” work. Writing blog posts about my experiences from my job was the only thing I did during that time that required a different level of concentration than my day-to-day errands. But now, even if I still work part-time, I find myself feeling mentally exhausted at the end of the day, so doing one more thing that requires my focus  just seems too much. Watching TV, playing games or just simply doing nothing when the day is over feels like a pretty good plan to me right now.

So, the natural question here is, why am I writing this blog post? I still find joy in doing it. I feel no obligation to “produce” something every so often. It also doesn’t need to be perfect as I’ve come to embrace my stupidity in most new things I try. Nowadays, it’s about trying to formulate half decent questions, and if something comes out of it, note it down. And that will do for now.

DevOps Enterprise Summit 2020 – Notes on Compliance

Last month, I was lucky enough to attend the London edition of the DevOps Enterprise Summit 2020. Like most events this year, I got to watch the presentations from the comfort of my living room even though I was planning to go to London for it. The reason this conference is particularly interesting to me is two-fold; first, because it is addressing DevOps challenges in large enterprise and secondly because it has dedicated track to compliance governance. As someone working on a compliance service in a big company, this was a perfect event for me to have a look at the industry’s trends.

So here are my notes on 3 presentations I attended, with the focus on handling compliance in DevOps.

Bureaucracy and DevOps by Mark Schwartz (AWS)

When hearing the word “bureaucracy” most of us get a bit anxious and irritated. In his presentation, Mark Schwartz highlighted the benefits of setting up rules to be followed by everyone and how DevOps help that these rules don’t get in the way of the actual work that needs to be done.

He then proceeded to make the bold claim,

DevOps is a kind of bureaucracy.

He backed it up, by noting that DevOps principles like automating repetitive tasks, align with bureaucratic benefits like: fairness – the rules are the same for everyone, predictability – if you do what you are required, you get what you need, consistency – everyone uses things the same way.

DevOps also help remove some of the burdens that come with bureaucracy, for example by getting fast feedback on the process, it is easier to adjust the rules. By creating “minimal viable bureaucracy” when automating compliance rules, we remove waste and reduce “red tape” instances.

Bureaucracy is a value stream and the product is compliance.

In summary, his message was to take our bureaucracy, automate it and make it enabling.

Low Context DevOps: 3 Ways to End Knowledge Frustration by Thomas Limoncelli (Stack Overflow)

Thomas Limoncelli framed his presentation around high and low-context cultures, an anthropology concept. You are in a high-context environment when you are supposed to know how things work just because you do, for example in family gatherings. On the other hand, in low-context environments all the rules are explicitly set out for you.

He proposed that a DevOps environment should strive to be low-context and suggested three ways to achieve this.


The defaults are how you expect most people to work, so defining them and supporting them “out-of-the-box” is something to go for. His second point was to embody and “standardise” the recommended practices for all of our tools, from the CI/CD pipelines to our bug ticketing systems. Or simply put:

The lazy path guides you to the right way.

The final point was to provide information exactly where people need to see it. Adding a URL pointing to a meaningful explanation is cheap, so why not use it? It also implies that information needs to be documented along with development, so that knowledge is shared and the context is reduced.

I believe compliance is a good candidate to lower its context. The defaults should address the company’s main risks. They should be machine readable and easy to check against. And finally, they should be easy to explain and versioned so that they are always up to date.

DevOps and Internal Audit: A Great Partnership by Rusty Lewis & Clarissa Lucas  (Nationwide Insurance)

In their presentation, Clarissa Lucas and Rusty Lewis set out to answer the question that many teams dread to ask:

How can we pass an audit when we are moving to a DevOps operating model?

Using the example of the risks that accompany the change management process, they walked us through how controls such as Approvals and Segregation of Duties can be evaluated from a DevOps perspective.

When thinking about Segregation of Duties what we usually have in mind is one human handing over to another, for example one developer writes the code and a different one reviews it. To shorten the time and efficiency of the control, we can implement some automated checks that we deem necessary for a review and leave only the critical thinking part to the reviewer. And we can go further, by logging any deployed changes and verify if they belong in a pre-approved low-risk list. In both cases, we mitigate the change management risk by automating some of the steps, thus enabling fast deliveries in a compliant way.

They summarised their findings in the slide below:


For me, the biggest takeaway and the biggest challenge is to enable the collaboration between development and audit teams. Development teams need to understand the risks to the enterprise and find efficient ways to implement controls while the audit teams need to look beyond their existing checklist and be open to evaluate them.

Some conclusions

Whether we like it or not, there are always some rules we use to build our software. Some we choose to follow and some we must. But all three presentations mentioned here made the point that having such rules is not something inherently bad. Automating what makes sense to automate, allows for more time to invest in “custom” quality for a product, which brings even more value to its users. The “DevOps Automated Governance Reference Architecture” paper (access to Forum papers), provides invaluable information on how to achieve that technically. But in the end, it’s up to all of us – developers, auditors or management- to find ways to uphold the rules in a sustainable way. And we can do that only by working closely and honestly together.