For 20 years, I have worked with researchers in academic settings to help them design, develop and obtain resources to support the research they do. Over those 20 years, I have cultivated relationships and developed partnerships to the benefit of these researchers, sometimes brokering relationships and other times developing partnerships on behalf of others. I am not advancing my own research or research interests. Instead, I am developing my own understanding of what others do with their research and communicating that understanding to other audiences. Knowledge transfer of this sort is somewhat common in academia, and in other sectors such as industry or non-profit organizations, this form of communication might also be referred to as marketing, storytelling, and/or knowledge mobilization.

In this post, I am identifying a nuance to this type of communication concept in research: translation. This term can apply to many different situations but is applicable to academia and research settings as an intellectual practice of learning information, weaving it with other information and context, and being able to communicate this “converted” content to a new and relevant audience that will readily understand the converted content but might not have understood the original learned information.

The Importance of Context

As a psychologist, observing, noticing, and relating are key components to studying and understanding behavior — and to telling stories. You don’t have to be a psychologist to develop these skills but it helps to have fundamental curiosity about behavior to be motivated to be constantly observing, noticing, and relating. Long ago, my research focused on how we remember things and the context that influences one’s ability to remember and remember accurately. I don’t actively research memory and context anymore, but context is still the most fascinating concept to me related to information processing, thinking, learning, knowledge transfer, and innovating.

A standard dictionary definition describes context as “the circumstances that form the setting for an event, statement, or idea, and in terms of which it can be fully understood and assessed.” The word is derived from the Latin term contextus, con for “together” plus texere which is “to weave.” It is this aspect of context and the process of weaving things together that I am interested in applying to activities I and others commonly practice today: translating information and bridging knowledge gaps.

The Act of Translation

Translators are skilled at the sort of translation communication described above. Translators are not just taking information and repeating it elsewhere or connecting people to the information. They are enhancing and adapting the information with the context included. They consider the audience receiving the information and guide their understanding. Weaving and integrating content and context changes the perception of the understanding of the original information, which often allows that information to become applicable elsewhere. The translator notices how the information has relevance in a different context, which enables the translator to make connections, analogies, relevance and see applications that wouldn’t have been possible using the untranslated information.

The skills involved in translation communication can be learned but must be practiced. The skills of observation, noticing and relating are critical. Considering the audience, perspectives other than your own, and context are essential to translation. It is also important to be able to draw relevant connections and be comfortable with experimenting with loose connections. Taking risks and seeking relevance far beyond the most obvious or intended context is where the most interesting translations take place. It is likely that you know of people who are skilled translators. In discussions, they are easily recognizable because they hear what everyone else is hearing, but they have a keen sense of being able to explain the content differently and adapt it, especially if other listeners are having a tough time comprehending the original content.

Translating information that originates from a different source can be a challenge. Credit for the original information/idea remains with the owner of that information/idea. The translator isn’t seeking to own the origins of information or ideas. S/he is interested in mobilizing information to new situations. Translators share.They don’t usually own. And in fact, this is one of the challenges to being a translator.Translators have their own ideas and their contributions are most powerful when they apply their skills to helping other people’s ideas find relevance outside of the original idea. Translators are quick to give credit to the ideas’ original owners. But they aren’t just the messengers of other people’s ideas. Their ability to weave and integrate content and context is their unique contribution to enhancing the original idea and helping it broaden its relevance.

When I have shared this notion of a translator, especially in the context of research teams in academic settings in which ideas are protected and coveted, the notion of a translator is met with skepticism but mostly from individuals who are not translators. When I share the notion of translation with people who are doing it, they immediately recognize their skills and behaviors and often have a sense of validation that someone else perceives these skills and behaviors to be valuable.

The Difference Between a Translator, Facilitator and a Knowledge Broker

Let’s imagine the following common scenario in academia.

We are in a team meeting.

An idea is presented and the “owner” of the idea has a particular way of presenting the idea. The way in which that idea is described could immediately resonate with the team members, especially if everyone has similar backgrounds and common knowledge about the content and ideas being discussed. But it also could be the case that some team members might not have similar training, backgrounds, or knowledge as the owner of the idea, and these members may not immediately connect with the idea. It is entirely possible that the meeting will continue and a gap will start to form between the members who understand the idea and those who do not.

In some team meetings, there may be individuals who participate with the express purpose of helping team members connect to one another and ideas. For example, a facilitator may participate on a team to create conditions in team meetings so that others feel welcome to provide their perspective on the ideas, and the facilitator ensures that the discussion is inclusive and equitable. The facilitator makes sure that the discussions can continue and that ideas are allowed to evolve or at least understanding around the idea can evolve. However, the facilitator doesn’t necessarily translate content around the ideas to make ideas more accessible. Instead, the facilitator’s role is typically to provide inclusive conditions so that the meeting can be productive around specified meeting goals.

In this same team meeting context, a knowledge broker might take the idea being presented, repeat it, invite other people to contribute to the discussion, relate concepts to one another, and possibly suggest the inclusion of other individuals and perspectives at future meetings. To borrow from Wikipedia: “A knowledge broker is an intermediary (an organization or a person), that aims to develop relationships and networks with, among, and between producers and users of knowledge by providing linkages, knowledge sources, and in some cases knowledge itself, (e.g. technical know-how, market insights, research evidence) to organizations in its network.” The knowledge broker’s role is to advance understanding and connect to the ideas being presented and to notice gaps or the potential for additional content and ideas to become part of the discussion. The role of the knowledge broker is to connect, rather than change or adapt the way the ideas are described and/or perceived.

A translator as part of a research team discussion absorbs and adapts the original idea, the context in which it was presented, the tone of the meeting and reactions to the idea, different perspectives discussed around the idea, and additional behavioral cues from the participants and integrates all of this information and observations into a new perspective on the idea and how best it may be delivered for the remainder of the meeting or following the meeting. Having absorbed and integrated the content and context, the translator can now notice how and when this new perspective on the idea might be relevant to other ideas, in other contexts, other perspectives and the translator is capable of presenting this new version of the idea in a new context and/or to a new audience without the presence of the original owner.

There is definitely some nuance to these definitions and these roles. I am not intending to suggest that one role, facilitator, knowledge broker or translator, is better or more relevant than another role. They can be implemented in different situations for different outcomes. But what I do want to emphasize is the depth of integration and transformation of the information that a translator can apply to content and that this is a valuable contribution, especially to bridge knowledge gaps, broaden participation among team members, and enrich understanding and comprehension in a collaborative environment.

What is missing from this blog is an assimilation and translation of published work relevant to this idea of translation. I promise a future post summarizing and translating this research, because I think the translator role is critical to collaboration and an often overlooked contributor. I welcome your thoughts, reactions, and suggestions to advance the notion and value of translation and translators.

Originally published at https://www.exaptive.com on October 7, 2019.

Some problems are complicated. Finding a solution requires expertise and analysis, but the solution exists. Sky scrapers are complicated. Some problems are complex or even wicked. These problems have no solution. They’re too big, too slippery, too thorny.

Public Health is a complex problem, if not a wicked one. The facts are dynamic. The outcomes are hard to measure. The notion of a solution is subjective. There is no “fix.” The same can be said of climate change, information security, or a complex disease, like PTSD.

These complex challenges require research, creativity, and discovery. They require working in the realm of unknown unknowns. So can innovation management software help?

Reach Beyond the Known

Most innovation management software shares a similar value proposition — capturing good ideas. An answer exists. Let’s find it, they say.

