Stop Blaming Others. Take ownership of your own team members… at the least!!!

Hiring good people is not easy. It doesn’t matter what role you are hiring (Architect, Manager, Tech Lead, Developers, Automation Engineers. Don’t question me why I have not mentioned manual testers in this list :(), it takes a while to find the right person.

Hire MeI am involved in Hiring people for the last 10 years and my average is 40:1. Unless you are lucky and know someone for the job, you may have to speak to 40 candidates before finding 1 Good guy. This average has not reduced in the last 10 years and I don’t see that reducing. It means on an average to get one good guy into the system, it takes approximately 40 hours (at the least).

After you spend so much time and on board a member, there is still no guarantee that the person whom you hired will work.

If it takes so much time to hire and on board a member, why not we spend time with those people, keep them motivated and retain them in our own teams. This is a question I get every time when I hear a good guy leaving.

I have heard multiple good people leaving off late and my frustrations has gone to its peak last week.

I recently heard a manager saying a good team member is leaving because this guy heard someone else talking for 10 minutes, got frustrated and leaving. I know that, I am a naive person. I don’t manage team members now. But, this immediately came out of my mouth.

Really…. Really…. Really…. Really….

May be, it could be just a triggering point. But, this guy would have left even otherwise. Why can’t this manager see this coming?

More than 1 million employees can’t be wrong, so bosses take heed of this. A Gallup poll of more 1 million employed U.S. workers concluded that the No. 1 reason people quit their jobs is a bad boss or immediate supervisor.

People don’t leave jobs, they leave managers. 

If it takes so much time to hire a person, why don’t managers generally spend time with their best guys, motivate them and retain them?

After thinking for a long time this is my conclusion. Generally not every manager gets involved in Hiring. They don’t even speak to candidates and spend enough time before getting them on board. Otherwise, stand in the road with a board “I am hiring” and whoever comes in their way, offer them a job.

When you don’t spend time in hiring (like spending 40 hours), you will not even know what is involved in getting a good guy work for you. It’s someone else’ blood. Why should I care in that case?

Worried People

Guys… Let us stop blaming others. At least let us take ownership for our own people. Start spending time with your team members. Speak to them (1:1 – Once in a month) and understand them. Be available, honest and transparent. Help them resolve their day to day issues. Trust will automatically build. 1 Lac here and there will not become a major issue.

Better Bosses, Better Retention!

Happy Learning!!!

Image courtesy

Stuart Miles /
Ambro /


I “Post Master”

Delegation, A topic which cannot be missed in any management books. The message is don’t try to do everything by yourself. By delegating to others (who is capable of doing), you can groom the person, help him to grow and one can focus on the most important tasks.
But, what is the key here?

  • Don’t do everything by yourself… It doesn’t say don’t do anything at all
  • Delegate to a person who is capable. “Horses for courses
  • Follow up in a regular interval, check if things are going OK and whether the other person needs any help.

Check here for the 12 Rules for delegation

But People are different. They take only what is important for them. Anything and everything can be delegated to others…

I recently spoke to someone (Let us call him A) who took over an account from another manager. This account is a crucial account and there is a struggle to fill the key position for this crucial account for a very long time. There was no progress made for about 7 months till A took over and suddenly in the last 1 month, there is enough progress that has been made, which is visible.

How come someone couldn’t do anything for 7 months and there is a sudden change in the last month? You can say “Luck“… But that’s not the truth. The Previous person delegated his work to someone and probably that someone delegated it to someone else and this chain could have extended further down and no one had any accountability.

Post MasterBut, since its a crucial thing, A has personally started working on it and because of that things have started moving, and the progress is visible.

Did A do anything different in this context? No, A just did his work and nothing else…

Delegation is important. Delegate when your plate is full, or you know someone else is ready and he can do the job so that you can do something more important.

Don’t Delegate because you have a person and you don’t want do anything at all…

If you do so then you can proudly call yourself as “I am a Post Master….”

Happy Learning!!!

Image courtesy

Ambro /
Dundee Photographics /

Release Planning and Schedule Monitoring : Myth or Real

In the previous post, we looked at the issues with estimation and for sure it’s clear that there is no way one can estimate accurately.

If you want to plan and monitor a release, the first thing one should know is the pace in which his/her team is running and the second is where we stand as of now. All the management care is if you cannot complete it tomorrow, when you can complete.

Obviously, one cannot go to their senior management and say it will be done whenever it is done. I am sure, we all need our jobs :).


