Don’t Procrastinate

It’s always easy to leave things for later, but the consequences are almost always bad. Usually, there is no logical reason to defer anything, starting with simple things such as paying your bills, and ending with dealing with your project’s problems. They won’t just get solved by themselves, they are only going to get worse as time passes. What is more, there are for sure some people relying on you and waiting for you to finish, in order to be able to do their job. You owe these people to get your job done as soon and as well as you can.

Respect Your People

They’ve made it to this team thanks to their qualities and strengths. They have developed into experienced professionals, or they are just taking the first steps. Anyhow, they are the ones directly helping you do your job, and respect is one of the key factors in any good relationship.

Trust Them

There are two kinds of people. The ones thinking that trust is to be earned, and the others who trust people from the beginning, only to lose it if they get let down. I personally belong to the latter, but I find worth mentioning that trusting someone doesn’t mean being naive. You still have deadlines to meet, you still have to make sure your team is producing quality work, so there is a very thin line between being trusting and being too loose.

Don’t Lose Control

There is an old saying: Trust is good, control is better. You may be shocked to find out it belongs to no other than Joseph Stalin, but I consider this only proves that even villains can be pretty wise from time to time. Even if you are lucky to have competent people in your team, you still have to find non-intrusive ways of keeping track of your schedules and commitments. Thinking about that fine line again…

Don’t Micromanage

While being confronted with stressful situations or tight commitments, you can easily turn into a control freak. You may feel the need to know every aspect, every detail, in order to be able to have everything under control. Humans however, are not that “multi-threaded”, so they need to surround themselves with trustworthy and skilled people who they can rely on, rather than trying to squeeze every bit of information into their 20%-used brain.

Listen and Make Sure They Listen to You

You want to be constantly aware of your people’s needs and problems, while making sure they know your expectations. You have every reason in the world to be attentive while in meetings with your fellow leaders and managers, but also to be able to leave relieved that they all know your team’s status or your personal points of view, when the meeting is over. Finding the right ways to communicate is therefore crucial, and yet so different from one situation to another.

Never Wait

Leaders aren’t waiting, they’re acting. Being reactive, or even worse – passive, isn’t part of a leader’s job description. A good way to tell if you are being proactive enough is to ask yourself this question: Usually, when my manager asks me something, do I know the answer on the spot, or do I have to find it out? If you are always being told what to do, you probably aren’t much of a leader after all.

Be What You Want Them to Be

Being a leader means heaving people follow you. But if they find you worthy in any way, they will also borrow from your way of being, more or less consciously. Your behavior is therefore crucially determinative for their own, so unless you don’t want to be surrounded by jerks, make sure you’re not one. Unfortunately, negative behaviors are easy to imitate, but the good news is, positive things are also quite catchy.

For years I have relied on different reports, pie-charts and graphs for tracking my team’s progress, as well as my own. I had filters for the tasks which were in progress, for the ones overdue, and for the ones assigned to myself. I had pie-charts rendering the bug count for each of the guys in my team, and also for each product component (architecture-wise). I used a graph that was telling me how many issues were created, in contrast to how many were resolved over a period of time.

But why…

Well, I guess we were driven to this kind of management by the way we used to work.
Our teams were built around the omniscient Team Lead figure, the one who had all the answers to any question, from anyone – “above” or “below”; the one who was reporting, and was being reported to. Each developer was focused on his or her components, not “needing” too much knowledge of others’, so the lead was playing a key role in keeping things together and working. Testing was perceived as a somewhat external job, as there was a completely separate team for that, with their own schedule, and their own way of doing things. The developers pretty much thought their job done as soon as the product of their work was delivered to the testers.
You have probably figured out by now, that the team leads had all the reasons in the world to make sure that they were aware of the detailed status, problems, and interdependencies with other teams, while still struggling to avoid doing micromanagement. Tough job.

This is exactly why we had to change something.

