If your virtual team is resistant to using new technology, or you’re suffering update fatigue, (I’m looking at you, Microsoft Lync/Skype/Teams/Whatever’s next) I want you to think about this quote from the head of the Roman Empire in England in the year 80:
“I lay aside all hopes of any new works or engines of war, the invention of which has reached its limit and in which I see no hope for future improvement.” Because, you know, once you had the gladius what other weapons would you need? Stop inventing and finish building that wall, darn it!
Now, I understood what Sextus Julius Frontas meant. He had the best army in the world. If his men would just use the weapons they had well, they wouldn’t need new ones, so stop whining. The same is true in today’s business world.
As the leader of a remote team, you rely on the team tools you are given to get your job done, and just when you get everyone on board, there’s something new happening. Worse, it feels like the upgrades are disruptive but not necessarily an improvement.
We find ourselves asking: Why are we getting a new version of Teams when we are using only 20 percent of the tool we have now? Is the time spent learning a new tool going to be worth the short-term lost productivity and chaos?
Yes, there are communication challenges that need to be met, and somewhere a software engineer is locked away pounding pizza and energy drinks trying to upgrade Slack so it does something slightly better than it did yesterday. That’s as it should be. But let’s acknowledge something else. It’s exhausting.
Here are some guidelines for overcoming update fatigue and deciding when you need to invest the time in new tools. You may argue with these, and I’d love to hear your logic in the comments.
Are you leveraging the existing version of the tool?
If you’re not using the tools at your disposal well, will an upgraded tool make much difference? Honestly assess if what you’ve got now could get the job done, assuming you actually used it properly.
Do you know what the upgrade/change is supposed to accomplish?
When you’re exhausted and cranky and you suddenly have to stop what you’re doing for an upgrade to take place, remember this: They upgraded this for a reason. Sometimes it’s a good reason (security, functionality) and sometimes it’s more trouble than its worth (hey, we’ve added a new font!) Is there a compelling reason to make the change? Ask yourself (or your IT team) this question: How will this change impact the work we’re doing?
Is the upgrade “before the dot or after it”?
This sounds geeky but this one really matters. In the world of software development, you often see version 2, but then there’s 2.1, 2.2 ad infinitum. A change “after the dot” indicates small changes which might be important but don’t radically alter the look, feel, or functionality of the technology. A change from version 2 to version 3, though, usually involves significant changes (whether they are upgrades is open to debate) but it will look and act different in some important ways.
Does the rest of the world need you to adapt?
Individual people and teams can make anything work if they are motivated and develop work-arounds. But if your customer relies on outputs in a specific version of the tool, or your organization is rolling out the latest version and your refusal to change will impact the work flow, suck it up buttercup.
Do you have someone on your team who can be the guinea pig?
Most teams have that person who loves new tools and can’t wait to play with all the latest gadgets. Rather than inflict unwanted change on everyone right away, perhaps have that person try out the new version and identify the really important information their co-workers should know. If there’s an improvement to work flow, or a trick to speed up the work, people should know about it and will probably embrace the change more willingly than if you all have to do it at the same time because you were told to.
Since it’s unlikely that “they” will stop inventing new tools, we need to be smart about how much effort we put into adopting those changes, and make them work for us instead of driving us crazy.
What’s your take on this? We’d love to hear it in the comments.
ABOUT THE AUTHOR
Wayne Turmel
Co-Founder and Product Line Manager
Wayne Turmel is the co-founder and Product Line Manager for the Remote Leadership Institute. For twenty years he’s been obsessed with helping managers communicate more effectively with their teams, bosses and customers. Wayne is the author of several books that demystify communicating through technology including Meet Like You Mean It – a Leader’s Guide to Painless & Productive Virtual Meetings, 10 Steps to Successful Virtual Presentations and 6 Weeks to a Great Webinar. His work appears frequently in Management-Issues.com.
Wayne, along with Kevin Eikenberry, has co-authored the definitive book on leading remotely, The Long-Distance Leader: Rules for Remarkable Remote Leadership.
0 comments