Getting motivated

June 8, 2012 / / No Comments

Are you motivated?

I remember reading an article a few months back from HBR and it was very insightful, and I highly recommend reading it before continuing… It certainly struck an accord with me, as I think I’m very motivated. However I hate finishing things off, the closer I get to completing the less interest I typically have. This isn’t a bad, but it is something I need to be aware of, I certainly wouldn’t be any good at following a set process day in and day out or finishing things off perfectly, but I am very good at getting 90% of the way there and getting it up and working in a sensible way.

If you’ve heard of Belbin he came up with some tests that identified the roles within a team and predicted that teams made up with a mix of roles functioned better than those with predominant roles. If you imagine a team where everyone wants to be in charge you can already work out they’ll spend more time bickering than actually getting the task done. I imagine that based on my results (Co-ordinate, with secondaries of plant & teamwork) is why I prefer to be making the decisions rather than finishing off the work, which back to the motivation element is probably why I also don’t like completing things, there’s a lack of decisions to be made towards the end.

So I am motivated, but I find it a real struggle to finish things off, sometimes it just has to be done and I will typically work from home or put my headphones in and just get on with it. That is how I deal with motivating myself to finish tasks, but what do you do if you aren’t motivated to start?

Getting motivated

I believe that to be motivated about something you need to have a few things, you need to be part of the process, making some of the decisions or feeling that your input is valued. You also need to want it to succeed, this is the difficult one to achieve, if you’re part of a team and you don’t think it’s the right thing to do and you don’t really want it to succeed then that will bring down the rest of the team, as well as frustrating you and making you more unmotivated.

You have to take some responsibility for changing your perspective on a project or a task, sure your manager could identify that you are not too keen on it and they could throw some rewards your way to help with the motivation, but ultimately you need to want to make yourself motivated and communicate what is stopping you be motivated.

When I am in a situation where I’m struggling to get motivated about it I tend to look at why we are doing it, in most cases it is to get us to our end goal on the road map at which point, even if I disagree with the task I remember it’s an iterative process and we are always iterating towards the goal, that is all it normally takes for me to get back to being motivated. I am not suggesting that will work for you, but you should have a look and a think and see why you are not being motivated and then come to terms with it. For me it is always abut getting to the end goal, as long as we’re doing that I’m happy, I use to struggle more with it in the past, always wanting the perfect solution, but after time I realised that is not really feasible so I came to terms with accepting little victories that are towards the goal rather than the end goal in one step.

Summary

As nice as it is to blame everyone else for you not being motivated to do something, you have to take some responsibility to get motivated. There’s only so much your boss will be able to do, they may throw money at you which might well help in the short term but it won’t in the long term. So look at yourself and why you are not motivated and try to work out what you need to do to get yourself motivated about the task in hand.

Siliconmilkroundabout

June 1, 2012 / / No Comments

What a Day!

For those that don’t know Silicon Milk Roundabout (SMR for short) is a recruitment fair held in London for tech start-ups started by a company called Songkick who were facing a struggle like a lot of tech start-ups, How do you get good, talented and motivated people interested in working for start-ups.

Well it works, this is the third event and it has grown from strength to strength each event has doubled in size which is pretty amazing in its self.

I went on the Sunday with Alfresco to help fill some Java developer rolls we have and to get details of people interested in working with us when we have rolls available, I think giving away a free iPad 3 helped get some details.

Was it hard work?

You bet!, there was a lot of people to talk to and so many people seemed really interested in the culture Alfresco has and how they reward their staff and it was good for us to meet people that were engaged and passionate about their area of expertise. I personally think that if you’re passionate about what you do, you never really work, and if you’re not passionate you shouldn’t be doing it, do something better with your time… Luckily all employers want passionate employees that are willing to go that extra mile, and where better to find them than in a building with no air-con on a scorching May day at 26 Degrees celsius on a Sunday; I mean they have to be passionate to still want to go to recruitment fair when the weather is perfect out side, and it looks like to me there was as many people as the time before especially on the day I was at.

There was a certain amount of prep work we decided to take upon ourselves for the event; some of it was worth while, some of it not so much, but that in its self was invaluable, it had to be done, we didn’t want to be a company standing there with no branding or anything to sell what it was that we were about. Other companies took a lightweight approach some had much more elaborate stands involving rigging for lights, one even had a juggler.

I would recommend that anyone spends a little time working out how they wish to come across and then learn from their experiences, for example, we now know taking chocolates on a hot day is not a smart idea.

Was it worth while?

