Technical Leadership #2

(continuing on from “Leading the Highly technical Team”)

The thing about leadership is that its such a large subject and there are any number of books and other writings on the subject. The point that I'd like to make, stated in my last instalment, is that leading technical teams has some very different aspects to leading other teams.

However some things don't change. There are lot of young people who have been placed onto a leadership role and have had no training or mentoring and in these days of tight training budgets, and no place to get it. Often these people are given those roles due to nothing more than their technical knowledge. It is my hope that this series will give those people some basis for their new career.

Firstly, for those who are starting in on this path I will congratulate you. You have shown that you do have the ability to lead, even if you don't yet realize it. To get to this point you have not only shown leadership in the past but you probably also have the support and recognition of your peers. All you need is some training.

Let's cover the bases first, in no particular order a good team leader…

1. has empathy with both the team and the individuals in the team.
2. makes decisions for the team
3. is able to listen effectively and impassively
4. stands between the team and others who might work against the team
5. gains the respect of the team
6. ensures the productivity of the team
7. ensures the ongoing enjoyment and cohesion of the team
8. ensures the team produces in the overall direction of the company
9. ensures the team works effectively with others
10. makes the very hard decisions that are sometimes needed for the good of the team

Empathy

Empathy itself is a large subject and absolutely essential for leadership. Without it you are nothing more than a manager and possibly a tyrant.

Empathy means to have an understanding of another person's viewpoint. Not just knowledge of, but “understanding”, there's a big difference. Some have described empathy as "Agape".  Agape is a Greek word with several meanings relating to a type of love. In this case the meaning I’m using is of a brotherly type of kinship, understanding, placing yourself in another’s shoes, a non-physical, non-sexual type of love. Not the English word or meaning of love but something that still means a positive emotional, yet professionally appropriate, feeling towards another.

Don't confuse this with agreement, its not necessary to agree with someone to have a true understanding of their viewpoint. This empathic feeling goes towards the team as a whole as well.

Often during this series I'll be talking about the individual and the team as if they are entirely separate and this is definitely the case. The team is like another identity that takes on it's own role and personality. I have even seen teams hell-bent on doing something that none of the team members want, usually a very bad situation, however it goes to show that the team itself does take on a personality of it's own. It's up to the leader to ensure the team's personality is in harmony with those in the team, and with the positive purpose of the team.

It is then with this empathy that the leader can understand the person's position and feels a genuine compassion for the circumstances, but in their position of management he/she also must take into consideration all the other factors surrounding a decision and acts accordingly. Being empathic, the leader will let the person know that he/she understands their position and communicates both his/her understanding, and the final decision equally.

I can almost hear some readers say that this talk of empathy will show a leader to be weak. Not at all, in fact I might suggest that if you are at all worried about appearing weak to your team, then perhaps you may have to reconsider how you interact with them. Are you leading them from the front, or are you chasing them from behind?

Weakness suggests that you can’t make those all important decisions and are easily led. We’ll get to those hard decisions in a later part of this series, but I’d suggest that you don’t even go there for the moment. You don’t want to appear ready and able to be the hire/fire kind of boss that looks around only to find no-one there.

Empathy has nothing to do with either strength or weakness. It has to do with understanding your team.

For the technical team this takes on another dimension. It is rare indeed that the leader has all of the skills of the team. I’ve heard even recently a manager claim that he would never ask one of his team to do something that he would not be able to do. This is a fallacy, in a technical team all the team members are there because they have specialist knowledge that is sometimes very unique. Its not possible for a leader to do everything the team members are able to do unless the members are reduced to a single skill level. Not a very effective team in most cases.

I couldn’t do half the things my wife does and she could not attempt to do a lot of what I do, yet we make a very effective team. As leader I have led teams who program in several languages on several platforms and have qualified skills that I could not master without the years of training and experience that they have. This I consider ideal as every member of every team is different. I have great admiration for the skills of the team members and this in turn prompts me to do the very best for the team; to be there for them when they need it; to listen; to stand for them against others; and to serve in the best way I can to allow them to use those unique skills. That is empathy.

