12

People Hiring, Incubation, and Mobility

This chapter is dedicated to your most valuable asset in the DevOps 360° evolution: the people. The chapter will start by briefly outlining the value proposition of people in the DevOps 360° evolution. We will continue by highlighting the importance of creating Π-shaped DevOps professionals during the evolution, as well as the need to be forward-looking by ensuring that our DevOps-related professions will be fit for future purposes. Afterward, we will move into the domain of hiring for our DevOps 360° evolution and we will outline what we consider to be the most important elements of our hiring strategies. In that section, we will give complementary tips and recommendations regarding the value of 360° interviews and precautions on using external parties to scale. The second part of the chapter will be dedicated to the topic of people incubation. We will examine the importance of incubation for both leaders and people on the ground, why you should be conducting your incubation in a targeted and relevant manner, and how absences in or limitations on your incubation means can severely jeopardize your evolution. This chapter will close by providing the value proposition of people mobility for DevOps while providing 360° evolution considerations derived from real mobility cases.

In this chapter, we’re going to cover the following topics:

• The value proposition of people in the DevOps 360° evolution
• DevOps Π-shaped profiles
• Strategic considerations in DevOps hiring
• DevOps incubation recommendations
• Practical DevOps mobility cases and precautions

The value proposition of people in the DevOps 360° evolution

We have smoothly reached the last, though definitely not the least, important part of the DevOps 360° operating model. In this chapter, we will focus on the most valuable asset within your DevOps 360° evolution. This refers to people. In contrast with the preceding chapters, in this one, we will not give a lengthy value proposition. It is a rather obvious one, in accordance with a Greek saying, “τα εύκολος εννοούμενα παραλείπονται.” In English, this means “What is obvious can be deliberately omitted.” Therefore, I will briefly summarize the value proposition of people in the DevOps 360° evolution in one sentence, and we will move on to the essence of the chapter:

People: the most valuable and challenging-to-acquire asset that will enable your DevOps 360° operating model.

In this chapter, we will focus on three important elements concerning people:

• Hiring: The process of bringing new people and skills into your organization
• Incubation: The process of uplifting your personnel’s DevOps skills
• Mobility: The process of mobilizing people across the various DevOps 360° enablement and adoption domains

In the coming sections, we will go a little bit broader than the mainstream job descriptions, one-to-one meetings, and proposals to have all your people certified in Google Cloud Platform (GCP) as an example. Our focus will be on some decisive recommendations and perspectives on how to approach DevOps hiring, incubation, and mobility. In this chapter, you should not expect to find complex concepts and terms. We will be plain and concise about the context. You can actually perceive this chapter as a small DevOps people pocket guide of tips and recommendations.

Just to make sure (on people and culture)

In this chapter, we are following a lighter approach compared to other chapters, not because the people side is to be downplayed (unfortunately, it often is in reality) but because I consider people (and consequently, culture) a very context- and case-sensitive element of your DevOps adoption. This context and case sensitivity makes the people aspect of DevOps not very applicable to being addressed using proven practices, frameworks, and patterns. It requires more sophisticated and delicate means that heavily rely on specific use cases.

Question: did you notice that this is the first time in the book that I have mentioned the word culture? Culture in my opinion is not only heavily context-sensitive but also intangible and of historic organizational roots that require deep awareness of its evolution. In my opinion, only when someone is within a situation (and I am not working in your organization) can they provide advice on how cultural matters pertain to DevOps. Therefore, I’ll leave it totally up to you on how to handle it, because you are the one who knows your organization. As I respond to every single new manager who hires me, when I am asked “What do you plan to do with the people?” – firstly, I get to know and understand them.

The importance of creating Π-shaped profiles

Before starting to structure your hiring, incubation, and mobility tactics, you need to define what DevOps profiles and professions you wish to create as an organization. Your focus should not just be on the engineering roles, but also on architects, process governance, and regulatory governance profiles – basically, the ones that directly and indirectly will have a stake in the DevOps 360° operating model. Are you going for a certain number of generalists and a certain number of specialists?

