Software Engineer growth & development at Zaleos

One of Zaleos' root philosophies is to continuously improve: the software we produce, the processes and workflows we use and most importantly, the human capital we have, our team.

Zaleos' Software Engineers need to continually strive to improve their professional skills, but... how can we be better if we don't know what to improve? This is the question we asked ourselves when we started our Software Development team, and we answered it by developing an internal process with a definition of the skills we consider a great Software Engineer must have. Today, we want to share it publicity so other Software Development teams can use it or be inspired by it. Let's continue!

We've grouped the skills into six different categories, and we call it the Software Engineer Skillset Hexagon, each category is a vertex of the mentioned polygon figure:

• Communication Vertex: Articulating ideas to others, being an active listener, using proper language, making good presentations, being confident.
• Attitude Vertex: Holding yourself accountable for your own actions, being an active participant, being flexible, respectful and positive. Keeping a can-do attitude.
• Team Vertex: Coaching another team members, sharing your procedures with the team, providing constructive feedback, connecting with people and creating a good team atmosphere, resolving conflicts calmly, providing promptly responses, managing own time extraordinarily.
• Performance Vertex: Getting the job done in a timely manner, providing cleaned and high quality solutions, being autonomous, constantly checking-in about your work-in-progress, providing regular updates and transparency without being asked.
• Tech Vertex: Being a great problem-solver, being creative in your solutions and constantly proposing new methods, being an expert in a given topic, scenario or situation.
• General Vertex: Being easygoing and easy-to-work-with. Overall professional and personal impression.

Detailed descriptions of each vertex can be found in this blogpost.

Skillset Hexagon

How does this report look like?
The following image is an example of the report sent to the Software Engineer. It has a radar/spider graph which contains not only the engineer's current report, but the previous' term report. It also contains a list of human-readable text for each vertex: "Needs Big Improvement", "Needs Improvement", "Meets Expectations", "Exceeds Expectations", "Strongly Exceeds Expectations" and "Superb".

How do we gather the data?
The data used to populate the hexagon is based on two different sources:

• Using tech-lead notes from the daily work. The notes describe highlights and things to improve for each team member's progress.
• Using the 360-degrees process, which is an anonymous feedback gathered from the people who work around each Software Engineer (manager, peers, and direct reports).

Tech-lead collects these two inputs, merges the data, weights-in and generates the final numbers and comments/thoughts for the report.

How often this report is generated?
All Zaleos' employees receive this report every four months. Today, we split the year into three periods of fours months, which has proved to give us perfect time-windows for our iterative processes.

How can a Software Engineer develop his/her skill gaps?
Hexagon's vertices provide enough details to understand if the engineer is failing in a certain area, but the most value comes from the follow-up done using one-on-one sessions with the tech-lead, where the Software Engineer can ask for clarification and the tech-lead can provide more personal information.

At Zaleos, one-on-one meeting between the Software Engineer and the tech-lead are important. They not only serve as a great space to deliver feedback regarding individual growth & development skills, but also as a way to build trust and strengthen the relationship.

Another resource that the tech-lead has at his/her disposal is the trends chart, which shows not only the current skillset status, but also keeps track of the historical reports. This chart is very helpful to identify the patterns over time and allows the tech-lead to take actions and provide better feedback.

Challenges found

All looks bright and shiny, but there are still some pain points:

• An extensive vertex description might not be really helpful for anyone trying to do the evaluation: it gives a lot of smaller variables to consider/evaluate separately and then somehow combine into a single number for that skill vertex.
• Software Engineers might not know how to improve a given vertex if the tech-lead is not clarifying accurately how to improve that skill. Providing good feedback and directions is very important but sometimes is hard to do.
• Describing the vertexes is not easy, and when a vertex changes (either the main vertex name or any of the categories within itself), the historical data gets corrupted and the Software Engineer gets confused. We try to stick with the same vertexes as much as possible to give homogeneous feedback.

Conclusion

A lot of professional skills are competencies that often are not taught as part of the college degree's coursework. What we just shared here is our approach to define, measure and communicate the ones we consider important for our daily job. Keep iterating, keep improving!