Rather than weakness, this empathy is what allows a leader to make what are sometimes very hard decisions for the good of both the team and its individual members.

continued next session…

Leading the Highly Technical Team

Leading a team is definitely challenging but leading a technical team is a very specialised area that is extremely demanding. It is very different to other teams in many ways. A highly technical team is made up of artistic individuals who have a world of knowledge, skills and experience in their own technical areas. The highly skilled technical engineer, developer, programmer, or analyst are not generally known for their people skills. This results in every individual of the team wanting to head in their own direction, each certain that their choice is the right one and demanding that others follow their direction, even the boss.

They not only fall into the “we’ve tried that before and it didn’t work” attitude for every idea, as do most teams anywhere, but these individuals also are more likely to get upset with any changes, need to feel more status than others, and need to be recognised for their often very unique skills.

I have been very fortunate to have made a career out of leading technical teams, sometimes multi cultural, sometimes leading several teams based in different countries around the world.

When thinking about this recently I began to wonder about a question often asked, what makes a good leader? I’ve heard it said that people can be born leaders. Absolute rubbish! People are not born leaders, rather they are a product of the experiences they have and the people they meet. Its those experiences and the advice and ideas they get from people they grow to admire that gives them the tools and mindset to lead others.

Sure there are various skills required to be, for example, a development manager - project management and methodology understanding are some, but I'm not talking about management, I'm talking about leadership. The difference is that a manager manages things but a leader leads people.

Its not much help having a masters degree in project management when your team has no wish to do the project, our you are faced with a team member who wants to undermine you and your project in order to get recognised by the boss above you. Sure you can threaten dismissal or some other disciplinary action but that's not necessarily leadership.

Leadership is having empathy with the team and the individuals within the team, and the ability to focus that team towards a common goal. Providing a common direction is a difficult task for managers and it takes leaders to turn a team towards that common goal.

It’s a sad and unfortunate fact that there seems to be more managers these days than leaders.

To be continued…

Word Clouds

I've been playing around with Word Tags or Word Clouds recently and was directed to a website called Wordie (http://www.wordle.net).
This website allows anyone to create word clouds from their favourite websites. Here's mine from my blog.

The PDA Today

It's a little off topic but I've been using it so much these days I thought it worth a mention.

As mentioned in another post, I've used PDA devices since the late 90's starting out with the Psion 5 before I moved on to the very successful palm pilot, specifically the Palm Tungsten T. I switched to windows mobile with the purchase of the Palm Treo 700w a few years later and in the last year I have had an iPhone and a Blackberry and now back to an iPhone.

My favourite was the palm tungsten with the great screen and huge array of very useful applications. It never left my side. It wasn't a phone at all but it was a very practical PDA device. I admit I've been struggling to find a replacement as genuinely practical as that little device since.

The Treo 700w running Windows Mobile I found frustrating. The tiny screen did not allow the lengths that I took the Tungsten to with, for example, running spreadsheets and viewing the calendar showing handy icons (in a third party application). And the little keyboard took ages to learn effectively. I admit to reverting to Palm's hand writing characters as a preferred way of entering a reasonable amount of text.

When I got my first iPhone I was dismayed. I couldn't even find a spreadsheet - one of my most useful tools. There was no copy and paste which was screamingly annoying and it just didn't have the power and usefulness I was… well… used to. Then, surprisingly, over the next couple of months I grew to understand the iPhone. It wasn't trying to be a PC and it did have it's limitations, but accept that and you ended up with something, although not nearly as powerful as other systems I've used, was very practical all the same. The penny had dropped and I finally understood the iPhone.

The iPhone was supplied by the contract I was in at the time and when that was completed I handed that back.

The next contract supplied a Blackberry Bold 9000 as a standard device. Aha, I thought, back into the "blue suit" of devices. The Blackberry was the true workhorse. No time for nonsense like enjoyment. In my role controlling several development teams around the world and the fast push email processing I was getting emails all day and night. But the workhorse was solid and reliable ... Once I had ironed out the bugs.

