Deciphering People

During my time working in the software development industry I have met a large group of interesting professionals with varying personalities. I have blogged before that some of these relationships have been challenges. However, I guess that is just part of life’s rich tapestry otherwise known as human-kind……We are only talking about 6 or 7 out of hundreds and hundreds……

Another occasion I have blogged about management and team building principles. In particular I once wrote a post that was referring to the team leader or manager being whiter than white when it came to their decisions and actions.

Viewing a team member or a manager through a different perspective is a technique I have come to appreciate in recent years. After all, there is always another view point out there. Whether you agree with the other persons view or not is largely irrelevant, at least in the first instance. The skill is if you are able to see it from their perspective, you are in better position to assist them seeing your viewpoint. Which in theory, should lead to a better solution for your business, client/customer or yourself.

Instigating thinking of perspective in your life and encouraging those around you to think in a similar vein must be good for you, your team or your business that you represent. Far too many people get caught up in politics. I must admit that from time to time I used to get dragged into these kinds of debates.

Developing these skills is difficult and my previous role here in NZ certainly gave me a lot of opportunity to witness first hand a whole myriad of people who failed to see the other perspective and continued on their personally driven paths. Not realising that they were leaving a trail of chaos and dissention in the rank and file.

Considering that this was pointed out to the business on numerous occasions and not to mention by countless numbers within the organisation, it was rather disappointing to witness the situation continue to escalate month after month.

Other approaches to dealing with problems is to not change the perspective and understand other views but to change he scope of the problem. i.e. Describe the problem to yourself in a different way. Therefore, rather than sitting there wondering “Why aren’t my ideas being taken on board?” Ask the question in a different way. “Do the people I am talking to care about the business?”. If the answer is no, then you probably have your answer.

Now we have covered the two simple strategies for breaking down a problem in the workplace, business or home. Yes I did say home. How many of you have kids? How many of you have had to intervene into a piece of sibling rivalry? Firstly, you carefully listen to the views of all the kids involved before choosing who and how to sanction/punish/ground.

Why, why, why then do we see professionals in the workplace not follow these simple steps of listening to all the view points before making a judgement call. I am guessing, it could be preconceived ideas based on ignorance, arrogance, education, experience, naivety……….. This list goes on and on.

Analysing this a little further I feel there is a small element of fear for some. A large degree of politics and sheer greed. Not necessarily monetary greed. Power hungry greed, people who will often step on anyone they feel obstructs them from their personal mission without considering the merits or sentiment of the view holder. Very rarely do these individualistic and selfish approaches to managing a team or business align with the company strategy.

Yet time and time again this cancer of the modern workplace appears to raise it ugly head above the clouds and rain or should I say reign down a culture more aligned to the 15th century rather than the 21st. Thankfully I live in the 21st century and practice personal policies and ethics that try to understand before I react.

If you find yourself in this situation, what are your options? I guess this depends on the area of conflict, whether you feel that anything will change, your personal circumstances etc. This list is longer that the Chinese phone book in Howick.

Sedentary work, or office work as my physio described it to me the other week suffers this kind of politics more than most other areas. If there is a disagreement at a car parts yard or a cement layers business the actions are generally quite direct and quick. In the office world we appear to provide an environment where a punch up and a skinful or beer is not considered conducive to a harmonious working environment. And quite rightly so.

As a result of this mature approach we are actually creating a breeding ground for single minded, single problem definition and/or single perception people. It is like the air cooled/heated offices act as a giant Petri dish allowing this bacteria to blossom.

Considering the above, I have always wondered if this kind of person has a hidden agenda or some sort of underlying code of conduct that requires decrypting, a bit like the Da Vinci code I guess. Are they a freak wave in the corporate world? I have met very few people like this but the one that stands shall remain nameless in the blog at this stage.

Until such a time that I am ready to publish more on the subject I guess we have to make do with one final thought.

Not until you have been a victim do you really understand the ramifications of these actions. However, if you are prepared to stand up and challenge areas that you feel passionate about you’ll root out these personality types before too long. Once that objective is achieved, if you can’t win the argument, move on and find somewhere where you can influence and enjoy your work. I have met far too many people over the years who have spent years and years (quite literally) of their lives battling against these machines. Sometime you just need to know when to move on. I did.

