Growing as an Engineer
Because of the nature of engineering roles, continuous learning and improvement are crucial to working efficiently as an engineer. The engineering team invests heavily in the growth of its individuals, as it is the key to its success.
The Developer Track, created in 2017 and regularly updated since then, provides detailed information on the skills engineering team members need and plays a central role in guiding and assessing individuals’ growth.
However, growing as an engineer is not limited to leveling up to the Developer Track but also requires leveraging the company environment and meeting the team’s expectations continuously and efficiently.
Principles
Guided Process
Should I learn a new programming language? Or focus on my code review or communication skills? What about soft skills? Do they matter? Is it better for me to delve into engineering management at some point?
This type of question is prevalent among software developers as the path from junior to senior – or even a lead role – is not straightforward. At Nimble, engineering team members are not left to figure out what they should focus on next to become better at their work. Through the Developer Track and mentorship by their Engineering Leads, they are guided on their individual growth path.
Continuous Process
Software products are built iteratively over time. Similarly, growing as a software developer is done through small continuous increments. The speed of these increments can vary between individuals; i.e., some might grow faster or slower than others. However, there are no shortcuts or skips over a whole level. Everyone can only grow efficiently over time by building on top of the previous step. Each step matters.
The engineering team fully integrates continuous growth in its processes. Feedback and reviews are provided by engineering leadership throughout the year so that each individual has the required information to plan and improve continually. In return, it is expected that every software developer must integrate continuous growth as part of their work efforts too; i.e., they should not think about it only once a year (e.g., such as New Year’s resolutions). These efforts also require going beyond working on client projects, as explained below in the next section on growth outlets.
Personal Drive
While the team environment and processes play a significant role in providing tools, assistance, and simply a space for software developers to grow, each individual is responsible for making the necessary efforts to grow and improve. The hard truth is that no one else can do it for them.
Whether it is about a change of personal workflow, learning a new technical skill, or actively soliciting feedback from peers, each software developer owns their individual growth. Having a solid personal drive is not only a necessity, but it can also, in effect, multiply the impact of the provided environment and processes, thus hastening the development of an individual. Inversely, the best environment and processes cannot magically make a software developer better at their work without a person’s will. Even the best coaches in the best sports teams cannot improve athletes if they do not do their part. Therefore, the personal drive in each individual is vital to leverage what the team offers.
Developer Track
It comprises ten levels, two specialization paths, and 100+ skills. Each skill in each level is a stepping stone to becoming a better engineering team member.
Seniority Levels
The levels follow guiding principles along four core expertise areas:
- Code
- Project Management
- Team Work
- Team Management
Junior (Level 1-3)
| Area | Guiding Principle |
|---|---|
| Code | Basic knowledgeable of one scripting language |
| Understand and operate according to internal rules e.g. code style guide, processes | |
| Project Management | Understand the requirements and deliverables of tasks |
| Understand how to set up and run an application | |
| Can understand and follow technical communication with external stakeholders | |
| Team Work | Knows how to follow the direction of a team lead |
| Take part in all team conversation in a constructive way | |
| Team Management | Not required at this seniority level |
Mid-Senior (Level 4-6)
| Area | Guiding Principle |
|---|---|
| Code | Advanced knowledgeable of one scripting language |
| Improve and participate in the definition of code conventions | |
| Project Management | Can analyze the requirements and deliverables of tasks and raise issues/shortcomings |
| Has a deep understanding of application architecture | |
| Can participate meaningfully in technical communication with external stakeholders | |
| Team Work | Can lead a team under supervision |
| Lead team conversations by summarizing and finalizing ideas | |
| Team Management | Not required at this seniority level |
Senior (Level 7)
| Area | Guiding Principle |
|---|---|
| Code | Advanced knowledge of multiple programming languages |
| Formulate novel internal rules and conventions | |
| Project Management | Can formulate requirements and deliverables of tasks independently |
| Can design complex application architectures independently | |
| Knows how to communicate directly with external stakeholders efficiently | |
| Team Work | Can lead a team independently |
| Trigger and cultivate team communication | |
| Team Management | Know how to analytically assess the performance of teammates |
| Know how to assess and hire recruits |
Lead to Head/Principal (Level 8-10)
| Area | Guiding Principle |
|---|---|
| Code | Advanced knowledge of multiple stacks/platforms (web and mobile) |
| Create and define best practices for the team | |
| Project Management | Knows hows to pro-actively detect and remove blockers within the team |
| Knows how to guide external stakeholders in achieving their goals | |
| Team Work | Can lead multiple teams independently |
| Team Management | Nurture the individual growth of developers |
| Can build and manage entire teams | |
| Knows how to delegate responsibilities efficiently |
Growth Paths
All engineering team members follow the same path up to Level 7, after which the Developer Track branches out into two distinct paths: 1) People path and 2) Technical path.
The People path remains a 100% engineering path and comes with management responsibilities. While the Technical path is designed for individual contributors and technical experts with no direct reports. One path is not superior to another; both People and Technical paths require leadership.
A simple and general rule for software developers to decide on a path is to use these questions:
- “Do I want to manage bigger and better teams?” → People path
- “Do I want to build bigger and better systems?” → Technical path
Skills
The skills for each seniority level and growth path principles provide detailed insights on the following:
- Rationale: Why is this skill important?
- Actions: What can I do to improve this skill?
- Objectives: What are some objectives I can set for myself to improve this skill?
Growth Outlets
Growing as a professional does not happen in a vacuum. One needs to work on something and with other individuals. Progress is made through learning, practicing the learning (i.e., experimentations, trials, and errors), and interacting with peers. While client projects are the primary space where software developers can do all of the above, growing at Nimble is achieved through more than working on such projects. Software developers can leverage numerous outlets for their individual growth.
Client Projects
At Nimble, engineering team members work in cross-functional squads servicing client projects for various durations. An assignment on a client project can last several weeks to several months. Each engineering team member is dedicated to a single project, i.e., a developer has an active role with development duty on only one single squad at any given time. Through this focused assignment, they can fully immerse themselves in the domain/problem of the application for each client project.
Through each assignment, software developers can thus work in different industries, on different systems, with different stakeholders, and in different roles.
First, since the company does not specialize in developing solutions for a single industry, engineering team members build products for any verticals, e.g., finance, e-commerce, healthcare, etc. This alone brings its own set of challenges. Working on a B2B eCommerce application differs significantly from a B2C FinTech application. The features and end-users are very different. What works in one application cannot be transferred as-is, as different product concerns require drastically different technical solutions. Through each assignment, developers can think, experiment, and implement different solutions for the specific issues of a product. Every assignment is thus an opportunity to learn something new, improve from what was done before, or work on something never done before.
Second, every client project also means working on a new and different system with parts built by the client or provided by third parties. On greenfield projects, each client has its own requirements and preferences, which the squads must work with. On brownfield projects, squads inherit codebases built by other teams, thus developing their ability to discover and reverse-engineer codebases regularly. When it comes to tooling, it is common for developers to use different tools for the same purpose. For instance, instead of working on a single CI/CD platform like Jenkins CI, developers have to learn and work with different tools such as Github Actions and Bitrise. While challenging, this constant practice gives developers broader technical knowledge and skills.
Third, since squads are not permanent, engineering team members must constantly adapt and thrive in different environments with different engineering and product peers. Indeed, squads are assembled, modified, and disassembled based on the project’s needs. In addition, while there are shared conventions and processes, each squad also has a lot of leeway and independence in delivering its product. Each Product Manager, Engineering Lead and Team Lead also has their leadership style, which impacts the day-to-day running of a project.
Eventually, even the roles in a squad are not permanent. Through rotations, the role of Team Lead, Developers and Code Reviewers are regularly re-assigned. So even when working on the same client project, an engineering team member can grow by endorsing a new role since responsibilities differ greatly between roles. While challenging, a role transition is often the best way to develop new skills, such as leadership.
By working on different squads, a team member’s experience is enriched tremendously. Each client project broadens and deepens the breadth of their technical and soft skills.
Individual Objectives
Engineering team members can work on short-term assignments with a measurable output towards a specific area or skill on the Developer Track. The completion time for an objective can range from a few weeks to several months, depending on the outcome planned. Regardless of the duration, all objectives have a due date that individuals must work towards meeting.
Individual objectives are defined for each individual in collaboration with their Engineering Lead and managed on Notion. Each objective has a rationale (i.e., the why), which area or skill is worked on, and the expected outcomes (i.e., acceptance criteria).
While Engineering Leads usually recommend the bulk of objectives for their reports, the latter have a voice in that process. A report must first and foremost be aligned with the goals of the objective. First, it is not a forced assignment. Upon a recommendation of an objective, an individual can accept to work on it, propose amendments to the expected outcomes to suit them better, or not accept it. Second, reports can also propose objectives they would like to work on based on the skills they want to focus on. The more senior engineering team members are, the more they are expected to propose their objectives.
The Developer Track provides examples of objectives, but individuals are not restricted to these. Individuals can propose their own objectives as long as an objective is aligned with the expectations for a specific skill or focused on a specific area (e.g., improving communication in English).
Individual objectives provide the following benefits :
-
Individuals can grow their skills in areas or on skills that cannot be achieved otherwise via other outlets. For instance, the skill “Can lead a project by making prioritization and planning choices independently” requires to have the Team Lead role on client projects. However, individuals can have an objective to lead an Internal Initiative to demonstrate such skill.
-
An individual can demonstrate repeated efforts towards a specific area or skill. For instance, for the skill “Knows how to set up a production/deployment / CI environment”, an individual might have done it once on a project. Since this is not enough, having multiple objectives for this skill allows demonstrating a strong knowledge and understanding of what this skill entails. As a result, the validation process for the skill can be fastened as it is not dependent solely on the work on client projects. An Engineering Lead can more confidently vet the engineering team member based on repeated actions.
Internal Initiatives
The engineering team manages all its internal initiatives on this Notion board. Similar to small standalone projects, these initiatives aim to support the betterment of the whole engineering team’s tooling and processes. The Engineering leadership team formulates and prioritizes the initiatives for each engineering cycle. Once prioritized, each project’s owner and a list of contributors are assigned to ensure delivery. Engineering team members can either volunteer for an initiative or are assigned by an Engineering Lead.
There are no differences in the development processes and quality expectations between an internal initiative and a client project. The same team conventions apply. Thus internal initiatives share many of their growth benefits with client projects. In addition to these benefits, internal initiatives allow the team to work on tech that has not been used yet on client projects yet because either these are still cutting-edge/unproven or there have been no opportunities to use them. As a result, team members can venture outside of their comfort zone and broaden their technical skills.
Eventually, leading an Internal Initiative is an efficient way to demonstrate leadership skills in a risk-free environment. Engineering team members can lead internal projects before taking on the role of Team Lead on a client project, for which there are critical responsibilities. The same skills apply when one leads a client or an internal project. Therefore, software developers can use this sandbox-like environment to broaden necessary technical and soft skills to lead teams.
Certifications
When it comes to developing and validating the technical skills of software developers, preparing and going through a certification process brings numerous individual growth benefits. At Nimble, software developers can be certified via two approaches:
-
External certification
Third parties offer this type of certification, e.g., AWS Developer Associate for Web developers or Associate Android Developer for Android developers. Such certification provides benefits to both beginner and experienced developers. As a beginner, preparing the certification allows acquiring the baseline technical knowledge. For experienced developers, it can cover blindspots in their technical expertise as they might not have worked in specific areas of a platform.
-
Internal certification (IC)
This type of certification is managed entirely by the engineering team. Its goal is to provide a formal process to vet software developers learning a new programming language by their peers internally. ICs have been and continue to be instrumental in the up-skilling/re-skilling of numerous software developers.
👉 This guide provides detailed information on the rationale of this process and how it works.
In both cases, certification is a formal validation of acquiring technical skills.
Engineering Chapters
Software developers are part of a Chapter with whom they regularly discuss on Slack, collaborate on tooling, and meet for bi-weekly retrospectives.
This group of peers can play a significant role in supporting the growth of an individual. Indeed, an individual can ask for guidance and receive feedback directly from peers in the same domain of mastery. On the other hand, individuals can demonstrate their skills in supporting their peers proactively and efficiently by participating in technical discussions and sharing their knowledge in retrospectives.
Each chapter is led by a Chapter Lead who is rotated every six months following this schedule. Taking on this role is also another efficient way to demonstrate leadership skills regardless of seniority level. This role is open to everyone since its chapter elects the Chapter Lead.
Growth Targets
While engineering team members grow at different paces, most can achieve the following growth targets. The engineering management team uses these targets as general guidance for their reports.
Levels
Every engineering team member should target to level up at least once every year.
Every engineering team member has two checkpoints per year to receive feedback on their efforts and have skills validated towards completing their current level.
However, leveling up once a year is not a right; it remains a goal since one needs to work towards it. At the same time, leveling up once a year is also not a limit. Some individuals can grow faster, so leveling up twice a year is possible.
Technical Breath
The more versatile an engineering team members is, the better for both the team and the individual.
Since engineering team members work in cross-functional squads, technical breadth and versatility are crucial. No one is specialized in doing only one specific engineering tasks, such as backend, UI implementation, or testing, for instance. Engineering team members must develop their skills to cover any tasks that projects usually require to remove the dependency on specific individuals. In addition, team members must strive to add more tools to their toolsets, such as new programming languages. Both Web and mobile engineers should strive to work on more than one of the team’s current stacks.
Having engineering team members with a wide breadth of technical skills removes many logistic blockers in sprint planning and squad management. Team Leads can confidently assign any tasks to any team member on the development squad. Engineering team members are selected based on proven technical skills through past projects or certifications when assembling squads. As a result, engineering team members experienced in both Ruby and Elixir can be assigned to a wider diversity of projects, thus enriching their experience further. Like a virtuous circle, wide technical breadth fuels individual growth.