[Tech Blog] Introduction to engineering team management policy at AnyMind Group

Team management in a multi-location, ethnically diverse environment

Hello, my name is Shibata, I’m a manager of the engineering department at AnyMind Group.

In this article, I would like to share with you our management and evaluation policy of our Engineering Department (hereinafter referred to as the engineering team for brevity).

About AnyMind’s Product Development organization

AnyMind Group is developing a variety of software products with the mission to “Make every business borderless”. The business unit that develops these products is called Product Development, and within it are the product management team and engineering team. With that, Takemoto, from an earlier article, leads the entire business unit and product management department.

How we’re organised across products (not all our products are pictured).

The basic division of responsibilities in product development are as follows: The product managers are responsible for considering the functions to create and at what priority. Designers are responsible for creating UIs of the product, based on requirements set. Engineers are responsible for implementing the functions and maintaining them.

What we aim for

In order to function as a team within an organization, we naturally aim to produce the best results as a team. Additionally, the characteristics of the engineering team at AnyMind Group include:

– We are a startup, so speed to ship is very important – we want results now rather than later.
– We are developing products in new and rapidly evolving fields, so we focus on being able to build and fix things quickly.
– We are constantly looking to add new services and features, so we need to grow our team and look at ways to increase productivity.
– Since we are expanding our business across Asia, we have engineers from many different locations and ethnic backgrounds. However, not many of them are native English speakers.

Also, as you might already know, there are some common characteristics of software engineers:

– If you are a great engineer, your productivity can be several times higher than others.
– Since teams work together to assemble a single system, communication increases dramatically as the number of people increases. (the Two Pizza Rule is very relevant here)
– Technology is advancing rapidly, and more useful libraries and tools are coming out every year.
– There is a low hurdle to changing jobs, and while it may be easy for a company to attract people, it is also easy for engineers to leave a company.

These are just some of the common characteristics. Based on these points and the current situation, we are managing the team based on the following policies:

– Bring in engineers who are able to run on their own (“self-starter”). Recruitment
– Give more responsibilities and allow for mistakes. Assignment
– Focus on results rather than the process. Evaluation

The following are detailed explanations of the background and specific initiatives put together.

Bring in engineers who are able to run on their own (Recruitment)

First of all, we have to hire talent who have the skills for the position we are looking for, but we also look at whether he/she is a “self-starter” or not.

There are some areas I’m checking:

– Readily accept constructive feedback on how to improve themselves.
– Flexibility to adopt new technologies without sticking to their current skill set.
– Ability to distinguish between facts and subjectivity, and make fair judgements.

We consider a person to be “self-starter” if he/she meets the below criteria.

If a member is considered a “self-starter”, he/she will respond flexibly even if there is a change in the system or if a new product is started. Also, as mentioned earlier, one of the common thoughts on software engineers is the idea that you can expect better results if you have a few selected engineers than if you just increase the number of junior engineers.

Fortunately, we have been able to hire well because of our excellent recruiters and the fact that we are able to work with people from various backgrounds and nationalities (although travel restrictions are limiting our recruiting as well.)

Give more responsibilities and allow for mistakes (Assignment)

Currently, each product team is entrusted with almost everything – from technology selection to team composition and scrum implementation. For example, in terms of server-side programming languages, we use Python, Kotlin, Golang, Scala, etc., and the frameworks are all different.

As I will explain later, this is influenced by our evaluation policy that “it doesn’t matter what you choose, just make sure you produce results” (there is also the intention of not creating restrictions for our engineers. It’s also more fun to be exposed to a variety of technologies).

Also, in just a short period of time, the number of products that AnyMind has has increased and there is much work to be done. At this time, we are giving the opportunity for members with no managerial experience to take on the role to lead a product. Of course, we’ll discuss their career plans before assigning these roles.