Good ideas get lost and forgotten. Employees and customers have first-hand experience and insights, about which no one ever asks. When they happen to ask, the input dies in the daily hustle and bustle, without a process to nurture an infant idea. The solutions are hidden or obscured, but they are known to some. Innovation management software can help collect and catalog ideas, and shepherd them forward.

But a dragnet of ideas from the field won’t solve a complex problem. The problem is complex because the answer isn’t known to anyone out there. And new ideas, in fact, appear to be harder to find.

Find Non-Obvious Input

If new ideas are harder to find, we have to think in unconventional ways. Some of humanity’s most interesting and impactful innovations are based on ideas borrowed from another field. These “discoveries” or “inventions” repurposed and combined existing solutions into something new, a phenomenon referred to as exaptation or the adjacent possible.

The majority of these breakthroughs, however, were inspired serendipitously. Gutenberg happened to visit a vineyard and see a wine press that inspired his printing press. An astronomer and a physician met at a cocktail party and discovered MRI software could be used to visualize nebulae.

Find it as a Matter of Course

Why rely entirely on conference happy-hours or facilitated brainstorming to trip over a breakthrough? Some innovation management products take the approach of Design Thinking, or they facilitate Innovation Games, to pro-actively generate new ideas. These creative exercises are invaluable, but they happen on a small-scale and rely on the recall of the human mind, unassisted.

Software can help find the non-obvious possibilities. The human brain can only store five to nine items in short-term memory. It can’t explore an entire solution space. Computers can though, through ever-improving data science and processing speeds. They can also digest the implicit — the metadata — while we’re focused on what’s in front of us — the data.

Innovation management software for complex problems should, as a matter of course, redirect our attention to unseen possibilities and connect us to non-obvious collaborators. It should analyze our bad ideas, just as much as the good ones. It should relentlessly find new perspectives for us to consider, measure which ones generate progress or improvement, and help us repeat the process.

Computers should not replace human creativity. But they can do some heavy-lifting that positions us to be more creative. With data visualization, social network analysis, and the science of team science, innovation management software can create the conditions that make it more likely we’ll find the adjacent possible and solve those complex problems.

To see how we approach this, walk through some of the software features we use to help find the non-obvious.

Originally published at https://www.exaptive.com on September 17, 2019.

The goal: investigate huge amounts of research data in new ways. The pool for teams: neuroscientists, data scientists, and software developers. The result: answering questions we didn’t even know we had.

The Set Up

Exaptive built a software platform: the Cognitive City. Just like physical cities, the Cognitive City has utilities: data and analysis tools any citizen can access. In the same way people make each physical city unique, each Cognitive City is unique due to the mission and expertise of the community. Researchers can even use this shared virtual space to meet, collaborate, and develop new analysis tools. The more work is done in the Cognitive City, the ‘smarter’ it becomes, as algorithms are refined to measure what matters. The Cognitive City then can make suggestions for collaboration partners, tools, and data sets.

Cohen Veterans Bioscience (CVB), a non-profit, is utilizing the Cognitive City to do all those things. They’ve sponsored the BRAIN Commons, which utilizes the Cognitive City to create a virtual, digital ecosystem where neuroscientists, data scientists, and really anyone who traffics in the translational brain health space can meet and collaborate. They can find resources and share them. Bioinformaticians can iterate on the code for analyses to ask new questions of data without having to rewrite an entire application. Dr. Terri Gilbert, Engagement Director of the BRAIN Commons, said, “The idea of being able to actually develop an application that could visualize data without knowing how to [code], I knew was amazing. And I could see immediately the applications for brain scientists.”

But until there was a hackathon, this was all in theory. Would it work? Exaptive data scientist Alanna Riederer took point on coordinating all the technical aspects. “What I spent most of the time on was getting some data access components together. And there were some specific data sets that Terri and Dan [Knudsen] had wanted.” Alanna worked with other Exaptive developers to upload the data sets to Amazon S3 so they could be accessed right away.

We had the software set up. The data had been imported and/or the API calls were ready. The next thing to do was test the theory. How much could be accomplished in eight hours on a topic as complex as neuroscience?

Getting Started

The first step was to get a high-level overview of the problem space: brain science. Terri spent about 90 minutes talking about the goals and challenges of brain science and explaining the data sets that were available for the hackathon. For the purposes of testing the system, we used only publicly available data sets. Dave King, founder and CEO of Exaptive, asked Terri to explain four things about each data set, “[1] Here’s the study. [2] Here was maybe the motivation; the sorts of questions [asked initially]. [3] Here’s sort of technically what the data means… And then [4] tell us everything that’s wrong with the data.”

Terri gave enough context with such great clarity that before the end of the overview, programmers were already eagerly asking questions to refine their new ideas for analyzing the data. The teams self-selected around four people who knew right away which data interested them the most. Each team had at least five members.

The Teams

A common pattern emerged as soon as the teams started ideating. Teams were forming around the goals of (1) connecting data to (2) algorithms and (3) displaying them with the right visualizations in (4) the context of answering a specific question.

Dave and Alanna’s team whiteboard their ideas

Dave & Alanna’s Team: Alanna knew right away she was interested in a data set that showed gene expression data in human brains that was collected at different ages. Terri, trained as a neuroscientist, was the subject matter expert in this group.

Team Cheese Tray (self-assigned name because they worked around the table that had the cheese tray.): Data scientist Frank Evans immediately wanted to see if there was another way to investigate the pairing of affected patients to control patients in a data set about traumatic brain injury (TBI). (The controls were +/- TBI and were matched based on age, sex, and PMI.) BRAIN Commons neuroscientist Daniel Knudsen joined this group.

Team Imajen Dragons (self-assigned name inspired by working with OpenSeadragon.): Developer Josh Southerland was ready to tackle the challenges that come with analyzing large image files within software. In this case, the image files were histological images and MRI scans. BRAIN Commons Associate Director of Data Science, Deepti Cole, was this group’s link to brain science.

Team Four: Exaptive information technologist Bob Barstead spent many years in research labs during a previous career as a geneticist. This team was the only one without a member from the BRAIN Commons. After running through several ideas that — upon further investigation — seemed to have already been turned into applications, they were able to get feedback from the subject matter experts and focus on creating a modular component that would connect to the Gene Ontology Consortium and retrieve all available information about a specific gene.

Building on Ideation

An incredible example Terri gave of how biologists and data scientists can work together came from the Allen Institute. The team at the Allen collected gene expression using a popular staining technique of all the genes across the entire mouse brain. One of their bioinformaticians suggested integrating all the expression data instead of looking at one gene at a time, to understand what the gene expression signal could reveal about the structure of the brain. Biologists were skeptical until they saw the resulting “ Anatomic Gene Expression Atlas.” Terri noted, “The biologists at the Allen generated really extraordinary data, but it was the information [scientist] or the data scientist, the bioinformaticians, who were able to visualize it in a way that the biologists could see it; see something new out of their data — something that explained how the brain was put together, and that wouldn’t have been visible had they just had the disparate data to view.”

Team Cheese Tray dives into a TBI data set

As the teams refined their ideas and decided how they would build useful tools, much of the initial conversation was question-and-answer. Team members had to figure out a shared vocabulary that could span programming and brain science. Developers asked brain scientists about what questions they wanted to ask of the data. Brain scientists asked developers to explain the limitations of data science. Terri noted, “Brain scientists understand the brain. They understand their aspect of study in the realm of the wet biology. In the process of doing that, they generate a lot of data. … The entire realm of information science and data is not typically what you learn as a biologist.”

