★❤✰ Vicki Boykis ★❤✰

How non-technical teams work together

I work as a data scientist. I’m also in my last semester as an MBA student. One of the most important things I’ve learned over the course of the program is how differently technical and business people think.

There is a huge push today for society to become technically literate, particularly given that the Robots are Coming. But the opposite is true as well. It is for technical people to understand the non-technical mindset, particularly given that most people, even if they work in the tech industry, report to executives who are well-versed in their industries and the nuances of corporate life, but are not necessarily technically savvy, at least in the way developers define it.

For example, many of the classes in my program so far have focused on group work of up to 6 people in a team, with the final grade being based on a submitted group paper or presentation. In theory, these classes sound a lot like engineering teams writing code: each person writes their own section and corrects any mistakes they make along the way. Then all of the changes get merged together in a single paper which is “pushed to prod,” aka submitted to the professor by a single person.

It’s apparent to anyone in the software industry that there is a specific set of tools for this workflow: version control, preferably Git (on GitHub or Stash), Evernote to save research, Sublime Text/vi/emacs to write, and the command line to glue it all together.

But this kind of workflow has an extremely steep learning curve that is not accessible to the majority of people. Why? Let’s start by looking at version control, for example. Learning version control is so far out of the scope of someone who’s worked in Word and Excel for their entire office life that it is not only never mentioned, but simply not even feasible to implement in classrooms teaching business students how to collaborate.

Let’s take a look at this very beginner Git question on Stack Overflow: How to revert a commit, aka “how to undo the last change you personally made to the shared document” and let’s list out all the concepts someone needs to be familiar with:

That’s just off the top of my head. And this doesn’t even get into the culture and stigma of not knowing enough about tech. Most non-technical people are too embarrassed to ask anyone technical at the office about how technical stuff works, for the same reason anyone anywhere is afraid to look ignorant. I know this was absolutely the case when I started out as an intern and continued for some time into my career.

I’m really intimidated by tech people. What if they think I’m stupid? They always seem to be in another universe, working on black screens. And,if I learn version control, who can I use it with? My colleagues are too busy. We will send files to each other via email, because it’s easy. Why do I need this?

For someone coming from the point of view of the GUI, this is an incredibly complex ecosystem to learn, probably as complicated as learning the rules of double-entry accounting for a non-accountant for the first time. (how is the balance sheet related to the income statement? why are these the primary ways of looking at money? what’s the difference between revenue and net income? whoa! cash flows!), with just as little benefit as learning it (how many engineers need to do the accounting for their organization?)

With classes lasting fifteen weeks (much less for weekend-only classes or half-semester classes,) there is not a lot of time to get into the subtleties of rebase. The work just needs to get done, as is the case in the real world.) I once was a TA for an intro to command line class and it took 2 hours to learn about creating folders, directories, and files, not accounting for the time it took to set environments before class. We never even got into pipes.

On top of everything, I’m in a part-time program, which means everyone is also juggling full-time jobs and families. There is no time to fiddle with ANY of this.

##So how do MBA teams collaborate in 2015?

The business world doesn’t collaborate the way the tech world does, but there is a suite of tools I’ve heavily leaned on over the course of my program.

Tools that are not used:

##Why analyze the tools business students use?

First, many MBAs will go on to be tomorrow’s executives — people who approve budgets, set ROI rates, and listen to you make the case about why your department needs Redshift or needs to send people to Strata. Making sure they understand what you’re doing is key to the success of your department, even if your department is just the CTO, talking to the CEO, who is your cofounder. The tools they’re using today are likely to be their frame of reference and comfort zone well into the future.


Dilbert is an exaggerated but often accurate example of how technical and non-technical people see each other, and it’s important to break through that wall and understand how the other person communicates to get any real work done.

Second, this set of tools is prime for someone creating something more efficient for non-technical teams that is not just project management or communication. That something needs to make version control more efficient than 5 people editing a Google Docs document at the same time, but much easier than version control the way developers think of it. That something needs to probably be an abstraction of Git, needs to include video capabilities native to whatever it has, as well as the ability to chat and save chats, the ability to create Excel-like documents, to create simple graphics including Venn diagrams and bar charts, and to be easy enough to access from multiple places (work, home, school, mobile) and save states. This is extremely hard, which is why it has been tried hundreds of times by millions of companies (Evernote, Atlassian, Asana, Basecamp,and shudder Sharepoint.)

That something right now is Slack. This semester is the first I was able to use Slack, and it’s made running group projects a million times easier. This is not an exaggeration. Being able to see all conversation history in one place, instead of going into each individual Google Chat, being able to add calendar events, automatic reminders of team meetings from a shared Google Calendar, uploading files for reference, being able to @ everyone in a channel and have them receive notifications that they need to do something, setting up separate channels as placeholders for links to Google Drive files - all of this has made running a team project with asynchronous inputs MUCH less of a nightmare.

There are a couple features Slack is lacking, such as Google Hangouts-like functionality, the ability to screenshare and annotate files, a really solid project management component, and the aforementioned version control. But Slack is a very young company and has the potential to create many more integrations, which could move it to be the product that covers at least 70% of inefficiencies in the space. Unless there is something new on the horizon. Whatever it is, it better have Giphy integration.