focus… Focus…. FOCUS!

Geesh, how hard is it to stay focused!

In a number of employments the focus of a project has always seemed a fine thing, and those that are lacking in focus tend to do worse. I don’t know the reason as to why, but I imagine it is something to do with getting all of your resources to run all over the place and do all sorts of other things without clearly defining or completing a single topic.

This is, to say the least a little chaotic and not good for the employees either, I mean who wants to work in an environment where on a daily basis what you were working on changes so you never finish anything?

It’s good to do lots and to be seen doing lots!

Erm, No; at this point I would really like the noise of a buzzer or some other equally annoying sound. It is true that people like to be seen to be delivering a lot of things, but ask your self this, Are you delivering a lot by doing a lot ?

The answer is probably not, there is no point in doing a lot of things if you can not deliver on any of them, trust me, on this route leads isolation and resentment from the rest of the business, so in short, Don’t do it

I worked in a team about 2 years ago that were controlled by a manager who thought it was a good idea to say yes to everything and occasionally say no, the result of this was that we took on a lot of work that we delivered poorly on and were late on every project. The resulting damage of this was that the reputation of the IT team diminished so far that there was no faith left in them and everyone in the business started seeking their own route to get the solution. This is even worse than simply tarnishing the name of the IT department, it leads on to many unique systems all not integrated and yet the business keeps coming back to IT to get them integrated and you end up with what can only be termed as bespoke crap hooking it all together. Needless to say, this manager did not last too long (thankfully).

It is better to deliver than not

As I touched on above, people do like rapid delivery, but they like it even more if you can continue to do that and that the next time they ask they get the same experience. You can only get that sort of consistency through decent processes and by thinking through the solutions you are doing and accurately time boxing them. If you are not delivering the full solution then you are not delivering, if you did not consider the wider implications when scoping the project, you are not delivering.

Don’t get me wrong this is a balancing act at this point, you have to work out the right way of delivering a project that still enables you to… 1, deliver it and 2, future proof the delivery.

If you only churn out 2 or 3 projects a month, but all of them are on time and on budget it’s better than turning out 5 that are all late. Credibility of the department buys a lot of trust and leeway when needed and by not delivering on what you say will harm this (golden no no)

Focus

Finally after a long winded ramble we are back at where we need to be. Focus. By staying focused on the road map and the committed goals it helps the team and the department continually deliver on the things that are needed, and keep the reputation intact, which is vital.

So the next time a random “wouldn’t this be nice” comes up, think long and hard about if it is needed now, is it worth re-directing resources on to it, and if you do are you still able to deliver what you were committed to? You are in most cases better off planning the work in rather than subverting resources to try and deliver extra.

You need to stay focused on what is already committed before adding in extra work, if you absolutely have to add something in you need to have a strategy for coping, are you going to pay over time to get the work done? slip something else and hurt the reputation of the team? negotiate the delivery of a task slightly later so you can do the new thing?

It’s not bad to have this happen, it’s just bad to keep asking for the work to be done with out thinking about how it is actually going to be delivered.

Summary

Stay focused on what is committed, take on extra tasks after considerable thought and stay focused…

How to get a spaceship

It’s all about aiming High!

I remember a while back I was reading a book about goal setting (I can’t remember which one now) and it was touching on the points of goal setting and achievement of goals. The bottom line for those who can’t be bothered to read on is that you typically will achieve 80% of a goal. I took this and had a bit of a think about it, if you have a goal that is large enough and you actively work towards it you’re going to achieve 80% of it, knowing that is good, aim 20% higher…

I’m not really sure if that will help in the long run but it is a good guideline, I’m not exactly known for my small understated targets and ambitions, part of the reason behind this is the 80% targets. I know that if I achieve 80% of what I set out to do I’m happy with that. What more can you ask for, it’s crazy to think that you’re going to achieve all your goals, so just be happy with 80% but if that means you need to aim 20% higher do that.

I’m not sure of the psychology involved but by having a higher goal you just try harder to get there, I’d suggest this is balanced up with a bit of reality and what is actually achievable, just like the spaceship, a small tiny bit of reality.