It’s easy to see how the knowledge transfer process between scientists and programmers could get derailed in the everyday operations of a lab. Bob explained the situation really well afterward, “The problem is that the cycle time, the iteration between ‘here’s what I think I want as a subject matter expert’ and then the data scientist goes off and produces something and doesn’t really understand what they’re supposed to produce. And it takes weeks and weeks and weeks and in the meantime people are kind of losing track of what they’ve been attempting to do. They come back to the subject matter expert with this pile of data and try to explain it as best as they can but they don’t really know the subject.

“And what that should lead to is another round, because now we understand it better, and can communicate it better. But because the cycle time is so long, that communication is very difficult. When you have these kinds of dialogues, there’s a shelf life to the conversation. You think you kind of understand what’s going on, and then two weeks later you’ve kind of lost track of that entire conversation. And one of the great things about Exaptive[‘s platform], is that the cycle time for developing a data application is hours or days and not weeks.” With the direct exchanges during the hackathon, team members on all sides were able to get answers so quickly, they could then generate new questions they might never have otherwise advanced to at all, but if so, certainly not nearly so quickly.

The devs also soon discovered the challenges of working with brain data. A data set might have hundreds of data points, but the data points may be self-reported traumatic brain injury, which doesn’t include which part of the brain was affected. “The most surprising thing I learned during the hackathon was how little information there actually is with which to work as a brain researcher,” said developer Cory White. Cory was on Dave and Alanna’s team. “For all of the volumes of data or images that you might be able to dig up, there doesn’t seem to be much that you can do with it using manual processes. I realized how much of an opportunity there is to produce things that are really valuable in that space.”

The Reveal

After working intensely together for less than 24 hours, the room was practically vibrating with anticipation during the demos. Terri observed later, “Working on the edges of two different disciplines I think is where some of the best, most productive friction happens. I’m not a dev. I’m not a software developer. I don’t know how to build those kinds of tools. But I could direct and I could see things, and there were questions I could ask that had me feel like I could contribute to the ‘magic’ that got produced by the devs.”

Developer Austin Schwinn from Team Cheese Tray revealed the tool built out of the original question of how pairs are made for studies that match a patient with traumatic brain injury to a control patient without traumatic brain injury. They created a minimum viable product (MVP) that allowed for the user to choose a data set, then choose a variable to split the data from one set into two cohorts, and finally choose a second variable to examine how splitting the data on the first variable affected the distribution of the second variable.

Subject matter experts noted it was very helpful for adding context to the numbers and identifying dependent and independent variables. Developers appreciated their feedback. “It was amazing how much neuroscience information we were able to cover in such a short time and it really helped frame what the data meant and what it could be used for,” said developer and statistician Kent Morgan, also of Team Cheese Tray. “And it was super helpful having the subject matter experts in the room — or near enough to it — as we worked to get immediate feedback on what was useful.”

Josh demonstrated Team Imajen Dragon’s two prototypes. The first tool allowed for huge histology files (125+ MB) to be quickly retrieved and viewed with fast and clean zooming and panning capabilities. Their viewer tool performed even better than viewing the image from the local hardrive. Using OpenSeadragon for this tool showed the team that it was possible to do what they wanted to do. Deepti noted the team recognized a more secure way to transfer the images will have to be incorporated going forward to meet the high security standards for medical research data.

The second tool Josh demonstrated allowed for researchers viewing MRI images in a Cognitive City to annotate the images as they made observations. Every observation added a node to the user’s profile. This meant that team members could look at their map of collaborators and see which ones were making observations — and about which data. “It was really cool to see the process of building things and fitting it with my emerging understanding of where we’re going with BRAIN Commons,” Dan sounded blown away. “Especially in this space of interacting with the data, doing some interesting analysis, but also in people space. It was really cool to see [Josh’s] team connecting people with the annotations on the brain. [That] was not a use-case that I had thought of at all for the Cognitive City. At all. I thought it was all about people and, yeah, search terms that they might use and things like that. But seeing that a particular output of a particular xap was capturing some output that might be relevant to other people and connecting people on that? That was super cool and gives me all sorts of ideas.”

“Ours is more of a utility tool, to be integrated into other tools,” developer Stephen Arra drove the demo for Team Four. Bob explained later, “Because we didn’t have anyone from CVB on our team, mostly we addressed problems that I thought would be of interest. Or would have been of interest to my colleagues when I was at the [ Oklahoma Medical Research Foundation].” Rather than focus on a tool that better utilized specific data sets available, Team Four created a tool that could supplement any data analysis tool by incorporating the capability to aggregate external data about specific genes.

Dave shared his laptop screen for the final demos. Dave and Alanna’s Team had created a tool that could show gene expression over time by structure as the human brain grows. The tool also clustered gene expression signatures that had the same temporal profile. But all the gene names were short strings of letters and numbers. Wouldn’t it be great if there was a way to get more information about what scientists know about those genes of interest without having to leave the tool? It was a question Dave would never have thought to ask before the hackathon.

Exaptation: from Millennia to Minutes

In biology, exaptation is when a feature that evolved for one purpose starts serving a completely new purpose. The go-to example is feathers. Birds evolved feathers for warmth, but then feathers became important for flight. In software development at Exaptive, exaptation is when someone writes a piece of code or algorithm to do one job, but later someone else finds a way to repurpose it.

Exaptive data scientist Alanna Riederer coordinated the data ahead of the hackathon

As Dave finished his part of the demos, he realized he could use the component built by Team Four in the xap built by his team. After an almost imperceptible moment of hesitation, “Let me pause my [screen]share for a second.” Dave decided to try adding the component in real-time while the rest of the room watched, “Yeah, we’re gonna try this live.”

He used the Exaptive Studio to find Team Four’s component and reconfigured his team’s tool to include it. Three minutes and 19 seconds later, the new feature worked exactly the way he wanted it to. Everyone in the room applauded. The relief of having a successful live demo wasn’t the only reason. The cheer was loaded with validation of all the work of the previous seven years that had created a community-informed, data-driven, rapid-prototyping virtual space: the Cognitive City.

We’ll Do This Again

Having the subject matter experts and the developers in the same conversation made all the difference. It gave teams a chance to create several unique tools that improved the ability of researchers to query their data and gain insights that would have otherwise remained hidden. Hackathons are usually exciting because of the competition. Ours ended up being transformative because of the collaboration.

Terri is already looking to the future. “I could see holding virtual hackathons through the Cognitive City to allow people to meet up with subject matter experts, have developers from all over the world, and have Exaptive tutors as well, to be able to create really extraordinary tools that would forward the whole field,” she said.

Dave noticed having scientists embedded in the teams served as a constant voice, directing developers away from creating novel tools just to be creative. “The coolness of the technology, the size of the data set, the complexity of the algorithms. [Having embedded subject matter experts] turned us away from those things that I think programmers get excited about, and directed us towards what the real excitement is, which is these things can make a difference for people dealing with disease. Or they can advance the science and they can advance the understanding.”

We don’t think this experience has to be unique to brain science. This could be a model for innovation in many areas of research. The Cognitive City is a virtual space where transdisciplinary hackathons could happen at any time. Check back in with us for new articles as we do more hackathons in the future and make more discoveries about how they impact innovation.

Originally published at https://www.exaptive.com on September 16, 2019.

I presented at a conference recently on how co-production can bridge the gap between academic research and industry use-cases. Co-production in this context is people with different skills and perspectives working on a common goal. Marrying different skills and perspectives is what brings an idea born in research to life in industry.

