Jeff Szczepanski: Why Isn’t Technology Making Us More Productive?

• Slides
• Transcript
• About the Speaker
• Join the BoS community

Successful businesses have a powerful combination of core and context. After several successful exits, Jeff considered his next move and pondered the question, ‘Why isn’t technology making us more productive?’

Jeff wants to build an organization that tackles that challenge and realized this meant pursuing invention over innovation. Jeff shares some of the lessons he learned scaling successful companies and why sometimes, to invent something new, you have to take a radically different approach to building a company.

You’ll learn how you can approach building new, breakout products in your org and the different risks associated with pursuing big ideas.

You’ll learn:

• Technology has boosted task-level productivity—but left us overwhelmed and misaligned at the organizational level.
• Most digital tools are just “paper in a screen,” not systems that truly support collaborative cognition.
• There are five types of thinking—only one is instinctual; the rest require structure, vocabulary, and intent.
• Productivity failures often stem from time compression, poor planning, and strategy misalignment—not bad intentions.
• To truly innovate, we must name the paradigms we’re shifting—and build systems that support every level of thinking.

Slides

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

Transcript

I’m going to talk about a bit about why isn’t technology making us more productive, or maybe more like, why technology isn’t making us more productive, without the question mark. This talk is going to have two halves to it. A bit of theoretical, trying to build a framework, how we think about our businesses and how we run them, and what the technology is doing for us, and not doing this in there. But also some practical side to this, where we get some vocabulary, some tools.

So two kind of halves in the sort of structure of the talk. This the sort of academic and framework for kind of part of it blended in with some practical tools and tips that we can apply even without the technology. So two halves of the talk relative to the things being integrated between the theoretical and the tools, sort of diagnostics that we can use in the business every day, even without the technology helping us more. I’ll just give you a little bit more about my background.

My Background and Perspective

That’s the full surname there, Szczepanski, but everybody really does call me Tall Jeff. It’s good branding, I guess at some level, especially because I’m actually tall. My background formerly as electrical engineer. The first half of my career really was spent designing chips and embedded systems, lower level software, mostly in like imaging applications for like places like Eastman Kodak Company or HP Xerox, things like that. The roles during that point in my career was really as VP of engineering CTO and what you would think of as VP of product, basically nowadays, kind of intermingled at various phases through there.

I founded a total of three companies now, including the current company that I just recently founded. I’ve been COO three times of three different businesses that other people have founded. One of those is Stack Overflow, spent eight years as COO. Stack Overflow really building the business behind the network that you guys may be familiar with.

And then now, I’ve had a total of three exits now in my career. One of them was one of the second company that I founded. It was a voice over the company called Allworks, was acquired by one of the major telecoms in 2007. And then I was CEO of a company called Sphere Knowledge that was acquired by Twitter and 2021. And then the real big exit is Stack Overflow itself, which also exited in 2021 for 1.8 billion with a B. A good exit for everybody.

Somewhere in there, managed to be a dad twice, two time dad. Which means, I guess you could say my wife has had two exits herself. So we are a five exit family, and now I am CEO and founder of Reframe Technologies, which ties into our talk here. So with that, enough about me.

Why Aren’t We More Productive?

So why isn’t technology making us more productive? There’s a good New York Times article here. You can see the headline of that, was talking a bit about this. There’s a lot of good research behind it, and I won’t spend a lot of time on this, but I’m hoping you guys have a sense of this. What the data shows is that for the last several decades, as we’ve computerized a lot of things, and this is technology, in the sense of us doing knowledge work, using computers to try to get useful things done.

There was a really good increase in task productivity at the sort of individual task level, but we’re now essentially suffering information overload, you could describe it. And I think again, you guys probably have a decent sense of what that’s all about, all these notifications, all these different applications, different things like that. So that’s sort of the under opinions of what we’re going to talk about, and then try to break this down. We’re going to do this as a three part of the talk here.

• The first is to sort of understand the problem a little bit more, the symptoms that we sort of feel, but then also a little bit more of this is a problem that’s interesting, and what’s really kind of going on under the hood.
• And then we’re going to kind of decompose the knowledge work a bit more, so we can start working ourselves with a framework to start solving the problem, or at least found lay a foundation for solving the problem.
• And then finally, we’re spent most at a time actually talking about a framework, building it up to start reining in the problem. Some more formalisms, some of the stuff you’ll be very familiar with, but we’re going to try to tie it all together here for you, and then see how this can be sort of leveraged in the technology. And again, this is where it would be as we go through this, we’ll both talk about sort of practical things that we see near term. And then it’s like, what do we do to get these practical things into the computers and helping us essentially?

So before we actually dive into part one, there’s this quote here I really like.

Talent hits a target, no one else can hit. Genius hits a target, nobody else can see.

And I refer back to this often, and think about this in the sense that the reason I put this here is because when you start thinking about solving hard problems and doing really cool things, you start to realize that this is all about putting vocabulary to things that we sort of have some notion about or an inkling but it’s only in the formalism of a structure that we really can start talking about it in precise ways and essentially improve our ability to tackle and solve these problems. So part of what I’m really trying to do is, the key part of building up this framework is so we actually get a much better sense of what it is that we’re actually trying to do all the time to essentially make ourselves and the organizations that we’re trying to build much smarter, in a sense.

Understanding the Productivity Probl

So part one: understanding the problem. I’ll let you read the tweet.

This is from Joe Leech, who’s been on the BoS stage before, I think several times here in the US and even in the European version. Did you get the Zoom link for the Google Doc, so on and so forth? You guys can read the slide, right? And hopefully, maybe show of hands? Everybody kind of know what I’m talking about here. And I don’t actually think he’s overstating it too much there. It’s obviously funny way to think about it. But this really is going on every day, right? So something’s going on here.

Another one symptom of the problem is just this. We look at this every day. I’m being pretty polite here, with a small number of windows and a small number of tabs, this is actually my desktop probably cleaned up a bit for the screenshot. But yeah, we sort of we take this for granted, like this is here in front of us every day, where we come back to our computers. What do I do first? Where do I go? Do I mark this on red? Do I put it on my task list? Do I go back? There’s all this kind of stuff going on, and this obviously starts to hint towards this information overload, with so many different things in front of us. I think the data shows something like 50 some odd applications in the typical mid sized company being used to try to get work done in that organization. And all of our brains, even 100% of our brains being used, a lot of it getting distracted and losing sort of cognitive function, distracted by many different things.

