DevOps and Agile transformations continue to be challenging for organisations due to the complexity of the problem. It seems that most people agree on what good looks like but struggle to find their way there. Successful organisations like Netflix or Spotify provide examples but their journey cannot be simply copied and organisations which try encounter a lot of challenges as their context organisationally and technology-wise is different. The transformation is different for every organisation, but some patterns are common, so what can one do.

In my book “DevOps for the Modern Enterprise” I tried to write down my experience from working with many large organisations. While there is no one solution, certain patterns that prove successful can be seen and more importantly a certain way of thinking has been common for organisations who made progress. And of course I have been part of many things that did not work out and can share those experiences too to help others avoid costly mistakes. No need to pay for those lessons yourself.

Three themes run throughout the book:

• The transition from managing IT work similar to manufacturing work towards managing a creative process enabled by knowledge workers
• Dan Pink’s three ways to motivate knowledge workers: Autonomy, Mastery & Purpose
• The power of small batches – why it is important to work in small batches and how to enable them

These three themes run like threads throughout all parts of the book. I was motivated by the fact that as a developer myself, I found it very frustrating how for a period of time over-industrialisation created a view of IT work as just a production process that should be optimised for cost and productivity. Something that simply is not appropriate in this day and age.

The book is structured in three dimensions of change which need to be addressed for a transformation to be successful:

• The ecosystem of the organisations including vendors and software partners
• The People Dimension and the organisational structure
• The Technology Architecture of practices and technologies to enable engineering

And in the center of it all is a rigorous continuous improvement process that leverages the scientific method to plan and evaluate the experiments that make up the transformation over time.

Let me give a little summary of each section:

Creating the right ecosystem

The ecosystem is the environment in which the transformation needs to take hold to make real change. This part of the book looks at how to setup the transformation for success and how to identify the right applications in a legacy environment that should be tackled first. It also explores the roles of technology vendors and systems integrators and helps organisations choose the right ones that can help during the transformation.

The People and Organisational Dimension

Nothing happens without people in technology, so how can we structure our processes and our organisation in a way that maximises Autonomy, Purpose and Mastery for our knowledge workers?

I explore how Agile helps to provide all three things to our people, how some organisational structures have shown to be good stepping stones for success and how the organisation has to move from testing to quality engineering.  I also provide some ideas on how to focus more on the people in the team when managing teams based on my own experience of managing teams.

Technology and Architecture Aspects

The last part of the book is the most obvious one that many expect from a DevOps book. What technologies and technical practices should you use and how can you be successful with them. I revisit Continuous Delivery and more advanced delivery patterns. I take a long hard look at the DevOps tools out there and how you can choose the most suitable ones for your organisation while avoiding any specific vendor recommendations as they would age way too quickly. Of course architecture evolution towards Microservices and leveraging the cloud successfully are covered as well.

Organisations who consider all three dimensions are stacking their chances for success. Each chapter of the book comes with practical exercises that I run with clients and that the reader can run for her/himself in her or his organisation. I wanted to make sure that the book is not just for reading but also for taking action and taking the next step of the journey.

DevOps for the Modern Enterprise is widely available from 4 April 2018:

Amazon: Link
iTunes: Link
Bookdepository: Link

I like it simple. And I have a somewhat shaky relationship with maturity models as might have gathered from some of my other posts. I see the power of using a maturity model or assessment to help people understand where they are, but it’s also so prone to Dunning-Kruger (Link). So what else can we do to understand our maturity in IT delivery as it relates to DevOps.

I am running executive training that helps program leads and delivery leads understand how to run programs that use Agile and DevOps methods. As a lead they are unlikely to run stand-ups or configure Jenkins but need to understand enough to support their teams and help stay the course. Hence we created a training that focuses on principles and how things look like from the executive perspective. We call it Modern Engineering Bootcamp. I cheekily usually say in the introduction that the aim is to make executives dangerous for their teams, because they will be able to call things out that teams don’t do well. They will be able to call BS when their teams believe they are doing well but really are not. We had this moment when a participant during the discussion on configuration management spoke up: “Until just then I believed we had our code in configuration management and only after asking a few more questions inspired by this course have I just found out that our Pega configuration is only stored in Pega not in a proper configuration management system. We will change this ASAP to improve our DevOps setup and to be able to automate further”.

