What Makes a Good Manager?

I have worked with many managers over the years.  Some of them I have found inspirational, others absolutely unbearable, but I’ve tried to learn from them all.

So, what is it that makes a good manager?

Well, here’s my 5 point score for ranking managers:

  1. Understands people
  2. Is one step ahead of the team
  3. Organised and can handle interruptions
  4. Determined
  5. Honest

The first quality I’ve identified is the ability to understand people.  Management is really all about people, so a good manager needs to be able to work with other people.  When managing developers I believe empathy is the best approach, you must be able to see the world from their position (and developers can have some odd views on the world!).  However, empathy is not the only way to be a good manager.  I have seen several great managers get the tasks they want doing using psychology and salesmanship.  They can find a problem and sell a vision of how to solve it that the team will follow.  This is a good technique to have available, but as soon as someone sees through the sales process or the vision you sold them turns out to be a lie then you may never gain their trust again.  So use this with caution and only when you also truly believe in the vision as well.

The second ability I’ve recognised is in being one step ahead of the team.  As a manager one of your main responsibilities is to keep your team moving forward.  You should be clearing the roadblocks, identifying the risks to progress and trying to remove them.  To do this you need to be thinking about them before your team runs into them.  Of course some problems are going to come from nowhere and no amount of planning and forward thinking is going to help you.  In this case, you need to be available to handle interruptions and think on your feet to deal with them.  Keeping organised is going to help make sure you don’t miss any of your commitments and actions.  I’d definitely recommend something like GTD for this.

A manager has to be incredibly determined.  They carry the weight of the team and need to drive it forward in the most difficult of circumstances.  If they lack determination, the team will lack determination.  This leads to an acceptance of second best, and can quickly degenerate and destroy the team.  For more information about Broken Window Theory see this excellent post on Coding Horror.

Note that I’m not advocating blind faith.  Projects can and do fail, and recognising when they do is a skill in itself.  Continuing a Death March is no fun and one your team will definitely not thank you for.  You need to be determined enough not to accept defeat at the first hurdle, but not so determined that you waste time chasing a lost cause.

The final attribute that I think is essential is honesty.  If you are ever caught lying then all trust you might have had will be lost.  Without trust you are going to struggle.  Trusting your manager frees you up to simply get on with the job you should be doing.  Distrust leads to questioning every decision they make and is definitely going to distract from whatever it is that you are trying to achieve.  So a team that trusts its manager can focus, a distrusting team cannot.

So, there you have it, 5 qualities to look for in a good manager.  There may be other things that you also think are important, but for me, these are the 5 things that stand out.  Why not let me know if you think I’ve missed something or you disagree with any of the 5 I’ve chosen?

Posted in motivation, peopleware, planning, process, Project Management, time management | Tagged , , , , | 5 Comments

Risks

I remember being a technical lead on a project and working with our project manager and his newly introduced risk register.  Something bothered me about that risk register and the way it was being used and I’ve recently managed to figure out why – it wasn’t effective.  The process was good, identifying risks and planning mitigation strategies and contingency are some of the most important tasks of a project manager, so why didn’t it work?

I think the issue was in the identification of the risks themselves.  Whilst you can define a risk as anything that could affect the progress or outcome of a project, I think this definition is too broad.  Seriously, anything that could affect the project? The bubonic plague making a comeback would seriously affect the team, but probably isn’t worth tracking on a risk register or making contingency plans for – unless of course you happen to be working with infectious diseases!

So that was the first issue – identifying risks is hard as the risks need to be relevant, not just a big list.  Quality is definitely more important that quantity.

The second issue was in the plans he made to mitigate the risks.  A major risk identified was staff leaving and taking their knowledge with them.  Not only did this fail the first criteria of not being likely (the team had been together for years, and no-one had left in that time), the mitigation plan was harmful to the progress of the project.  People weren’t allowed to specialise, areas of the product were constantly moved between developers, extra (unread) documentation was produced, and presentations were performed to uninterested participants.