But even more important to this picture, the other thing I’d like to help you see here is this. What’s the difference? Right? It’s kind of crazy when you start to think about it this way, right? We’ve literally, in the knowledge work sense, just digitized the paper, and we’re still stuck doing all the same things we were doing before we digitized the paper. And this starts to shed a little bit of light on where we’re going. And in fact, it’s even more interesting to think about, you know, the desktop on the left versus the desktop on the right, the one on the right, I guess for you guys, the one on the right is wasn’t really designed for productivity, per se.

In other words, at Xerox PARC, when people sat down and we had this computer science problem of, I’m only running run program at a time with my DOS machine or CPM machine, back in the olden days, and this desktop was really designed just to be an intuitive way to solve the computer science problem of getting multiple computer programs running at the same time. It’s about dividing up the screen real estate. It’s about where does my mouse and keyboard input go? How do we divide up the memory and the processor resources? That’s what our operating system is really designed for. No one looked at this and said, Hey, this is a great way to do a workflow of a bunch of different applications.

And so the conclusion here is that really, this is a victim of its own success. And obviously, over the last several decades, we did get good task level doing tasks inside of a particular silo. We got a big gain, but now we’re being overwhelmed by this excess of this. And being forced to still deal with it just as if it’s the same picture on the left every day. And so if we go into thinking about our different application suites, all the different sort of categories of whether it’s sort of workspace collaboration, your browsers and the operating system itself, the workspace collaboration stuff, really G Suite and Microsoft Office, or even what we’re doing in AI nowadays. You’ll really see that this is actually very much focused only on task level activities.

And so this, you have this task level domain work on the one side, but there’s a whole other type of work that we do when we’re doing the work. This alludes to this idea that we’re coordinating this, whether it’s just for ourselves trying to use a bunch of these applications together to get something done, or whether it’s us collaborating across the organization. And I think it was in Matt’s talk where you mentioned the thing about, does really 10% of our brain get used and the science has, you know, sort of proven that not to be the case. But there’s really two things going on here. One of them is the idea that the stuff on the left here is causing us a lot of distraction, and the cognitive function is being diverted for things that maybe we shouldn’t be doing and the computer should be doing.

But the other part of it is, how are we doing to work together? And the sort of idea that I think Matt said, 10% of the organ getting sort of 10% of the brain power of the organization, and this is exactly why I would claim. So it’s like, what is the tools to support this? What is the computer helping to do this? And this is where we realize we’re still dealing with this thing, and we haven’t really computerized any of that.

And so the moral of the story, basically, is there’s two different types of work that we’re really trying to get done. We spent a lot of time automating and digitizing the stuff on the left, but we haven’t done anything to digitize on the right. And you might say like, Well, what about Trello or project management software and stuff like that? Is that helping you coordinate things? And my claim is, is we’re doing all the coordination of the activities, copying and pasting, moving between silos, sending things.

In Slack, or whatever, we actually do all the coordination work in our heads, and those tools are just capturing the output of that. That’s the digital paper. I mean, a Trello board is literally the transformation of a physical board we used to have on the wall just moved into the computer. And the computer, in a sense, has no way to help us actually do the real work there.

So, the moral story, there’s a huge untapped opportunity here, and this again, alludes to where the technology is actually holding us back, especially with all the different things we’re trying to do now, with the fact that. It’s so easy to move the paper around and generate more documents, AI, in some sense, is going to be making this problem worse, because, yes, I can generate stuff faster, but then we have to deal with a lot more stuff as well. And so that’s the real opportunity here.

There’s a great book. It’s called World Without Email. It’s by Cal Newport. He put a vocabulary to this idea that the way we’re working with our computers now, and the technology is really just an artifact, sort of a set of norms around something that people put together for computer science reasons. He talks about this as the hyperactive hive mind workflow basically. It’s just what emerged around the fact that we needed to solve this problem of getting a bunch of things to run together on our computer at the same time. So that’s part one.

Decomposing Knowledge Work

Part two, so let’s start to break this down so we can start thinking about, what would it mean to sort of solve this problem. And this is the part where it starts to get hard. I showed you the messy desktop, but it’s kind of like, oh, wait a minute, what isn’t the computer doing that it should be doing? There’s a lot of things we take for granted here. So this part of the talk, part two, I want to just kind of dive into a little bit more. What is knowledge work? What are we trying to do, in a sense? And then we’ll go to part three to sort of dive in and start building up a framework around this.

So decomposing knowledge work, Business of Software Conference. Well, what is the Business of Software? Software is a really cool thing, right? Incredibly virtual. Everything that we do in a software business, there’s no actually traditional sense of productivity. We’re not building widgets on an assembly line with these long term, repeatable processes. It’s just completely virtual. And in a sense, a software company, I would claim, is like the purest form of knowledge work. So in a sense, the business software is knowledge work. That’s essentially all we are doing in a software company, it would claim.

And again, this is really neat to think about, because of the fact that software companies essentially move at the speed of thought, if you will, our ability to create new things. Think of new things, imagine stuff. And all it is all about is getting individuals empowered with the best set of tools to be creative, as we’ve seen in some of the other talks. But then also collaboratively, how we’re going to work together in those things. There’s a great term in the literature called collaborative cognition, sort of the official term for what we’re trying to do when we get a bunch of people together and try to do some knowledge work, in the sense of our software companies.

So this then kind of raises the question, looks like, oh, OK, well, what do we know about cognition? What are we trying to do when we collaborate? We sort of take it for granted, because we sort of do this on a day to day basis, just part of what we inherit, sort of when we grow up.

Thinking Fast vs Thinking Slow

We can talk about another great book here that I really enjoyed, Thinking Fast and Slow. I’ve seen a bunch of you certainly familiar with the book, have not read it right, just as the entitle implies, it’s kind of interesting, two kinds of thinking, much like there’s two kinds of work. And I’m not suggesting quite that there’s an exact one to one mapping there, but there is some really interesting ideas that we can start to draw from the book. And what’s kind of going on in our behaviors, and why, maybe we’re only getting sort of 10% if we will, just to use that number of our sort of collective abilities.

And so if you’ve read the book, there’s some really interesting lessons in interesting lessons in it. So we have the thinking fast, and we have the thinking slow type thinking, and there’s sort of the lizard brain on the bottom, and the fact that we can sort of act, react, have instincts around things. And one of the lessons in the book is that we start to see that a lot of the thinking slow, it’s not nearly as rational as we think it is. And we just describes this idea that we basically come to either emotional or sort of instinctive conclusions. And then what follows is a post rationalization of the other part of the brain, sort of catching up with this conclusion you’ve already drawn, and then tries to come up with some rational explanation for why you’ve been thinking that.

