Comments URL: https://news.ycombinator.com/item?id=42691095

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37661991

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=35956278

Points: 18

# Comments: 22

Comments URL: https://news.ycombinator.com/item?id=35281322

Points: 5

# Comments: 1

(I'm not affiliated with them.)

Comments URL: https://news.ycombinator.com/item?id=33628208

Points: 5

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=33237690

Points: 2

# Comments: 0

For anyone who doesn't know us, we have an unhealthy obsession with simplicity and set out to build something as conceptually simple as Trello but with much better usability, and specifically for software teams.

1. https://constructor.dev

Let's leave aside for a moment that this piece begins with an impressively uninformed and circular definition – "Developer productivity, in general, refers to how productive a developer is during a specific time or based on any criteria." – and focus instead on the question of why does this stuff keep popping into existence; what's behind it?

As a tech exec who's researched and given several talks on this to large audiences of non-technical execs like CEOs and CFOs, I believe the root causes are an understandable and intense desire for "visibility" and exec accountability coupled with a set of false beliefs held by non-technical managers including "anything can be measured if you try hard enough" and "nothing can be managed unless it's measured" and the classic quantitative fallacy of "things that can be measured are more important than things that can't be". Besides, it's only fair that if the VPs of sales and marketing have to stand up and talk about funnel metrics and sales rep productivity (with real metrics like net new bookings divided by fully loaded sales rep cost) that the VP of engineering - an often enormous fraction of a SaaS company's budget – should be similarly held to account for some number, any number, we just need a number, so we can look for "trends" (actually, noise). It also seems to be driven by a push from HR for fairness in promotions and terminations, which is also totally understandable, yet misguided.

I have a wisecrack response to non-technical executives when discussing this which is "how do you measure your own productivity?" that helps them understand the absurdity of what they're trying to do and how common it is that no true measure of productivity exists. People really struggle to understand that some metrics, no matter how great it would be to have them, simply do not exist, and so we have this – measurement theater.

[edit: fixed typo]

Our differentiator is lightweight flexibility, supported by conceptual models that reflect reality and don't impose one particular way of doing things on teams. Our goal is for teams to be able to "start simple and evolve easily" because for many teams their process is always being adjusted as they grow and mature. Our approach is essentially "Trello is like 90% of what many teams need, let's redesign it from the ground up for software teams and get it to 100%". It's early days but it's an approach that seems to resonate with many teams. At least partly this is because PMs and designers readily understand Constructor instead of being annoyed/overwhelmed, so everyone is happy using the same tool, and that's pretty important (to avoid tool schisms).

This is an awesome point, and one which we're keenly aware of. This is how we think about this:

Constructor must serve different roles with their own notions of success, and those notions may be at odds. That is, there are some tensions and tradeoffs within teams that exist independently of any tool, e.g., managers want stuff reported but developers just want to build software and not fill out TPS reports.

So our approach to solving your biggest problem is to try to create the best UX for each role, period, which implies Constructor must mediate these tensions where possible. For instance, our approach to blockers is very lightweight and we saw immediate uptake from devs when this was released, indicating they saw it as a help, not a burden. And of course it makes it apparent to managers what's going on without having to pester anyone. So we consider this a feature that helped both managers and devs do their jobs better without imposing an unwelcome burden on anyone. We're looking to extend this pattern in much more clever ways to get managers the facts they need without burdening developers with housekeeping tasks to provide those facts. It's a tough problem but we're optimistic we can make headway here.

Thanks for raising this point; it's really, really important.

Your 80% observation is if anything an underestimate; there's almost nothing in Constructor that makes it dev-specific beyond the GitHub and devops integrations that are mostly absent if you don't activate them, and would be easy for us to make totally optional. This surprised us when we realized it, because we are quite devoted to serving software teams specifically.