My approach to Management

This is a topic that I have been asked to talk about quite a bit recently and I thought that it would be worth writing a brief article on the subject. There are many different approaches to management that can be successful and here I am not looking to present best practice, just to outline what has worked for me over the years. We are all individuals, as are the people we manage, and different things will work for different people at different times.

Helping people to climb to the top...

I first started managing people in 1992 at the tender age of 26. My preparation for this elevation was being a team leader for the previous three years. At the time I was working in a software house, having joined as a trainee analyst/programmer in 1988. As is typical in such organisations (and indeed in most other types of organisations) I had progressed thusfar by being good at design and programming, not by virtue of my amazing people skills.

As a new manager, I had little personal experience or training to fall back on. However I was lucky enough to have some one working for me who had had a long career in management. The gentleman was in his mid-50s, had previously been the IT Director of a major food company, but had decided that he had had enough of the stress of managing and gone back to programming for the last few years of his career. While having someone twice my age and many times my experience working for me might have been difficult for both of us, I guess I was at least smart enough to realise that here was someone I could learn from. In fact throughout my career I have often been lucky enough to find such people to provide advice and act as my mentor.

The person in question taught me that management was – unlike design and programming – messy and complicated and that there were no hard-and-fast rules to guarantee success. However, he did instil in me a respect for the people who work for me, a willingness to listen to them and the idea that it was my role to help them be successful and thereby help the company to be successful. The idea of achieving success through people is something that has stayed with me ever since.

Later in my career at the same company, when I was responsible for running development with 30 people working for me, I was lucky enough to have a great role-model as my manager. This person was integrity and unflappability personified. While he never shied away from addressing difficult issues, he did so in a calm and humane manner. He always gave people room to explain their views and listened to them. When it was time for him to set out his own position, he did so carefully, but clearly. More often than not, this approach brought people with him without the need to pull any of the command and control levers that he had at his disposal.

In my final two positions at the same organisation, I reported directly to the Managing Director (and owner). I had worked closely with this remarkable man throughout my time at the company, but now being his right-hand-man gave me a great opportunity to learn from how he operated. The MD was probably the most intelligent person that I ever had the pleasure to come across in a work-related environment. He was obviously very confident in his own abilities and in making assessments of complicated situations. He also would ask probing questions about areas that were of importance and had a nose for detecting any attempts to pull the wool over his eyes. The flip-side of this almost academic approach was that, if you did know your stuff and provided credible answers based in fact, then he began to trust your judgement and to allow you increasing levels of autonomy. Also, as is common with some of the smartest people, he never felt that he had a monopoly on knowledge or that he could not learn from other people’s perspectives. He was much better at admitting to mistakes, or acknowledging that some one else’s opinion had been correct than many senior managers that I have met since.

Of course there have been many other people that I have learnt from over the course of my 20 years in the IT business and I hope that I continue to learn for the rest of my career. However, the three people I have just mentioned all had a big hand in shaping my general approach to management and I doubt that the basic framework of this will alter too much in the future. Having provided this background, what does my management framework look like?

First I like to give people a good degree of autonomy, within parameters that I have set. I like to give my people assurance that one of my main roles is to be there to help when they need it. When the inevitable problems occur, I try to work with people to establish why they have happened and help people to learn from setbacks. I have found that many people respond well to being treated in this way and I think that this approach has helped me in developing managers who have gone on to greater things in their own right.

Second I have a broadly collegiate approach. This is not just to be nice, but because I believe that it is often a very effective way to work. Of course there will always be situations when decisive leadership is required and I am comfortable that this is part of my role. However in these circumstances, I think that it helps enormously if you have already built up a mutual respect between yourself and your team. Something that might sometimes be overlooked is that when you take other people’s opinions into account they can sometimes save you from making a complete fool of yourself!

Third I like to give my managers a very clear idea of what we are trying to do and why (a vision that I would also expect them to help me form), but then give them the space to achieve these objectives in their own way. Particularly coming from a technical background, as many IT managers do, it can be very tempting to think that you know best. However taking this approach can be demotivating for the people working for you, it can deprive them of a chance to learn and of course it is just possible that you don’t know best after all and that someone else will come up with a novel and superior approach.

Fourth one of my prime responsibilities is to grow talent for the organisation where I work. This means challenging your people to take on new things, delegating tasks to them even if it may be a stretch for them to carry these out in the first instance. This is the main way that people grow and the occasional false-step is a reasonable price to pay for increasing people’s experience and broadening their horizons.