When defining the DevOps profiles and professions, there are some important questions that you need to answer collectively. Do you want your people to be able to get the big DevOps picture, while also being able to deep-dive into certain areas? Is full stack engineering the way to go? Or might that create DevOps Swiss army knives with a lack of deep expertise and people knowing everything and nothing at the same time? And if you decide to balance the breadth and depth of DevOps, how broad and how deep should you go?

I have come across these dilemmas in several DevOps evolution contexts in my career. And in all cases, there was a certain approach that was ideal and could fit every context (of course, upon tactical incubation). That approach is what is called in the industry the creation of Π-shaped profiles and professions. But what is a Π-shaped profile or profession? Π is a letter in the Greek alphabet (too much Greek in this book!). It is the equivalent of the letter P in the English alphabet. What is of interest in our DevOps case with regard to the Greek letter Π is not to do with linguistics but its shape. Take a close look at it. You will notice that it consists of a horizontal line with two vertical lines beneath. In our DevOps profiles context, the horizontal line symbolizes the breadth of DevOps knowledge, and the two vertical lines are the depth of the two domains of DevOps expertise. In simple words, a DevOps Π-shaped profile or profession characterizes a DevOps professional or practitioner that has broad DevOps knowledge and subject matter expertise in two DevOps domains. The following figure provides a representation:

Figure 12.1 – Examples of Π-shaped profiles for a DevOps engineer

But what are the benefits we have seen in organizations of creating Π-shaped profiles?

• We ensure that people have broad DevOps awareness and therefore can connect the dots of the big picture, consequently understanding how they are to contribute to it. To some extent, they are actually able to grasp the complete DevOps 360° operating model.
• We build expertise in people. Not only do we move away from generalists, but we also enable people with primary (leading) and secondary (shadowing) expertise. This primary and secondary expertise enables us to ensure contingency and mobility.
• We moved away from the fallacy of full stack engineering. DevOps Swiss army knives do not work. You need specialization – in other words, to demonstrate that you know your DevOps stuff in depth, as in, to demonstrate DevOps expertise.
• We provide career paths to people and also a broad variety of DevOps tastes in their daily work, eliminating DevOps single-domain fatigue.
• It allows us to slice the responsibilities across the DevOps 360° technological ecosystem more dynamically, building cross-team complementary skills.
• We employ four-eyes principal peer reviews and senior/junior peering in truly cross-functional teams.

Is FSI knowledge a requirement of a DevOps Π profile in the industry?

It used to be high up in job descriptions, but in recent years, it has simply become a nice thing to have. The talent war in the market does not allow such luxurious requirements. It’s preferable that you know Azure DevOps and resource management templates rather than cross-border payment flows. Nevertheless, FSI knowledge is a strong asset when pursuing opportunities in organizations.

Comparing Π-shaped profiles to other profiles

I will keep this short while adding a couple of extra arguments on why Π-shaped is the most sustainable way to go. Typically, DevOps professionals and practitioners fall into one of the following categories. In each of them, I have cited some disadvantages that I have observed in my career:

Table 12.1 – The disadvantages of different shapes for DevOps practitioners and professionals

Advice

Please get people with deep and broad DevOps expertise to design the Π-shaped profiles, not any random PMO or HR person.

The importance of predicting role evolution

You must be forward-looking with your hiring, incubation, and mobility tactics. The world is moving fast with new technologies emerging and evolving in the blink of an eye. The situation does generate business opportunities, but also requires adaptability for these opportunities to be pursuable. Certain DevOps roles and professions might advance, stagnate, or be eliminated in the years to come. Do you need to hire skills that you might not need in 2 years? Being able to predict (or follow) the future developments of DevOps professions is decisive. Using your current DevOps roles and professions as a baseline, you need to ensure that your current hiring and incubation actions will make your organization fit for future purposes. Perfect data you will not have, but you will definitely have a good number of intelligent technologies that can predict how your DevOps-related professions may evolve in the future. The following figure provides a representative example:

Figure 12.2 – How roles involved in the DevOps evolution can develop

Strategic considerations in DevOps hiring

In this section, we will outline some tips and recommendations derived from real use cases to consider as part of your hiring strategy or tactics.