And what we learned from the book is that this isn’t bad, actually, necessarily. Some of the most brilliant insights are actually thinking fast. And we come up with a very good, useful post rationalization to try to make that thing come true, or not necessarily a rationalization, but an explanation for it, and then figure out how to act on it. But then we also have the thinking fast that’s kind of bad. We have a sort of bias in our thinking from the thinking fast, and then we come up with a bunch of gobbledygook that just makes it sound good and right, but didn’t really mean anything. And the challenge in the book is that, at least in my recollection, I don’t think it actually resolves this problem. In other words, how do we know the difference? And when is our thinking fast serving us really well, and when is our thinking fast, not serving us so well. And so that starts to shed light on what’s starting to happen, I think. In our brains, when we’re trying to collaborate together, we’re like, problem solvers as humans and we tend to, like, want to do things quick. And this is all about survival. You know, fire. Throw the fire out. You can’t do a lot of analytical thinking. If I want to put out the fire and still survive, or run away from the saber tooth tiger or whatever.

But in knowledge work, I’m going to claim there isn’t any real fires going on. No saber tooth tigers in the closet. And they’re all sort of figurative, but our brain still is predisposed to work this way. And this is where the idea of the pyramid is, not only in the area of the two boxes, but the fact that we’re genetically predisposed to do the other one, and sort of trumps what’s going on in the upper half of the box. And so this is something we want to deal with.

So when we get back to thinking flow and slow and thinking fast and the lessons of the book, I’m going to claim that Daniel here was, oops wrong, or at least it’s under specified. So it’s a very useful model, but it’s not enough to, like close the loop around our thinking processes to figure out when is the thinking slow and thinking fast working for us, and when is it not? And this is where we want to start to build up a framework beyond this to try to solve this problem.

Introducing Five Types of Thinking

So I’m going to claim or explain why there’s actually five types of thinking. And we still have the same pyramid. At the bottom of it, we have the thinking fastest like we had before. And in a sense, what we’re going to do is break down the thinking slow into four different types of thinking. And we’re going to formalize this a bit more. And what we’re trying to do with this is get more purposeful about what different types of thinking we’re trying to do, and we’re thinking slow and build up a more formal framework for this. And what’s important here is that, like when we start to think about it, is that there’s two things.

One, first of all, the pyramid is still here. And I’m going to claim, as we get sort of these higher and higher levels of thinking, we’re less and less disposed to do this. Well, it requires more practice, more more structure around it, and I’m also going to try to explain why it’s actually exactly five types of thinking. Why isn’t it seven or nine, three or two? As the book would imply, from Thinking Fast and Slow. And so we’re going to work through all that. But another thing we’re trying to do with this framework is sort of square up the triangle, so that we take the bias out of this. And we really can start to solve the problem when starting to understand whether thinking fast is getting us in trouble or whether it’s just genuinely useful. And then we’ll build up the other layers on top. And this is sort of a academic framework to start to build this thing. And there’ll be some familiar terms in this relative to what these layers are. And I might even ask you guys to try to guess as we build them up what the other layers might be.

But also want to make sure you have a visceral sense of what we’re doing here, so you can kind of relate to it at a more thinking fast level, I guess. And that’s gets into these kind of quotes. There was the big debate about founder mode versus manager mode. There’s the execution eat strategy for breakfast or a vision without a strategy is an illusion, and these are kind of all funny statements, right? There’s certain wisdom in all of these, even manager mode versus founder mode, probably mostly Bob guess, but we kind of know what they’re talking about there, right? But the problem is we don’t really know which one of these to apply when. When are they good advice?

And my claim is basically in all these words of wisdom that we have in different ways of thinking, simply just incomplete in a sense, there’s a lot of false dichotomies in here. There’s certainly a big, huge false dichotomy in the founder mode versus manager mode. And so what we’re trying to do with this framework, actually, is break all these dichotomies. So we can get really rigorous about how we attract problems, how we build our businesses, how we organize, how we decompose things, how do we invent things and stuff like that? So that’s what we’re trying to do. This is knowledge work decomposed for you, or at least we’re going to start to build it up.

A Framework for Knowledge Work

So the next step is part three. What is this framework? Let’s take the question marks and fill in the boxes, and let’s give ourselves a bit more vocabulary around this. Right back to the original quote, we’re going to start to put labels on things so we start to see how the system works, and we’ll start to get a lot more smarter about if we see something going in an organization, which types of these thinkings is the one that’s getting us in trouble? Or if we have a problem just as an opportunity sense, which one of these tools should we be using to help move us forward? The fastest or the best? That’s the idea here.

The Vocabulary of Core vs Context

So before diving in this though, we’re going to go through the framework and answer the questions. Give you some more vocabulary, more tools along the way here. But before I dive in, there’s a really important idea that I want to kind of have his vocabulary to use along the way. It’s something we used to talk at Stack Overflow quite a bit.

I think Joel Spolsky at Stack was the first one to kind of bring the vocabulary to the company, and it’s something I’ve really latched on to ever since then. And it’s this idea of core versus context. This is actually a well defined thing. I think there’s a whole book, or it’s part of somebody’s book. I wish I knew the reference. Sorry, I didn’t look it up for you. But there’s this idea of core versus context.

And when we tackle problems, and core is the things that are we’re basically doing new or different in our organizations, than in a sense, where the differentiation comes from. We’re doing something new or different because we believe there’s some sort of advantage in the market for doing it. But of course, we don’t want every single thing in our company to be core, because there’s no reason to reinvent certain things. And that’s where context comes in. When we undertake other activities in our organization, they can be purely context. So we’re just going to go do, I don’t know, B2B selling according to standard practices that.

Many different companies, you know, doing B2B SaaS use as a fundamental thing. Now, it’s obviously going to vary some, and there’s, you’re never at the complete extreme of 100% core versus 100% context in things. But this idea that when you start thinking about what you’re going to do and start to say, like, Oh, should we just use standard practices and deploy that? Or is this something we really want to own internally, because we believe there’s some advantage in the market for that kind of thing? And so that’s something I want to have here as a vocabulary.

