Hiring Tech Talent: What to Look For (And Why)

As part of Solutions Review’s Contributed Content Series—a collection of articles written by industry thought leaders in maturing software categories—Premkumar Balasubramanian, the SVP and CTO of Digital Solutions at Hitachi Vantara, provides some guidance on how companies can improve their tech talent hiring efforts.

It has never been easy to compete with big tech for talent. And it was even more challenging during COVID when big tech firms rapidly expanded their ranks to meet the surging demand.  

But all that has changed. In recent months, economic headwinds led Amazon, Google, Meta, Microsoft, Yahoo, Zoom, and other tech companies to cut tens of thousands of tech workers. Layoffs.fyi estimates that the total number of tech layoffs for 2023 reached 168,243 as of early June. As Harvard Business Review reports, these layoffs provide “an incredible opportunity for companies that previously aspired to grow their ranks but couldn’t.” 

At the same time, as IDC notes, we are seeing a “once-in-a-generation shift in the composition of the IT workforce.” This shift now has IT professionals occupying “hybrid roles that combine traditional development activities with activities that formerly were associated with operations professionals who historically had few or no development-oriented responsibilities.” And it’s automation and cloud technology—not business—that’s causing this shift to happen. 

Here are the roles and disciplines you may want to hire for and emphasize as your company embraces this shift, adds IT talent, and works to grow and be more efficient and innovative. 

Technical Product Managers 

Many companies endeavor to move towards a product engineering model and DevOps—and align to products as opposed to legacy domain-based structures—to become more technology oriented. Yet business is still business, and IT is IT, and there’s no flow between the two sides.  

So, when new ideas come in, the organization returns to developing the old-fashioned way. The problem, which has existed for a long time, is that no one is responsible for interpreting business requirements into IT requirements so that IT can develop the right business solution. Things get lost in translation, so you may end up with a scooter when you want a car. 

A technical product manager (TPM) can prevent that from happening. This individual can understand the features the business requires and translate that into IT terms. And with DevOps and the tooling underneath, it’s easier than ever to do those translations.  

Historically, you had to write huge Word documents of requirements. Now we have moved into user stories and behavior-driven development (BDD). TPMs are ideally positioned to input stories into tools like Cucumber, which supports BDD, to generate scripts that developers, product managers, and scrum masters within development teams can then qualify. 

DevOps and DevSecOps Pros 

Ten or 15 years ago, there were a lot of specialties involved in new product development. Business teams would drive the requirements, and requirement analysis tried translating them into something meaningful for IT. An architecture group would define the product architecture. Design groups would then translate the architecture into high-level and low-level designs. Developers would use the low-level design to develop the solution. Testers would then test the solution. Then, release managers would put what was built into production.  

But with the advent of automation and the cloud, there was a movement on the development side away from having all these silos. Developers can now use scripts and automations to do test automation, so you no longer need separate testers and don’t have to wait six months for testing environments to be commissioned. When agile, iterative development emerged, it eliminated the need for substantial design documents, so high-level and low-level designers vanished.  

However, although DevOps has collapsed automated testing and provisioning into its purview, once the code hits production, the operations of that code in production are still separate. Now that needs to come together, and I believe that will be the next iteration of DevOps. 

Site Reliability Engineers (And an SRE Mindset) 

The IT workforce shift started on the left side—the development side—with the move to DevOps and DevSecOps. But the significant change happening now is on the right side, the operations side, with website reliability and engineering extending into operations. 

Artificial intelligence is central to this new movement. Within Hitachi Vantara, we firmly believe that knowing how to utilize AI effectively is crucial. It’s not about AI taking your job but recognizing that individuals with the skills to leverage AI will play a vital role in driving success and achieving remarkable outcomes. So, every engineer needs to understand how to leverage Copilot, cognitive searches, and generative AI for anything they do. This is not about going deep; it’s about using existing models to become a more productive engineer and creating new business models for your company. 

At the same time, IT teams must align on a single backlog, ensuring a seamless flow of development features into production. However, operations teams often face challenges in getting developers to address issues that arise in production. By embracing the principles of site reliability engineering, the entire team can collaborate effectively on a unified backlog, enabling prompt problem resolution and streamlined operations. 

If you can hire a site reliability engineer, that is an excellent skill to integrate into your organization. But there are not enough site reliability engineers in the market, and a single SRE can’t do it all. So, the best approach is to think of SRE as a mindset rather than a skill set. 

Developers prioritize functionality over critical aspects like performance, scalability, and availability. However, these factors are essential for meeting business metrics. For instance, if a feature expects 20,000 users to generate significant revenue, developers may overlook this user requirement, relying solely on performance testing. But when it fails to support 20,000 users in production, the system breaks, hindering revenue goals. Similarly, promising 100 percent availability without acknowledging its limitations can lead to unmet customer expectations and financial consequences. It is crucial to emphasize the significance of these non-functional aspects for overall business success. 

These are site reliability engineering conversations because they require operations savvy. When a business signs up for a service level agreement (SLA), that SLA translates to everybody. TPMs need to think about converting that into a requirement, and they understand the service level objectives (SLOs). Developers take that requirement and must write code with the understanding it must meet the stated SLA and SLOs. Doing all this with an SRE mindset means everybody in the ecosystem understands and acts on their role in meeting these requirements. 

Trusted Partners 

Hiring TPMs, DevOps and DevSecOps pros, and SRE experts, and adopting an SRE mindset, will better position you to meet requirements, move faster and get where you want to go. You will also want to bring in technology partners—because you don’t know what you don’t know. Be bold in welcoming outside partners into the fold. Avoid thinking about partners as a solution to your staffing needs helping you fill 10 or 20 positions, and focus on the problem you want to solve with partners.  

Seek partners that share your mindset and speak your language. Partners with experience in your industry will be able to bring more than just developers and engineers to the table. They’ll understand your intent. You’ll be able to challenge each other and have a shared purpose. This will better position you to collaborate to solve problems and build solutions together. Coming together to deliver results faster is the direction in which IT and industry are headed.