Starting by defining your hiring strategy

I am certain that you do not have either the quantity or quality of people that you need to enable and adopt your new DevOps 360° operating model. Even if you think you do, as we mentioned in an earlier chapter of this book, it will be to the advantage of your DevOps 360° evolution to bring in some new blood that can disrupt your current DevOps status quo. Usually, organizations define certain hiring strategies to back up their DevOps endeavors. These hiring strategies can range from purely simple to rather complex. The parameters of the following table are the ones that I consider the most important as part of defining your DevOps hiring strategy:

Table 12.2 – An overview of a sample hiring tactic

Did you know?

European incumbent banks prefer countries such as Poland, Lithuania, Bulgaria, Romania, and the Czech Republic to establish nearshoring DevOps capabilities teams. I have worked with Polish and Lithuanian teams and the engineers there are great. Trust me.

Introducing 360° interviews

360° in the DevOps hiring context indicates interviews being conducted by a sufficient cycle of relevant stakeholders, assessing both the broad and conceptual as well as technical and specialized DevOps knowledge of the candidates. This practice will give both you and the candidate a more spherical view and I highly recommend it. Where applicable, if you are hiring a business application-focused team, get them to also talk to the team’s product owner so that they also get a good feeling and insight into the business domain they will be working with. Note that the 360° rounds do not all have to be formal interviews. Some can be coffee talks. In coffee talks, you are not really assessing the candidate, but you get a better feeling of who the person is, and the person gets a better feeling of who you are.

Two tips

Test their technical skills as the first thing in the interview process by conducting real-time, rather than home-based, assessments.

Wherever possible, be flexible about the specific technologies you require. A senior DevOps professional who does not have Azure experience but does have GCP experience, with a good mentality, the desire to learn, and some support, can learn (beyond) the Azure fundamentals in 3 months. Seniority is usually accompanied by agnosticism. Take advantage of that while you look for the perfect job description match, as in “the unicorn employee.”

In one of the banks I used to work at, in the engineering organization, we had CI/CD, private cloud, and public cloud teams. We got candidates to meet people from all three teams. That was, on the one hand, for us to get a spherical view of the candidate’s technical awareness, but also for the candidate to be exposed to our broader DevOps technological ecosystem.

A practical perspective of 360°

A very practical perspective of 360° interviews is in cases where a candidate is proven through the interviews not to fit the requirements of the hiring team but is more suitable for the requirements of a sister team. Having both teams as part of the interview enables you to efficiently swap the person for a different position if they are interested. I’ve done that many times.

On using third parties to scale fast

You will face difficulties in scaling fast in your DevOps hiring. This will naturally make you consider going to consulting firms asking for support. In my experience, going to a large consulting firm and asking about 50 SREs in one go will not work. Either they will not have them at all, they will have a limited number, or they will even send you random CVs to review just to keep you warm, wasting your time. The most sustainable way to use consulting firms is to go to small but very DevOps-specialized consulting firms. They will probably not be able to provide you with a scale of 50 SREs, but they will be able to provide you with 4 to 5 very seasoned SREs. With those, you will be able to make a much bigger difference in your evolution. Another alternative, and a quite sustainable way to do it, is to use incubation camps. These are basically recruitment companies that train or incubate young university students and prepare them for the industry. You can go to them with your job descriptions and requirements, and they will do the incubation job for you. Afterward, they will share the profiles and you decide whether you wish to move on. You can also use these incubation camps to incubate your own people. Either way, incubation camps can be a golden opportunity for navigating through extremely challenging market conditions effectively.

Last tip

Have your procurement and talent acquisition people establish a fast-track process for onboarding consulting firms that are not on your pre-approved list. There are some small DevOps boutiques out there with tremendously skilled people that most probably are not part of your procurement’s approved list of vendors. Put some pressure on them (procurement and talent acquisition) if they tell you, “But we need to go through a lengthy process to get them approved. Is it really necessary to use them?”. Losing out on good people for bureaucratic reasons is unwise.

DevOps incubation recommendations