Fifth is maybe the less pleasant side of management and to do with dealing with under performance. When some one working for me struggles, my first duty is to help them to be more successful. This can often require a long-term commitment to coaching and some difficult conversations about where improvement is required. In these situations I have two guiding principles: a) be as open and direct as you can be as it is much fairer on everyone and b) act sooner rather than later, the longer a problem persists the more difficult it will be to address. Taking this approach has often led to problems either being overcome, or to a mutual recognition that things are not going to work out. This latter outcome, while not exactly great, is vastly superior for all concerned to a more dictatorial approach (and also has less of a negative impact on the rest of the team).

At the beginning of this piece I mentioned that I had learnt respect for people from my first management mentor. I think that this principle underpins my entire approach. I suppose a simple summary is that I try to manage people the way that I would like to be managed myself. Of course sometimes I fall short of this ideal, but it is not a bad thing to aim for and I believe that this approach has been a significant contributor to the successes that I have enjoyed in different roles and different organisations.

Mitigating problems with the IT cycle

This article is the second of two focused on problems arising from the IT cycle. The first piece, which may be viewed here, talked about what can sometimes be the unfortunate aftermath of a successful IT project; the team seeking new work rather than the allocation of resources to the most pressing business needs. As previously explored, the problem is basically one of human nature and therefore addressing it is not straightforward. However here I make some suggestions that could possibly help.
It is not possible to totally “solve” the problem of the IT cycle; however there are some steps which can be taken which can reduce its impact. Happily, several of these are also positive for the organisation in their own right.
The Basic Problem
1. Communicate better about projects

A prerequisite to not building up monolithic, inflexible IT departments is awareness of opportunities elsewhere in the organisation. Where people have some perspective of other current and future projects, they may see opportunities for advancing themselves which, in turn, can provide opportunities to mitigate the IT Cycle problem.
2. Use similar technologies / development methodologies

The more similar the approach taken in different teams, the easier it will be for people to migrate between them. Obviously using similar development tools is one area; however it is perhaps even more important that teams adopt similar development methodologies. People can adapt much more quickly to doing the same sort of thing in a different development environment than they can adapt to doing something quite different in the same development environment. Having said this, the best case would clearly be to work in a new team in a similar way and with the same tools.

Different tools will always be needed when, for example, development of reporting and transaction processing systems. Even here, it will be helpful to enhancing flexibility if the same databases are used and if the same terminology is adopted for business objects.
3. Cross train staff

This is pertinent to development environments where these differ between teams. However, even if all teams share a common development tool-set, cross training can give people an appreciation of systems which they did not develop, both their technical architecture and business purpose. This will stand them in good stead should they be required to work on these systems.

Cross training does not have to be extremely time-consuming and extensive in scope. Much could be learnt by 30 – 60 minute seminars held at lunch time. Such work not only prepares staff for changing teams, finding out more about other systems and projects it may also encourage them to consider other roles within IT.
4. Cross train managers

At least of equal importance is making managers aware of what is happening in other teams and how. With the right attitude, such information can be the genesis of a more flexible attitude to staff deployment and career development.
5. Make use of temporary secondment

The nature of IT work (or most other kinds of work if it comes to that) is that what was a priority last year may not be one this year, but may become important again in six or twelve months. This volatility argues for some flexibility in resourcing. If department X has a trough in workload which is anticipated to last six months and department Y has a peak which is also anticipated to last six months, then seconding some of department X’s people to department Y may be an answer (this of course assumes that people’s skills are transportable – see the last two points). Of course the peaks and troughs will not always coincide so conveniently. Nevertheless, secondment can be a tool in both increasing the breadth of knowledge of IT staff and in managing fluctuations in demand for people between different departments.
6. Make appropriate use of contractors

Particularly when there is a focus on expense, contractors are often seen as a bad thing. They cost a lot, they have little commitment to the company, any intellectual capital which they accumulate during an assignment is not retained by the company when they leave, and so on. However some of these criticisms could also be applied to at least a substantial section of permanent staff. Contractors are expensive because they offer specific skills at short notice and do not require much commitment from the company. Replacing contractors with permanent staff reduces our ability to cope with the IT Cycle (though clearly when managers retain contractors beyond their useful life, this contributes to the IT Cycle problem).
The Budget Problem
7. Build IT budgets from the ground up

Rather than starting with the existing IT staff in their existing departments, a potential approach might be to assess the priorities for each year and then allocate resources accordingly. This might introduce a note of instability to IT, but this could be managed and the process would also better reflect business realities.
8. Rank projects by business benefit

