If you’re struggling to keep up…
How to build momentum as a software engineer
Most software developers experience pressure in the form of requests, deadlines, and questions. The greater frequency and volume of these pressures, the more fast-paced the work environment. Most developers will hear about scrum, agile, sprints, and project management in these workspaces, and they will seek to understand how this process works to contribute effectively. Providing context and understanding of what is needed by the team’s staff (which sometimes includes an engineering manager, project manager, and technical project lead) is essential in the onboarding process.
This blog post will share more about these roles and how to navigate workplaces that incorporate Agile practices.
Common roles in a software team
There are different ways to build a team. Let’s discuss common roles on a software team and how each role has its specialty and tracks for growth. First, there are managers of a team. Every engineer has support for what they are building, and it often comes in roles that include engineering, product, and project manager.
The engineer reports to an engineering manager as an individual contributor (IC). ICs are not people managers, so they don’t typically have anyone reporting to them. Most commonly, you’ll have two or three kinds of ICs: Engineers, Project Managers, and Project Managers.
Engineers contribute to a team as an individual. An engineer can become promoted into a senior, principal, or staff leveled engineer based on expertise, preferences, and experience. You can also have them take on roles for projects to serve as technical lead on some work. Tech leads make decisions and guide the work from a technical standpoint. Staff engineers contribute to multiple teams. In the data space, we have data scientists, engineers, and machine learning researchers which are specialties that engineers can pursue.
Engineering managers are people managers; they manage the engineering aspect of the work. An engineering manager may lead one team of engineers, multiple teams of engineers, or manage engineering managers. They work with the other team leads to ensure that development and the health of the team are sustainable, timely, and working as expected. Some engineering managers may also take on the tech lead role for projects where it makes sense.
Product managers are ICs with domain expertise around the products that are being built. They own the product roadmap, and the vision for what is being built, and they can help prioritize the work. There are senior product managers that may contribute to multiple teams or even manage other product managers.
Project managers manage project operations and logistics. Some project managers have specialties in domains specific to certain teams is helpful and some do not. But these project managers support the project deliverables from an operational standpoint, so if someone is out of the office or a work item is canceled a project manager can appropriately adjust the pace of the team to account for these changes. If you have a project manager and work in a Scrum Agile environment can be called the scrum master.
How to build momentum as a software engineer
I recently got a question about keeping up in a fast-paced work environment from a software engineer who started a new role.
I keep getting my tickets taken away because I’ve been too slow, and it’s making me self-conscious… I only had to work with 2 people in my last role in development, so it was easier to manage. We didn’t have an ‘engineering’ manager, for example.
It’s normal to experience some disorientation when joining a new team. It’s similar to jumping into a double-dutch situation. First, you need to understand the pace of the work items being created and delivered in a set amount of time. As you join and contribute, the pace feels more harmonized with how you work and what you can accomplish.
The goal should be to complete tickets that yield some knowledge over a part of the system/service owned by the team. A small work item usually reflects a small change in the system. Seemingly small or easy tasks are repeated in different parts of the system or are meant to lead to bigger, more complex system changes. Major system changes are influenced by requirements that team leads have insight into.
Getting tickets reassigned happens but shouldn’t happen during the actual sprint. It should be left to the manager or team during planning and prioritization if your team is following a scrum pattern and you all have planning and prioritization calls. If there is no formal sizing and vetting of tickets that happens, I would reach out directly to the managers to find what tickets are best to take on.
If you happen to see something you think you can reasonably tackle quickly, I would sign up or prompt interest for that work ahead of time in manager 1:1s. It’s a tactical little tidbit that’s good for your career. I don’t believe you have to outpace anyone else on your team to be considered high performing.
In summary
I’ll say this again: I don’t believe you have to outpace anyone else on your team to be considered high performing. If you’re struggling to keep up don’t isolate yourself, start building momentum through small work items and lean into the supporting roles on your team.