We assign as many roles as possible in order to prevent the load from being concentrated on managers, and to give motivated members a bigger chance to challenge. If the role is unfamiliar to them, the manager may check on them for a while, but all decision-making and communication is done by the person-in-charge, and managers try not to interfere too much.

If we proceed with such policies, it is natural that new leaders may not be able to manage the team well because they are not used to it, or that the quality and development speed of the product might drop temporarily. However, since managers have to do other tasks as the organization expands, managers leave as much as possible to these members, and since those who are involved in the product full-time should have a better grasp of the current status of the team and product, we set goals that have some leeway for failure, and try to take the long-term view on development.

Of course, we don’t leave these members alone for long, we watch them for a while, so if we spot any difficulties, we can support them. For example:

– If new leaders decide to use a specific format for the sprint review, I’ll tell them that this is a general way & reasons to do it, and I’ll watch to see if it works.
– if they say, “Let’s introduce a new technology for this new product,” I’ll share about the possible risks and discuss with them why they chose it.

Gradually, we build trust that they won’t make major mistakes, so we are able to check in less frequently or increase their discretion accordingly.

Focus on results rather than process (Evaluation)

In terms of goal setting, each product development team sets short-term goals for every three months, and quality maintenance policies for the long-term.

For short-term goals, the product manager and tech lead discuss and decide the range of goals that can be achieved in the next three months based on the long-term plan that the product manager has in mind, and the manager approves them.

As for long-term quality maintenance, it is not so clearly defined, but the tech lead and manager will build it from what they envision. For example:

– Since performance is expected to worsen with the increase in data in the future, the Read logic should be separated so that it can be easily tuned.
– The number of development team members will increase in the future, so we need to prepare to separate systems as microservices.

This is about non-functional requirements and putting them into goals.

Although we set the team goals this way, we’ll not set clear individual goals of team members. The reason for this is, as I mentioned at the beginning, that due to the startup nature in AnyMind, we have a strong focus on product achievement. The other reason is that we want our members to cooperate with each other with a sense of unity, not just to do well for themselves only. Therefore, in order to achieve results as a team, we only state their areas of expertise, such as “I’ll contribute to the infrastructure” or “I’ll lead this function.”

These goals are reviewed and evaluated every three months, and as I mentioned earlier, the evaluation is basically based on the achievement rate of the team. The major evaluation is as follows:

– Tech Lead: (team achievement) = (individual achievement)
– Members: (team achievement) = AVG(individual achievement) is the base, and evaluated by the Tech Lead based on their grade and contribution

Currently, Tech Lead evaluate members subjectively with qualitative targets. So we also conduct peer reviews to prevent large discrepancy in perception between the tech lead and the members. This is not directly reflected in the evaluation, but is used by managers to understand the condition of each product team.

Summary

We have talked about how we manage engineering team, and the system looks not very structured, and how members and leaders are able to operate freely. This is because:

– It is more efficient to hire excellent members and leave it to them.
– We designed the system to simplify the goals and evaluation aces, and to share responsibilities transparently and clearly with each person.

The disadvantage is that we can’t give detailed instructions. One of the disadvantages is that it is difficult to make adjustments when results are not as expected because we leave things to them without giving detailed instructions. Therefore, I think it is important to hire only those members who are independent and carefully judge whether it is safe to entrust this person as a leader.

Additionally, what I would like to improve in the future is the following:

– Only product managers tend to understand the business requirements, etc., and the engineers tend to focus only on how to realize the given specifications, so I would like information to be shared more actively and have the engineers to also propose specifications based on current implementation.
– Since we don’t get many opportunities to have face-to-face chats with each other due to COVID-19 and multi-location development, we need to talk more with members to improve their psychological safety within the team.

At AnyMind Group, we are developing various products and are on the lookout for product managers and engineers. If you want to solve global problems with your technical skills, please select “Product Development” from the link below to see open positions.

https://anymindgroup.com/career/

We also have a blog written by engineers in AnyMind Group. If you’d like to read it, please click the links below: