Bridging the Gap between Academia and Industry in Research

Peter van Hardenberg talks about Industrialists vs. Academics, Ink&Switch's evolution over time, the Hollywood Model, internal lab infrastructure, and more!

Peter is the lab director and CEO of Ink&Switch, a private, creator oriented, computing research lab. 

References

• Ink&Switch (and their many publications)
• The Hollywood Model in R&D
• Idea Machines Episode with Adam Wiggins
• Paul Erdós

Transcript

Peter Van Hardenberg

[00:01:21] Ben: Today I have the pleasure of speaking with Peter van Hardenbergh. Peter is the lab director and CEO of Inkin switch. Private creator oriented, competing research lab. I talked to Adam Wiggins, one of inkind switches founders, [00:01:35] way back in episode number four. It's amazing to see the progress they've made as an organization.

They've built up an incredible community of fellow travelers and consistently released research reports that gesture at possibilities for competing that are orthogonal to the current hype cycles. Peter frequently destroys my complacency with his ability to step outside the way that research has normally done and ask, how should we be operating, given our constraints and goals. I hope you enjoy my conversation with Peter.

Would you break down your distinction between academics and industrialists

[00:02:08] Peter: Okay. Academics are people whose incentive structure is connected to the institutional rewards of the publishing industry, right? You, you publish papers. And you get tenure and like, it's a, it's, it's not so cynical or reductive, but like fundamentally the time cycles are long, right? Like you have to finish work according to when, you know, submission deadlines for a conference are, you know, you're [00:02:35] working on something now.

You might come back to it next quarter or next year or in five years, right? Whereas when you're in industry, you're connected to users, you're connected to people at the end of the day who need to touch and hold and use the thing. And you know, you have to get money from them to keep going. And so you have a very different perspective on like time and money and space and what's possible.

And the real challenge in terms of connecting these two, you know, I didn't invent the idea of pace layers, right? They, they operate at different pace layers. Academia is often intergenerational, right? Whereas industry is like, you have to make enough money every quarter. To keep the bank account from going below zero or everybody goes home,

[00:03:17] Ben: Right. Did. Was it Stuart Brand who invented

pace

[00:03:22] Peter: believe it was Stewart Brand. Pace layers. Yeah.

[00:03:25] Ben: That actually I, I'd never put these two them together, but the, the idea I, I, I think about impedance mismatches

between [00:03:35] organizations a lot. And that really sort of like clicks with pace layers Exactly. Right. Where it's like

[00:03:39] Peter: Yeah, absolutely. And, and I think in a big way what we're doing at, Ink& Switch on some level is trying to provide like synchro mesh between academia and industry, right? Because they, the academics are moving on a time scale and with an ambition that's hard for industry to match, right? But also,

Academics.

Often I think in computer science are like, have a shortage of good understanding about what the real problems people are facing in the world today are. They're not disinterested.

[00:04:07] Ben: just computer

[00:04:08] Peter: Those communication channels don't exist cuz they don't speak the same language, they don't use the same terminology, they don't go to the same conferences, they don't read the same publications.

Right.

[00:04:18] Ben: Yeah.

[00:04:18] Peter: so vice versa, you know, we find things in industry that are problems and then it's like you go read the papers and talk to some scientists. I was like, oh dang. Like. We know how to solve this. It's just nobody's built it.

[00:04:31] Ben: Yeah.

[00:04:32] Peter: Or more accurately it would be to say [00:04:35] there's a pretty good hunch here about something that might work, and maybe we can connect the two ends of this together.

[00:04:42] Ben: Yeah. Often, I, I think of it as someone, someone has, it is a quote unquote solved problem, but there are a lot of quote unquote, implementation details and those implementation details require a year of work.

[00:04:56] Peter: yeah, a year or many years? Or an entire startup, or a whole career or two? Yeah.

And, and speaking of, Ink&Switch, I don't know if we've ever talked about, so a switch has been around for more than half a decade, right?

[00:05:14] Peter: Yeah, seven or eight years now, I think I could probably get the exact number, but yeah, about that.

[00:05:19] Ben: And. I think I don't have a good idea in my head over that time. What, what has changed about in, can switches, conception of itself and like

how you do things. Like what is, what are some of the biggest things that have have changed over that time?[00:05:35]

[00:05:35] Peter: So I think a lot of it could be summarized as professionalization. But I, I'll give a little brief history and can switch began because the. You know, original members of the lab wanted to do a startup that was Adam James and Orion, but they recognized that they didn't, they weren't happy with computing and where computers were, and they knew that they wanted to make something that would be a tool that would help people who were solving the world's problems work better.