So where does the spaceship come into it?

Well this was jus a personal goal I set myself, I simple want a spaceship, nothing flashy just enough to get into orbit; have a bit of zero-G and back again. This all stemmed from a couple of years ago when I was having serious thoughts about setting up a small business which started off as a website but ended up with a spaceship, it’s a weird set of steps to go through to end up with a spaceship.

In my head the business plan was good, but as with these things a bit of planning and a bit of graft reveals that although it could be sustainable and provide an income I could live on it was not the grand scheme I was looking for so, in short I shelved the idea.

However I haven’t lost site of my goal, I have no delusions of grandure, I just want to get 80% of the way there, so maybe a small aeroplane or something similar. That’s what the spaceship is about, it’s about having a goal to stretch for.

This does mean I’m always looking for a big idea to get into to help me get my spaceship, but it is a goal, a goal I’m aiming for, it’s also one I have no real plan for, well other than the South park (contains adult content) school of planning.

I guess this also stands as a marker in the ground for everyone reading, let’s see how close I get to having a spaceship, note I reserve the right to just go out and buy a small plane if needed ;-)

Summary

I could spend a long time here going through different ways to plan things and how to get to the goal but it is kind of all pointless, this whole taks is more about setting expectations and having a positive outlook on what you can achieve. When you aim higher you get further, you need to have passion, drive and commitment to the goal.

By having a slightly higher goal that intended you will find your self getting closer to your original intention.

But I digress, this was about getting a spaceship, well, quite simply, aim for a space station.

Who burnt down the building?

"Fire? What fire?"

Fire!

There comes a time in every Sysadmin’s life where some management bod comes rushing over red faced and out of breath, From my personal experience I highly recommend not replying with “It is working okay for me” That does not get brownie points.

Having learnt from that experience I do highly recommend showing a bit of understanding instead, It is far far better to reply with “Let me look at this right away”. That doesn’t necessarily mean you do need to look at it right away, but if it’s someone in your direct reporting path I’d highly recommend following up on the lip service.

Whether you like it or not, sysadmins are on the front line, it doesn’t matter if you are labelled as “3rd line” or “4th line” you are still on the front line. The buck stops with you, sorry. This also means your customer service skills need to be exceptional, again, sorry. I realise that most sysadmins are technology focused, the latest and the best technology geek-o-rama is all important etc etc yadda yadda *Yawn* For reference that is what the Sales / Marketing guy is doing while you’re explaining the problem that he really doesn’t care about.

At this point you’re wondering what this has to do with fire fighting, absolutely nothing, Wrong!

Welcome to the world of expectation management

So you’ve had the angry management bod, You’ve correctly not told them “it’s all okay” and you didn’t chew their ear off about all that wonderful technology stuff that may be causing the potential issue. At this point there’s a few acceptable ways to mitigate another bigger (and redder) management bod turning up.

    “Let me look at that right now for you”
    “Let me have a quick look and see what the issue is and I’ll give you an update in 5 mins”
    “Thanks for letting us know about this issue, we’ll send out a note to everyone with an update shortly”

Here we have our 3 easy answers to all issues:

1, You know what it is and you know it’s an easy fix, You could ask them to log a ticket (this will annoy them for what it’s worth..) or you can just do it quickly. Even if you have a policy where tickets must be logged, just do the work and log the ticket for them. Once you’ve fixed it you can let them know that the easiest way to get this change done is through the ticketing system.

2, You know what the issue is, It may be 5 mins, it may be 25 mins. At least this way you can get rid of the person standing over your shoulder and focus on fixing the issue. Best case is you fix it in 5 mins walk over (yes, walk over and say you fixed it!) and you have a happy person. Worse case scenario is you spend 5 mins working out what the issue is and walk over (yes, again with the walking over) and you update the person with the ETA, at which point you rush back to your desk and try to fix the issue, shortly followed by… you guessed it, A walk ver to their desk / office to inform them it is now fixed, “Would you mind having a quick test?” Why would you risk it not working! or something else going wrong… Customer service, remember you’re on the front line, if it’s not fixed you’ll just have the same manager or a bigger manager standing at your desk, this, in case you’re struggling to make the connection is “pro-active” shock!, horror! it’s sort of like a management buzz word but it just means you do a good job and get confirmation from the affected person or parties that you did do a good job.