Now maybe I’m just lucky, but reading other team members code is not hard.  If someone left, the team would take a hit, but we’d soon be back up to speed.  Before a single line of code was  written on the project, the team discussed coding standards and agreed on a way of writing the software.  This common style made the code a lot easier to read and understand as even previously unknown areas felt a little familiar and welcoming.

So, the risk of someone leaving should have been classified as unlikely (even 8 years later the same people are still on the team).  The impact should have been classified as low with no need to change the working behaviour at that time.  It is ok to monitor the risk to make sure that these classifications stayed the same, maybe people would be more likely to leave, maybe the code being written becomes to specialised and key people start to emerge, maybe retention plans need to be put in place to encourage certain people to stay.  It is also ok to have thought about how to deal with a risk before it occurs (contingency planning) so that the way of dealing with it has already been considered.  A plan that covers how to transfer areas of knowledge if someone hands in their notice is a good one.

Overall we need think about how it helps the team progress.  A risk register in itself is not enough.  It must be used correctly, it should take the panic out of projects, both in avoiding risky areas that are unnecessary (some risky areas may be needed for the success of the project) and in dealing with issues as they occur (as they have already been thought through).  It should help set realistic expectations; instead of guaranteeing certain deliverables the project manager can identify a range of outcomes based on the risks to the project.  A risk register that isn’t helping the team should not be used.  A risk register that is helping the team can be a great tool.

Posted in planning, process, Project Management, software development | Tagged , , , , , , | 1 Comment

Update

It’s been a while since my last post, so I thought I should try and fill the gap a little.

I should have been posting my discussion on Risks; what they are and how to deal with them. However, having hit the word limit on the post I was writing on my Windows 7 Phone, I somehow did the wrong thing and lost the lot! Maybe one day I’ll be able to bring myself round to writing it again, but not at the moment.

I’m still going to use my phone to write my posts, but I’ve switched to using One Note and Skydrive to back it up (free with my phone).

I’ve also been spending time learning a bit of ruby as part of the excellent Nottingham Digital Events.

I’ve always had a need to do more than the usual 9-5 work thing and have a couple of projects I’ve been tinkering with for many years.  I’ve recently dusted off one of these projects and have started adding a bit of web presence to it by trying Webmatrix. This is the first time I’ve really looked at any web development and my first time using C# to any great extent. I have to say I’m really impressed with both Webmatrix as a platform for getting things done quickly and efficiently, but also C# as a language.

Perhaps, I’ll give some more details in a future post, but for now I just wanted to post something and let you know I’m still alive!

Posted in Meta, News | Tagged , , , , , , , | Leave a comment

Software Develpment and Customer Support

Here’s something that has bothered me for a while – being able to manage a software team which involves keeping on track with new developments whilst still supporting our existing customers.

First, a quick look at the history of the team and how we have managed these needs, then I’ll describe our current situation and add my thoughts on what we should be doing.

Many years ago, I worked as part of a software development team who worked on development contracts for customers. This placed emphasis on specifying the work to be done upfront, producing defined deliverables and test plans to confirm acceptance. Support involved agreeing to fix any reported defects for a fixed period – typically 6 months from delivery. Anything extra was chargeable and generally that was enough to stop any further support requests. One theory would be that we wrote better software “in the olden days”, but that isn’t one I would subscribe to.

The big change for the company and the development team was producing our own product. Initially, this was sold through a 3rd party who did a fantastic job of documenting, installing and supporting the product that whenever a defect came through to the development team, it had already been investigated, diagnostic information collected and was ready for a developer to resolve.

Once that layer of support was removed the quality of defects rapidly declined and developers had to get more involved in just figuring out what the issue was. Resolutions often just involved informing the customer of the correct way to perform an operation or the need to adjust external components not provided by us. However, we didn’t have many customers and this extra load was not too much for the team. We could offer amazing levels of support – just imagine ringing a company and being able to speak with the company expert (the person who wrote the software) about your particular issue!

This was fine for a while until we got too many customers! We couldn’t handle the amount of questions coming in without seriously affecting our ability to develop new functionality. We lacked the documentation, the installation skill and the support personnel to deal with this load.