Loosely speaking, and this is very loose, I’m sure there’ll be several engineers in the room as we go through this. This won’t hold up quite precise for you, but just to kind of give a better sense of it too, how this connects back to some of the other ideas, is that anything that’s core, where you’re inventing and doing something new, in a sense, always has to be thinking slow. Okay? Because you haven’t done it before. It’s not something that’s instinctual. And almost by definition of sort of doing something new, you’re not going to necessarily have good habits around it. And we’re going to talk more about that later in here.

But, and then you have the other thing, which is context. And in a sense, context is the thinking fast stuff. It’s the things that we can execute without a lot of higher level thought. And yeah, that’s the basic gist of it. So this idea we have core and that we have context in our organization, and that this is an important thing to keep an eye on, is sort of part of our decision process and even labeling of things, and I’ll talk more about that later.So anyway, core versus context is vocabulary.

Type 1: Thinking Fast – Execution

So now we want to take this knowledge work decomposition, start filling in the question marks. And we’re going to start in the thinking fast, because this is, in a sense, where the most goes, goes wrong. And in my experience of working with a lot of different companies, the own businesses that I’ve been in, but also giving advice or advising other companies. There’s a lot of pitfalls in the thinking fast problems because of that pyramid that we’re trying to deal with. And just to formalize this a little bit more, the thinking fast is these action, reaction instincts, and I’m just going to call it execution. It’s the things we will do and execute again without a lot of high level thought and instruction to support it. We know what we want to do, and we just sort of go do it, and that’s the thinking fast execution. So what goes wrong?

Common Pitfalls in Thinking Fast

I love these quotes. I’ve heard them all multiple times. I think through my career, I don’t have enough time to get those hires done. The very thing that will give you more time. We better hurry up and start coding. There’s going to be a lot of bugs to fix. I love that one, right? And then why bother estimating the schedule and picking the deadline? We’ll just use all that time to get started sooner. That one probably is less intuitive to a lot of people. I have to argue about people on that one a lot. That one a lot less intuitive.

But what I’m trying to expose here is basically what you’ll see in this diagram, right? You literally are not doing the very thing that can actually help you out forward. And this is the thing I want to put a label on which my term for this is a diagnostic in the organization, whether it’s in a team or sort of more organizational wide. It’s a lot of the move fast and break things, kind of thinking, I guess, in a sense, but it can come in much subtler forms, as these sort of quotes allude to.

So the diagnostic here is time compression. It’s this idea because of our instinctual things, being problem solvers, trying to survive in an evolutionary sense, we jump to action and we do things, and we tend to rationalize away things, tunnel vision if you will. And I’ve always called this time compression, because I think it’s, it’s the label that if you talk to somebody that’s suffering from it, you know, fears and triggers and things. Fears and triggers and things cause us to not be taking a step back and looking at the bigger picture. And if you sit down and explain to somebody, usually it’s much harder to diagnose in yourself than it is you see other people doing this. And so if you sit them down and say, Hey, I think you’re suffering from time compression, and start to explain this concept, they’ll actually start to viscerally feel it when it’s kicking in.

So this is a big one, and I actually see this in all organizations, all teams, certainly at certain points in time, different aspects of the companies and things super important diagnostic in the thinking fast realm.

The next diagnostic that happens at this level, I like to call gyration. I always somehow giggle a little bit when I say, it seems kind of funny. And the picture here at it wasn’t the best one. This is one that came up quick in a Google search. Is sort of the dog chasing its tail a bit. We’re kind of going around and around in a vicious circle. Hence the gyration, sort of term. A little bit more formally, what I’m trying to highlight here is this idea that, because we’re problem solvers, we have sort of a problem in our head that may not even be very well defined, and we here’s a solution for it, but then the person sitting next to you comes to a different conclusion in their thinking fast sense, and then you start arguing about option A versus option B. And this starts to go on endlessly. You can waste an entire meeting doing generation. You can waste an entire year, probably at the organizational level, where there’s dissidents and certain key decisions are not getting made because we really can’t decide between option A and option B. And, you know, these could be minor things.

And you know, a special form of this is bike shedding. It’s probably a common term a lot of people have done, you know, it’s when you’re probably because of time compression, and you start to gyrate, and you start to just try to just try to debate something that’s easy to debate, rather than thinking about the hard, scary problems. And that’s what this is, the gyration.

And what’s really funny around this is that we get this advice there’s like, what they call the Ben Franklin where you have option A and we can’t decide versus option B. So let’s do the pluses and minuses. I’m here to tell you that Ben Franklin was wrong. It’s a very bad process. We do not want to be comparing options against each other, and that’s the thing we’re trying to fix here. And I’ll talk more about that. This gets into the next level of thinking, of course, to solve these.

And then the last one that I have for you here is best effort. And I call this best effort because you have a lot of good people on a team, and everybody’s very well intended. And maybe, again, I think it was Matt in his talk, talking about how people love to have their checklists. And we check things off on the checklist, and we think of going down the checklist as progress in a best effort kind of way. But there is a problem here. And there’s kind of two different problems of best effort.

One of them is this idea that we equate, even if we sit down and have a little bit of a plan to make up a list of things to do, we equate completing the things on the checklist with actually achieving the goal or the outcome we were trying to achieve. Even though maybe when we were done, we really didn’t how many times, oh, we completed it, we did everything in the spreadsheet or the micro-self project plan, but did it actually achieve the outcome that you wanted?

But the other thing that’s really important, and this tends to come up on agile teams more so, or sort of a rationalization in the sprints kind of thing, is that did we actually try to bound this plan, the activities that we were doing on the task list in our plan by time and resources? Because obviously your decision to do certain things is highly predicated on the idea that how much it’s going to cost to do it. That’s sort of a key trade off when you try to go down a particular path. And so these things are all trying to capture. When I see in organizations or within your own teams that you’re sort of operating in a best effort mode. Are we really closing the loop around this? And that’s the thing that’s going to lead us to the next level of thinking. So that was all the thinking fast. And what can go wrong.

Type 2: Planning as the First Slow Thinking Mode

The first level in thinking slow is what I’m just going to call planning. It’s about building a plan. And this is going to seem very straightforward, but there’s a couple of really interesting subtleties in this. And a plan, in a sense, this is why it’s the next level up. Is the explanation for why you’re going to go take a certain set of actions to achieve a particular outcome.

So what is a plan really formally? I just kind of alluded to it, but I’m going to formally define a plan for us so that we can use this as a key tool at level one. Which is it’s essentially a time series of actions bounded by those time and resources that can deliver an outcome, I achieve a goal with a high level of confidence. In other words, a plan is only a good plan if you know and believe that it has a good chance of achieving the outcome.