And we did. After countless attempts to correctly understand and adopt the Agile practices and principles, after reading many books, attending some conferences and trainings, and after having failed so many times, we have now finally come to a point where we’re doing things much different than before.

The all-knowing team leads turned into trusting scrum masters, relying on their people, who now need to work closely together to get the job done. The teams are now composed of both developers and testers, so everybody finally got on the same page. We don’t develop anything that can’t be tested right away, developers receive useful input from the testers just from the analysis and design phase, basically everyone works together from the start ’till the end. This doesn’t only happen inside a team, but to some extent, throughout the entire “big” team.

I still have my reports and pie charts, but I don’t recall when I’ve last checked any of them. Instead, we all use a continuously updated Burndown Chart. Not only it tells us how much work we have done, but most importantly, it tells how much we have left to do until we’re done. This also means that we can use it to tell whether we are able to finish everything we’ve planned, and also, what we are going to get done by the end of the sprint. Combined with the task board, containing cards for what’s to do, in progress and what is done, we’ve got all the information we need.

If anybody asks about progress, problems or status, anyone in the team can answer, because we’re all together in this. We are all estimating, planning, reestimating when needed, together, so we all know and care about what’s happening anytime.

And it’s all in one single chart.

In a sane working environment, everyone seeks consense whenever decisions are to be taken, whether on minor or important matters. It is desirable for everyone involved to feel ok with the future plans, as it really helps not only for people’s morale, but also for getting things done.

Humans tend to be good at what they do if they do something they like. There are however cases when correct decisions can only be taken on – if you will – scientific grounds rather than their popularity. Consider, for example, the architectural redesign of a pretty large software application, which had evolved year to year into something difficult to debug, develop, or even understand. You will most probably organize technical meetings with the right people (not too many!), in order to figure out a solution. In those meetings, there is a significant possibility of rather different views to take shape. In such times, the handy approach would be to select the solution by voting, but it would be much preferable to do it by weighing the advantages and disadvantages of each alternative.

It may not please some for the moment, but in the long run, everyone will be happy to benefit from a wise, however not popular, decision.

Building a strong team usually relies on finding skilled people you can trust, each one of them bringing value to the whole, by their personal, unique strenghts and qualities. Once you succeed in this, it’s up to you to take the challenge of offering them the opportunities to develop their skills, enabling them to become trustful experts which you will always rely on, when being asked for estimations, plans or just plain technical oppinions.

In this context, thinking of them as replaceable only makes you set an artifficial barrier on the way of their personal and the team’s evolution. The only replaceable one should be you, as achieving this translates into a powerful, self-organizing and tightly bound team. You don’t have to be afraid of this, because your company will most probably see it as an act of performance; and if they don’t, you wouldn’t probably want to work there anyway. Also, it’s nice to know you can take a one-week holiday once in a while, and when you come back things wouldn’t be a mess.

People usually like taking challenges, so empowering them to do things a little beyond their current knowledge will only help them develop. No proffesional would like to do the same well-known things every day, so by offering them tasks that require study, prototyping or exchange of knowledge with senior colleagues would usually motivate them in their work, so it’s a win-win situation.

Letting your people know about their value should make them feel more responsible for what they do. Still, remember to avoid establishing an environment where everyone tends to be a “star”. Try to create a Star Team rather than a team of stars, by encouraging them to collaborate rather than compete. They need to understand that they all need each other in order to succeed.

When you are fair to your people, they are fair to you in return. This enables them to benefit of evaluations, and improve their skills by taking your positive or negative feedback as useful input in their own development. It is therefore up to you to provide them useful information about their actions, and not theirselves - you don’t want to change them, you want to help them act as needed.

Having the right pieces, sometimes unfortunately means parting with the people that don’t “fit” in the picture you and the others are part of. If there is nothing you can do any more to help a person be on the “right” track, it is in everybody’s interest that he/she moved on. This doesn’t necessarily mean firing them, as you could help them find their place in another team in the company. However, it’s good to keep in mind that negative influences spread quickly, but so do positive ones.