If the above is not practicable, it would still be beneficial to rank the business benefits of projects undertaken by different departments. The difference here is that the assessment comes after budget submission, rather than before. However the results might be somewhat similar. If one department’s new projects all ranked lowly, then thought should be given to reallocating some of their staff to higher priorities.
9. Have departmental IT budgets vetted in detail by other IT managers

It is difficult and time-consuming for non-IT people to assess the intricacies of projects. However IT professionals are familiar with these. A review of an IT department’s budget by an IT manager who is not part of that department can improve the likelihood of the budget being closely aligned with business value. This need not be an adversarial process if seen as a method by which to enhance the quality of the budget.
The “Latest and Greatest” Problem
10. Identify what new technologies are most applicable to the organisation

As well as exciting IT professionals, the “latest and greatest” technologies may often have solid business benefits. However the state of the art in IT moves forward so fast and in so many simultaneous directions that it would be nigh on impossible to keep apprised of all of them. A better starting point might be to assess what capabilities are the basis of an organisation (e.g. an organisation might decide that the expertise of its staff and the quality of the relationships with its customers are fundamental) and then investigate what technologies best support this. This can lead to a good alignment between employing newer technologies (happy IT people) and focused business benefit (happy profit centre managers).
11. Be prepared to let some people go

Ultimately, if people want to be into the latest cool thing then sometimes we will have to let them go a do that elsewhere. It is better to try to build a culture where success rather than use of “cool stuff” is important. IT staff with a strong appreciation of the organisations business and how to support it will ultimately be a more valuable resource than a group of talented technicians.
A General Suggestion
The above problems are all essentially managerial in nature. The final strategy addresses this head on and is perhaps a prerequisite for progress on the other ideas.
12. Provide incentives to IT Managers who effectively manage staff numbers

People are after all human and nothing helps quite so much in aligning the goals of the corporation and the individual as targeted incentives. Such incentives can be direct (e.g. bonuses for re-deploying staff) or indirect (e.g. annual objectives including one pertinent to this area or the manager’s attitude to effective use of resource being a criteria for advancement).

If an organisation is suffering from the problems inherent in the IT cycle, then I would recommend this final step as the first one to take.

Problems associated with the IT cycle


This article examines an area that is often one of some debate in both IT and business circles; namely issues pertaining to the size of IT teams, the length of IT projects and the ongoing expense associated with both. Here I will attempt to analyse problems associated with the nature of IT work and IT management and to identify the underlying reasons for these. In a forthcoming article I will offer some ideas about how a more flexible approach could lead to more efficient deployment of IT resources and thereby enhanced business value.
The IT cycle

Figure 1 - The IT Cycle
Figure 1 - The IT Cycle

Systems’ development is inherently a cyclical activity. An example of a typical cycle appears in the above diagram. The solid line, bordering the blue area, shows how resource is built up over time in order to develop an application meeting a business need and then requirements for resource fall as the system stabilises and moves into maintenance mode. There are a number of distinct stages: –

1. Feasibility
2. Preparation
3. Development / Testing / Deployment
4. Maintenance
Each of these is stages characterised by, amongst other things, different resource levels (these stages are described in detail in Appendix A – Description of project stages, and the levels of resource required are described in Appendix B – Resources required during different project stages).

The above may be seen as a somewhat idealised – and certainly simplified – view of a project. For example, a project may have more than one phase, the first could roll out basic functionality, the second enhance this with less time-critical (but none-the-less important) functionality, the third could extend use of the system to other business areas or locations. In these cases, the point at which the project first goes live is not the beginning of reducing staff numbers. Instead at this point two teams are needed, the first to support the live, phase one system, the second to continue to build phase two. This would frequently lead to a resource increase at this stage.

Also by the time that the system is deployed, business focus may have changed, leading to substantial requirements for modification or enhancement. This is essentially the same model as phased delivery of fixed requirements, it is just that the planning of the overall project is more fluid.

Nevertheless, such refinements of the model do not change the basic message. At some point (possibly extended by planned or unplanned phased deliveries), the system will meet the majority of the business requirements and new development activity will offer diminishing returns. At this point, the system needs to be put into maintenance mode and less staff will be required. This is the essence of the IT cycle.

I will now consider some problems that the IT cycle can lead to.
The Basic Problem

