Determining Differences Between Position Levels
I've acquired a new team that I'm not entirely familiar with all of the services the team offers, however, one of the team's biggest concerns is that they do not know what it takes for a Network Engineer I to move to a Network Engineer II or a II to move to a Senior.
Does anyone have any current documents or methodologies to specifically call out these kinds of expectations for each position level for a Network Implementations Team?
Thanks!
Does anyone have any current documents or methodologies to specifically call out these kinds of expectations for each position level for a Network Implementations Team?
Thanks!
Replies to This Discussion
-
Permalink Reply by Tim Ventura on -
Hi Alicia --
A VERY interesting question: the simplest answer is that your company should hopefully have some guidelines in place surrounding the job responsibilities & salary-range for each gradation of that role. Maybe there are guidelines for sysadmins that are close, and could be re-written for network engineers. If not, then you may have to resort to less precise methods:
1. On the most basic level, if your staff has a range of skills & experience, you can roughly sort them into groups of junior, intermediate, and senior. These correspond to the I, II, and senior (III) levels described above.
2. Several employment sites, such as (I believe) salary.com, offer 3rd-party definitions of what each level of ability means in terms of job-duties. These are vague definitions, though.
3. Many corporations (AT&T, for example) have in-house definitions that are nearly defacto industry-standards. If you surf their job postings online, you'll get a good idea what the current corporate standards are for each designation.
4. Odds are that the network engineering team already has defacto-rules in place about responsibilities. Usually the senior guys won't let newbies participate in architecture, and the mid-level folks have a few systems they're responsible for, but aren't focused on the health or operations of the entire network. It could get complicated.
Newbies are usually responsible for the least-important tasks: managing user passwords, Tier-1 or 2 support (usually they handle helpdesk trouble-tickets), etc. Obviously mid-level are more trusted, and they're usually the people that the junior staff refer the really challenging stuff too.
The mid-level staff are also the ones usually handling pet-projects: if all your storage-area-network issues go to a single guy who's overwhelmed and only seems to shower & shave once a week, he's mid-level.
Then, in my experience, the difference between mid-level & senior staff is whether they have much say in planning & architecture - which may get complicated if your firm has a dedicated architect or not. Senior staff tend to be in a lot of meetings, spend a lot of time answering questions for PM's & stakeholders, and typically have some management authority regardless of whether or not that's in their job description.
Tim
-
Permalink Reply by Keith Brugnani on -
In my past, a company I worked for had guideline just like Tim had mentioned. Teir 1 2 3 support techs and the triage person was responsible for answering the phones. All tickets were delegated to the proper level tech and it really should be easy for a company to set some sort of guidelines and delegate responsibilities.
-
Permalink Reply by Kenneth Brown on -
If you look on salary.com they have a fairly comprehensive set of position definitions. This is a good baseline that you can customize for your organization. Since each company and group has some unique needs/requirements it's best if you modify the boilerplate to fit your group's needs.
-
Permalink Reply by Dan Hollingsworth on -
Does your company have an HR dept? If so they may have some idea of what each level's responsibilies, roles, and requirements are. If not perhaps it's time to step up and help them document some.
-
Permalink Reply by Kenneth R Ward on -
Do away with those old archaic modes please !! just establish a 'Team' based compensation package i.e. if the team meets it's 'goals' then reward.
-
Permalink Reply by Ray Cassick on -
Lot's of opinions here :)
I agree with most of them, but think I prefer a blended approach myself.
I, as a person that focuses on professional growth in my line of business, like to know clearly what it takes to move from level to level and increase in my knowledge area. I think that makes many people comfortable because it establishes a clear chain of what can be done to help them grow within an organization, sets expectations up front on how to do it, and helps clarify a plan of attack to get from 'A' to 'B' and so on.
However, I also like to know that, within a team, I have an opportunity to NOT have to serialize my learning into steps, and if I am on a project that offers the chance to learn something I can take that opportunity and am not told that before I can get involved in that I have to first learn 'this other thing' fist. I have seen that allot in organizations that are very level structured where you can't even consider looking more than one step forward, even if you DO have proficiency there, just for the sake of walking the process tree.
I think they key is to use job grades in a productive way to establish a plan, but then allow for enough flexibility to look at a persons existing strengths and interests and then model their 'path' based upon a mixture of existing knowledge, targeted interest areas, their personal development plan, and what is available to them as far as training options both internal and external from their work environment.
-
Permalink Reply by Lorenzo Farris on -
If you do not already have a set of guidelines in place, first place to start is your senior engineers. Have them identify who is (or who they think) is level I or II, etc., and why. This should give you a sense the existing requirements for each level. Ideally, this will give you not just the technical skill sets expected at each level, but also the expected behaviors, e.g., independent research, communications skills, understanding of the technology space, planning, driving projects, etc. From there, it will be up to you to flesh out the requirements and expectations of each level. In my company, while the technical skills are important, success in those types of behaviors I have indicated is, in prinicple, the driving factor for promotion. You can't just educate your way to a promotion, you have to be doing the things the next level up requires already.
-
Permalink Reply by Altan Khendup on
-
I would have to agree with many of the comments here having done this myself in the past and recently as well.
1) There should be HR policies and guidelines that are outlined unless you are a startup.
2) If you want different definitions understand that it will depend on the generic definitions found at companies such as AT&T, Cisco, etc. and sites such as salaries.com or payscale.com. The HR guidelines can be very helpful in taking these and other definitions and making them more tailored for your company.
3) Please review ANY definitions with your HR before you ever put them in front of your team. You need their official blessings for obvious legal reasons.
4) Once you have some official guides, tailor them to your specific style. Such as merit-based, goal-based, etc. The official guidelines will provide the legal basis, then you can alter them to fit the company culture, goals and team itself.
Good luck!
Sincerely,
Altan Khendup
About
© 2010 Created by Kevin Jenkins.
Powered by 
.