Title picture © Ilya Postnikov | Dreamstime.com

Mark was feeling worse, as the cold was taking over him. This was a somewhat new experience to him, as he had always been so healthy that it was really hard to even remember when he’d last felt that way. But his condition got pretty bad, so he picked up the Yellow Pages from the top of his nightstand and looked for a doctor. Although it was late in the evening, he found this very kind Dr. Harris who came right to his appartment and, after having him examined, prescribed him Darvon, 2 tablets each day, for his coughing problem.

As he was finally getting better, Mark could now go to work. But during his week off, a decent amount of files, one more urgent than the other, piled up his desk. He was really doing his best but he was still having a hard time sleeping every night due to the great deal of responsibilty that was screaming in his ears all the time. There came a time when, combined with his coughing problem, the situation became unbearable, so he had to do something to be able to sleep. He remembered his friend Andy, who used to take Diazepam for the same problem, so the next day he met Andy during lunch time and got a few tablets from him.

He could finally sleep. His cold was also getting better, and he was catching up with the unfinished work at the office. Things were looking better for Mark, until one day when he died in his sleep.

The authopsy revealed, not surprisingly, significant amounts of Dextropropoxyphene and Valium in his blood, which – taken in decent amounts – are not dangerous for the human body; hovever, when combined, they can usually cause allergic reactions and, to the least fortunate, even death.

Communication is one of the key factors that drive teams towards their goals, making possible the exchange of ideas, plans or problems. It is therefore crucial to do it efficiently, while keeping in mind that you’re still talking to humans and not some kind of information processing machines.

It is therefore essential to choose your media wisely according to each situation, but to my experience so far, nothing compares, in terms of efficiency, to just saying out loud what you have to say. Emails may be useful for storing decisions or ideas, but it’s by live talking that you can transmit them in the best way.

Personally, whenever I need to discuss something with my team, I always prefer talking to them rather than exchanging emails or leaving offline messages on their IM accounts. I do write emails on important matters, but mostly aiming to archive the discussions for later reference, or when they involve many people which may not be in the same office or on the same schedule.

Title picture © Ghubonamin | Dreamstime.com

Change is one of most people’s greatest fears, and therefore introducing it usually meets significant resistance. We all tend to stick to what we know, as we usually get quite good at what we’re used to do. Thus, when being faced to important changes in our lives, work or habbits, we will most probably react by trying to reject them, unless we really understand the benefits.

This is why, whenever you need to introduce new concepts, technologies, or working styles to the people you are working with, you need to ask yourself “what’s in it for them?”, as you can bet they will all ask themselves the same question in their own minds. If you are really lucky, they’ll even say it out loud.

Even if they didn’t, it’s still fair to ask yourself this question, as you wouldn’t want to introduce something that brings them nothing useful, you wouldn’t want to do the change just for the sake of it. It’s up to you to take the challenge of finding the fair arguments that will make them understand the benefits of walking a new way, rather than accept a decision.

Title picture © Ilya Genkin | Dreamstime.com

Between October 26 and 30 – 2008, I’ve been fortunate to attend the Software Development Best Practices Conference in Boston MA. Apart from the opportunity of listening and free talking to people like Ken Schwaber, Bjarne Stroustrup, Mike Cohn or Scott Ambler, it has been a great time to visit a very beautiful city.

Communication is part of our every-day life, it is the key to all our relationships, personal or business, good or bad. In a high speed society like the one we live in, we tend to overlook the importance of words, spoken or written, therefore being misunderstood by our interlocutors. Hi-tech environments like IT companies, where we are mostly used to “talk” to machines by giving them clear and brief commands, expecting immediate action and answers in return, may sometimes make us forget that this doesn’t always work for people, who have feelings, beliefs, backgrounds and perceptions different from our own.