But is that an excuse for the manager’s to sit idle and do nothing saying my developers are not giving any estimates or say I have got you an extension whenever you asked for. For sure, most of the managers rely on their techies to give the real picture. But isn’t that we all have some brain and we should put our brains to some use?

In one of my previous posts i have talked about my view points on this “Are we there yet?

There are two things one as a manager can implement, which can help him make informed decisions.


As a manager one of the tools that can come handy for monitoring is the cycle time. Cycle time is the time that takes to complete a feature/story/task from start to end. Now classify your stories/features/tasks/whatever you have, in the format of small, medium, large, and extra-large.

Cycle Time

Calculate the cycle time. What one should be more interested is on the Average. Display your average time takes to complete the Features on a White Board. Build a Trend chart on the same so that everyone knows how things have changed (whether you are spending more time or less time) over the course of the development.

What if we realize that we are taking a lot of time to complete a feature?

There are two things one can look at.

  • How much time is spent at each section (Analysis / Development / Acceptance)
  • The Lead time to move a story from one section to another

This will give you the complete insight and all possible optimizations can happen after that. This will not only expose the problem within engineering team, but also the time spent in requirements. Say for example: If you see your team members spending most of the time in Analysis, i am sure you know where to optimize.

What are the benefits of doing this?

  • As a manager, one is not only dependent on the team to get the estimates. 95% of the teams are into brown field development and this will help big time.
  • Everyone in the team knows how much time approximately it takes to get anything done (since the average time and the trend chart has been displayed). If you are the Product owner, it’s easy to plan for releases by seeing the average time taken and the trend (whether it’s taking more time or less time).  Will it still be accurate? May be or may not be. But then you have some way to predict (using the Velocity Chart, Cycle Time and Cycle Trend) rather than just shooting at the dark.
  • Oh, this works for Brown field. But ours is Green field. Sure, you cannot change the estimates given. But even in your Green field you still need to plan for releases and this will be very helpful even in that case.

What are the downsides of it?

  • Project status will be crystal clear for all the stakeholders. People can make informed decisions.


Check this post from Johanna on creating project dashboards to display progress

Create the Line chart with Markers in Excel sheet which displays

  • Total Number of Features to be delivered in the duration of the project in X Axis and
  • Duration of the project (Week wise or month wise) in the Y Axis

Velocity Chart

(A Velocity chart for one of the projects i managed in 2009. This Snapshot was taken sometime around 26-Jul-09)

This will help you see the Features done on a week wise or month wise and the features left on a weekly or monthly basis. If there is a new feature or a set of features added on a specific period it will also show you a spike of the remaining features and anyone with common sense can understand what is going on in the project. If you need the project to be done on time, then most likely the Features done line and Features Remaining line has to meet in the middle.

What are the benefits of doing this?

  1. First, it gives a clear status on what is going in the project, how many features done, how many left and how many are newly added etc.
  2. Second, it helps the manager in clearly showcasing the changes that happens in the project. So no need to defend saying features added or modified is troubling the guestimate. In other words it helps in CYA…
  3. Third, the manager do not have to go to a techie to ask where they stand if he/she has to give a monthly update to the stakeholders.

What are the downsides of it?

  1. Project status will be crystal clear for all the stakeholders.
  2. Manager has to work. Apart from giving GYAN to the team members saying they need to be disciplined with their code, Manager also has to be disciplined in creating, updating and maintaining this which is quite some work. Of course, one can always find an executive assistant to do this. J
  3. Manager cannot blame someone else when things go wrong.

