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.