3, Quite frankly, if you’re using this response you’ve got bigger issues with environment. Something catastrophic has gone wrong, emphasise if needed. Your aim here is to re-assure the person raising the issue “Oh, that is not good, I can see how this is affecting your ability to do your job” (I wouldn’t use those words, but you get the idea) Make sure that you escalate this to your boss so they can take care of the management with the business freeing you up to do what you do best, Grab coffee. I was half serious this time, You’re going to be at your desk a while, take 2 mins to sort your self out so you can focus on the issue. Make sure that someone (ideally your boss) is sending out regular updates, in the updates tell people when you will next update them and stick to these time frames; and remember when you start talking about the DNS cache being corrupted on one of the slave caches in the backup data centre affecting the transfer to the internet they are ….*yawning* Do 3 things:

    Summarise in the subject / heading (yes this will not be a direct contact event…)
    Give a one or two sentences at the top of the email with a tiny bit more detail
    Knock your self out and write all that pent-up technological mumbo jumbo you really feel the urge to get on paper for the techno-geeks in the company to read, but please, do it at the bottom so as people become less interested in the technology they can stop reading higher up

Why was that so important?

Well, in short people like being informed, they like being given relevent information and they like it even more when you do what you say you are going to do.
If you can stick to doing those things and ensuring that you try to understand the real issue to the people affected you will be a better sysadmin for it. I realise it’s easy to build up the walls and start blaming other people or to become complacent around outages. If you were thinking, even for one moment “well it was their fault” … Bad sysadmin! really if it is any ones fault it is your fault. Why didn’t your monitoring pick it up? Why were you not able to send out an announcement before you had someone standing at your desk all red faced.

If you ever get anyone at your desk for something more than “How do I do…” something is not right. Try and be self critical and remember that you can not change other people (well you can but it’s much harder than you might think.)

The whole point about managing expectations is that people will start to have trust in you, the department and when you say 5 mins, they know it means 5 mins not 20. If you’re unfortunate enough to be in a position where your IT department already is the lowest of the low and people are always fuming about what you do and that you never deliver, well expectation management will help you out, in a time of crises people typically accept the authoritarian figure’s word so you can use this implied authority as a foot hold into fixing the bigger issue which is trust.

So who did burn down that building?

Well the most important thing here is that it wasn’t you, find some other sucker to pin the blame on, Why build up your reputation to knock it back down again! … Seriously?

Okay the most important thing is to actually not be part of any blame culture, it’s so counter-productive it’s not funny, you end up in a position where people will actively not do work because they won’t take the risk / blame if something goes wrong. If you start hearing someone blaming another department or you hear your self doing it. Stop them, interject, put the record straight. There’s a big difference between saying “Because Bob didn’t ask for the backups to be done we lost the data” and “when we were setting up the database our process wasn’t good enough to catch the fact we had missed the backups” “we missed the backups”, “Our process wasn’t..” key terms, after all even in a team of one it is a team effort between you and the rest of the business.

Obviously if you’re in the meeting and saying that the best continuation of that sentence is “But Ted has now checked the other database servers and we have also updated our process to catch this if it was to happen again”. Hang on, The problem was fixed and you didn’t take any glory, even though you spent an hour explaining to Ted how to even check if there was a back up and you re-wrote the entire process! Correct! If you want to be taken seriously and not destroy trust you’re busy building up in the rest of the business, don’t ever take the glory. People are smart enough to know that you were involved and doing a good job, and by thanking Ted publicly you’ve motivated a colleague and more importantly made your self not look self-centered. Which for those of you struggling… this means you gain more trust from the business as they believe you have brought into the bigger picture, what the company is trying to achieve.

In some case you would have used your best political speech to explain what the problem was and how it was fixed, for some reason people are still not happy. Ideally in this position your manager will speak up and take the blame, if you’re unfortunate to not be in this position, or you are the one that made the mistake, or maybe your colleague did but he is not taking the blame; Don’t be afraid to take some of the blame, “Sorry, I can see now that I should have double checked the backups”