This sounds good. But how will it help me solve my estimation problem?

One may not get rid of the issue with estimates completely. But if this data is captured organization wide and have some way to classify data, you still have some scientific way to estimate rather than guesstimate  Of course, I do understand that every project is unique and the complexity varies.

An almost immediate thing which you can expect is

  • Oh, we don’t have such tools in our organization or project.  You don’t need a tool to do all this. You can do it using Excel sheet. Immediate response would be i don’t know how to create a line chart in Excel. All you have to do is type “Line charts in Excel” in Google and click “I am feeling lucky”. Of course one needs to read it which is beyond the scope of this post 😦
  • The other thing is oh, we are not agile. For sure, you don’t need to be agile to do this. Anyways most of us who claim that we do agile do not anything about agile.

IMHO, it is all about bringing in some discipline within the environment, and with a very minimal change everyone can gain.

Happy Learning!!!!

Image courtesy

ddpavumba /

The Estimation Myth

My discussion with Sendhil on this topic started after reading the recent blog post from Ron Jeffries on Estimation is Evil.

I had a wonderful opportunity to listen to Linda Rising (Author of the book: Fearless Change: Patterns for Introducing New Ideas) at the Agile India 2013 Conference recently on this topic Deception and Estimation – How we fool ourselves.

If you are a Manager or a developer or a Tester or Director or you do anything related to Software, listen to this talk. To me, Linda is one of the masters of storytelling. Watch this video and you will understand.

My version of the example on this: 

Count BeansHave you ever been to a local salon/barber shop on a Sunday?

In India, we don’t have the concept of taking appointments yet with local salons and the salon will be crowded with people. If you enter the shop say @ 10 AM, you will see at least 5 guys waiting and at the max the local shop will have 3 people working. Now the shop owner or the leader of this 3 will look at you and say 10 to 15 minutes sir.

You know for sure there are only 3 guys working and there are 5 people waiting to either get a haircut or shave or head massage etc… How in the world they will be able to finish the 5 + 3 in 15 minutes and attend you? If you are a logical person, who wants to leave they will still persuade you saying wait sir… it will be over very quickly and you most probably end up listening to this and spend few hours of your Sunday in his shop.

What does it communicates to us?

  • First of all we don’t have any clue on how much time it will take to complete a specific task (even with the guy who is doing the same thing his whole life) – > (Developer, tester)
  • Second, we as humans always want to communicate to the other person in the way he feels comfortable  -> (Manager)
  • Third, we as humans are always optimistic (even when we know that things cannot be achieved in a specific time) – > (Client)

Linda in her talk refers to a research where in as humans

  • If speak for ten minutes there will be 3 lies at least in that.
  • We are tuned to say and accept lies right from childhood. Example she quotes is that a Grandparent gives a gift to their grandchildren. Even though the child, doesn’t like it, as a parent one excepts their child to say “It’s a very nice gift and that’s exactly what they were looking for” 🙂

So how does it translate to our software projects?

  • If you are developing software for whatever period, there is no way you will be able to provide an accurate estimate.
  • If you are a Manager, even when you know that you will not be able to meet the commitment, you will still persuade your client saying that you will be on time.
  • If you are a Client listening to your vendor or to your own team, even when you know that it will not be done on time, you will still accept saying that it will be done on time.

In his book “The Mythical Man Month”, Frederick Brook mentions all Programmers are optimists. The underlying assumption of scheduling is that “all will go well”, i.e., that each task will take only as long as it “ought” to take. It’s a book (bible) for everyone who is into software business.

So much has been said / discussed about this topic. But even 30 years after Frederick Brook has written the first version of his book, nothing has changed. We still believe in the same model.

Young boy countingThe other side of the equation is that if I don’t know the numbers I will not know how much I need to spend and when I can go to market. How will I get bid for a RFP? How will I give a number to my CEO so that he approves the budget?

