It's always frustrated me that the to-do-next short list is something to "figure out" instead of being presented explicitly and obviously. Anecdotally, this issue seems to have an outsized cost, because the devs impacted most (or who've complained to me most) tend to be very productive.

David R., Engineering lead

"What's on my plate? What's the next thing I should focus on?" These questions shouldn't be difficult for a developer to get answers to, but too often, it involves digging through different systems, chat apps, and personal notes. This is both frustrating for the devs and bad for the business. If priorities aren't clear, people will inevitably end up working on the wrong things (at least some of the time). And time spent trying to merely get a handle on one's work is time taken away from actually getting it done.

Part of the problem is that a developer’s work is often scattered across several locations: the work definition lives in a tracking tool, code collaboration happens in GitHub, and small requests or questions constantly pop up in chat apps like Slack or Discord.

And speaking of chat apps, another problem faced by many developers (and not just developers!) is the endless stream of chat interruptions that destroy their ability to maintain a happy and productive "flow state". Interruptive notifications are valuable when messages are urgent, but most messages aren't, so being interrupted by them is annoying and wasteful. It's also easy to fall into the habit of having chat conversations synchronously when async collaboration would suffice, whether because of team norms or personal habits.

These two problems – seeing everything on our plates and staying on top of important updates without constant interruptions to our flow – are closely related. What developers really want is a quick way of checking in at their convenience to see what needs attention, as in “Ok, I've been heads-down on something all morning, what’s been going on, and what’s next for me?". Ideally when they’ve finished whatever they’re working on, or are taking a break from it, they could poll a single location, and instantly see a complete snapshot of their prioritized workstream. That's exactly what we're aiming to provide with our new "My work" menu that we recently released, shown here:

An important part of our vision for Constructor is to reduce as much as possible the “work surface area” that developers have to contend with, in two ways. First, by aggregating and organizing information so developers can quickly find and grasp what they need. For example, in Constructor, pull requests are automatically attached to their corresponding tickets and can be found instantly in their own section on ticket pages. Second, by offering user-friendly alternatives to scattering important information across systems in the first place. For instance, Constructor’s discussion threads are often the easiest way to ask a question, so no one has to be cajoled into using them, and then the conversation lives right alongside the work, rather than getting lost in Slack.

Having all the relevant information organized within Constructor is a great start, but it doesn't really solve the problem if devs still have to be constantly scanning boards to assess what's on their plate. This is where the "My work" menu comes in – tickets you own, pull requests waiting for your review, and threads assigned to you are now all visible in a simple, clear list that you can check in with at your convenience. For quick items like threads and code reviews, this lets you rapidly knock out a bunch of small things when you need a break from deep work.

The mission we set ourselves for this feature was to enable our heaviest users to actually turn off all notifications from Constructor without worrying that they’ll miss something important. Of course, users who don't use Constructor frequently will probably want to keep getting notifications, but developers, team leads, and PMs who are very active in the app can now replace an endless series of notifications with an occasional quick glance at “My work” whenever it suits them. Having been working this way myself for the past few months – with notifications turned off completely – has been transformative for me. I feel much more focused, more productive, and happier in my work.

We believe both job satisfaction and maximizing the rate of value delivery depend on working in serial as much as possible: completing tasks, shipping value to customers, and moving on; generally avoiding multitasking but jumping in to unblock teammates when required. In our view, developers shouldn’t have more than a handful of tickets assigned to them at any one time, and reviewing code and unblocking tickets should be done fairly quickly. The My work menu reflects and supports this philosophy. It isn’t intended to be a lengthy table of dozens of items; it’s meant to be a short list of what needs your attention today and what can reasonably be done this week or next. When we started using the My work menu ourselves, one positive side effect we noticed is that it creates a gentle pressure to resolve open threads, clean up ownership, and just generally run a slightly tighter ship. We hope you find it as useful as we have.

This is our first attempt at solving the deeply important problem of getting developers the information they need instantly with zero friction, and it won’t be our last. Thanks to everyone who helped us iterate on this feature over the past month, and we look forward to getting more feedback about it!

(Note: ticket pull requests waiting for your review will only appear in your My work menu if you’ve connected your GitHub username in Settings | Profile.)