A Tale of Two Doctors

In 1969, Dr. John Burke gave a tour of his burn ward at the Shriners Hospital for Children in Boston to an MIT professor of polymer science, Dr. Ionnis Yannis. The children’s bandages were failing regularly. Children were dying. Over the next 10 years, Dr. Yannis used his polymer engineering expertise with Dr. Burke to create the first artificial skin. They redefined the prospects for severe burn victims.

Glory! But maybe not so glamorous. Dr. Yannas reflected on their act of co-production, “When Dr. Burke and I got together and started working, that was a step very few people today in science or medicine undertake. It’s a step that requires working across disciplines, which means working in areas that you’re not comfortable with. Like I was not comfortable in Dr. Burke’s surgeries and he was not comfortable with my molecules. The fact that we got together was something that was very difficult. And I would credit this with the success that we eventually got.”

Co-production is hard. But that’s probably what makes it important.

Barriers to Co-production

Communication barriers can undermine progress without us even knowing it. People speak different languages — domain languages. We use the same words but mean different things based on our fields. Coworkers from a different department use acronyms that mean nothing to you. Colleagues from another field use abstract words that have little significance for someone outside their field. We are reticent to share our work when we feel it will be misunderstood. We tend to share our work once it has reached a level of completion that’s harder to misinterpret, and we usually only share success. We don’t talk about our failures, even though they create contain the most opportunity for learning.

We have misaligned, often unspoken incentives. Doctors Yannis and Burke were successful because they were aligned on the vision of creating a new treatment for severe burn victims. If Dr. Yannis had only wanted to publish a paper on the theory of his new polymers, they would not have achieved what they did as a team.

Making Co-production Work

The act of sharing incremental output — artifacts of your work — has a surprisingly powerful mitigating effect on these challenges. This can be anything from a summary of an idea to a tangible product of your work. Artifacts reduce barriers to communication because they provide context.

An astronomer approached a medical doctor to talk about nebulae. (It sounds like the beginning of a nerdy joke, but it’s a true story.) These two don’t have much background or know-how in common, but the astronomer came armed with years of data. With something concrete to look at, the doctor proposed running the data through MRI visualization software. The interaction launched the Astronomical Medicine Project, in which techniques used for 3D imaging of brains are exapted for the stars!

Artifacts are essential as co-production scales. Over the past year, we helped a major European Union climate change initiative, Climate-KIC, better understand in what areas their community have focused their work. We used a network visualization to show all the projects the initiative has funded for the past three years, and how those projects fit to the initiative’s goals. The diagram below became an artifact for the organization’s leadership to quickly see what areas the initiative has focused on.

In addition to this historical context, an artifact can be used for future decision making. By mapping the organization’s new 2019 funding requests onto the same visualization, leaders were able to make educated decisions on how newly funded grants would fit into and supplement their current portfolio.

Even more exciting, this same artifact can be used to support co-production within this community. It creates the opportunity to connect projects that are working towards the same goal but have unique approaches.

Try It Yourself

At Exaptive we use digital artifacts to scale this process and its benefits. But technology isn’t required. I challenge you to experiment with leveraging artifacts in your work today, without buying software. As you work with colleagues, ground your conversations in the context of common language and nascent ideas to create mutual understanding. Try using analogies you are both are familiar with or refer to previous projects or initiatives that are meaningful to you both. Let me know if you find it makes a difference, or if you need a little more guidance.

Originally published at https://www.exaptive.com on July 25, 2019.

Ever work in a place where you looked up to everyone there because they are experts at whatever they do and can pretty much solve any problem that arises? That’s what working at Exaptive is like. It’s a mix of expertise across various computer/data fields that works very well. Ever felt like you didn’t belong in a place like this?

It’s hard to work for a small software company and see everyone wearing multiple hats but see that you just have one that fits and doesn’t feel quite as important: designer. This can be internalized negatively by thinking you HAVE to learn something you may or may not be capable of to carry your weight. My first instinct was, “Well, I’m going to learn javascript so I can be more useful.” It’s been four years. I still know just enough javascript to be dangerous.

Image from The Matrix (1999), scene: Choices… and a Cookie

So what happened? There is a scene in the Matrix when the Oracle gives Neo a cookie, she asks him what a sign above the door says… Temet Nosce (know thyself). Was I hired to write code? Nope. Was I hired to design all the things? You know it. So why would this place want me doing design work for them? It took me a bit to come to this conclusion, but it’s because I am an expert. My grandma thinks I am an expert. She also thinks I hung the moon so I don’t think I can trust her completely. Coworkers? Yep. The boss? Yep. Sometimes others can see what is in us better than we can ourselves because we get blinded by our own perceived flaws or shortcomings.

Is all of this from a lack of confidence? I don’t really think so. I know what I can do. For me, it came from not always seeing how what I was doing is leading to better outcomes for our clients or helping the sales team put its best foot forward. Recently, we launched a new version of the website and I have started to better consolidate our collateral designs into a cohesive set of messages (thanks to Shannan, Jill, and Mike) to go along with a slew of conference appearances. The result has been hearing first hand how design has an impact, which in turn makes me feel like I am doing my part to help (without all of that pesky coding). Achievement Unlocked.

The bottom line is that if you look around and see a lot of great people in your organization and have self-doubt, don’t. Any place that will hire only the best considers you to be exactly that. Go own it.

Jill and I are going to embark on learning javascript or die trying.

Every year in July, Exaptive celebrates surviving another trip around the sun. When we reach major milestones, I make a poster for it. Here’s a look back at some of the milestones we’ve celebrated in the last few years:

My perspective: We celebrated the Studio MVP (minimum viable product) launch with bowling.

CEO Dave King’s perspective: The first milestone poster Derek ever made was this one, in April 2016, but the idea for it far predates that. In the summer of 2011 I was living in India with my wife, Deonnie Moodie, who was wrapping up her dissertation research for what would become a book about Kalighat Temple. I had quit my previous job in order to mull over the idea of starting Exaptive. Walter Isaacson’s biography of Steve Jobs had recently come out and it included an anecdote about Jobs that I hadn’t previously heard — that he had the early Macintosh team’s signatures etched into the tooling that made the Macintosh case so that they had all “signed their work”. I had my own background in art, having spent time as a fine-art photographer, so I knew the feeling of accomplishment that came with putting your name on a creation you had put out in the world. Job’s team had built a hardware device, which gave them a convenient canvas to sign. My team was producing software so I needed Derek to create a canvas for us. That’s exactly what he did with this first poster. We printed it out nice and big, had the whole team sign it, and hung it on the wall. More importantly, next to the signed milestone poster we also hung a long row of empty frames — motivating the team to push towards the next release.

My perspective: We were recognizing some important improvements to our agile development process.

Dave’s perspective: Exaptive was growing quickly in 2016, demand for our product had increased, we had hired more people, and we were experiencing growing pains. We needed to scale our processes. By Q3 of that year we had implemented a number of improvements to our agile process that allowed us to map our work onto goals much larger than individual ‘sprints’ . We called these larger work units ‘planning cycles’. I wanted to have a milestone poster that celebrated the team’s ability to build a process, not just a product.

My perspective: So-named because of the variety of Studio features that were packed into this release.

Dave’s perspective: As our processes improved, so did our bandwidth. The team was excited to tie up loose ends, clean up technical debt, and crank out a bunch of small but high-value features. When people signed the Kitchen Sink Release poster there was a lot of “I can’t believe we fit all that in!” We had also set up the engineering infrastructure to support continuous delivery and automated deployments — an engineering and devops accomplishment that changed our mindset, dramatically improved our productivity, and took our game to the next level.

