There are some fallacies about product development I’ve faced over my career that not only make daily work harder but actually have a toxic effect on both culture and processes.
Sometimes these misconceptions come even from seasoned, senior leaders - which is on one hand quite surprising, but on the other hand totally understandable, looking at the classic environments these leaders socialized in.
Let’s look at four of these fallacies today.
1. Low productivity or output is because of lack of motivation
While this can be true, it’s not the first place I’d look for an answer. I’ve seen scenarios much more often where the main factor was the environment. This can take any combination of:
- lack of vision
- lack of purpose
- too much toil (see this post on technical debt)
- unclear processes
- gatekeeping
- super fragmented calendar (lots of meetings in the wrong time slots)
Look at systemic issues first.
2. We need early and accurate estimations
Nah, you don’t. Also, it’s mostly impossible.
In many cases this is about ‘but my boss is asking for it, so it’s my job to provide them’.
Wrong. Your job is to create clarity and push back whenever necessary. If it’s impossible to do so, my advice is to find another place (but try first!).
In reality, most projects (especially longer ones) are nearly impossible to estimate well upfront. There are simply too many unknowns, pitfalls, things to research and discover.
Take a look at the Cone of Uncertainty.
Usually where this push for early estimates comes from is because stakeholders need to understand the Return On Investment profile for projects and simply want to make sure the organization is focusing on the highest value delivered over time. There’s nothing wrong with this, in fact, this should be our goal! The trick is that nobody sees the future.
Your best bet is to make small, exploratory investments. Use your best judgment to identify the next most important thing and invest some time to both validate its value and to get a better understanding of the investment needed. Do it with the top items of your investment portfolio or idea backlog, regroup, rinse and repeat.
Use something like the (R)ICE scoring method to understand what you should focus on next. Refine as you learn more along the way and don’t be afraid to reprioritize and refocus.
3. We need to get more work started, for speed
There’s not much you can do about your capacity other than hiring, onboarding and training people. We often fool ourselves into feeling productive by starting many things at the same time, which gives us the illusion of progress but in reality, it just dilutes our effort.
Streamline your workstreams according to capacity and leave a buffer for unexpected complexity, vacations, attrition, and sick leave. Consider that pair programming, decision making requires multiple people. A team of 5 engineers probably should not take on two parallel long-running initiatives.
Optimize for the outcome, rather than output. Sometimes the code you haven’t written is the best, and in analogy, the feature you didn’t deliver leaves time for more important things.
You need Ruthless Prioritization.
4. High output comes from isolated, individual coders
Rookie managers (and young teams) often make the mistake that having 5 engineers means they’ll work on 5 distinct backlog items. While sometimes this can happen (very small, well-defined cards), most often folks need to put their heads together to figure out good solutions.
Also, on the project level, the team needs to coordinate frequently about strategic and technical decisions. The isolated coder is a myth.
Another angle: think about whether you’re creating heroes in your teams and how it’ll affect everything.
Proper teamwork usually results in a much more effective value stream.
This post was inspired by this thread from Agile Otter Tim