Catch a current livestream, or watch recorded livestreams here »

Thinking in Public

I’ve been CEOing Wolfram Research for more than 30 years now. But what does that actually entail? What do I end up doing on a typical day? I certainly work hard. But I think I’m not particularly typical of CEOs of tech companies our size. Because for me a large part of my time is spent on the front lines of figuring out how our products should be designed and architected, and what they should do.

Thirty years ago I mostly did this by myself. But nowadays I’m almost always working with groups of people from our 800 or so employees. I like to do things very interactively. And in fact, for the past 15 years or so I’ve spent much of my time doing what I often call “thinking in public”: solving problems and making decisions live in meetings with other people.

I’m often asked how this works, and what actually goes on in our meetings. And recently I realized: what better way to show (and perhaps educate) people than just to livestream lots of our actual meetings? So over the past couple of months, I’ve livestreamed over 40 hours of my internal meetings—in effect taking everyone behind the scenes in what I do and how our products are created. (Yes, the livestreams are also archived.)

Seeing Decisions Be Made

In the world at large, people often complain that “nothing happens in meetings”. Well, that’s not true of my meetings. In fact, I think it’s fair to say that in every single product-design meeting I do, significant things are figured out, and at least some significant decisions are made. So far this year, for example, we’ve added over 250 completely new functions to the Wolfram Language. Each one of those went through a meeting of mine. And quite often the design, the name, or even the very idea of the function was figured out live in the meeting.

There’s always a certain intellectual intensity to our meetings. We’ll have an hour or whatever, and we’ll have to work through what are often complex issues, that require a deep understanding of some area or another—and in the end come up with ideas and decisions that will often have very long-term consequences.

I’ve worked very hard over the past 30+ years to maintain the unity and coherence of the Wolfram Language. But every day I’m doing meetings where we decide about new things to be added to the language—and it’s always a big challenge and a big responsibility to maintain the standards we’ve set, and to make sure that the decisions we make today will serve us well in the years to come.

It could be about our symbolic framework for neural nets. Or about integrating with databases. Or how to represent complex engineering systems. Or new primitives for functional programming. Or new forms of geo visualization. Or quantum computing. Or programmatic interactions with mail servers. Or the symbolic representation of molecules. Or a zillion other topics that the Wolfram Language covers now, or will cover in the future.

What are the important functions in a particular area? How do they relate to other functions? Do they have the correct names? How can we deal with seemingly incompatible design constraints? Are people going to understand these functions? Oh, and are related graphics or icons as good and clear and elegant as they can be?

By now I basically have four decades of experience in figuring things like this out—and many of the people I work with are also very experienced. Usually a meeting will start with some proposal that’s been developed for how something should work. And sometimes it’ll just be a question of understanding what’s proposed, thinking it through, and then confirming it. But often—in order to maintain the standards we’ve set—there are real problems that still have to be solved. And a meeting will go back and forth, grappling with some issue or another.

Ideas will come up, often to be shot down. Sometimes it’ll feel like we’re completely stuck. But everyone in the meeting knows this isn’t an exercise; we’ve got to come up with an actual answer. Sometimes I’ll be trying to make analogies—to find somewhere else where we’ve solved a similar problem before. Or I’ll be insisting we go back to first principles—to kind of the center of the problem—to understand everything from the beginning. People will bring up lots of detailed academic or technical knowledge—and I’ll usually be trying to extract the essence of what it should be telling us.

It’d certainly be a lot easier if our standards were lower. But we don’t want a committee-compromise result. We want actual, correct answers that will stand the test of time. And these often require actual new ideas. But in the end it’s typically tremendously satisfying. We put in lots of work and thinking—and eventually we get a solution, and it’s a really good solution, that’s a real intellectual achievement.

Usually all of this goes on in private, inside our company. But with the livestream, anyone can see it happening—and can see the moment when some function is named, or some problem is solved.

What Are the Meetings Like?

What will actually be going on if you tune into a livestream? It’s pretty diverse. You might see some new Wolfram Language function being tried out (often based on code that’s only days or even hours old). You might see a discussion about software engineering, or trends in machine learning, or the philosophy of science, or how to handle some issue of popular culture, or what it’s going to take to fix some conceptual bug. You might see some new area get started, you might see some specific piece of Wolfram Language documentation get finished, or you might see a piece of final visual design get done.

There’s quite a range of people in our meetings, with a whole diversity of accents and backgrounds and specialties. And it’s pretty common for us to need to call in some extra person with specific expertise we hadn’t thought was needed. (I find it a little charming that our company culture is such that nobody ever seems surprised to be called into a meeting and asked about a detail of some unusual topic they had no idea was relevant to us before.)

We’re a very geographically distributed company (I’ve been a remote CEO since 1991). So basically all our meetings are through webconferencing. (We use audio and screensharing, but we never find video helpful, except perhaps for looking at a mobile device or a book or a drawing on a piece of paper.)