It’s early days to say for sure wether or not it worked out for us from a recruitment point of view but regardless of us filling any roles, we got the details of a lot of people that were passionate and interested which we can hopefully pull on for future vacancies to save us relying on recruiters and LinkedIn.

The other benefit, outside of recruiting is that I’m sure it helped raise the profile of Alfresco, which should have more of a “Buzz” about it, even I learnt new and interesting facts, most importantly it is the 2nd largest open source company in the world. Thats something we should be bragging about a bit more than we are.

Summary

It was a good day, a long day and definitely a worth while day; one which I hope to do again soon anyway.

focus… Focus…. FOCUS!

May 25, 2012 / / No Comments

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…

Valuable vs Rapid change

May 18, 2012 / / 1 Comment

Change, Change, Change, All Change!

For those of you in IT where a change seems a rare and wonderful thing, this post is probably not for you, if you are implementing less than a change a week, this post is not for you…

So where I am, we make in some cases several changes a day through our various systems, all in a bid to keep away the Big Bang of changes (also known as the Service disrupter), quite simply, our ethos is many small releases so the change pattern looks like a saw tooth not a set of steps.

Just like this:

Courtesy of Its Tech up north

see those tiny little releases, that’s the aim, the right hand side of the picture is when it all goes wrong.

So, back to the topic, lots of changes all the time, And at this point you may think I’m going to deviate into discussing the merits of quick releases and longer releases, as per the graphic. Well you’d be wrong, you should all be doing the left side of the graphic.

What’s a Valuable change?

It is all too easy to fall into the trap of Agile = Quick therefore make many changes and use all those rapid changes later to fix things up again. This is not right. This is not to say that you shouldn’t make a change rapidly if it fixes a service affecting issue… i.e. reconfiguring apache; however this is to say that you shouldn’t release half arsed.

So a valuable change is a well thought out change that adds benefit, it is in line with the road map and well tested. There is no time limit on a valuable change, you could spend months working on it, you could spend minuets. The key is as above, it’s on the road map, it’s well tested and it adds benefit, if any of these three things are not in alignment you probably have a rapid change; sorry for your service loss.

A Rapid change!

They are cool, they are quick, everyone thinks they are amazing because of how quickly they made it into the product / the service and they are by far the most pointless changes you’ll ever have to make.

Sometimes you will need to make rapid changes, i.e. one of your nodes in the cluster isn’t working so you need to make a change to remove it. This is not in line with the road map, it is not even a sensible change in the bigger picture, but it is absolutely necessary in the short term.

So rapid changes are fine to fix service affecting issues, you have to keep the service running, no excuses.

Rapid changes are ugly, often poorly documented, thought out and designed. So they should not be a method for implementing changes for the long term, i.e. a new way of logging in, a new graphic, a new way of balancing traffic etc etc

Rapid changes always produce Technical Debt where as valuable changes do not. So the sure fire way to identify a rapid change is by the fact it has technical debt.

Slightly off topic, I wonder if it’s worth graphing the tickets that produce technical debt and link those back to the change that produced it, you would then be able to show how much effort was created by a rapid change and categorically prove how bad it was to do and therefore discourage then in the future…

Summary

You will always have some element of rapid change, the aim is to make the number of rapid changes as small as possible, as stated they aways produce technical debt and that is really bad for you, really bad. Where possible even in a crises you should try to come up with solutions that are valuable and do not produce technical debt.

This should always be your aim, for the sake of another couple of mins of thinking about a solution, do it, it may save you a lot of technical debt and reduce the pain of supporting a system that is not as ideal as it should be.

Universal trouble shooting

May 11, 2012 / / No Comments

Simples!

Recently I’ve been going through some “interesting” times with my lower back; it all started several months back (October, 2011) and it was only about a month back when someone started to do tests, actual tests that would prove or disprove the situation. To be honest it’s a little frustrating being in a position where trouble shooting is my job. I’m very use to working with and understanding many different technologies, personal experience and gut feel for what is the root cause of an issue might be, but it struck me as a little odd how physiotherapists took roughly the same approach, but before proving what the problem was they would try a cure.

That is kind of like saying, “I can see you can’t connect to the internet so I’m going to call your provider and make sure you bill is up to date” very strange, this approach to trouble shooting is something I’m going to term “Following the light”

Following the light

What do I mean by following the light? If you’ve ever had a cat and a torch you probably have a picture of what I’m thinking, else have a look at this.

