Month: January 2017

You have just met an architect, let’s call him Bill. Bill works on the design of a new skyscraper, he has the designs approved and funding awarded. He gets straight to work and builds the most beautiful building in town. Immediately after he destroys the building having met his goal of building the most beautiful structure in town.

What do you think of Bills behaviour?

Crazy?

Well, tech organisations do this kind of stunts all the time. They put in massive resources to build a team that will work on a project, once the project is done the team is disbanded and assigned to different projects. This is a massive waste of time, money and human capital.

In this entry, we are going to be discussing how this happens and why it is so costly to your organisation.

How do teams form?

A group of people does not become a team because you call them a team. In fact, Jon Katzenbach and Douglas Smith in Wisdom of teams argue that teams go through 5 distinctive stages:

The team members have just been assigned to start working together. Being human and thus social creatures, they spent a good amount of time studying each other personalities.

The members have discovered differences in how they work. This points of difference become fertile ground for blame games. If you are lucky the members move past this stage.

The team has started experiencing some success working together, points of synergy have been found and exploited. They are actually starting to like each other more and leaning on their own judgment rather than the team leads.

The team is now performing at optimum. At this point, we can confidently say your team has jelled.

This is not necessarily a linear process or even a four-day process, rather an iterative process that the team members work through to get their stride.

Why should you care about having a strong team?

You may be thinking “Chencha, this is a self-evident truth, just get on with it?”. You would be wrong. Cooperation can be achieved successfully without going through the trouble of forming a team. In fact, this happens all the time. Think about your trip to work this morning, if you drove, then you had to cooperate with all the other drivers to ensure a safe trip.

Real teams matter the most where you need the sum to be greater than the parts. Companies whose primary work is innovation need teams.

Peer pressure is far more effective than the concept of a boss and much more powerful

Therein lies the power of teams. Organisational goals tend to be abstract and far removed from the everyday lives of the team members. Millions of years of evolution, however, guarantees that each member cares a lot about the other members.

Evoking this old instinct means that the team will serve the goals of their “tribe” loyalty. When this happens, the chances of success dramatically shoot up.

So then how am I destroying teams?

For consultancy firms, projects have finite timelines. At the end of the project, the default action is to disband the team and allocate them to different projects. The other option would be to keep them on the same team but with some downtime as you wait for the next project to come. This does not reflect quite well in your financials.

Yet, I firmly believe that it is better for a jelled team to have some downtime than to incur the cost of growing a whole new jelled team just to serve a new project.

My former boss always said, “When it comes to it, I would rather be loyal to my employees than to my clients”.

If your business relies on developers for its success, you are worried about losing some of your best within the next year. If you are not, you should be, the turnover rate is surprisingly high.

In an industry where anyone of your employees can become a competitor with virtually zero cash investment, to begin with, you best find a way to build loyalty.

In a previous entry, we talked about some of the things that you may be doing to demotivate your developers and how to fix it. In this entry, we will be seeing how to be more proactive in motivating your tech workforce.

Build shared purpose

In 1995, Stephen Hawkings came up with a rather colorful description of the human race.

The human race is just a chemical scum on a moderate-sized planet, orbiting around a very average star in the outer suburb of one among a hundred billion galaxies. We are so insignificant that I can't believe the whole universe exists for our benefit. That would be like saying that you would disappear if I closed my eyes.

The universe is large and for the most part doesn’t care about us. John Truant explains the concept further on his own blog. Crucially, he highlights the fact that we have to create meaning for our own lives.

Your greatest developers are acutely aware of how short life is. They want to do something meaningful with their life. Luckily, at this moment, they are working for your business, their passion and zest is thus available to you. Your task is to continually reflect the meaning of their work to them.

Are you providing medical care to the poorest of the poor? Take some of your techies to the ground. Are you streamlining government operations? Let your techies see the appreciation of your countrymen as they get service in minutes that would have taken weeks.

Let them make and own their decisions

Command and control as a strategy is just not feasible for a tech company.

All you need are people with good judgement in other parts of their lives who care about you and will give you their honest opinion with no strings attached

Becoming a master software engineer is hard, even getting to a decent level requires a great amount of skill and effort. If on your staff you have someone who has achieved this status, they should get bonus points for resilience, patience and self-drive. In short, all the qualities you want in a good decision maker.

By providing only the higher objectives of the product or the business and letting the team hash it out. You will be pleasantly shocked at the novel ways that will come up with.

Provide time, space and resources to grow

I find it ironic that some companies will invest in expensive gaming equipment for the office but find conference costs to be wasteful. Even worse are organizations that give a ton of lip service to growth but provide no means of making this possible.

A while ago, I tried writing out an application using one of my favorite frameworks, Laravel. Shamefully, I no longer write as much code as I used to. The last time I wrote a production level app, Laravel was in version 5.2. At the time I was trying to write out my application, Laravel was at version 5.3. This should be easy peasy, right? Wrong! The entire framework had pretty much changed. Even the underlying language, PHP, has changed from PHP5 to PHP7! The migration doc qualifies as a mini-book!

The point is that technology tools and processes change really quickly. Thankfully the change is mostly for good. You want to harness this change to serve your customers better.

You must then provide your developers with the time they need to learn new technologies. As they are learning them, you must allow them the space to experiment.