I’ve outlined the 3 issues right there, so addressing those should be easy right? Wrong! It’s a huge cultural change to address those issues. We have taken steps in the right direction, but we still have a long way to go. We have an Operations Manager with a dedicated installation team and a full time support team. We have a Pre-Sales team to help bridge the technical gap and prevent some of the installations issues before they leave the design stage. We also have a Product Manager to help address the lack of documentation, but the increase in customers is happening quicker than those new roles and teams can keep up with.

Some indication of how much of an issue this has been can be seen in my previous post on changing managers. The first Operations Manager didn’t have enough of an impact and so we are now trying a second manager.

As part of the support team we have 4 developers seconded to the Operations Manager. This creates an issue, how does the Operations Manager manage software developers? Isn’t that the role of the Software Development Manager? Perhaps a more helpful question is why does the Operations Manager need a team of developers at all? Well, our software isn’t perfect, so we accept that a certain level of development is required to address the needs of our customers, but that still doesn’t answer the question.

The reason the Operations Manager needs software developers is that Operations is woefully under staffed. We are using developers to investigate and resolve issues that don’t need a developer to resolve. We are asking them to answer the telephone, we are asking them to fill in gaps in the knowledge that should have been documented, we are asking them pre-sales questions, we are only partially using them as developers.

But isn’t support and the happiness of our customers important, so don’t they deserve to talk to the experts and not a clueless call centre operative following a script? Sure, if you can afford to do that, then go ahead, but as we’ve seen that way of working doesn’t seem to scale. However, I believe a customer would be equally happy talking with a specialist skilled in the art of communication who is equally capable of resolving their issues. It is those 2 skills that a customer requires – good communication and the ability to resolve their issue. Communication is not always a developers strong point and many issues do not require code changes to resolve.

We have a Product Manager tasked with delivering functionality into the product, but they have no developers with which to do it. So, why would an Operations Manager tasked with installing and supporting our customers need developers? The simple answer is they don’t.

We should recognise this issue, recognise that the time of developers covering support is over and make plans for moving them back where they belong – under the control of the Software Development Manager. To do this requires a drastic increase in personnel in Operations. Emails should be dealt with on the day they arrive – not 2 weeks later. Customers shouldn’t have to ask 4 times for a status update – they get them when they have been promised, and developers can once again focus on resolving faults that have been thoroughly investigated and documented.

Posted in information, peopleware, process, Project Management, software development | Tagged , | Leave a comment

Three Levels of Object-Oriented Programming

Everyone claims to understand Object-Oriented Programming (OOP), it is taught on nearly every programming course and is supported by nearly every programming language in general use. However, if my own experience is anything to go by, then there are very different levels of understanding as to what it means to practice OOP.

I’ll outline the 3 levels of understanding as I see them:

1. Objects represent actual objects

Most courses I know start by introducing the idea of objects being used to represent real objects. They are used to explore the more advanced concepts of inheritance and polymorphism and tend to use objects such as cats and dogs as the items represented as objects. Great theory, but I want my program to do something!

2. Objects as groups of functions

This is the answer to getting objects to achieve the goals of the program – group all those procedural functions together into something called an object. Now we can at least get something done and that is often enough to add OOP to our CV. However, whilst you may be programming with objects, this isn’t really OOP.

I will confess, this was my level for many years. I’d done the theory of OO on my University course, I’d joined a small team of developers writing C++ and risen through the ranks to the point where I was leading the team, but still our programs were little more than objects being used to group functions.

The turning point for me was reading Design patterns : elements of reusable object-oriented software

3. Objects as conceptual items

Having read Design Patterns I noticed a whole new way of using objects to get a task done. These objects represented conceptual items and worked together in such an elegant manner that I was embarrassed by some of the previous objects I’d produced! Being able to produce programs that make use of objects as a way to model real-world items, can get the job done and also model the concepts of the program is the level of understanding that OO programmers should be achieving.

Posted in software development | Tagged , , | Leave a comment

The State of Project Management