You’ve seen a small hint of something that could possibly be the cause of the problem, and in your finite wisdom you have decided to follow the first credible route until it is proven to not be true, at which point the next credible route will be followed. Great, eventually you will solve the problem, by which point the service will be turned off or if you had my Physiotherapists’ I’d be dead.

This is not to say that the first thing you stumble upon can not be the cause of the issue, it can, but you’re now trying to solve a problem to something that may not actually be a problem.

This isn’t a bad way to problem solve, it just takes for ever, so there’s a another way which when everything goes well is by far the quickest problem solving technique, “Scatter gun”

Scatter gun

Okay, another weird phrase, Imagine someone trying to hit a bank note with a gun from 20 paces away, a good shot would hit it right away, every time, a average shot (where most people are with problem solving) misses 9 out of 10 times, so they would be better off with a shot gun, it’s the only way they’ll hit the target every time. Unfortunately the rest of the shot misses.

With this approach you dive into a problem, get the first 2 mins into the problem description and you already have the problem sorted, except you stopped listening 2 mins into a 5 min problem description; take the following example.

The last time I went to my favourite website it asked me to change my password, so I did, I definitely changed it to meet the security requirements, and I continued to browse around, it worked fine for a a week or two and then when it prompted me for the password again it wouldn’t accept the new one. Any idea what the problem is now ? seems pretty clear, Error 18 (the error is 18″ away from the computer), PEBKAC, PICNIK what ever you want to call your generic user error, continue reading…
Just by chance I tried my old password and it worked fine. What I don’t understand is why would they ask me to change my password and then forget to save it? seems odd, but either way I can log in again now. Cool, so by doing the scatter gun approach you just missed a security breech, Nice one ;)

To be honest that could happen to anyone, but the scatter approach of try this, try that, try something else may work every now and then but it’s not an efficient way to get to the solution, if anything in theory it would take longer than “Following the light”

Which leads onto what is the right way? How about a “Sniper” it’s a lame name but it’s late (At time of writing anyway) and it’s the best I can come up with…

Sniper

So Snipers will go and sit quietly for days at a time waiting for a target and then attack at the most opportune moment, relying on instinct and experience to chose that time. By listening to the whole problem and asking some simple questions you can get a fuller picture of what is going on, by this point if you have experienced issues similar to this then your experience will play a part and your gut instinct will fill int he gaps. This doesn’t mean you now go and grab the shotgun to shoot the target. Is this the right problem? does it match the use case? based on your understanding could it possibly cause the described problem? if so, pick up the rifle and fire off a shot. There’s a better than average chance you’ve solved the problem, if you haven’t then you have ruled out the most likely cause based on the current evidence.

What next? you go after the next most likely cause based on the new set of information and rinse / repeat. The most important step is to re-base our decision based on failed likely outcomes. Now what do you do when you have no idea what the problem is, well you need to start somewhere so rule something out. If you have the opportunity to do something that is simple that would rule out multiple possibilities, do it. Then rinse and repeat, always re-basing based on new evidence gathered, it sounds like the scatter gun approach, and it is but with one difference, you have listened to the whole problem, and based on your experiences and gut instinct you have logically chosen the most likely cause, you are not shooting in the dark or following a white rabbit.

Summary

If my physiotherapist had re-based their assumptions based on new data I’d have been treated sooner, instead I had to go see a surgical consultant that basically worked out what was wrong by listening to the problem, asking some simple questions and hitting me with a little hammer on each foot, one leg reflexes the other does not. He suspected a prolapsed disc based on what I had said and my symptoms and then set about doing a number of tests to prove the hypothesis, when one test didn’t show the problem a new test was tried.

Simples.

Dealing with Technical Debt

May 4, 2012 / / 1 Comment

A brief history

Last week I touched on Dealing with rapid change and I kinda got carried away and exceeded my self imposed 800 word limit. So the point of today’s blog is about capturing the technical debt and then how best to deal with it so you don’t end up in a situation where the service starts suffering because of tactical decisions made without suitable foresight.

So to summerise what technical debt is for those that did not read last weeks post (shame on you), Technical Debt is what you accrue when you have to make a change that does not head towards the overal goal but instead causes additional headaches for managing the environment or some how limits you in achieving the overal goal of a perfect system.

Capturing technical debt

My personal preference to tracking technical debt is a ticketing system, just create a way within that to easily identify what is technical debt and what is a normal task. You don’t have to use a ticketing system, you could just write it on paper or in a spreadsheet or what ever, the important thing is that you capture it with a reasonable amount of detail.