Thanks for reading.
Lee.

Credit Crunch 2009 and IT.

I would suggest that other that Britney Spears in recent months "Credit Crunch" has been the most widely used search term on the google servers. No doubt someone will correct me on this subjective comment.

What does this mean for us in IT over the coming months/years. For sure many companies are going to tighten their belts during 2009. Capital expenditure will probably have processes, procedures and forms redesigned/created for general publication. The good companies started this 12 months ago.

Well I guess there is (as always) both opportunity and risk. Mergers and Aquisitions will continue therefore some consolidation will occur. How you are affected will very much depend on what you do, your role and business etc, your skills and a little bit of luck. There isn't too much you can do if your CEO is Bernard Madoff. But if your company is tight on expenses and hasn't blown the budget in recent months on a hope of business eventuating then you have a tick in the good column.

I list below my 5 top tips to avoiding uncertaintly or unemployment due to the credit crisis.

1. Networking.

Many people have simply rode the good times of the last decade and have largely ignored this simple working practice. We all know the phase "It's not what you know but who you know." Check all your email addresses for old colleagues and make contact. Join professional and social networking sites like LinkedIn and put your profile on the web and reconnect to those old colleagues.

You may go as far as publish a blog. At a minimum your CV should be on your regional major recruitment portal. Employment is changing. People are now being headhunted via these sites and in these times they (recruiters and employers) will perform the data mining rather than incur the costs to advertise. You may be the dream candidate but if the job is not advertised then you will not hear about it.

Subscribe to news feeds for your technologies and industry and get reading. Join forums and post questions and replies therefore becoming known as a regular and reliable contributor.

2. Review and update your CV.

Even if you feel you have the most resilient of employer and the most solid of job prospects at your firm, you should always from time to time review the CV. That technology buzzword from 2005 may not cut it when there are 50 candidates for a job, the search spiders may know it as something different in 2008. Just ask IBM and the rebranding of the AS400, System i, iSeries or Power System.

Read, read and re-read your CV. Tune it to your skills, be honest and review it candidly. Would you employ you? I see too many CV's where the presentation is poor. Spacing, order, typo's are a few of my pet hates.

So update the CV and rehearse in your mind what you would like to project at interview. If the CV doesn't say it then you are unlikely to be be given the opportunity to do so either.

Do not wait until you need your CV. It takes a week or two to polish a decent CV and in a competitive environment like redundancy when many people or made available that next job could be gone before you hit the spell checker toolbar button.

3. Perform a skills review and add breadth to your skill set.

If you are a one trick pony. Learn another one quick. Unless of course you are best of breed then you might be OK. As a developer you are used to change and learning on the job. Make 2009 the year where you spend less time on the golf course and more on training courses and home learning. Understand what is coming in your area and ensure you know it well.

Challenge your employer for a training course. If they refuse? What does this say.......

4. Talk to your boss.

Put simply. Don't panic too much if your company is pretty safe. After all some firms have business models that thrive in these uncertain times. But there is nothing stopping you asking the hard and direct questions of your boss. Any quality manager will already understand the local situation and will have a reply for you if they haven't already addressed this as part of their attrition strategy.

If you don't like what the boss says then ask the bosses boss. Get the answers you need.

5. Cut your expenditure (Work and Home).

There are many things you can do here. Take sandwiches to work. Car pool to work. Reduce mobile phone expenses. Go to the gym instead of the pub to name a few.

All of these will boost your savings a little just in case you are cut. This will increase the amount of time you have a make an informed next career choice rather than a hasty decision and a blot on the CV.

As a Plex/2e developer you are probably slightly more shielded than others. After all, you are not ten a penny people. That niche skillset could help out quite nicely.

So look out for the signs.

Good Luck.

Thanks for reading.
Lee.

Is honesty always the best policy?

At various times in my life I have had this dilemma and I am sure many of you reading this have too.

I have always believed that honesty is the best policy.

Why?

This was drummed into me as a child. You would all remember being younger and hearing one of your parents or elders in your family/whanau say, “Just tell the truth, you won’t get into trouble as long as you tell me what happened.”, “Nobody likes liars.”, “You must be honest otherwise the truth will come out one day and come back and bite you on the bottom.”.