My perspective: We launched a community edition to the Studio.

Dave’s perspective: We had been selling the Studio for a number of years but hadn’t made a free version that was open to the public. Since the whole goal of Exaptive is to facilitate innovation, we knew that it was going to be critical to allow more users to be able to work with our tools at lower price points. The Community version of the Studio was our first experiment with this, and it’s still available for people to use today.

My perspective: The company re-aligned around how the various teams intertwined to make the whole.

Dave’s perspective: A year later, the company had continued to grow. We had released many more versions of our software and we had set up new teams devoted to support and training and customer feedback. We started to see our own silos emerging within even our still relatively small organization. Individual teams were being efficient and effective, but it was increasingly easy for those individual teams to lose sight of how their work had to all connect to a common set of goals. It was time for another process optimization that got all of our teams in alignment.

My perspective: We released the long awaited xap store infrastructure.

Dave’s perspective: The vision of the Studio was to not only allow people to build data-science applications more easily, but to allow them to distribute the “data applications” they had made. We wanted to be able to embrace open-source, free sharing, but we also wanted to support entrepreneurs that needed to monetize their work in order to achieve sustainability. I have often felt like the closed-source/open-source debate is a false divide. Both models are symptoms of a larger problem. The Xap Store was an opportunity to experiment with building platforms that could support a mixture of the two.

My perspective: We were recognizing the company shift towards Cognitive City development.

Dave’s perspective: We had started Exaptive with a focus on lowering the barriers to data-science with the Exaptive Studio, but always with the fundamental mission of facilitating cross-disciplinary exaptations. (See more of Derek’s graphic design work in the form of amazing hybrid ‘exaptation images’ he developed to showcase famous historical exaptations.) We saw the potential to facilitate innovation with more personas than just data scientists, so we started productization of the Cognitive City platform in order to drive meaningful collaboration across all divisions of an organization, foundation, or consortium.

My perspective: This was the first release of Cognitive City base functionality.

Dave’s perspective: Our wall of milestone posters had been filled in — there were no more empty frames. So, obviously, it was time to move offices. The Midtown Renaissance team was renovating a great building in OKC’s new Innovation District. That seemed like the perfect place for a company trying to facilitate innovation. We moved into the new space early this year and found a suitable wall for the milestone posters. Derek’s designs continued to give people both motivation and satisfaction as we started adding features to the Cognitive City.

My perspective: We released functionality that allows users to populate the city with their own data.

Dave’s perspective: There is a great line in Clay Shirky’s book Here Comes Everybody in which he talks about the important difference between technologies that are ‘televisions’ instead of ‘telephones’. Too much of our technology is designed for passive consumption instead of active conversation. Ideas are networks, the lone-genius is a myth, and the Cognitive City had to make it really easy for users to enter content if it was going to democratize innovation.

My perspective: We released functionality that allows users to populate the city with their own data.

Dave’s perspective: There is a great line in Clay Shirky’s book Here Comes Everybody in which he talks about the important difference between technologies that are ‘televisions’ instead of ‘telephones’. Too much of our technology is designed for passive consumption instead of active conversation. Ideas are networks, the lone-genius is a myth, and the Cognitive City had to make it really easy for users to enter content if it was going to democratize innovation.

Originally published at https://www.exaptive.com on July 16, 2019.

Within a group, a team, a network, or organization that relies on members being connected to one another, connections can be based on a number of factors but almost always rely on the availability, awareness, and mobility of knowledge or information essential to the group. How does information move within a group or across groups? We are interested in identifying catalyzing actions that occur in group interactions to facilitate the ease of information and knowledge exchange and the establishment of new connections of members in the group. Research suggests that ideas have value to the extent that they can be shared with a new or different audience (Burt, 2004). This research also suggests that individuals who can establish new connections within a group bring competitive advantage to the development of new ideas within that group. In our experience, the purposeful translation of ideas to new audiences reduces serendipitous connections and takes advantage of certain individuals’ natural tendencies to broker these connections.

We have created a three-part activity to demonstrate how reducing information to small exchange units, translating them across audiences and brokering connections to new audiences can close knowledge gaps and create new ideas and new innovations. We have conducted this activity with audiences who have expertise in collaboration and collaborative work (e.g., research team brokers, scientific research teams, and innovation experts), which is contributing to ongoing work around the characterization of different roles in teams and measuring the value of interactions across these roles in the process of generating new ideas.

This activity involves 3 parts:

1. Self-characterization
2. Knowledge kerneling
3. Network brokering

1) Self-Characterization

This first part of the activity serves to identify three types of characteristics or natural tendencies in participants of the activity: experts, translators, and brokers. One way to self-characterize or identify natural tendencies is to complete a formal skills assessment. However, we have adapted this activity to work in presentation and workshop settings with limited time periods.

Participants are given a sheet of blank paper (one side longer than the other, e.g., 8.5" x 11") and asked to fold it in half long ways, then to fold it in half to bring the two far ends together, and then to fold it in half again. When unfolded, the sheet of paper now has eight equal rectangles, which are then each labeled 1, 2, 3, and 4 across the top row and 5, 6, 7 and 8 across the bottom row. The folding isn’t so important as the numbering. One could similarly label eight lines 1 through 8 but this part of the activity encourages participation and interaction among participants. It often sets the tone for participation and engagement and can serve to encourage interaction prior to other parts of the activity.

The numbers represent the order in which the folds are made in the paper.

Participants are asked eight yes/no questions to identify the experts (participants who were very content-focused), the translators (participants who can understand, extract, and relay information across domains), and brokers (extraverted participants who are excellent at “winning others over”). The eight questions we have used are:

1. I respect a hierarchy (Yes = expert; No = translator)
2. I prefer working toward concrete goals than meandering toward a guiding vision (Yes = expert; No = translator)
3. I am comfortable with failure (Yes = translator; No = expert)
4. I do not like to feel vulnerable (Yes = expert; No = translator)
5. I prefer to recognize others for their good work than to be recognized for my own work (Yes = translator; No = expert)
6. I prioritize milestones of completion over milestones of learning (Yes = expert; No = translator)
7. It bothers me when people use different definitions for standardized terms (Yes = expert; No = translator)
8. I love meeting strangers and starting up conversations with them (Yes = Broker; No = expert)

For questions 1 through 7, a participant responding with a majority of “yes” responses would be characterized as an expert. A participant responding with a majority of “no” responses would be characterized as a translator. This is not a scientifically-verified scale but the odd number of questions allows for a majority of responses in one category vs the other. Question 8 is the singular question that identifies a broker. This is not scientific but in our experience, it identifies the natural tendency to “win others over,” which serves to identify the skills needed to broker within this activity.

Once experts, translators, and brokers are identified, ideally participants would characterize into nearly equal numbers for the 3 types, although having fewer brokers will still enable the activity to work. If the numbers within each type are uneven, activity facilitators can make a few suggestions to move individuals from one type to another.

2) Knowledge Kerneling

This second part of the activity creates a knowledge base that will fuel the exchanges and connections throughout the remainder of the activity.

Experts: Each expert is asked to think about a project or an idea of interest. This can be a current or past project or idea or something they have given some thought to. Because the activity relies on sharing some detail on this project and/or idea, it is helpful if the expert can provide that detail.

Translators: Each translator is paired with an expert. The role of the translator is to listen to the project/idea details provided by the expert and reduce those details into what we are calling “kernels.” The translator should write the kernels down, preferably in list form, so that they can be shared with other experts, translators and brokers.