Avoid the temptation of filling the ticket with a lot of information, just put enough in it that explains what the problem is and why it needs to be fixed, if you have some suggestions on how it could be fixed add them to the ticket but don’t worry about saying “this is the solution” that can be done when the ticket is actioned.

Try and make sure you capture the following as a rule of thumb:

  • What is the issue?
  • Why is it an issue?
  • Any future tasks that are dependant on it
  • How long the task will take
  • A rough priority

These things will help prioritise the task when it comes to the planning the next set of tasks / projects that need to be actioned, but it doesn’t really help it get prioritised. Why? because it will never be the focus of the business to do the boring work that makes it stable unless there are issues or it has to be done as dependancy of another task.

Actioning technical debt

As I pointed out before, the business will never prioritise the technical debt unless there is a real issue for it to do so, service stability or dependancy on another task. This is a fact of life, and if you’ve found your self in this situation getting frustrated about all the hundreds of days of backlog tasks of technical debt that is accruing, panic no more.

As I pointed out above, the business will never want to do the technical debt unless there is good cause to do so, so the point of capturing the tickets with the right information is that the dependancies are clear, the outcomes of not doing it are clear, this makes it easier to discuss it as a business requirement. That is not enough though, you will get some tasks done but you will not be decreasing the technical debt it will continue to increase.

You need to create an environment in your immediate team and the extended team that understand why the technical debt needs to be actioned. This will be easier to do than convincing the whole business as to why it is important. Once you have the buy-in of the teams everyone will hopefully understand why it is important to keep the technical debt to a minimum. This will help it take a higher priority when it comes to scheduling tasks and help reduce the technical debt in the long run, it would also be a good idea as a group to identify an amount of technical debt that as a group you are happy to live with, this can be calculated on the amount of effort days required to deliver each task. This is a sure fire way of getting technical debt actioned and will help ensure that it remains at a level that is sustainable.

There’s always going to be a risk that you’ve tried all of the above and you’ve still not gotten anywhere, the technical debt keeps rising and the environment continues to get more and more complicated to work within. Simple, do not worry about it, you did what you were meant to, you raised the issues, you pointed it out to your boss, you can kick back and relax, maybe even take deep joy in the moment when it all fails and someone asks why and you just point out the years worth of technical debt that has ground your system to a halt. In short, it’s not your problem, it’s your bosses, you just need to make sure you capture it and raise it.

Summary

Technical debt is bad, if you’re not aware of it you need to be, you need to have a mechanism for dealing with it and if you don’t your systems will grind to a halt and you will probably be one of those companies that re-builds the entire infrastructure every 3-5 years because the technical debt was so large that the environment was unmanageable.

Dealing with rapid change

April 27, 2012 / / 1 Comment

It’s never going to be perfect

I know a number of sysadmins, myself included; who always are striving to get to the “perfect” system. It’s a wonderful goal to have and it should definitely be what you’re aiming to do, but you shouldn’t hold onto the perfect vision despite everything else, at the end of the day you are at work to provide value to the business not to hinder it. This is not to say that you shouldn’t have morals, and that there are not things that you need to stick to your guns on, as long as there’s a good business reason for it you can pretty much do that, but again, at the end of the day you are there for the businesses benefit.

The first part of dealing with rapid change is to realise that it will never be perfect, any designs you draw up now will be totally inaccurate a few months down the line or the business would have changed significantly where what you were aiming for has now moved. Goal post syndrome. So you have to be adaptable, your plan can not be strict in execution but it can be a guideline to what you are trying to achieve. Once you have accepted that it will never be perfect it makes life a lot easier when compromising on the little decisions and means you can focus on getting towards the goal rather than achieving the goal, as long as each change is a progression towards the end goal there is really no need to argue the point, you may want to go “above and beyond” to deliver a little more benefit but that should be off your own back.

The second part is all about knowing what is important to hold onto and what is not. It’s very easy to treat every decision as being vital to achieving the goal but normally they are not so important. As I mentioned before, it’s more important that you are moving towards the goal than achieving it, so any decision that moves towards the goal should not be contested, by all means try and add extra work in to get to the goal quicker but do not contest the task.

You should never really carry out tasks that make things worse, and I’d suggest it is these that you hold onto a little bit (not a lot…), make sure you point out why the task makes things worse, if needed make sure you get it in writing, but ultimately you need to get the task done if the business needs it, regardless of it making the overall system worse.

Making sure it doesn’t get un-manageable