In various articles in this blog I have made reference to my experiences in general and I have been 100% honest in delivering balanced articles. IMHO.

Just recently I found myself in a situation where I was beginning to doubt my values/beliefs in this area. This was quite upsetting and worrying after 38 years of preaching and living by the aforementioned ideals.

So here are a few examples of where we all probably choose to ignore this policy.

Consider your answers to these questions.

“Honey, does my bum look big in this dress?”
“Who farted?”
“Do you love me?”

After looking at a baby picture “Isn’t he/she a stunner?”

Or, have you ever heard yourself saying that “The cheque is in the post” knowing full well that the cheque hasn’t even been written, let alone cashable.

Actually I have thought of a few extra ones but I will leave those to your imagination…………

So back to that dilemma. I truthfully explained why I was resigning from the company that I worked for at the time. I explained the major reason quite clearly and to be fair there were a few more including my desire for a fresh challenge so I could rediscover that "Woo factor!".

But.

The truth however, backfired I guess. Why.....

I was ignored for the remainder of my notice period and I struggled to provide the business with a true handover that it deserved. I guess as with all leavers my name will be mentioned for the things that go wrong. That is until the next person leaves. Actually i found out today that it was mud for some implementation tha I was working on. Despite my willingness to ensure it was completed.........

In summary, I believe that on this occasion it was because the truth hurts and sometimes you find yourself trying to be open and honest but if the listener doesn’t like it, they don't hear it.

I guess this has taught me that there is no judging reactions.

So I guess it all depends on the context that the honesty was received.

In my case, I believe on reflection that the combination of honesty (on my part), truth hurts (receivers reaction), arrogance and politics (receivers modus operandi and expertise), I may have chosen the wrong option, or did I?

I doubt this situation will happen again, but if I find myself in this situation in the next 25 years of my working life. I will then have a real dilemma.

Do I stick to the values that I was brought up with?

or,

• stoop to the lowest common denominator and play dead like so many others do and stagnate in their jobs.
• Add/have no opinion or worth to an organisation.
• Destroy that drive and energy within me.

I don’t know the answer to this question at this stage but it will either be:-

I’ll just say nothing, stay patient and look forward to the time when karma resolves my issue for me.

Or.

Tell it as it is and hope for a more professional response and keep one of my core personal life values in place.

What would you choose? I'm leaning to the later.

Thanks for reading.
Lee.

Knowledge capture & use in technical support communities - Part 1

This three-part article is adapted from one I wrote almost 5 years ago when much of what you will read about was fresh in my mind. This adaptation addresses only the passage of time and some points of style and meaning for a wide audience.

Whilst software development is the subject of this blog, let us not forget those who (typically in large organisations) support the developers and others.

The nature of technical support communities.

Technical communities come in many forms, be they design teams, development teams or support teams.

Whilst design and development teams are largely about the creation process, they still have many day-to-day activities which are defined and repeatable. Support teams, although fulfilling an entirely different role, often have to create on a very short-term basis. So it can be seen that the different types of teams have similar requirements.

However, the support team seems, most often, to be the one to get out of control. The difference is that the support team is always working on a short time frame. In addition, support teams often become involved in project work and this adds to the complexity of the day-to-day activities, as the time frames are shortened still more.

Most often, you will find that staff in a support team are very good at what they do - they have to be to survive. Unfortunately, the higher the skill of the staff, the more reliant you are on those staff to keep the systems running. It is a difficult and time-consuming option to bring 'green' members into the team.

How many support managers have not recognised that documentation is a key part to the support process? I would wager very few. Fewer still, I propose, have succeeded in completing the documentation requirements within their team and reaped the kinds of benefits they were expecting.

Documentation, to the 'tech', is a four-letter word. I, myself, recall asking the question "Do you want me to document it, or do it?" Simple economies prevent the techs from having enough time to complete the documentation task and many welcome this excuse not to do it.

Another trait of support teams is the experts. In virtually any support team, there will be experts in various disciplines. Most often, however, these experts are relied upon to provide most of the resource in fixing problems in their area of expertise when they should, in fact, be called upon to share their knowledge.

Shared knowledge is a powerful tool. Experts will always be needed when particularly difficult or unusual situations occur, but the team as a whole should be able to leverage the experience to improve task turnaround times through a more even spread of the load.

