"Do our team developers really just code?"

What is a day like for our development team’s Kim or James? Thanks to a few days of investment, we finally caught the bug that had been a problem until yesterday. Today, it’s finally time to develop the new feature. He opens the code editor and several tools, starts searching hard, and begins tapping on the keyboard to start his work. ...or so we think, but the reality is a bit different.

In reality, developers spend a lot of time figuring out how to phrase questions while opening Slack to send them to the planning team; they type and delete questions repeatedly. They search through Notion for the planning document and meeting notes; they ask other developers, "Do you know about this button’s UX? When I click this button, does it move to a new screen or open a modal?" ... Is it not the case that they often spend more time on such tasks than on coding? In the end, unable to find an answer, they might think, "Well... I’ll just create it this way and modify it later," making arbitrary decisions on ambiguous parts and starting the work.

I don’t think this situation occurs only in our development team (I hope not). We expect developers to develop, but in reality, we are wasting their precious time on invisible 'planning chores.' Today, I want to discuss this hidden cost and ways to reduce it to maximize development productivity.

1. Do you know about our team's 'hidden factory'?

In manufacturing, the inefficient resources added to fix defects that occur during production processes are called 'Hidden Factory.' This hidden factory causes tremendous losses in productivity, but it often goes unnoticed by managers.

The same is true in software development. Our hidden factory is the 'inefficient time spent deciphering, questioning, and inferring an unclear and fragmented plan, and sometimes reworking mistakes.' This time stealthily eats away at the team members’ precious capabilities.

The planning chores that developers are unknowingly engaged in, who should be doing them? Some planners think it’s annoying that the developer is asking questions about things they should just intuitively know if they read the planning document, while some developers think it’s something they shouldn’t have to think about and should have been clearly stated by the planner. As a result, someone (usually a developer) ends up doing this work hurriedly and inefficiently.

2. Who is stealing how much time?

Thus, it can be said that the biggest victims of this hidden factory are the developers themselves. They are tormented by numerous planning chores every day. Here are some examples.

• Situation 1: The developer contemplates while looking at a complicated Notion document and Slack chat. "What does this policy mean...? Is this really how I should implement it?" they mutter to themselves.

• Situation 2: The developer sends a question to the planner on Slack. The planner is in another meeting, so the response is delayed. While waiting for the reply, the developer sits idly, or starts coding with the frustrated thought, "I’ll just go ahead like this..."

• Situation 3: After seeing the developed feature, the planner says, "Um...? Didn't we agree to handle this part differently in the meeting?"

However, planners also have their side of the story. In many cases, planners believe they have explained everything, and if there were any misunderstandings on the part of the developers, questions would have arisen in the meeting. Ultimately, when developers ask questions during development or when planners see the features the developers have implemented, many planners wonder, ‘Where exactly did they fail to understand my words?’

Consequently, the following issues arise between planners and developers.

• Uncertain interpretation and inference of requirements: There are numerous user scenarios or policies that are not clearly defined in the planning document. No matter how perfect a planning document may be, it cannot cover everything. Developers ultimately have to infer policies to get work done, or in the worst cases, make arbitrary decisions. However, the primary role of developers is 'development', not 'planning.' The time developers spend engaged in these planning tasks is inevitably inefficient and likely to lead to errors.

• Constant communication and re-confirmation: Developers endlessly question planners, PMs, and designers to check if what they inferred is correct, or if there are any changes in policy. The same questions are repeated over various channels such as Slack, Jira comments, and meetings, and the time spent waiting for answers directly translates to a slowdown in development speed.

• Rework due to incorrect planning: Reworking already written code due to arbitrary interpretations or changes to the planning later is a major factor that demoralizes developers and disrupts project timelines. The cost of this rework translates into countless hours of development that could have been avoided if just one more hour had been invested during the planning phase.

• The hidden planning chores of other team members: Designers handle their hidden planning chores to reconfirm the intent of the planning, and QA checks for exception cases not specified in the planning document.

3. Solution: Planning as a 'system' instead of 'documents'

So how can we eliminate this enormous hidden factory? Once again, I believe the clues can be found in the history of development. In the past, when developers coded in notepads, they would have to sift through thousands of lines of code just to catch one bug. Now they use smart IDEs (Integrated Development Environments) and AI coding tools like GitHub Copilot. It's not just that they can type code faster; the way they manage, validate, and collaborate on code itself has changed.

The same goes for planning. We can no longer simply rely on the planner's manpower and just vow to "write the planning documents more meticulously." We need to change our perspective on the act of planning itself. It’s about making planning a 'living system', rather than scattered 'documents.'

First, we need to convert planning into 'structured data.'

The biggest problem is that we deal with planning in free-form text and images in tools like Notion or PPT. In fact, in many cases, we communicate by drawing on paper. Such unstructured information may be easy for humans to create and read, but it is the worst way to maintain consistency, track changes, and identify missing parts.

Now we need to view all requirements and policies as a single structured dataset. Each requirement should have its unique ID and properties like 'status', 'owner', and 'parent goal,' similar to a database. When planning is structured this way, developers no longer need to waste time interpreting the planners' expressions. They can create clear outputs based on clear data.

Second, we need to transparently synchronize the 'context' of the planning.

Jira tickets received by developers often only state 'what' needs to be made. The context of 'why' this feature is needed, and what discussions led to this decision, gets lost in Slack chats or meeting notes.

Therefore, the planning system must transparently connect the 'history' and 'conversation' of decisions with the requirement data. When a developer views a requirement, they should be able to see not only the output but also all the context that led to its inception. This way, developers can become proactive partners who understand the context and offer better alternatives, rather than merely passive producers of code.

Third, we need to integrate planning into the developer's workflow.

The ideal scenario is that instead of developers looking for planning information, the necessary planning information naturally flows into the developer’s working environment. Imagine if, when developers write code in VS Code or IntelliJ, the requirements or policies for related functions are displayed right next to the code like comments. Developers won’t waste time switching contexts anymore.

Ultimately, increasing the productivity of planning is not just for one planner. It’s about structuring planning as data, transparently synchronizing the context, and integrating it into the workflow of team members. This is the fundamental solution to eliminate developers' hidden planning chores and elevate the productivity of the entire team. And since it’s almost impossible to defend these principles through human effort alone, we inevitably reach the necessity for smart systems and tools.

In conclusion: The fastest way to give developers back their time for coding

We expect developers to go beyond simply typing code; we expect problem-solving and value creation. The best way to help them perform at their best is to free their precious time from meaningless hidden planning chores.

This is no longer just the issue of planners. It’s a problem for the entire team and an opportunity for productivity innovation. Please give developers their time back for coding and designers their time back for design. The first step is a bold investment in 'planning productivity.'

manyfast.io