DevOps as a Service. Part 4. We solve the problems of development of employees of the unit and management of initiatives

DevOps as a Service. Part 4. We solve the problems of development of employees of the unit and management of initiatives

Good morning everyone! With you is Oleksandr Krylov, and we continue the series of articles about DevOps as a Service, and how this approach can be used to solve a number of common problems. In previous articles, we described the approach itself, showed ways to solve various problems. You can read the articles here Part 1, Part 2, Part 3. Today we will talk about building the development process of employees and the team as a whole, as well as the process of managing initiatives.

Continuous education

First of all, we should understand the strengths and weaknesses of each employee in the unit. We will certainly start with hard skills, but we will not forget about soft skills either. Let’s imagine that we do not have any information on hand, and we will collect it from scratch. Who will we go to? That’s right, to the management – to understand the current goals and tasks at least for a quarter, but better, if possible, then for the whole year with a breakdown into quarters. Do not forget to ask about the plans and strategy of the company, because there may be an intersection with the emergence of new technologies, tools, processes, which may also affect the employees of the unit. That is, if the whole process is divided into stages, then ours first stage – Removal of information from the management.

We remove information from the manual

At the second stage we refer to the stack again. If within the framework of the timeline we have already studied it, as described in the article Part 1, then now we should remove the feedback on the desire of the employees to develop this stack. Here you can split into different streams, for example:

What could it all look like?

CI/CD

We took the stack AS-IS, and now we have to think about TO-BE. If, according to the results of the discussion with the team, everything suits us in CI/CD, then we proceed to the following restraints: monitoring, etc. If we understand that everything is “ok” with the point above, and we will not change anything, then it is better not to mention it during the further discussion with the management. Suppose we need changes for monitoring. In this case, the scheme will look different.

AS IS -> TO BE

We collect each of the elements of the infrastructure in this form, and we do it until we have formed the entire set of target architecture and tools that can be called target. But as you and I understand, they cannot become targets until they are agreed with management, unless, of course, you have such power and decision-making authority. In startups, this may be so, in medium and large businesses, such an opportunity may not be.

And this brings us to 3 stages – the application approval process.

Please agree

If you have an architecture department and a CTO to discuss this with, then prepare a detailed slide desk on each element of the infrastructure in the AS IS -> TO BE format with explanations and arguments for each change in both configuration and technology.

Here it is important to remember that we want to solve not only the problem of employee development, but also to improve the process of managing initiatives and introducing new technologies. If the company does not have a single process for validation, piloting and implementation of technologies, why not do it in parallel?

Before doing this, I suggest asking and immediately answering a number of questions, based on which we will be able to understand what will suit us best: Archcom, Techcom, NAP or something else.

Let’s break down each of these definitions and get to the questions.

Arch committee or architectural committee is an Enterprise & Solution discussion platform for architects, which is held on demand and solves architectural problems. Not always, but it can also include the most experienced members of the development, architecture, DevOps, DevSecOps, testing teams. The leader of this committee is the CTO. In addition to solving architectural problems, the committee can also deal with blocking or unblocking technical debt and consulting on solution architecture. And his workflow might look something like this:

Archcomm process

Technical committee or technical committee – an expert platform for discussion and validation of the introduction of new technologies in the company. Unlike the architecture committee, it consists of a narrower circle of high-ranking individuals and is selected by the CIO, who is the leader of the site. Each meeting is minuted, decisions are made by majority vote.

Next action plan (NAP) – the process of managing initiatives of the DevOps division, which can be expanded by members of the development and testing teams in order to stimulate and manage initiatives for piloting and introducing new processes and technologies into the company. In companies where there is a NAP and a Techcom or an Archcom, the NAP always acts as a tool for validating initiatives and piloting them before they reach the Techcom and Archcom. PS – the names may sound different in a number of companies.

With the definitions established, now we will move on to questions and answers to them (we will invent the answers).

  1. How often do we introduce something new? Once every few months

  2. Do we have regulations or guidelines for conducting pilots? No

  3. How often do we get to pilot something? From 2 to 5 times per six months

  4. Do we have a technical platform for discussing technology implementation initiatives? No

  5. How often do we need to review the product architecture? No more than 1-2 per year

  6. Are security guards involved in the implementation? So

  7. Does the company have a technical security unit? So

  8. How many systems and projects does the company have, and how often do new integrations between them need to be done? Multiple products, let’s say 4, new integrations are not often needed.

