What is the leadership book I should be reading?

It was probably 5 years ago, while waiting in airports, I read a Chris Lowney book about leadership the Jesuit way, and it´s been haunting me since then. This week I’ve been thinking about it a lot, since I’ve been having a lot of issues with my team.

The author criticized books about leadership written by sport trainers. He said that basketball coaches always play de same game, the rules never change, so motivation and leadership techniques used there does not apply in the real word. He then explained how the Jesuits are excellent at adapting to whatever comes. He had a point, and explained many examples thought history.

But what bothers me is that all these wonderful techniques Lowney exposed only apply for Jesuits how make a life commitment to be in the Company. I have to deal with people that have very little commitment to the company, are probably seeking higher payment jobs as we speak and will resign in a second at any time without even a week notice.
I have an unstable team, with little loyalty. What leadership? I am not leading, I am struggling to keep track while most of the people on my team are pulling their way. Most of them will not go the extra mile if we face any problems. So, leadership in the corporate world really means use people as long as they let you use them, and be sure that none is indispensable, for they eventually will leave.

What is the leadership book I should be reading then?

The ones we miss, the ones we don´t.

What makes people a good employee… according to me!


Last night, we were talking among other things about all the people that have helped us in projects since our company started. We remember a few because we really missed them when they left, and others because we were so happy they left, we almost made a party.

I was a lousy employee when I was one. But after being a “boss” for many years I think I will now be a fairly decent employee. (Same when you start driving, you suddenly become a very good pedestrian. You are aware of what bad pedestrians do and endanger their lives quite stupidly.)

These are some of the things I leaned:

Good employees help solve problems, bad employees create problems. I have so many many things in my mind, that what I appreciate the most is someone taking some of the load from me. When employees complicate the simple, or interrupt me to tell me some really silly problem, it’s really annoying.

Good employees work even when I am not watching. Bad employees need me to be on their back all day in order to achieve minimum goals. The typical bad employee spends most of his/her day chatting, doing homework or working in their second job, the funny thing is that they all think I´m stupid and don´t know.

Good employees tell the truth even when things are bad, bad employees will always lie and say everything is perfect and suddenly resign when they can’t keep up the lie. As a manager, when there is trouble in a project, and you know it soon, you can do something about it. As an employee you will never be punished for raising issues when they come. Hiding it and resigning the day before the dead line is the best example of a bad employee.

Good employees know they still have to do their jobs, even if I am friendly to them. Bad employees assume they can stop doing what they are supposed to because they share a beer or lunch with me. I finally learned my lesson and no longer share any beer with any employee. Have to say I learned it the hard way.

Good employees will help with ideas and new perspectives when a decision needs to be made, but then follow my lead even if they don’t understand or agree. Bad employees always want to do what they want and fight every single day about it. You cannot lead a team that does not understand you are the leader. In my experience, it happens a lot with very young employees (like a pack of teenagers fighting their parents).

I have a mental list of all my employees. They are listed in good or bad employees. But, why keep the bad ones? Well… It’s all about the money. Some times it’s cheaper to keep the bad ones that finding new ones, training them and taking the risk they are worst employees than the ones I already have.

When they want uncontrolled changes and you don't have a boss to blame