As a Manager, it is very clear that one need to still give estimates as the Top Management/Middle Management with whom you are dealing with doesn’t understand this and they need an estimate. So as a manager, one do not have an option, other than giving their gut feel numbers.

But is there anything that can be done which can help us and in turn we help the senior management and top management to make some informed decisions?

Let us see it in the next post…

Happy Learning!!!!

Image courtesy


Arztsamui /

People are not your most important asset!!!

If you are like me, your eyes would have popped out by reading this title. I am reading “Good to Great” after a very long time and am seeing newer perspectives after i started reading this book.

Read this statement now.Right People

People are not your most important asset. The RIGHT people are.”

Jim Collins in his book “Good to Great” defines “the right people” as people with excellent character attributes than specific educational background, practical skills, specialized knowledge, or work experience.

Not that specific knowledge or skills are unimportant, but great companies view these traits as more teachable (or at least learn-able), whereas dimensions like character, work ethic, basic intelligence, dedication to fulfilling commitments, and values are more INGRAINED.

Definitely these are not theory. He has written this after researching so many companies for 5 years. I am sure people who are into hiring and executing projects for some time will definitely agree to this.

A must to keep in mind if you are into hiring…

Happy Learning!!!

Image courtesy of stockimages /

Together Everyone Achieves More!!!!

After a very long time, i started reading the book “The Five Dysfunctions of a Team” again. One of my all time favorites. Wanted to post the summary of five dysfunctions, so that i can revisit the summary whenever required.

1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to Results

  • Absence of trust among team members. Essentially, this stems from their unwillingness to be vulnerable within the group. Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust.
  • This failure to build trust is damaging because it sets the tone for the second dysfunction: fear of conflict. Teams that lack trust are incapable of engaging in unfiltered and passionate debate of ideas. Instead, they resort to veiled discussions and guarded comments.
  • A lack of healthy conflict is a problem because it ensures the third dysfunction of a team: lack of commitment. Without having aired their opinions in the course of passionate and open debate, team members rarely, if ever, buy in and commit to decisions, though they may feign agreement during meetings.
  • Because of this lack of real commitment and buy-in, team members develop an avoidance of accountability,the fourth dysfunction. Without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team.
  • Failure to hold one another accountable creates an environment where the fifth dysfunction can thrive. Inattention to results occurs when team members put their individual needs (such as ego, career development, or recognition) or even the needs of their divisions above the collective goals of the team.

I found a link to an assessment. If you are running a team, you may find it useful!!!

Building and maintaining a team is hard work and can force even the most seasoned professional well outside of their traditional comfort zones.
Professionals have disparate work habits, communication styles and levels of emotional intelligence.
Getting everyone to pull in the same direction can be tough work!
Via : Five Dysfunctions of a Team – Summary

Useful Summaries

One of the patterns i started seeing with all these special books are that, every time you read you will get an interesting perspective from the book. Its very important to have a list of books that you may want to reread every year.

Happy Learning!!!

Guidelines for successful offshore partnership

Offshoring is not new. People have done this for many many years. Some have really become successful using this model and some couldnt gain much out of it.

You still see new requests everyday for a partner or a change in partner. If people have done this day in and day out, then identifying a partner should also be fairly easy. Isnt it? But the answer is NO. It is still not easy to Identify a Partner. Even if you are lucky with your partner selection, sustaining your relationship for a long time is not going to be an easy job.


Image: vichie81 /

Who is this Guideline for?
This Guideline will be applicable only if you have the following in your criteria.

  • You are looking for a partner for your new product development.
  • You need an extended development team offshore
  • You are very specific about code quality, maintability and extensibility
  • You want quick turn around time
  • You need Senior Management Attention and Guidance
  • You need excellent technical resources to build your product
  • You want agility

Guidelines during Evaluation
Every corporates website looks good. Companies have really mastered the art of messaging. So, how do you identify the right partner?

