9 Mistakes to Avoid When Hiring a Developer for a Product Team

Opinions expressed by Entrepreneur contributors are their own.

The requirements for product team applicants are usually much more stringent than those for component teams or classic project teams. This is due to the fact that the level of responsibility and involvement is usually significantly higher. In addition to high proficiency, specialists suited for them need other skills that will have an impact on both the quality and speed of a product’s release, as well as the sustainability of the business and its ability to respond quickly to market changes.

Some common pitfalls that can lead to hiring unsuitable candidates:

1. Lack of experience in a cross-functional setting

One peculiarity of a cross-functional product team is that its members are involved in the decision-making process, which means that they are accustomed to communicating with each other, and typically have a lot of meetings. A developer who is used to acting independently will find such communications unfamiliar. He or she might even feel distracted from the most important task: writing code. A developer of this type is likely to become a serious problem. Their decisions will slow down the work and could demotivate others involved.

Such teams also use an iterative and incremental development (IID) approach, meaning that the work is done in short iterations by regularly implementing the highest-priority business features in new versions of the product. Most often, an iteration lasts approximately two weeks, and during this time you need to design, develop, test and release the completely finished part of the product, with a goal of obtaining user reaction data from the market as soon as possible. Developers not used to working at such a dynamic pace can be slow to adapt, may prefer to be given detailed requirements in advance and could spend too much time on system design.

Related: The Executive’s Guide to Hiring Product Developers

2. Wrong work approach 

Besides the ability to write code, it’s important to identify the developer’s habits and approach when writing, as these directly affect the quality and time of the product release. It is essential to make sure that the specialist understands the difference between feature-complete and production-ready versions. Also, make sure that the candidate understands how the finished product is released and how to organize the overall ownership of the codebase. Finally, ensure that this person considers code review and automated testing to be part of the normal workflow.

3. Hiring a “superstar” software developer 

Hiring a “superstar” developer can seem like winning the multi-million-dollar lottery. Companies have high expectations for such specialists and utilize a lot of resources trying to attract them because they are able to make complex technical decisions and take the lead on big projects. If you are confident that such an employee is really the right fit for your business and team, then you should be prepared for the following issues: They like an increased amount of attention and often make technical decisions on their own without any input.

In the long run, such an approach can lead to a weakening of the team and as a result a diminished product. (After all, it cannot be designed and developed singlehandedly.) And if this “superstar” is fired, the company is left with a useless team that’s unable to make decisions independently and cannot not see the whole picture.

4. Low level of involvement  

If the developer has no experience in product involvement and user problems, and doesn’t want to be involved — preferring instead to write code in accordance with strict requirements — then such a person is not the best match. Coders only focus on getting a specific task done, but the value of an employee is not only in the code they write, but also in the quality of the decisions they make. If a specialist has no desire to find out why specific problems occurred, you shouldn’t expect breakthrough ideas from them.

Related: Why Everything You Know About Employee Engagement Is Wrong

5. Different perspectives on professional development planning 

There are always bottlenecks in the development process — often found in the backend, data analysis and testing parts. In such instances, developer growth in one of these bottleneck areas will strengthen the team and speed up product release, but not all employees are willing to learn new skills. Many wish to focus on their core area of expertise (especially if it’s rare) in order to become the highest-paid employee in a less competitive environment. It’s worth identifying a candidate’s willingness to learn new skills needed for development and what he or she has learned from past jobs. Choose professionals who are ready to grow along with your product.

6. Inability to handle or give feedback

Make sure that the developer knows how to handle feedback correctly — who won’t regard it as personal criticism and will also be able to deliver it tactfully to colleagues. Many professionals are prone to using sarcasm, jokes and other microaggressions to convey their point of view because they don’t understand how to constructively discuss team issues. A safe and open environment where people feel comfortable speaking up is essential for the successful function of a team, so ask a candidate how often and in what form he or she has received feedback from former colleagues, and solicit specific examples.

Related: 3 Employee Traits That Help Scale a Tech Business

7. Failure to communicate with users and stakeholders

Direct communication among the development team members, as well as users and stakeholders, is vital to the success of a product. It allows the team to form a holistic vision and creates additional sources of motivation. There are developers who prefer the manager to communicate with the client, who see no value in such direct contact and simply concentrate on writing code, but focusing solely on technical solutions can lead to some product features being unnecessary or even counterproductive for clients.

So, ensure that prospective employees are interested in delivering the best products on the market, and that they understand that direct communication with users is essential. (This can be organized in the form of special meetings and/or a series of user interviews/email questionnaires soliciting customer feedback.)

8. Inaccurate assessment of a developer’s competencies 

This may sound basic, but it’s essential: Hire a developer of suitable competence and expertise. If you entrust a specialist with a project that is too difficult for them, the quality of the product will decrease and the employee will waste time and effort. This causes stress. Conversely, if you give experienced employees tasks that are too easy and/or mundane, they will be prevented from developing their skills and can overcomplicate the architecture out of boredom. In the worst-case scenario, there is a risk that such a developer may leave. That is why it’s necessary to correctly identify core competencies and set tasks that both address and improve professional skills (though the amount of new knowledge required for each one should be limited).

Related: How to Assess the Compatibility of Your Company and a Hired IT Employee

9. Focusing only on hard skills

Both studies and project results clearly show that in order to predict the adaptation and effectiveness of an employee in a new place, it’s necessary to analyze their soft skills and motivations. The higher the level of an employee’s position, the more important these will be for their career growth.

What kind of soft skills and types of motivation should be taken into account? To answer this question, we conducted our own research, which covered 100-plus companies from various markets in the U.S., Russia, Europe and China. It indicated that the soft skills which determine the speed and quality of an employee to adapt to a new company can be grouped into four main clusters: “interaction with innovations”; “approach to problem-solving”; “communication with people” and “behavior under stress.” Within each, we identified key competencies.

For example, the “communication with people” grouping includes communicativeness, extraversion/introversion, interpersonal sensitivity, cross-cultural adaptability and teamwork ability. Assessing these skills allows us to accurately determine the individual preferences of a person and select his or her most comfortable working environment. This is key to a successful company.

Our research also identified 11 types of motivations specific to the IT industry. This is additionally useful, because the long-term relationship between employer and employee depends on whether the company culture matches his or her motivations and values. For example, professional development is important to many software engineers. However, it’s important to understand exactly how each wants to grow — whether via improving skills within a narrow specialization or more broadly expanding knowledge, practices and tools.

In addition, it’s necessary to realize the social drivers of an employee. For instance, this can include the social importance of a project, public appreciation, the opportunity to work in a large company or with famous products, partners, clients and/or “superstar” developers — and it’s common to find situations where a candidate can agree to receive less payment if the organization satisfies these motives.