And of course, at the end of the plan, you want to actually make sure that it achieved the outcome, and adjust based on whether or not you really did what you thought you did based on the plan is sort of the idea here. But from our layered thinking approach, what we want to say is that a plan is the justification for all the actions we’re going to take, so that while we take those actions, we can actually learn. So a good plan is basically a hypothesis, so that any execution can become an experiment to learn.

If you go off without all of these aspects in place, you’re missing the opportunity to learn a lot along the way, because you haven’t written down in advance what it is that was supposed to happen. And the thinking fast and slow part of us tends to really post rationalize things differently than what we really would have said before we started versus what we after we started.

But there’s another subtlety in here, around the goals versus the actions. Is what’s really the difference between a goal and an action, or a task, in a sense? And this may seem kind of simple, but if you think about it right, any sort of higher level activity, some outcome you want to achieve, can always be broken down further. You know what I mean? We can say, Go write this doc to do X, Y, Z. Well, I can stop there and describe that and say the goal is to go write this document for a marketing plan with certain characteristics in it. But then I can always break that down into smaller tasks, which is like, open up the word processor, type on the keyboard, hit the letter A, hit the letter B, right? We can always this can be turtles all the way to the bottom. So we want to have a formalism for the difference between goals and actions, so that we can clearly define the two different levels of thinking here. How do you know the difference?

And the difference is a goal is not separated from the actions you’re taking until you can propose a bunch of different ways of achieving the outcome. Otherwise, you’re just using the solution. The task list is a proxy for the goal. You haven’t really talked about what it means to achieve the goal well, and you’ll see that then, that the essence of the level one thinking is that we want to divorce the goal from the way it’s being implemented. That separation is what creates the two different levels of thinking and from the programmers in the room, we can talk in an object oriented sense. This is the difference between interface and implementation.

And the tool for this to actually help you do this and formalize this is what I’ll call quality attributes. Maybe I should be familiar with the term. I saw this from system engineering, but it’s basically the characteristics of a system or this outcome to define what it means to achieve the outcome. Well. So yeah, the this idea that you can separate them out, and we’re basically defining the goal really well and what it means to do it well. The quality attributes describe what it means to achieve the goal well. So then, independent of any solution, what does it mean to hit the outcome well? And this is the thing now where the quality attributes start to allow you to separate out the activities you’re undertaking to achieve the goal from the definition of the goal itself. And this is why you no longer have to debate option A versus option B. You can use the quality attributes to always evaluate each option relative to the goal and those quality attributes. And this turns it into authoring.

And this is the thing in Tanya’s talk, when we talk about creativity. This is how you can formalize creativity, because you start writing down for your brain and for everybody in the room what it is you’re trying to achieve, before you start getting into how to do it. And it’s amazing how quickly you can get to very good and innovative ideas by maintaining the separation. And the process here, just to make this clear, that you’re following in level one thinking is you want to have your goal. Talk about the goal you want to achieve. Define the goal clearly. Talk about using the quality effort to define what it means to achieve the quality attributes well, or the achieve the goal well. And then now let’s talk about building the plan. And you sort of do this in a rinse, repeat kind of way, until everybody agrees on the plan, and you’ll see you will converge on this much quickly if you attack it this way.

And in fact, there’s a key process here. So the whole point is to make sure that we can learn when we need to develop the plan with this very strong hypothesis. There’s the GROW Model. There’s a book called coaching for performance. You’ll see that the G is goal as and I was just talking about. R is reality, O is the options you can undertake. And the idea is, here is to define the goal.

Everyone agrees on the current situation. What does it mean to achieve the goal? Well, we have these options to move forward, and then what will we do to move forward? That’s your plan. That’s level one thinking in a nutshell. This is how you avoid a lot of those diagnostic problems around time, compression, gyration and so on.

Type 3: Strategy – Prioritizing Goals

So we’re going up the stack. I’ll just show you strategy, a much maligned topic. A much misunderstood topic.

I’m here to tell you that strategy is actually very simple. Strategy is just a way to prioritize your goals and the resources used to achieve the goal. It’s really all strategy is. So we have this thinking layer that we can put on top of plans, as we want to have a justification. See, if you see in this layering, right, our plan is a justification for the actions, the strategy is a justification for the various plans that we have going on. And so the diagnostic in the strategy level, do you have a strategy problem? Is a very straightforward question. Are your priorities unclear? So the job of strategy is to allocate resources and provide a clear way of answering every possible question of prioritization.

So if there’s corollary, flip this around. That means if anybody in your organization is confused about priorities, or you’re arguing about them, you have a level two thinking problem. You’re trying to refine your plan. And this is really a funny one for me. Dharmesh Shah, who’s been on the BoS stage several times before, he wrote a really good post recently called the three body problem, and he raises this question of how, or points out how, when you’re a company with a single product, things seem kind of simple and straightforward and pretty easy to organize, but as soon as you come up with a second product, all of a sudden you got all these questions around prioritization. Do we put resources on thing a or thing B?

And for me, it’s funny actually, in this article, even Dharmesh, being a very, very smart guy, didn’t raise the point at all that this is essentially a strategy problem. In other words, you can answer every question in their blog post about the free body problem by just realizing these are strategic questions. And so what’s missing? What’s happening when you’re in a single product company, and moving forward? It’s obvious to where all the resources and time allocation goes. It goes on that particular product as soon as you have two thing. Now, we have to have a way to rationalize. Product A activities versus product B activities conspiring together to create some broader outcome. That’s essentially the essence of strategy, is to actually define why you’re putting resources one way or the other. We need that broader outcome that has been decomposed in those two product initiatives to justify those.

And so what we’re really saying then is just a strategy is the justification for all your goals. Why do we set these goals? Why did we allocate resources accordingly?

Team Strategy Fit and Core vs Context Assumptions

Now this is interesting in terms of another diagnostic within our teams, priorities unclear is one of them. But then we get back to this core versus context that I talked about before, and this is actually a really interesting question, because it’s a little test survey tying our shoes. And if we’re tying our shoes, do we think that’s a core activity requiring invention, or do we have to do that as context? Yes, right. Of course, it’s context. Except if I give this to my four year old son and all of his classmates, and say, You guys are in a shoe tying business, and I need 500 pairs of shoes tied in the next hour. Is that core or is that context for my the four year old? Exactly. We need to manage that differently. So you start to see an interaction here.