1. Define your criteria for the target vendor (Technology Stack, Size of the company etc.)
Most of the offshore vendors are technology partners. IMHO, it’s not worth identifying a partner based on domain experience. Its always a nice to have.
Size of the company definitely matters. Assuming you are developing a product with 6 offshore resources. If the vendor is of 500+ in size, its very difficult for you to get their attention. Your vendors are in Services business and not charity business. Large size teams are their focus area. From your side, you need the attention from the Senior Management.

2. Do enough research about the company.
Look for Blog Posts, Linked In Profiles, Reviews (like mouthshut).
Assume that the Vendor claims that they do agile. Look for any blog posts related to agile, TDD, BDD, Pairing, Acceptance Tests, Continuous Integration, Continuous Delivery etc… If a company is excited about a certain thing and if they feel that its their culture, DNA, etc… it will definitely show up as blog posts. Ask for the Burndown charts, Retrospective notes, Action items etc… of couple of Projects.
It will give you a good perspective of the company.

Whatever is been sold, see whether its part of the organization culture or is it one single team which is doing that. Say for example, agile may not be the way most of the projects gets executed, but because of few individuals one particular team might be doing agile really well and obviously the organization would sell that. Now, if it is not part of the organization culture and the few individuals leave the company, you are stuck. So, spend enough time in understanding this.

3. Look at the Senior management profiles in the company.
Its very important to understand the senior management profiles (upwards of Project Manager). Say for example, if the company claims itself as a Technology company and their senior people have never done any development, to me its a definite smell.

Another reason: If you are building a platform, a normal business application developer will not work for you. The Senior Management team in the offshore partner has to understand the kind of resources needed to do the work. Otherwise its counted as another FTE and you may not really get the value out of it. For that, the senior management should be able to understand technology.

4. Shortlist companies based after the criteria

5. Initiate the Discussion

6. Understand how the development works with your vendor. People like to position their best people during the proposal period, but they may not get involved in the project after the proposal

7. Understand the hiring Process. Your vendor may want to position some account manager/delivery manager to take care of the engagement. See whether he has good understanding of what you are looking for (agile, TDD/BDD, Automation, Technology stack etc..) IMO, everything starts from the engagement leader. If he is aligned with your objectives, you will have a very good offshore relationship.

8. Get the Proposal. Look at the details. A Proposal should contain more meat related to the current work under discussion than 50 pages of marketing material.

9. Finalize and Get Started.

Guidelines during Execution
Your actual work starts once you have finalized the vendor, sign the contract. Moving from a Vendor to Partner has to be initiated from both parties.

0. Get Involved in the Hiring Process.
Everyone likes to talk about getting an extended team offshore, but reaching there is not simple. It starts with Hiring. Today, every other vendor says we do coding tests. Great, ask for the questions. When a profile is shortlisted and passed to you, look at the code and speak to the individual.
Make sure the key resources are filled with the right skill set (like architects and technical leads… Need the technology depth, breadth, awareness of industry happenings, ability to write clean code, ability to bring in automation etc…)

1. Build Trust with the Resources offshore (Vendor’s)
Show them that you care. Give your offshore resources enough time to get started. Understand that the 20+ years of your domain expertise cannot be absorbed by someone in 2 weeks.

Don’t try to squeeze the resources. Understand the meaning of sustainable pace and help them get there. If the resources are putting long hours offshore that means your cost of maintanence will be very high.

2. Do the work from your side. Meet your commitments, Answer Questions, Give them detailed specifications before development starts in a sprint

3. Visit the offshore team once in six months (atleast)

4. Get your team visit your place and work next to you (on a regular basis)

5. Help them build best practices from day one (whatever was sold to you during the sales process)

6. Have a Successful offshore relationship!!!

Prakash, this looks like lots of work. I thought once i outsource, the load is off from me and the offshore partner will take care of it. Yeah… all these are applicable, only if you want an extended team offshore/near shore/some shore. Not a vendor outside!!!

Good Luck and Happy Offshoring!!!