This got me thinking, can I come up with a small set of self assessment questions that helps people make the same kind of discoveries where they need to.

Thinking about it for a while, I went through my past projects and realised that I asked my teams certain questions and asked them to do certain things when I got a little bit worried we are missing something, it’s time to share these questions with you (and some of the stories behind it):

Let’s blow away the environment and rebuild it from our stored configuration

When I was still a young developer I was working on a mainframe project. We had a development environment that we used to check our code before deploying to the mainframe. I noticed that the environment was cluttered up with lots of things that seemed to be leftover from earlier iterations and decided to blow the environment away and rebuild it from what we had stored in configuration. We might call this now “infrastructure as code”. It turned out that when I tried to rebuild it, that not only some files were missing (they were not in SCM as they were never migrated when moving to a newer SCM) but also the mainframe CICS configuration was not correct. We spent 2 weeks fixing this and while my boss was initially not happy that I had caused two weeks of extra work, we were lucky to find this in development and not at some later stage in production. Some of the missing files only existed in live environments and not in any SCM system…phew… By the way nowadays this question usually means lets rebuild a cloud environment from scratch, which should cause even less headaches.

When you ask your team to do this you are really looking for two things:

1. Does your team look worried or push back against this request? Explore what the concerns are, it’s likely they know where the skeletons are in the closet.
2. If they are confident and kick this off, measure how long it takes and whether you are happy with the timing.

Keep repeating this regularly to improve speed and reliability.

Let’s delete the application config and redeploy it

In my second project we ran some pretty fancy Control-M schedules to deploy applications and update configuration as required. Jenkins was still to be invented I think (or I hadn’t heard of it at least). Because we ran two releases in parallel and had lots of queues and databases to connect, we used a massive excel sheet to store our environment configuration. By the time I joined the project the project was already under way for a long time. I was worried that some configuration was missed in the excel sheet and decided to build a new environment and deploy the configuration only from the excel sheet. No surprise I found a handful of configurations that were not stored. Luckily I had learned from my previous project not to blow away an environment in use but rather build a new one in parallel to find these problems.

You are using this question the same way as the first one. See whether your team is comfortable and regularly run the exercise.

Let’s redeploy the application even though nothing has changed

So your team told you the application deployment is automated and reliable? Great, ask them to schedule a deployment of the latest package every morning into your dev or test environment before the team comes to work. Given they are deploying the same thing there is very little risk and it’s automated so no one needs to be around for it. On my third larger project this is what I did. And when the team pushed back initially I asked for it anyway. And guess what… for the first few weeks someone had to come to office early as there was always a small hiccup or another until it was fully smooth. The only thing that proves automation and keeps it clean is running it outside of business hours when no one touches the system and doing it very frequently even (and especially) when no changes to the application are required. It keeps proving to everyone that the deployments are reliable and that if after deploying a new version of the software problems occur, they are likely to be found in the code not in the deployment mechanism. Running it every day also allows you to measure performance and keep improving it. Those of you deploying multiple times a day, well done yours must be reliable already to do it so often, for everyone else: Start doing it frequently to become reliable and take the worry away.

Let’s rerun the test suite and then again

In one of my later projects we were struggling to make test automation work. We had a few goes at getting a test automation framework going. At some stage the test team celebrated that they had a regression suite that works. After a successful run I asked them to quickly rerun it and it turned out that we couldn’t as the data had to be completely refreshed and would have blow away the progress made from manual testing that was running at the same time. We had some more work to do. We had other performance related issues too that made it difficult to grow our regression test suite. But that’s a story for another time.

So with these four questions I think I provide you a simple diagnostic for some of the basic principles underpinning DevOps. See how your team reacts when you ask these. If your team cant perform these tasks then start working on improving the situation until all four of these become second nature and the questions don’t even raise eyebrows anymore.