Knowledge transfer

It has been documented in studies that the best way to learn something is to have an expert stand over your shoulder while you go 'hands on'. The reality of the situation in front of the learner, coupled with specific and pertinent comments or instructions from the expert gives the learner an experience often indistinguishable from the real thing. The learner also has the opportunity to ask direct questions in the context of what they are doing. Book learning, on the other hand, can only go so far with static examples and predetermined situations.

Perhaps the most important aspect of 'over-the-shoulder' learning, however, is that the expert is unlikely to simply recite steps by rote. There will be an accompanying commentary and usually a significant amount of reasoning on why things are done that way. This is very important in equipping the learner for when things do not go to plan.

Learning the steps of a process by heart is well and good when the process works. Most often, however, processes do not cover all possibilities and the rote-learner of the steps is going to come unstuck when an unforeseen, or simply undocumented situation arises. Unless the learner understands why they are taking the steps and what they should be achieving, they are almost as much 'in the dark' as prior to learning the steps.

Having knowledge about the nature of the process and the goings on under the covers helps get through many small deviations from the norm and also helps in issue resolution, as the learner is able to return to the expert with an hypothesis, or at least having done some basic checks suggested by the nature of the operation.

The key issue with this type of knowledge transfer is that, in the majority of cases, the expert is already overworked and has no time to spend standing over shoulders.

A secondary issue is that the expert may have to impart their knowledge, over time, to a number of different people, and this is inefficient.

The 'Virtual Expert'

From what has been discussed so far, it is clear that expert knowledge is required, but that tying up the expert in this process is seen as unproductive in most situations. We cannot get away from requiring time from the expert, but we can minimise this time and capitilise on it by recording the knowledge in the right way.

In part 2 of this article I will go into methods for capturing this knowledge in the most effective way.

Thanks for reading.
Allister.

What makes a good software developer?

I have decided to move on from my current role after over four years working at my present company. My reasons are varied and plentiful but as always the lure of a fresh new challenge often commands the majority of my thoughts.

I have started once more on the interview merry go round, first with agents and then in the coming weeks with potential employers. This is an interesting time in my career and certainly a change I am looking forward to albeit a little nervously as I have only ever had three IT related job interviews in my life.

During my early stages of interview with one particular agent I was asked a really good open question. The question was “What makes a good software developer?”. I waited no more than 2 seconds before I began rattling off my opinion. Normally in these situations you take the time to consider what you want to say and then lead up to the answer.

This felt different.

I guess this is because although I have never answered this question before (personally or via my blog), I have hired enough developers and non-developers over the years to understand what I believe a good developer to be. After all, one of my own interview questions to potential new hires is “Why software development for a career?”

I ask this question as I want to know what motivated them to get into software development and what maintains that desire to be a software developer. At my last firm a new project manager joined and we got talking about stuff. You know, the technical stuff. It was quite obvious to me that this guy didn’t want to be a project manager and that he still harboured that technical development desire. I knew this because as a project manager he would say stuff like “Worst case I can write that program.” or “Couldn’t we do this in x language or y language.” It was pretty obvious to me that this guy couldn’t let go, and this is what I look for.

For me the number one thing is the passion. I want to see this in the eyes of the candidate as they express to me their achievements and technical prowess. I look for the body language that backs up these passionate views.

I have been part of and built software development teams. I have written in other posts that you do need a mixture of people at varying stages in their careers with a good balance of personal motivating factors. Passion is certainly the one I look for when I am considering the lead roles within a team. The reason being that I believe as a lead developer you must bring others on by example.

Other factors to look for, especially for a permanent employee are:-

* Longevity in the industry and loyalty to an employer or two.
* Proof of learning multiple languages and having the desire to adapt to development trends.
* Good understanding of general development concepts and practices.

These are pretty generic but with passion, loyalty, desire, adaptability and a good all round understanding of development I believe I can teach any developer the technology of the month.

Without these attributes I guess you could be selling your business short. If I had to choose one then passion is the one I would go for.

If you see a developer struggling with some code all day but eventually they let out an enormous scream of relief as they finally solve their issue, jump up and then start punching the air in delight in the style of Rocky Balboa.

I’ll have that person in my team any day.

