I played the role of “boss” for many years in my career, and I never liked hearing the word no from my team. There are, however, a few occasions where I found it not only acceptable but necessary. Let me explain –
Being in a position where you’re responsible for another person triggers a primal instinct of protector. At least for me, it does. This instinct tells us as managers to protect our team from outside pressures so they can focus on their work. In general, this is a helpful instinct, but it can turn bad.
Some managers take this “power” to their head and believe their job is to control their teams' actions as if they were cogs in a wheel that they could turn whenever and however they want. This is what we think of when we hear the term micro-manager.
In addition to this aspect of control that a manager may feel entitled too, they may also feel they need to be smarter than their team and will get angry anytime someone on their team corrects them or contradicts them. This leads to the “yes men” effect where the team is only comprised of people that will agree with the manager or leader regardless of their actual position.
The reality is, however, that managers are not generally smarter or intelligent than their team. They typically were just the first ones to do their job in a company and founded the team. Maybe they came over from another company where they were a manager, and they want to impose their will on this new team. If you’ve been in the corporate world for any amount of time, you’ll know that each company has a unique way of doing things so imposing a foreign way of doing things rarely works out and often leads to frustration for everyone.
In the world of data there is more at stake, so yes, there are times where it’s not only acceptable but critical that you tell your boss no. What I mean by more at stake is that bad or missing data can lead to bad decisions which can tank the entire company.
Not only are we talking about making a bad decision but also things like customer data security are at risk which can lead to people going to jail and worse, millions of people damaged from identity left and others scams.
The first example where it’s okay to tell your boss no is when you have potential data loss. I’m a fan of logging everything in case you need it at a later date. With storage prices at pennies per gigabyte and simple logging services to track all of your activity, it doesn’t make sense to skip any bits of data that might prove useful later. Of course, this is the rub, how do you know what data you'll need down the road? You won't…
This unknowable future in which you'll have questions about your present is why you need to log everything. Log all user activity in your app and on your site, all marketing efforts, sales transactions, HR moves, and financial results, everything. The only real way I’ve found to make this happen is to force it on teams as a requirement in their development cycles. Some may not like it, but if you provide an easy to use framework that can integrate with any teams efforts, it won’t be hard to start patching the leaky holes of precious data.
Contents
Scenario 1 – Data Loss Prevention
- You build a new app for a specific user group
- You launch the app and users start using it
- The amount of installs/downloads soar, and the team claims an easy victory due to their superior product design skills
- The product team surveys users asking what they think, they get mixed results
- Leadership wants to dig in deeper and ask about behavioral stats on usage of the app
- The team never implemented that, so they can't answer the questions
- Leadership is frustrated, tells the team to implement data collection
- The team spends weeks reconfiguring their app to track usage
- Customers don’t get any new features or updates for weeks
- Customers are frustrated and uninstall the app
- The product team adds the new data tracking features
- Because fewer customers use the app today, the product team lost all that historical data
- The leadership team never gets the answers they want
- The leadership team now trusts the product team far less than before
- Re-org happens, who gets let go?
Things don’t always work out that way, but sometimes they do, and because of this it’s okay to say no to your boss.
Losing data for laziness is the same as stealing cash from your own company
Data loss is unacceptable at all levels. If you disagree, or your leadership does, I’d question their commitment to being data-driven and using facts instead of gut instinct in their decision making. There are times when a team jumps the gun, and you can recover, but in general, I’m a believer that before any new product features or apps get launched someone from the data team needs to sign off that they have proper tracking in place. Otherwise, they could be in a world of hurt later.
The next scenario relates more to data governance, which is a term I hate but is incredibly valuable. The exciting thing about making an impact with your data is that the toughest challenges are non-technical.
Scenario 2 – Metric Confusion
- The business decides on a definition of “active user” for their tracking/analytics
- Marketing team buys whiz-bang new tool for tracking users on the site
- The new whiz-bang tool has a metric called “active users”
- This tool has no concept of your company definition of an “active user” and thus tracks them using different logic (aka incorrectly)
- Fast forward to the next quarterly leadership review and the marketing team presents “active users” using this new whiz-bang tool
- The standard company dashboard which the team has used forever shows a different number
- The leadership team is confused why two metrics with the same name are different?
- Chaos ensues, the blame game begins
- No one knows what to believe
This scenario is likely the most common I’ve seen in boardrooms. One team has a definition of metric A, and another team has a different definition. Conflict erupts, emotions run high, and most importantly data isn’t used to help aid decision making. Following these failures, teams go back and retool, perhaps have weeks of meetings arguing who is right and ultimately it’s a colossal waste of time and money.
In this scenario, it’s critical that you tell your boss no when they look to name a metric something that would conflict with another metric of the same name. This situation has to be the easiest thing to fix yet one of the most difficult as it hits home for those primal instincts of controls managers believe they’re entitled too. If you’re ever in this situation run them through the scenario above, have them ping me on twitter or even share this post with them.
The last scenario I want to cover is when someone presents data in a way that intentionally or unintentionally misinforms the reader.
Scenario 3 – Misinformation
- The Sales Team needs a report of the last campaign for an upcoming meeting
- They pull the data from the data warehouse and build some simple charts
- The charts aren’t 100% up-and-to-the-right, 5. so they’re worried they'll look bad
- They ask you to filter out records, or change the date range or perhaps even color things different to highlight the positive side of their campaign
- They present the skewed results and get a glowing review, even though the campaign wasn’t nearly as good as they made it seem
How you present information is as critical as how accurate and complete the data is.
A good designer can make the worst results appear to the best in history by merely adjusting fonts and colors on the page. In politics, this is known as “spin” and has led to some disastrous results in our history.
Telling your customer or boss no in this situation is just as important as the previous examples. You’ll want to make clear any filters or adjustments made to accommodate the customer request so that anyone consuming the information is aware something is off. Of course, your users will be upset, but it is the right thing to do and leads to more productive decision making based on data rather than “spin” offered up by teams phishing for accolades.
When it comes down to it, your boss isn’t smarter or better than you.
Neither are your customers. Telling either of them no is critical to learning and growth, both as a team and as a company. Your boss should do their best to create a working environment that inspires you to do your best work and get out of your way.
I am also a believer in roles. Your boss can, and should, overrule you at times. They don’t like the feeling of being told no and neither will you, but in both cases, there are times when it's necessary. In the end, they’re the ones responsible for making decisions. Just as you are obligated to tell them no in situations where appropriate, you are also obligated to carry out their requests with full effort even if you disagree. Collectively we all should embrace no as this is where learning happens and as painful as it is, is the most fruitful path towards growth.
Have you ever told your boss no?
How did it go?
Leave me a comment below; I’d love to hear your story.