Most often we’re looking at my screen, but sometimes it’ll be someone else’s screen. (The most common reason to look at someone else’s screen is to see something that’s only working on their machine so far.) Most often I’ll be working in a Wolfram Notebook. Usually there’ll be an initial agenda in a notebook, together with executable Wolfram Language code. We’ll start from that, but then I’ll be modifying the notebook, or creating a new one. Often I’ll be trying out design ideas. Sometimes people will be sending code fragments for me to run, or I’ll be writing them myself. Sometimes I’ll be live-editing our main documentation. Sometimes we’ll be watching graphic design being done in real time.

As much as possible, the goal in our meetings is to finish things. To consult in real time with all the people who have input we need, and to get all the ideas and issues about something resolved. Yes, sometimes, afterwards, someone (sometimes me) will realize that something we thought we figured out isn’t correct, or won’t work. But the good news is that that’s pretty rare, probably because the way we run our meetings, things get well aired in real time.

People in our meetings tend to be very direct. If they don’t agree with something, they’ll say so. I’m very keen that everyone in a meeting actually understands anything that’s relevant to them—so we get the benefit of their thinking and judgement about it. (That probably leads to an over-representation from me of phrases like “does that make sense?” or “do you get what I’m saying?”.)

It really helps, of course, that we have very talented people, who are quick at understanding things. And by now everyone knows that even if the main topic of a meeting is one thing, it’s quite likely that we’ll have to dip into something completely different in order to make progress. It requires a certain intellectual agility to keep up with this—but if nothing else, I think that’s on its own a great thing to practice and cultivate.

For me it’s very invigorating to work on so many different topics—often wildly different even between successive hours in a day. It’s hard work, but it’s also fun. And, yes, there is often humor, particularly in the specifics of the examples we’ll end up discussing (lots of elephants and turtles, and strange usage scenarios).

The meetings vary in size from 2 or 3 people to perhaps 20 people. Sometimes people will be added and dropped through the course of the meeting, as the details of what we’re discussing change. Particularly in larger meetings—that tend to be about projects that cut across multiple groups—we’ll typically have one or more project managers (we call them “PMs”) present. The PMs are responsible for the overall flow of the project—and particularly for coordinating between different groups that need to contribute.

If you listen to the livestream, you’ll hear a certain amount of jargon. Some of it is pretty typical in the software industry (UX = user experience, SQA = software quality assurance). Some of it is more specific to our company—like acronyms for departments (DQA = Document Quality Assurance, WPE = Web Product Engineering) or names of internal things (XKernel = prototype Wolfram Language build, pods = elements of Wolfram|Alpha output, pinkboxing = indicating undisplayable output, knitting = crosslinking elements of documentation). And occasionally, of course, there’s a new piece of jargon, or a new name for something, invented right in the meeting.

Usually our meetings are pretty fast paced. An idea will come up—and immediately people are responding to it. And as soon as something’s been decided, people will start building on the decision, and figuring out more. It’s remarkably productive, and I think it’s a pretty interesting process to watch. Even though without the experience base that the people in the meeting have, there may be some points at which it seems as if ideas are flying around too fast to keep track of what’s going on.

The Process of Livestreaming

The idea of livestreaming our internal meetings is new. But over the years I’ve done a fair amount of livestreaming for other purposes.

Back in 2009, when we launched Wolfram|Alpha, we actually livestreamed the process of making the site live. (I figured that if things went wrong, we might as well just show everyone what actually went wrong, rather than just putting up a “site unavailable” message.)

I’ve livestreamed demos and explorations of new software we’ve released. I’ve livestreamed work I happen to be doing in writing code or producing “computational essays”. (My son Christopher is arguably a faster Wolfram Language programmer than me, and he’s livestreamed some livecoding he’s done too.) I’ve also livestreamed live experiments, particularly from our Wolfram Summer School and Wolfram Summer Camp.

But until recently, all my livestreaming had basically been solo: it hadn’t involved having other people in the livestream. But I’ve always thought our internal design review meetings are pretty interesting, so I thought “why not let other people listen in on them too?”. I have to admit I was a little nervous about this at first. After all, these meetings are pretty central to what our company does, and we can’t afford to have them be dragged down by anything.

And so I’ve insisted that a meeting has to be just the same whether it’s livestreamed or not. My only immediate concession to livestreaming is that I give a few sentences of introduction to explain roughly what the meeting is going to be about. And the good news has been that as soon as a meeting gets going, the people in it (including myself) seem to rapidly forget that it’s being livestreamed—and just concentrate on the (typically quite intense) things that are going on in the meeting.