As Project Manager, one of your main responsibilities is to control changes. Its the only way to deliver maintaining the triple restriction: scope, cost and schedule. When ever a client ask for a change, what is expected from you is to determine the impact in scope and translate it into impact in cost and schedule. Then, a committee decides what to do about it. PMI recommendation is that the PM must never decide on his/her own, some one else needs to make the decision, to avoid you being crucified latter on. It must involve Senior Management, the project sponsor o who ever gave you the authority to be Project Manager.
So far, so good. Looks like a simple procedure. But when you are both Project Manager and head of your company? You are as Senior as it gets. Its your call and the client knows it. Then, there is a big difference in how to handle it all.
In the early days, my partner didn't work full time in Sincronía. It came quite handy to help me with this situation. When the client was asking for a change and I really didn't wanted to do it, I said after a few days that the change was not approved by my partner. He off course, knew it, so in the rare occasions he went to project meetings, he sat there with an angry face and talked very little. He was the mean partner that didn't allow changes to be considered minor and therefore be done without charging extra.
But now, we are both working full time in the Company, and most of clients know us both, having a good and a bad partner doesn't work anymore. So, what to do? Well, it depends on the project.
Ideal scenario is to have documented requirements and the complete base line at the start of the project. Any change that implies a change in the document, implies a change in base line. Easy to handle.
But if you are developing with extreme programming methods, it might not be that simple. The idea here is that the development team works and change functionality as required by the client. There is no complete documentation before its built. But you will eventually face the problem that your client has bad memory (as most of them have) and makes you change functionality from A to B, then decides B is not so good and you go C, and then he wants it to be A not even remembering that it was the first version he/she ever saw. At some point, you need to stop allowing changes or you will go bankrupt.
It you are lucky, you will have a conscient client, that after being pointed the obvious will decide to stop the change. To be honest, we have some of those conscient clients, and then we can easily manage their projects. But with the others, the only way is to use negotiating techniques and dead lines.
- Define a dead line for changes to be introduced. It's very unlikely you can actually make this happen, but the threat that if they don´t make the change now will not be able to do it, will make them gather and test the application. In this way, big changes will come fast, the at the end only little things will follow. If you still have many developers working on the project, its easy to introduce big changes.
- Say yes to little things so you can keep the no on the big ones. Many changes are easy to implement. Don't fight on little things, its easier to just do them than fight them. Even if they sound stupid to you, just do them. Leave your ego home if you have to.
- Don't be afraid to say no when you have to. Don't let the fear of "damaging the commercial relationship" bug you. Remember that broke software companies can do anything with great commercial relationships. Some of the changes will imply changing the whole application or even imply new modules that are not really needed. Be fair, do what is needed for the system to be good, but don't bend on things that are not fair to you as the developing company. Some times the client is not right.
- Clients don't like to hear no. They will scream, threaten, insult and call their bosses into the fight. Be cool. Remember its a tantrum and don't overreact. I usually win this fights the Gandhi way. Just be not violent, but don't move an inch from where you are standing. Be prepared, you will not be popular, but you will win the fight and save some good money for your company.
- And finally, be prepared to loose some fights. Remember that to win a war you sometimes have to retreat or even loose in a few battle fields. Don´t forget what the war is about: have happy clients that will bring new clients while having a profitable company. It can be done, but its up to you.

Careful with the language and the ego

Have you ever been annoyed at a dinner party with a lot of friends from some other profession (say Lawyers, Sport Broadcasts, Musicians, Physicians or any other), when they just assume you understand their terms of know what the hell they mean? Well, don't do that to others! Have this in mind, especially if you are the Analyst in charge of gathering requirements in a Software Project.

Let’s face it, most people don't have a clue what requirement elicitation is. It's even less probable they know what a use case is, or understand what a business rule is for you. But if they don't understand you, and because of that the requirements come out wrong, it’s your fault. And I really mean it!

You can't go asking "give me the business rules" or "what type of data is this? varchar 100?". Your mission, since you accepted it with the job, is to learn their terms, their language, and then translate that into software engineering dialect so your development team can build it.

In a requirement elicitation meeting, the star is your business expert, not you. The one with the sole truth is him/her because it’s his/her problem you are trying to understand and solve. Don´t call use cases use cases if you know it confuses your user. Call them screens, forms or whatever they call it. Don’t refer to the fields in the form, ask for what other little boxes you need. Don´t ask how many concurrent users will there be, ask how many people works in the system at the same time.

So far, we have solved the language thing. Let’s go to the ego part of this post. If you are like me, cocky because you know you are really smart, well... remember that part of being smart is being able to adapt and behave according to the situation. (If you are not cocky, but humble, well good for you, but still remember to behave in a smart way).

