Here is a quick tip from HBR titled 'Take Back 10 Minutes'. It is short and sweet, quite simply change your standard meeting time from 1 hour to 50 minutes. This is very much inline with some of the ideas I mention in the Post 'Too many meetings'. Here are a few of the tips:
1. Don't Blindly Accept - Make a judgement call if you should attend, delegate or decline.
2. If there is no agenda - Restrict the meeting to 30 minutes.
3. State the purpose and approach upfront
4. If the delegate is not taking notes their not going to take action.
Recently I've been listening to Seth Godin'sTribes: We Need You to Lead Us (for the second time). Amazingly I bought the book as well. Both good in their own right, although the audible version is abridged so only takes a couple of hours to get through. It is listening to Seth that has motivated me to tackle this post about the concept of 'Mandates' that has been on my list for a while now.
Mandates! Managers need them, Leaders don't. I have arrived at this perspective after years of comments like 'I don't have the mandate', 'If only the boss would mandate it', 'You don't have the mandate' and so on and so on. I'm not sure if this particular dilemma is a trait of Big Corporation's, although this is where I have seen it most often.
All of these comments have whirled around my group and I as we have plowed on and made a difference. In the way we work, how we are structured ourselves and the fund we were having in making a difference. To us waiting for a mandate is like walking through a Morass, it is really hard work, slowing you down, if not stopping you entirely.
Even if the above sentiments are real. I challenge you to be brave, ignore them, look at your job description or the activity you are driving and be quite literal. For example if your title is 'Head of Technology' then head the technology, head it in the right direction, head off the challenges and problems.
This is particularly pertinent when you are trying to change an IT Organisation. Chances are the senior executive don't fully understand technology, or if they do they are so busy trying to manage the broader scope of running a large Business Unit or organisation that they do not have the time to address it directly, and infact are assuming this is what you are doing.
Therefore you need to lead. In reality the only form of mandate you should be obtaining is funding approval and guidance. Even when it comes to having your leaders stand in front of the masses and re-iterate your message, chances are you will have a big role to play in defining the message, in fact even writing it.
I often tell people working with me it is easier to ask for forgiveness than permission (obviously there is a caveat to this - as long as you are ethical and within the law). It's great when they quote it back to me sometime later, as challenging to me as this can be, it is an indicator that they are leading and making a difference.
So get stuck in, be brave and have some fun, lead. If I haven't convinced you and you are going to sit and wait for the mandate from on high, could I at least encourage you to read or listen to Tribes: We Need You to Lead Us
Diagram's are central to an I.T. professionals career, be they Process flows, system diagram's, Ishikawa, causal loop etc. Interestingly as you get more experience you will become more and more reliant upon diagrams as a communication tool. In particular the informal ones.
With that in mind it pays to educate and familiarise yourself with the most pragmatic and easy to recall approaches that are out there. At the end of the day though people will argue that you really don't need formal training of any sort simply a piece of pen and paper.
So why would you need a formal approach to diagraming. The rationale behind this would be that using a structured approach to Diagram's in a collaborative session can harness the ideas and energy within a room.
For example having someone try to draw a process flow, whilst another is considering a systems thinking approach, while a third person doesn't understand either of these approaches will result in a lot of confusion beyond the normal challenges of terminology and jargon.
Before we define the life of a diagram and make some reading recommendations the key principle of diagrams needs to be stated. Quite simply diagrams are used to improve understanding and advance ideas. Interestingly people fly in the face of this principle all the time, two examples:
The first example is that of the overly complex or elaborate diagram. Interestingly I see a lot of these diagram's originate from some very smart individuals (i.e. see Zealots & Cowboys). Although they recognise the benefits of using diagram's they endeavour to interpret their thinking straight into a digital form (normally Power Point) and then cast this out onto their audience.
A second example I often see is the diagram that has achieved the goal of understanding quite quickly. The ideas are embraced and people move beyond the original diagram. Often because of the originator's attachment the diagram keeps appearing.
Both of these examples and many more resulted in the concept of the 'Life of a Diagram'. The first example can be addressed by the early stages of the lifecycle outlined below, whilst the second example is a problem that comes in at the tail end of a diagram's life. The life of a diagram concept/approach is as follows:
1. Scribble and talk, as you work through identifying the problem, opportunity or defining an approach to be taken, socialise it with your peers and co-contributors. test the diagram, get input, and then test it by talking and scribbling some more with another peer or contributor.
2. Go analog before digital, like many creative things, writing, presentations, concepts etc.. it often pays to work with good old pen and paper before you go and get digital. Doing this will allow you to further test the diagram as well as improve your understanding and interpretation.
A by-product of this approach is that you will become very proficient in drawing and articulating the diagram. Enabling you to draw it anywhere - on blackboards, whiteboards, napkins, tablecloth's etc. Something that may be pivotal in the case of a stakeholder encounter over a coffee.
3. Go Digital - when you want to communicate your diagram to a greater audience or in a formal construct such as presentations and whitepapers. Remember the KISS Principle (Keep IT Simple and Sweet). The rational for step 1 and 2 above is that starting analog keeps it simple due to time pressure and effort it takes to draw.
4. Seek feedback and suggestions for improvement, this has a number of benefits, one significant benefit is that as more and more people contribute to the concept you are presenting the more and more supporters and evangelists you have in achieving your goals.
5. Recognised when the diagram has done it's job. Retire it to your reference library for future use. Interestingly if you have followed step 1 & 2 above you're fine diagram will always be at hand (literally) if and when you need it for future conversations.
As an example to the output of this approach have a look at both the 'Process Approach' and STO Model represented on this site. Also look at other peoples diagram's, even better participate and contribute to the evolution of these diagram's.
Both books, although approaching the idea of diagrams from slightly different perspectives provide some great insights and ideas on using this extremely powerful medium to good effect. They do both emphasise the principle diagrams are used to improve understanding and advance ideas.
3 Weeks in and I miss the weekly goal!!! Wow what sort of commitment is that.
Big week this week, I've incorporated a company called 'Endurance IT', turned 39, picked up some new toys - in particular a 13" Mac Book Pro, and met with one of my first clients, with the intent of commencing work next week.
In addition to that I've just been down investigating the Antarctica trip - look like this will occur in early December. I am now taking moment to sit in a pub and create this post by way of penance for missing the Sunday deadline.
Over the coming weeks and months you will see a shift away from 5Why's and towards Endurance IT. I will shift some of the content from this site across, question is how much and in particular what.
In the meantime I will endeavour to get back onto the weekly post bandwagon. Please bear with me as I start to make these career/lifestyle changes. Coming up shortly 'Life of a Diagram' due out Sunday.
Keeping in line with the goal of a weekly post, I thought I'd take a direct approach this week. As suggested by Darren Rowse in his 31 Days to build a better blog (or was it one of his recent posts that gave me this idea), I am going to bring forward a number of key posts I have done over the last couple of years that may be of interest to you.
So here are 10 of the best in order of oldest to Newest:
1. Create and Communicate Direction - One of the handiest techniques I have come across. People who have worked with me in the past get sick of me asking 'Have you run this through CCD'
2. The Process Approach - This is an exceptionally useful tool when looking at improving or introducing new process. It keeps things nice and simple. Going analog on this can cause weeks if not months of continuous improvement
3. InBox Zero - This is more links to a really handy Site. Merlin Mann of 43 Folders provides great insights on sorting out your inbox. Something very handy when you are receiving 100+ e-mails a day. (Note - this fellow inspired number 5 on this list)
4. 5 Questions in 30 Minutes - Running a large team, or inherited one. How do you get to know your people as well as get some really valuable insights on what needs to be done. 5 Questions in 30 minutes was an approach I used to achieve just this.
5. e-mail Insanity!! - Unbelievably I still see this on a regular basis. In fact I'm probably suffering it a little myself due to the recent acquisition of an iPhone. This is something you should seriously consider.
6. The First Strategic Principle - One of the best!! Awfully simple to understand and draw with massive impact to any organisation design or strategic conversation you may be having. Feedback on this principle continues to be quite positive.
7. The GOOD, the BAD and the UGLY - Great approach to getting some feedback. I've even tested it's scalability by running it as a feedback mechanism for a group of 100 people.
8. To Many Meetings! - Add this to the InBox Zero and e-mail insanity perspectives above and maybe you can start to claw back some thinking time.
9. Elephant Spotting - An innovative way of seeking feedback from a large group of employees.
And a long break it was. My last post (below) was pretty much two months ago. Fairly slack of me, although I will admit some significant changes have occurred (more on that later). for now though I am going to announce a personal challenge, which I hope you will all benefit from at some point or simply appreciate.
The Challenge:
For the remainder of this year (Approximately 46 weeks) I am going to endeavour to publish a post once a week.
This is in no way a new concept or idea, it is something I came across a couple of years ago courtesy of Mr Merlin Mann (of 43Folders fame) and Jonathan Coulton. In short Merlin either interviewed Jonathan Coulton or discussed a challenge Jonathan and independent musician had given himself, and that was quite simply produce 'a thing a week'.
Theoretically this should be fairly straight forward - I've a backlog of at least 36 ideas to write about and more being noted all the time. In addition to this I am presenting at two conferences over the next couple of months (PACRIM IT Service Management and IT Showcase Asia) and feel these presentations should be underpinned by supportive articles.
Other challenges of course is juggling work and kids, throw in a trip to Malaysia and Antarctica and this is shaping up to be a pretty interesting challenge.
Your part in this, quite simply provide some comments/feedback on what I am posting, if I'm slacking off let me know. My intent would be to make a post by Sunday of every week.
Over the years I have come across lots of advice or inspiration around the concept of 'Fun' or play at work. These messages have been delivered through many forms. Everything from fellow bloggers, articles from Harvard Business Review, management training and Most recently a TED talk.
This particular ted talk was by Tim Brown CEO of IDEO. IDEO are exponents of the concept "Serious Play". I've included it here for your reference. The talk runs for approximately 27 Minutes.
This idea of PLAY has always appealed to me. An interesting perspective I have is that when I have actually achieved this it has not really been done with the concept of 'fun' at the forefront of my mind. This has been a By-product of the activity/task at hand. With that in mind here are three examples and a simple suggestion to get you started down this path.
NOTE - Fun at work should be the default state.
Stories at work
A lot of the teams I manage are involved with the process of making things work or happen. That is Service or Project management. When I first get involved I often find the groups are challenged by issues of ambiguity. Ambiguity in their roles, ambiguous actions that they take relative to others, ambiguity around their right to make decisions etc.
It is because of this environment that the group is often struggling to be objective. The concept of 'Accountability' and interdependence often alludes them. I have found on two occasions that I have a great method for addressing this particular challenge. In short I take them out of their comfort zone and tell them the 'Story' of My life as a submariner.
The benefit of this is that it is a fully immersive story (literally). Taking a team through this environment and being able to provide stories of first hand experience, I am able to articulate the concept of clarity in an environment where ambiguity can get you killed. It allows me to provide examples of clear process, clear communications, and team work.
Although a relatively extreme example of Story telling it has proven to be very effective.
Games at work
Games are a particularly under-utilised tool. I have used games on a number of occasions to great affect. One particular game that comes to mind is that of the Simpson's Game (Pictured) that I had created a few years ago, and have used with a number of teams since.
The beauty of this particular game is that it provided benefit from inception through to execution. I had inherited a demoralised disempowered team, which needed to be reinvigorated on all fronts (people, process and technology). I could not afford the $30k plus price tag to educate the team in ITIL concepts so we did this ourselves.
From the word Go we started to make an difference. Locking one or two creatives away in a room, having them carry big pieces of cardboard in with great fanfare, colouring pencils, colored cardboard etc. was a master stroke - the anticipation this generated was impressive. The team was learning to appreciate the adage 'Under new Management'.
Second to this letting the team come up with the 'Theme' proved to be invaluable. Out of this the Simpson's game was born. We then had team members buying Simpson's characters from their local supermarkets through to bidding for Simpson's cars on eBay. The creation of the game rules themselves provided a challenge for a different part of the team.
By the time we actually got together to play the game the team was keene to see what they had created, and the fundamentals we were trying to learn were easily understood. Three years later this particular game is still in use - although looking a little tired.
Play at work
The idea of banter and fun at work is often a challenge, especially if you're running a lead team of senior managers who spend 99% of their time on task, that is focusing on managing teams and activities to achieve outcomes, dealing with exceptions etc. Often a leadership team will find that they do not get enough time together to make sure things are running smoothly.
Traditionally this predicament is either addressed by extending the existing formal meeting by an hour, or simply having two of them. Interestingly this particular format is not overly conducive to addressing the actual need. Traditionally meetings can only handle 2 - 3 topics in a given hour, doubling the meeting time does not necessarily mean doubling the output.
My most recent team recognised this particular issue, and we started to try and work out how we can address the problem. In reality the team wanted more time together, whilst I really wanted a team - one that works well together. Enter the concept of the Mop-up.
This particular approach was influenced by the TMZ.COM team (tongue-in-cheek), agile methodologies, in particular scrum. We threw in some wine, cheese, crackers and an electronic egg timer.
As the mop-up matured we found ourselves having quite a good laugh whilst being able to discuss and address a number of issues/opportunities within the team, ranging from making sure each other understood our interdependencies through to discussing team members performance, as well as identifying actions to be taken in the coming week.
This particular approach really turned the group into a an efficient team. The philosophy here is that teams are not built on away days or off-site events, they evolve on a daily/weekly basis. The mop-up provided and enjoyable bookend to the week and allowed the leadership team to check-in on how things were going.
The above examples are simply some of the games and stories I have used in the workplace over the last couple of years. They are not overly complex, and as you can see by the quality of the game and video above it can result in considerable discretionary effort from your team. Something all managers should aspire to.
One last example and a take-away that you could apply immediately is the ide of the Photo collage. Have you team members bring a photo of themselves, a landscape from their travels or their hobby. Stick them on the wall and have the team guess what picture belongs to which team member. A simple idea, that can generate a lot of interest and good will within your team.
Have a play - you could only improve your environment.
Sometime ago I wrote two posts for the Alinement Network. As I mentioned in one of my recent posts titled 'Alinement Network - Missing in action' these guys were hacked last month. Louis has recently e-mailed me letting me know the two articles are up and running again. So with that in mind I thought I would provide you with a link to the two articles.
The first of the two articles 'Zealots and Cowboys' endeavours to explain two common blunders made by people trying to implement a program of change that revolves around a best practice such as ITIL or Six Sigma.
The second article 'Pragmatic Management' builds upon the story of the zealots and cowboys by providing you some pragmatic advice on how to avoid these common mistakes.
I stumbled across this idea by accident earlier this year. It was the eve of my inaugural presentation to the group that I had just commenced managing. I'd been observing/learning the lay of the land for approximately six weeks and now had to explain myself to 60+ people.
By explain, I basically had to let them know who I was, why I could lead them, what my lead team and I had decided to do and how we were going to do it. Really quite a bit of content to deliver. To add to the fun the I.T. group within the company I work for was also going through a major restructure announcement.
So here we were, myself and a communications consultant working through the CCD approach for the up coming presentation. When the consultant started discussing feedback channels. It is at this time that we came up with the idea of the 'Elephant'. How? Why? What? You may ask.
The inspiration was a draft presentation I was working on called 'Drawing the Elephant'. It was this pre-occupation with the proverb of the 'Elephant in the room' that caused me to suggest. "Why don't we simply tell the group that if they want to get in touch with me directly to send me an e-mail with 'Elephant' in the subject line."
On the day we did embellish this a little, firstly we added in a Service Level/Guarantee. I committed to the group that I would respond personally within 24 hours. We re-iterated this message a number of times throughout the presentation as well as ensured it was the full stop to all group meetings into the future.
Honestly this is one of the best ideas/initiatives we put in place over this last assignment. Risky as it may sound I have received numerous 'Elephants' all of them very valid concerns or comments from the team. Please note they have not been complaints, or condemnations. The majority have respected the idea by being both objective and constructive when articulating the elephant.
As recently as today I have received two 'Elephants' both of which are to be addressed tomorrow morning. Addressing the elephants is not simply a reply to an e-mail, although an e-mail acknowledgement is a must you should not restrict yourself to this when you actually address the elephant in question.
Methods of addressing the elephant include:
1. Escalation of issues to senior or peer managers
2. Engagement and delegation to direct reports and the individuals line manager
3. Meetings to further understand or address the issue
4. Public acknowledgement and discussion (Without disclosing the elephants instigator)
So if you want to go elephant spotting - why don't you simply follow these three simple steps:
1. Identify a term or saying your group can associate with (use 'Elephant' if you like)
2. Set a response time guarantee that you can achieve, and commit to it.
3. Get stuck in and make this part of your groups practices.
Note this is a bit of a derivative of an earlier post I wrote '5 Questions in 30 Minutes'. The challenge on this occasion though is that 5Q approach would not work on a team of this scale.
I'd love to hear what you think of this idea, especially if you implement it.
I've bought '31 Days to build a better blog' from Darren Rowse of Problogger fame and am slowly working my way through this. I'm not quite following the 31 day principle but am somewhat along the way.
That is I am up to day 5 in the program, and this post is actually representative of the day 2 task 'Write a list post'. On this occasion I have opted to provide you with 5 Blogs/websites I have found to be quite useful in my day job as an IT Manager.
2. http://www.manager-tools.com/ - I take this particular website so seriously I am actually a paid subscriber. The site provides a weekly podcast focused on helping you become a more effective leader. Paying actually gives you show notes, templates and presentations that accompany the podcasts
3. http://www.43folders.com/ - This is Merlin Mann's site dedicated to helping people find the time to get things done. Merlin is a little out there at times, the site does have some great content on creativity and productivity. Note it is a little neglected at this time as Merlin is concentrating on writing a book.
4. http://www.joelonsoftware.com/ - Joel Spolsky is one of the cofounders of Fog Creek Software, he writes on a range of topics from software development through to business and management articles. He does provide some interesting perspectives for the development managers amongst us.
(for the second time). Amazingly I bought the book as well. Both good in their own right, although the 
. 
. Well worth the read, Garr regularly provides great advice, tips and examples.
' and '