I guess it is time to get back to work. This week I will shift my focus away from teaching my son how to build block towers, how to not kill himself while climbing on and falling off furniture and other required survival skills. I will go back into the complex and exciting world of Agile and DevOps, but before I do this I wanted to share what my paternity time meant for me.

First of all, it was amazing to be full time dad while my son makes exciting progress in development, while I was at home he:

• Learned how to crawl, walk with the help of a pampers box and walk freely – wow what progress in such little time
• Kicked his first soccer ball (YAY!)
• Played with his first LEGO set (YAY!)
• Learned to eat food with his little hands and in the process spread it all over the dining area
• Became even more adorable than he already was

What did it mean for me? Well I:

• Slept an estimated 3 hours per night
• Changed roughly 136783 diapers or so
• Realised that you have to be super-efficient to fit breakfast, shower and getting dressed into a 25 min morning nap
• Caught up on few pop culture things I didn’t know about like Bananas in Pyjamas

The last 7 months or so have been absolutely fabulous. I am looking forward to get back to work, because I really enjoy what I do for a living and have a great time, but I wouldn’t have wanted to miss these special months in my son’s life. I certainly appreciate stay-at-home mums and dads a lot more and will never ever ask them: “So what do you do all day?”

I want to encourage all soon to be dads to take the opportunity if they have it to spend some time as full time dad: It is great for your bonding with your child, it will make you appreciate your life partner even more, it will provide you a new perspective on life.

Now I am looking forward to reconnect with my team, my clients and my friends in the industry, I see a few work dinners and drinks in my near future to share stories 😉

The Dunning Kruger effect (a.k.a. Illusionary Superiority)

If you attended any of my conference talks or spoke to me about maturity models, you would have heard me mention Dunning Kruger. Yet to this day I have not written a blog post about it. It’s well overdue as it is the single best explanation for the behaviours I see in our industry and the source of many of my frustrations. Let’s take a good hard look at ourselves in the mirror.

What is the Dunning-Kruger effect?

The Dunning Kruger effect says that people who are not that knowledgeable about a certain area actually believe that they are quite good at it. Perhaps we start with a few examples:

• 90% of drivers consider themselves to be above average – Daniel Gilbert Stumbling on happiness
• 94% of college teachers consider themselves to be above average – Daniel Gilbert Stumbling on happiness
• In a survey of faculty at the University of Nebraska, 68% rated themselves in the top 25% for teaching ability. – Wikipedia
• In a similar survey, 87% of MBA students at Stanford University rated their academic performance as above the median. – Wikipedia
• How do you think people would rate you as a leader?” It turns out that 74% of the respondents think they’re either above average or the best leader their people have ever had. – SmartBrief on Leadership
• Or consider Lake Wobegon where all children are above average 😉

Perhaps it is best explained by the anecdote that gave it the name, which inspired the original research from Dunning and Kruger:

A man decided rob a bank and did his research to prepare the big heist. He then entered the bank robbed the bank of it’s money and made his way home happy to see everything going smoothly. When he arrived at home the police was already waiting for him and arrested. The man was shocked. In his research he had found out that lemon juice can be used as invisible ink, and so he covered himself in lemon juice to be invisible to the people and cameras due to the invisible ink…

Is Dunning Kruger really a thing?

You might wonder whether Dunning-Kruger is really a thing and why it is important for you. Let me tell where I came across it most often. I do a lot of assessment work to understand where organisations are in their DevOps journey and there is one aspect that keeps baffling me: Continuous Integration. Here is a pretty common dialog that I experience with someone from the development of an organisation, let’s call him Adam:

Mirco: Do you practice Continuous Integration?

Adam: (with a little hesitation) Yes we do.

Mirco: (thinking I could stop here and tick the box, but am curious) How do you know that you are doing CI?

Adam: We have CI server and are using Jenkins.

Mirco: How often does the CI server build your software?

Adam: We run it once a week fully automatically.

Mirco: How often are your developers checking in code?

Adam: Multiple times a day.

Mirco: Does your CI server run cover static code analysis and automated unit tests?

Adam: No.

(…)

I don’t believe that people have the intention of lying in this scenario, I think Dunning-Kruger is working its magic here. I was baffled by seeing this pattern again and again. Once I learned about Dunning-Kruger things fell into place.