That's kinda a vague one, but You know, they were like, well, we're not physicists, we're not social scientists. You know, we can't solve climate change or radicalization directly, or you know, the journalism crisis or whatever, but maybe we can build tools, right? We know how to make software tools. Let's build tools for the people who are solving the problems.

Because right now a lot of those systems they rely on are getting like steadily worse every day. And I think they still are like the move to the cloud disempowerment of the individual, like, you [00:06:35] know, surveillance technology, distraction technology. And Tristan Harris is out there now. Like hammering on some of these points.

But there's just a lot of things that are like slow and fragile and bad and not fun to work with and lose your, you know, lose your work product. You know,

[00:06:51] Ben: Yeah, software as a service more generally.

[00:06:54] Peter: Yeah. And like, there's definitely advantages. It's not like, you know, people are rational actors, but something was lost. And so the idea was well go do a bit of research, figure out what the shape of the company is, and then just start a company and, you know, get it all solved and move on.

And I think the biggest difference, at least, you know, aside from scale and like actual knowledge is just kind of the dawning realization at some point that like there won't really be an end state to this problem. Like this isn't a thing that's transitional where you kind of come in and you do some research for a bit, and then we figure out the answer and like fold up the card table and move on to the next thing.

It's like, oh no, this, this thing's gotta stick around because these problems aren't gonna [00:07:35] go away. And when we get through this round of problems, we already see what the next round are. And that's probably gonna go on for longer than any of us will be working. And so the vision now, at least from my perspective as the current lab director, is much more like, how can I get this thing to a place where it can sustain for 10 years, for 50 years, however long it takes, and you know, to become a place that.

Has a culture that can sustain, you know, grow and change as new people come in. But that can sustain operations indefinitely.

[00:08:07] Ben: Yeah. And, and so to circle back to the. The, the jumping off point for this, which is sort of since, since it began, what have been some of the biggest changes of how you operate? How you, or just like the, the model more generally or, or things that you were

[00:08:30] Peter: Yeah, so the beginning was very informal, but, so maybe I'll skip over the first like [00:08:35] little period where it was just sort of like, Finding our footing. But around the time when I joined, we were just four or five people. And we did one project, all of us together at a time, and we just sort of like, someone would write a proposal for what we should do next, and then we would argue about like whether it was the right next thing.

And, you know, eventually we would pick a thing and then we would go and do that project and we would bring in some contractors and we called it the Hollywood model. We still call it the Hollywood model. Because it was sort of structured like a movie production. We would bring in, you know, to our little core team, we'd bring in a couple specialists, you know, the equivalent of a director of photography or like a, you know, a casting director or whatever, and you bring in the people that you need to accomplish the task.

Oh, we don't know how to do Bluetooth on the web. Okay. Find a Bluetooth person. Oh, there's a bunch of crypto stuff, cryptography stuff. Just be clear on this upcoming project, we better find somebody who knows, you know, the ins and outs of like, which cryptography algorithms to use or [00:09:35] what, how to build stuff in C Sharp for Windows platform or Surface, whatever the, the project was over time.

You know, we got pretty good at that and I think one of the biggest changes, sort of after we kind of figured out how to actually do work was the realization that. Writing about the work not only gave us a lot of leverage in terms of our sort of visibility in the community and our ability to attract talent, but also the more we put into the writing, the more we learned about the research and

that the process of, you know, we would do something and then write a little internal report and then move on.

But the process of taking the work that we do, And making it legible to the outside world and explaining why we did it and what it means and how it fits into the bigger picture. That actually like being very diligent and thorough in documenting all of that greatly increases our own understanding of what we did.[00:10:35]

And that was like a really pleasant and interesting surprise. I think one of my sort of concerns as lab director is that we got really good at that and we write all these like, Obscenely long essays that people claim to read. You know, hacker News comments on extensively without reading. But I think a lot about, you know, I always worry about the orthodoxy of doing the same thing too much and whether we're sort of falling into patterns, so we're always tinkering with new kind of project systems or new ways of working or new kinds of collaborations.

And so yeah, that's ongoing. But this, this. The key elements of our system are we bring together a team that has both longer term people with domain contexts about the research, any required specialists who understand like interesting or important technical aspects of the work. And then we have a specific set of goals to accomplish [00:11:35] with a very strict time box.

And then when it's done, we write and we put it down. And I think this avoids number of the real pitfalls in more open-ended research. It has its own shortcomings, right? But one of the big pitfalls that avoids is the kind of like meandering off and losing sight of what you're doing. And you can get great results from that in kind of a general research context.