Turns out that the very limited memory for applications meant that every application had to be specifically closed down or the memory would soon fill up. Filling up the memory would slow the system down so much the device would be totally unusable until you were able to either reset the Blackberry, or wait long enough for each painful command until you got to a point where you could shut down enough apps for the system to work again - and even then sometimes it still needed a reset.

This also prevented loading other applications so I was left with a pretty boring, yet (if I remembered to close each app regularly) a pretty effective one.

One feature with the Blackberry that took me a while to get used to was that it didn't have a touch screen. No stylus, no finger pointing, just a little trackball controlling a cross-hair cursor. I will taper this with the fact that I'm an experienced PDA user and was forever trying to "tap" a link rather than move the cross-hair to it and "select" the link. I never got used to that but passed it into a learning experience, like learning to drive an automatic without trying to depress the clutch; or learning to be a passenger without trying to use the brake pedal.

I did have a pretty major issue with it though. As I received so many emails that demanded my reply, I was annoyed to find that the Blackberry would "send me" every email I sent. In other words, not long after I fired off a quick reply I would receive another email. With so many emails coming in I would be forced to bring out the Blackberry again and check, only to find it was the email just sent and if I didn't open it to read it the Blackberry would forever show up that I had xx unread emails. Not something that endeared me to it after a while. I could not find a way around that issue.

Recently I had an opportunity to purchase another phone so I looked at all the offerings.  Having a long and enjoyable relationship with Palm products I really wanted to get the Palm Pre but it's still not available in Australia with no signs of it ever being released here.

I opted for the simplicity and sheer "nifty-ness" of the iPhone. The new 3Gs version was out here which answered a lot of my earlier issues. I am so far quite pleased with it. It's taken me a while to learn to type on it (all my recent blogs have been written on the iPhone and transferred to the PC for spelling and formatting. It keeps insisting to replace Aus words with their American spelling so I have to keep an eye on it. World domination ain't here yet people and we spell our words using S's and there’s no such thing as a Zee, they’re Zed’s

But back to the iPhone and I find that the number and power of apps has increased dramatically in the last year. Yes there is even a spreadsheet now and clunky as it is, I can use copy and paste at last. I enjoy the wireless connection meaning the huge amount of data I paid up front for, hardly gets used at all as the danged thing keeps finding home, work, and free wireless connections to use.

Below, a few screen dumps of some of my more favourite iPhone apps.

More on Cloud Computing

A few posts ago I spoke on attending a Cloud Computing seminar put on by NetSuite. Since then I have looked into this a little more and hope to dispel some of the misconceptions of Cloud Computing.

The idea sounds great, and it's certainly the buzzword of the week if we believe the hype.

"But hang on," I hear some of you saying, "Cloud Computing is just having apps on the Internet and we've had that for years. Why should it be different just because someone wanted to get their PhD by coming up with a new name for old technology?" ...and you'd be right in asking that, its a pretty legitimate question in my book.

Definition

So let's define Cloud Computing precisely, even more than we did in my post of a few days ago. To be considered a true Cloud Computing system, an application must satisfy all of the following criteria:

1. Application on the Internet. It must reside on the publically available Internet. Publically available does not mean anyone has access to your systems, you will still need to log in. Now there is such a thing as an Internal Cloud, and even a Private Cloud, but for the purposes of this paper I'm going to limit this to full public access applications. That is: externally hosted applications where you can use and store your information on the externally provided system (e.g. salesforce.com).
2. Data on the Internet. The data you place into it must reside on the Internet, although obviously it must also be secure so that only you have access to your Data.
3. No to little up-front costs. You are not purchasing software licences or additional hardware. Sometimes you may purchase consulting services to assist in converting your systems and data. In some extreme cases like perhaps a corporate wide accounting system, additional consulting and training may be necessary.
4. Nothing is installed on your computer apart from a web browser and perhaps some browser additions like adobe PDF viewer.
5. Costs are consumption based. In other words pricing is charged per hour; gigabyte; or hits per month. The less you use it the less it should cost you, and the reverse is also true.
6. On-demand. The service should, in its minimum configuration, be able to be set up by the user for use that day. Of course in very large and complex corporate systems this may take planning and often highly specialised consulting services.
7. Scalable. As far as the user is concerned they shouldn't have to worry about infrastructure at all. They should be able to increase from megabytes to terabyte throughput without having to organise storage or backups, extra staff, servers, or any of the other hassles.