In a requirements meeting, it’s very tempting to come up with a really new and smart way of doing things. But, the truth is you don’t know your client business that much, and you don´t know the organization or all the regulations. Maybe your way is really cool, but there is a very good chance it’s not appropriate for the specific need. For example, people don’t like change, and if you want to force a thousand employees to change the way they do simple tasks in the information system that works just fine because you want to show how smart you are, well, that might not be the best ways to go.

Remember to listen, ask properly, make sure you really understood, and remember that the Analyst role can decide if a software project fails or succeeds.

“Sorry, but I won’t tell you how much it cost, nor will I start the project right away”: When clients want to close a business but you know it is a bad idea…

When selling, the whole idea is to close the business as fast as you can. But then again, Software industry is not like any other business. If you are interested in building a confidence long term relationship with you client, sometimes closing a deal is more a curse that a blessing.

Custom software is expensive. It requires a lot of effort, translated into many engineer hours, translated into a lot of dollars. Still, if done properly, custom software can solve many client problems and potentiate their business. But if the software does not reflect the real processes, does not allow the users to actually do their job and even make it more difficult then you are just expending money to lose some more money.

Process analysis and optimization is the first step before even talking about building software. Some clients understand it and will contract you analyst team as consultants first. That is always the best way to go. But if the client is new at these, he/she will try to force you into giving a price and time for the development before the processes have been identified or a scope has been defined. Don’t go for it, even if it means losing this particular deal. If you don’t go for it, someone else will, they will mess up and the door of the client will be open for you a few months later.

Don’t hire someone just because you like him/her: Bad hire means loosing time and money

After some years of losing a lot of time and money selecting new hires I finally developed a good eye for reading resumes and a few tips to get the hires that last. I no longer interview more than a few people for each position and haven’t been terrible mistaken for a while.

This is how we select personnel today (technical and not technical staff), and why:

1. Publish the request for at least 2 weeks, and get as many resumes as possible:
We don’t use paper, only specialized portals or Universities Alumni organizations. People will apply even if they don’t have the required profile or experience, so you will get many resumes that don’t even apply making you lose time. That is why we prefer Alumni Associations that will filter that for you. Specialized portals give an additional help, they force people to include their resume in a template, so the information you receive is normalized, making it easier to compare candidates.

2. Just by reading resumes, we select a group of no more than 10 people:
Only with what is written you can eliminate most of the bad candidates. You should avoid: people that switch jobs too often, recent graduates that insist they have managerial experience, those who state the obvious with many details(*), lack of confidence or excessive confidence in presentation letters or career goals and those that work as a hobby.

3. We do first interviews and check references of those that seem to have an option (no more than 10):
The main objective here is to see if you could work with this person. Its more like a chemistry thing, and here it will depend on the values of your company. For us, we look for people that will speak their mind, will be creative in problem solving, but are disciplined and not a rebel without a cause. From those I like, I check references by phone… You’ll be surprised, but many people lie in their resumes…

4. If it’s a technical position, we include some technical test or code examples:
Some will be excluded form the selection if their test show no understanding of important concepts, and if code is not 100% complete. We recently started asking candidates to send code a few days after the interview. It helped me see who will go the extra mile for the job, and most important, will keep his/her word in when the work was going to be sent.

5. We select 3 or 4 people per position we need to fill, and then, let someone else choose:

we hire an expert in Human Resources do some character and values tests. Technical knowledge can be taught, but honesty, commitment or discipline can not. As a sub product of this stage, we also get a profile of the candidate, giving us tips on how to get the best of each person, if hired.

Only then, after this 5 step process, we decide who to hire… Its not a infallible system, but has lower our bad hires to almost zero. I am quite confident with it.