But we're very much an industrial research context. We're trying to connect real problems to specific directions to solve them. And so the time box kind of creates the fear of death. You're like, well, I don't wanna run outta time and not have anything to show for it. So you really get focused on trying to deliver things.

Now sometimes that's at the cost, like the breadth or ambition of a solution to a particular thing, but I think it helps us really keep moving forward.

[00:12:21] Ben: Yeah, and, and you no longer have everybody in the lab working on the same projects,

right.

[00:12:28] Peter: Yeah. So today, at any given time, The sort of population of the lab fluctuates between sort of [00:12:35] like eight and 15 people, depending on, you know, whether we have a bunch of projects in full swing or you know, how you count contractors. But we usually, at the moment we have sort of three tracks of research that we're doing.

And those are local first software Programmable Inc. And Malleable software.

[00:12:54] Ben: Nice. And so I, I actually have questions both about the, the write-ups that you do and the Hollywood model

and so on, on the Hollywood model. Do you think that I, I, and this is like, do you think that the, the Hollywood model working in, in a. Industrial Research lab is particular to software in the sense that I feel like the software industry, people change jobs fairly frequently.

Contracting is really common. Contractors are fairly fluid

and.

[00:13:32] Peter: You mean in terms of being able to staff and source people?[00:13:35]

[00:13:35] Ben: Yeah, and people take, like, take these long sabbaticals, right? Where it's like, it's not uncommon in the software industry for someone to, to take six months between jobs.

[00:13:45] Peter: I think it's very hard for me to generalize about the properties of other fields, so I want to try and be cautious in my evaluation here. What I would say is that,

I think the general principle of having a smaller core of longer term people who think and gain a lot of context about a problem and pairing them up with people who have fresh ideas and relevant expertise, does not require you to have any particular industry structure. Right. There are lots of ways of solving this problem.

Go to a research, another research organization and write a paper with someone from [00:14:35] an adjacent field. If you're in academia, right? If you're in a company, you can do a partnership you know, hire, you know, I think a lot of fields of science have much longer cycles, right? If you're doing material science, you know, takes a long time to build test apparatus and to formulate chemistries.

Like

[00:14:52] Ben: Yeah.

[00:14:52] Peter: someone for several years, right? Like, That's fine. Get a detach detachment from another part of the company and bring someone as a secondment. Like I think that the general principle though, of putting together a mixture of longer and shorter term people with the right set of skills, yes, we solve it a particular way in our domain.

But I don't think that that's software u unique to software.

[00:15:17] Ben: Would, would it be overreaching to map that onto professors and postdocs and grad students where you have the professor who is the, the person who's been working on the, the program for a long time has all the context and then you have postdocs and grad students [00:15:35] coming through the lab.

[00:15:38] Peter: Again, I need to be thoughtful about. How I evaluate fields that I'm less experienced with, but both my parents went through grad school and I've certainly gotten to know a number of academics. My sense of the relationship between professors and or sort of PhD, yeah, I guess professors and their PhD students, is that it's much more likely that the PhD students are given sort of a piece of the professor's vision to execute.

[00:16:08] Ben: Yeah.

[00:16:09] Peter: And that that is more about scaling the research interests of the professor. And I don't mean this in like a negative way but I think it's quite different

[00:16:21] Ben: different.

[00:16:22] Peter: than like how DARPA works or how I can switch works with our research tracks in that it's, I it's a bit more prescriptive and it's a bit more of like a mentor-mentee kind of relationship as

[00:16:33] Ben: Yeah. More training.[00:16:35]

[00:16:35] Peter: Yeah. And you know, that's, that's great. I mean, postdocs are a little different again, but I think, I think that's different than say how DARPA works or like other institutional research groups.

[00:16:49] Ben: Yeah. Okay. I, I wanted to see how, how far I could stretch

the,

stretch

[00:16:55] Peter: in academia there's famous stories about Adosh who would.

Turn up on your doorstep you know, with a suitcase and a bottle of amphetamines and say, my, my brain is open, or something to that effect. And then you'd co-author a paper and pay his room and board until you found someone else to send him to.

 

I think that's closer in the sense that, right, like, here's this like, great problem solver with a lot of like domain skills and he would parachute into a place where someone was working on something interesting and help them make a breakthrough with it.

[00:17:25] Ben: Yeah. I think the, the thing that I want to figure out, just, you know, long, longer term is how to. Make those [00:17:35] short term collaborations happen when with, with like, I, I I think it's like, like there's some, there's some coy intention like in, in the sense of like Robert Kos around like organizational boundaries when you have people coming in and doing things in a temporary sense.

