So as I sat in theatre F at DevOps and Cloud World listening to a talk on Waterfall — Agile — DevOps — NoOps and pondering upon all these different terms being used by the panel to steer the discussion, it dawned on me that in reality at the core of DevOps lies Empathy. Design thinking employs a similar concept, a human-centred approach to solving problems.
DevOps is essentially a client-centric operational philosophy in a (software driven) ecosystem that combines people, processes and technology to help deliver technical vision, drive business value and achieve operational velocity.
Empathy, you say.
In case of DevOps teams using Empathy and having a customer-centred (which can be a dev or perhaps even another system) approach in its implementation, what does it actually mean, you ask. Let me elaborate with an example:
Let’s say a delivery manager and his team of talented devs and project managers are working on a greenfield project. Now under the most basic standard model an Ops or service management individual (in a siloed organisational structure) would just wait for the project team to provide requirements document, provision Infrastructure accordingly, do any handovers and get back to their seat. If the dev team needs access to logs or a copy of the database for troubleshooting, they have to raise a ticket and Ops team find the right logs / db dumps and provide them with those, so on and so fourth.
Now that works fine in smaller teams and maybe that’s what you want but by spending more time with the team and individual devs initially (or even better at the stage of initial dev resource allocation meeting) you can build a mental map and try to understand their potential frustrations / pain points and use them to ideate / suggest workflows that will allow you to build workflows and iterate over them with a growing team ultimately delivering value across the board and giving you more time to drive cultural change and deliver excellent service.
You can build a mental map and try to understand their potential frustrations & pain points and use those to ideate / suggest workflows that will allow you to automate processes.
AutomatedOps
So for the above example, on a simpler side to make sure the team has access to centralised logs, you would push logs to a central log collector and give devs access to that portal or in case of a db or have a copy of the db available on a local dev server ready to be used for troubleshooting.
Now the above can be extended where you build custom utilities which allow developers to get access to the logs / APM / db dumps as if they were available locally or if you want to go all fancy (which is what I have been doing over the past few years), implement a ChatBot (Essentially a Workflow bot) which allows the team to perform all types of tasks from getting a copy of a db to triggering complex CI / CD pipelines spanning multiple systems and integrations. The simplicity (despite the complex nature of how the bot accomplishes these tasks) of this approach is that if you integrate it with a collaboration / communications tool like slack or hipchat, you now can give the power of this approach to teams sitting anywhere in the world. Your can scale the team rapidly and it will scale with the team because of it asynchronous nature and you can extend it as and when you feel there needs to be new feature or system integrated. QAs, project managers and even account managers can deploy code to QA / testing / demo environments allowing flexibility.
This also means that you don’t have to adapt a specific DevOps model created by someone else instead you build devops roadmap based on the needs of the business and deliver value to the entire organisation.
Empathy is an important tenet not just in DevOps but also in any position you might be, but in the context of DevOps it seems to be a non-tangible transformative abstraction allowing immense cultural change and business value.
Now all of the above doesn’t come without some caveats, the major one being able to write code as an operations person which is becoming more common as the boundry between Dev & Ops fade slowly. The velocity you gain by allowing different stakeholders to get involved in SDLC and release processes with constant feedback loops has huge benefits. Everyone gains from getting involved but without having to learn really complex systems, for non-technical stakeholder its as simple as delegating a task to AutomatedOps (in which case is a bot).
Empathy is an important tenet not just in DevOps but also in any position
you might be, but in the context of DevOps it seems to be a non-tangible transformative abstraction allowing immense cultural change and business value.