In this section, I will open with a few political economy theories. Political economy is a sub-domain of international relations and can be easily related to DevOps.

Technological progress and human capital

Technology and human capital have a strictly interlinked relationship. The means through which the former is deployed in an organization can create a significant competitive advantage and is heavily dependent on the availability of the latter. For instance, let us suppose that two different organizations are building a GCP public cloud platform team. It is expected that the organization that is more advanced in terms of GCP knowledge and skills is likely to build a higher-quality GCP platform more quickly than the one that is less knowledgeable and skilled. Through the GCP example, we can safely and with certainty conclude that technology is directly proportional to the DevOps capability growth pace of an organization. Therefore, the organization’s people must have experience and expertise with certain technologies to accelerate this DevOps growth. Ideally, that expertise and knowledge of technologies must not only come with education or practical experience but with a combination of the two. In conclusion, incubation will be proven a core accelerator in your DevOps evolution. The accumulation of sufficient technologically literate human capital will enable the full exploitation of your technological means and capabilities.

In our context, with the term incubation, we refer to the process of supporting your people to grow in the domain of DevOps throughout the DevOps 360° evolution. Mainly, incubation will have two aspects for your DevOps 360° evolution. The first one is that you need to ensure that your organization has the necessary skills to enable and adopt the new DevOps 360° operating model. The second is that the DevOps job market is getting extremely competitive. With the demand for DevOps professionals exceeding the supply, not only do organizations have difficulty attracting people but they also need to pay more. As you know from the fundamental principle of macroeconomics, low supply and high demand drives prices (as in, salaries) very high. Therefore, incubation in several cases becomes the only sustainable way to acquire the skills required by your DevOps 360° operating model. If you cannot buy it, you need to build it yourself. Let us now look into some tips and recommendations on incubation that I have collected through my experience with it.

Focusing equally on leaders and people on the ground

Let’s start with a clarification. The phrase people on the ground is not entirely figurative. I use it to indicate ground as the solid foundation of your organization.

Throughout my DevOps career, I have made two classifications when it comes to people incubation: direct and indirect. The direct one is that organizations mostly focus on the people on the ground, not their leaders. The indirect one is that leaders in middle management positions in most cases become one of the most severe execution bottlenecks – on the one hand because they are not DevOps literate, so basically, they don’t get it, and on the other hand, because their role is quite challenging in nature. It’s challenging in the sense that they are the ones in between executive leadership and the people on the ground. Having said all this, I urge you to prioritize the DevOps incubation of your people in leadership positions. Just buying books for them (the most typical way I have seen) to read before going to bed or during vacation is not enough.

Look for the “dark knights”

I am borrowing this expression from an old peer of mine. He used to call the DevOps incompetent leaders dark knights. That is because, in an attempt to hide their DevOps ignorance or general ignorance, they were intentionally slowing down adoption to the disadvantage of the rest of us and the broader organization.

The most effective incubation for leaders in my opinion is shadowing by DevOps experts. Those people can act as advisors and indirectly incubate leaders through that advice.

Being targeted and driven by real work

All of us in managerial positions have had that employee who insisted on having DevOps training (baking cookies with DevOps practices, for instance) that was obviously irrelevant to what your team and the broader organization were focusing on. You will also have heard the story of a sister team attending SAFe training while your organization is already in the process of adopting the Spotify model. Or you’ll have seen LinkedIn posts of your organization’s DevOps engineers who are new to the public cloud getting Azure fundamentals certifications while your organization’s public cloud strategic direction is AWS. Lastly, we’ve all had that peer who approved any random single training to keep their people happy and make the annual performance review look good. All these examples in my opinion are incubation irrationalities. Borrowing a phrase from an ex-line manager of mine, “What is the value of training if you cannot use what you learned?”. When addressing this incubation irrationality, you should focus on three areas:

• Start saying no to random training certification requests.
• Base the people’s incubation plan on the core of your DevOps 360° SDLC and technological ecosystem (there are more than enough already there).
• Create the ground for real incubation – through real work. Do not just send people to AWS training if you have started your AWS journey. Learning by doing and getting educated while doing is what you should strive for. If you do not provide this incubation through real work opportunities, employees will eventually find them in the building next door. And you will have paid for the training as well.