Brokers: Each broker will be asked to read the kernels produced by pairs of experts and translators and attempt to broker a connection to another expert-translator pair (see Part 3: Network Brokering, below)

The term ‘kernel’ is found in different disciplines including machine learning, mathematics, biology, and the like. For this activity, a kernel is a simple, understandable, discernable, and relatable element of a project and/or idea. This reductionist approach is likely familiar to translators who are practiced and interrelating concepts and ideas and often have to reduce these concepts and ideas to levels they can understand to enable sharing with others.

It can be an unsettling experience for experts to hear their project/idea reduced to simpler terms, losing detail or nuance. Experts can get frustrated or feel uneasy with this part of the activity. However, practiced translators will likely feel at ease and will not require significant instruction as to how to translate kernels about a project/idea.

3) Network Brokering

The third part of the activity is to share information across parts of the network, exposing new/different audiences to new ideas. The brokers play an initial role in making connections but the translators and experts will play roles in the development of new ideas.

With the experts talking to their translators, the translators will write down the kernels in large enough print and simply enough (no sentences) so that the kernels can be read by the broker without interrupting the expert-translator conversation. The broker is seeking to make a connection between two expert-translator pairs.

To broker a connection, the broker will suggest that two pairs join together (likely changing their location within the room) and the translators and the broker will discuss the kernels to determine if or to encourage the two experts to form a new idea together based on the kernels that were shared from their individual projects/ideas. The translators and broker will likely lead the discussion and translate the potential that they see across the kernels but the experts should also play a role in the idea formation.

After discussions have had time to evolve and new ideas have been created, a representative (possibly the broker) from each newly-formed group will present their resulting idea.

Postscript:

If time allows, participants often enjoy sharing their perspectives on this activity and can provide interesting insights into the roles they assumed and the ease with which they were able to participate in the activity.

Burt, R.S. (2004). Structural holes and good ideas. The American Journal of Sociology, 110 (2), 349–399.

Originally published at https://www.exaptive.com on July 10, 2019.

In the early 1990s, Burger King began an ad campaign that had a massive impact on consumers, especially in the United States. Anytime I hear the words, “Your way, right away,” I immediately hear the jingle that went along with it. The promise that you could have anything you wished — and have it immediately — was adopted in many sectors and pushed as good customer service, whether you’re in Human Resources and your customer is an employee, or you’re in Client Support and your customer is the client.

“Right away” hampers good development, interactions, and business relationships because doing good work can take time. Leaders (CEOs, COOs, CIOs, and others) often only have a few minutes to explain their work from a team of 50 or more people. That’s 26,000+ hours of work in a quarter, that the bottom line is being affected by. What if there were other metrics that could visually show a deeper story?

The concept of Exaptive’s Cognitive City innovation platform is one that can be overwhelming and a little hard to imagine. I spoke with our Product Owner Tom Lambert about a real interaction and exercise he did with a potential client. I realized it was a great chance to show our story.

Building Schema to Tell a Story

Every organization has facilitators, people who translate between departments and stand in the gap with relationships and project management skills to push work and the vision of the organization forward. Often, they have some kind of CRM (Customer Relationship Management) software, even if it is as simple as an Excel spreadsheet. They use it to keep people connected, organized, and on track.

The problem with this role is that it is really tough to scale. The information facilitators hold speaks directly to that individual who stands between organizational data and their own creativity while the visualization of the information is in their mind and can’t be scaled. The question the Exaptive team is working to solve is: what if this data could be alive and visualized in a way that makes facilitators and translators 10 times more effective? What if that could help them train others within their organization to use the available data in the most effective and efficient way?

Generally, we organize our data into rows and columns and multiple tabs in a spreadsheet. Tabular data gets overwhelming quickly, and doesn’t represent relationships the way network diagrams can. If you want to connect people to resources in a meaningful way, it helps to look at the data a little differently. Some people (usually they have titles like project managers, facilitators, or translators) are amazing at standing in the middle of projects or even organizations and making these connections possible. They know just how to keep work moving forward and in an efficient manner.

What happens when they leave the room? Will everything fall apart if those people can’t be engaged with every interaction? How do you share them when they are needed in many places at once? We need their imagination and explanations to anchor a team, a project, an organization. We need a way to capture the successful mental models they’ve created in a way that other people can understand and learn from knowledge typically locked in someone’s head.

Let’s go a step up from spreadsheets and talk about data visualization. Most people are familiar with these as pie charts or bar graphs. The charts created can be hard to work with because they are static. It is so much better to work in an innovation platform that:

• is alive.
• retains data, connections, projects, partnerships.
• can visually help create efficiency.
• has tools for data visualization.
• keeps teams connected and collaborating no matter where they are geographically.

Getting Started

We start with a diagram of the data you have. We call the diagram above a schema. You know your community and the people or actors inside, their attributes (location, age, degree, specialty, etc). You know the projects they are working on and everything about them. We call projects and other things created by humans artifacts (some examples: grants awarded, papers published, projects completed, initiatives worked on, clients won).

In this example, Tom had several meetings with the leadership of the small non-profit Rural Aspirations, which works to support innovation in education in rural Maine. The project in focus was the Maine Forest Collaborative, which would connect teachers with experts to supplement or participate in rural student curriculum. “Both my colleague and I are really action-oriented people. We see a need and jump in to do things,” says Val Peacock, education consultant and co-organizer of the Maine Forest Collaborative. “So when we first started doing this work, I don’t think we really understood all about … the different sort of capacities and skill sets [involved]. One of the things that came from working with Exaptive for me was [the realization that] what we’re actually doing is building a network around students.”

Tom took what he learned about the problems they were trying to solve and turned it into a linear dataflow (the above image). The goal was to not only visualize what data they had; it was to help them work toward getting better at finding holes, using data to illuminate gaps in planning or areas of focus they needed to consider to achieve future goals. Already we can see the story of this organization in the schema above.

While showing the organization their Visual City based on the schema with yellow boxes, they started asking questions about how the queries are structured. Their Visual City looks something like this right now:

Full disclosure: it took some work to get to this view. The first view of the group’s network diagram looked like a hairball because there was so much internal connectivity. “The network map wasn’t necessarily as clean as the schema, so we went through multiple iterations of trying to clean [the network view] up and make it usable for a teacher or a user. … It feels better now than when we first started, but the schema itself was the thing I think that helped us to clarify: ‘what are we actually trying to connect’ and ‘what are we trying to look at’ and ‘what do those edges mean.’”

Tom showed them the schema to help them understand how the data reflects their real-world understanding of the network they’re trying to map and grow. He then explained to them how Exaptive’s interpretation of the underlying problem they’re eventually trying to solve is the development of solid models for how private sector, public sector, academic sector, schools, and communities can work together to transform education systems so that teachers have easy access to all kinds of resources for students.

Data visualizations can represent what has been accomplished, but they can also hold goals and aspirations for future work. During Tom’s information gathering, he was able to identify data needed for this organization’s future. He added blue boxes which represented his understanding of the concepts that the organization would like to be collecting data for.

He took a chance in showing them this information and it was clear that it resonated with them in very real terms. They talked more about the data the organization don’t have yet, and how to create a system for getting that data through various mechanisms. Some ideas included apps that help teachers find experts who can present in classrooms and apps that let students evaluate projects and write stories about their experience so that when they want to create models to reproduce in other communities they have everything at their fingertips.

Creating the Living Network

