I would be interested from the community, what type of people or organizations push back the hardest using collaborative software. I assist some organizations with Asana and am shocked at some of the professional people who won’t take the time to learn, mock implementation and actually stand in the way of collaboration. Some of course are stuck in Outlook, some can be the improper set-up of Asana, some can be training but in the end anyone that want to use collaborative software must make a commitment to learn. Do you think that some organizations are just better off never even trying to have them use such a tool. As you can tell I am a little frustrated today especially with management people who just don’t try. It may be the fear of being held accountable.
Was part of a team that introduced Yammer (before Microsoft took it over) to a large enterprise.
Key reasons I found where;
- They are seen as time wasters… People should be working rather than sharing some piece of information… This view was normal expressed by someone who was more than happy to spend all their day in meetings…
- They will lose their power by sharing knowledge. People seemed to be scared that if they shared their knowledge to lots of people. It would mean they weren’t indispensible anymore.
- Tangible Benefits. It was very hard to come up with some way saying what Tangible Benefit the organisation would get. Intangibles weren’t a problem…
Great question @JCarl and thanks for your input, @Woodsysnr. All good points.
I think this Guide article on inspiring team confidence covers your question very well. We can certainly sympathize! Check it out for primary concerns we hear and how to address them.
Key concerns we hear people asking:
- The current way we work is fine
- We have so many other tools we don’t even use
- I don’t want to have to learn something new
- It looks too complicated or technical
- My work doesn’t map well to tasks
- I’m afraid I’ll mess things up
- I’m unsure if I’m using Asana correctly
I agree heaps with the “We have so many other tools” comment even if they are used.
Currently where I am consulting, they have Yammer, Slack, Sharepoint, Jira, Confluence, Trello, LeanKit etc.
They are all good and tools like Jira, Confluence are specialised tools for specific purposes.
How Asana would fit in with all these tools is the challenge.
Hi @JCarl ! This is a topic I’m really passionate to speak about-- mainly because I have been a daily Asana user in my personal and professional life since 2010, not too long after the app initially launched.
Originally I was a Basecamp die-hard-fan, and I fell in love with the power and flexibility of Asana. Basecamp almost encourages its userbase to “grow out of” the product-- which is amazing in its simplicity and ease of use, which consequently would be the only “drawbacks” of Asana. I say “drawbacks” bc I personally don’t see any “drawbacks” in Asana-- only in that I run into these issues when I try to get other people to use the platform.
So
1) Ease of use it’s not very easy to get even a single person (much less two, or 3, or god forbid an entire company of 50+ people) to change his/her daily habits. Something must be done daily for 6-8 weeks religiously with the added intention to change a habit.
2) Co-operation from ALL-- So if there isn’t company-wide adoption from the top-down, nobody will even take it seriously.
3) Loss of Immediate Revenue– The fact that it takes at least a couple weeks to get someone to get accustomed to the new workflow means that immediate results/revenue will suffer-- this is at the expense of added value over the long-run, and multiplied exponentially by every new hire, because not only will you be improving old employee processes, these will become the new employee processes as well; it is almost like literally pulling someone’s leg when you try to convince the CEO it is a good idea to forego current revenue for any reason.
4) Difficult to change a process in the middle of doing that process
Imagine trying to change your car’s engine while you’re speeding down the highway; I think this is the ultimate reason why people and companies fail to change; AND, this is where startups have the advantage of being NIMBLE and QUICK and free of BUREAUCRACY; an existing company is slow to move because of layers of management with ingrained beliefs and processes; a 1-man startup operation can change his pricing and business model overnight and not need to teach the new system to 100 people; THIS MEANS HE CAN START SELLING OVERNIGHT instead of waiting for everyone to get on board.
I haven’t had a chance to work in a large Asana-style organization, I could be way off in my assumptions about the long term benefits this work culture.
@FATBOY I agree. It seems to me that top-down adoption is the best way to go and older successful people fall into the “if it ain’t broke don’t fix it” mentality. And @JCarl, I suspect in some cases people do have fear driven objections. For those of us who believe in the value of these tools, I daydream about an exodus from these old-school businesses in favor of next-generation businesses who “get it”; for the old-schoolers who refuse to get on board, I wish they’d go out of business from lack of talent ASAP to make room for more Asana-style businesses. I also wish there was a place online where we could easily find all the truly Asana-style businesses in our area and maybe even ratings like “top-down” vs “beginning implementation”; if I had access to info like that, I wouldn’t bother looking for work anywhere else.
@Alexis I’m hopeful about the future of this community site. Thanks for working to keep it alive and engaging!
My name is Omar
When someone says “hey Omar, ask PersonA for XXX for me, would ya?”
I say “no, ask him yourself, that is what Asana is for.” … “yea, just ‘at’ (@) the person’s name, it’s quite easy, just like talking to someone in real life, except it happens via this thing called the internet”
And even when these “someone’s” happen to be my clients, I still tell me clients to get the info themselves when I’m busy;
Because seriously-- who the hell (besides and awesome account manager) has the wherewithal to be a messenger?
Wasn’t the point of E-MAIL to solve this problem of needing someone to pass a message for you?
Example–
Client wants to know “where we’re at” with the project-- “ask the acct mgr”
Client wants to know “how’s the web dev going?” – “I dunno ask my web dev guy”
Obviously I will try to always know what is going on before my clients do; however that’s not always the case-- and it’s actually never efficient; it would be better if clients communicated directly with the people doing the work; well sometimes it’s good to have the “shield” of an account manager, so to speak.
I encountered something recently, a client and a vendor couldn’t get along, and for no other reason than they both had poor people skills, the deal is almost (not sure which way it’s gonna land) got killed because I allowed the sensitive client to speak with the snobby vendor… meh 
@FATBOY that Client vs Team vs Vendor relationship is interesting.
An Asana objection I heard once was, “it’s too much work onboarding clients”.
One of the companies I work with has decided to keep clients out of the Asana Or; only using Asana with active project team members. Have you ever brought clients into an Asana project and regretted it? Is it too much trouble to let clients into the Asana Org?
Hey Adam. I am trying this for the first time right now, but in reverse of your question. I am going through an EHR implementation so I required that my EHR implementation team all learn asana. But the experiment I am doing is having the VENDOR come into the workspace as a guest.
So far it’s working ok. The vendor set up the project with a ton of excel templates, and I’m working with them to see the light that things like the “issues log” and “actions log” are totally useless in excel.
@Kristian_Sekse, I’m glad to hear you’re leading the way with your team! Sometimes I like to use Google Sheets links in my task and/or project descriptions to improve the connection between what the task is about and where the work is being done. The ability to morph Asana to the unique team use case is a nice thing about Asana’s generic simplicity; some creative assembly required 
@Jason_Woods I’ve heard the same arguments on my end too. As much as I would love to see something like Asana at my work, there’s no real demand for something like it as a whole.
It’s a solution looking for a problem in companies with established processes and tools.
@atrain101 it sounds like you’re an avid Asana user. 
What draws you to Asana and where do you think the disconnect is between you and your team? What kind of work do you do, by the way?
I’m a system admin for a biopharama where there are more softwares and systems in play than I can account for. Introducing a NEW application into the mix that people must learn and simultaneously abandon old habits and processes is distracting and expensive to… Well… any established business.
While Asana could introduce some better work- management and communication habits through its UX, they are lessons that can be replicated in our existing environment through training and practice. Unless you’re working with a very small team, the cultural buy-in required from the business is large and can be imposing.
It took me a while to accept that it’s not the tools we have, but how we use them that we need to address first. So when I hear arguments about how Asana or Office 365 or Trello (etc) can fix everyone’s workplace problems, it comes off as short-sighted to me.
To adopt Asana at work is to adopt their philosophy of workplace management and communication. That’s not a bad thing, but it’s something that is better built from the ground up rather than wedged in later as a “solution”.
I still would love to use Asana as a daily driver, but only under the right circumstances.
I appreciate you sharing your story @atrain101. What you describe is logical and, honestly, something we see a lot. These are just the kinds of conversations we’re excited to have here in the Community! How teams are working, how cross team collaboration works across companies, what tools people use, and where Asana fits in.
We actually see companies where a single team adopts Asana, rather than a whole company. While some teams that are successful with Asana do adopt what you might call Asana’s philosophy of workplace management and communication, I would caution folks from thinking that is the only way to use this tool. In fact, it’s possible and sometimes preferable to integrate Asana into a company’s existing communication processes. You could compare this to wanting to go on a diet and choosing to change everything and go Paleo vs. taking it slow and starting by eating smaller portions. Paleo works for some, but it can be easier for others to make the transition by modifying existing habits rather than creating new ones.
I’d be curious to learn from Asana champions who introduce Asana to their team (marketing, CS, product, etc.) and see success with without completely changing existing company philosophies.
I hate to say this, but I am a little more cynical in my observations. I find most small business’s and non-profits highly disorganized and most of that starts in the corner office. I don’t think things get any simpler than Asana (there are missing pieces though) and where people have adapted it in a department they agree that it improves execution. This tends to make me feel that some people do not want accountability, some are not willing to learn on their own time, some just have difficulty with adding a rather structured overlay to execution. Having said that I come from a CPA background, so maybe I have always been checklist oriented. But I truly enjoy working with people willing to learn and improve their processes.
@James_Carl I’m similar to you in the regard that I enjoy working with people to flush out continuous improvement, but the fight against “this is the way I (or we) always done it” is really an eternal struggle against company culture, not individuals necessarily.
I’ve stopped trying to impose the philosophy and features of tools like Asana, as the quality of my work will always say more in the end.
If my employer notices an improved output from me, they may ask me how I achieved it. The reality is that I’m not going to say “oh well Asana is the greatest thing since sliced bread and everyone should use it”. I will share how I approached the problem and executed on it. Asana may come up in the conversation if it was involved, but the process is more important than the tool used to achieve a desired output.
I’ve been leading the charge in my department’s adoption for over a year now - while I would never say there’s fighting, there will always be some resistance to new things, especially if the team is smaller. It’s hard to see why a team of 2 or 3 needs something like Asana when they can just lean over and ask someone something, etc. But in reality it’s about efficiency and over time those side conversations add up!
What I’ve found is not to push a shift or major process overhaul. Start with a project - simple, like a meeting agenda, or large like an event. Ideally it’s something that many people in the department, regardless of focus, will need to know about or be involved in. If you set it up correctly, and use it well - I’ve found people are more susceptible to it when you start adding them to tasks as collaborators, etc. Of course, I’m in the perfect position to do it as a PM/Ops manager.
But ultimately the resistance comes from a central point - I’ve heard this mentioned a LOT by @Kaitie (and others) in her trainings over the last 15 months or so, but identify your organization’s ‘Source of Truth’ and I think it will help clarify things for teams who find themselves overwhelmed with different tools.
Example: Where do I go if I want to know what the most up to date deck is for XYZ? We’ve agreed that it will be housed in the decks project, etc. and so any time it needs to be updated, the request will be there regardless of where it came up (email, meeting, etc.). And that that is the “Source of Truth” - ie where do I go if all else fails, to get the right answer. (This may not be what yall mean when you say that btw, it’s just how I’ve been going about it).
All of these reasons aren’t unusual, they’ve been toted around as excuses in organizations. But the major reason is different. No real tool has brought the simplicity and elegance to do the collaboration piece well. Base camp started well but v3 is a mess. Yammer etc are genuinely time wasters and a noisy stream of chit chat after a while. Wrike is too flexible. Clubhouse is too simple. Anything from Microsoft is too clunky. Jira is too ugly and too “IT”.
Asana is somewhere in the middle. But it too is far from intuitive with its hoisting of some presumptions. All we need in any organization of any stripe–
-
We should be able to create multiple teams. These should not be tied to a domain name. That’s a weird choice by asana. I’d like to create various internal and external “teams”, and external ones such as vendors will have different email addresses.
-
We should be able to create projects and milestones and tasks and sub tasks (which is ok in asana) but then assign people to projects across various teams. We should neither be limited by organization nor by team. Why is a project tagged to one team? Who thought of this knuckle headed idea?
-
All the projects across teams (each project selectively accessible to allowed teams), should be easily trackable in ONE dashboard. One report. We should have pre set views by project, or by time, or by team, or by status. This is as simple as pivoting. A concept from 30 years ago. And yet none of the aforementioned “collaboration” tools have nailed this.
To me, wrike and asana come closest, but miss the cigar. Asana gets too noisy, doesn’t do well with customization of simple things like logos and themes (which goes a long way in people feeling comfortable), and that silly animation at every click is totally useless. Make it simple and quick, and solve the above very simple interconnectivity of projects, teams, and tracking thereof – and it’ll be a winner.
@MoreGreens you make some interesting points. I like the way you’ve broken down your thoughts. Your idea of Asana coming close but not being as intuitive as it could be bring up the philosophy that Asana is in the middle of the powerful and easy to use spectrum. While a Jira might be very powerful but not so easy and a Trello might be easy to use but not so powerful, Asana fits, as you say, “somewhere in the middle.”
I’m curious. It sounds like you’re an Asana user, yes? What has inspired you to select and implement Asana over other tools and does your team or entire org use Asana, or just you? I’m interested to know what has been successful and how you’ve gotten through the “fight” being discussed.
Thank you for the patient response. You’re right about asana being a middle ground. I’m not sure it’s a very successful middle ground though. The requirement of almost every organization is pretty much as I’ve described it above. I’ve been through a few, and worked with many, of different sizes. All of them use their collaboration tools with moans and groans and learning to live with woeful inadequacies. Which is surprising because the core need is pretty straightforward and has been consistent for about 30 years. Perhaps more. Asana has made some very limiting presumptions about projects and teams work which makes it utterly useless for real world scenarios of any putport. Sure, like trello or clubhouse, tiny teams are using it everywhere with pain. Doesn’t mean it’s cracked the code. I wouldn’t say we have had any success with asana. I just hope someone in the product team at asana is reading this. Thank you.