Mostrando entradas con la etiqueta responsability. Mostrar todas las entradas
Mostrando entradas con la etiqueta responsability. Mostrar todas las entradas

13 mar 2016

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

18 nov 2011

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

3 jul 2010

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.

11 may 2009

A lame excuse

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

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


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

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

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