Once you know it, you will see it everywhere in the DevOps and Agile world. People believing they are done when they are just at the beginning. People attending conference talks and rather than understanding the difference picking up only the things they have in common to validate their self-evaluation.

This also means that self-assessments are potentially dangerous and that maturity models can be misleading. It might also make you question the validity of some of the surveys you see out there. Well, it might make you doubt yourself? Am I really doing this right or am I falling into Dunning-Kruger?

I think the most important takeaway is that we need to talk more. We need to try to understand the context and the situation much better before we do an evaluation. We need to look for others to take an external look at our situation and compare it as objectively as possible. We need to provide more education for our people as a recipe against Dunning-Kruger. As an alternative to the usual maturity model I once created a “Civilisation”-inspired technology tree for Continuous Delivery with one of my clients, you can read more about this here.

Rather than looking for maturity models, perhaps it is better to look at outcomes and use maturity models as a conversation starter with a coach to help us identify which steps to take next rather than an evaluation of our teams. It’s only one of the tools in our toolbag and we should not put too much emphasis on it.

I will leave you with this final picture that I came across, unfortunately I don’t know the origin (Update: Martin in the comments told me it’s from Simon Wardley), but it does describe the danger zone very nicely in which many people new to Agile and DevOps find themselves:

In November I had one of the most stressful, most nerve-wracking and most amazing days of my life. Of course it won’t compete with the birth of my son or my wedding day, but it was still very special. I was at the DevOps Enterprise Summit to speak and to hand out preview copies (called galleys) of my upcoming book “DevOps for the Modern Enterprise” (available in April 2018 from Amazon, Bookdepository and many other sources).

When I saw a physical copy of the book for the first time in the morning, it was an unreal feeling. There was certainly pride but also a level of disbelief. But damn does it look good 😉 I went on to an interview with Alan Shimmel (which you can find here) to discuss the book. I can’t wait to hear from Alan what he thinks about the book. Before this day only a small number of people had read the book and they are people I consider friends, hence they would have been kind to me in any case, now the book is out in the wild and I am nervously awaiting the feedback from the community, a community that is passionate, opinionated and full of experts in their own rights. Let’s see.

Later in the afternoon I presented my talk “What got you here, wont get you there – a story of transformations”. You can see the video of the presentation here. I think the talk went reasonably well as several people over the next couple of days commented on it with positive feedback. The talk gives a nice glimpses into the content of the book and is a good teaser. If you like the talk, I think you will like the book as it is very similar in tone and content.

And then came the big moment, a 2 hour book signing event in the evening. I was more nervous about this than anything else to be honest. Would anyone even come by my desk when the alternatives are great authors like Mark Schwartz, Gene Kim, Dominica deGrandis and Nicole Forsgren? I didn’t have to worry, many people stopped by to get a signed copy of the book. Lots of people who had been at my talk and wanted to read more. I think I got the hang of the book signing process after a while and apologise to some of the early people in the queue when I was clearly still a bit overwhelmed by the experience. I enjoyed talking to so many people about the conference, the book and my talk.

After the book signing I thought I might go for a drink, but had to admit that my social batteries were depleted after the experience. I am humbled by all the positive comments from people and by so many people from the DevOps community turning up to grab a copy of my book. You made this a really special experience and I hope you enjoy the book. Do let me know what you think.

Happy New year to you all. I am now half-way through my paternity leave and I will have to admit that the “Father of the year” award might be slightly out of reach for me this year. I will get to that, but first let me tell you that I will write to the government and make it clear that this should not be called paternity leave. It is paternity work. I have so much respect for all those full-time parents, your day is fully organised by eating, putting little one to bed, cleaning up, making food, changing baby,… I am keeping up with the schedule but will admit that my wife sent me some handy SMS reminders during the day in the beginning. And then you need to use the few free moments to get the basics done: Shower, eat, check on the Ashes and soccer results,…

You wonder why I don’t think I will win the Father of the year award…well…okay here some not so pretty truth:

• I always thought I would not buy many toys for my kids…but man are they fun. I am buying those toys because its fun to teach him something new with building blocks, and shape sorters, and Duplo blocks, and have you seen the Ballapalooza…you get the gist. By now we are drowning in toys that Papa thought might be nice to play with. And really for an adult who keeps buying lego sets for himself (have you seen the recent millennium falcon set?), should I have really expected anything else from myself?
• Somewhat related is the “we will keep it tidy” idea that I had. And then there is the realisation that your trip from the bedroom to the bathroom at night is now a dangerous endeavour through a minefield of sharp or loud objects…I wonder is it worse to have a sharp pain under your foot or to trigger a loud noise that makes the little one wake up…I let you judge that…I swear the enemy (see picture below) is getting cleverer every day
  
• And of course there is the “we will not let him watch TV until he is old enough”…”Are you thinking what I am thinking B1?”, “I think I am B2”, “It’s papa let’s me watch TV time” Papa gave up and uses a bit of TV once in a while to keep him under control when feeding. And I let you guess which one is his favourite TV show? Oh well I have fond memories of the shows I watched as a kid.

But apart from that the two of us get along well and time flies. We go to weekly swimming lessons together which is fun. We explore the local parks. And since he started walking around Christmas, I am chasing around the house to protect him from the furniture (or is it the other way around?!?).

And then there are those moments when you wonder what is going through his head. I bought him a set of the construction toys, one of them a CAT excavator. And then one of the real ones turns up next door to demolish the house next door. What goes through the head of the little man when his toy all of sudden has a gigantic brother? Is that scary or incredibly cool? I wish he could tell me.

My leave was sweetened by getting promoted to Managing Director in December which gave me reason to celebrate with family – and again just like later at Christmas, I wonder what the little one is thinking? Perhaps: Why is everyone so happy today and why am I not the centre of attention as usual? Our joint birthday is coming up and will mark the end of my paternity leave and for that celebration the little man will be the centre of all attention. The other birthday boy will gladly stand aside and enjoy the loudest birthday party he has had in a long time with the coolest birthday cake (yes I know it’s for the little one, but still 😉) I will post one more time to reflect back before heading back into the office in February.

After writing about behaviours that help new joiners to be successful I finally got around to write about managers. What does a successful manager look like. And here I don’t mean specific practices like the ones you can learn from www.managertools.com but rather the more high level behaviours. This is what I expect from a manager who works for me. It surprises me that so little guidance is provided for new managers (or at least I didn’t know where to look when I first got promoted). The below is what is in my head when I think of successful managers, with many years of managing managers it was well overdue to move this from the frequent coaching discussions into a blog post.

• Servant leadership to set a positive example
  Servant leader sounds good, but what does it mean? A servant leader puts the team before his own interest. There are a number of behaviours that servant leaders show:
  – External blame stops with him – if there is a problem with something that the team has done, a good manager never blames an individual on the team. To the outside world he absorbes the critique and takes it on himself
  – Praise gets spread liberally – The opposite is true for praise. When the team has achieved success, a good manager goes to extra length to make sure everyone in the team gets credit. A servant leader knows that credit multiplies and by giving credit to team members, he will also be getting credit for managing that team
  – Sets good examples by doing what he expects from the rest of team himself. For example he also comes in when he asks the team to work weekends and makes sure the team has what it needs to be successful – and yes that might mean as a manger to get the coffees or pizzas if the rest of the team is busy and the manager can afford the time.
• Ownership of the outcome
  As a manager you own the outcome of your team and yes that includes any dependencies that the team has to manage. As a manager it is your job to get things done with the help of your team – the times of “the dog ate my homework” are now truly over…sadly 😉 You should consider any deliverable that your team produces as your own deliverable, so make sure you are comfortable with it. Trust the team to get it right, but check on it as you need to. You cannot claim ignorance if someone in your team produces sub-par deliverables.
• Has financial and schedule control for the project
  No matter whether it is explicitly stated, the expectation is that a manager knows what budget and schedule he has to work with and that at any point he knows how much of it has been consumed. If it has not been explicitly mentioned, you should get this information and understand how you can track it. If no support is provided create your own tracking mechanism. Communicate the status of budget on a regular basis to make sure that people are aware when things change and can let you know when external factors change (e.g. budget reductions). It doesn’t matter whether you run a small team or a large project this basic is important and the earlier you learn it the better. You might never get asked for it (good news) but when you are (mostly when things start to turn bad) you are ready and have all the answers