[00:17:55] Peter: Yeah, academia is actually pretty good at this, right? With like paper co-authors. I mean, again, this is like the, the pace layers thing. When you have a whole bunch of people organized in an industry and a company around a particular outcome, You tend to have like very specific goals and commitments and you're, you're trying to execute against those and it's much harder to get that kind of like more fluid movement between domains.

[00:18:18] Ben: Yeah, and

[00:18:21] Peter: That's why I left working in companies, right? Cause like I have run engineering processes and built products and teams and it's like someone comes to me with a really good idea and I'm like, oh, it's potentially very interesting, but like,

[00:18:33] Ben: but We

[00:18:34] Peter: We got [00:18:35] customers who have outages who are gonna leave if we don't fix the thing, we've got users falling out of our funnel.

Cause we don't do basic stuff like you just, you really have a lot of work to do to make the thing go

[00:18:49] Ben: Yeah.

[00:18:49] Peter: business. And you know, my experience of research labs within businesses is that they're almost universally unsuccessful. There are exceptions, but I think they're more coincidental than, than designed.

[00:19:03] Ben: Yeah. And I, I think less and less successful over time is, is my observation

that.

[00:19:11] Peter: Interesting.

[00:19:12] Ben: Yeah, there's a, there's a great paper that I will send you called like, what is the name? Oh, the the Changing Structure of American Innovation by She Aurora. I actually did a podcast with him because I like the paper so much.

that

that I, I think, yeah, exactly. And so going back to your, your amazing [00:19:35] write-ups, you all have clearly invested quite a chunk of, of time and resources into some amount of like internal infrastructure for making those really good. And I wanted to get a sense of like, how do you decide when it's worth investing in internal infrastructure for a lab?

[00:19:58] Peter: Ooh.

Ah, that's a fun question. Least at In and Switch. It's always been like sort of demand driven. I wish I could claim to be more strategic about it, but like we had all these essays, they were actually all hand coded HTML at one point. You know, real, real indie cred there. But it was a real pain when you needed to fix something or change something.

Cause you had to go and, you know, edit all this H T M L. So at some point we were doing a smaller project and I built like a Hugo Templating thing [00:20:35] just to do some lab notes and I faked it. And I guess this is actually a, maybe a somewhat common thing, which is you do one in a one-off way. And then if it's promising, you invest more in it.

[00:20:46] Ben: Yeah.

[00:20:46] Peter: And it ended up being a bigger project to build a full-on. I mean, it's not really a cms, it's sort of a cms, it's a, it's a templating system that produces static HT m l. It's what all our essays come out of. But there's also a lot of work in a big investment in just like design and styling. And frankly, I think that one of the things that in can switch apart from other.

People who do similar work in the space is that we really put a lot of work into the presentation of our work. You know, going beyond, like we write very carefully, but we also care a lot about like, picking good colors, making sure that text hyphenates well, that it, you know, that the the screencast has the right dimensions and, you know, all that little detail work and. It's expensive [00:21:35] in time and money to do, but I think it's, I think the results speak for themselves. I think it's worth it.

[00:21:47] Ben: Yeah. I, and I mean, if, if the ultimate goal is to influence what people do and what they think, which I suspect is, is at least some amount of the goal then communicating it.

[00:22:00] Peter: It's much easier to change somebody's mind than to build an entire company.

[00:22:05] Ben: Yes. Well,

[00:22:06] Peter: you wanna, if you wanna max, it depends. Well, you don't have to change everybody's mind, right? Like changing an individual person's mind might be impossible. But if you can put the right ideas out there in the right way to make them legible, then you'll change the right.

Hopefully you'll change somebody's mind and it will be the right somebody.

[00:22:23] Ben: yeah. No, that is, that is definitely true. And another thing that I am. Always obscenely obsessed, exceedingly impressed by that. In Switch. [00:22:35] Does is your sort of thoughtfulness around how you structure your community and sort of tap into it. Would you be willing to sort of like, walk me through how you think about that and like how you have sort of the, the different layers of, of kind of involvement?

[00:22:53] Peter: Okay. I mean, sort of the, maybe I'll work from, from the inside out cuz that's sort of the history of it. So in the beginning there was just sort of the people who started the lab. And over time they recruited me and, and Mark Mcg again and you know, some of our other folk to come and, and sign on for this crazy thing.

