Moving out, leaving it behind

 It´s been a while. This blog started way back when I was head of a small company, that no longer exists. 

My path has changed many times, yet I am still working on Software Management.

Preparing to my next change of path, I will continue this blog in

www.mariavelascocampuzano.com

Join me there...  This blog will be up as a reminder of the paths already traveled. 

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

Timeless Principles for Leadership

I read these principles on Linkedin and thought it was really timeless and accurate, so I want to share them with you. This is how I try to manage teams, it just reflects my own views perfectly.

1. Know yourself and seek self-improvement – understand who you are, your values, priorities, strengths and weaknesses. Knowing yourself allows you to discover your strengths and weaknesses. Self-improvement is a process of sustaining strengths and overcoming weaknesses, thus increasing competence and the confidence people have in your leadership ability.

2. Be technically and tactically proficient – before leaders can lead effectively, they must have mastered the tasks required by the people they lead. In addition, leaders train their people to do their own jobs while understudying the leader so that they are prepared to replace the leader if necessary. Likewise, leaders must understudy their leader in the event they must assume those duties.

3. Seek responsibility and take responsibility for your actions – leading always involves responsibility. Leaders want people who can handle responsibility and help achieve goals. They expect others to take the initiative within their stated intent. When you see a problem or something that needs to be fixed, do not wait to be told to act. Organizational effectiveness depends upon having leaders at all levels that exercise initiative, are resourceful and take opportunities that will lead to goal accomplishment and business success. When leaders make mistakes, they accept just criticism and take corrective action. They do not avoid responsibility by placing the blame on someone else.

4. Set the example – people want and need their leaders to be role models. This is a heavy responsibility, but leaders have no choice. No aspect of leadership is more powerful. If leaders expect courage, responsibility, initiative, competence, commitment and integrity from their direct reports, they must demonstrate them. People will imitate a leader’s behavior. Leaders set high but attainable standards for performance and are willing to do what they require of their people. Leaders share hardships with their people and know that their personal example affects behavior more than any amount of instruction or form of discipline.

5. Know your people and look out for their welfare – it is not enough to know the names and birth dates of your people. You need to understand what motivates them and what is important to them. Commit time and effort to listen to and learn about them. Showing genuine concern for your people builds trust and respect for you as a leader. Telling your people you care about them has no meaning unless they see you demonstrating it. They assume that if you fail to care for them daily, you will fail them when the going gets tough.

6. Keep your people informed – people do best when they know why they are doing something. Individuals affect the bottom line results of companies by using initiative in the absence of instructions. Keeping people informed helps them make decisions and execute plans within your intent, encourages initiative, improves teamwork and enhances morale.

7. Ensure the task is understood, supervised, and accomplished – your people must understand what you want done, to what standard and by when. They need to know if you want a task accomplished in a specific way or how much leeway is allowed. Supervising lets you know if people understand your instructions; it shows your interest in them and in goal accomplishment. Over-supervision causes resentment while under-supervision causes frustration. When people are learning new tasks tell them what you want done and show them how. Let them try. Observe their performance. Reward performance that exceeds expectations; correct performance that does not. Determine the cause of the poor performance and take appropriate action. When you hold people accountable for their performance, they realize they are responsible for accomplishing goals as individuals and as teams.

8. Develop a sense of responsibility among your people – people feel a sense of pride and responsibility when they successfully accomplish a new task. Delegation indicates trust in people and encourages them to seek responsibility. Develop people by giving them challenges and opportunities that stretch them and more responsibility when they demonstrate they are ready. Their initiative will amaze you.

9. Train your people as a team – teamwork is becoming more and more crucial to achieving goals. Teamwork is possible only when people have trust and respect for their leader and for each other as competent professionals and see the importance of their contributions to the organization. Develop a team spirit among people to motivate them to perform willingly and confidently. Ensure that individuals know their roles and responsibilities within the team framework. Train and cross train people until they are confident in the team’s abilities.

10. Make sound and timely decisions – leaders must assess situations rapidly and make sound decisions. They need to know when to make decisions themselves, when to consult with people before deciding and when to delegate the decision. Leaders must know the factors to consider when deciding how, when and if to make decisions. Good decisions made at the right time are better than the best decisions made too late. Do not delay or try to avoid a decision when one is necessary. Indecisive leaders create hesitancy, loss of confidence and confusion. Leaders must anticipate and reason under the most trying conditions and quickly decide what actions to take. Gather essential information before making decisions. Announce decisions in time for people to react.

11. Employ your work unit in accordance with its capabilities – leaders must know their work unit’s capabilities and limitations. People gain satisfaction from performing tasks that are reasonable and challenging but are frustrated if tasks are too easy, unrealistic or unattainable. If the task assigned is one that people have not been trained to do, failure is very likely to result.

