Constructor: the lightweight, pragmatic dev tracking tool(kit)

by Seth Purcell on 1/7/2022

Why do so many software teams feel their tracking tool is more of a hindrance than a helper, adding complexity, friction, and opacity to the work that it’s supposed to be facilitating? We think it's due to a mismatch between how they want to work – as simply as possible – and the ability of their tracking tool to implement their process in a lightweight, pragmatic way.

The tracking tool is mission control for most software teams of nontrivial size. Its job is to collect, organize, process, and disseminate the information required by team members in their various roles, and that involves both modeling and facilitating the team’s work. If the tracking tool can’t model how a team works in a lightweight way, it’s perforce adding complexity and, by extension, friction and opacity for the team. This is the problem that Constructor aims to solve.

But how are we going to solve this problem where many others have (in our opinion) fallen short? We think the problem and the solution both lie in the data model. We envision Constructor not as an embodiment of a particular development process but as a lightweight, flexible toolkit for implementing a wide range of processes; as a medium for teams to map how they work onto data structures that they’ll then interact with, many times a day. And as anyone who’s worked with different woods, clays, paints, metals, or programming languages knows, your medium has a huge influence on what you’re able to create. If a team wants to have a lightweight system for tracking their work – as most teams do – their tracking tool has to make it possible. We believe success here – and the core challenge for us as product designers – lies in making it easy for teams to strike the right balance in their tracking tool between fidelity to how they work and the effort required to operate it. Or to frame it another way, between what managers need to know and what developers are required to provide. Of course, a custom-built tool could theoretically nail that balance perfectly, but at a cost few teams – even at the largest tech companies – are willing to pay. Note that modeling flexibility is not the same thing as “customization”: rather than e.g. providing a rigid hierarchy of work structures and just letting users rename its parts, with Constructor you can create the hierarchy however you see fit – or don’t, if you don’t need it.

But Constructor can’t just dump a bunch of parts out on the floor and say “there you go!”. On the contrary, we’re obsessed with delivering an out-of-the-box experience that’s superior to the lightweight tools that dev teams usually start out with, with enhancements like threaded comments, explicit free-form blockers, and deep integrations with GitHub and devops tools. But that’s just a starting point. When we think about software that inspires us, what comes to mind are tools like HyperCard that provide an awesome combination of simplicity and power that lets new users see value immediately, with no training, while also supporting them as they grow and become “power users”. What makes these tools so valuable is that by supporting their users’ growth and evolution they provide a great return on the investment users make in adopting them.

Building a lightweight, flexible tool like we’re envisioning, one that doesn’t fall into the trap of serving nobody well, is tremendously difficult. And it remains to be seen whether we’re equal to the challenge. So why don’t we make it easy on ourselves and just build a tool that implements the best dev process right out of the box? Because despite a healthy supply of priests of the one true development methodology, there is no such thing.

Though many teams share the same agile values, and may operate similarly, every team has its own context, its own history, and its own good reasons for doing things the way they do – and equally good reasons when they modify or abandon those practices to try something else. If management could be reduced to a universal optimal approach that could be embodied in software, every team would presumably be using it. The fact that it can’t be is why every team has to figure out on their own what works best for them, given their goals, constraints, and culture. And that’s the real reason why Constructor must be flexible and not rigidly dogmatic: not to support lots of teams doing things differently, but to support each team through its growth and evolution.

Both times I’ve assumed the leadership of a small dev team I’ve immediately dispensed with whatever bloated/opinionated thing they were using to track their work and spun up the most stripped-down kanban board I could find. The improvement in simplicity and clarity was dramatic, and appreciated both within and outside of my department. Everyone could easily see what was going on and stay focused on what mattered – building the right stuff and maximizing our flow. But my bare-bones approach hit the end of the road as the team repeatedly doubled in size and added business requirements like predictability to our process. Our vision is for Constructor to be the dev tracking tool that lets teams start simply with no setup or learning curve and evolve easily so they can adapt how they work to rapid growth and organizational change – while constantly minimizing friction and maximizing clarity for everyone on the team.