This discussion process advanced the organization’s resource map into a living network. They began to see how to get from what they have now — a loose-knit and serendipitously innovative community — to what they want: a highly-functioning community where multiple sectors are focused on the common goal of helping students learn and be proud of their communities.

Within a few hours, they came back with their own representation of that network and what they envision it looking like (diagram below). Val notes, there’s a “real tension between talking about the work and doing the work. Sometimes we live in this abstract world of talking about what we’re doing and how we need to do it and really getting into the depths of the systems that were trying to build. … [That’s] not engaging to a lot of people. Some people are really sort of intimidated by that and not interested and it’s not helpful [for them] and so there’s this other part where to do the work, we need to simplify and clarify and bring it down to a usable” level for people in the network. Adding concrete action items to their schema helped reduce the tension between thinking about the work and doing the work.

The interesting thing here is that we’re now conversing in database schema with a customer in a way that couldn’t happen before. The ability to create graph database schema that represents the customer’s understanding of the real-world network is helping identify the critical information that’s missing. More importantly, once a partner like Exaptive knows the customer’s story, we can understand which tools are most important to build first. We can provide an innovation platform that captures the real world behaviors playing out every day in the organization’s network so they can identify and measure those behaviors. When they have a clear understanding of which behaviors give them the outcomes they’re looking for, they can reproduce them.

What are the patterns you’re trying to reproduce in your organization? If you don’t even know where to start, email me. We can talk through your data, goals, and team dynamics and help you develop a simple schema that shows your story. If you want to take a stab at it on your own first, download a free template by clicking on the image below.

Originally published at https://www.exaptive.com on June 12, 2019.

At some point in your life, you’ve found yourself describing a project you’ve worked on to a friend. They interject, “I’ve done something similar to this before,” and go on to describe a field or skill you didn’t know they were familiar with. You’ve just uncovered some dark assets about your friend: a set of skills or knowledge that were only discovered due to an accidental trigger.

This can be problematic when it comes to group projects, whether you’re working with an existing team or you’re putting one together. The people and tools available to you are limited to those you are aware of or those cataloged in scattered directories and lists across the internet. There are far more dark assets than known assets.

In order to build and branch teams more effectively and innovatively, we need two things: a map and a compass. We build a map so that we can see the dark assets. We equip ourselves with a compass to guide us towards relevant assets.

We like to use a network diagram as our map.

We use these networks to map people and resources. People could be resources, but we tend to distinguish people from inanimate assets, like publications or technologies.

We dub these people and resources “entities.” Every entity has “attributes” that describe it. For instance, people have interests, skills, passions, publications, and projects associated with them. A publication has a date, an author list, an abstract, and key terms. As I list these out, imagine how connections would form in the network between entities across shared attributes.

In the network below, you can see some shared connections on technology, for-profit, javascript, music, and sustainability and unique perspectives of Education, Social Good, cello, art, and AI.

In addition to the map, we need the equivalent of a compass — finer tools to navigate this environment. These tools illuminate the entities that bring the most complementary skills to our team composition.

• Suggestion algorithms allow us to find teammates that add complementary differences to our team. This is helpful for deciding which entities we should focus on in our map.
• Artifact-recording tools allow us to document and track ideas inside documents and see how they connect.
• Termscapes are a richer map for navigating the content that our community generates or studies. They are generated by analyzing unstructured text about a collection of entities and arranging those entities into a landscape of their terms.

Using these tools allows us to remove the accidental nature of discovering important resources. What tools do you use or wish you had to approach this problem?

Originally published at https://www.exaptive.com on May 7, 2019.

When I first started at Exaptive as a Media Specialist, I heard there was a Design Team, and that they had meetings. I immediately thought, That sounds like a team I should be on! I should go to those meetings. We use design every day in marketing and communications. So, I get to the meeting, and it turns out they are focused on designing the software and the data model.

I don’t code!

It was like being a woman and walking into a poorly-marked men’s bathroom. Everything looks right at first, until you see the urinal and realize you’re in the wrong place. Except at the design meeting, I couldn’t just turn right around and walk back out. That’s okay, because I stayed and increased my knowledge of what ‘design’ means to software developers.

What does this have to do with team building?

Context building is a huge part of collaboration. Any time you have a team that pulls together people with different levels of expertise or different kinds of expertise and different fields, they’re going to bring different jargon with them. You can expect some communication barriers, especially if you have two fields that use the same word for completely different things (e.g. “design”). More than just ironing out differences in jargon, establishing context among a team involves communicating complex mental models that individual team members have, until a group mental model develops and can be acted on. When we introduce data and technology with intention to the team building stages, we can optimize teams and make the whole process go much more smoothly.

What’s the team building process?

Forming, storming, norming, and performing. It’s cool that they all rhyme, but they’re legit stages. An academic named Bruce Tuckman was researching group dynamics when he wrote extensively about these stages of group development in 1965. Humans have been going through this process for as long as we’ve had to work together to survive. Now that we have tools to introduce specific kinds of data during specific stages of the process, we can get teams from formation to performance much more quickly and with less conflict.

What we’re seeing at Exaptive is that when you bring people with unique perspectives and skills together — and you bring them together around a goal — they start communicating. They start sharing stories, and they use the things they have in common to create analogies. These analogies help the other team members understand quickly the value each unique perspective brings to the team. We developed the Sticky Note Exercise to do this in a fun, data-limited, analog way. We’re developing the Cognitive City innovation platform to do this in an engaging, data-unlimited, digital way.

Successful team formation is all about resource discovery.

The first thing you have to do on a team is form it. Who’s going to be on it? When will they get together and meet? What role will each team member have? How is each person dependent on the other team members? How do you choose those team members? But you can’t stop with the historic, human resources-type data. You also need to know what the individual’s motivations are. Are they looking for mentors? Mentees? Have they been trying to learn new skills? Do they have a specific kinds of projects that they want to be on? Maybe they want to get experience in different roles. Taking all those kinds of data into account can lead to the formation of some incredibly successful teams because you’re taking some intrinsic desire a team member has for their personal growth and incorporating that with the team’s shared desire for a successful outcome.

When choosing potential team members, it doesn’t take an incredible number of people to result in an incredible amount of options in the forming stage. If you’re at a 30-person company, and you want to form a 3-person team, how many possibilities are there? This is a math problem, which we love at Exaptive, but if you want to skip ahead to the answer, we’re not going to judge you.

To find out the number of possible three-person teams there are at a 30-person company, we multiply 30 times 29 times 28. That’s 24,360. But we’re not done; there are some duplicate teams in that number (for example, a team of Jill, Brandon, and Erin is the same as a team of Brandon, Erin, and Jill). To get rid of those duplicate teams that are the same people, but in different orders, we divide 24,360 by 3 times 2. That’s still 4,060 possible unique 3-person teams! (Does your company feel a lot bigger now?)

Sometimes there are so many possibilities, it’s just easier to put the same people together over and over, especially if they’re really productive. Productivity is great, but if you’re optimizing for productivity, you are not optimizing for innovation.

Repeat: If you are optimizing for productivity, you are not optimizing for innovation.

The qualities that make a team productive are not just different from the qualities that make a team innovative, they’re mutually exclusive. To be productive you have to get good at efficiently completing projects over and over again. To be innovative, you have to have freedom to fail. You have to be able to try to do the same thing ten different ways to see which idea is crazy enough to work. But whether you’re building a team to be productive, or building a team to be innovative, forming can take a long time.

Teams that don’t get past the storming stage are miserable.

