In the experience of leading a DevOps team, some team members have the concern about being a DevOps engineer:
Concern #1: Is it better to be a developer because writing programs looks more competitive? However, we seem to be just doing the integration of various tools.
Concern #2: Only developers deliver the value to end user because they face the market requirements, but we not.
Concern #3: Is the DevOps team no longer needed after completing the tool chain?
Being Committed to Yourself, That Is Engineering
Every field of engineering definitely has its domain knowledge, the differences are just the techniques, tools, and target users. Although IaC, or any XaC tools are not like the well-known programming languages such as Java, TypeScript, Python, etc., it is still necessary to logically consider the flexibility, modularity, and to ensure the quality through testing. Sometimes, it needs to be more cautious because it is the foundation or related to the policy, so its impact is also relatively large. Besides, in the various tools, choosing one that suits your organizational culture, process, and team is also a big decision to make, and it is important not to fall into cargo cult. Therefore, always having the curious and positive mindset, doing the things right, this is the beauty of engineering.
Building DevOps Platform with Product Thinking
In some situations, the DevOps team may feel exhausted of integrating tools and fighting fires, and do not know what is their role in the organization’s roadmaps, and what is the value they delivery? But, try to image, if the CI/CD pipeline cannot provide service, the stakeholders will get crazy because the value cannot be rapidly delivered to market, and bugs or outages cannot be immediately resolved. As an important role in business, it needs to be treated as a product, and with the support from organizational culture (executive buy-in), not just a project. DevOps engineer needs to communicate with the stakeholders(e.g., auditors, security team) and the customers (e.g., development team), and create the user stories with “who”, “what”, “why” as well as acceptance criteria.
As a developer, I need the metric dashboard, so that I can monitor and analyze the status of the service in the production environment at any time.
As a product owner, I need a robot to alert responsible development team if their application keeps crashing in the production environment, so that the developers can quickly be notified and fix it.
Besides, the demonstrate and promotion of the platform can make platform users get closer to the platform, and DevOps team can also collect feedback from their users. Just like products sold to the market, let every DevOps team member clear the goal of the product and the added-value is such an important thing for real DevOps.
There is no such thing as a 100-point process, and even if it is perfect now, it may not be true forever. We often see that many cases have been using the same approach without continuous identification of the bottleneck and improvement, and then finally lead to failure. A DevOps team absolutely needs to be formed for the long term, not being disbanded along with the projects ended. To provide effective platform and processes, DevOps team and their users should collaborate without silos, to keep finding the waste and toils in the process, and put the improvement missions into product backlog, which towards to a smooth process and user-centric platform.