So assuming that you have had to make some changes that are not in-line with the end goal you need a way of dealing with it, you have to track the fact that because of one change you have extra work to do. This is called “Technical Debt”, it’s what you accrue when you make a change that is not overall beneficial to the management of the environment or has a negative impact on the business in the long run. You’re always going to have some technical debt because you will never reach your goal, and if you do you will be dreaming up new ways to create technical debt.

These types of changes that produce technical debt can be summarised as “Tactical” typically because the business needs it now to remain competitive. The trick here is to not be objectionable to doing the tactical change, at the end of the day you have to deliver X by Y, so the scope of changing how you do that is finite, from the sysadmin point of view you can do an elaborate deployment if you wish, as long as you meet the time based deadline. This gives you the ability to try and carry out the task in a better way and hopefully reducing the technical debt.

This post was all about how to deal with rapid change, so far I’ve only really taked about making the decisions around what is important to hold on to and not arguing about every detail. This is important as it will make you less objectionable and hopefully minimise the technical debt, but you still need to deal with the technical debt.

Every time you have to make a tactical change that produces technical debt, spend a couple of mins logging tickets or making note of all of the individual actions that need to happen to get back out of the situation that has now been created. This is vital as the next time it comes to prioritising a project you have a shed load of evidence that says what you need to already fix to get back to a positive position, to make sure that is easy to plan in when you log the tickets make sure you capture the amount of time it will take to do the task.

Hopefully your boss will like the fact that the work has been captured and you can discuss how to reduce the technical debt to get “back on track” if you’re really unfortunate and your boss still has desires for tactical changes that eventually lead to fire fighting you have a nice list of tass that you have raised to say that you should be doing those to get back to a point of not fire fighting.

Summary

Don’t be too stuck on arguing the point of a task, eventually you’ll lose so just focus on minimising the technical debt that it causes and where possible only make changes that progress towards the end goal. I’ll write something else next week about dealing with technical debt, mainly because this was getting too long. Just take away from this that you don’t have to hold on to you technical bone to get your way, you just need to make sure that if there is a negative change the remediation work is tracked.

Hiring in IT

April 20, 2012 / / No Comments

The background

So for those of you that do not know me, I work at a Open Source company called Alfresco and we are hiring a lot of people this year. As a result we are suffering like all other IT companies trying to hire in the UK at the moment, there’s a skills shortage in IT and it is not something that we as an individual company can solve. If you are a person currently looking for work and struggling in IT I suggest you stop reading now.

What’s the real issue

It’s not a lack of candidates, we get a regular stream of good looking CV’s, but we’re not in the habit of looking for just anyone, we want people that are passionate about open source, people that want to make a difference. I suppose that by it’s self is not difficult, but when you combine that with a relatively decent job spec, and then the personal fit of the team etc it becomes a bit more challenging. We quite regularly get either very personable people that are lacking the technical skills to do the job or some very technical people that are missing the personal skills, needless to say it’s about compromise.

The above is based on a good candidate that just isn’t right for us, however in most cases (80% ish) the candidates are, how do we say this, overly optimistic with their CV’s? there’s been a number of people we’ve interviewed off of the strength of their CV and then they honestly expect us to not ask questions about their past experiences. Quite a number of CV’s have items on them where the person was part of a team doing the task and they claim (on the CV) to have been more or less the sole member, it all becomes very painful in the interview when you start asking questions on it. Do people really think we won’t ask?

So with that in mind, be weary of CV’s that have a lot of jargon on them, if possible aim for CV’s that have less on them, especially if that’s backed up with years of experience. it is more likely that that candidate is only listing things they are proficient in rather than things they have touched, or watched someone else touch.

The right compromise

If you think you won’t have to compromise on some element of the job spec / candidate persona then you should also probably stop reading this and go back to that wonderful place you come from where pigs fly and monkeys act as butlers.

It’s easier to say this than to live with the consequences, needless to say I have been unfortunate enough to live with some compromises that just weren’t quite right. Lets look at it in little chunks.

Technical ability is not everything, if you do have to compromise, compromise on this, you shouldn’t shoot your self in the foot, but choose a candidate that can do the job at hand and has room to grow. Hopefully the candidate will want to learn new things and develop their careers so it wouldn’t be the end of the world as long as they show signs of wanting to progress and develop.

Personality is key, there’s no point hiring someone that will come in and act as a rouge agent or isolated because they can’t gel with the team. I’d say the personality of the person is an area where you really don’t want to compromise on, if they only seem to slightly not fit with the team don’t worry about it, the team dynamic will change slightly but it should settle, you would need to identify which elements of the team’s “quirks’ you want to preserve and which ones would be benefited by having a slightly different personality in the team.

