When we started from scratch, we thought that it would be a good idea to compile a comprehensive list of requirements and expectations for our engineers. This hard-skills checklist would allow us to assess and rank engineers as senior, middle, and junior.

Initially, we tried to create two checklists: one for back-end and one for frontend engineers. However, the back-end includes a Java server and a database; they require different skill sets. There goes our one-size-fits-all checklist for the whole back-end engineering group.

The situation on the front-end side is very similar: the application client and the website use different technologies, and they require specific skill sets.

And then QA and DevOps: they’re also completely different knowledge realms.

The “one list to rule them all” approach didn’t work: it ended up being either too generic, or incomplete. In either case, it didn’t serve as a tool to establish objectiveness. Moreover, since the market and the technologies change quickly, we would need to do a lot of maintenance to keep the checklist up to date. This approach would become unreliable and labor-intensive.

We assumed that engineers at the same level would have more or less the same set of soft skills, regardless of their technical specializations. How can we best determine the skills that are really important? What should a senior engineer's skillset be like? And what about mid-level and junior engineers?

We found ourselves in a similar scenario to the previous iteration: we couldn’t define a skill set to help us assess engineers in a fair, objective, and consistent way.

We hoped that this approach would help speed up the hiring process and hire in a more focused way, but it didn’t work for us. Since we often change requirements for hard skills, keeping the process up to date was expensive. Adding extra work to keep track also of soft skills made it even more error-prone.

We started building a performance review process that included assessing behavioral patterns, establishing a career map, progressive levels, and a scoring system.

What are management behaviors? We can all sum up our knowledge and skills. For example, in my resume, the back-end stack includes knowledge of SQL, Oracle, and Informatica ETL. However, this doesn’t help assess my actual qualifications, if I haven’t worked with this stack for a long time. There is knowledge, but it’s not actively used.

We pay more attention to the active skill set that a person has, than to what’s on their resume. For example, think about the actual contribution from an engineer to their team’s success, how they invest in the product, and how they drive initiatives and projects.

After the first onboarding week, these are the desired behaviors we’d like a newly hired engineer to put into practice in their team

• Day 1 checklist completed; they signed all necessary documents, and they have basic access to our internal services.
• They know and understand what their manager expects from them at the end of the onboarding period.
• They can carry out their tasks as instructed; we don’t expect new hires to be proactive already in the first week.
• They speak up and ask for help if something is unclear.
• They participate in their team’s activities.

An explicit and realistic set of expectations helps new engineers become familiar with their team’s way of working. We want new hires to feel free to ask a lot of questions to their mentors. These expectations help navigate the onboarding process, and they minimize stress.

By the end of their first week, we expect new hires to already book concrete results:

• They complete at least one task to become familiar with the whole process: from development to the CI / CD pipeline, until production. This is a pragmatic way to gain practical skills and to learn how our processes work, from writing code to production.
• They can relate expectations as to how a particular team is performing.
• They can receive feedback and act on it.

Behavioral models from the developer’s career map:

For more experienced developers, the bar is higher. For example, we expect them to:

• Independently analyze product requirements, and develop a technical design based on them. This is a real-life application of systems thinking and interaction with product owners.
• Produce high-quality results: test their code, meet deadlines, and so on.
• When facing obstacles, they should proactively search for suitable solutions rather than waiting for guidance.

Instead of creating a checklist, we describe the desired behavior. A checklist would be too rigid; it would be difficult to apply it in real-life work situations. Describing the behaviors strikes a balance between rigid formalization and vague expectations, and it’s more actionable for managers and engineers.

The career ladder is a well-known concept: it provides a model to grow step by step in a company.

The career map provides a broader context; it guides through progressive growth and professional development. The map helps explore possibilities to put one’s skill set into practice within the framework of different development areas.

The colored blocks represent different roles, such as engineers, product managers, designers, and so on. Each role adds a set of specific behaviors to a shared baseline.

Maturity levels and their associated skill sets are in horizontal rows. Each cell describes the specific skills matching a maturity level for each role.

A unified level system with shared expectations allows moving from one role to another clearly and transparently. The requirements are the same for each level, regardless of the role; a significant part of interaction and soft skills are shared across roles. If you want to move, say, from technical support to engineering, see which skills you need to develop, draw up a development plan, and discuss it with your manager.

Within our framework, a level implies a set of necessary skills.

Levels are described with behavioral examples: “meet deadlines”, “correctly create design systems”, “minimize errors”, and “effectively interact with products and designers”.

Level descriptions must be clear for the users. This is a practical guide for all team leads and managers as they help their employees build their careers.

Levels are a combination of general and specific. It’s a bit like hard and soft skills. For example, there are general skills that are characteristic of all senior levels, independently of a specific role: influence on a certain amount of functionality, risk management, time management, working with stakeholders, and a proactive approach to problem-solving. And there’s a part that is specific to each role. For example, the ability to break down product requirements and develop a technical design or long-term ownership of a system or subsystem.

