While non-leadership .NET positions are rarely uniform across teams and employers, our research shows far greater disparity at management level.
What your business sees as a .NET Lead, an Engineering Manager, or a Head of Engineering position in terms of ability, responsibility, salary and career goals are – based on the data – likely to show a markedly different perspective from other technology leaders.
Insight into the most commonly held .NET leadership roles is essential in terms of increasing your ability to attract new hires and retain existing .NET professionals by aligning your positions with industry standards.
To that end, we spoke to 551 individuals who had held .NET leadership positions,
in order to to break down managerial structures in their engineering teams
and understand their career path and motivations.
The most senior of their teams, .NET Leads are adept at everything .NET and are able to operate autonomously on projects, delivering user stories without supervision. They may or may not directly deal with the company’s Architecture, though they would be able to understand and describe its back workings.
.NET Leads are highly technical and are focused on hands-on work. They may lead and manage small teams of engineers, but they will not have the same level of overall accountability or managerial work that Development Managers and Heads would have.
Despite their title being technically less senior, they may nonetheless have more experience or capability, just less interest in working in hands-off managerial roles.
In a nutshell, they:
- Are hands-on
- Specialise in their field
- Can deliver user stories of any level unsupervised
- Can understand and describe Architecture, but are not likely to work directly on it unless in small organisations
- Have some accountability for technical decisions and direction
- Are familiar with Agile and Scrum methodologies. May be asked to step up as a Scrum Master when necessary
- Can lead and manage small teams, offering mentoring and on-project leadership
- Would report to a Development Manager or Engineering Manager
.NET Architects are those engineers that have chosen not to go into management or hands-on technical leadership. Typically, they sit outside the regular 'progression' of the .NET Engineer, which can make tracking their career difficult.
Architects are unlikely to deliver user stories, focusing primarily on the management and administration of the complex architecture. They typically own technical decisions and direction and will have a degree of influence across the business. In Agile companies, they will be unlikely to take an active role in ceremonies. However, they will be the point of contact for all Architecture-related decisions and guidance.
In a nutshell, they:
- Can describe complex architecture and all decisions that sit behind it
- Own technical decision and direction
- Are able to influence across the business and explain technical, business and Architectural concepts
- Are unlikely to deliver any user stories
- Are unlikely to play an active role in ceremonies
- Can provide Architectural guidance as needed to all levels of engineer
Principal .NET Engineer
Principal Engineers are senior-level engineers that do not have a specific team reporting to them. Instead, they move from team to team offering assistance and direction as necessary, helping to resolve difficult issues and mentor other less senior members of the team.
Principal Engineers are the primary ‘firefighters’ of the Engineering function, using their expertise to help troubleshoot and untangle business-critical issues. Principal Engineers are often responsible for proof of concepts and offer insights into the technical ramifications and necessities that come with business decisions.
Principal Engineers regularly evangelise new tech to the teams and will generally only report to the CTO or Director of Engineering or Architecture.
In a nutshell, they:
- Are hands-on with technology most of the time
- Move between the different teams, assisting with complex tech problems where necessary
- Are often responsible for proof of concepts and adoption of new tech
- Evangelise best practice, scalability and performance
- Are the troubleshooting/escalation point for business-critical issues
- Help to upskill the team via coaching and mentoring
- Don’t usually have anyone reporting to them
- Are usually the strongest engineer in the business
- Support commercial decisions by providing technical insight
- Typically report only to the CTO or Director of Engineering or Architecture
Engineering – or Development – Managers are the first step away from hands-on work for .NET professionals. Engineering Managers will have come from a background as a developer or software engineer, giving them the technical know-how they need to manage teams of developers.
They also need to have great interpersonal skills, as a large chunk of their job pertains to the management of their teams, including managing leave, offering career advice and planning, holding 1-to-1 sessions, arranging training, and ensuring a consistent output of quality work.
Engineering Managers will have a hand in developing their teams, including hiring new developers to fill gaps when necessary.
In a nutshell, they:
- Are hands-off
- Specialise in their field
- Often manage teams of 10+ engineers
- Take pastoral care of their team, including holding weekly one-to-one sessions and managing training arrangements and sick/holiday leave
- Are responsible for their team’s career planning and road mapping, appraisals, and performance
- Are familiar with Agile methodologies and are capable of implementing and enforcing them
- Manage the team and pipelines to ensure completed work aligns to project needs
- Ensure that the team is enabled to do their work, and manage any roadblocks that crop up
- Are in charge of quality management in their team, taking responsibility for all output
- Help to hire new engineers for the team and ensure effective team structure
- Help to make Architectural decisions and shape product direction
- Would report to the Head of Development
- Need to have good interpersonal and managerial skills
Head of Development
The Head of Development – or Head of Engineering, as they may be called in some organisations – may be hands-off or hands-on, but will likely lean toward the latter in smaller organisations.
Heads are more likely to be tech agnostic than Leads or Managers, and they should be the last line of defence against faulty code . Their role is more overarching, encompassing team management, resource allocation, reporting, culture development, and project management.
Heads need to have stellar interpersonal and management skills to succeed, along with a good head for long-term, big picture business planning and strategy.
In a nutshell, they:
- May be either hands-off or hands-on, depending on the size of the team and organisation
- Are likely to be tech agnostic, with a broad knowledge spanning multiple languages
- Will need to firefight complex challenges that crop up
- Implement and nurture the culture within the engineering team
- Ensure all code produced is high quality and up to standard, doing what it should
- Ensure the right tooling is in place, to free the team up and allow them to add to business value. This can include automation and continuous integration
- Allocate resources (both human and monetary) and manage all projects with an overarching view of business needs and the big picture
- Are responsible for all the developers in teams (including Development Managers) and ensure deadlines and milestones are met
- Perform high-end line management duties, focusing on aspects such as long-term planning and conflict resolution
- Would report to the CTO or Director or VP of Engineering (depending on the organisational structure)
- Require exemplary interpersonal and managerial skills
- Likely have large-scale budgetary responsibilities
Remember your business is unique – there is no “one size fits all” that you should adopt.
Clear separation of duties is most common in larger organisations where multiple teams exist. In smaller businesses like startups, the Engineering Manager may be eschewed in favour of a CTO that performs all the Engineering Manager duties in addition to their own. Likewise, hierarchies in a smaller organisation may be flatter than in a larger one, meaning an Engineering Manager may not have a Head of Development to report to, or a Head may not have Engineering Managers between themselves and the Leads.
The single best way to approach this is to create a list of every task that will be performed in your function now and assign each to a position. Now do the same for where your function will be in 12 months’ time – consider your existing hires and their career growth, and new hires you’ll be able to make. This is your own personal model and it will work better for you than replicating the structure of Spotify or any other technology behemoth you admire.
Create total clarity surrounding the specifics of each role and the growth path within it.
Job titles are a good start in defining roles, however there can be uncertainty caused by companies that mis-title their employees or job adverts, or because of the inherent blurring of roles that occurs in senior positions.
To eliminate any confusion for your incoming hires – or for the team surrounding them – ensure that the entire spectrum of their job role is clearly detailed from day one and is available for them to refer back to whenever necessary.
Put ownership of Architecture in the right place for your enterprise.
Typically, engineers look to one of three routes of progression when considering motivations; management, technical leadership (whilst remaining hands-on) or Architecture. For the first two, the progression would lead into an Engineering Manager or a Technical Lead/Principal Engineer. With Architecture, the progression is often less clearly defined.
By making Architecture accessible to the Engineering function, and by building a clear career path into that team, it becomes a lot easier to plan a learning curve that matches the motivations of those looking to step into Architecture long-term.
Ensure pastoral care is made a priority in the firm.
Pastoral care being treated as an after-thought is commonplace in Engineering functions, with the responsibilities often added on to the end of a Technical Lead/Engineering Manager’s remit, without a semblance of whether this is the correct positioning for that team. This can lead to dysfunction within the team/function, as the pastoral needs of the team function go unmet.
To avoid this, pastoral care needs to be considered with the same gravitas as Architecture or work processes. By ensuring clear reporting lines for each member of the team, you can ensure that the needs of each employee are being met and that issues are dealt with by somebody who is adept at and comfortable doing so.
Ease staff into management based on evidence.
All too often, good Engineers at a senior level are shoe-horned into management-based roles with little training or understanding of whether that employee can, or even wants to, manage a team. In these cases, the engineering team inevitably ends up being mismanaged, leading to a lack of job satisfaction within the team.
Once it’s been established that management is something that motivates a particular person within the team, the best course of action is to begin with smaller leadership tasks that offer insight into what management entails, under the mentorship of another who holds experience at this level. You can even offer an option that allows employees that have transitioned into a management position to cycle back to a fully hands-on, non-pastoral position if they feel that the role of a manager is not a good fit for them.
By easing staff into these responsibilities with a clear succession plan, you can be assured that, once this person becomes solely responsible for a team or a function, they will be fully equipped to succeed.
Remember that job titles are not necessarily a measure of experience or seniority.
While job titles generally do show career progression, it is important to remember that this is not always the case – especially once you reach more senior roles. While the progression from .NET Engineer to Senior .NET Engineer to .NET Lead is an assured depiction of career growth, a .NET Lead that stays in their role for years on end is more likely to be someone uninterested in a managerial position rather than someone stagnating in their career.
For a .NET Lead, progressing to a role as an Engineering Manager could be unappealing due to the necessity of becoming more hands-off and having to lead a large team.
However, if Leads don't receive pay increments to match their level of expertise, they may feel pressured into management despite lacking the interpersonal skills or desire to manage a team of engineers.
Senior managerial roles often focus less on technical aspects and more on the hiring, teambuilding, and standards and practices capabilities of the applicant. This may be why someone refuses a perceived career step upward in their career, or prefers to go from Lead into consultancy roles or similar.