We can go to the other extreme and say, going to put somebody on Mars, safe land, a person safely on Mars. Core, context, core, right? Yes, objectively speaking, it is. But just hypothetically, let’s say I go to SpaceX and call it Mr. Musk, and say, Hey, I got ten billion for you, and I need in 10 years, I want to get somebody on Mars. Can you do that? And he says, Yes, Jeff, I’m on it. When I’m managing Elon Musk in that project, I might be inclined to believe him, and I might be able to manage that project. F  brom my perspective, strategically, as something that is actually context. I’m not going to say that’s literally true, but you get my point. So this raises the question of a diagnostic of team strategy fit. Can your team execute your strategy as presumed? And so the canary here, this gets back to the level when planning and our resource and our assumptions, the canary in the coal mine for team strategy fit is, can they hold a schedule? Does the plan put forth actually achieve the goal, or to what extent it achieved the goal?

And this is the thing that starts to formalize how strategy and planning is separated cleanly. And that’s why it’s so important to have all of that in place when you make a plan, because you want those plans to be a hypothesis, to say, Hmm, can we do this in the allocated time and resources? This is going to tell us something about whether it’s core or context. And essentially, there’s no other good way to close the loop if you don’t have all these things in place. And this is where you’re starting to guess and rely a bit more on luck.

So is team strategy fit? The point then, is a labeling of something as core context is actually a critical assumption in your strategic thinking. Do we believe the thing we’re undertaking is a core activity, or do we believe it’s a context activity? And this is why Joel and I would talk about it so much. It’s not just simple vocabulary. You’re putting forth an assumption. This is another layer of assumption to tell you whether or not your strategy is holding strategy is holding up. And in a sense, the job of strategy then, is that realize that you can, by definition, only have a good plan if the activities in the plan are all assumed to be context. Otherwise, you’re kidding yourself that you can actually achieve the goal within the allocated period of time.

Or to put it another way, because this is not always so black and white. You want to be able to strategically adapt to what’s happening on the field, so to speak, based on the fact of whether you see it, tracking the plans and resources or not, you start to realize you need to decompose things differently. And this, in effect, is the essence of strategy. It has to be context for the team implementing it, and you’re learning something about your organizational capability if you’re doing this.

So just to drive a point home then, how do we get core into context? What we’re really saying is that anything you assume to be core needs to be broken down into activities that are context. And this is what strategic objectives are all about. What you’re trying to do is basically the thing you can make context when you’re doing core things, is experiments. You can plan the experiment itself, and the outcome of the experience informs your decisions and the strategy about your core activities. That’s really what you’re doing there. And you’ll see then we have a really nice sort of grammar and layering building up, where we have a very clear distinction. When we see things going on in organization, are we suffering from level zero, level one or level two problems? Strategy is your justification for your plans. Plans, justification for your actions.

Type 4: Paradigm – Defining Your Vision

Now we’re gonna talk about this next level of thinking is your paradigm. It’s the paradigm of your business. In a sense, if you think about it, your company, when you’re trying to accomplish something, you’re basically breaking one paradigm of the market and creating a new one for the market. That’s essentially the essence of moving things forward. And so the paradigm is your set of beliefs about the way you believe the world should be, or the way you want it to be.

And what’s really neat about the level three thinking is that, in a sense, you want to think of your mission and vision as being viewed as a set of paradigms and a paradigm shift that you’re trying to create a shift in the world. That’s what the vision really is doing. And what’s neat about level three thinking is that this is the source of all sustainable advantage, and this is actually really important.

So in other words, innovation and differentiation can only come from breaking one paradigm and creating another one. Otherwise, in a sense, it’s just context. So to be successful, you must realize that you’re inventing something here and that you’re going to need vocabulary and a new model to talk about things. Otherwise no one’s going to understand what your product does, or your people on your team are not going to understand what it is that you’re doing. And the funny thing is that us as founders vision trying to make teams do things, we can imagine these. These shifts in our head, but we don’t have vocabulary to talk about it, and this is where all the confusion comes from.

So we got to realize that our job here is we’re trying to cause this shift, and that we have to wait have a way to externalize this. This is what tends to be going wrong in level three thinking. So right, doing it right requires new vocabulary. Therefore you’re inventing something, and a lot of times it’s just vocabulary to talk about the problem in new and better ways. Back to the quote about the genius hitting targets people can’t see. We need words to describe exactly it is what we’re doing that people can understand. And so, but the other thing that’s really interesting is that this is the only source of sustainable advantage, because of the fact that if it wasn’t core, then it would be context, and that’s easily copied by your competitors.

And what’s really neat here to think about is, if you kind of roll this forward in the logic, then a very mature market is where things that were core of the past, where somebody was innovating and differentiating and delivers that solution to the masses, it becomes context. Because we’ve rein that in, we have new technology to explain how to do that. Everyone’s adopted it. Now it’s a standard practice, and so that’s what you’re actually doing when you go to invent and differentiate innovating market, is you’re just trying to create a paradigm shift in the market. And if it’s successful, everybody inherited it, and that’s the new context for the next generation of innovation, whether it’s in your company or in the marketplace.

The Froto Tool and Paradigm Shifts

Now, the tool here that I want to talk about called the Froto. I also stole this from somebody else can’t remember.

And this is the idea that you’re going from something to something the Froto. And this is the essence of that paradigm shift that I’ve been talking about. And the reason this is so important gets back to what I was already describing, which is that we imagine things in our heads, and we try to hand wave and explain them to customers or users or people on our own teams, and they don’t really understand it. And so the reason the Froto so important is basically, in a sense, we have to capture our mission and vision of what we’re trying to do in the world as a set of Frotos, because this is the only way that you can kind of write a document that somebody else can pick up and read and actually understand what you’re trying to do. Otherwise, we’re always struggling to get more and more vocabulary. People can only understand things in the context that they currently exist. And then we got to kind of show them the diff. So, well, it’s not a user interface, it’s a graphical user interface. And you start to explain and show people what it means to be graphical user interface, as opposed to a more general, maybe text based interface, those kinds of things. This is the essence of category design.