Personal confession

I myself have come into conflict with people in my teams several times when I did not approve training and certificates that I did not consider valuable to what we were doing in the organization. Training takes money and time away from daily work and therefore, you have to be conscious of where this time and money are invested. Balance what is best for the individual and the organization.

Utilizing your organization’s graduates

Every single organization out there has at least an annual intake of fresh, smart graduates, thirsty for knowledge and full of ambition. I know because I was one of them back in the day and have incubated several in my teams over the years. While the era of graduates photocopying is in the past, there are still occasions when graduates are not given enough space and proper attention. Those guys can learn faster than you think and their young revolutionary minds can disrupt your DevOps status quo. Instead of giving them small tasks, pair them up with seniors and throw them in the DevOps deep end as early as possible. It’s better to invest your money and time there than in questionable training and external consultants. Ensure that you also rotate them across business areas and technologies so they gain a broader DevOps perspective.

Incubating at relevance – eliminating the incubation red tape

Do you remember the incident management training mandatory KPT from the previous chapter? For some reason, organizations tend to train or incubate people using red tape and not relevance (you thought we would talk about relevance in this chapter, right?). I have repeatedly seen cross-organization horizontal training applied to everyone unnecessarily. Yes, I understand that some mandatory training is a regulatory requirement, as is the “how to handle a client at a local branch” training that I have done about five times in my career, even though I have never worked at a branch. Without overexplaining, incubation or training red tape is just a box-ticking exercise. People who do not see the relevance of an incubation initiative have already checked out before entering the incubation room. DevOps productivity is not just the fast provisioning of infrastructure. It also pertains to the time not wasted on irrelevant training. Your DevOps incubation plan should therefore be shaped by relevance.

To close, I wish to mention another ineffective incubation strategy I have seen failing repeatedly in incumbent contexts – the notorious in-house incubation schools. See, we live in 2022, so if a DevOps engineer wishes to learn Python, they will do it through online resources either during work or over the weekend. Bundling 70 engineers into a room to teach them Python with their colleagues as the teachers makes for a good post for LinkedIn that says “Hey! Today, 70 of our company’s engineers gathered to learn Python.” But it’s also lost DevOps productivity.

Stop the DevOps baptism – it’s just wrong!

Let me just be bold here and include myself in the example so that I am not perceived as finger-pointing. The fact that someone attended GCP training and changed their job title from infrastructure engineer to cloud engineer does not make that person a GCP cloud engineer. Maybe they’re a GCP cloud engineer in the very early making. I hold an MBA degree and learned tons while pursuing it. The degree itself, though, does not make me competent enough to become the CEO of an incumbent bank. Please take precautions around the coincidental (through re-organization) or the intentional (due to personal motives) baptism of people. It simply creates the wrong impression of their actual personal skills, which consequently creates the wrong impression of your border DevOps capabilities and capacity.

The inability to incubate will severely jeopardize evolution

A little bit of a personal story to cover this one – long story short, in one of the banks I used to work at, we designed the new DevOps SDLC while, of course, keeping the organization updated on our progress. Once our group was close to finalizing the ready-to-be-discussed with management version, we decided to open up a little bit to teams that were not involved in an attempt to collect feedback. As we had various DevOps maturity levels across the organization, we wanted to cover a maturity context as broadly as possible. I was considered to be one of the most senior DevOps people in our group and to possess good interpersonal skills, so we decided that I was to meet the more junior DevOps people. Lower maturity would have required me to spend more time explaining things, be patient, provide simple examples, and so on. Therefore, I went, I met that low DevOps maturity team, I presented the new SDLC, and the feedback was indeed very positive; the team liked it very much. “Very ambitious, but it looks good,” they said. Then I asked, “Do you think that there is anything on the practical side of things that would make it difficult for you to adopt the new SDLC?” Their chief architect said, “You know we have a lower DevOps maturity; many of our applications do not even use CI/CD pipelines. We will need training and incubation for certain concepts and technologies.” I told him to send to me a list of areas that they wanted incubation for based on the new DevOps SDLC. I got an email after 2 days with literally 21 (I honestly remember the number by heart) DevOps concepts and technologies that they required incubation for. That was too much and we were (for undisclosed reasons) not able to cover all of that using the central incubation mechanism. They basically had to learn DevOps from square one and, to some extent, had to do that themselves. Without going into much more detail, I volunteered to act as DevOps advisor to them over the course of the evolution and therefore had the chance to observe their progress firsthand. Things moved extremely slowly in that area and, eventually, the gap between them and the more advanced teams of the organization narrowed.