• Communicates double as much as he think he should
  As a manager you are likely not working on your own tasks anymore (if you do, lucky you!) so a lot of the work is in stakeholder management. It does not matter what you think, it is likely that you don’t communicate enough. There is so much noise out there in regards to emails, collaboration tools, text messages, etc. that your job is to communicate with the target of being understood. You will have to tailor your approach to each individual. If you have to refer back to a memo from a while back when being questioned about a decision is bad news for you. You want to make sure your stakeholders are well informed and never surprised. That means over-communicate at all times and check whether you have been understood. Sometimes you will have to try several times before you are understood. If anything changes on the project, communicate this and the reason for it as early as possible even when its bad news. Bad news only get worse as time goes by.

• Respects the basics and makes sure his team adheres to them
  The manager feels responsible that his whole team adheres to the basics of professional behaviour and provides feedback when this is not the case:
  – Meetings run efficiently, have agendas and notes are sent around in timely fashion
  – Actions are defined by “Who does What by When”
  – All major work products are documented at sufficient level
  – Commitments are being upheld and when things change it gets communicated early
  – Everyone in the team treats other people with respect and behaves professionally
  – Team members adhere to corporate policies
• Knows his team and himself
  Besides delivery of the business outcome, a manager helps everyone to improve. This means he understands the ambitions of each person in the team and coaches them to achieve these ambitions. He has a plan for everyone in the team and a succession plan for when its time for someone to leave the team for bigger and better things. A good manager plays to the strength of the team members and does not focus on the weaknesses. He staffs his project by getting a diverse group of people with different mindset and working preference to avoid group think. He encourages productive arguments and discussions and steps in when they become unproductive. He also knows his own limitations and is able to ask for help from his team. Last but not least he always knows who is doing what and is aware of the status in case someone asks.
• Escalates early and transparently
  A manager is careful when reporting status and risks, which means if in doubt she adds a risk or changes the status to something different than green. While many supervisors don’t like additional risks or non-green status, the ethical correct and best thing to do for the company is to provide the status to the best of the knowledge of the manager. Any doubts or concerns should not just be in the managers head (she might win the lottery tomorrow and disappear to the Bahamas) but rather be documented and represented in the status report. Someone once told me that a project status is amber until you have the first working version, as any green before that is absent of any objective validation. I like that, but perhaps wouldn’t go as far with the reporting. A good manager also never hides anything. While it is not strictly lying, omitting something relevant is pretty close to it, so similar to the earlier point you should rather overcommunicate so that there a no surprises, ever!

I know that there is probably a lot more to be said, but the above are for me critical things I want to see from a manager above and beyond and project or technology specific things. After all each project is different but the above characteristics create successful teams and winning cultures. Something we all aim for.

The good news first: our little one is still alive 😉  All the abstract talk about being a full-time dad has now become my reality. We do not have family around us here as our families live in Sri Lanka and Germany respectively, so there is not a lot of help available. I have been pretty hands-on before as well, getting the little man to sleep, making him food and feeding him and of course changing lots of, let’s say smelly, diapers. But that has been nothing in comparison with being a full time dad.

One could say I swapped getting screamed at for not fulfilling unintelligible demands by my supervisors with having the same experience just from a much younger little man. I have to say this little man is much cuter than the alternative. I do think the little one is missing his mama during the day and first had to get used to me being around all the time, but by now we are making an okay team.

We are definitely rocking the ball slides and the construction toys – two men hard at work. And yes i have already bought two new toys for us to explore this week. Might be an expensive few months if I keep finding cool new things to explore with him. This week still held a few work related activities that I had to finish off for me – after all it’s salary update time and the people who report to me deserve to hear the news from myself. Although in this case with a very excited little man making himself heard in the background. From next week, I hope to go cold turkey on work emails and we will see how it goes…perhaps just the odd glimpse when the little one is sleeping…we will see how strong the addiction to email is.