And it’s actually also the essence of innovators dilemma, or, I should say, really more like crossing the chasm. Jeffrey Moore stuff, early adopters, innovators. What’s going on with your early adopters is they envision the thing that you’re trying to sell them already, and they just see your thing, and they’re like, oh my god, this is what I’ve been looking for my entire life. That’s why they understand it. They didn’t have vocabulary for it. But you can connect over the idea that you both see it when the product gets out there in the market. And the Frotos, either from a marketing sense or from a team sense, are the things that you need to help people understand what it is you’re trying to do, and why. And then if you put this all together, this paradigm shift in the Frotos sets the context for your strategy. Your strategy is just there to accomplish the shift. From point A to point B through a series of plans that come out of the strategy goals that you need to achieve, actions you’re going to take, or experiments you’re going to run.

Type 5: Reality – Embracing Uncertainty

And now we have a really nice framework here to run our businesses by, except there’s one more layer.

Does anybody spot the problem in this framework so far? Then we need to fix? This is hard to see. This took me a long time to see. I bounced this off of somebody, and they actually hit on it exactly what it is. What was that? Exactly. Right? It floats in isolation. We have our companies, we have our paradigm shifts. But what’s the problem with all paradigms, or all abstractions?

There’s a good Joel and Software blog post about this. All abstractions are leaky. Paradigms are not as solid as we think they are. And in fact, by definition, a paradigm is just a model of the world. And so the other layer of thinking is somewhat philosophical, which is, if we want to, kind of like, step out of this system and look at it from the outside, we have to realize this entire framework. And the thing that we’re trying to cause the shift in exists in a broader world that is just reality. There’s the underlying reality that actually exists in the world. And any model that we’re going to come up with is just an approximation of the reality that’s easy to rein in and talk about it becomes actionable. Because in a philosophical sense, we can never know the true underlying reality that the market lives in. And so we need to take this into account and have some thinking around it.

The Meteor Framework and Level 5 Thinking

And just to drive the point home on this quickly, which is that even physics, physics seems very, very tangible. Hey, man, Newton, can’t argue with him, right? Except that Newtonian physics got replaced. Still super useful, but general theory relativity came along. And started explaining a lot of things that Newton couldn’t explain. But then we also have Einstein with the general theory of relativity. This is seeming awful physical and also permanent gravity. It works. We’re here. Can’t argue with it, except it’s just another model of the world. And people love to debate whether you can this physics. It was Newtonian physics invented or discovered. Did Einstein discover or invent the general theory of relativity? Even this type of paradigm, I’m going to absolutely tell you that it’s invented. And how do I know that it’s invented? Is because it’s wrong.

We know the general theory of relativity is wrong. It does not explain everything in the universe. There’s the whole kind of quantum world. No one knows yet, exactly how useful and what the boundaries are yet of the general theory of relativity and the frontier right now of physics inventing in physics. The paradigm shifts of physics to come is people trying to figure out what’s actually really going on under the hood, and they have to postulate about what the heck is really going on in the world, and try to come up with new models.

So if you want to have a tool for this, I call the tool meteors.

That’s the thing you’re going about your business, like Mr. Dinosaur over here. Crazy, right? Drinking his coffee. Very bright star. Kind of interesting. So what are the thought process we undertake? I call this meteors. It’s sort of like red teaming it. You can think about all kinds of different ways. We could literally spend all day talking about this of different ways to think outside of your system. But the whole idea is that you’re acknowledging the fact that whatever you could come up with in your paradigms, the way your company is assuming it has assumptions built into it, and that you want to step outside of that paradigm and start understanding what its limitations are, because these can be existential threats.

And so your goal, basically in a sense, is to take unknown unknowns and turn them into very explicit assumptions that can be tested, or you just take on the risk which you understand that you’re taking on the risk and say that’s perfectly acceptable. All businesses have existential risk of some sort. And so you just want to be purposeful about this and realize, especially if you start identifying these, you can start to see signs that, hmm, that star didn’t used to do that thing. Maybe we should start paying attention to it.

And the funniest thing I find about the meteor is talking to lots of different people and lots different companies, is the crazy shit here. And this gets back to the thinking fast versus thinking slow, is that I’m going to claim the meteors are almost always known. We’re just used to ignoring them, or it’s too painful or scary to think about what it might mean that that meteor, or that star is actually a meteor, and we just sort of ignore them. And so the point is, in all this is that I think you see them. The question is, is put some level four thinking in this will improve the robustness and stability of your entire business. Many, many industries are disrupted by ignoring the meteors. And this is why startups, in a sense, can disrupt stuff, because they see the meteors. Or, in a sense, maybe even create them. They create a paradigm shift, because even the physics is fungible. Certainly what we do on our software in a virtual world can be highly fungible.

Bringing It All Together

And that is the five kinds of thinking and how to bring it all together.

But there was a higher level thread here, and the crazy thing is to realize computers don’t help you do anything that I’ve just talked about. But what if they did or what would you want them to do? And it’s, of course, everything that I just talked about, right? The GROW model, time compression, gyration, an we start to have structures that actually formalize how our projects are related. The actual thinking behind it layered up like this. Can we have a grammar that structures the five types of thinking? And we as users don’t necessarily need to know about this, but from a technology perspective, this is a great computer science problem. And so you want the structure to have formalisms around things like the GROW model. How does the computer actually help us align, rather than just have a bunch of lists of us doing pluses and minuses about things? Can it help us do the GROW model, align and connect? Formalize the connection between the five levels of knowledge is at least an ongoing hypothesis that we can be very specific about, rather than us all hand waving in documents and meetings, being much less precise about what it is we’re really trying to do.

The computer, then could start to leverage that context, maybe even language models, if this stuff existed, to actually help us navigate it, and then the computers are actually starting to help us to be more productable. If the computer knew in my strategy, what was core versus context, or even if you knew what was core in context versus what I assumed was core in context, we have a very specific way of talking about everything, and everything starts to get better. We can essentially do Lint checks or Syntax Checking, in a sense, on this grammar for the computer to be looking out for many different pitfalls that we could easily be falling into. Because as we just walk through everything I described in terms of this vocabulary, we can put labels on it. We all see it better now probably we did at the beginning of the meeting or the beginning of this session. We just want the computer helping with this.

Introducing Reframe Technologies

So back to me, Reframe was founded to lead this journey.

We call it an organized work environment to help jump from what I like to call a productivity theater into really pushing forward a next leap in human capacity for knowledge work. I like to think of us as taking off where Xerox PARC left off, or taking over where Xerox PARC left off 50 years ago, in terms of the GUI desktop. What comes next? We can fix the messy desktop. We’re going to help fix the functional org chart, so we can all align better. Not that there’s anything wrong with the functional org chart. It just needs some help.

