Defining Seniority in IT

Seniority within Information Technology (IT) departments has always been a hard thing to define. The technologies in use shift so rapidly and people move jobs quite often; that determining who is the most Senior person on a team is often not as simple as who has been there the longest or who has worked in the field the longest.

Seniority in the sense of this posting is having the position and experience that the fellow members of your team go to you when they have questions, need advice or otherwise need a second opinion on what they are working on. Seniority is also defining the person that your managers are most likely to go to when they need direction on a project, or need to delegate important work.

Traditionally, companies have often set seniority within a team based primary on time within a given job. This is a less adequate measure in IT because the technology changes so rapidly, a person must keep up with both the technology and what are often called soft skills. These soft skills enable an employee to be more flexible in what they work on, and more dynamic in who they interact with within a company, based on the project and needs of the day.

So, ultimately, what makes you as an employee more senior within your team and subsequently more valuable to the organization?

When positioning the more senior staff up with the lower experienced team members, it is a balance of multiple skills and experience types. One does not necessarily replace another, and a truly Senior member of any team must posses all the following skills at a minimum, with an emphasis on some more then others based on the job role:

• Contributions (Time, Company Goals, Knowledge) - Contributions are the most important part to establishing a position as a Senior member of an IT team. Contributions can be technical in nature, time or knowledge, but all show other members of the team both your dedication, capabilities, and commitment to the future success of the company.
• Experience (Current Technologies, Past Technologies) - Experience with a wide range of technologies and hardware will enable you to make informed decisions and suggestions on future direction and architectures. A wealth of knowledge and hands-on experience will ensure that no matter the problem, you will have experience in how to approach it, even if the specific technology is a new one.
• Understanding of the existing IT Infrastructure - A solid understanding of any existing IT infrastructure will enable you to fully understand legacy burdens when making future planning decisions. It also enables you to understand where the company has been and what has been tried so that if something worked or did not, that can properly be taken into account on future solutions.
• Understanding of the business problem to be solved by IT - Information Technology (IT) is not the primary, driving factor for the majority of businesses. The majority of the companies out there only use IT as a way to meet their primary market more effectively. The most senior staff in IT must understand not only the IT aspect, but the technology and business behind the companies primary market. This ensures that IT is properly aligned and working towards the larger company-wide goals.
• Ability to interact with varying levels of staff and management - Interacting with various levels of staff and management within a company is an important skill. It shows that you not only understand the challenges of each level, but you understand what types and details of communication need to be understood at each level. The proper level of detail and big-picture at each level of communication can ensure quick decision making and solid support from executive management when escalations are necessary.
• Understanding of the company direction - Having a full understanding of a companies long term goals and direction allow IT staff to ensure that suggestions, plans and comments will not become obsolete early in the project life cycle. By showing your managers that you understand the direction, allows you to put the companies best interests first and work towards hitting those goals.
• Time Management - Time management is your ability to prioritize projects based on deliverable dates and ensure that appropriate forward progress is made on all projects to meet the appropriate targets for delivery. Time management shows senior leaders at the company that you understand the complexities of juggling many projects and can compensate as unexpected items come your way.
• Project Management - Project Management is your ability to manage not only your tasks and deliverables, but the dependencies between them and the work of other staff. This type of leadership enables you to work with larger, more complex teams, as well as provide status updates to management on project progression.
• Knowledge Transfer (Mentoring) - This is your ability to assist other staff in developing, both company specific knowledge, as well as industry knowledge. The goal in this category should be to develop into a staff member that others are comfortable speaking with for advise and input, knowing that you can provide a unique, relevant insight for them.
  

Now - the big question - "What about my salary, how does that relate?" - Salary is a difficult subject for some folks. Some people prefer to discuss salary as a very private matter, others feel it is a public topic for discussion. Regardless of a person's choice, their salary is a reflection of the value a company sees in them. If a company is willing to provide a higher salary, they expect a higher level of return. The more traits you posses from the above list and the higher level of development of those traits will translate into your ability to provide more value to your employer.

I hope this has provided some insight into how staff are defined as Senior within IT. Ultimately, it should be your goal to develop the proper balance of the skills listed above, based on your job role. The more experience you can gain in each area and the more expertise, the wider a range of jobs you can hold and staff you can interact with. That flexibility will create value for the company you work for and put yourself at the top of your peers.

Risk Workshops

Risk workshops are an important part of managing risk for all projects. They are typically done at the beginning of a project and any time a major change is made to the requirements or acceptance documents for the project. Risk workshops are brainstorming sessions to develop a list of risks for a project and determine the factors associated with those risks so that they can be mitigated.

Throughout this posting I use the word project a lot. In this context, project is a defined set of activities with a given beginning and end. Projects are common in all companies to take a unit of work and properly manage that unit of work to completion.

A Risk Workshop is a sit-down, face to face, thorough review of all aspects of a project. This commonly includes delivery schedules, acceptance plans, project financials and contracts associated with project delivery. The primary purpose of the risk workshop is to allow both project participants and outside observers to brainstorm all possible risks that could come up and come to agreement on risk level and mitigation strategies.