This week I also had the chance to show the little one our new office and he had a great time meeting many of my colleagues and looking around the modern office. Of course his daily routine got disrupted by our little adventure. So far I am enjoying the experience and the world at work is not coming to an end. It was a slow letting go of work as I spoke to someone at work every day. Next week I will hear less from work I think. Let’s see. The weather is certainly incentivising me to spend more time outside in parks and cafes, that’s a performance objective I am happy to work on…

It’s over again. The annual DevOps family reunion in San Francisco. This year was extra special because I feel I learnt even more than in previous years and because I was able to hand out preview copies of my upcoming book. I am really looking forward to hear from those of you who got a copy what you think. Reach out and let me know. I will talk a little bit about the book in an upcoming blog post.

The summit had a lot more variety of topics than previous years (at least the talks I attended), which I found very refreshing. Technology talks, culture talks, security, case studies, agile – so many different perspectives on IT transformation. Congratulations to the program committee for getting such a good mix and balance.

So let’s recap what I have learned from the summit.

Keybank presentation

This was clearly one of my highlights. Hearing from a bank which is using microservices and the Netflix OSS to stabilise environments was great. To then hear they were able to outperform expectations and delivery faster and with increased scope, just shows what is possible when you get this right. Well done team and looking forward to hear more in the upcoming years. They mentioned one really interesting ideas that I will take away from the conference: “It is not a reason not to automate something if you don’t do it frequently. In fact you should automate in those cases as you don’t get a lot of practice at it.” I will remember this.

John Allspaw

Of course the expectations on my side were high when I saw John will speak. And boy did he deliver. A fascinating talk about how we cannot see what we do directly but rather work with models in our head and manipulate it via a keyhole – the screen – to interact with the invisible system. This makes you think. It requires us to move from incidents as motivators for policy – towards incidents as messages of the invisible system to us that we should use to update the mental model. Incidents show where the models are misaligned. This is tricky to operationalise and speaks to us as individuals.

We should then look at incidents as unplanned investments where the cost is already fixed for us – so how do we maximise the ROI on it? Commonly Post Mortems value the actions items at the end, but more important is the updated mental model we should have at the end. Questions to ask beyond “What went wrong?” and “How did it break?” We should talk about what made it not nearly as bad is could have been. And how can we continue to learn about the invisible systems. This talk created a lot of conversation over drinks. Mind Blown!

Scott Prugh and Erica Morrison from CSG

The continuation of the CSG story which is familiar to many of us. Good to hear they continue to challenge the status quo and push forward. The metric of the conference was “how much sleep do I get when we make changes” which moved from very little to a lot. It also showed the need to shift from a more dev focused devops to a more ops focused or balanced view and what it does to the incidents in production. And of course we might never forget Scott with a sledgehammer destroying mode 1 once and for all…

Columbia’s Scott Nasello

A story of just getting on with it and doing the right thing to improve the situation. Not a transformation with funding etc. A good reminder of what can be done if you really want to do something. The stories around Configuration management as foundation to everything – from emailing scripts to proper SCM – sound very close to some of the things I have experienced. And then the innovative approach of swapping people out regularly to create that constant beginner mindset that allows you to question things and to learn new things. Really interesting approach.

And of course the coolest random fact: It takes only 29 dominoes to take down the empire state building. Yes really!

Damon Edwards

I liked this presentation just like all the other ones that Damon has done. A good reminder that Ops is more than deployments and pipelines. I liked the insight that ticket driven queues are a sign for silos in your org. And that tickets should be for exceptions not for actual work. He went on to define Ops as a service – definition of automated procedure, execution of it and governance – which is a framework I will surely use in the future. Thanks Damon.

Amazon

This was a good industry story of the need for immediacy and how this will continue to increase. They had to learn how to integrate across multiple teams and how you need have teams that look after the end to end business service. I also learned a new word: “hyperconvenience”

Disney – Jason Cox