A little digression but probably valuable at this point, in the past I’ve had a sysadmin working along side me who seemed personable and would fit in personality wise (and they did) they seemed a little weak technically but we hoped that would develop; it turned out when they started they thought they were more technical than they actually were. They were the sort of person that you could give a task to and eventually they’d have something that worked, but they may not necessarily know how they got it to work. They also had issues arguing technical points, sticking hard and fast to their guns while not having a good reason to at the time and requiring a few days of googling to come back with a link that summarised that you could do it their way or the other way, so it also didn’t back up their ideals.

To be honest it was a real struggle for me personally as what I needed in the team was someone that was technical enough to take some of the workload off of me, but despite spending time training and explaining why things were done that way, the knowledge didn’t sink in. I’d feel bad that I couldn’t get the information in, but other people tried and failed as well, so the common problem is probably the cause. The biggest issue was that they were not willing to progress, maybe because they thought they knew it all, or because they just weren’t able to grasp the technical detail.

So if you have to compromise on technology skills make sure they are personable and willing to learn and progress, people can develop technical know how if they have the personality that allows them to, but changing someones personality is much much harder.

If you’re interested in working at Alfresco you should keep a regular eye on our Careers page, it doesn’t have all of our jobs on it so feel free to email your CV through just on the off chance, we’re always looking for good people.

How to get a spaceship

April 13, 2012 / / 1 Comment

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.

Are you doing what you love?

April 6, 2012 / / 1 Comment

Well, are you?

I am a firm believer in doing what you love todo, What I mean by that is that if there is something you like todo you should try to find ways to make it a central part of your life.

It doesn’t make sense to be doing a job that you don’t like or that you are uncomfortable with and if you want to get ahead and you want to be more than average you have to do something you are passionate about. Just look around the office and see how many people you perceive to be more than average I bet all if not most of them are passionate about what they’re doing…

So the question is are you? if you ever wake up and think “I just don’t want to do it today” Then probably not, and even if you do think that, work out is it because you don’t like what you’re doing or the environment around you?

If you are not doing what you love to do you need to first work out what that is and then work out how you can spend more time doing it.
I can’t tell you what you love to do, but you will have an idea about it, what do you do in your spare time, when you’re bored of sitting in front of the tv and you really feel like doing something, for me I always end up fiddling with one of the servers I have or writing a small application or doing something a little techy.

It’s not all roses

The only reason I’m a sysadmin right now is I like knowing how things work, I like diving into the nitty gritty detail and coming out with an understanding, I also know I hate getting bogged down in the detail, I really don’t like it when I feel like I’m learning all that can be learnt about a subject so I tend to start to switch off if I sense the end is in sight. So being in IT is good for me I get to play with all sorts of interesting stuff and I get to do it to an interim level and I never have to be considered an expert in anything, if only. Some times you have to do things that are not interesting, things that are not what you find enjoyable about your work, but work is work, the good with the bad, the trick is to minimise that work so you spend more time doing what you like.

As times goes on you can start to realise that there’s many elements of even the things you like doing that are not right for you. I hate documenting, I hate long drawn out problems, I hate tickets so what do I do to stop myself doing them? Well with documentation, I relaised that I hate spending hours in one chunk writing something that is useless, but I don’t mind throwing a structured wiki together and just writing small snippets of docs, so my documentation is now light not heavy, so it’s not that i hate documentation it’s more that i hated spending all that time in one go on it. Same principle with long drawn out problems, I tend to chunk them into smaller more manageable pieces and do a little it it often.

Summary

While doing all the things you love there will of course be bits you don’t love doing but still need to do, the trick is to find ways of doing them that make it more bearable. Try and avoid the temptation of just offloading the work to others, it doesn’t make you look good, and it is good to keep your hand in.

Also while in the job you love, don’t be afraid of looking for other jobs with different challenges or opportunities, change is good and helps us provide more value to an organisation. This doesn’t mean you need to look outside of your current organisation but by being a little astute with your conversations in work you may find other opportunities arise and help you out.

Also don’t be afraid of working out what you actually love, so I started out in IT because I love the technology and the playing with things, but as I’ve been in the environment for a while thats tuff is interesting but not so much a passion, I have realised over the years that I prefer helping people, Mentoring people planning projects etc, and i’m sure when i start doing those things more I’ll find other things that I like doing and I will always move towards doing more of the stuff I Love doing and less of the stuff I dislike, it’s better for me and it’s better for the organisation.