Research Byte relevant to .NET or C# professionals or the .NET market.

How To Design Motivating .NET Leadership Positions

Published by Profile picture of Jordan Barker from Talent Point. Jordan Barker on the 26th April, 2019

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.

.NET Lead

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:


.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:

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:

Engineering Manager

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:

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:

Key takeaways:

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.

Need further direction or clarification regarding senior engineering job titles
and their significance in hiring? Want to know more about other roles, or tech specialisations?

At Talent Point, we help organisations amplify their ability to attract, engage and retain technology teams by putting planning, data and career growth at the heart of their hiring.

As part of our ongoing commitment to keeping our finger on the pulse of London's tech industry so as to better serve our customers, we have released a number of the data reports and analyses prepared by our research team.

If you think what we do could help you,
we'd love to talk to you.

Otherwise, we hope you gained tangible, actionable insights to take with you
on your journey to create winning tech teams.

Copyright © 2019 - Talent Point - All rights reserved
Privacy Policy
Case Studies