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

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.

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.