Phew – Finally I could attend a full talk from Jason – yay! Of course the videos were awesome and a Star Wars trailer always gets my full attention. I could very much relate to the analogy of “corporate” services perceived as the empire. Even though all you want to do is help the team and how they had to overcome this perception. I also really liked the technology rotation program for managers to continually challenge the status quo and build empathy across the business. And of course I wish I could call my training program “Jedi Engineering Training Academy” – best name ever for a training program 😉

Pivotal – Cornelia Davis

Really good semi technical talk about cloud native applications – I will definitely will buy her book. She spoke about:

• Dynamic load balancing
• Statelessness in the architecture
• Application lifecycle – events have rippling effects – you need to ping and deal with it automatically
• Versioned services and deployment in parallel not replacement of services
• Dynamically updated router for service discovery or a dedicated server to manage it
• Data APIs and caching is important to decouple from database
• Or a database per microservice and event driven data propagation, commonly using kafka as unified log and universal source of truth

Nicole Forsgren

The queen of DevOps data did not disappoint. Nicole went through 4 years of learnings. Most importantly how throughput and stability move together and are not a tradeoff.

That you should use MTTR, lead time to change and deployment frequency as good measure to understand improvements. And that when you improve DevOps performances it is likely to improve organisational performance. Nicole also shares my scepticism about maturity models which are aging too fast due to changes in capabilities. I think they can still be useful in the right hands, but one has to be careful. In a room full of techies she challenged us with “Tech plus”: It takes  IT combined with other things to make companies successful.

Her litmus test for DevOps success: “can you deploy on demand, independently and during business hours?” And if you don’t know where to start, take her advice and look at  Architecture, Continuous Integration and a lightweight change approval process as good starting points

Unfortunately I could not attend the third day of the conference, but I will surely catchup on the videos later. I will certainly be back next year and look forward to hear what everyone else learned this year.

Thanks Gene, Thanks organising team, thanks DevOps family – looking forward to see all you brothers, sisters and cousins at the next family gathering with Papa Gene 😉

You might have wondered why there have been so few updates recently on my blog. The answer is twofold a) my creative juices have gone into finishing off my book (DevOps for the Modern Enterprise) and b) earlier this year my son was born, which is the best possible reason to spend less time in front of the PC. As things are settling down I will start to write more frequently again, which brings me to today’s post: I have decided to write some blogs about my upcoming paternity leave, so you will see some less technical posts in between technical posts.

The reason I decided to do this is to encourage more fathers to take paternity leave and get them some honest first hand descriptions on how it plays out. I have learned over the last few months that many fathers have not taken paternity leave for many different reasons: career, company policies, being unsure what to expect as full time dad. So I decided to write about my experience.

I am about two weeks away from taking around three months off as full time dad. My son is 9 months old and he is a handful. I have heaps of respect for the work that my wife is doing to keep him on a schedule and look after him. The long nights of getting him back to sleep and looking after him during the days sound tough…soon I will know first hand how it is, something that so far has been limited to weekends when I don’t have to work.

You might wonder whether I am worried about what will happen at work when I am gone for such a long time and the truthful answer is “a little”. Of course there is that little voice in my head telling me that lots of important things will happen while I am gone and that I should really be there for it. But then I think of my incredible team that will cover for me when I am off and I know they will do a fantastic job. Over the last few months they already picked up a lot of the scope of work that I would usually deal with and have done great. My bosses are extremely supportive of me taking my paternity time and understand that things will be a little bit different for a period of time.

Until recently I thought that work (and potential career impacts) are the only things to worry about, but then I started to hear from mums and dads on how tough it can be to be the full time parent, the days where you only speak “baby language” and miss a meaningful conversation. The days when all hell breaks loose and you struggle to keep the baby fed and clean. The days when finding the time for a shower and a warm meal is a real challenge. The days when you had hardly any sleep and the little one wants his normal routine while you can hardly keep your eyes open. Phew…

Perhaps this gig is going to be tougher than I thought…but then I look at the little man and see him smile and I know I will enjoy the time no matter how hard it might be. Work will go on and I am sure I will catch-up when I am back. My team will do great and I will see my little man grow over the last 3 months of his first year in this world. I will keep you all posted how my paternity leave is playing out with regular blog posts.