It’s time to fight back against complexity and distraction
Constructor was born of several frustrations.
Frustration with having to choose between dev management tools that are either a) simple but so limited that they push complexity elsewhere, or b) powerful but so complicated that they add friction to every interaction and are difficult to adapt as conditions change.
Frustration with dev management tools that constrain teams to dubious “best practices” that certainly aren’t best for everyone. Or serve managers well at the expense of developers, or developers well at the expense of PMs.
Frustration with having context, collaboration, and decisions siloed in separate systems like docs, wikis, chat, and other apps, with nothing tying it all together. And as a result, having to constantly hop between these tools and hold too much in our brains.
And frustration with the endemic style of working that author and computer science professor Cal Newport calls the “hyperactive hivemind”: where an incessant barrage of concentration-destroying chat messages and email notifications makes it difficult for people to get their actual work done.
Our vision is for software teams to be able to work together in a simple, uncluttered environment that helps them focus on their real work while minimizing friction and distraction; that’s agnostic about tools and processes; that supports experimentation and evolution; and that provides clear visibility to management without imposing extra work on the team.
Our core product values:
Lightweight, flexible, and pragmatic is our mantra. If something isn’t utterly required, leave it out. Make all complexity opt-in. Recognize that removing stuff can provide the most value, and simplicity takes effort.
Constructor is essentially an information collection and dissemination system: the information a user needs must always be close at hand. Priorities must be clear, as well as the status of everything in flight.
Teams must be free to choose how they work, to make incremental improvements as they grow or their process evolves, and to cheaply and reversibly experiment with new ways of working.
Defend the real work
Eliminate friction wherever possible. Keep the focus on the real work – the docs, the designs, the code. Minimize breaking team members’ flow by offering alternatives to interruptive notifications.
Serve the whole team
Most teams include users in different roles with differing requirements. If we serve some of them poorly, we run the risk of them breaking away and using a different tool from the rest of the team – an outcome nobody wants.
Constructor is part of a system including users in different roles and departments, ever-changing processes, and other tools. If we reduce friction or complexity in our app by creating it elsewhere, that’s not a win for our users.
About the founders
Seth Purcell has been leading software teams at startups for more than fifteen years and was previously the CTO of Signpost, a marketing software company in NYC. Seth has been programming and designing user interfaces since learning BASIC in 1990 and is a little too passionate about software engineering management. Seth studied Aeronautics and Astronautics at MIT.
Andrew Kallem has pursued software engineering since childhood, including web, mobile, and game development. Most recently he was an engineering team lead at Signpost. He has also led technology projects at Goldman Sachs and McKinsey. Andrew studied Economics at Harvard and Computer Science at Columbia.