April 17, 2016

#AndyTalks 034 – It’s all about processes

When I was in IT I spent a lot of my time putting out fires.

I only got ahead by documenting, automating, and delegating processes.

In this video I show a checklist I’ve created for the beginnings of my video marketing process, and talk about the importance and lifecycle of processes.

TRANSCRIPTION

Saturday morning. My kids are playing Minecraft or watching Kiddies YouTube. I need to get a haircut because all the greys are showing. I’ve been a bit geeky before we go and have breakfast.

There’s an AndyTalks video marketing project in Basecamp. I’ve created a Google doc. I link to it in here. So I’ve listed all my videos, the video description, the URL, the time — well I haven’t put all the details. I’ve got the date that the transcription’s created, captions created, captions uploaded to YouTube, subtitles added into the video, whether I’ve paid somebody, blog post created, posted to Twitter, posted to Facebook, posted to Linkedin etc. I’ll make it up as I go along. I’ve called this my “Andy Talks Video Marketing Checklist” and this is me getting organized.

The first 31 days of videos was just me trying to get into a daily habit, which I’ve done now. Now that’s going, I’m going I’m going into Phase 2, which is getting more organised and getting streamlined and then starting to outsource. Obviously it’s taken me time, which costs money really at the end of the day, to do all this and I’m going to start paying people as well. Which is all good, because sometimes you can put time into something and not think it’s money. But when you’re paying €10 a video to get it up, transcribed, captioned and whatever and you’re doing one a day, then the cost is going to start racking up and you’d better get an ROI on it. So, now I’ve got to start thinking how can I make return on the work I’m doing and the money I’m forking out.

Obviously I’ve thought about this already before but now I’m going to have to get into detail. Obviously I wouldn’t go down this route if I didn’t think there was some benefit for my business. Of course now that I’m going down this route I realize that I’m doing this sort of vlogging for the benefit of these guys here when they get a bit older.

Right lads. Breakfast?

Kids: Yeah.

[laughs] That wasn’t that enthusiastic. Minecraft is currently winning.

Wow, that’s a big old house being built there isn’t it? Not so sure about it being below the level of the canal. But I guess the canal isn’t going to flood is it. They’ve got all the locks further up, better than being below the level of a river.

I wanted to talk about processes a little bit this morning. Back in the day when I was an IT contractor, a database administrator, I was a production DBA, meant I looked after live systems. I’d be brought in to keep systems running and often there would be fires that I’d have to fight. A system might fall over or space would fill up or something would go wrong.

My first few weeks — maybe even months — I spent doing a lot of fire fighting. When you spend all your time fire fighting it’s very hard to get ahead. I noticed some fires kept coming up in the same place. So once I’d worked out how to solve it or put that fire out, next time that fire started I’d be able to put it out quicker because I knew I’d already done it. Once I’d done it a couple of times, maybe three times. I’d start writing my notes up on how to put this particular fire out.

Actually, back-tracking a little bit, because I’m managing production systems — live systems — even before a process starts forming and I start documenting it. I would be logging all the changes that I’d be making in a hard bound book that I was using every day. I’d start the day putting the date and time and if a particular problem popped up I’d make a note of the time in the left-hand margin, what the problem was and who gave it to me and I’d start work on what was called an “incident.” Maybe that client would have an incident management system where — like a core handling system — where an incident was raised and assigned to people. If not, I’d create a little spreadsheet or something and make a note of a date and time what was being done, why it was being done, who was doing it. All the Ws — What, Why, Who, When. Maybe Where.

I actually call this the four Ts. First step is to ensure that there’s visibility of what’s been done and why and who by etc. The next step is to log in detail all the actions taken and the results or the steps, I call this T the traceability . . . go through all the details . . . how you did it. Once we have a detailed log like that which gives traceability, you often have repeatability, somebody else can go through, follow the steps you took to get the same results. The final T would be accountability. If you knew who did what and when and the results and all the steps and could see what they did, then you have accountability.

The four Ts. First T is visibility, what’s been done, why, by who and when. Second T is traceability of how it was done. Do that well enough and then you have repeatability. Then finally, you’ve got accountability of you know if you want to go on witch hunts or whatever.

My job was actually to put out the fires, start documenting so that other people could then do it, do root cause analysis to find the underlying problem that was causing these incidents, means going from MacGyver hat to Sherlock Holmes hat. Finally handing over to help desk or automating them because that was part of my skill set. I used to train other people in process improvement as well.

In my mind a process can go through six stages. First off it’s just ad hoc; you’ve never done it before, it’s an ad hoc process. A few times you define it as a process; it’s a process you haven’t documented yet. You could put it on your list of processes that you need to document.

Pick the most important of these processes and document how to do it so someone else can do it. In my years of documenting processes I’ve never ever had one process that I’ve been able to give to somebody and for them to repeat it in one go. To make sure a process is repeatable you’ve got to give it to somebody else to step through and see if they can get the same results as you do. Like I say, they’re going to come back with questions and things that you’re going to have to add to the document to make sure it’s clear for other people to follow. Take an ad hoc process; you define it as being a process that your team needs to do; you document it and then you give it to someone else to make it repeatable. Once it’s a repeatable process, it could be automated. Not all processes can be automated. After a process has been automated as much as possible, you can then optimize it.

What’s up buddy?

[kids singing]

I don’t think I did that good a job explaining the four T’s and the stages in a process life cycle very well. It’s really important stuff though, so I’ll go through it some other time and try and get it really condensed. Maybe I won’t bore you on Snapchat with it; I’ll do a video.

Anyway what do you think of the barnet? You can’t see any greys now can you? It took him a while but he managed to cut all the greys out.