As software project managers we have a reputation for delivering poor quality products, finishing late or over running our budget. Is this because as project managers we are deficient in some way, or is it the nature of our projects that makes it so hard? How do project managers in other fields get on? Can we learn something from them?

I was pondering these questions when I spoke with someone in a non-software company about how their projects are run. I’ll compare what they told me with the way we run our projects in the software world.

They work for a national charity who run projects from government and similar public sector organisations.  Before a project starts it must have received funding, usually as the result of a bid process. This necessitates a certain level of understanding of what is involved in the project and the cost of performing that work. However, it does add a level of competition that perhaps leads to over optimism and cost cutting.

The projects they run all tend to be very similar in nature even though they may have very different goals and be of very different sizes.  A project usually starts with some desk research; examining the previous work in this area and setting the context for the rest of the project.

Next comes a phase of original research; producing questionnaires, arranging interviews or focus groups, and gathering the results.

The project ends with the analysis of the new research and some form of dissemination of those results; a publication, a conference paper or other specific event.

At this level of abstraction it could be argued that producing software also has a repetitive pattern to it; we specify what we wish to build, we do some work to produce it and then we test and release it.  However, I think one of the key differences between the two types of project is in the details. Let’s explore some of those details so you can see what I mean.

Desk research has been transformed over the years and is now almost exclusively searching on the Internet for information. This can be easily time-boxed and a certain level of diminishing returns will apply (thanks to Google page rank) – after all if you can’t find something after several days of trying, how important is it?

The risks here are the same, you find something or you don’t. You are unlikely to overrun your timescales as you can simply stop when time is up and use whatever has been found so far.

The next stage of original research is again well understood. There are only so many ways in which data can be gathered. Questionnaires tend to follow a similar pattern, use a standard method of scoring the answers and suffer the same problems in analysis. The same can be said of focus groups and interviews, it is always difficult to find the right people, encourage participation and keep the discussions on track.

The final stage of analysis, presentation and dissemination is again well understood, with similar risks to be considered each time the project reaches this stage.

So what about software? Well, the things we are asked to develop can vary greatly, they are nearly always unique and often not very well understood. So we have to think uniquely about each project and be aware of the risks that apply to that particular project. We can use our previous experience as a guide, but there will always be surprises.

This pattern of pioneering continues into the development and testing stages. As we are designing something unique, we are therefore building and testing something unique. We can make use of re-usable components, we can build at a higher level of abstraction in order to reduce the timescales and risks, but the risks are still there – chances are no-one has ever used those components in the same way and in the combinations you are using them and expecting the results you are expecting.

The final part of our software project is the release stage. This stage has improved greatly over the years and is now perhaps an area with the least amount of surprises. You will almost certainly be deploying using a technique done many times before and so should contain minimal risk and be easier to plan for.

As we can see, running a software project contains many more risks and would appear to be a more difficult prospect to manage. So, we can at least feel a little better about our failures. 😉

What I really wanted to know was there anything we could learn from other industries, and in particular from this conversation?

Here’s the bit that surprised me. Our software projects were already way ahead in being able to recognise risk, deal with change and deliver results. Software project managers appear to be leading the field!

Perhaps we need to be ahead of the game, not just in our implementation of a methodology, but in our understanding of why it is important.  If our projects are to stand any chance of success we need to do all we can to help.

Being able to embrace change and focus on the customer should be something everyone benefits from. These things shouldn’t be limited to software projects, but perhaps without the bad press other industries don’t feel the same need to change.

Posted in planning, process, Project Management, software development | Tagged | 1 Comment

Why do developers think they know everything?

Ok, so maybe it’s not just developers who think they know everything, but there does seem to be a stronger concentration of ‘know-it-alls’ within our community. You know the person, they are always right and they are unable to see another perspective. What’s more annoying is that they have a terrible habit of telling you that everything would have been perfect if you’d done things their way. They don’t tell you this at the start of a project when such insights would be useful, they wait until it is too late, safe in their perfect imaginary world – hindsight makes everything easy.

Maybe you are that person, maybe in your world everything is black and white, but for the rest of us, there is plenty of grey.