Storming can derail a team entirely. Did you ever get assigned to a team that just never made it past storming? In my experience (when I was on a stagnant, stormy team many years ago), it was a sad, sad way to live. We’d all show up to work and no one knew what anyone else was doing. Deadlines were missed constantly. Some work was getting done but it was obvious that it was no one’s best. I wouldn’t wish that situation on anyone, but it happens.

Team members have to depend on each other for things, and that creates vulnerabilities. Humans don’t like to be vulnerable. Imagine introducing data and technology and intention at this stage.

Transparency is the key to reducing storming. When it’s absolutely transparent why each person was chosen for the project, storming becomes almost non-existent. Visualizing team data as graph data (i.e. — in a network diagram) is a great way to create transparency. (We made a free tool for you to do this. Go here to try it.) When you show someone a network diagram of a project, and the key components of that project, and map the potential team members onto the project, people can immediately answer questions they might not have even known they had. How do I fit with the group? How do I fit with this opportunity? How do the other team members fit? How are we alike? What differences exist?

By the way, seeing yourself in a project this way is a powerful way to reduce a lot of communication barriers. Especially ego! There’s no reason to feel threatened when we see what special thing it is about us that makes us perfect for a project. (Seriously, go do this with the City Planner we made. It’s free.)

Prevent norming from turning into complacency.

Norming is where the team starts to cohere. Team members have used analogies with each other and they’re figuring out how to take what they have in common and use it to explain what’s different. In the norming stage, a common language is developed. And even if it includes jargon, everyone has the context they need to understand it or to translate it into their own language.

For some people, this is the best stage. This is the stage when you feel like you can catch your breath. You start thinking, Ok, we can do this. This is a great team, we all know what we’re here to do. Let’s do it! Norming is such a great stage to be in, sometimes people don’t want to advance past this stage. Maybe you’ve heard of analysis paralysis? It feels good to strengthen the bonds on your team that developed by overcoming the conflict during the storming stage. It’s easy to get trapped in comfortable, circular conversations about process or semantics or fine details, and never be quite ready to move on to the next stage.

The data important to introduce at this stage to keep that from happening are the processes and rules that the team is going to operate by. Charters, goals, requirements. For maximum buy-in, the team needs to create these collaboratively, and the files should be kept in a place where they are living documents the team can maintain and uphold. Other important data here are those common terms. It’s okay to say “design” as long as everyone knows the context and how to translate it.

Performing is pretty much everyone’s favorite part of group dynamics.

Once you finally get to this stage, the team can be productive and everyone can actually work on the tasks at hand and advance the project. It’s a satisfying part of being on a team for just about everyone. The data that matters here are the outputs and the iterations. When you centralize access to the files that the team is all working on together, everyone can be incredibly clear about who is doing what, how much work is left to be done, when the work is done.

The other data important at this stage comes from analysis. In my experience, this important step is overlooked the most. Retrospectives are so important for figuring out which parts of the project were successful and can be repeated elsewhere. The team should be able to analyze their own performance and easily share their findings with each other or their bosses or other stakeholders.

You, too, can collaborate and innovate.

If we want to collaborate with other humans, we can’t avoid the fundamental group dynamic process. Fortunately, by introducing data and technology with intention, we can at least help shorten the time it takes teams of humans to go through those team building stages, make the whole experience go more smoothly, and start performing right away. It’s a powerful way to foster innovation within an organization.

Originally published at www.exaptive.com.

In Stanley Kubrick’s famous film based on Arthur C. Clark’s book, 2001: A Space Odyssey, a mysterious black monolith appears on Earth millions of years before modern humans. It’s the classic “black box.” We don’t know who made it, what’s in it, or how it works, but it’s miraculous and powerful and somehow results in jumpstarting the entire evolution of humankind.

A week ago I traveled with two of my colleagues to India where we participated in a multi-day workshop for a large-scale multi-continent collaborative data-science initiative that was just getting underway. No one at the conference talked about Kubrick’s film, but there was plenty of talk of “black boxes.”

Data science algorithms were black boxes that non-data-scientists didn’t understand. Experimental research setups were black boxes that other researchers couldn’t reproduce. Organizational processes were black boxes that participants couldn’t navigate. Teams were black boxes that managers couldn’t easily monitor.

In a collaborative project of the size and scope being discussed at the workshop, there were no shortage of things for which different stakeholders felt they lacked visibility. This was clearly a source of stress and frustration. There was excitement too — a sense that all these black boxes together had the potential to advance both science and society — but no one wanted to just trust blindly in them. On the second day of the conference, just before my colleague Dr. Alicia Kneodler and I were about to present to the group about the Cognitive City, the Q&A from the previous presentation led back to this topic. A participant asked the question, “How can we shine more light on these black boxes and make them a little less opaque?”

Alicia leaned over to me as said, “That’s exactly what a city is: a bright spot of light. Can we use the Cognitive City to shine more light where it’s needed?” Her question really stuck with me. The Cognitive City is the name of the platform my company has developed over the last 8 years for making collaborative research easier. We’ve been focused on trying to facilitate innovation; that’s where the whole name for the platform came from. Cities are birthplaces of innovation, and my team wanted to create a system that could foster innovation in virtual space the way that real cities can foster innovation in physical space.

But now Alicia was making me think about visibility more explicitly than ever before. We had always put a strong emphasis on visualization in our platform — from visualizing the ‘dataflow’ of an analysis to visualizing the network of a research community. We liked visualization precisely because of its ability to illuminate complex things. But now I found myself thinking about visibility and the city metaphor more holistically, and of images of the Earth from space, like this one from NASA:

It turns out that these maps of light from space are incredibly telling. The amount of light that a city puts out tells you about their economic development. The increase in their light output over time tells you about their urbanization. In India, what we were hearing was that for a lot of the participants, data-science projects were dark portions of the map, and they desperately wanted a brighter landscape.

Deeply understanding how people collaborate to generate outcomes and innovate is a wicked problem but it doesn’t have to be a black box. There is a rapidly growing field called the science of team science which aims in many ways to illuminate aspects of scientific collaboration. There is even a “team science toolkit” available on the web that allows you to access much of the latest research in this area (I went to the site and searched for the term “black box”, which resulted in just one match — a paper focused on increasing visibility to the different motivations driving researchers).

Some of what the science of team science literature explores includes the various roles, behaviors and contributions of team members. The multi-country/continent collaborative project mentioned above brings together domain scientists and data scientists. Other teams we are working with emphasize the co-production of knowledge across domain scientists and stakeholders. There is much diversity across teams performing research together and Alicia and I have been focused on adding visibility to team science focused on human behavior within teams. In the case of data science-focused projects, it appears to us that there are several distinctive types of black boxes that need to be illuminated, and it seems that no comprehensive framework yet exists to provide structure to this work of illumination. So, let me take a nascent first pass at a rough scaffolding:

When I look at this list, I see a lot of work ahead of us. One thing that stands out to me is that most of our current methods of illumination are backwards looking. They are flashlights that we try to shine behind us after the work is done. In order for large-scale data-science projects to be successful, I think it is critical that we develop the ability to shine the light ahead of us and illuminate the increments of work that are currently in process or still under development.

This is one of the things that I’ll be asking the Exaptive team to think more about as we continue to develop the Cognitive City. If they are fans of 2001: A Space Odyssey, like I am, they might be tempted to say, in their best HAL impression, “I’m sorry, Dave, I’m afraid I can’t do that.” But it won’t work on me. I know they can, and I’m looking forward to blogging more about the progress they make.

Originally published at www.exaptive.com.