Many organizations will have an IT Team Leader – these are usually the people responsible for managing a team of engineers. They are usually technical specialists and may well have risen to their current role as a reward for technical excellence. Large IT departments will often have multiple IT Team Leaders, probably specializing in different areas. And straightaway, we can see how silos form.
An IT Team Leader is different from an IT Project Manager – although some similar skills are required for both roles. The IT Project Manager tends to be assigned per project for a fixed duration, whereas the IT Team Leader is a more permanent role spanning multiple projects.
Increasingly as the world turns agile and evolves to DevOps, we are seeing neither IT Team Leaders nor IT Project Managers, but Product Owners. In an ideal world Product Owners would adopt the best of both Project Managers and Team Leaders. After all, they are associated with a Product for longer than the usual Project time-span so they learn the technical capabilities of the toolsets, but they are delivering (ideally on a Continuous basis) to the Business so they really understand the business requirements.
Here’s the dilemma. We have found in larger organizations that the business still tends to think and act waterfall and IT wants to think agile. The Project Manager, representing the business, is maintaining Gantt charts and planning one big release. The Product owner talks minimum viable product (MVP) and two week sprints. The Team Leader is caught in the middle.
Friction occurs when the Project Manager’s objectives clash with those of the Product Owner. This source of friction is something that Daysha has a particular interest in. We see it is our job to ease this friction through;
- Value Stream Mapping to identify waste and quantify value to the customer
- Codifying changing processes in lightweight flexible tools like Jira
- Training, through traditional methods, and recently,
- running Simulations that get everyone involved.
The traditional IT Team Leader usually protects the IT team and the existing IT systems. This is totally understandable and something that any project manager would be well advised to recognize and empathize with. Some 70% of effort and budget is spent on ‘keep-the-lights-on’ activities – these are the activities such as troubleshooting and maintenance upgrades that keep the existing systems running. Everybody, especially in Business roles, see excitement in delivering new applications when the reality is that existing systems are adding customer value and must be stable/scalable, but we all know that they must also evolve.
Getting a balanced view of this is difficult where change means different things within different silo’s. Having one pipeline of work for IT Teams to collaborate on is crucial. Getting an agreement on putting this in place is difficult but our SIM is a good start. And having collaborative tools around which IT Team Leaders can engage is a critical next step.
How can IT Team Leaders help themselves? What if we could better define the Roles and Responsibilities of the IT Team Leader? And can we help IT Project Managers, Product Owners and business leaders to better understand the position of the IT Team Leader?
We believe that the following are the key areas that need to be addressed in this regard:
Culture: The IT Team Leader and the various project managers they work with need to take a collaborative approach to building software.
Different departments within your organization need to work together to find solutions to core issues that can work at effectively at every level. A culture of collaboration needs to evolve. A good project manager is politically aware and emotionally intelligent to the sensitivities involved in working with multiple departments at the same time and these traits will allow them to figure out how best to align the interests of the business, the business sponsor, the Product Owner, the IT team leader and any other significant stakeholder involved in the project.
Automation: It is the responsibility of the IT Team Leader to focus their team members in decision making and planning, not repeating the same task 70% of the time
Your team needs to focus on making the right decisions. Involvement in decision making can mean many things and have different implications. For example, complete consensus building approach might be fine in an enlightened, self-organizing team, but is not appropriate in teams who expect and are used to working in a more bureaucratic style. It is also the Team Leader’s responsibility to ensure that team members understand the priorities of the business, why specific projects are important, and why certain decisions have been made. To make the time to focus on decision making you need to automate out the routine.
Lean: Like it or not, the IT Team Leader has to be able to respond to changing requirements. A culture of agility within the team is needed.
Big ships take a long time to turn but nowadays nothing stays heading the same way for long. Smaller teams, focusing on making the right decisions can evolve and change quicker. Not getting caught up in endless red tape, not carrying passengers, not doing something because ‘that’s the way we’ve always done it’ but living in a rapidly changing world is how things are now. Team members need to understand why change is a reality. If Team members can understand more about the business and the reason for changes they will be more accepting of the need to change plans. It is up to the business, through the IT Team Leader, to find ways to share this information. Stay lean, stay mean.
Measurement: The purpose of measurement is to impart collate information and come to some shared understanding”.
Measurement of your team’s velocity is essential, because it forms the basis for valid and meaningful communication. Good communication is not the same as reporting. Compiling and distributing status reports or plans is only part of communication. Listening is just as important in this regard if not more so. Listening in this context is not just auditory, but the ability to absorb and understand information from many different sources. Using the five why’s and equivalent listening techniques brings some rigor to listening but an open mind is a great start. Minds are like parachutes – they work best when they’re open!
Sharing: Everyone’s a winner
The problem with existing silos is that the IT Team is seen from outside as a ‘black-hole’ or a cost center. The activities of the team are not transparent. If the IT Team Leader says there is only 20% capacity for new project work this week, it’s not clear why this is. It’s also never clear how the time is being spent and what value a project is getting. It is the responsibility of the IT Team Leader to find ways to inform everyone (above and below) what the actual capacity of the team is week to week. Furthermore if relationships of trust are to be fostered with the business, ongoing accuracy is required. If you don’t share knowledge, or capacity, or resolutions, who benefits?
The above are just some of the responsibilities of an IT Team Leader. Consultants, Project Managers, Product Owners, Engineers
POSTED IN: Blog