Your unique set of skills

As I am ready to start a new endeavor, and with it, to establish a new team, I started thinking on what skills I already have. Every person on a team has a particular set of skills that give value to a project. As a Manager, being able to recognize these skills and take advantage of them, will help immensely in delivering the project or process as planned.

But the skill starts with oneself, the ability to recognize our own personal unique skills, and measure them objectively is one of the most valuable trades or a good executive. Know thy self, they say.

At this stage of my life, I am reviewing my past experience, my core values and deciding what are the skills I will develop even further. What is the Project Manager and Executive I am? This is what I have come up with so far:

For good or worst, I am aware of how everybody in a team provides value (or problems) from their own perspective. I have a great difficulty to see people as their titles or status, I see people. Jerarquies mean little to me, in work environment, I see people as their role in the particular project or scenario but have no special distinction on how I treat anybody, according to rank. So I do well in organizations with more horizontal structures, where people speak their mind and a good debate is always welcome, where respect is shown equally to everyone.

I also like to learn and speak other people's language. Even though I have a technical background you will not see me talking in IT technical jargon unless I am sure everyone in the room has also a technical background. I do not assume all people know the same as me and don't expect them to know what I know. I do good in interdisciplinary and multicultural teams.

I am an introvert. I am not shy or insecure, just an introvert. I am constantly having so much inner dialogue that I need to spend time with myself just to think. I like having lunch on my own and spend most of the time in a meeting in silence, listening and analyzing. I am bad at small talk and will avoid office parties if I can, but will develop deep connections with each person in the team. I just need to talk to them one at a time, get to know them, really listen.

I am goal oriented. I need to see tasks finished, and even when I take on multiple tasks at the same time, I will naturally use the Kanban approach and stop taking new ones until I have finished the first ones. I like working smart instead of hard, so, eventually will have no problem with canceling a task if it no longer provides value to the project or the organization. The reason to finish the task is to add value, not just mere stubbornness.