The original link is here, in case you want to take a look at the complete article. 
http://www.linkedin.com/today/post/article/20140607131713-404673-11-timeless-principles-of-leadership-us-army-1948

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.

Silver platter and the doom of custom made software

Silver plattering is a made up verb that refers to giving to the customer more that what is in the scope of the agreement. Basically, you give them your work for free while smiling, you give them what they want in a silver platter.

As any good negotiator might tell you, it can be a good deal if by giving a little you get something else, but it can be the doom of a project if the silver platter starts and never ends. When working in projects, be aware of the risk of silver plattering. I  sank a 7 year old company just because I was not paying attention to it. Believe me, its a high risk.

The expectation that the contractor change indefinitely a software is quite common in organisations that don't have mature processes and don't have a clear understanding of software development practices. It basically describes most organisations working in a undeveloped software market, Colombia for example.

For example, they want the software to fit the process, but they keep changing the process and expect you to develop the change again and again. One that is happening to me right now is that the requirements are given to you with little or no details, for example lacking special cases or precise data that needs to be saved. Then, when the testing starts you are expected to change it again and again for not being a good psych and developed exactly what the customer had in mind but forgot to write down.

What to do? Its as clear as water. Don't give your work for free, no matter what happens. It you loose a client because of it, it might be better for you. First, be sure to include in the contract a clear definition of change and defect. Second, include in you plan a specific milestone for client approval of the requirements and don't start development until you have a valid signature. Then, stick to your process like a fly to honey.

When asked to do a new change because its the "last one", just say no!

Why commit to quality?

Colombia does not have a developed market for software. In most companies the person in charge of buying software is the same person that buys the soap, and buy it using similar criteria.

Quality in software is not understood, and developers have to do not one extra mile, but ten extra miles just to have them accept simple suggestions to avoid petty requirements that will affect significantly the maintainability of huge applications. Most clients haven´t even heard of maintainability as a concept.

You can loose your mind trying to explain the difference between a defect and a change and why you will correct defects but will not implement changes for free. And the concept of controlling changes seems to your client as a bad way to ask for more money.

If complete mess is the rule, why bother implementing a costly maturity model to guaranty quality in processes and products for clients that will not appreciate it and consider it as bureaucracy that increase the cost?

Just because you know maintainable and reusable software will save you money in the log run. Eventually you will move into the maintenance phase or build a similar system and the fact that you can reuse the documents, design or code and make your life easier will be worthy.

Normalize, but not too much

 Its common to have understaffed projects. People get recruited just when the team starts to get behind, but not before in an attempt from administrative staff to save some money. If team members can barely finish their jobs on time, they are not very interested in making advance reports or help you define how much time it will require the next task. They are tired, and they don’t see the point, since their perception is that the job gets done just because they don’t get to see their families. In this scenario is quite difficult to gather information for planning and control.

Still, if you are at the PMO, you are aware that knowing the status of the project is as important as doing the job. That is why it is your job.

How to do it? I found that adapting to the team worked properly, and try to find information in the format that is more natural to the person doing the job. Some people have organized tables where they keep track of everything, some just keep the record in a board with post-its. I just took their particular methodology, analyze it and talk them into including additional information I needed. For example, making the reports with the same periodicity or adding one more field that will allow me to have the statistics I needed for the reports.

I was able to get normalized data from all fronts of the project without having every team member filling specific formats. It just worked for me, and I guess for them, since they never felt my reports to be a burden.

 

Just a new remainder that projects are made by people, and that your need to normalize PM data should never imply you have to normalize the people you work with.

Estimations

I remember the first time I heard about Delphi Estimation*. It was my first undergrad course on software engineering. I couldn't stop laughing for a while, how can you base the whole project plan on some persons guess? It sounded so stupid, I kept making jokes about it for a while.

Many years later I found my self having a great deal of respect for estimations based on experienced persons "guesses". Delphi method just growed on me, without me even noticing.

I can now see at a proposal and just know if the estimates are good or not, by heart, I just know. During the last decade I acummulated experience and I am able to classify requirements by risk, know what can be done fast and where the programmers are being just too optimistic, in mi head in minutes.

But this gut feeling wasn't given to me by the gods as a gift, it was built with hard work. I have records of times of the work I have done, for years. Every day I record how much time I spent in each project or activity. Not histericaly, with seconds, but just a rought count each day. Every month I take an hour to summarice it and check if my estimates were correct when I planned my activities. Some times my estimates where acurate, some times they weren't. I learned from the mistake and managed to improve my estimates for next month.
I then started doing the same thing with other's people's work. I created a way to classify requirements by complexity (a personal simplification of the function points, that latter learned, are called use case points). I used to estimate how much time a team needed to develop a set of classified requirements. Then I measured, and compare my "guess" to reality and learned from the mistake. I made this for years and still do it, every day, even with the smallest simple task (like checking expenses from a trip, or reviewing a report).

