[wrs]

I must have missed something, because this seems to say you do capacity and headcount planning and publicly commit to the work before you know how to solve the problem? This seems like the “draw the rest of the owl” part of this process…

[ndneighbor]

I am more than happy to add color here, I am sorry, I try my best to write everything but my editor cuts as much as I add. We also tend to hire really autonomous engineers who tend to like just going off on their own to try to solve the issue.

There have been a few times where we would commit to the problem, assign a DRI, and then find out midway that... no we have to hire/consult our way out of the issue. I think that's okay, we then look back at the retro to see what we missed.

If interested, I think we can blog about what happens when a problem gets converted to an RFC and then we have more engineering discussions with the stakeholders but the piece was pushing a 10 min read time as it was...

[dirtbag__dad]

This is interesting to me, too! My team is in the midst of opening new reqs. A leader wants to hire based on skillset. The team wants to hire based on upcoming work. We had a decent employee churn recently because the work wasn’t what they thought they were hired for.

I can see both sides. We don’t have work planned more than a quarter out (a good thing IMO). Generalist SWEs make a good fit. But we think we need someone specialized in AI/ML. Unclear to me if that’s the case… and how to plan for it if we don’t want to explore concrete features we _might_ build.

[wrs]

"Try to solve the issue" is the key phrase there. In my experience you're generally wrong about how long it will take to solve any nontrivial software problem, and that's exactly what's hard about results-based planning.

If this is a process to decide what to commit to start working on, not to finish, then that makes sense, and I congratulate you on having an environment that acknowledges and accepts the impossibility of planning results rather than planning activities.