Thanks for reading.
Lee.

Always wipe your bum!

“What comes around goes around” is a phrase commonly used when preaching to others about ethical behaviour or by those that believe that there is a levelling force out there that cares enough to ensure that things work out evenly in the end. Other phrases like “You are what you eat”, “You will reap what you sow” or “Do unto others as you would have them do unto you” are also symbolic of phrases embracing karma.

I am a keen believer that as a role model (Manager/Leader) in team management you need to practice what you preach. During the team management phases of my career, my style has generally been a hands-on approach. This enables me to utilise my technical and leadership qualities on a daily basis from within the bosom of the team. I have never sought my own luxury office or other status symbol as an indication of my position. My positioning amongst the team would mean I am always available to talk through ideas or issues. I most certainly will be there to encourage, assist and develop the teams skills. If I ever needed privacy I could always track down a meeting room, shelter in the local café or work from home for an afternoon.

The purpose of this article is not to discuss the merits of positioning yourself as a manager or a leader within your development team, or is it to debate the benefits of the hands-on versus hands-off management and leadership philosophies. Each of these items are environment specific and so in depth that they are best served with full discussion in a future article.

I want to discuss the aspects of being a role model for your team and how your behaviour affects others around you.

I have worked with many different people over the years all with interesting quirks and features and every single one of them has in some way or another left their mark on me, not physically but by influencing my views as a ‘software development professional’ and helping me cast my expectations of the working community in general.

Some I speak of as visionaries and ahead of the curve, I value many others as trusted colleagues whose integrity has shaped my beliefs of honesty and transparency, there are the characters who make you laugh/cry or cringe, even before they speak. Then there are the odd four or five that if I were to write down my true opinion would land me in court fighting a defamation hearing, the blog would be censored as the article degenerates with unprintable language that even Kevin ‘Bloody’ Wilson would find objectionable.

Many managers fail to understand that you are judged on more than just your innovations or effectiveness, and you can guarantee more than death and taxes, your staff and colleagues will eloquently appraise you behind your back, if you are lucky to your face also. Managing upwards or sideways is only half the issue and this is where your political skills shine if you are that way inclined. Having a team that is 100% focused behind you is the harder half of the equation to implement successfully, and it is this half that is often overlooked by a manager on the path of change glory.

To put this into context I once read a couple of short quotes that I believe summarises the management challenge quite succinctly.

“Bulls**it can get you to the top of the corporate ladder, but it’s not good enough to keep you there”.

“When a monkey at the top of the tree looks down they see smiling faces. When you are below and look up, you only see a**eholes.”

As a manager you will be remembered for what you do wrong or badly as much as you do good. Actually, a sack full of positive memories can often be overshadowed by one or two bad decisions whether by misjudgement or deliberately/deviously thought out. The fact that this perception is fair or not is open for debate.

On a personal level I owe as much to the four or five people I’d rather not mention (All ex colleagues) as I do to those that have provided the motivation and broadened my thinking.

Quite often I have seen people behave in a manner that inspires me to make that mental note of “I wouldn’t do it that way” or “When I am in that position I wouldn’t do that”.

• Ever had a manager who bullies staff or chastises staff in front of others?
• Ever had a manager that values process and technology over the people aspects of running a team?
• Ever had a manager who seeks opinion but never listens and ignores all input?
• Ever had a manager who promises a review and then waited months or years for it to materialise?
• Ever had a manager breeze though a company with change havoc only to move on without seeing the job through.

Many of these are management lessons on page one of the manual and combine communication and basic human needs. Anyone who has ever taken the time to read material related to Maslow's triangle will understand my point here. I have seen all of these incidents above over the years with varying results, and once again the negative memories override any goodwill previously earned.

Last week I witnessed another of those moments (albeit small) when a direct line manager at my firm failed to stand up and be counted during a leaving speech of a long serving colleague who now reported to them. I was aware of a few differences in opinion between the two people that led to the resignation in the first place, but I felt that this could have been a time of reconciliation.

So whilst most were expecting the usual speech from the line manager I was shocked to see the manager hiding in the wings, quite literally, and instead it was left for other managers to make the ‘Sorry to see you leave speech’. The employee did their speech afterwards and kept it civil and in my view edged the overall contest on points.