I learned this wonderfull trick in the same class where I learned the Delphi method. I was "forced" to used the PSP (Personal Software Process) that includes keeping an engineering journal with notes of your work and time taken by different activities. My journal was then a ridiculously pink Hello Kitty notebook, now I just keep it all in google docs files. I will record in a while that this post took me about 40 minutes to write (including finding the magic eight ball picture), and hope that after the 5 minutes it took you to read it, you are curious enough to check the PSP and keep a journal. Believe me, its worth every second spent on it.


* Sorry about including a Wikipedia link as a reference, couldn't find a better link to explain the Delphi Estimation. If you have a better reference, please let me know, I will gladly replace the link.

Just read the PMBok book! (or not)

I still find strange that Project Management Best Practices are uncommon or not known by companies working with Engineering Projects. 

Being common in the Engineering(or almost any) discipline, projects represent doing something specific, like creating a new product, in a predefined period of time. Since the idea is to do it efficiently, using developed techniques (even templates) would be an easy way, a natural shortcut. Yet, many people still think that Project Management happens magically if you put many people and give them requirements to fulfill. It doesn´t, and after some time, the team ends up frustrated and the requirements, if fulfilled are done with pour quality or triple budget or time.

The Project Management discipline has been around for 30 year or so. There are hundreds or books, blogs, websites on the subject. You can take courses, even post graduate programs, or get certifications that are recognized worldly (like the PMP). Yet, still, in some organizations it’s a completely new and novel approach.

If by fate or choice you end up in such organizations, you might spend much of your time struggling to get your boss to read the damned PMBok. But it might not happen. It they made it so far without it, why will they want to change their approach? According to their experience, projects are messy but somehow get done.

Do you want to give the fight and try to change your organization? If you do, my advice is not to battle but show how project management techniques can solve daily problems efficiently. Take little steps, don´t fight (creating more chaos into the chaos). Remember one of the most important responsibilities of a PM is communicating. Make sure all people have the information they need when they need it, and that issues are properly communicated to the involved before becoming an issue. This talking, is nothing else but coordination. If you are able to do this successfully, you have gained a lot, and made a big step in the right direction.

Then, start using planning techniques to eliminate the sense of  "no control" your team might be experiencing. Start by doing a simple work break down structure, a list of tasks and a Pert diagram. (Try not to call them that, you boss might think you are bringing those hippie PM things). Planning means nothing if a team is not committed to fulfilling it. Try doing that, but just talking to people. A Schedule should not be enforced, but sweet talked into people. If the team is convinced the planning is right and the due dates are required to make it all work, you will then have a very decent planning and will be able to follow it and see significant delays.

Budget will not be hard to include into the plans and follow ups. Next step, will be to plan for quality. Both can be done by slowly including into the plan control activities. If you do all this, probably the project is over and you had a lot of work in it. But you will have interesting data to show your boss and your bosses boss. You can show results of using project management techniques and have arguments to keep on the battle for introducing the best practices you know really work.

Not in charge

Recently, I was offered a position in a huge engineering project, changing transportation systems here in Bogotá. I decided to take it and I am now part of the PMO (Project Management Office), in charge of schedule and risk management. The PMO includes now 5 people and is still growing, since the project is that big.

For the last 7 or so years, I lead small software projects, 10 to 12 people tops. We didn't had a PMO, just a PM. I did all managing activities. It was doable considering the size of the projects at hand. This is my third week in this position, and I am aware of how different a project seems when you are a project worker instead of the PM.

It has been quite interesting to see how my perspective on the matters is so different when I am not in charge, and how people working in projects see their little bit of it in particular ways.

All PM books and best practices insist on communication being the main activity of any PM. It´s been sort of a revelation how more critical  this is when being a part of the team. If strategic decisions or even simple little decisions are not informed to you systematically, your job might seem irrelevant or might certainly be irrelevant. Knowing their importance before, I now give more value to team follow up meetings.

posted from Bloggeroid

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. 

Project Management is not fighting

While developing custom software with a difficult client, it is frequent to see inexperienced Project Managers thinking their job is to fight the client.


I read The Art of War many years ago, but it took me a while to understand most of it. In war, all sides lose much. You must only go to war if you have certainty you will win, and that you will win will be more valuable to you than what you will lose. These three simple concepts have to be in the mind of anyone dealing with a client.


Fighting and conflict might win a small battle but will get you into losing the war. You need to pick your fights since having constant communication and being able to negotiate with the client is one of your main responsibilities as a Project Manager.