Advantages of Cloud Computing

This definition of Cloud Computing shows up a number of areas of cost savings, reduced hassles, and sometimes increased functionality over in-house systems. These include:

• Costs can be avoided or deferred. In most cases, increasing both functionality and capacity should be totally transparent  process. No server purchases or increased IT management. The regular billing cycles of the Cloud Computing model allow businesses to accurately forecast their IT budget based on known consumption levels.
• Increases a business ability to change. The on-demand model inherent in Cloud Computing enables organisations to increase or decrease computing capacity without hardware, or IT management concerns resulting in no lag time while IT management orders the new hardware; installs the appropriate drivers; sets up the new cabling; tests the newly raided disks; increases the tape backup facilities; increases rack space; sets up active directory; and all the project work that comes with installing new capacity. The ability to then, just as quickly reduce that capacity without worrying about costly hardware lying idle is one compelling reason for the Cloud Computing model.
• Faster ROI. The Cloud Computing model allows businesses to pay for only the resources it consumes and only as it consumes them. Businesses are able to see a faster return on their IT investment because there is no need to wait for the resources to be procured, provisioned, and managed.
• Increased mobile workforce access. Your users will be able to access required business functionality without the overhead of network hardware, VPN software, and network management. Users will also be able to access their applications and data while at home, on the road, or in the office from any computer. Some Cloud Computing vendors (some through third party software vendors) allow access via mobile devices like the Blackberry or iPhone.
• Additional expert IT staff. Highly-skilled professionals are available through the Cloud Computing SaaS (Software as a Service) company to operate and maintain their (your) service.
• Increases business continuity by providing inexpensive disaster recovery options:. In some cases, cloud computing can be utilized as a viable disaster recovery option—especially for storage—thereby increasing business continuity.

On the definition of Cloud Computing given in the last section, businesses and individuals should never be concerned about backups, infrastructure, server space, firewalls, upgrades, storage, daily security patches or any of the plethora of other things that are nothing to do with running their business.

In summary, the ROI (return on investment) should be greater without the large up-front costs of infrastructure; software purchase and installation; and the manpower costs to manage it all. The infrastructure changes need no longer be a concern of the business allowing for both business growth and business reduction to occur without the penalty of either time lag and up front purchases or costly redundant and idle hardware. Also, business can plan their financial outlay with known, regular payments rather than up front large purchases.

It is also the nature of some businesses that sometimes additional infrastructure and computing power may be needed for short periods of time. Cloud Computing will be able to accommodate these bursts without the huge infrastructure and set up time costs required for something that will not be needed after the task has been completed.

Pitfalls

All of this of course sounds like a utopian situation but to the consumer there are pitfalls that they should take into consideration before embarking down that path. These can be summarized as the following:

• Be sure of the SLAs. It is up to the consumer to be happy that the SLA will cover their requirements and that they can survive any unforeseen downtime or lack of service. Of course this downtime may also occur even when they have the best server rooms and the best of staff so normal disaster management plans should always be in place anyway.
• Consider the SLA that you provide to your customers. Will holding their data off-line hold up if a customer questions an SLA they hold with you?  This is often overlooked in the rush for the savings and ease of adopting Cloud Computing.
• Vendor lock-in. Will the provider allow you to access your data and how soon can they get it to you if you ask for it? Will they work with another provider to transfer your data if you ask for it? How easy will it be to transfer? Even if you could download your data, will it be accessible to you or will it be in a proprietary format only available from the provider?
• How secure is your data from other eyes. It is possible that your closest competitor is, or will in the future be, using the same service that you are using and perhaps even shared resources. How will you know if your data has been stolen or hacked? Perhaps one way is to review the audit trail - if there is one. This may be able to let you know if someone is using an old forgotten login to access your data or if someone is having too much access that should be investigated (it may be a very valued employee so care must be taken as others may have obtained their login). How can you tell if a sysadmin has copied your data? What security is in place at the SaaS provider to ensure this does not happen? Are they open to an external audit of their security?
• Backups. What backups are taken? If your data is found to be corrupt, how far back can you go to obtain valid data?
• Deleted data. If you permanently remove some sensitive information, has it truly been removed? On what other systems has it been stored?
• Can you download your own data? Even if you can, will you ever be able to access it or is it in a proprietary format only available from your provider?
• Security. Many companies don't even know how many computers connect to their data now, or what data reside on those computers and how and when they are accessed.

None of these items should stop you investigating Cloud Computing for your own organisation, however you should not abdicate your responsibilities to a third party provider. It is your data and your business that you are dealing with. It is up to you to not only obtain the cost savings that might ensure a good profitable business model for your company (or your employer's company), but to ensure business continuity in the event of the unforeseen.

Many nay-sayers cite a few instances of data corruption or downtimes, however these must be put into perspective of supplying the service in-house. If an external audit was performed on your current in-house systems, would it pass muster? Have you complete security that your systems are safe and up to date with all patches? Do you know (I mean really know) who access your data now? If you had a disaster or fire on your premises that totally destroyed your server room and office, from an IT perspective would your business survive?

Although Cloud Computing has been around for a number of years, only recently under that name, it is still seemingly in its infancy. The take-up has not been rapid in some cases. While customers can hand over CRM and email systems to the Cloud, handing over the full enterprise system to the Cloud may be a little hard for most of us right now.

Problem Resolution or Project Resolution?

Several years ago a large government department IT section was in almost total stasis with every person desperately running in circles at 110% capacity every day but nothing could be accomplished.

Each person would come to work each day and arrive to problem after problem as management wanted this or that done urgently and a plethora of every day issues like simple user requests kept the IT staff occupied.

It wasn't until the end of the day came and the staff crept away for the night before they were called to another crisis, that they realized that yet again, nothing tangible was accomplished.

I was hired as the process and change consultant to come in and, along with other things, find a way to get things done.

I was there for a number of months trying to find a way around this issue. I had other work which kept me occupied as I oversaw a large project so I wasn't simply sitting in an office (sadly, I'd like one of those jobs sometime ... or maybe not).

At first I looked at the normal things like task management and priority and while this gave a little more clarity, it still didn't resolve the main problem of too few hours in the day. I looked at the logic of hiring more people but already this team was larger than most other IT departments for the size of the department.

I tried several other "normal" and quite logical practices but this government department were set in their ways of abusing the IT staff, and in turn the IT staff were too used to stamping fires.
I was reminded of a saying as I explained the issue to a colleague one time: "sometimes, when you're fighting back crocodiles, it's hard to remember that the purpose of the exercise is to drain the swamp".
It was then that I came up with a fairly drastic idea. I worked evenings and weekends over the next few weeks to fully document my plan. At last I took it to the executive for approval and was pleased to get an OK with their full support.

Over the next few months the IT department were able to implement several major installations and other changes. Yes there were still the same number of problems coming up each day but now, despite these every day issues, major projects were being completed.

What I proposed and implemented was nothing less than a total change in the structure of the IS department. Almost every person had a change in their title and job spec. It was drastic indeed but it worked.

I changed the title of the teams to ""xx Project Team", I changed the titles of the team leaders to "Project Managers", and the team members to "Project Support" or "Technical Project Support".
So why would changing someone's title make that much of a change to the way they work? As it turns out, there are several reasons. Firstly it gives them an amount of empowerment over their work. They now feel that they themselves can make decisions on how they prioritize their tasks.

Secondly they now have a focus. No longer are they coming to work to answer phone calls and being pushed and pulled in every direction. Their direction is clear - the project!