And we started working with these wonderful, like contractors off and on and and so the initial sort of group was quite small and quite insular and we didn't publish anything. And what we found was that. Once we started, you know, just that alone, the act of bringing people in and working with them started to create the beginning of a [00:23:35] community because people would come into a project with us, they'd infect us with some of their ideas, we'd infect them with some of ours.

And so you started to have this little bit of shared context with your past collaborators. And because we have this mix of like longer term people who stick with the lab and other people who come and go, You start to start to build up this, this pool of people who you share ideas and language with. And over time we started publishing our work and we began having what we call workshops where we just invite people to come and talk about their work at Ink and Switch.

And by at, I mean like now it's on a discord. Back in the day it was a Skype or a Zoom call or whatever. And the rule back then in the early days was like, if you want to come to the talk. You have to have given a talk or have worked at the lab. And so it was like very good signal to noise ratio in attendance cuz the only people who would be on the zoom call would be [00:24:35] people who you knew were grappling with those problems.

For real, no looky lose, no, no audience, right? And over time it just, there were too many really good, interesting people who are doing the work. To fit in all those workshops and actually scheduling workshops is quite tiring and takes a lot of energy. And so over time we sort of started to expand this community a little further.

And sort of now our principle is you know, if you're doing the work, you're welcome to come to the workshops. And we invite some people to do workshops sometimes, but that's now we have this sort of like small private chat group of like really interesting folk. And it's not open to the public generally because again, we, I don't want to have an audience, right?

I want it to practitioner's space. And so over time, those people have been really influential on us as well. And having that little inner [00:25:35] circle, and it's a few hundred people now of people who, you know, like if you have a question to ask about something tricky. There's probably somebody in there who has tried it, but more significantly, like the answer will come from somebody who has tried it, not from somebody who will call you an idiot for trying or who will, right, like you, you avoid all the, don't read the comments problems because the sort of like, if anybody was like that, I would probably ask them to leave, but we've been fortunate that we haven't had any of that kind of stuff in the community.

I will say though, I think I struggle a lot because I think. It's hard to be both exclusive and inclusive.

Right, but exclusive community deliberately in the sense that I want it to be a practitioner's space and one where people can be wrong and it's not too performative, like there's not investors watching or your, your user base or whatever.

[00:26:32] Ben: Yeah.

[00:26:32] Peter: at the same time,

[00:26:33] Ben: strangers.

[00:26:34] Peter: [00:26:35] inclusive space where we have people who are earlier in their career or. From non-traditional backgrounds, you know, either academically or culturally or so on and so forth. And it takes constant work to be like networking out and meeting new people and like inviting them into this space.

So it's always an area to, to keep working on. At some point, I think we will want to open the aperture further, but yeah, it's, it's, it's a delicate thing to build a community.

[00:27:07] Ben: Yeah, I mean the, the, frankly, the reason I'm asking is because I'm trying to figure out the same things and you have done it better than basically anybody else that I've seen. This is, this is maybe getting too down into the weeds. But why did you decide that discourse or discord was the right tool for it?

And the, the reason that I ask is that I personally hate sort of [00:27:35] streaming walls of texts, and I find it very hard to, to seriously discuss ideas in, in that format.

[00:27:43] Peter: Yeah, I think async, I mean, I'm an old school like mailing list guy. On some level I think it's just a pragmatic thing. We use Discord for our internal like day-to-day operations like. Hey, did you see the pr? You know, oh, we gotta call in an hour with so-and-so, whatever. And then we had a bunch of people in that community and then, you know, we started having the workshops and inviting more people.

So we created a space in that same discord where. You know, people didn't have to get pinged when we had a lab call and we didn't want 'em turning up on the zoom anyway. And so it wasn't so much like a deliberate decision to be that space. I think there's a huge opportunity to do better and you know, frankly, what's there is [00:28:35] not as designed or as deliberate as I would like.

It's more consequence of Organic growth over time and just like continuing to do a little bit here and there than like sort of an optimum outcome. And it could, there, there's a lot of opportunity to do better. Like we should have newsletters, there should be more, you know, artifacts of past conversations with better organizations.

But like all of that stuff takes time and energy. And we are about a small little research lab. So many people you know,

[00:29:06] Ben: I, I absolutely hear you on that.

I think the, the, the tension that I, I see is that people, I think like texting, like sort of stream of texts. Slack and, and discord type things. And, and so there's, there's the question of like, what can you get people to do versus like, what creates the, the right conversation environment?[00:29:35]

And, and maybe that's just like a matter of curation and like standard setting.

[00:29:42] Peter: Yeah, I don't know. We've had our, our rabbit trails and like derailed conversations over the years, but I think, you know, if you had a forum, nobody would go there.

