A developer’s level should be the level that best describes them. This does not mean that a developer must achieve every attribute of a level to be assigned that level. There are many dimensions of improvement and achievement for developers, and it is unlikely that any one individual will excel at all of them. Level descriptions are not intended to be a checklist, and we do not expect a developer to demonstrate all the attributes and behaviors at a given level to be assigned or promoted to that level. We do expect a developer to demonstrate many of these attributes, and we expect a developer to operate at a given level before being promoted to that level. A developer’s current level is not a list of attributes to aspire to; it is a list of attributes that best describes that developer.
Levels and compensation are related but not perfectly aligned. Compensation ranges will overlap across levels. While a rise in level will generally be accompanied by a raise, most raises will not be accompanied by a rise in level.
Progress towards promotions should be regularly discussed in one-on-ones and quarterly check-ins. Promotions shouldn’t come as a surprise. Promotions are to be used as long-term goals shared between leaders and reports. For example: “my goal this quarter is to accomplish X, demonstrating my ability to do Y, towards my goal of becoming Senior Software Developer by the end of the next year.” An important goal of a leader is to create opportunities for their reports to develop and demonstrate their abilities to progress their career. A leader will work with the development leadership team to calibrate performance across teams. The manager will also reach out to other developers at the desired level or above to better understand areas of development.
A promotion will generally come with a salary increase. The salary increase will be effective the date of the promotion.
When a role is opened a level, or at least a range of levels, should be targeted by the hiring manager. The hiring manager, with input from the interview team, will assign a developer a level by offer time. In addition to factoring in the interview process and references, every candidate will be assessed at the level that best corresponds to the candidate's compensation requirements. In other words (barring exceptional and rapid changes in market conditions) this organization will not "blow up" its compensation-to-level balance to attract a candidate.
The technical career track is not only a tool for technical career development within this organization. It is intended to help create career milestones and encourage career growth that will be beneficial to developers if they decide to leave AVEVA. We want AVEVA to be more than a great place for developers to work. We want it to be a great place for developers to develop skills and experience to open new career opportunities. At AVEVA the level should mean something. Progressing from Software Developer 2 to Senior Software Developer should set up a developer for more senior development opportunities at other companies. We can’t control external title inflation, but we can control what it means to have a title at this organization. Our levels are intended to represent meaningful experience and achievements while at the same time calibrating well against the industry at large. The levels should be viewed as career steppingstones, not just this organization's milestones.
It is assumed that an Engineering Manager will have at least reached the technical level of Senior Software Developer and be ready for promotion beyond it before forking to a leadership career path. For example, a developer at level Software Developer 1 is not technically developed enough to credibly manage.
Although Architecture appears on the technical track, individuals in the top tiers of the technical track have significant influence in the department and are considered leaders.
We are aware there are roles needed to organize above the team level to accomplish more complex solutions. We would like to focus on these job roles and responsibilities instead of titles.
This question brings into light the many roles that need to come together within Operations Information R&D. Scenarios that drive valuable outcomes The SPM will define high value scenarios that span AVEVA’s Operations Information infrastructure. Use cases and Features The role of the TPM is to work with the SPM to break down the scenario into Use Cases and Requirements that define features within AVEVA’s Operations Information data infrastructure with clear acceptance criteria Development Team The development team or teams work with the Principal Software Developer or Architect assigned to a program to take these artifacts and perform software design which ends in what deliverables meet the Scenarios, Use Cases and Requirements. We should communicate the deliverables and estimates on when these deliverables can be achieved. Iterative Process This is coordinated, shared, iterative process that requires constant coordination and clear understanding of roles and responsibilities
The answer is a shared responsibility.
Two important things to keep in mind as we answer this question:
With these two topics in mind.