Performance reviews assess employees’ achievements and results every six months. Performance reviews are a four-stage process, and they use the tools and the framework we described.

Reflection is an employee’s assessment of their results and how they achieved them. This step helps look at one’s work in a meaningful way; it acts as a stepping-stone to making deliberate decisions and conscious changes in the way you develop.

The image above shows how we structure reflection. Achievements are visible to everyone taking part in the employee’s performance review process. The other items are visible only to their manager.

Top achievements in the last 6 months. The employee describes their best and most important accomplishments. Achievements don’t need to be development-related. For example, it was an achievement for me to speak at a conference for the first time. It took me time and effort to prepare properly for the event, so I mentioned it as one of my significant achievements in the previous six months.

How this was achieved. The employee tells about how they worked toward their achievements and how they aligned their way of working with the Miro culture. Because while it’s possible to achieve results without paying too much attention to your colleagues, this is unacceptable for us. In “Culture as the foundation to double a team in size every year. About hiring mistakes and culture fit” I talked about how our culture works at Miro.

Strengths. Time to shine and to talk about what one is good at. This is also where the employee clarifies how they intend to use their strengths to positively influence the work of their team and the company at large in the next six months.

Areas for improvement. This is the space that opens up possibilities for growth: the employee describes what didn’t work particularly well, and what they would like to improve in this area.

We allocate three to four days to the reflection stage in the performance review; during this time, the employee writes a self-review.

The employee selects 3–5 peers to get feedback from. We recommend that mid-level engineers choose people from their teams. For senior engineers, their reviewers colleagues from other teams: at this level, engineers exert influence also outside their team’s results. Each engineer must add their team’s product to the list.

Managers can confirm the peer reviewers; they can also suggest different reviewers to share better the workload that comes with writing a peer review.

This stage takes a couple of days.

During the peer review, the selected peer reviewers give their feedback with the help of a template.

Again, there’s feedback that all participants in the process can view, and there are comments that are available only to the manager.

Helpful feedback. This is feedback that really helps the recipient make a meaningful difference in their work.

Commentary for the manager. This detailed version of the feedback allows managers to get more context about the employee’s work. Here you can highlight achievements, or raise flags for potential problems. For example, as a peer reviewer I can mention that the colleague I’m reviewing didn’t include some significant results in their list of achievements, and I could also point out any issues that may have gone unsolved.

This stage takes about a week.

Feedback from the manager. At this stage, the manager reviews the employee's accomplishments over the previous six months and how they achieved these results. To prepare a review, a manager needs to study the feedback from the employee and their peers carefully. After that, the manager provides their assessment. Based on this information, the manager evaluates the overall performance and how much the employee meets expectations based on their role and level.

Helpful feedback. This feedback provides practical recommendations for positive change in the employee’s behavior and work. There are suggestions for further development, as well as for items that need some work.

Next steps. A very important part is defining concrete steps that the employee should put into practice in the coming six months, based on the feedback received, the business objectives, and the employee’s wishes.

This stage takes no longer than a week. This ends the review process.

Scoring is a formal assessment of an employee’s performance.

We defined four levels. There’s no average rating on purpose,- to avoid setting the socially expected rating for the majority. We feel that introducing an average rating wouldn’t help highlight problem areas at the beginning of the performance review. The format we decided to implement encourages us to write meaningful feedback to provide a clear and pragmatic indication of strengths and weaknesses.

Looks good so far. But we’re not there yet!

After conducting several performance review cycles, we realized that we needed to change the scoring process.

We didn’t take into account the fact that at the more senior levels, it takes longer to make progress because one needs to acquire more and more very specific skills. This means a person can stay at the same level for several years while producing excellent results. Therefore, the assessment when the employee only “doesn’t meet” or “exceeds expectations” pushes always to exceed expectations. This approach works when starting a career, and it helps reach a senior level as quickly as possible, but then it becomes an obstacle.

Calibration is a series of meetings to align expectations between managers. At these meetings, managers share their experiences of how they decide to change level. Calibration is necessary to ensure that decision-making principles are consistent throughout the company.

After the managers have finished writing their feedback, we set up several meetings for each level. In these meetings, managers talk about how the performance of each employee relates to the expectations of their level. In the end, managers summarize the assessment of the results based on our scoring system.

When managers share their mental decision-making model, they share knowledge horizontally among them. This is how we address issues related to personal bias.

After that, we decide about promoting the employee.

Let’s sum up:

We have levels for all functions, they are the same for the whole company. There’s a baseline of shared expectations at each level, regardless of teams, roles, or other specific aspects of work.

We don’t consider how long a person has been with the company. The main thing is that he copes well with the tasks. We put in place a performance review process that takes place every six months to assess our people and their achievements.