Hiring Technical Skill Sets Within a Procurement Context

By Laura Beth Hirt-Sharpe

Hiring technical skill sets in procurement organizations is a complex task, particularly for those with less technical backgrounds. As companies procure more technical software and architectures, team members with more technical skill sets will be required to run the procurement teams of the future. But is your organization ready to find these team members?

When hiring technical skill sets on my team, we follow the below recommendations to ensure we are doing right by applicants and our organizational goals.

Early Stages of Hiring

Reflect on the technical skill sets you need and fine-tune existing role descriptions. Role types are constantly evolving and will matter significantly for finding the right match. The best match of candidate and role can be made only if both parties understand what that role is.

Develop the most accurate name and description of the role you are looking for. One way is to research roles online. Technology or software providers often will highlight the recommended skill sets and roles for best utilization of their products. Examples of role names that will be clearer to a potential hire include:

  • Data engineer
  • Database architect
  • Machine learning scientist
  • Business intelligence developer
  • Front end developer.

Additionally, clarify tools and technologies. Be straightforward about the technologies available to applicants, as well as those used on the job. For example, a team member could be a business intelligence developer utilizing IBM Cognos Analytics, and may also have access to IBM DB2 to perform data preparation activities.

Other considerations:

  • Talk about the working environment. Will the applicant work alone or as part of a technical team? Is he or she working on sprints or in a ticketing environment? How much creativity and innovation are anticipated?
  • Keep in mind that technical candidates typically expect a more casual working environment, with such benefits as casual dress and remote work. If your company cannot offer those perks, think about what else can be offered, since other companies competing for talent will likely offer such benefits.
  • Define a fair salary. Utilize publicly available sites like Glassdoor to identify salary levels for roles you’re hiring.

During the Interview

It’s essential that the interview covers technical aspects. If possible, invite a technical resource to the interview, even if the person won’t be directly involved with the team. This will ensure you are not dazzled by buzzwords and a well-written resume.

Another option is to use a standard set of technical interview questions that can be asked by non-technical resources. Such questions should have clear right/wrong answers or answers that contain specific words or details. For example, one question could be whether Python is a 0- or 1-indexed language.

Evaluate communication abilities and business-centered questions only if necessary for the role. If the team member is not going to be communicating to non-technical team members or overseeing a budget, asking them to describe these details during an interview is unnecessary and favors candidates with a different skill set than the one required.

Additionally, be open about the company’s retention strategy, as this will inform a new team member what to expect.

After Hiring

A good retention strategy is the best hiring strategy. It takes time for team members to learn an organization’s technical connections, processes and nuances. Though people with technical skill sets stereotypically move quickly from role to role, there are factors that managers should consider to increase retention odds:

  • Offer mentorship and coaching opportunities. Most employees want to grow their skills, and one of the best ways to make this happen is through mentorship in their technical areas of expertise. Consider other organizations within your company or tap into your external connections to identify mentors and coaches.
  • Technical team members are not your on-call information technology (IT) support. Many technical team members in non-technical organizations are called on for every task, from Microsoft Excel help to TV connections. Protect your team members from becoming IT support by being clear about their roles and responsibilities, sharing their accountable outcomes with others in leadership, and creating an open environment for feedback when these boundaries are crossed.
  • Provide opportunities for career advancement. Establish a clear pathway for team members to become senior resources with increased responsibility and accountability, as well as enticing factors such as titles, salary, and a seat at the table in key decision-making. As your team members may have their own seniority plans, discuss their ideas and motivating factors with them. You may find salary is not the only one.

Stretch assignments also can provide more advanced projects for team members. Even if an assignment is outside the procurement team, there may be applicable technologies, skills or contacts that are helpful for day-to-day tasks.

  • Consider out-of-company involvement. To keep up skills, particularly in fast-moving areas like technologies, technical team members will need strong connections with experts outside of their organization. These could include committees, memberships and conferences. Emerging professional hires may also have opportunities to engage with professors, student organizations and graduate students from their university — which might even help with recruiting in the future.

Hiring technical skill sets is not easy for the non-technical among us. But with the right preparation, interviews and retention strategies, any team can find the right technical match for the long term.

(Photo credit: Getty Images/Nitat Termmee)

About the Author

Laura Beth Hirt-Sharpe

About the Author

Laura Beth Hirt-Sharpe is the product owner of IBM’s Procurement Analytics as a Service and is based in Raleigh-Durham, North Carolina. The perspective and opinions represented are those of the author and do not represent those of IBM; they are reflective of the author’s experiences at various companies and organizations.