Based on the answers received above, by which we can judge the maturity stages of the company, we will try to determine which process will be the most suitable for implementation.

  1. If the use of something new, in particular research, does not happen regularly, for example, 1-2 pilots per month, it makes sense to manage only the pilots themselves, initiatives from them and their results. In this case, NAP will be sufficient.

  2. If there are no such regulations or instructions for conducting pilots, why not create them? Even if pilots are not such a common story, having such a document will definitely not be superfluous from the point of view of speeding up the process, both in terms of input data and analysis of the result of pilots.

  3. 2-5 times per six months is, of course, not enough. This suggests that either the company does not have such a need, and there is nothing wrong with that, or the company’s processes are not yet mature enough, and therefore it makes no sense to burden the company with the bureaucratization of processes at the expense of the implementation of the Techcom or the Archcom, enough NAP.

  4. If not, then why not do it, but let’s start from the answers to the questions above, which will work best.

  5. If we have only a few products, and not 10+ systems and a bunch of projects, then this is probably one of the main criteria in favor of the fact that Techcom is definitely not needed here. Archcom, maybe, but as a rare phenomenon, and NAP fits right in.

  6. This is good, so there should be some requirements for the security of the product and its development, if not, then it is worth thinking about their appearance.

  7. It is always a good sign that if there is no security department, then it is worth making sure that it appears, based on the needs of the business and the company’s product development strategy. A good tone is the entry of security representatives into Tech and Arch Committees. As for NAP, a DevSecOps specialist with a minimal set of technology requirements will suffice here.

  8. Such an answer makes it finally clear that the company has enough NAP process, because the maturity of the processes is lacking in the introduction of the Arch Committee or the Technical Committee. There’s nothing wrong with that, but at this stage these committees could do more harm than good through increased bureaucracy.

The conclusion is that the application of NAP is sufficient.
What can this process look like and what components does it consist of?
Components:

  • what do we need?;

  • what are we missing?;

  • what are the problems?;

  • initiative.

And then we go through the process:

  1. We take the company’s problems and tasks for the year;

  2. We understand which processes or technologies can solve them, and which of them, in turn, are not yet available in the company, while removing information from initiatives and wishes;

  3. We validate all this;

  4. We schedule status meetings to discuss initiatives and what should be piloted;

  5. We pilot selected initiatives;

  6. We study the results of the pilot;

  7. We legalize the implementation of what was piloted, if, of course, it is successful;

  8. We implement.

This process should be turned into a routine, and iterative meetings should be scheduled, for example, once every 3 weeks, where each new initiative and the status of current ones will be discussed. Schematically, the process will look something like this.

Next Action Plan process

And visually, for example, in the knowledge base, like this:

Now, let’s get back to where we left off about technology implementation validation. Let the use NAP we had 4 stageswith the help of which we validated all the technologies described in TO-BE and agreed on their implementation.

5 stage we will try to formulate a mechanism for the development of employees and the team. If the company does not have an accepted grading system or KPI, MBO or other mechanism of quarterly goals and its evaluation, this will both complicate and simplify the task at the same time. It will be simplified in that you will be able to correlate the employee’s development with the unit’s goals for the year, which you will set yourself and agree with the management, and you will also be able to develop a grade system and a competency matrix yourself. Difficulties here, in my opinion, will arise in two moments:

  • from the point of view of the lack of additional financial motivation, if there is no bonus to the goals and KPIs;

  • At first, you will have to go almost blindly with considerable labor costs to collect information from each employee of the unit. If there are up to five of them, it will not take much time, and if there are more, it is better to do it through team leaders or through the mechanism of polls.

Let’s go to the solution of the problem, and this solution for us is the implementation of the concept of building an IPR or an individual development plan for both all employees of the unit and for the unit as a whole. Thus, we will form a strategy for the development of each employee with his individual goals for the quarter with the development of the entire division with quarterly goals.

How is IPR formed?

  • we take the company’s tasks for a year;

  • we take MBO or KPI of the company for the quarter;

  • we correlate all this with quarterly projects and “wishes” of employees, including additional training and attendance at conferences;

  • validate all this;

  • and we get the first version of the IPR.

If everything is OK, we give it to the management, undergo additional validation, after which the employee’s final IPR appears, the implementation of which we monitor during the quarter, including when you can ask questions at one-to-one meetings. Thus, we close the problem of lack of control over the development of both each employee of the unit and the team as a whole.

Schematically, the IPR development process looks like this:

IPR process

Let’s add to this process and divide it into 2 phases, the first of which can be used as a decision-making mechanism in favor of the successful completion of the probation period by new fighters.

Phase 1. Onboarding:

  • interview;

  • offer;

  • appointment of a mentor;

  • formation of IPR for a trial period;

  • mid-section after 1.5 months regarding the implementation of current IPR tasks;

  • control slice at the end of the trial period.

Phase 2. IPR for a year:

  • skils;

  • strengths and weaknesses;

  • goals and strategy of the company;

  • quarterly goals of the company and divisions;

  • new projects and technologies;

  • the wishes of employees – training, technologies, conferences.

Phase 3. Control:

  • every month we discuss the current status with each one on one;

  • once a month, we monitor and communicate on newsletters about the division’s tasks for the quarter;

  • once every 1.5 months, individual and team intermediate sections;

  • by the end of the quarter summing up and planning or adjusting to take them into account the next quarter.

Worked well

Thus, we killed two birds with one stone – regarding the process of introducing technologies and stimulating initiatives, as well as monitoring the development of each member of the unit and the service as a whole.

In the next article, we will consider ways to solve problems related to increasing the competences of IT departments in the company and approaches to working with the backlog. And a little spoiler. In the first article, I talked about the implementation of the DevOps as a Service approach, but did not describe the criteria for choosing it – why, for example, not DevOps as a Platform or other approaches. At the upcoming DevOps Сonf 2024, I will cover this in more detail, followed by another article that expands on the first in terms of how to choose what to implement in a given situation.

Well, Oleksandr Krylov was with you, see you soon!

Related posts