I will try and look for the positives out of all this even though I was disappointed enough to blog this today. I am not saying that as a manager or leader you have to be whiter than white. There are occasions when you have to make decisions people won't like. In other situations in sports management I might suggest that pleasantries are not high on the agenda. But I am saying that it is important to consider every factor of your role and day. It is often the little things that undo a manager.

So, another mark has been etched into my mind and I have learnt that it is more important to front up rather than avoid those awkward moments. After all, the negatives may build up and may invoke a re-greasing of the corporate ladder.

So, if you believe in karma please remember, you never know who is sitting on the rung just above or below you or whether they harbour plans to move ahead, so always wipe your bum.

Thanks for reading.
Lee.

"It's a funny old game."

This is a phrase that was immortalised many years ago into the educated soccer commentators punditry. To this day it is associated with the footballing legend Jimmy Greaves. He however denies that he has ever muttered these hallowed words, but I clearly recollect him talking to Ian St John on the Saint and Greavsie Show on numerous occasions. But if the man himself denies it then I guess I must be mistaken.

The ‘Saint and Greavsie show’ was a Saturday morning football preview show with a combination of the video highlights from the previous weeks games, interviews, opinion and a review of the upcoming games on the Saturday. With the advent of Sky and the commercialisation of the beautiful game, this show would now be a review of the upcoming games on the Saturday, Sunday and Monday.

I have been working in the software development business for far too long. My roles have ranged from day to day software developer, those with project and team management responsibilities to my current position of technology advocate for the CA 2E and CA Plex toolsets, specialising in enablement and best user practices in enterprise sized software development environments.

I often use analogies referring back to football to simplify describing issues or ideas to members of my teams, in fact, I find it rather amusing to compare football management to software development practices and the careful balancing act of creating high productivity software development teams.

My thoughts thus far are that the art of football management and that of software development team management have numerous parallels. I would historically refer to the construction industry or the car manufacturing industry to derive a comparison for the creation of the software product itself. But, when shaping your team it is quite clear that you require a myriad of skills, approaches, characters, opinions, ego’s, attitudes to name just a few of the attributes required to form a modern day software development team.

You will need to give careful consideration to your preferred team formation, management and coaching staff, youth development plans, team captaincy selection, picking the players for a particular project, substitutions, dealing with injuries to the squad, career mentoring as well as dabbling in the transfer market. The prospective number of parallels appears almost infinite.

So where do you possibly start?

I guess you have to look at yourself (The Manager) and decide on your style and approach. Are you going to be a hands on tree hugger or a hardnosed disciplinarian. i.e. A Steve McClaren or a Fabio Capello!

You then need to employ your trusted backroom staff (coaches and medical team). It is highly possible that as a manager you were also a former player and you probably still retain most of the skills required to perform many of the roles within your team, but be warned, if you do find yourself doing rather than managing then this is a sign that you have the incorrect balance in your team.

A manager that believes he can do every role within the team and often gets sucked into the detailed coding on the teams projects is guaranteed to be holding back the team come match day. He needs to empower his team with clear instructions and tactics in order to navigate the perils of developing quality software systems. His role should be to conduct the performance of the team from the broader viewpoint on the sidelines.

Your coaches are your technology evangelists. Their role is to ensure that the team fully understands industry best practices for your technology implementation and they are responsible for the day-to-day training and fitness of the players. These guys educate the players and control items like development standards and peer review processes. They play a pivotal role within the team to provide feedback about a player’s progress and readiness. The medical team are your DBA’s, they ensure that your players are in peak physical condition and provide ideas for improving performance and integrity of the team and products.

With the manager and backroom staff in situ along with the assumption that you have finalised team tactics and on field communication strategies, it is now time to concentrate on the squad.

The types of players that you have are critically important. It is imperative that the right mixture of roles and personalities are employed. It is no good having an entire squad made up of day coders or similarly overloading the human resources entirely out of super-coders and architecture astronauts. (Thanks Joel for that gem)

Great football teams have a mixture of leaders, defenders and all-rounders, as well as, specialist roles like striker or winger. These roles will have varying objectives and performance targets and are likely to be rewarded with differing pay levels. Generally, a striker will command a higher salary than a goalkeeper or a defender, they will also be motivated with bonuses linked to the number of goals that they score during a season.