Summary

  • Be nice, have empathy with the users issues and really try to understand how this affects them and their day to day business.
  • Don’t be afraid of talking face to face with people, if you can you should, people like talking to people, and they love talking to people that think they’re special and important.
  • Do what you say you are going to do, no excuses, if you’re struggling to do things in the time frame you set out, check back in and expand the update, explain why it hasn’t happened yet
  • Don’t blame others, Thank those that helped, Take no glory, And if necessary Take the blame

With thanks to: Oldonliner For the fancy image.

Welcome to the 21st century

Today is the Day…

Today is the day I decided to enter the 21st century, I finally decided to sign up to twitter. Obviously being a Sysadmin I’ve heard of this “twitter” milarky for a while but I could never bring myself to sign up. I tend to leave signing up to social networks quite late as typically they are fads, MySpace anyone?

Either way, Twitter has proven it is not going anywhere, not now and not in the immediate future, so I am taking this brave new step into the 21st Century; part of my brave new step is also this blog. For those that don’t know I did use to have a blog but that was back in the days when it was cool to have one where as these days it is more of a necessity, especially if you want to be taken seriously as an authority on a subject. With that in mind, this Blog is formed; my aim is write things that are not as personal but hopefully more useful than my previous blogging attempts.

Does Technology help us

So joining the 21st century as I have was to fix a niggling hole I felt I had in my online presence, I felt the urge to communicate the projects I’m working on and the day to day challenges that are faced in rapidly expanding environments.

As I said earlier I was late to the boat on Twitter, I had a blog, I stopped blogging and now have returned to blogging, I was late to Facebook, I was however very quick on MySpace.

This all got me thinking, so often as a sysadmin you are faced with technical decisions and the balance between stability and innovation.

Which leads nicely onto “How important are your clients?” and “What problem are you actually trying to solve?” a lot of the time a technology decision can be made in the heat of battle or with out considering all of the facts, Our jobs as sysadmins is to make that technology decision that is the best fit for the current problem, not one that may happen at some point.

So “Does Technology help us?” The short answer is no. Technology is not the answer to a problem, it never has been it never will be. Oh my, shock horro, A sysadmin who said technology is not the answer! Correct.

“Why is that?” you may be thinking, well most problems in IT are created by the technology that has come before hand. It is rarely caused by the Client or Customer asking for more features, and even when the request comes from Clients or Customers they often are not asking for a largely complex solution, lets examine this a little bit.

So your Client has asked for… “I’d like to have my website available in multiple countries”
For anyone that thought…”Oh host a server in which ever country, bingo” Bad Sysadmin! It is a website, it already is available in multiple countries. Our job is to work out what the client means when they ask these questions, depending on the answers the solution should be derrived. Did they just want a .de domain name pointing to the site and a German site presented? Did they want extra resilience?

Even if the client comes back with “I’d really like more resilience around my web server” we need to think about the why they would ask that, has the site been unstable lately? Are they expanding? Are they getting slow load times in the USA?

Our job is to ask questions and to provide the simplest solution to that problem. It may just be that we need to implement some monitoring as a first step or a better back up strategy.

Granted not every solution will be simple, you may need to set up some geo load balancing multi-site international data centre, or simply copy the site to another box in another country. Either way, start of simple, add complexity as needed.

Summary

I guess the point I’m getting too is don’t create a solution because you want to play with some new technology, don’t come up with a solution with out working out what the real point of the question was.

Adding in technology complicates a solution, so you should only add it in if it fixes a problem. In larger environments where you are supporting hundreds of servers you may need tools like Puppet, Chef, OpsView etc etc but in smaller environments you do not always need them.

The only exception to this is if you think there will be a need for it in the medium term, if you are rolling out a new solution that requires multiple environments and potentially will grow rapidly, then adding in these tools is a good start, but please start them out as simple as possible, you have all the time in the world to improve upon them later, don’t get caught up in technology for technologies sake, think simplicity, agility and rapid deployment.