By changing their titles and focusing them on project work they can still "stamp fires" as they occur but now can choose which fires need their immediate attention and which can be left to another time while they concentrate on the all important project.

These people were well qualified and good at what they did, it was just that they had allowed themselves to be rag dolls being pushed and pulled from one event to another and it wasn't until now that they felt any sort of control at all. It didn't matter what a so called "expert" said to them or what procedures he wanted them to do, they never felt they had enough control over what they did to even attempt to follow them. By changing their focus to project work, I had given them that control.

So next time you and your team feel harasses and finding it difficult to get things done, ask yourself if you are out to resolve problems, or projects. Look at the longer term.

It has been said that there are two types of team leaders: one would take their team into the forest and by support, moral-boosting and excellent project control, would cut down the most trees in a day; the other would arrive at the location, then climb the tree to look around, come down and say "guys, we're in the wrong forest we'll need to move before we cut down any trees".

Think about it, plan, and know you're delivering to the correct goals.

Mind Mapping

I have been using mind mapping software for many years now and it has often been a great boost to get clarity around thought.
I know that I've often been told that my mind needs a map to get around and I've agreed with them. I know I  think the same way everyone else does. Do you memorize your phone number by turning it into a complex calculation? Of course you do and my wife's statements that I'm somehow different is just well, silly.
But back to mind maps.
I have a copy MindJet on my computer at home and pull it out occasionally to help me formulate some thoughts. Often this results in only a half a dozen links before I know where I'm going with my thoughts and can take it up from there. Sometimes it takes a very large map that I export to an outlined document where I can fully document the thoughts that are now concisely laid out before me.
However it wasn't until I started using mind mapping on my iPhone that real map production became a reality. Now I can take those ideas and problems that arise during the work day and map them out on the train ride home. Next morning I can export all of those linked thoughts into an outline document and produce my paper.
I've tried several systems on the iPhone from a straight outliner (CarbonFin Outliner) to specific mind mapping programs. There is no doubts on my favourite for the iPhone and that's MindNode. This is a simple clean interface that's good for all you can and need to do on an iPhone while sitting on a moving train. I love the fact that the points are not boxed (which to me, makes them harder to read) and each base node is a separate colour. I can even choose sub nodes to be different colours as well.
The ease of transferring the maps to my computer is as simple as selecting to email them (to myself) as an attachment. I have the choice then of several formats including graphics, as an outline document or one of a few standard formats other mind mapping software recognizes.
The only down side is that so far there is no way I can then copy maps back onto the iPhone unless I have an apple computer (which I don't). They say they are working on it and I hope so because this is a very powerful business function for the iPhone.
While I'm at it, why did I choose the iPhone? I've used the Psion, a PalmPilot, a Windows Mobile phone and the Blackberry. All work very well but I just like the simple nature and use I'd the iPhone. If I could I'd have perhaps gone with the Palm Pre but it is yet to be seen in Australia so I opted for the iPhone and so far, apart from the short battery time, quite enjoying it.

Cloud Computing

I went along to a cloud computing seminar last week to see what the fuss was all about.

Cloud computing is a term bandied about a lot in recent times and I really didn't fully understand what it was. When NetSuite put on a free seminar, that is to say; "a free sales pitch", I took the opportunity to go along and learn more about it.

I'm not putting down a supplier who would put on such a seminar, in fact I applaud it. It is a good way to learn the different technologies. However as in all such cases, we must weigh what we learn knowing that a fair bit of sales pitch comes along with the facts. This case was no exception to that rule.

So what's all the fuss about cloud computing? Well, it turns out not much at all … and a whole lot, it depends on your perspective.
Cloud computing is the name given to the industry springing up around hosting applications and data on the Internet (the cloud). The idea is that it allows a company to get away with just having the laptop or desktop PCs with no need for servers or the infrastructure normally required to support them. All email, scheduling, accounting and all other company software will be a matter of simply accessing the Internet.

Gmail is a good example of Cloud Computing where the small business can leave all their email details up to Gmail. No in house mail servers; everyone is automatically using the latest software; no backup issues; and no need for an administrator to keep it all protected and current.

The seminar hosted a few guest speakers who had moved all their corporate accounting to the Cloud (by sheer coincidence, NetSuite products - who would have known). It was interesting hearing first hand how they were able to make the change. I was especially interested to hear one company who had international offices and international currency issues and yet still made a successful change to Cloud Computing.

The only part of the evening that really annoyed me was hearing  Zach Nelson, CEO of NetSuite repeat often his favourite saying "why would anyone want to use applications designed before the Internet?". Zach repeated this several times and was obviously very proud of this saying but all it did for me was succeeded in getting my goat. Often applications are not built on the Cloud because of serious reasons. They may be very forward thinking applications that have some serious non-Internet uses. To me Zach Nelson's unfortunate comment displayed his ignorance of the wider business requirements and showed a very narrow view of the world. I will taper this a little though as his view as a Cloud Computing supplier with server based corporate software as his competition, he will naturally be narrow in his outlook.

There are no doubts in my mind that Cloud Computing will have a large future and it will be interesting to watch how fast the take-up will happen.

Sydney This Time

The photo was taken on my iPhone from our apartment towards the Blue Mountains one evening.

Here we go again. I'm really looking forward to buying a house and settling down in one place again. A luxury that has been out of our grasps for a while now.

After a great year in Melbourne we've moved again, this time to Sydney.

I've taken on a position as Product Manager for a spatial data (mapping) company in North Sydney. It's an interesting position and one that has enough challenges that will keep my interest and allow me to learn heaps. It is the first role I've takenon in many years that does not have a team, the last role had a team of around 40 people based all around the world so this will be a little different.

I'm looking into some exciting technologies and some interesting discussions which I hope to write about soon. The last year has been so disruptive that this blog has suffered from lack of postings, a situation that I hope to rectify in the coming months.

My interests reside in technologies that help companies and people, in leadership, and in company management so if you have something that you want me to look at, or simply want to meet up sometime and you live in Sydney, then drop me an email (from my profile section) and I'd love to talk to you.

Even Programmers need to Communicate

Few programming teams that I have met really understand how important communication is to their everyday lives. Let me yell this from the highest places I can find - Communication is the most important factor a software team can possess, above technical abilities, above delivery, above project work, above code itself. Without communication, a programming team can die.

Take two hypothetical programming teams, one is extremely effective and highly knowledgeable and technical. This team can deliver programs on time and on budget at every opportunity, have a repertoire of current programming languages and skills, and can understand and deliver highly complex applications. However, this team has no communication skills.

The second team has only ever used a single 4GL language, have no technical knowledge outside of their areas and couldn’t hit a delivery target if it was painted on the side of a building in big bold bright neon colours. This team however works hard at communication.

Now let’s put this in terms understood in today’s financial restraints – Which team would be open to being outsourced?

The answer would be the first team. Without communication, this team are “perceived” by management and other departments as a cost to the company and full of Prima Donna programmers who don’t offer any service to the company to justify their (perception) huge salaries.

The second group however are perceived by management as a hard working and loyal group of technically brilliant people that the company simply cannot do without.

Development teams must be able to explain what they are doing, why they are doing it, the value they give to the company, and why that value should be maintained. But we are talking about a bunch of programmers here. By pure definition these people communicate with one’s and zero’s not with other living organisms.

I’ll draw on my own experience to give you a real life example of the changes that communication can give to a programming team.

Many years ago, I was appointed as development Manager to a team of programmers. During the interview process, this team had been described to me as unable to achieve any targets. Production was down and the team was not viewed as a valued asset to the company. It was generally accepted that the team would be outsourced within the next 6 months and I would then move into IT Manager’s role (due to be vacated).

The first few days on the job, I observed what was happening. Every 30 minutes or so, a different department manager would come into the development area and talk directly to one of the developers and demand they drop what they were doing and work on their project as it was needed yesterday. The programmer would dutifully drop their current workload and take up the task demanded of him by that manager.

No wonder the programmers had a bad name - they could never finish anything because they were constantly being shifted to working on something else. Every manager thought the programmers had to be forced to work on their material otherwise they’d never get their project out.

The programmers also complained about their workload telling me they needed to at least double the team to keep up with their work.

I looked at the code and the projects these developers worked on and spoke to them about their work. It quickly became apparent that the skill level was extremely high but the moral was at an all time low. I concluded that their only fault was their communication so I set about correcting this and became the mouthpiece of the Development Team.

There were several things I did immediately which had a huge impact. The first was to put into place a job request form. This was originally a simple paper based form allowing users to enter the details of their project on a paper that had a unique job number. This job number was kept by the internal customer to refer to their request.

For the first time, programmers were then able to prioritise their work. They were also able to see what work was ahead of them. By having all their work available on the desk in front of them, they could tell the internal customer that their job would be due to be completed at a particular date.

I also spoke individually to those customers who filled out the form, explaining the work request form giving them confidence that their project was now in the “system” and that the work was now prioritised and a date for delivery was now available. This meant that customers were much less likely to come in and speak directly to the programmer unless their project was late.

Meaning the programmer could concentrate on completing that one task without interruption - new requests could be referred to the job request and any member of the team could take over this discussion. Jobs were actually getting completed.

Now we had the process in place, I concentrated on communication. It was then my job to support the team by educating everyone on this new process and how to use it to their advantage. I wrote up a development process document and created one-on-one meetings with each of the departmental managers throughout the company. There I showed them through the process and effectively “Sold” the process to them. I also added a “Software Development” column to the company fortnightly newsletter and added the Software Development department to the list of those giving a talk to new employees during their induction. This had the added side effect of being seen by other managers who came along to the induction process for their talk.

I then started talking directly to the CEO (Chief Executive Officer). I told him what was happening to the Software Development Department and what applications we built and look after in his organisation.

Within six months, this department went from being a bunch of dead-beats who were due to be outsourced, to being the only IT department that was confirmed too valuable to be outsourced. The CEO started placing Software Development on his rounds when showing visiting VIPs through the company and the main software packages we wrote and supported were being highlighted as great achievements for the company. Eventually the CEO, in his monthly report, stated that all of the company should look towards the Software Development Department as an example of what a well run department should look like.

So for the matter of a few processes and some effective COMMUNICATION, this team went from a dead weight and an unwanted “cost” to the company, to taking pride of place within the corporate environment.

So yes, even programmers need communication. Few programmers have that ability to communicate effectively. That is their nature in that the skills of a really good developer are in understanding code and code flow, and to understanding the user’s requirements and delivering to them, not in the areas of marketing and communication. It is up to those supporting the team - the Development Manager, the Team Leader, or the Project Manager - to take up this task of communication.

So Many Things, So Little Time

It has been a very interesting past 6 months or so. I'm now settled in my role in Melbourne as Development Manager for a good sized company here with offices in many countries around the world. It was not the original role that I came over here for, but this time it looks very good.

It will take me time to put some plans into fruition here but the company is strong and the people who work here are wonderful, both technically and socially. I've got to say that this will be a very enjoyable and hopefully long term stay.

The methodologies that I have seen working in this organisation range from close to waterfall right through to a form of Scrum, or even sweat room style. All have their places and all work very well for the teams involved. It will not be an easy task to combine all the teams, globally under a single methodology or even if I would ever want to. However I will need to combine them into a single company-wide toolset and supporting structures and increase their visibility to the rest of the company and their needs.

I have been working on the organisation chart and gaining a feel for the way information flows and how things are done. I've yet to concentrate too much on the other offices but have already expressed that I'll need to get to the European offices in the next few months to meet everyone and spend some time with them.

Our furniture has finally arrived from New Zealand and we are now settled with schools, church, and other necessities all now sorted.

I'll try to revive and update this blog reasonably regularly over the following few months. In the meantime I hope this finds you all well and able to survive the current economic uncertainty.