Why?
The Software Engineering Competency Matrix enables line managers to track the engineering skills and knowledge, along with a development plan tailored to each individual member. It also helps developing a comprehensive assessment of people’s abilities.
What?
It offers a visual map of the skills, knowledge and necessary training necessary for each software engineering role, in addition to the proficiency levels.
Tech Competency | Junior Software Engineer (E1) | Software Engineer (E2) | Senior Software Engineer (E3) | Tech Lead (E4) | Team Lead (E4) | Engineering Manager (M1) |
---|---|---|---|---|---|---|
Coding | Good understanding of programming basics, writing production-ready code Expected to have an understanding of basic fundamental concepts of programming: – variable declaration – basic syntax – data types and structures – iterations – functional and OO programming Adheres to the team’s Coding Guidelines, writes code with readability in mind considering edge cases and maintains the code of existing applications. Support from colleagues is provided when complex situations might occur and pairing sessions can be facilitated. Tracking – good understanding of the team’s coding guidelines – small rework rate (change requests from code reviews, returns from QA) – features delivered to production | Good coding skills writing production-ready code Expected to write production-ready code with readability in mind, easy testable, considering edge cases / error handling. Algorithmic thinking, avoiding brute force code. Support from colleagues is provided when complex situations might occur and pairing sessions can be facilitated. Tracking – good understanding and contributing to the team’s coding guidelines – small rework rate (change requests from code reviews, returns from QA) – features delivered to production – used design patterns / code duplication removal, good coding standards | Excellent coding skills, writing production-ready code Expected to write performant and defensive production-ready code with readability in mind, using design patterns where applicable to reduce code duplication and facilitate easy testing, accounts for edge cases and error handling. Driving innovation and technical excellence initiatives (cost saving tasks, performance improvements, service reliability and other NFRs) Support and coach other team members on our coding guidelines, strategies, as well pairing sessions can be facilitated. Tracking – features delivered to production – effective coding practices, using design patterns / code duplication removal strategies – technical excellence initiatives (performance improvement, code improvement, defensive coding, good error handling) – driving innovation – supporting other team members on increasing their coding skills | |||
Testing | Awareness of various levels of testing and their benefits (e.g. unit, functional, integration, API and E2E testing) Expected to have awareness of various levels of testing and their benefits. Support from colleagues is provided to understand the project’s testing strategy, tools and the setup. Tracking – knowledge on different levels of testing – awareness of the project’s testing strategy, testing tools and setup | Good understanding of various levels of testing and their benefits (e.g. unit, functional, integration, API and E2E testing) Expected to have good understanding of various levels of testing, their benefits and related tools. Support from colleagues is provided to understand the testing tools and the setup. Tracking – knowledge on different levels of testing – awareness of the project’s testing strategy, testing tools and setup | Experience with different levels of testing, their benefits, testing frameworks / tools, testing practices as well helping defining / improving the team’s testing strategy (e.g. unit, functional, integration, API and E2E testing) Expected to have great experience with testing frameworks / tools, to easily determine the product testing strategy, to write clean and maintainable tests, cover any edge cases and providing great tests coverage for the written production-ready code. Support and coach other team members about the testing strategy we’re using and the tools. Tracking – examples of written code tests that are accordingly with the team’s standards – examples of using testing frameworks and tools – examples of ownership on a service’s tests coverage – examples of a defined or improved testing strategy | |||
Debugging | Basic knowledge for code debugging and debugging tools Expected to have awareness about debugging strategies, the benefits of logging and potentially how testing can help when bugs are occurring during writing code. Support from more senior engineers is provided when debugging more complex systems is required. Tracking – awareness of debugging tools that we use in our services – [OPTIONAL] example of an issue where using debugging strategies were necessary | Experienced in debugging systems and debugging tools Expected to have experience with debugging systems (monolith or micro-service architecture), debugging tools and logging strategies. Pragmatic thinking when debugging a system always balancing between manual debugging or adding tests where they’re missing. Support from other team members is provided when debugging more complex systems are required. Tracking – awareness of debugging tools that we use in our services – examples of issues where using debugging strategies were necessary | Expertise in identifying, isolating and correcting or determining the best way to work around a problem in software applications Expected to be able to define a debugging strategy and choosing the tools, to be proficient at using systematic debugging, to diagnose issues located to a service or debugging a flow that might traverse one or multiple services within the squad. Identifying opportunities when debugging and testing can be complementary processes. Static analysis, print debugging, remote debugging, post-mortem debugging are key to be part of the debugging strategy. Support and coach other team members about our services and the debugging strategies on different levels (single service, request flow, remote). Tracking – examples of defining a debugging strategy or improvements – example of issues where using debugging strategies were necessary – examples of supporting other team members on debugging issues | |||
Observability | Understands the benefits of monitoring Expected to have awareness of the organization’s monitoring philosophy and the operational data for their team’s domain. Considerations: – awareness of our organization’s monitoring strategies | Understands the benefits of monitoring Expected to have awareness of the organization’s monitoring philosophy and the operational data for their team’s domain. Considerations: – awareness of our organization’s monitoring strategies – example of basic understanding of our organization’s monitoring tools within the squad | Strong knowledge on how to define / maintain production monitoring Is aware of the organization’s monitoring philosophy. Helps tune and change the monitoring on their team accordingly. Awareness of the operational data for their team’s domain and uses it as a basis for suggesting stability and performance improvements. Considerations: – awareness of our organization’s monitoring strategies – examples of monitoring improvements – examples of supporting and mentoring other team members with understanding and using our monitoring strategy and tools | |||
Software Architecture | Knowledge on how to represent simple software through diagrams. Expected to understand the overall service architecture, to avoid duplication when designing new code / services and to be able to draw diagrams that might represent code structure, user flows or simple services and how do they connect with each other. Support or pairing exercises from more senior engineers is provided to design more complex systems. Considerations: – examples of involvement or understanding our (partially) software architecture | Knowledge on designing code that is aligned with the overall service architecture Expected to understand the product architecture, avoid duplication when designing new code / services and utilizes abstractions and code isolation effectively. Ability to draw diagrams that might represent code structure, user flows or simple services and how do they connect with each other. Support or pairing exercises from other team members is provided to design more complex systems. Considerations: – examples of architecture improvements and the thoughts process around it – examples of improved KPIs as result of an architecture change | Expertise in defining / improving software design and architectural design Expected to have expertise in defining and improving software design, finding reusable areas to avoid duplication, utilises abstractions and code isolation effectively. Collaborative working, ensuring that other team members have visibility and understanding on how and why systems are being designed in a certain way. Clear communication of the improvements to the business using KPIs (e.g. loading times, cost saving amounts, re-work times, bug detection rate), what is the customer value (e.g. reduced PDP loading time) or how a development improvements might impact delivery positively in the long-term (e.g. building a CLI tool that automates a process). Support and share with other team members architectural decisions through clean documentation and diagrams, as well holding knowledge sharing sessions with other team members that has not been involved in the initial decision sessions. Considerations: – examples of defined architectures or improvements and the thoughts process around it – examples of improved KPIs as result of an architecture change – examples of supporting other team members on defining software design or architecture | |||
Security | Understanding of overall software security, as well basic practices for developing secure web applications. Expected to understand our software security techniques in compliance with the team’s technical reference architecture. Furthermore, it is key to be mindful of security practices (e.g. input validation, personal information data encryption, exception management) during coding and reviewing other people’s code. You should always consult team members on secure coding practices and maintain any security documentation. Support will be provided from more senior engineers about the implemented security practices and future expectations. Considerations – awareness and understanding of team documentation on security practices – examples of implemented security practices in compliance with the team’s technical reference architecture | Basic experience on developing secure applications, understands the importance of security and best practices. Expected to understand our software security techniques in compliance with the team’s technical reference architecture. Furthermore, building and running a service with a responsibility for security (e.g. input validation, personal information data encryption, exception management) and consider secure development techniques during coding and reviewing other people’s code. Third party code libraries or other code dependencies need to be considered in the same light as the code you author. You should always consult team members on secure coding practices and maintain any security documentation. Support from other team members will be provided about the implemented security practices and future expectations. Considerations: – examples of knowledge on the implemented security practices awareness and understanding of team documentation on security practices – examples of implemented security practices in compliance with the team’s technical reference architecture | Excellence in developing secure applications, software security knowledge and best practices. Expected to define / improve software security techniques in and the team’s technical reference architecture. Furthermore, building and running a service with a responsibility for security (e.g. input validation, personal information data encryption, exception management) and consider secure development techniques during coding and reviewing other people’s code. Third party code libraries or other code dependencies need to be considered in the same light as the code you author. Always inform team members on secure coding practices and maintain any security documentation. It is highly expected that the Senior Software Engineers and the Technical Leads are holding accountability of our system’s security. Support and coach other team members about our security practices and future expectations. Considerations: – examples of implemented security practices in compliance with the team’s technical reference architecture- awareness and understanding of team documentation on security practices – examples of contribution on the team’s technical reference security architecture – examples of supporting other team members on security practices |
Agile Competency | Junior Software Engineer (E1) | |||||
Work Breakdown | Understands value of rightsizing tasks to enable continuous integration and incremental delivery. Expected to understand the framework that the team is using for estimating tasks and contribute when feeling comfortable. Regardless of their size, tasks has to be broken-down in such a way that ensures incremental delivery. (e.g. logo change, text change, a new feature). Support will be provided from more senior engineers about breaking the tasks in such way to support incremental delivery. Considerations: – examples of work breakdown in order to enable continuous integration | |||||
Prioritisation | Understands that the product backlog it is certainly the property of the Product Owner and it is the product owner who decides the priority of the deliverables. Expected to stick to the sprint plan and any task from the backlog should be picked up with the Product Owner’s agreement. There is no expectation for code refactoring initiatives and technical excellence for this level, although they will be appreciated and should be discussed with more senior engineers and the Product Owner. Support from more senior engineers will be provided about the work priority. Considerations: – examples of where the engineer had to pick up new tasks and what was the priority criteria – [OPTIONAL] examples of where the engineer achieved work initiatives through backlog, sprint work (code refactoring, technical excellence) | |||||
Ambiguity | Understands that there is one funnel of requirements and that has to come from the Product Owner. Expected to understand that any sprint or ticket scope change should only happen with the awareness and the agreement of the Product Owner. Support will be provided from more senior engineers about agreeing risk, change, and uncertainty. Considerations: – examples of tasks with risk, change and uncertainty that has been completed | |||||
Dependencies | Understands what dependencies are, what risk they bring and how can dependencies impact the deliverability Expected to understand that tasks might have dependencies. The dependencies can be part of other PLT teams or 3rd party service. These dependencies are initially flagged part of the Backlog Refinement. At this level it is required that the engineer pays attention to the Backlog Refinement sessions and notes what kind of dependencies are being flagged. As the engineer grows up in seniority, it is expected that the engineer to develop a capability in highlighting dependencies. Support from more senior engineers will be provided with regards to determining dependencies their magnitude, complexity and risk. Considerations: – examples of tasks with dependencies that has been completed | |||||
Accountability | Understands what are the benefits of accountability and how it helps to meet goals, targets and deadlines efficiently Expected to collaborate with the team on commiting to a realistic amount of work. Escalates any blockers, delays to their team daily. Furthermore, taking accountability for failure will allow the team to learn from your mistakes and being vulnerable will help you building trust with the team. Support from more senior engineers will be provided around how to be accountable of your tasks. Considerations: – examples of accountability for your actions, behaviours, performance and decisions |
Competency (Soft Skills) | All Roles (E1, E2. E3, E4, M1) | |||||
Attendance | Regular attendance and punctuality are vital attributes. It is important and expected for employees to attend work / meetings regularly and to start work on time, because failure to do so detrimentally affects the other’s morale and productivity. Considerations: – attentiveness – punctuality | |||||
Dependability | Expected to have the motivation to complete assigned tasks following the best practices and take pride in the accomplishment of work assignments. Dependability is significant because an individual’s absence can have a negative ripple effect on the success of a project or team. Considerations: – reliability – responsiveness – meet the deadlines – be timely | |||||
Respect | Expected that regardless of the seniority level you are at, you need to ensure that all your actions are fair and just, particularly if you are entrusted with a position to lead. Always remember that every member of the team deserves to be treated with respect and dignity, regardless of who they are or which position they are at. Considerations: – dignity – gratitude – appreciation – favouritism prevention – control anger – politeness – privacy respect – avoid gossip – good manners | |||||
Empathy | Expected to show empathy which helps influencing people and build connections that lead to a deeper understanding of others. Also expressing compassion toward others and can create a positive working environment. Considerations: – involve workers in decision making – acknowledge other workers perspectives – watch out for signs of burnout – identify unconscious bias – steer away from unsolicited advice | |||||
Communication | Expected to be communicative, instead of individual work, focus on solving problems together. Furthermore, ensure exchange of information and transmission of meaning. There are great opportunities like stand-ups, planning, refinement and the most important retrospectives where information can be shared. Considerations: – exchange information – transparency around issues / blockers – provide feedback – respecting other people’s opinions during their communication | |||||
Collaboration | Expected to express collaboration through establishing common team objectives, set common expectations or standards and contribute on creating a trustworthy and trustful environment. Furthermore, it is not about how much an individual delivers, it’s about how successful are we as a team. Considerations: – set common expectations / objectives / standards – contribute on creating a trustworthy and trustful environment – team success – use collaboration tools – include relevant people in meetings | |||||
Ownership | Expected to take responsibility for outcomes and being empowered to make the decisions that will lead to those outcomes. You have to own the mistakes and take responsibility for successes. Taking ownership is key for enabling a high-performing team. Considerations: – take initiatives (technical excellence, team improvements) – being accountable for the results of your actions – feeling trusted by the team to do the right thing | |||||
Time Management | Expected to have control over how you spend your time, how you break down your workday and run meetings. Very important to know that poor time management leads to stress and is not just about missed deadlines or staying overtime. It can also become overwhelming and cause people to be nervous and afraid of missing important information or tasks. Considerations: – breaking down workday – politely decline meetings where you feel that you can bring value – timebox tasks and ask early for help if stuck – talk with the team about distractions | |||||
Conflict Resolution | Expected to avoid conflict and even if you agree with one or more individuals in a conflicting team, make sure that you remain objective. If conflict is spotted, avoid leaving it to the team members or HR to resolve, instead, act! Considerations: – being objective – stepping in when needed – avoid assumptions – keeping confidentiality | |||||
Open to share feedback | Expected to be open to share feedback to your teammates regardless if it is positive or negative. If you are unsure about how to share negative feedback, please read about the Tortilla Feedback Method. https://www.coursera.org/lecture/principles-of-management/the-tortilla-method-kYejJ Considerations: – examples of when you shared feedback to your teammates | |||||
Open to receive feedback | Expected to be open to receive feedback from your teammates regardless if it is positive or negative. Do not confuse feedback with criticism, when feedback is shared, you should take notes, improve yourself and check progress by seeking feedback again on the same problem. Considerations: – examples of when you received feedback and you improved |
Competency (Line Management) | Engineering Manager (M1) | |||||
Career Planning, Promotions and Coaching | Expected to identify individual career goals and proactively coach people to work towards those goals. Define / use the existent career laddering system to show what expectations are at different levels of a role, a purpose of which can be defining how one might be promoted. Considerations: – Technical or Professional Leadership (for Senior Engineers) – Assess together on competencies – Keep the plan updated (documents, excel, platforms) – Building trust – Clarity with people about their level and being explicit about what they should be working on is critical – examples of career planning system you are using for an engineer – examples of coaching – examples of successful promotions | |||||
Headcount Planning and Hiring | Expected to create and implement growth initiatives for our employee headcount to achieve short (contractors) and long-term (permanent) goals and objectives. This requires that you have a good understanding of the the business’s strategic goals and objectives by collaborating with the PLT Product Group and commonly agree on the required resources. Forecast future workforce needs, identify potential skill gaps, anticipate talent requirements, and proactively plan for recruitment, training, and development initiatives. Optimise costs by effectively analysing staffing needs and avoiding over or under-staffing. Enable Compliance and Risk Management by considering legal requirements and diversity and inclusion goals during the planning process. Promote fairness, and create an inclusive work environment. Considerations: – strategic personnel alignment – cost optimisation – talent acquisition and retention – compliance and risk management Deliverables – examples of strategic hiring plan inline with the business’s needs – good understanding of the talent acquisition framework – continuous improvement of the hiring / interview processes | |||||
Objectives, Performance and Feedback | Expected to create a framework for skills and competencies management or adhere to an existing one. Set clear goals and objectives, conduct performance appraisal sessions and provide regular feedback. The goals should be reached during a specific timeframe, and the employee may also be able to choose goals they want to work on based on past performance or the needs of the business. Competency Tracking – examples of conducted performance reviews – examples of goals & objectives that has been set – examples of given feedback – examples of performance assessment – success through performance improvement | |||||
One on Ones | Expected to conduct One to Ones on a regular basis with your reports. Use these catch-ups as an opportunity to: – give feedback – keep each other in the loop – resolve issues – help the participants grow in their roles – lay the foundation for a trusting and productive work relationship – improve employee retention – ask your team members how you can better support them Build your own One to Ones framework notes and keep track of the updates. Ensure that the notes are following a structure, are easy to read and don’t include personal information. Competency Tracking – one to ones meetings with your reports – evidence of one to ones notes and the growth strategy | |||||
Cascading Communications | Expected to have awareness of your teams and ensure all stakeholders will receive aligned and accurate information. The communication can be both ways following an executive meeting, or anytime there is information to distribute or changes have been made. Define a communication strategy with your peers / reports ensuring you get the right level of information. Areas to have awareness of: – team’s / individual performance – team’s structure and their goals – progress of deliverables – incidents and their resolutions (RCAs) Competency Tracking – examples of a defined strategy for cascading communication from your reports | |||||
Team Protection and Happiness | ||||||
Ability to Act as Tech / Team Lead when Required |
Leave a Reply