There are 2 priorities for all risk workshops. All participants should enter with these at the top of their mind as they look for mitigations strategies and project plan changes:

1. Protecting the company from financial loss. This can include penalties for delays or missed features, or having to redo work because of low quality.

2. Delivering the project on-time. All risk mitigation strategies should be worked together with developing the project plan so that estimations are realistic.

The primary deliverable for all risk workshops will be a risk workbook. The most common categories to track for each risk in this workbook are:

1. Risk Number – A unique identifier for the project so that team members can clearly communicate about each individual risk.

2. Raised By – The name of the individual who first brought up the risk. This should be tracked in the event clarification is needed about the risk or impact.

3. Date raised – The date that the risk was first discussed. All notes associated with the risk should have associated dates as well to track the progression of the risk discussions.

4. E/B/C – Engagement/Business/Customer – This category will define the risk type. Engagement is a risk associated with contractual details or the relationship between customer and vendor. Business risks are a risk that a product lifecycle may change or priories shift for a team. Customer risks are associated with delays on the customer side, either because of pre-requisites not being met or changes to the customer's requirements.

5. Description – This is the detailed description of the risk, what it affects and any supporting details to what could trigger it.

6. Risk Cost – This is the monetary cost of correcting the risk should it become a problem during the project. This includes time, facilities, and all associated resources needed to resolve the risk should it become a problem.

7. Risk % - This is the chance that the risk will occur during the project. This is used in pair with the risk cost to determine a risk budget for the project.

8. Mitigation Strategy – This category defines the solution for mitigating the risk. This should define what steps will be taken to lessen the chance of the risk turning into a problem. This could include additional staff on the project, earlier testing, or a chance in architecture.

9. Mitigation Cost – Mitigation cost documents the cost to minimize the chance of a risk occurring. This cost is then compared to the chance of the risk occurring and the cost of the risk occurring to determine if the mitigation cost should be spent, or continuing on the project and managing the risk if it does occur.

10. Risk Owner – The risk owner is the individual that best understands the risk and associated mitigation strategies. This is most commonly the person responsible for monitoring for the risk occurring and documenting the risk mitigation strategies.

11. Risk Trigger – Not all risks will become problems and impact a project. The risk trigger is what defines when the risk does become a problem so that staff can take steps to address the problem.

The first part of any risk workshop is to discuss the objective and purpose with the participants. All risk workshops should begin with a discussion of why the team has come together and what deliverable is expected at the end of the meeting. This deliverable will most often be a risk workbook containing all risks and their associated risk level, potential cost and mitigation strategies. All risk workshops should set time limits to ensure that if a discussion occurs on one risk, the meeting time is not overwhelmed. This time limit is too ensure everyone has a chance to speak on the topic. If consensus is not reached in that time frame, someone delegated by management should be responsible for getting input from all parties and making a decision on the risk level and other details.

I can not remember a project that I have worked on that had zero risk, or a list of zero risks. All projects have some level of risk, and the purpose of a risk workshop is to clearly define them and the plan for avoiding delays because of them. A long list of risks coming out of the risk workshop shows that the team was successful in thinking of possible pitfalls and mitigating them. The purpose of the meeting should not be to have a list of zero risks, that is not the same thing as a zero risk project.

As part of the risk mitigation portion of the risk workshop, there are two primary strategies for handling high risk components of a project:

1. Redesign – Often times a design can be redone to limit, or minimize the risk of a project. The redesign may have other impacts including cost of delivery or schedule impact that must be weighed against the potential risk.

2. Risk Mitigation – Mitigation is the most common strategy for managing risk. This is the early planning of how to handle a risk, should it become a problem. Mitigation often involves having clearly defined paths for escalation to other teams or additional resources available.
   
   

Ultimately the risk workbook will be used to develop a risk budget. This risk budget will be built into the project financials to ensure adequate resources are available to respond to risks if they do become problems, as well as providing funding to cover risk mitigation as necessary.

Risk workshops are a critical component to all successful projects. A risk workshop allows for all interested parties to express any risks they foresee and how to properly plan for and mitigate these risks. Risk workshops should not consume an unlimited amount of time, but should allow everyone to express an opinion to risk levels and allow that to be documented in the risk workbook for the project. Risk workbooks are living documents for the duration of a project and provide a single reference for developing the risk budget and showing mitigation strategies for a project.

Time scheduling for IT Staff

Information Technology (IT) staff often must juggle both daily demands of user requests and daily repair activities, with long term projects like upgrade testing, capacity planning and new feature evaluation. These two distinct types of work are difficult to juggle, in addition to a never ending array of meetings, office interruptions and service outages. Many IT jobs today are high stress, both because of the level of work to be completed, but as well as the chronic mis-management of time, creating both higher stress levels and lower productivity levels.

