Presented at LAST 2019: So you walk into a new company, get the lay of the land and then realise, crap! Their development processes are like they were design by a bunch of first-year uni students doing a group project. There is no DevOps to speak of. There are snowflake servers everywhere. Their git branching strategy is unmanageable. They run tests only every 3 or 4 releases. Their deployment is manual and different for each release. The have no real alerting. Ok. Take a deep breath! Calm down. So much to do, but where to start? The business has produced a list of improvement actions, but those actions are focussed around fixing the symptoms of the problems, not solving the root cause. The business does not understand that the path to DevOps improvement is complex and each task has many inter-relations and dependencies. This is the problem that I faced about a year ago. To overcome this, we went through a process of defining all of the DevOps tasks we could think of and mapped them into a dependency diagram. This diagram was useful to communicate both internal and external to the team. In this case study, I’ll go through the process to design the dependency diagram, but also our progress through the diagram one year later.