Problem solving

Another of my occasional attempts to explain my work

I joined Autodesk in 2012 having chosen, and been chosen by, the Enterprise Data Management department. At the time, EDM worked almost exclusively with account data, i.e., the information the company uses to identify its commercial customers. As described in my first "here's what I do for work" posting, I began my work there, but Autodesk had decided to stop selling software by the box and to instead become a subscription business and that meant we needed to concern ourselves with a lot more than just accounts. So I created the broader role of Business Data Architect and went on to spend several years working in one domain after another, finding ways to make our product data and contact data and usage data, etc. more "fit for purpose."

In 2016 I moved into another sui generis role as a product manager for piracy analytics. This took me from improving the foundational data upon which others built business analytics to building those analytics myself. It was a great fit: I knew what our data was capable of, I'm good at developing and explaining analytics, and, to my frank surprise, I discovered I really like working with salespeople. This work was easier to explain--"I use data to find out who is stealing our software"--and tangibly productive: the amount of revenue gained from the leads these analytics identified was significant.

I was hired into and managed in the EDM period by a wise and patient person, mentor as much as boss. I was invited into my second role by another. That run of good fortune ended, however, when a new VP pushed out this latter manager and brought in another, who, lacking any practical knowledge of how to do the work, focused instead on convincing his superiors that the organization he inherited was full of incompetents. Though hardly threatened by this corporate cuckoo bird, working with him was intolerable, so I began casting about for my next role. An invitation soon came from the VP of Research, who was aware of my work on the MX3D bridge and who had read an internal memo I'd written about the ethical issues raised by data collection in public spaces. He invited me to join and then to take over our Data Ethics program. Now based in Autodesk Research, I ran that for about a year before creating and taking on my new role: Director of Data Acquisition and Strategy.

As mentioned above, a lot of my work at Autodesk has been driven by changes in how we sell our product, the so-called "business model transition" to subscription. My current work is necessitated by a comparable transition in how we make our product. Today, we create stand-alone systems of slowly evolving logic (AutoCAD, Revit, etc.) that deliver their capabilities via enormous chunks of software code. In future, those capabilities will be driven and delivered by increasingly capacious and intertwined machine learning models that evolve in response to the data fed them. Figuring out how to get, or "acquire," the data to build and grow these models is my job.

As more and more of the world is run on AI the job of data acquisition will become an increasingly common one. At the moment, however, it's a novel role, formally speaking, and there's not much explicit guidance on how to do it. That suits me just fine: I'm all about creating answers, especially when the question itself isn't even quite clear. Also, this is not, as they say, my first rodeo: the driving force is different but the job is not dissimilar to the Business Data Architect work mentioned above. For example, one of the key questions, then as now, is How much data is there and where do I find it? That was one of the first questions I tried to answer when I worked with our account data, using a single Sankey diagram showing where that data was created and consumed throughout our back office environment.

I think it's important that kids have some understanding of what it is their parents do with the majority of their time, so I seek opportunities to share my work with the boys (witness Felix crawling around on top of that Sankey diagram I just mentioned). With this in mind, I recently raised the question of "How much data is there and where do I find it?" with them. Specifically, I asked my boys how they would go about counting all the designs in Autodesk's computer systems. Their answers were illuminating, both of the problem and of their individual psychologies. Felix, displaying technical acumen but organizational naivete, said that it should be easy, you just needed to find the GUID (that is, globally unique identifier) for each design and count how many such IDs there were. Gideon, thinking as Gideon does, said that the key would be to find the person who was responsible for those computer system and to get them to do the counting.

In practice, the answer is a mix of both: we will need design GUIDs and mechanisms for counting them, and getting that will require working with our internal systems and data architects. These problems are always both technical and organizational in nature, so it takes a Felix and a Gideon to solve them. Fortunately, I'm both.