Early Notification of Concern Shows Maturity

Somewhere along the way during my time at Microsoft, I learned that when there is a problem or a potential problem one should let other people know early. After I left Seattle I found that there are many people that haven’t learned this, so I’m putting my learning down in writing.

Why?

The reason to let people know of potential difficulties early is to allow other people to be prepared and maybe even help if they can. This is not just in terms of software development, but is a principle that should be applied to every situation where you’re not working alone. Let’s take a generic situation for example:

Danny has an important task to do tomorrow, but during the day he found out that he might not be able to perform the task tomorrow. He ponders whether to let his manager know immediately, but ended up not telling anyone hoping to wait until he knows for sure whether he can or cannot. After dinner, Danny finally decides that he cannot perform the task tomorrow and gave his manager a call. His manager understands Danny’s situation and will find someone else to take care of the task.

In this situation, Danny had 3 opportunities to notify his manager:

1. During the day when he knows performing the task might not be possible for him
2. After work before the next work day
3. Call in the next work day to let manager know

The best choice is #1. Why? Because it gives the manager the most amount of time to find a solution. The reason #1 is the best time is because you’re not working alone and people do depend on you.

Translating to software industry, these are the corresponding situations:

1. A short while before a deadline, there’s a possibility Danny will not be able to meet it due to whatever reason.
2. Very, very close to the deadline
3. Right before the deadline

You don’t want to avoid communicating with other people to discuss risks or uncertainty in a software project. Early notification allows you and others to either seek help or prepare a plan B. That’s why #1 is the best.

Option #2 is not as good since it’s closer to the deadline. In our example, it’s after dinner before work the next day. That’s cutting it pretty close for the manager. The manager now has couple hours to contact others to get help performing the task, but has less time than if notified earlier.

Option #3 is the worse. It’s already the next day and the manager has no time to look for someone else to help.

Let’s now look at some common reasons why people don’t notify early.

But, but…

1. Maybe I’ll later find out that I’m able to do the task, then telling my manager would have been unnecessary.

Yes, this may very well be true, but you should still let the manager know of the uncertainty. In software industry a developer’s mindset might be similar to this. Maybe he or she will be able to overcome whatever obstacle is in front and be able to meet the deadline afterall. Why notify if it’ll end up being ok?

What if it doesn’t end up ok? Typically not wanting to notify people is related to reason #2.

2. It’ll seem like I’m not as good if I tell people I might not be able to perform the task.

No, as the title of this post says, it shows maturity in handling situations. It’s not a weakness. Everybody understands that life is unpredictable. It’s even more so in software field where we are always doing things we’ve never done before.

I know it sucks to be wrong or to be seeking help. However, it will help you become even better by getting over the mindset that you have to always be right or know everything. Have the humility to recognize that and keep learning to get better.

Ultimately the end goal is to ship software or perform whatever task. If by notifying early, by getting help, or by preparing plan B allows the project to be successful, then the end goal is reached. However, if by withholding information and the project ends up being unsuccessful, then the team have not reached the goal.

3. But I have to do it because I’m the only one there to do the task.

First let’s understand that absolutely everyone can be replaced. Even a country has a president and a vice president.

In an organization if there really is only one person that can perform whatever task, then that’s trouble and you should get out of there.

Chances are your co-workers are competent and will be able to pick up whatever they need to learn. If not, get out of there.

An even better situation is when everybody knows at least some idea of key things such that the bus factor is not low. This is one of the many reasons why I like code reviews.

My Personal Experiences

I have been asked in interview this type of situational questions. I have also seen the benefit of working as a team to achieve a common goal.

For one of the projects that I worked on, I think about 4 to 5 weeks before the deadline I found that there is uncertainty whether the project can complete on time. I notified higher-ups to let them know of my uncertainty. Meanwhile I continued to do my best to make things happen. However, about 2 to 3 weeks prior to the deadline the uncertainty is still there, one of the higher-ups used his contacts that eventually helped us out.

I could have held on to the last minute to break the news, but doing so would’ve ruled out any possibility of getting external help. In the end the project is successful, and that’s all that matters. I handled the situation well and to the best of my ability.

Conclusion

When there are potential problems, communicating to other people is a sign of maturity and not a sign of weakness. People working with you will like you even more by handling the situation better. Be a team player. Have humility.