As with all professions, the goal with time management, by both staff and management should be to minimize context switching. A context switch is each time a person must change from one task to another; this can include changing project focus, phone calls, office interruptions or stopping a task to goto a meeting. By limiting context switching IT management can allow more time for staff to focus, and provide them clearer blocks of time to complete their work, in a more efficient way.

It is quite common within the IT space to schedule meetings mid-day as well as pull staff into meetings during the day. This is quite disruptive and often not necessary. It is important that managers within IT organizations clearly define what constitutes an emergency and how to properly justify pulling staff away from their daily work load versus planning for a meeting in the future.

Suggestions for minimizing interruptions and increasing time utilization:

Meeting Free Days – Blocking out days specifically for meetings will allow the remaining days to be used by staff to focus, free of interruptions on long term projects, research and other work that is more efficiently completed during a focused period of time.

Set Aside Time for Ticket Based Work – It is very common for IT organizations to have a ticket tracking system to handle incoming requests and common tasks. This should be monitored by a dedicated person; if that is not possible time should be dedicated for other staff for monitoring. Tracking and managing many small requests in the middle of project based work is very disruptive and negatively affects productivity on the long term projects.

Clearly Defined Office Hours – Clearly defining staff's office hours can set a stage for limiting interruptions to minimal times within the day and giving staff dedicated time for focusing on ticket based work and project based work. This will ensure that staff are available for drop in discussions, but that these do not dominate their available time.

Staff Privacy – One method to ensure IT staff can focus and ensure time is used properly is giving IT staff a private office and workspace. All IT jobs require some level of collaboration, but they also require time to focus on projects and work as an individual. This focus requires a place free of interruptions like ringing phones, conference calls, others talking in the hall way and side discussions.

Within IT, time management is important to ensure staff can properly focus on both daily needs as well as long term projects and goals. By minimizing context switching by the use for dedicated blocks of time, staff can have better focus and concentration on their projects, and ensuring completion on time and minimal delay and interruptions.

Importance of Code Reviews

Code reviews are an important part of the software development process. They are the period during development where a more senior team member reviews the code written by another team member, prior to submission into a companies version control system. Code reviews are a formal process to both improve the quality of submitted code, as well as to allow for mentoring of all developers on the team.

Any time a piece of code is being submitted for eventual inclusion in an application, a code review should be part of the process prior to formal inclusion. This ensures that a minimum of two people review all changes to the software to check for defects. This code review process also ensures that knowledge is duplicated within the enterprise to better manage project transition and long term support responsibilities for all applications.

There are several primary areas that should be of focus for all code reviews:

Company Coding Standards
All companies should have standards for software development. These should include the libraries used during development, the documentation of the code base and the languages used for development. This is the first item that should be reviewed during all code reviews. By reviewing all code for adherence to company standards, it ensures all team members not only follow the standards, but have a chance to learn any standards that they may not be aware of or that may have changed.

Company Enterprise Architecture Standards
In addition to company coding standards, all firms should have a formal set of Enterprise Architecture (EA) standards. These often include how data is stored, managed, tagged, backed up and secured during transport and manipulation. All code reviews should ensure that new code being submitted follows existing company EA standards for ease of interoperability, as well as long term software life cycle management.

Mentoring
Mentoring is a key component of all code reviews. Code reviews allow senior staff to review code of their teammates, and provide them suggestions for improvement based on experience. This mentoring is key to ensuring better long term quality from all produced code, as well as for providing staff a path for development. Each staff member that is having their code reviewed could potentially be reviewing code in the future, so it is key that this mentoring process be official, and an important part of the software development teams culture.

Security
In today's IT environments, security is a critical component of software development. All code reviews should include a portion of time for reviewing security to ensure that input and variables are handled securely, that temp data is cleaned up properly and that host to host communication is handled in a secure fashion, just to name a few.

Security is a complex topic, especially in the software development arena because of the wide range of attacks, challenges and threats. Code reviews allow for a formal process to ensure common mistakes are not made, previous mistakes are not made again and that staff have a forum for discussion of implementation details.

Scalability
Today, many applications are scaling to levels of usage never first envisioned when the application was written. This causes many problems for both the administrators of these applications, as well as the users. Code reviews should ensure that applications are properly handling resources like CPU time, system memory and disk bandwidth as to allow the application to properly scale over time. Scalability is a combination of many components, both the responsibility of the developer and other IT administrators; code reviews should ensure that all code written is properly prepared to scale over time and handle even the most extreme loads on the system.

Coding Quality
Ultimately, the final key of all code reviews is ensuring quality. Quality can come from many aspects of the code base including documentation, ease of understanding of the code and the maintainability of the code. These are all key aspects that if properly addressed and corrected during code reviews can ensure not only better developers, but more manageable code over time.


Code reviews are an important process component for all companies developing software, either for internal use or external sale. Code reviews ensure that staff are formally mentored on the code they contribute, allowing them to increase their skills and experience as developers and become more valuable to the organization over time. A side effect of this mentoring is higher quality code submissions, with fewer defects and better long term manageability of the code base.