Where Did All The Focus Time Go? Dissecting 1.5 Million Meetings With Clockwise's VP of Engineering Dan Kador

Where has all the focus time gone? Why does there seem to be less of it at big companies than at startups? And do managers really have as little as they claim?

It should come as no surprise to our listeners that we're big fans of data here at Dev Interrupted. The coolest thing about having Dan Kador, VP of Engineering at Clockwise, on the show is that he brings data we already intuitively understood but could not quantify.

Armed with data from 1.5 million meetings, 80,000 engineers and over 5,000 companies, this episode answers every question your engineering team has wondered about meetings — and might just reaffirm every suspicion you've had too.

Episode Highlights Include:

• (2:58) Dan's career journey
• (6:24) What is The 2022 Software Engineering Meeting Benchmark Report?
• (8:43) How the data was collected
• (13:50) Is there a Clockwise secret sauce?
• (20:46) The time it takes to enter a flow state
• (25:17) The "Coordination Tax"
• (35:21) How to improve your engineering team based on the data

Episode Excerpt:

Dan Lines: Is there a Clockwise secret sauce that you can talk about?

Dan Kador: Yeah, of course. Yeah absolutely, what kind of tech company would we be without a secret sauce? So again, at the heart of what we do is an acknowledgement that time is a network resource, right? So it's like, a kind of fancy way of saying something that anybody who's worked on a team knows is true. You don't have full control over your calendar. You get invited to meetings, someone cancels at the last minute, whatever it is. So, individuals are actually pretty good at managing their own calendars, but managing, for example, a small team's calendar is hard, and managing a department's calendar is much harder, and managing calendars across the whole company is almost impossible. So Clockwise, what we do is we're constantly looking at all of these calendars. Remember, we're subscribing to them in real time across all members of a company, and really what we're doing is we're considering up to a million permutations a day of- and that's per team per day, of ways to rearrange events on these calendars. Again, all in service of trying to create more focus time for people to do deep work. So, as we're doing these many many permutations per team, what we do is we try to select the best possible permutation, the one that's generating the most focus time, reducing the most conflicts, and apply it to these calendars by moving events around automatically on behalf of our users. And as aside, we never create conflicts, we're never going to move a meeting you haven't asked us to manage for you. We really try to respect preferences in that way. So, secret sauce. Imagine you're a developer and you're asked to build something like this. You know, it's pretty straightforward if you're doing this for a couple of people, like you can kind of think in your head, I can think about how to write that code. It gets complicated but still feels a little tractable if you're doing it for a midsized team. But think about how nasty the problem space gets if you're responsible for doing this for a company with thousands or tens of thousands of employees. It quickly spirals out, it's an end squared problem. So how can you consider the seemingly infinite number of permutations? So putting this in terms of, you know, if I really dust off the cobwebs, but in terms of my ancient CS degree, what we've learned is that this is actually similar to what's formerly called the Maximum Independent Set Problem. So in other words, if you have a company at ten thousand people, how do you map those people into smaller groups of independent folks who can make optimizations among those smaller groups. You can't simply go, alright, let's take marketing on one, sales on another, engineering in a third. And if you look into the problem space, it turns out that maximum independent set problem is actually strongly NP-hard, which means there's just no known efficient general algorithm for solving it. So the secret sauce we have is how we solve this specific problem and this specific domain, and that's probably about as far as I can get, but if you want to know more about it, come work with us, because it's pretty fun.