If you are going to preach ‘the one true path’ of software development, you’d better be damn sure your own work is flawless. Any hint of imperfection and you just look stupid.

It seems to me that the best developers know they’re not perfect. They strive to learn, to improve and are humble with it.

Take Jeff Atwood or Eric Sink for example.

Posted in peopleware | Tagged , , | Leave a comment

News

You may have spotted that my domain name has changed. I’m now the proud owner of http://thebiggh.com

I’ve also joined Twitter.  You can follow me by clicking this button:

Follow the_big_gh on Twitter

Posted in Meta, twitter | Tagged , | Leave a comment

Changing Managers

As part of a very successful and growing company it has been interesting to observe and be part of the changes that have taken place.

When I first became Software Development Manager I had responsibility for all aspects of our software – designing, writing, testing, deploying and supporting it. This was ok for a while, but we grew to a point where we had that many installs and customer requests that our deployment team and support team grew to a size that required more direct management. At that point I handed over installation and support responsibility to an Operations Manager so that I could focus on the software development again.

This was the first change of manager and was an uncomfortable time for me. It felt a bit like I had failed, I felt I should have been capable of still managing the software development and operations and that by bringing someone else in it was an indication that I wasn’t good enough. It was hard to watch someone else take over the roles I had been doing, especially when the team responded so well to the change. Everyone was full of fresh enthusiasm and delighted in the small improvements in process and definition of responsibilities. Not only had the board given me a vote of no confidence in bringing someone else in, my old team also seemed pleased to see me gone.

I’ve since got over this feeling, as the job really was too big for one person, and my skills (and passion) are in software development not managing installs and running customer support. After the change, the initial enthusiasm didn’t last and the cracks started to show. It eventually got to the point where the Operations manager was so disliked that his ability to manage was severely compromised.

We’ve recently changed Operations Manager again and again the change seems a good one. The team are enthusiastic and the small changes to process and responsibility seem well received, but will it last? I’ll get to that in a minute, but first let me digress.

One of my favourite websites “The boy from brazil” follows the fortunes of Bradford City football club. As with most football clubs Bradford City have had their share of management changes. Those changes have been debated on BfB with a level of intelligence not seen elsewhere in footballing circles. In particular there have been two significant changes in recent times and the chances of a third are rapidly increasing so the arguments for and against changing managers are again being aired.

The first change came after Bradford City had slumped from a Premier League outfit to a mid-table team in League One. Colin Todd had got the team stable, everyone knew their job and did it effectively, but it was uninspiring (see BfB talking about Managing Failure in relation to Colin Todd). He was working on a shoe-string budget and most people now think he did a good job bringing some stability to a club in turmoil after 2 relegations and 2 administrations. However, as they say “football is a results business” and the results that Colin brought were not seen as good enough and he left the club. The change of manager back-fired and saw the club slip from mid-table safety to relegation at the end of the season. A dire warning to all those who continue to suggest a change of manager is the answer to all footballing problems.

