What’s wrong with Autodesk? Part I, Feedback Mechanisms

In the past month, I was part of a conference call with Autodesk and industry technical artists about integrating .NET into Maya (and how we use it in game development), and a couple weeks later we also had a couple Autodesk reps visit BioWare Austin to talk about their consulting services and get feedback. Both were very honest and constructive discussions. I said what I wanted to say and felt I got honest answers. It was fun to take them to task about a variety of things, but more importantly, it gave me a much more nuanced understanding of the external problems with the company. I’m going to go over them in the next series of blog posts.

Problem 1: Feedback Mechanisms

Once, when a woman made a request of him as he passed by on a journey, he at first said to her, “I haven’t time,” but afterwards, when she cried out, “Cease, then, being emperor,” he turned about and granted her a hearing. -Cassius Dio, Roman Histories, 69.6.3

The above is a famous quote about the Emperor Hadrian, who was famously approachable. It is this lack of approachability that is the first and most fundamental correctable problem with Autodesk. There is simply no good feedback mechanism for Autodesk users. (I’ll explain in my next post how this is technically false but effectively true). Whenever I rip on AD to their faces, I always have brief guilt when they respond with ‘You need to tell us about it so we can fix it.’ And they are, of course, correct.

I have the same issue with my tools at work- if people are having issues, I need them to tell me about them. Every day. Until I do something, even if that only means getting it into Hansoft and on the schedule. But they don’t- the teams that do it the best have been cultured to do it. The animation team, which I’ve worked with the longest and thus has the longest history of support, is the best at requesting tools and demanding support. The environment team, which has traditionally had little and poor quality support (though, admittedly, far simpler requirements) often doesn’t respond even when things are crashing.

I think we, as AD customers, suffer like my environment team does. We are not used to getting support from AD and are unsure of the people we’re dealing with. This falls squarely on AD’s shoulders; when we report issues, we need acknowledgment even if we can’t get immediate results. When we see changes, we need to know what prompted them, and we need to know when our prompting causes changes.

In most ways, my position and Autodesk’s is fundamentally the same- we are both tools producers. The difference is the route feedback and requests take. In my case, they all must be balanced against a schedule driving towards a creative vision (a videogame, film, whatever). The people using the tool must communicate upwards to the people scheduling me, and they schedule me to work on what they deem most important. There’s conflicting pressure from below (users) and above (planners). In AD’s case, there is not that conflicting pressure. It is the users that should be driving the development of the middleware. It is still important for AD to provide a vision (and I don’t believe they have the right people to do this right now), such as ‘a plugin model architecture’ or ‘bloated with features’, but that vision is only relevant towards how it accomplishes customer requirements (‘creating a clean API’ or ‘writing a closed but fast tool’).

This lack of feedback mechanism is undoubtedly the biggest problem I have with Autodesk- they are a company that doesn’t seem to communicate with their users. But there’s actually a dirty little secret only the most privileged of lead artists at the most wealthy of studios know: Autodesk actually has important and serious feedback mechanisms. Confused? You should be.