Managing expectations is something a Software Engineer needs to practice routinely. In fact, this applies to all careers, not just Software Engineering. Being a Software Engineer though, it’s easier for me to relate this to you from that perspective.
So, what does it mean to manage expectations? It means that before promising to provide a service or do something for someone, you and that person must have a clear understanding of what exactly is to be delivered and that you deliver on your promise. In this article I will discuss a few qualities Software Engineers must have in order to manage expectations more easily.
As an ambitious Software Engineer new to the trade, there’s a tendency to over-promise. When confronted with a project/task/problem, etc. there’s an urge to look at it and quickly go “Oh, that looks easy. I can do it in one hour.” What then happens is the Engineer gives the company management an estimate of one hour. The company could then give its clients or customers an ETA based on the employee’s estimate. Then the project starts. Now that the employee has to write serious code for it, he/she takes a thorough look at the requirements and discovers to his/her utter bewilderment that it may take a day! What happens then? Assuming all available resources have been expended, the project will generally get delivered late, breaking trust of the client/customer in the company and the company in the employee in question. In this scenario, the employee has not managed expectations properly. So what can Software Engineers do to manage expectations better?
A very important quality one needs in order to manage expectations properly is being able to ask questions when in doubt. When you are asked to deliver a feature or do a service and you aren’t really sure of how it is meant to work, don’t quickly cook up some assumption and rush off with it. Rather, ask a question or two. Don’t be afraid to look stupid for not understanding what is required. Even if you feel your question may seem naive, you should still ask it up front and gain understanding, rather than assume and potentially fail to meet expectations. Pardon my French here, but there’s a very good saying that sums this up. It goes as follows: Assumption is the mother of all fuck ups. So, in short, always ask questions when in doubt.
Also, you must be able to raise flags ASAP. When you promise to deliver something at a particular time, e.g. say you want to create a website X and have promised to deliver it in 2 days. What happens if after the first hour you discover a big problem with the task which you didn’t anticipate? Do you panic and start figuring out how to fix it on your own? No! A good communicator must raise flags with appropriate stake holders as soon as problems are found during task execution. As such, you should let your manager know as soon as you run into non-trivial obstacles. When you do this, it is easier to agree quicker on an appropriate course of action perhaps in terms of finding an alternate solution or letting a client know early that a project may be delayed. The earlier you raise flags, the better.
Furthermore, you need to know your strengths and weaknesses and be honest about it to others. If you don’t know about how to go about satisfying a need or approaching a problem, don’t act like you know. For example, what do you do if you are asked to say how long it will take to create some feature X, Y, Z which you have never even heard of or are only very vaguely familiar with? A wrong approach will be to take a superficial look and say, “Well, I sort of think it might take X days.” A more appropriate response should be “Well, I’m not familiar with this feature. Let us allocate some time to research on it and figure out how best to approach it and how long it will take.” Another example of this is in the aspect of deciding if to take on a task at all or not. If your boss asks you to perform a certain task and you know that you are weak at doing tasks like that and also know a colleague who is stronger at that sort of task, rather than say “Yes sir!,” do the task and complete it badly, a smarter response is “I can work on this task, but it may take me a while to do it. Person X here may be more suitable to do the job as he/she is better at this sort of task.”
In addition, you need to be able to give yourself a margin of error. If you are asked to quote how long it will take to perform a task and you have a gut feeling it could take say 2 hours to do it. Do not for the love of God say it will take 2 hours. What if there is some aspect of the task you haven’t yet considered and will only see once you start working on it? You need to be able to account for uncertainty. So a smarter estimate might be 3 or even 4 hours. So, don’t try to impress your boss with how quickly you think a task can be done, only to fail at it when actually asked to do it. In short, you need to give yourself a margin of error. This is especially important when estimating tasks on the fly in sprint planning meetings. Now, don’t go around doubling all your estimates in meetings. The margin of error you add to your estimates should be commensurate to how much uncertainty you have about the task at hand. So, for trivial tasks, you can afford to give estimates that match your gut feeling, but for bigger or unfamiliar tasks, you should increase your estimate by a larger factor. When you make a habit of accounting for uncertainty, you will find it significantly easier to complete tasks within your given time estimates and keep everyone happy.
One more things that is very important in managing expectations is being thorough. Before you promise to deliver something in a certain time, you need to make sure as much as possible that you have thoroughly analysed the task, thinking not just of regular use cases, but edge cases. In short you need to learn to ask lots of “What if” questions.
Another important point is that you need to be empathetic. Put yourself in the shoes of the person you want to perform a service for and honestly think about what he/or she will expect. Then, think of what effort it will take to perform the task and let that guide you on your promise to such client. Empathy is very important especially in places where you need to make assumptions for yourself because even though I have mentioned earlier that you should try not to make assumptions, we know there’re always some places where we Software Engineers must use our best judgement to assume things. So, if you must assume something about a service you provide to your client, think about it from your client’s point of view.
A final point is that you need to be willing to go an extra mile to complete tasks promised. When everything mentioned above fails, you must be ready to put in extra effort to get things done on time. This may be in the form of working longer, harder, faster or smarter. Ideally we should be able to deliver on our promise without too much extra work, but we know that sometimes things just don’t pan out that way. So, when the going gets tough as they say, the tough gets going.
In conclusion, I’ve talked about ways people, especially Software Engineers can manage expectations at work. This includes things like asking questions when in doubt, raising flags early, understanding one’s strength and weaknesses, giving margin for error before making promises, being empathetic and going the extra mile to deliver on promises. I hope you find some of these useful. Take care!