Practical DevOps mobility cases and precautions

The mobility of people is an important mechanism that I consider part of incubation and part of the tactical adoption approach. In simple terms, the concept of mobility enables people from different parts of the organization to change teams and positions either virtually (see the DevOps CoE engagements) or permanently (by full moves to new teams). Mobility as with our DevOps evolution adoption is divided into two main approaches – organic, when people self-seek new opportunities within the organization, and tactical, when people are intentionally moved from one part of the organization to another.

DevOps mobility is a concept that I have experienced in several forms, and while it can involve practical difficulties to implement, it has paid off in the following applicable cases:

• As a retention mechanism: People who wish to have a job change can find this change within your organization and don’t have to look elsewhere.
• As an incubation mechanism: Promotes the organic growth of DevOps practices and free incubation with knowledge and experience spillover.
• As an enabler and a contextual awareness mechanism: Central utility areas such as the DevOps 360° technological ecosystem and the DevOps CoE, through tactical adoptions, engagement, and having their people virtually embedded in other areas, gain DevOps contextual and organizational awareness, and can therefore better serve the organization.
• As a career growth mechanism: Supports people advancing their careers within the same organization by moving to different areas – particularly applicable in large organizations.

Minding the mobility gap

The are some particular concerns and precautions to take concerning mobility:

• Moving people around in times of understaffing and cost-cutting can be impossible.
• Positions that require specific business knowledge are more difficult to fulfill through mobility.
• The higher the level of standardization, the greater the chance that mobility will succeed.
• Mobility within the same ecosystem, value stream, or tribe is easier to achieve.
• There is a form of mobility that is labeled fixed rotation where people move around areas and spend a certain amount of time in each area. Technological utilities are a great candidate domain for this, though some people struggle with changing context frequently.
• Emotional attachments and historical reasoning can prevent tactical mobility.
• It can be used by some teams as a mechanism for getting rid of people.

In conclusion, I have heard several stories from organizations that have not managed to get mobility to work effectively. My experience is different and I advise you to attempt something similar.

Summary

In this chapter, we reached the biggest milestone of the book. We covered the last (but definitely not the least important) part of the DevOps 360° operating model’s third pillar. The chapter started by outlining the obvious people value proposition for the DevOps 360° evolution. We continued by making a case for why you should aim to enable DevOps Π-shaped professionals, along with why you should be able to predict how DevOps-related professions are to evolve in the future and start to plan accordingly. Afterward, we touched on some key elements of consideration for your hiring strategy. We also provided some tips on the value of 360° interviews and using third-party providers. We then moved on to discussing several dimensions of incubation. Starting with the urge to focus on leaders as much as people on the ground, we moved on to the importance of being targeted with how your people are being incubated, focusing on relevance but also creating real daily work opportunities. Finishing up the incubation part, we provided a real-life story about how the inability to incubate effectively can jeopardize the DevOps evolution. We closed the chapter by referring to the value that the mobility of people can bring to your evolution, while also highlighting several precautions to consider.

You should perceive the next chapter as a bonus or special focus chapter. In it, we will discuss my favorite DevOps topic, which is site reliability engineering (SRE).

Shape	I-shaped	T-shaped	Π-shaped
Characteristic	Only specialization	Broad knowledge and a single specialization	Broad knowledge and several specializations
Drawback	Lacks broad knowledge and therefore struggles to get the big DevOps picture	Only one area of specialization and therefore limited mobility and fatigue	Too many areas of specialization, turning into a Swiss army knife