[00:29:51] Ben: Yeah.

[00:29:52] Peter: like, and you could do a mailing list, but I don't know, maybe we could do a mailing list. That would be a nice a nice form, I think. But people have to get something out of a community to put things into it and you know, you have to make, if you want to have a forum or, or an asynchronous posting place, you know, the thing is people are already in Discord or slack.

[00:30:12] Ben: exactly.

[00:30:13] Peter: something else, you have to push against the stream. Now, actually, maybe one interesting anecdote is I did experiment for a while with, like, discord has sort of a forum post feature. They added a while back

[00:30:25] Ben: Oh

[00:30:25] Peter: added it. Nobody used it. So eventually I, I turned it off again.

Maybe, maybe it just needs revisiting, but it surprised me that it wasn't adopted, I guess is what [00:30:35] I would say.

[00:30:36] Ben: Yeah. I mean, I think it, I think the problem is it takes more work. It's very easy to just dash off a thought.

[00:30:45] Peter: Yeah, but I think if you have the right community, then. Those thoughts are likely to have been considered and the people who reply will speak from knowledge

[00:30:55] Ben: Yeah.

[00:30:56] Peter: and then it's not so bad, right?

[00:30:59] Ben: it's

[00:30:59] Peter: The problem is with Hacker News or whatever where like, or Reddit or any of these open communities like you, you know, the person who's most likely to reply is not the person who's most helpful to apply.

[00:31:11] Ben: Yeah, exactly. Yeah, that makes, that makes a lot of sense. And sort of switching tracks yet again, how so one, remind me how long your, your projects are, like how

long, how big are the, is the time box.

[00:31:28] Peter: the implementation phase for a standard income switch Hollywood project, which I can now call them standard, I think, cuz we've done like, [00:31:35] Ooh, let me look. 25 or so over the years. Let's see, what's my project count number at? I have a little. Tracker. Yeah, I think it's 25 today.

So we've done about 20 some non-trivial number of these 10 to 12 weeks of implementation is sort of the core of the project, and the idea is that when you hit that start date, at the beginning of that, you should have the team assembled.

You should know what you're building, you should know why you're building it, and you should know what done looks like. Now it's research, so inevitably. You know, you get two weeks in and then you take a hard left and like, you know, but that, that we write what's called the brief upfront, which is like, what is the research question we are trying to answer by funding this work and how do we think this project will answer it?

Now, your actual implementation might change, or you might discover targets of opportunity along the way. But the idea is that by like having a, a narrow time box, like a, a team [00:32:35] that has a clear understanding of what you're trying to accomplish. And like the right set of people on board who already have all the like necessary skills.

You can execute really hard for like that 10 to 12 weeks and get quite far in that time. Now, that's not the whole project though. There's usually a month or two upfront of what we call pre-infusion, kind of coming from the espresso idea that like you make better espresso if you take a little time at low pressure first to get ready with the shot, and so we'll do.

You know, and duration varies here, but there's a period before that where we're making technical choices. Are we building this for the web or is this going on iPad? Are we gonna do this with rust and web assembly, or is this type script is this, are we buying Microsoft Surface tablets for this as we're like the ink behavior, right?

So all those decisions we try and make up front. So when you hit the execution phase, you're ready to go. Do we need, what kind of designer do we want to include in this project? And who's available, you know? All of that stuff. We [00:33:35] try and square away before we get to the execution phase.

[00:33:38] Ben: right.

[00:33:38] Peter: when the end of the execution phase, it's like we try to be very strict with like last day pencils down and try to also reserve like the last week or two for like polish and cleanup and sort of getting things.

So it's really two to two and a half, sometimes three months is like actually the time you have to do the work. And then after that, essays can take between like two months and a year or two. To produce finally. But we try to have a dr. We try to have a good first draft within a month after the end of the project.

And again, this isn't a process that's like probably not optimal, but basically someone on the team winds up being the lead writer and we should be more deliberate about that. But usually the project lead for a given project ends up being the essay writer. And they write a first draft with input and collaboration from the rest of the group.

And then people around [00:34:35] the lab read it and go, this doesn't make any sense at all. Like, what? What do you do? And you know, to, to varying degrees. And then it's sort of okay, right? Once you've got that kind of feedback, then you go back and you restructured and go, oh, I need to explain this part more. You know, oh, these findings don't actually cover the stuff that other people at the lab thought was interesting from the work or whatever.

