devopsy.kinsta.cloud

Tag: staffing

  • Don’t Hire for Product Expertise

    Don’t Hire for Product Expertise

    We all know the jokes about talent recruitment that “requires a century of experience in AI/ML.” With the number of layoffs, no doubt this type of approach will get worse. But that is not generally a tech problem; it is an HR problem–the problem of having people hire in tech that aren’t active in or knowledgeable about tech.

    The real concern that is very much a tech problem is hiring for product and/or technology. I will say outright: Stop doing that except in very special circumstances. Hire for the ability to find information. One of the other things we all joke about is increasingly convoluted interviews where the hiring company wants you to solve their problems in a fraction of the time it would actually take them to do it. Again, if you’re a hiring company doing this, knock it off.

    IT is an ever-evolving field, more so once Agile and DevOps are taken into account. Indeed, we would not be far off if we renamed the field Continuous Evolution, because tomorrow is guaranteed to hold different solutions, no matter what. The idea that requiring experience in Grafana or mastery of Python is an indicator of long-term success is downright farcical. There are positions where this is tolerable–if a position is for maintenance of a traditional app that is not going anywhere and is not getting massive updates, then a list of what tools are desired for the role is easy to build and will be lasting. But I would argue that hiring specifically for that application’s needs is not in the best interest of the organization as a whole, because that person is not portable and adaptable. For modern development, particularly of new products that are just now being architected, the needs are going to change in the process, so claiming you want X years of experience in Spring (when it may use a different framework by deployment time) is not productive.

    As we move into belt-tightening yet again, employees who can do the job and know how to look up new information will be worth their weight in gold. Having a person who can work on existing applications and drive innovation in future applications all in one body is important. Giving them a chance to exercise that drive to learn is also important, but is a separate issue. None of the areas I cover–applications, operations and security–are standing still or even coming close to standing still. The need for people who can go find out what is needed is huge.

    And while the internet is a horrendous mix of good and bad, the ability to find information—and even solutions to problems—is undeniably better than it ever has been. Having people skilled at using that information resource is the key to moving forward.

    So, find people that can solve problems given a modern context. Hiring for technology will solve today’s problems, but problems are not restricted to today, so solve ongoing problems. Gate for basic tech knowledge and skills, then evaluate for the ability to find answers. A far better use of everyone’s time during interviews would be—using email as an example—“Hosted Exchange just went down. Walk me through your troubleshooting steps. You have a couple minutes.” Or—using development as an example—“We just discovered that an OSS library we use has unacceptable vulnerabilities. Walk me through how you would find instances of it and what steps you would take to find replacements. Compliance is breathing down our neck, you have a couple of minutes to show us.” You get to see how they approach likely problems, they get to ask about the environment. Far better than “Show us all the steps to get BGP routing configured,” or “Develop an entire B-Tree while we watch,” questions. Certainly better than any question that ends with “And don’t use the internet.” Are you kidding? Can we talk about the field and what year it is?

    As I’ve said off and on over the years, you want the best coworkers you can get or the best employees you can get. Either way, hiring for expertise with a given tech product is not the best route to that goal. You rock—so get people with you who do, too. It’s not going to get less complex, so have peeps that can keep up and carry a load, no matter what tomorrow’s technology looks like.

  • Best of 2022: Return to the Office? Nah.

    Best of 2022: Return to the Office? Nah.

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    I was watching Charlene O’Hanlon’s interview with the CRO of Rollbar, discussing the slow growth of “return to office” policies. High-tech, because we are more mobile, had more options than many people—the janitor, for example, must be physically at their job to do it. High-tech employees did not have that issue—or if they did before the pandemic, they certainly didn’t after a few months of lockdowns. And now our infrastructure allows us to work from anywhere.

    One of the things that some companies are considering is requiring that all employees come back to the office. I rarely say things super bluntly, but this time, I need to be blunt.

    Fight that tendency if it shows up at your organization. At this point in history, that way lies corporate doom. Okay, maybe not doom, exactly, but certainly bad things. Some people back in the office is fine, a choice about coming back to the office whenever your state/provincial/local government decides to allow it? Fine. A required return for everyone? No.

    Of course, one cannot make such a blunt statement without an explanation. Do I think that remote work is somehow better for the company? No. Some people are more productive working from home, while others are distracted by the many non-work things around them that they want/need to do. So it is a mixed bag that requires monitoring. In all my years working from home and mentoring others just starting to do so, I’d say this split is closer to 50/50 than you might think. To paraphrase a sergeant from my army days, “Those who most want to are sometimes those who absolutely should not.” He was talking about living off-post, which is outside jurisdiction in much the same way that working from home is. And I’ve found some truth in that statement when applied to WFH. In fact, one interesting thing for me to watch were the success rates for companies that went 100% WFH. It’s gone better than I expected, probably because it was a broader swath of staff than just those who wanted to.

    So why would it be better if I, who have worked from home for more than 20 years at a number of different companies, think it’s a mixed bag?

    Hiring and retention.

    We know that we’re short-staffed. We know that it is hard right now to find any flavor of IT peep, but it’s brutally hard in InfoSec and pretty tough in DevOps. A decent percentage of employees is going to want to keep working from home, and in the current environment, they can change jobs faster than you can say “retention bonus” if you give them a reason. I don’t have hard numbers, but let’s assume a hugely conservative 10% of IT staff preferred working from home. Can you afford to lose that number of your staff? Or even half that number, assuming some won’t leave? Probably not, considering the openings versus employee counts we’re currently seeing. More to the point, can you afford to never hear from that percentage of applicants because they don’t want to work somewhere that mandates their physical presence in the office? From talking to people, it seems money doesn’t resolve this issue. Working from home is a tangible benefit, and whatever a company offers, the next one might match with the WFH option.

    There was a slow change going on in IT, where a significant percentage of staff were working at least part-time from home; the pandemic just sped that process up—shifted it left and iterated, so to speak, and now HR and management are going to have to deal with this reality head-on.

    I’ve felt that some of the positions I’ve held at some of the organizations I’ve worked at/for were best performed on-site. But we have enough successful 100% virtual companies now to acknowledge this might be a corporate culture issue and not a “job fit” issue.

    I don’t know how companies will handle it, but absolutism is not the way forward here, IMO. Charlene and Michael Davis had some thoughts on WFH and returning to the office you might want to listen to.

    After all, you all are kicking it, and I know some of you don’t want to go back to the office. Can your org afford to lose you? Not if there is an easy way to avoid it.

  • Are You Feeling the Hiring Crunch?

    Are You Feeling the Hiring Crunch?

    After years of experience, we can now definitively say one thing about information technology: There is always a hiring crunch, and it will always be better soon.

    I first noticed this trend in InfoSec years ago. Everyone was short-staffed and looking for available candidates. Everyone wrote their recruitment text like there was no shortage and they could ask for the moon and everyone was certain that this temporary staffing shortage would end soon.

    It didn’t. It still hasn’t. And it has spread. DevOps in general, development in particular are acting exactly the same these days. And it’s not going to get better.

    So, my advice? If you absolutely must have a person, write your recruitment copy to reflect the actual skills you must have. No bells and whistles, no “We always include…” no “But what if we…” Hire for what you need. Or hire with an eye to training what you need. And offer competitive pay. No one here will argue that IT is underpaid, but when there is a shortage of people, or more are leaving than coming in, then the cost of employees goes up. That’s just the way it is. If you are only hiring the ones you must have, then you can afford to pay them a bit more.

    Meanwhile, invest in even more automation. Let’s face it; again, we can learn from InfoSec. They are doing more with less staff—even if “more” is not “everything that everyone wishes they could”.  They have at least partially conquered their staffing woes by increasing the use of automation. DevSecOps is automating even more of the space, so we really will eventually get over the InfoSec staffing shortage.

    We can do this for all of IT, too—just follow their lead. Invest in automation, take the risk and turn on automated actions. Start small, but get started. Relatively high turnover and lower qualified applicant counts are likely to be the status quo for the foreseeable future, so automating processes as much as possible is not taking away jobs at this point, it is improving response in light of a lack of people for the available jobs.

    So, to sum up:

    • Hire when you can, but be focused. Don’t ask for experience in all three big cloud providers if you’re looking for an Azure person. Don’t ask for fifteen years of experience in Go for that entry-level position. Be realistic, be laser-focused and get the person you need in.
    • Train when you can’t hire. Let’s face it, there are going to be people who are massively familiar with application security but who have never done DevSecOps specifically or never used your DevSecOps solution. Train them—whether they are internal or hired with an eye toward training.
    • For non-critical, long-term needs, explore automation options. That includes both things that are being done manually today and things that are not being done at all. Find a way to get it done in the absence of hiring someone.

    And keep rocking it. You are already getting the job done—I’m just recommending ways to stay on top of it and deliver more while you try to find the additional people you need. A balance of automation and hiring will help you sleep at night and make the rest of the org certain that IT is on the ball.

  • DevOps Hiring: What Do You Need?

    DevOps Hiring: What Do You Need?

    IT has long had a problem with hiring. I’m not certain where it started; most of us blame HR, and that’s probably incorrect, but gives us someone to blame. It’s that we post jobs with insane requirements. Sometimes this is done to keep the applicant pool down, but most of the time it is a simple case of throwing in the kitchen sink. We have laughed at advertisements that wanted applicants to have more years in a given technology than the technology has existed. The laughter was because someone quipped, “So what we really want is only liars to apply.”

    But it doesn’t stop there. How many advertisements have you seen for a person to join an already good-sized team of developers, and the requirements include experience in every single language/tool the person might encounter—and sometimes ones the organization might use in a year or so? And DevOps, with its increase in toolsets and broadening complexity, make this problem worse.

    If you want good DevOps team members, you have to focus your search. We’d all love to have unicorns who could do it all on day one, but those people don’t really exist. Even with experience in every single tool in your chain, they still have to learn apps and environment. Try to craft job requirements that focus on the couple of core tools, and then filter for ability to learn and adapt. Because the only certainty about IT at this point is that technology will be shifting, so focusing on the tools you are using today is pretty limited.

    Role plays a part in this also. While we like to pretend DevOps is one thing, it is a rare application or portfolio for which there are not specializations on the team. If you are looking for someone who will lean more toward the DEVops side, do you really need them to be operational wizards with three years each in storage, networking and container management? Conversely, if you are hiring someone more for the devOPS side, do you need them to have expansive experience in Javascript, or do they just need to know who to call if it gets beyond their ability?

    Maybe your company is one of those shops where everyone on team X is expected to be an expert at everything. Kudos for you, but there aren’t a ton of those people out there. There is a different mindset to DEVops versus devOPS, and even if unofficial, most employees lean one way or have a more proficient side. If a candidate fits the bill in an area you are weakest, consider training them on the job in the area you are strongest, rather than waiting for who knows how long for the perfect person to fill the open req.

    And we still have a need for hardware specialists. I’ve said it before, but do you want your EMC (or Cisco or whomever) person to be a generalist, or do you want that person to make the infrastructure that underlies a huge chunk of your applications hum? Hire specialists for specialized skills, hire broad knowledge for app-spanning needs.

    It’s been a problem for years, and only you can fix it. Call out overambitious job postings and make managers ponder what they’re actually looking for. You know you have a need, you know what the position will do. Help hone down postings so that they fit the actual requirements, not some blue-sky version of potential requirements.

    And get the best people for the job. After all, you are going to have to work with them.

    — Don Macvittie