A Project Manager should not fight, but solve problems. Use force and conflict only if it's the only way, you have certainty you will win and are sure that what you will get is more than what you will lose.

Where have I been?

I decided to change a few things in Sincronía in 2010:

• We started with market research and organizational consulting ending in new strategic planning and balance score card analysis. 
• To reinforce the operational strengths I leaded the company into a ITMark certification. 

Both processes are going on since March, so, I haven't had much time to write. I will be back soon, sharing all the lessons learned while leading this huge and ambitious projects.

Just one woman

Leading a company in which I am the only woman might not be a big deal for most, but it is for me. Gender issues are present in my daily life. This post is just a thought and hope I have.

Some years back I entered an IEEE mentoring program for women. I started talking to this lady in the US that worked in IT. I asked her about her experience, how she dealt with it all. She didn't understood my questions, she said she went into college and then marry some engineer and all was great in her white picket fence house. What was I talking about? I left the program really fast. Women engineers don't struggle much in the US.

But, I don't know any other women that lead teams in masculine environments. Here in Colombia, women in high positions always hide (or are force to be behind) some man. I really don't have a role model, and sometimes don't know how to get by.

What I do, is pose as a man most of the time. Sometimes I am not so good at it, and my feelings show. I get disappointed and sad, instead of angry when things go wrong and things like that.

I hope that age will help me find balance, so I don´t have to deny my initial instincts, act according to my true feelings and still be able to lead successfully my team. I now think I have to give up to much to be where I am.

Geese and your team productivity

People say that the first job you have as a young professional marks you for life. I agree. When I was a grad student, just after finishing my BA I worked at ACOPI (that is the Colombian Association of Small Industries www.acopi.org.co).

Their most important project at the time was called PRODES: Programa de Desarrollo Empresarial Sectorial. It still exists and its main idea is to group similar small business to potentiate their development. For example, if negotiating raw materials for 10 companies, you could make a better deal than if negotiating individually. You can easily implement quality methodologies if you share the work, etc. It made a lot of sense and it was very successful. I didn't work on the PRODES project, but I was always listening, for I found it quite interesting. Many years later I still run my company having in mind many of the PRODES tips. Working on ACÖPI clearly marked me for life.

A basic principle in PRODES was shared leadership: the group will change the leader periodically. Leading a small company is hard; imagine leading a group of 10 companies on top of that. They used as an example how geese fly. When the goose leading is tired, it gets in the back and the one closer takes the lead immediately. The group always has a leader, but no one gets burned in the process.

Recently I have understood (and am experimenting in) a new dimension for the shared leadership. I now use it to elevate software development team productivity. The concept is simple, keep moving the pressure from one team member to other, never dropping the pressure, but never keeping it on one person for too long.

This is how I suggest you implement it:

Know your project
Functionality will have different levels con complexity: might require knowledge for the business, particular technical skills, prerequisites from other use cases, etc. You need to know as much as the project as you possibly can, keeping a general (managerial) view.
With this knowledge you´ll have what is needed to have estimates for all units of work. We have estimates based on historical averages and a bit of my own personal invention (Delphi technique, so it doesn´t sound so bad).

Know your people
Every person in your team has different skills and abilities. They also have limitations, lack experience or have certain difficulties. Since the PMs job is to make it happen in the time you have with the money you said you would, knowing as much as you can (from a professional perspective) from you team will always help. You will then be able to know what will be a challenge to one person and will kill him/her of boredom.

Know your bias
All PMs have a team member they prefer, just as parents have a kid they prefer (no matter how much they try to hide it). It's inevitable. Bias will make you assign complex use cases to a single person, or silly boring ones to the other. When in doubt, just look at your statics, that might help you remember that the good one is not so good, the bad one is not so bad and that most of the bias is a construction of your mind (we hopefully someday quiet).

Remember it's all about the money
Well, all these know and acknowledge has one single purpose: build the schedule for the development team. Now, define the time period to switch the pressure for one member to the next, and identify your critical tasks. Assign a team member to each task on the critical path, switching responsibility periodically, and shortening the time to do it. Don't use the effort you estimate on critical tasks, use less. Take no more that 10%-15% off; if you go for 50% then your schedule will just be unrealistic. Then, fill the rest of the schedule making sure each member gets a simple task after finishing a critical one. Use the regular estimation on all the tasks that are not in the critical path. Your goal is to use shared leadership in the critical path so the schedule will end with extra time and extra money. Really, it's all about the money.

You still need to monitor closely this schedule, and manage any differences from the planned schedule. But will probably get the best out of your team by using the geese technique.

By the way, PM stands for Project Manager.

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.