The second significant change happened when club legend Stuart McCall left as manager. The critics had suggested that Stuart was too inexperienced and too close to the club to make the tough choices needed to get us promoted (see BfB describing Stuart’s last match in charge. An experienced and proven manager was needed – such a manager would virtually guarantee promotion with such a large ground and fan base. Many argued that stability is what brings success and that changing managers does no good and can even do harm (Colin Todd being the prime example). However, failing for a second time to gain promotion from the bottom tier of English football was the end of Stuart’s reign and Peter Taylor was brought in as his replacement. Here was a manager with an outstanding CV. He had achieved repeated success with getting teams promoted, but had also reached the heights of England manager. Surely, Peter couldn’t fail?

Well, here we are most of the way through the season and Bradford are again some way adrift of their aims for promotion. It seems that the change of manager has had no effect on the fortunes of the club. We are still struggling in the mid-table, able to win some unexpected games, but inconsistent and losing games we should be winning. (Again I refer you to the excellent BfB website)

Is football management the same as other management? Well some of it is: Can you get the best from your staff? Can you inspire and lead and get the team all pulling in the same direction? Can you balance the needs of yourself and those of your team? Can you identify the weaknesses and address them? Can you make best use of your strengths?

A football manager can change the day to day details of the team – what they do in training (fitness, ball work, set pieces etc), how they talk to each other (calling the players by nicknames or referring to the manager as sir), what they wear on match days (training clothes or suits). A football manager also has a huge influence on who they have to work with – most players can be sold and replacements found. They also choose the 11 players (plus subs) to put in the team, the rest of the players will simply watch and play for the reserves.

As a software manager, you can also tweak the day to day stuff (how projects are run, who runs the projects), you can drive improvements to process, practice and tools (code reviews, documentation, source control etc). Over a longer period, you can influence the hiring process. You are unlikely to be able to “sell” any of your team members, but you can certainly decide whether to put them in the “starting 11” for a project – you can’t leave them with nothing to do, but you can keep them away from the really important projects (they can play for the reserves). If the team expands or people leave, you can identify what sort of person the team needs most to improve (a big man upfront to score goals, a loud midfielder to boss the game, a safe pair of hands in goal etc).

So for Bradford City, changing managers has had no effect. The players in the team have certainly changed, the way they play has changed, the day to day training, the clothing, everything a manager can do has changed, but the results stay the same. So maybe there is a bigger problem at the club that a manager simply cannot solve.

As we saw from the first change of Operations Manager, people and process changed, but the results eventually returned to being “not good enough” and another change was required. Our new Operations Manager is again achieving with new people, better defined roles and responsibilities and the results so far are good. Let’s hope they last, or as with Bradford City, we may be looking at issues outside of what a manager can solve.

Disclaimer: Whilst speculation is rife amongst Bradford City fans as to what the “bigger issue” is, that isn’t the conclusion I’m trying make here. I don’t believe there is a bigger issue at work. If there is anything that would cause a need for change it would be that ambition had over taken reality – a good job was no longer good enough (see Colin Todd as an example). This could be considered outside of the managers influence (although being able to “manage up” is a skill a manager should also have).

Posted in Bradford City Football Club, Football Management, motivation, peopleware, process, recruitment, software development | Tagged , | 1 Comment

Getting Things Done

Getting Things Done

Whilst on holiday last year I did something I haven’t done in a while – I went to a bookshop. It was whilst browsing the various books on offer and noticing how small the computing section had become that I spotted a book I’d heard a bit about – David Allen’s Getting Things Done. I picked up the book, scanned the back cover and flicked through the pages. I was sold, I had to see what all the fuss what about. After all, who doesn’t want a bit of stress free productivity?

I was a little sceptical at first, could this book really deliver the “mind like water” that it promised? However, the more I read of the process and the reasons why it works, the more convinced I became.

I could become a complete addict, an evangelist, it is that good. I’m only just beginning and haven’t really managed to jump in with both feet, but even the small steps I’ve taken have been greatly rewarding.

I’ve signed up to the GTD connect membership with helpful tips via email, forums, videos and podcasts and have just started reading “Making it all work” another David Allen production.

In order to help my own understanding I thought I’d outline my current use of GTD and try to identify the areas I need to improve.

If anyone needs an overview of GTD then I’d recommend looking here and in wikipedia . Of course you could also buy the book and read it yourself.

Three areas of change have really helped me. The first was in processing my email, the second in capturing projects and thirdly in my use of calendar items.

It is true that no-one ever seems to teach you how to organize your email. When I first started work, the paper less office had not been invented yet, so any emails of importance were printed and stored in a folder. My own organization grew from the project / topic kind of filing. Over the years I grew irritated with that approach – how do I file something about multiple topics and a range of projects? I couldn’t find what I was looking for amongst the noise of filing everything. When I read something (I think from Google) about how filing wasn’t needed anymore as search was so good, I instantly stopped filing. My inbox was just a collection of all my emails with no order, but I could at least stop wasting time and mental energy filing every email. Search was pretty good at finding what I needed, but another problem arose – actions. How could I keep track of emails that required responses, emails that required external actions and then a response and ones that had been dealt with. My old system was one of keeping emails unread and flagging emails for actions. This worked ok, but was always prone to missing actions or responses (especially since I also check email on my Blackberry).

GTD has transformed my email processing. I’m actually starting to enjoy the knowledge that I’m on top of everything. I know nothing will slip through the cracks and having an empty inbox is a great little boost to my productivity.

So how did I get from a chaotic inbox to my current basic level. I did a lot of reading on email processing and how other people file their email. The system I settled on was one described by Scott Hanselman. I have 2 big buckets – Reference and Dealt With. If I think I will need to keep the email for a long time I put it into reference, if not then it goes in dealt with. That mental choice is so easy compared to trying to decide the subject to file it under (and having to keep making new subject areas). At some point I will chop the end of the dealt with folder and delete those emails, but until IT complain about disk space or my email client can’t cope I can just keep them.

To give myself a fresh start, instead of processing my whole inbox (several years worth of backlog) I simply dumped it all into an archive folder. I then scanned back a few weeks looking for emails that I might have missed from my previous system and pulled them back into my inbox for processing (I found more than I expected which just confirmed again that my old system was not working).

As I mentioned earlier, I’m only just beginning with GTD, so here’s where I need to do better. Having got my inbox empty I tend to let it fill again with action emails before I bite the bullet and move them out into my actions list (or respond to them). I also have a tendency to use a new email as an interruption and start responding straight away instead of staying focussed on my current task.

Whilst I have email in my inbox I tend not to look at my action list as much. This make me less likely to create actions in the first place – a bit of a catch 22, and one that stops me being as efficient as I think I could be.

Another area of weakness with my emails is in applying the 2 minute rule. Any emails that take more than 2 minutes to deal with should be moved off to my actions list. I tend to either take the extra time to deal with that email when it arrives or later when re-processing the inbox – these should again be added to my actions list.

So what can I do to improve? My first area to tackle is my context lists. I’m not happy with my current set, some are working fine, but the main bulk is simply put into “work” which isn’t fine grained enough. Recent reading has suggested using items like “work timely” and “work sometime”. I think if I had better contexts I’d be happier using them and my email could be processed more smoothly.

The second area of improvement has been in using One-note. I’m fortunate to have a great memory, so haven’t ever needed much help in remembering things, but One-note is much more than that. It allows me to explore ideas and dump items out of my brain that I don’t need to hold in current storage. One-note links in really well with Outlook tasks and emails in Outlook can go the other way into One-note as well.

One-note is my projects list – all the things I have on my mind that are more than single actions. This introduction has again helped me keep track of items and make sure nothing gets forgotten.

My weakness here is my weekly review. I keep being told how important it is, and I agree, but so far it hasn’t become a habit and my projects can get a little stale. I don’t have any regular time at work to shut myself away and perform my review. I need to find or make that time.

Finally, I now make far better use of my calendar. I used to be very passive with my calendar – it had events that other people invited me to, but nothing much of my own. Now, when someone mentions a date I add it to my calendar – an important install, project deadlines, and things that must happen that day. I’ve also started adding items outside work to my calendar – tv that I want to watch and phone calls I need to make.

Again, I think I could do more with my calendar, but as it was the least used area of my work, it is also the least of my concerns at the moment. My days are still a little re-active (one of the drawbacks of being a manager) and I think with better use of my calendar, context lists and actions I could be more pro-active.

So, here are the areas I will be trying to improve:

1. Better contexts for my actions.
2. Processing email into actions instead of holding them in the inbox.
3. Expanding my use of projects to cover different horizons of focus (at the moment I’m very low level covering day to day projects and a little above that, whereas I could also be looking at bigger goals and things like the direction of my career etc.)
4. Refining my use of the calendar.
5. Using GTD more outside of work – the things I need to remember and process are very different, but if it is so good at work, why not use it everywhere?
6. Bring GTD benefits to my workplace – I’m probably not the only one who could benefit from some of the GTD principles of efficient processing.

I’ll post more on my progress with GTD as I discover useful changes or refine my system.

Posted in GTD, time management | Tagged | 3 Comments