I am always thinking of the new product, the new service, the new something. I can´t help imagining new solutions to the problems I see. I am a startup person and will find a way to create a new startup or innovation team in where ever I can. I am also good at the excitement and the risk, the constant moving and adapting, the need to "move fast and break things". I am a specialist in Startup Project Management (yes, this is a thing! check it out: https://www.toptal.com/project-managers/startup)

Many of the projects I have worked on where software development. Software Engineering is probably one of the Engineering disciplines in which you develop more respect for being methodical and keeping best practices in mind at all times. Software projects can go wrong in so many ways, that you do not skip steps on the way. I started my career when RUP was the best thing available, and have seen the Agile take over in many scenarios. Then you complete your view with PMI and, you have a PM Certified Profesional, able to identify what is the best methodology for a particular project and then, using it to produce value.

Having been an Entrepreneur and CEO on medium-sized companies, I am very much aware of how costs and cash flow can affect the results of a project. It's not all technical, or about the quality. Money issues will determine if you survive or not. Keeping a business perspective is as important as finishing the tasks.

Finally, I think I am old enough to not take things personally. Many ways conflict comes from taking too personally things that are not even about you. Took me years to understand it, and embrace it. Wish I knew it when I was younger, but I guess that is how we all feel, as we grow wise.

With this reflection done, I am now ready to take on new challenges. Knowing the unique skills I have already in my team. What are the skills you can bring to the team?


Photo on Foter.com

Role definitions

This post on Quora, which I found by chance yesterday, goes along the lines of the importance of defining objectives very well. I had some experience in being burnt after accepting a role that was not well defined. So believe me, I can´t stress enough how important it is to have a clear view of what is expected from you before accepting a role.

Here it is

---

Answer on @Quora by Gil Yehuda to What is the craziest thing you have ever said (or done) at an interview and still… 

In response to a job offer, I said no. As a result, I got the job.

I was interested in a particular job, and read the description carefully. It listed 5 specifications, covering a wide range of skills in my field. They really needed two people to do the job as described. After the phone interviews, I was invited to a full day of on-site interviews. I first met the hiring manager, and then a few people associated with the role. The last interview was with the recruiter.

First interview with the hiring manager (CTO) went well, but ended strangely. He asked if I had questions. I asked about the five items listed in the spec: they were diverse. Which was the most important part of the job? He scanned the job spec sheet and said #5 was most important, the other four were much less relevant. I asked: why is the most important part of the job listed last? Usually a list like this would have the most important item listed first. He seemed annoyed at the question, and reiterated that #5 was the primary job, the rest were not as important. That felt strange.

The next five interviews went smoothly, and things looked promising. Each interviewer asked if I had questions, and I asked each the same question: "If we asked the CTO which of these 5 items are most important for this job, what would he say?" Each one answered #1 is the primary job. Then I said "I actually asked the CTO, he said #5 was the essential part of the job. What do you think that means?" Their reactions were very interesting. One said "No, I meant #5..." Another said "Oh that's not right, I need to meet with him and correct this." Fascinating indeed! I discovered a disconnect between the CTO and the team about the job.

The last interview was with the recruiter. We had a frank conversation about the company and about the issues I uncovered. She told me that feedback from my interviews was positive. But she did not have a good answer about the role clarity. Yet they still wanted to make me an offer. The truth is, I really wanted (needed) this job. But I said: I'm sorry, I don't think I can take the job if the company doesn't know what the job is. You need to figure out what you want before you make an offer. I don't think anyone could succeed in a job where the very role is in dispute.

She responded. The reason they wanted to make me the offer was that I was the only person to see what was going on. It was a new role and they didn't understand what they needed. Apparently I read the situation in a way they were unable to see themselves, and that's what they needed. They want me to take the job in order to help figure out what the job should be. That’s a twist, and a huge opportunity.

She asked me what salary range I was looking for. I thought, this makes no sense. Yes, I want the job, but the risk of failure is high since the job was ill defined. Given the risk, how would I know if they are serious about having me figure this out for them? So I said "If you make me an offer I can't refuse, I won't be able to refuse it." She came back 15 minutes later with an offer I could not, and did not refuse. No regrets either.

 Link to the original post

https://www.quora.com/Experiences-in-Life/What-is-the-craziest-thing-you-have-ever-said-or-done-at-an-interview-and-still-got-the-job/answer/Gil-Yehuda?srid=zA9t&share=b2bc108d

Loyalty, respect and fear

There are as many Managing styles are there are managers. Some base their leadership in loyalty, others in respect, others in fear, and so on.

I take a lot of time just thinking in the type of manager I want to be, and how I want my teams to follow me. I sometimes experiment on different approaches and see what happens. But there are some things that don´t change, they are a part of me. I do love working with smart, rebellious people that challenge me. I love teams that debate, where people need to be convinced instead or ordered. And I make sure they know they can all argue and challenge me, again and again.

I really takes a lot of effort to lead teams of people where people just do what I say and never argue, those that bring me coffee cause they think that is what I want, and always answer what I want to hear. It annoys me deeply, and I have to breathe deep for a while just not to react quite badly.

Now I am facing the challenge to work for people that expect from me being obedient and quiet. And I am not sure I can do it. I am not sure I want to do it. It’s going to be a hard week. Hope I can survive it. 

It has been really hard to be lead after so many years of being the leader. But his has also given me back the sense of working on a team, to put one stone to build something bigger.

Both win or lose are team results

Looking back gives perspective. You might be doing some reinterpretation of the past events, but if you are honest enough you might find the reasons that lead to the events. At least that is what I think.

I have been doing a lot of thinking of past events, those that lead to me taking the decision to close Sincronía, my former company. We had three unsuccessful projects after a long line of reasonable successful ones. What happened? What went wrong?

The first conclusion, that might be obvious to some, wasn't to me. Things don't go wrong just because the leading person (me in this case) messed up. Most of the people involved have to mess up for something to go bad. Working groups are able to level themselves, balance charges, deal with stress and move on until they reach the desired goal. When one person is not able to give his/her best, someone else takes over and keep going. When a project gets delivered in time, on budget and ending in a happy customer, you have to recognize that every single person in the project (and in the company's support system) was a part of that success.

Same happens the other way around: in order to fail you need all of the team to be unable to balance and support itself, you need a full team of people failing individually at the same time.

This is the first lesson I have learned, every single person involved helped in successes we had, and every single person helped in the final fail. Failing is easy, you get there by not caring, not having enough experience but still taking the job, not helping others, even have some serious cases of people liying, cheating or even sabotaging code. I ended up with a team that had it all to fail and it took us about 9 months to do it. I am responsible of not noticing it on time. But I was too, at that time, a person that didn't care much and wasn't interested in taking over some one else's work.

So here is what I learned and my list of unasked advice for PMs:

• Be sure to always care, and have the energy to do something about it. Don't let your self be so burned out you no longer care. Take a break when you think you can't take it any more (and don't feel guilty about it).
• Monitor individuals and their performances, but be sure to also monitor the health of the group as a whole. See how people interact, how they talk to each other, monitor if there is respect in the team. If you don't have a healthy team you will certainly fail.
• Don't hesitate (as I did) to fire those that are not working as part of the team (and not doing their jobs and expecting someone else to do it is one of the worst ways of not being a team player).
• Be sure to remember that a fail (even a huge one) does not define you. If you fail, don't care that much. Learn from it, pay for it (mistakes are often payed in the form of money) and then, move on. 

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.

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/

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