Having reviewed some aspects of the IT cycle and explained how this applies to all systems development, regardless of how extended this might be, we can now focus on the basic problem that this model presents.

This basic problem can be seen as one of inertia – the tendency of things to persist in their current state unless impacted by some external force.

Over the first three stages of the IT cycle, focus has been on developing a strategy, building a team to execute it and then realising the vision. Anyone who has been involved in this process will attest to the collective pride and comradeship that develops with the team. A feeling of “us against the world” can take hold, followed by an immense sense of joint achievement when a system is successful. People often also grow through such a process, junior analyst/programmers become senior analyst/programmers. Designers become more experienced. Project managers become battle-hardened. As a result of this, at the beginning of what would be the maintenance phase, the IT organisation is left with a group of people who are creative, successful, focussed on development rather than support and have the mindset of wanting more challenges. Such people have a high value in the market and are more than aware of this.

Therefore, the IT organisation has both a challenge and an opportunity. The successful project has resulted in more experienced and able people being available, but where will their next challenge come from? This situation can be addressed in two ways. The former is harder to achieve and less often practiced, the latter is the path of least resistance and more prevalent than many IT managers would like to admit.

Option A – Assess what the current, pressing business priorities for IT are and devote the best people from the completed project to these.

It is likely that there is more than one area to which they could contribute. Maybe they will be able to take on a more senior position in their next project. This option is not as easy to achieve as it might seem. Consider two projects, X and Y. The former has been very successful but is going into maintenance mode and requires less staff. The latter represents a current business priority. Assuming the goodwill of the managers of both projects, potential obstacles to behaving this was would still include: –

people in Project X have different technical skills to those in Project Y and so cannot simply transfer and start work immediately
people in project X may have a different way of working from those in project Y – this may present cultural difficulties which are disruptive to both new starters and existing staff in Project Y

However, because it is a very positive outcome, I will devote some time to how the obstacles to this option can be negotiated in a later article.

Option B – Try to find more work for the existing project team to do in the same area.

It is a lot simpler to take this approach. People often appreciate continuity more than new challenges. It is generally the case that there will be more work which can be done, the question is rather the value of this work compared to what the same resource could be doing in other areas.

There are some very human factors that can reinforce this approach: –

managerial prestige (or, less kindly, empire building)
rewards and progression being seen as tied to managing bigger and bigger teams
job security of the management of the project moving into maintenance mode
lack of appropriate positions for staff elsewhere in the organisation
the effort involved in building the project team being seen as wasted if it is “broken-up”
the desire not to fire staff, particularly those who have served the company well and just completed a major project successfully
business sponsors wanting to retain “their staff” anticipating further work at some future stage
“rewarding” past work with more work

The combination of these factors can modify our resource graph to look more like Figure 2 below.

Figure 2 - The problem with the IT Cycle
Figure 2 - The problem with the IT Cycle

Here, when the project has notionally reached the maintenance stage, resource does not reduce and may indeed continue to grow. The red area demonstrates the difference between actual staff numbers and what the IT cycle model would predict. This may be seen as excess resource, or perhaps as a loss in productivity in IT. If, instead, this excess resource can be re-deployed, we have an opportunity to increase the overall effectiveness of the IT organisation.
The Budget Problem

The normal budget process can exacerbate this phenomenon. Often the manager of an IT department will start with their existing budget plus wage inflation as a base line. Anticipating future cuts, they may increase this by say 20%. What then follows is a turf war with each IT manager trying to hold on to their budget. While there is no incentive for any given manager to take a more flexible approach, such behaviour is rational and will continue. Of course it should be stressed that IT is not the only area to suffer from this type of problem.
The “Latest and Greatest” Problem

On top of this we can add some attributes of IT staff which, although generally desirable, can have a downside as well. Many IT people want to be involved in the latest and greatest technology – this is not always what is going to add most value to the business. Sometimes, in order to retain the best people, IT management can give in to this trait. At the positive end of the potential results, this can lead to happy staff and greatly enhanced systems. At the negative end are projects to re-write systems in new technology for little reason other than the staff would like to do this and may leave if they do not get the opportunity.

There is no right answer here, what might be seen as indulging IT staff’s whims may actually be the hard-headed, practical thing to do in some circumstances. What is most important is to achieve an appropriate balance between the need to retrain and motivate the best staff and the need to align work to business priorities.
So there are a number of problems facing IT in this area. However I believe that they are all tractable and I will offer some ideas for addressing each problem in a future article.

Continue reading about this area in: Mitigating problems with the IT cycle.