Our mission is broken down into four seasons, seasons like a television series. Long term mission here lots of level three and four thinking. Season one is really the first step where we have a new piece of software for Mac OS and Windows that basically switches your computer from being application silos based into streams based so that the computer is organizing the way you do. The alpha release of episode one of season one is coming soon. Thank you.

Q&A

Mark Littlewood 

Wow, I’m thinking about questions. I have so many questions, and I knew I would, and I feel like I should probably have moved you somewhere else in the album, because I think there’s going to be people with questions. Let’s do a quick. Has anybody got a quick question here? Let’s go Martin.

Audience Member 

I read Cal Newport’s book, Deep Work. Thay’s you’re familiar with. And I wonder, and I’m kind of throwing anyway, I’ll just say it, is it possible that the computer is never going to be able to help us do this real work? Because I found that the biggest change to being more productive was just changing my habits of for example, to take something simple, not looking at email for long periods of time and not having more than one screen up on my on my computer. I don’t need the computer to force me to do that, but I do have to decide to do that.

Jeff Szczepanski 

Yeah, great question. So yeah, I think you know, there’s layers to this, I guess, yeah, in terms of, like, the distraction factor, we can obviously build habits or obviously build habits around the existing technology, existing technology. It’s got us a long ways. I think the question is when you think, like, you know, Facebook and the optimization of feeds and the fact that you get notifications, why am I getting notification from that app? There’s a whole team of people at Slack figuring out how to make sure people are using Slack every day, as opposed to helping you be productive, right? And, yeah, the idea is here is that, you know, we get the dopamine hit from responding to them. It’s just a question of, how often does the thinking fast trump the thinking slow? You have some good work habits to do that.

And Cal, in his book, actually, the second half of the book is talking about, given the hyperactive, high mind workflow, what do we do better? I’m looking at it from the standpoint of saying, Well, this is a limitation in technology. Why do we have to have? Why can’t the computer be helping you not do the bad behaviors, rather than being designed in a way that implicitly makes it require a tremendous amount of discipline to undertake good behaviors? In other words, it should really be genuinely assistive and not, you know, because sometimes you don’t want to turn off all the notifications when through one of these mediums.

You know, my kid second, I got to pick them up from school, right? There’s layering to this. There’s stuff that should get through and there’s stuff that shouldn’t get through. And right now we basically have kind of an all or nothing kind of thing. We’d really like to break that dichotomy, basically. And so that’s one of the key things that we think about.

And the way I like to think about that specifically is a relevance question. It’s what’s relevant to me. Now, my kid being sick and I got to pick them up from school. 100% relevant all the time. But if I have something, that I’m working in, one stream of work, notifications related to that are probably a lot more relevant than notifications related to other extremes or other streams, unless it has some particular urgency, emergency meeting aspect to it. So hopefully you get the idea.

Mark Littlewood 

Thank you. The word the last word, Levy.

Audience Member 

Cool talk, Jeff, how does this all blend in with our I guess primary or secondary computer, our phones?

Jeff Szczepanski 

Is that sort of like a Reframe question? I mean, for technology perspective, I’d like to say it’s mostly agnostic. There is some interesting things about mobile devices and and what does it mean to do that? I think maybe I’ll just leave it at the point of, when we’re creators and doing deeper work and trying to really move the ball forward and thinking we’re much more likely to be, you know, interoperating with large screens, people in a room or people on calls. Obviously, we’re using the mobile devices for communication, but it’s typically much more consumption oriented, I think, as a rule, that’s probably slightly generational statement. But yeah, so we think, at least in the reframe sense, if I’d answer it that way, you want access to your streams. You do want to see the notifications and be able to triage what’s going on so you can make a decision about maybe where you should be or what you should be doing, but you’re not trying to really do the deeper work where you got big documents open, trying to code something in the database, something like that, that’s going to be more of something on the desktop. And that’s really the main way we think about the difference between the two different types of devices. It’s sort of the tethered or untethered nowadays, situational awareness machine in the mobile form.

Audience Member 

Thank you. It’s great presentation. Thank you. Very inspiring. I am manager, right? I’ve seen a lot of my co workers doing different type of works and how they approach work, and what I learned from couple of engineers, not everyone, but they split that mess you showed into Mac desktops. So each time they take something, they’re like, oh, which desktop I should put it. And this is kind of streams you’re talking about, I think so they literally switch between desktops on different times of their work, but it requires a lot of discipline. What do you think?

Jeff Szczepanski 

I think that’s the key. Yeah. So the first level of stream based thinking is kind of thinking of spaces or virtual desktops, whatever your terminology is. Favorite terminology, is like the first version of streams is kind of like virtual desktops or spaces on steroids, I like to say. And to maybe highlight one particular example.

First of all is that if you think about spaces or virtual desktops and their traditional Mac OS and Windows Forms, each desktop is literally just giving you more and more desktop space, in a sense, right? You’re just sort of switching. I have set a one desktop with messy paper on it. I have a bunch of other messy paper desktops, in a sense, is that sort of better or worse?

In other words, the computer has no sense of what’s going on there, and it doesn’t really glue together the context. It’s just the physical This is where the paper is on the desk. And so maybe even the simplest example in there is something like Slack, or any application that crosses work streams. In one desktop, you’re going to want to have slack certain position on the window, maybe in a certain channel. Versus another workspace, you want to have in a different place in the desktop and a different channel. Why doesn’t the computer keep track of that for me? And so that’s sort of like the first thing you could think of fixing.

And then the next stuff is to actually have some more formal structure, so the computer starts understanding the relationships of this right now, it cannot rely on the fact that common things on the desktop are actually related to the same stream of work, essentially. Good question. Thank you.

Jeff Szczepanski

Founder & CEO, Reframe Technologies

Jeff is an extraordinarily successful software entrepreneur with three exits and a track record of delivering business results. As founder and CTO, he pioneered VoIP products at Allworx Corp before its acquisition by PAETEC Communications. As COO, he was responsible for scaling Stack Overflow into the internet powerhouse that sold for $1.8B in 2021 and then as COO again, led Sphere Knowledge to an acquisition by Twitter. They were highly innovative companies.

He has a proven ability to scale a business from initial pre-revenue founding team and early employees to leadership in multilayer organizations. He’s raised venture capital, debt finance and led the integration of acquired companies.

More of Jeff’s previous BoS talks.

Next Events