(*) This was sent to me by diegus9, and I do agree with it… might help the programmers improve their resume:
http://improvingsoftware.com/2009/04/17/the-programmers-guide-to-getting-hired-your-resume-its-the-little-things-that-hurt/
And these I found also in the same page:
http://improvingsoftware.com/2009/04/10/the-programmers-guide-to-getting-hired-the-code-sample/

A lame excuse

“The written requirements said the system must held 1500 concurrent users, instead of the 7000 we are getting.”

Monday last week, a new governmental web application was deployed: the RUNT (www.runt.com.co). The application, built by a group of Colombian IT firms headed by Heinsohn, will held information of all transport vehicles in the country. All owners of cars and motorcycles have to register to update information regarding the vehicle and owner. A fine up to two minimum monthly wages (about US$430) will be imposed among those that register late.


Monday noon last week, the system was down. The number of users exceeded the capacity of the system and it took all week for the technical team to catch up. Friday, both the software building firms and the Transport Ministry gave a press conference, to explain what happened. Too many people try to enter at once, and they didn’t expected it.

Lame excuse cause the dynamics of building software has changed (like 20 years ago). Technical staff is responsible for validating requirements given by the client, not just follow them blindly. We, the developers, are responsible for the system having the appropriate functional and non functional requirements, for the client knows his/her business, not how to calculate expected concurrent users.

Analysts should go a mile forward, other wise, how can organizations trust software companies to build exactly what they need?

How to deal with recent graduates

One of the most difficult tasks when managing any kind of company, is dealing with people. Recent graduates represent a large percentage of my technical and administrative staff. But the youngsters that join a working team for the first time, need to be dealt in different way that more experienced professionals.
So far, this is what we know and how we deal with it.

Recent graduates tend to see you as their teacher, not their boss. They expect you to tell them how to do all tasks and to get help when they don’t understand something. They no longer raise their hands (they know they are not in a classroom), but will ask you anyway. We deal with it by empowering them: “Do it your way, just complete the task”.

But it usually brings the second problem. Recent graduates tend to ask for a good grade cause it was hard, without even finishing it. While in the educative system effort and learn by doing is valued, the switch needs to be made to make them result oriented people. Since they don’t deal directly with clients, and they don’t understand the pressure you are facing when they don’t complete a task on time, you need to pass the pressure to them. Be inflexible when it comes to dead lines, get mad if they are late, get madder if they are late a second time. Make it completely clear that the work will not be appreciated if it is not delivered 100% and on time.

But then, there is the next problem. They don’t have enough experience to estimate how long a task will take, so they usually cant keep a dead line even if they decided on the due date. So, don’t let them decide schedules. That is your job as manager. Trust your statistics, your data, and your Delphi ability(*). But don’t let recent graduates put dates on tasks, or you are going to be disappointed. Help them be systematic (force them if you have to), to learn how to estimate. We use the logt form from PSP and make them record all activities they do every day, until they get what they are doing wrong.

Since, at this point the new team members still don´t differentiate well if a difficulty is due to their inexperience or a real problem, they will complaint incessantly or not tell you if they are behind until it’s too late. So, check on them frequently. You need to monitor if a delay is coming and if its caused a real issue and a due date needs to be moved. When in doubt if it’s a real problem or just whining, keep the deadline and let them deal with the heat later. They are not your kids, keep that in mind.

Finally, the hardest thing to deal with. Recent graduates tend to think their work has a greater value than it has. When I was in my senior year in Engineer School, a Professor I have a lot of respect for, once told us, the one that hires you when you graduate is well aware that you don’t know anything. I found it funny, but took me several years to understand he was serious and right. You are dealing with smart people, with ability to learn, but they still don´t know how to behave outside campus. Don´t expect too much. Be patient. When they ask for a raise for no reason, just kindly explain that their salaries are proportional to the amount of money each individual represent for the company (if you can make us make money, you get paid more). That is clear for us managers, but not to them.

*http://en.wikipedia.org/wiki/Delphi_method