Age is also important. Consider a team of 17 year old apprentices playing against a group of wiley old professionals with all the life experience caps that they have attained. Balance is a key element of this article and age along with the relevant fitness, naivety, passion, rawness and nerve is equally as important as any other attributes that make a strong team. Historically and with the only exception in soccer being the Busby Babes. Succesful sporting teams in general would have a mixture of ages.

All members of the team will have their objectives set at the start of the season and reiterated before each game. In fact the Post Implementation Review after the game will significantly affect the managers decision making for future games.

The yearly budget you have available will determine the number of star players that you can afford to employ. Just like when creating a fantasy football team online you will need to ensure that your team performs as a whole and doesn’t rely on a few heroes to score you those all important fantasy points. It is the same for a software development team. You can’t rely on a couple of heroes to do all the hard graft whilst the rest of the team sits back and watches. It is proven that heroes do not scale.

The type of project is also an important factor. The race for the league title could be considered a release of the software. Meticulous planning is paramount and this generally represents the highest team priority for the season. A cup competition could be described as PTF or service pack and generally has less lead time and the items of work are more random in scope and type. Emergency patches, I guess, would be extra time in a knockout match that has been tied after the first ninety minutes or the all important penalty shootout that the English always seem to lose.

Now that you have assembled your squad and understand the scope of your requirements you need to consider the team formation. Do you go for an attacking formation and line up for a project or a defensive approach? You can certainly draw from experience with similar projects and previous games against the same opposition. Do you go for an industry standard 4-4-2 formation or an attacking 4-3-3 with more focus of scoring goals with the risk that you may concede more.

So what roles do your players perform for your development team? Do you have a team of permanent players or do you have some on loan (contractors). You then have formation and player positional issues to consider.

Your goalkeeper is your gatekeeper. Their sole focus is to ensure that no errors make it into the production software. They perform the system regression testing.

Your defenders are your process converts and quality conscious developers, their stalwart approach ensures your projects have fewer bugs. These players traditionally lack flair and innovation and the technical ability to complete the highly intricate activities so should be avoided for high pressure or groundbreaking assignments. They are however, tenacious and determined and just as important to the overall performance of the team as any other team member. The defenders love solving configuration issues and enjoy debugging other developers code. They are advocates of unit testing processes and even talk to the testing team. There are of course exceptions to this sterotype, especailly in the modern game where the technical ability of players has been improved from the days of Chopper Harris.

Midfielders are much harder to quantify. They are generally the fitter members of your team and have the ability to perform many roles throughout the team. Some are specialist defensive minded players who protect the defenders with the extra level of security. They enjoy performing peer reviews.

Every team needs a playmaker. This is the person who enjoys having extra time on the ball and loves playing that killer pass to open up the projects defence. They are dead ball specialists and keen reference book readers.

Your wide players have speedy boots and code at a frenetic pace. They can sometimes trip up and get caught out of position but the times when they do get beyond the defence to create opportunities for the strikers can be crucial for a project that is running behind schedule. The amount of running they do during a project often ensures that they need to be substituted during a game.

The striker’s job is to produce the goals. They like to code all the sexy aspects of the deliverable. They tend to prefer GUI development to batch processing and they definitely pay lip service to the art of unit testing. They are generally calmer under pressure and have sublime belief in their own abilities which can lead to a sense of laziness as they tackle most projects with aplomb.

You also need to consider the preferred kicking foot or development skill. There are positions like wing back or winger where delivery is paramount. Having a rightfooter playing on the left or a leftfooter on the right has both good and not so good options. Again, with the modern game this is being phased out by two-footed players who have been nurtured since birth. But if you do have a one trick pony in your team then you need to consider their involvement carefully.

Getting the balance of your team right is important. Too many strikers and you will fail with every project as no-one wants to do the grunt work. Too many defenders and your project timelines will consistently slip. Every team needs to be carefully balanced, coached and briefed on the preferred ways of working.

It is a shame that so many managers just don’t understand the dynamics of a highly productive software development team. Perhaps we need to ensure that software development managers obtain their coaching badges and have performed at a professional level before progressing into the management arena, after all........

It’s a funny old game".

Thanks for reading.
Lee.