It is therefore essential to communicate not only efficiently, but also “humanly”. This latter notion involves respect and care for the others’ oppinions, beliefs and efforts, values that make or break, by presence or absence, relationships, friendships and teams. When you really believe in these values, you come to realise, more or less consciously, that there are some words that you might want to avoid when talking to your mates.

Must

You are a free person, so there is nothing that you must do. If your boss tells you otherwise, it is only because he’s not willing to take the time to explain to you why it is better, for you and everybody else that relies on you, to take those actions. It is much easier to tell people what to do then explaining them why to do it, taking advantage of a position.

You may say that there are still things that you must do, whether you want to or not. Like, for example, paying your taxes. If you think deeper, you will realise that you are in fact weighing the impact of different situations in which you land if you take one or another decision. As a rational being, you will then do what is better (or less bad) for you, but you still don’t have to do it. You’re doing it because you chose to.

Fault

When something goes wrong, the first thing that comes to your subconciousness is to make sure that you’re not “guilty”, and the easiest way to achieve this is by pointing fingers and passing the blame. Good news is, that you don’t need to do that when you are part of a team. There is no such thing as “fault”, “best” or “most” in a team. Responsibility, success, failure and difficulties are shared by all members, acting as one single bigger force which overcomes everything much easier than you alone.

Impersonal Passive Voice

How often have you read e-mails or heard news saying that “this and that has been decided”, or “has been done”? Have you ever asked yourself how come these things have just happened? Did they just occur by themselves, do they have a mind of their own so that they can take decisions by themselves? Why aren’t the people who have decided or done them, able to take responsibility for their own actions?

It is what it is

When things go really wrong, after there is nobody left to blame, and nothing obvious left to be done, people just say that “it is what it is”. Bad news is, that it’s not what it is, but what you made it. There are no dead ends and unsolvable problems, but there are people without the will to fight further.

I did my job

You might be one of those who finish things faster than the rest, and do them very well. Still, the project is falling behind schedule and it is likely to even fail completely if things go on like they did so far. It is the time for you to chose to be a superstar or a helping hand. Winners usually take the second choice, because there are no personal victories in a team sport.

Title picture © Aleksandr Stikhin | Dreamstime.com

Xerox-boy

Matt used to be an appreciated developer at his previous job, but now he succeeded to join a much bigger software company, one which he and all his friends had always admired. His new colleagues started to trust him also, so he was assigned with creating one new plugin for their application. They were even so nice to show him other plugins’ source code, and explain him how they worked by means of code samples. In one week’s time, he got it all woriking well, but when his code was reviewed, this came out:

/*
* class CGuiSettingsPlugin
* Manages settings for the Graphical User Interface
*/
class CCommunicationSettingsPlugin
{
…
} 

He is now known as “Xerox-boy”.

As a developer, you are often faced with the situation of creating software components very similar to others, in terms of structure and behaviour. In those times, the easiest approach is to simply copy entire functions, classes, or even source code files and do some changes here-and-there. This habbit, however, has several darker sides which usually strike back sooner or later, one way or another.

Why Copy and Paste? 

Because it’s easy. Why rethink an architecture, why bother to try and convince the managers that the (proper) changes would take more time, why even bother when you can just copy that class, change its name and slightly modify one single member function? It has already worked for you so many times before, so it’s pretty much supposed to work this time too… after all, you are just duplicating something that’s already working.

Because others also did it before you. You are faced with adding a new branch to a decisional “switch”, that already contains 30 other alternative cases. You’re not supposed to change the whole logic right now, are you?

Wrong

Nobody said it was gonna be easy, and after all, it’s not always necessarily supposed to be. There are times in products’ lifecycles when architectures need to be revised, and code needs to be refactored. Postponing those times for too long may force you to eventually do the right thing exactly when you have no time for that.

You may not want to start thinking everything all-over by youself, and it also wouldn’t be advisable, but the least you could do would be to raise the problem, and make people aware of it. There will be for sure many who will understand the need of allocating time and resources for finding the right solutions.

Title picture © Mafoto | Dreamstime.com