Going Above and Beyond – Without Going Rogue

A man with glasses and a suit jacket.

Posted by Kevin Miller

This blog post was published on the Built In platform on November 10, 2020.

If you’re like me, you don’t like to deliver only what is expected of you; you strive to exceed expectations.

Maybe that phrase is used in your annual review, and there is a larger financial reward for doing so. Maybe you possess a competitive spirit and have ambition to do more than your peers. Or maybe you were raised or trained to always deliver more than the bare minimum.

A long time ago, in a galaxy far away, I had a computer science college professor who would only give students a score of 90 out of 100 if they completed their coding assignment perfectly. To score anything above a 90, you had to go above and beyond and deliver a little something extra. He wanted independent thinkers, not robots just following an assignment. As a programmer for a decade, I lived by his lesson, and I always strived to think outside the box to add something more.

When I became a project manager, I found a new perspective on going above and beyond. I now view someone on my team going above and beyond as a risk — but only because it usually comes as a surprise. There is a cost to going above and beyond, and it is usually paid by a lack of focus and time. That’s called “going rogue.”

At What Cost?

When a developer adds a cool, new feature to an application that no one requested, time is spent conceptualizing the idea, designing it, coding it, testing it, no doubt changing it once the stakeholder sees it, retesting it and maintaining it. There is also an attachment to the surprise feature as he or she thinks it will be loved by all.

As a project manager, when I learn someone on my team has gone above and beyond unexpectedly, the first thing I wonder is: What was put to the side for this extra effort? Was a key requirement ignored? Was a business relationship neglected? Was everything tested as much as it should have been? Focus on the end goal was clearly lost, and time was spent on this new idea that no one else knew anything about.

A project manager has to be supportive of his or her team but must also balance that with completing expected deliverables on time. In a worst-case scenario, the extra scope is not desired and the stakeholders lose trust in the project team, which has now fallen behind schedule. In a best-case scenario, the stakeholders are pleasantly surprised by the extra scope, but they wonder what was left out — or why so much extra time was available.

Either way, trust is lost between the project team and the stakeholders. Going above and beyond can be, in every essence, blindsiding. A blindside with good intentions and good results is still a blindside, and that makes people lose trust.

The Simple Solution: Communicate

So what can you do about a team member who unexpectedly goes above and beyond? The answer is simple: more communication. With more communication in the beginning, surprises at the end will be reduced or eliminated. While the answer is simple, putting it into practice takes effort and commitment.

First, have an open and honest discussion with your team. Explain that surprises with good intentions can unfortunately lead to negative results. Reassure them that you want their ideas and input in order to produce a better product and help them succeed individually. In order to do those things, you need to hear their ideas early, which equates to them trusting that you will not steal or ridicule their ideas.

Cultivate the good ideas and always give credit where credit is due. Your primary role as a project manager is not to come up with every good idea. Your primary roles are to keep things on track and keep everyone informed. If you are uninformed, you cannot keep anyone else informed. Two of your secondary roles are to present refined ideas to the decision makers and to grow your team. You don’t have to support every idea, but you must be consistent with your reasoning and treat people with respect.

While dismissing or rejecting an idea is not the same as dismissing or rejecting the person presenting the idea, the person presenting the idea may think it is. You need to use some emotional intelligence and follow the platinum rule: To establish transparency and trust, treat others how they want to be treated. Yes, this will take some of your already limited time, but the payoff of a team with open communication — where they present ideas early, and you don’t get blindsided late — is well worth it.

A former boss once told me, “I don’t like surprises, and neither should you.” I consider that good advice.