Good design achieves firmness, usefulness, and delight. It’s relatively easy to translate the first two of those ideas to workflow automation design: whatever we build, it should consistently do the job we want it to do at the scale, speed, and quality that we need. The first step of a good design is to decide what we want to accomplish. Encoding workflow saves time and effort over the long-run, but it also requires being explicit about what workflow is in the first place.
Data science is currently very good at coming up with answers. It’s not very good at coming up with questions. I believe that requires data scientists to pay more attention to building non-technical skills, but I think it also requires us to build more tools that facilitate that part of the process. In fact, building the tools will contribute, in large measure, to building the non-technical skills.
A data scientist skills framework should take the big, messy data-scientist-by-data-scientist’s-skills matrix and try to reduce it to a few informative dimensions that minimally overlap. A skills framework establishes common ground for conversations, even when those conversations are among people of wildly diverging perspectives. A good framework doesn’t guarantee that a conversation will be productive, but a bad framework comes pretty darn close to guaranteeing that it won’t be. If we can be more clear and precise about what a data scientist needs to be able to do, we can make both groups happier than they are now.