And then that goes through, you know, an increasing sort of, you know, standard of writing stuff, right? You send it out to some more people and then you send it to a bigger group. And you know, we send it to people who are in the field that whose input we respect. And then we take their edits and we debate which ones to take.

And then eventually it goes in the HTML template. And then there's a long process of like hiring an external copy editor and building nice quality figures and re-recording all your crappy screencasts to be like, Really crisp with nice lighting and good, you know, pacing and, you know, then finally at the end of all of that, we publish.

[00:35:33] Ben: Nice. And [00:35:35] how did you settle on the, the 10 to 12 weeks as the right size, time box?

[00:35:42] Peter: Oh, it's it's it's, it's clearly rationally optimal.

[00:35:46] Ben: Ah, of course,

[00:35:47] Peter: No, I'm kidding. It's totally just, it became a habit. I mean, I think. Like I, I can give an intuitive argument and we've, we've experimented a bit. You know, two weeks is not long enough to really get into anything,

[00:36:02] Ben: right.

[00:36:02] Peter: and the year is too long. There's too much, too much opportunity to get lost along the way.

There's no, you go too long with no real deadline pressure. It's very easy to kind of wander off into the woods. And bear in mind that like the total project duration is really more like six months, right? And so where we kind of landed is also that we often have like grad students or you know, people who are between other contracts or things.

It's much easier to get people for three months than for eight months. And if I feel like [00:36:35] just intuitively, if I, if someone came to you with an eight month project, I'd be, I'm almost positive that I would be able to split it into two, three month projects and we'd be able to like find a good break point somewhere in the middle.

And then write about that and do another one. And it's like, this is sort of a like bigger or smaller than a bread box argument, but like, you know, a month is too little and six months feels too long. So two to four months feels about right. In terms of letting you really get into, yeah, you can really get into the meat of a problem.

You can try a few different approaches. You can pick your favorite and then spend a bit of time like analyzing it and like working out the kinks. And then you can like write it up.

[00:37:17] Ben: Thanks.

[00:37:18] Peter: But you know, there have been things that are not, that haven't fit in that, and we're doing some stuff right now that has, you know, we've had a, like six month long pre-infusion going this year already on some ink stuff.

So it's not a universal rule, but like that's the, that's the

[00:37:33] Ben: Yeah. No, I [00:37:35] appreciate that intuition

[00:37:36] Peter: and I think it also, it ties into being software again, right? Like again, if you have to go and weld things and like

[00:37:43] Ben: yeah, exactly.

[00:37:44] Peter: You know,

[00:37:44] Ben: let let some bacteria grow.

[00:37:46] Peter: or like, you know, the, it's very much a domain specific answer.

[00:37:51] Ben: Yeah. Something that I wish people talked about more was like, like characteristic time scales of different domains.

And I, I think that's software, I mean, software is obviously shorter, but it'd be interesting to, to sort of dig down and be like, okay, like what, what actually is it? So the, the, the last question I'd love to ask is, To what extent does everybody in the lab know what's, what everybody else is working on? Like.

[00:38:23] Peter: So we use two tools for that. We could do a better job of this. Every Monday the whole lab gets together for half an hour only. [00:38:35] And basically says what they're doing. Like, what are you up to this week? Oh, we're trying to like, you know, figure out what's going on with that you know, stylist shaped problem we were talking about at the last demo, or, oh, we're, you know, we're in essay writing mode.

We've got a, we're hoping to get the first draft done this week, or, you know, just whatever high level kind of objectives the team has.

And then I was asked the question like, well, Do you expect to have anything for show and tell on Friday and every week on Friday we have show and tell or every other week.

Talk a bit more about that and at show and tell. It's like whatever you've got that you want input on or just a deadline for you can share. Made some

benchmark showing that this code is now a hundred times faster. Great. Like bring it to show and tell. Got that like tricky you know, user interaction, running real smooth.

Bring it to show and tell, built a whole new prototype of a new kind of [00:39:35] like notetaking app. Awesome. Like come and see. And different folks and different projects have taken different approaches to this. What has been most effective, I'm told by a bunch of people in their opinion now is like, kind of approaching it.

Like a little mini conference talk. I personally actually air more on the side of like a more casual and informal thing. And, and those can be good too. Just from like a personal alignment like getting things done. Perspective. What I've heard from people doing research who want to get useful feedback is that when they go in having sort of like rehearsed how to explain what they're doing, then how to show what they've done and then what kind of feedback they want.