But something interesting that happens when we’re livestreaming a meeting is that there’s real-time text chat with viewers. Often it’s questions and general discussion. But sometimes it’s interesting comments or suggestions about what we’re doing or saying. It’s like having instant advisors, or an instant focus group, giving us real-time input or feedback about our decisions.

As a practical matter, the primary people in the meeting are too focused on the meeting itself to be handling text chat. So we have separate people doing that—surfacing a small number of the most relevant comments and suggestions. And this has worked great—and in fact in most meetings at least one or two good ideas come from our viewers, that we’re instantly able to incorporate into our thinking.

One can think of livestreaming as something a bit like reality TV—except that it’s live and real time. We’re planning to have some systematic “broadcast times” for recorded material. But the live component has the constraint that it has to happen when the meetings are actually happening. I tend to have a very full and complex schedule, packing in all the various things I do. And exactly when a particular design review meeting can happen will often depend on when a particular piece of code or design work is ready.

It will also depend on the availability of the various other people in the meetings—who have their own constraints, and often live in a wide range of time zones. I’ve tried other approaches, but the most common thing now is that design review meetings are scheduled soon before they actually happen, and typically not more than a day or two in advance. And even though I personally work at night as well as during the day, most design reviews tend to get scheduled during US (East Coast) working hours, because that’s when it’s easiest to arrange for all the people who have to be in the meeting—as well as people who might be called in if their expertise is needed.

From the point of view of livestreaming, it would be nice to have a more predictable schedule of relevant meetings, but the meetings are being set up to achieve maximum productivity in their own right—and livestreaming is just an add-on.

We’re trying to use Twitter to give some advance notice of livestreaming. But in the end the best indication of when a livestream is starting is just the notification that comes from the Twitch livestreaming platform we’re using. (Yes, Twitch is mainly used for e-sports right now, but we [and they] hope it can be used for other things too—and with their e-sports focus, their technology for screensharing has become very good. Curiously, I’ve been aware of Twitch for a long time. I met its founders at the very first Y Combinator Demo Day in 2005, and we used its precursor, justin.tv, to livestream the Wolfram|Alpha launch.)

Styles of Work

Not all the work I do is suitable for livestreaming. In addition to “thinking in public” in meetings, I also spend time “thinking in private”, doing things like just writing. (I actually spent more than 10 years almost exclusively “thinking in private” when I worked on my book A New Kind of Science.)

If I look at my calendar for a given week, I’ll see a mixture of things. Every day there are typically at least one or two design reviews of the kind I’ve been livestreaming. There are also a fair number of project reviews, where I’m trying to help move all kinds of projects along. And there are some strategy and management discussions too, along with the very occasional external meeting.

Our company is weighted very heavily towards R&D—and trying to build the best possible products. And that’s certainly reflected in the way I spend my time—and in my emphasis on intellectual rather than commercial value. Some people might think that after all these years I couldn’t possibly still be involved in the level of detail that’s in evidence in the design reviews we’ve been livestreaming.

But here’s the thing: I’m trying hard to design the Wolfram Language in the very best possible way for the long term. And after 40 years of doing software design, I’m pretty experienced at it. So I’m both fairly fast at doing it, and fairly good at not making mistakes. By now, of course, there are many other excellent software designers at our company. But I’m still the person who has the most experience with Wolfram Language design—as well as the most global view of the system (which is part of why in design review meetings, I end up spending some fraction of my time just connecting different related design efforts).

And, yes, I get involved in details. What exactly should the name of that option be? What color should that icon be? What should this function do in a particular corner case? And, yes, every one of these things could be solved in some way without me. But in a fairly short time, I can help make sure that what we have is really something that we can build on—and be proud of—in the years to come. And I consider it a good and worthy way for me to spend my time.

And it’s fun to be able to open up this process for people, by livestreaming the meetings we have. I’m hoping it’ll be useful for people to understand a bit about what goes into creating the Wolfram Language (and yes, software design often tends to be a bit unsung, and mainly noticed only if it’s got wrong—so it’s nice to be able to show what’s actually involved).

In a sense, doing the design of the Wolfram Language is a very concentrated and high-end example of computational thinking. And I hope that by experiencing it in watching our meetings, people will learn more about how they can do computational thinking themselves.

The meetings that we’re livestreaming now are about features of the Wolfram Language etc. that we currently have under development. But with our aggressive schedule of releasing software, it shouldn’t be long before the things we’re talking about are actually released in working products. And when that happens, there’ll be something quite unique about it. Because for the first time ever, people will not only be able to see what got done, but they’ll also be able to go back to a recorded livestream and see how it came to be figured out.

It’s an interesting and unique record of a powerful form of intellectual activity. But for me it’s already nice just to be able to share some of the fascinating conversations I end up being part of every day. And to feel like the time I’m spending as a very hands-on CEO not only advances the Wolfram Language and the other things we’re building, but can also directly help educate—and perhaps entertain—a few more people out in the world.