That not only do they get really good feedback, but also that process of making sure that the demo you're gonna do will actually run smoothly and be legible to the rest of the group [00:40:35] forces you. Again, just like the writing, it forces you to think about what you're doing and why you made certain choices and think about which ones people are gonna find dubious and tell them to either ignore that cuz it was a stand-in or let's talk about that cuz it's interesting.

And like that, that that little cycle is really good. And that tends to be, people often come every two weeks for that

[00:40:59] Ben: Yeah.

[00:41:01] Peter: within when they're in active sort of mode. And so not always, but like two weeks feels about like the right cadence to, to have something. And sometimes people will come and say like, I got nothing this week.

Like, let's do it next week. It's fine. And the other thing we do with that time is we alternate what we call zoom outs because they're on Zoom and I have no, no sense of humor I guess. But they're based on, they're based on the old you and your research hamming paper with where the idea is that like, at least for a little while, every week [00:41:35] we all get together and talk about something.

Bigger picture that's not tied to any of our individual projects. Sometimes we read a paper together, sometimes we talk about like an interesting project somebody saw, you know, in the world. Sometimes it's skills sharing. Sometimes it's you know, just like, here's how I make coffee or something, right?

Like, You know, just anything that is bigger picture or out of the day-to-day philosophical stuff. We've read Illich and, and Ursula Franklin. People love.

[00:42:10] Ben: I like that a lot. And I, I think one thing that, that didn't, that, that I'm still wondering about is like, On, on sort of a technical level are, are there things that some peop some parts of the lab that are working on that other parts of the lab don't get, like they, they know, oh, like this person's working on [00:42:35] inks, but they kind of have no idea how inks actually work?

Or is it something where like everybody in the lab can have a fairly detailed technical discussion with, with anybody else

[00:42:45] Peter: Oh no. I mean, okay, so there are interesting interdependencies. So some projects will consume the output of past projects or build on past projects. And that's interesting cuz it can create almost like a. Industry style production dependencies where like one team wants to go be doing some research.

The local first people are trying to work on a project. Somebody else is using auto merge and they have bugs and it's like, oh but again, this is why we have those Monday sort of like conversations. Right? But I think the teams are all quite independent. Like they have their own GitHub repositories.

They make their own technology decisions. They use different programming languages. They, they build on different stacks, right? Like the Ink team is often building for iPad because that's the only place we can compile like [00:43:35] ink rendering code to get low enough latency to get the experiences we want.

We've given up

on the browser, we can't do it, but like, The local first group for various reasons has abandoned electron and all of these like run times and mostly just build stuff for the web now because it actually works and you spend all, spend way less calories trying to make the damn thing go

if you don't have to fight xcode and all that kind of stuff.

And again, so it really varies, but, and people choose different things at different times, but no, it's not like we are doing code review for each other or like. Getting into the guts. It's much more high level. Like, you know, why did you make that, you know, what is your programming model for this canvas you're working on?

How does you know, how does this thing relate to that thing? Why is, you know, why does that layout horizontally? It feels hard to, to parse the way you've shown that to, you know, whatever.

[00:44:30] Ben: Okay, cool. That, that makes sense. I just, I, the, the, the reason I ask [00:44:35] is I am just always thinking about how how related do projects inside of a single organization need to be for, like, is, is there sort of like an optimum amount of relatedness?

[00:44:50] Peter: I view them all as the aspects of the same thing, and I think that that's, that's an important. Thing we didn't talk about. The goal of income switch is to give rise to a new kind of computing that is more user-centric, that's more productive, that's more creative in like a very raw sense that we want people to be able to think better thoughts, to produce better ideas, to make better art, and that computers can help them with that in ways that they aren't and in fact are

[00:45:21] Ben: Yeah.

[00:45:25] Peter: whether you're working on ink, Or local first software or malleable software media canvases or whatever domain you are working in. It [00:45:35] is the same thing. It is an ingredient. It is an aspect, it is a dimension of one problem. And so some, in some sense, all of this adds together to make something, whether it's one thing or a hundred things, whether it takes five years or 50 years, you know, that's, we're all going to the same place together.

But on many different paths and at different speeds and with different confidence, right? And so in the small, the these things can be totally unrelated, but in the large, they all are part of one mission. And so when you say, how do you bring these things under one roof, when should they be under different roofs? It's like, well, when someone comes to me with a project idea, I ask, do we need this to get to where we're going?

[00:46:23] Ben: Yeah,

[00:46:24] Peter: And if we don't need it, then we probably don't have time to work on it because there's so much to do. And you know, there's a certain openness to experimentation and, [00:46:35] and uncertainty there. But

that, that's the rubric that I use as the lab director is this, is this on the critical path of the revolution?