When developing, planners and managers sometimes say, "ㅉㅉ, the developer's mindset..."
What is this developer mindset?
I remember hearing it when developers reacted negatively or presented defensive schedules regarding development/issues, but developers don't react that way from the beginning.
When a development task is brought up and asked, "How long will it take?" and if the feature isn't completed by the date the developer provides, after experiencing the endless responsibility of "You set the schedule," they tend to set the schedule to 1.5 to 2 times longer and answer as negatively as possible.
This is because they are held solely responsible for situations they didn't anticipate before starting development, but as time goes by and experience accumulates, they "predict" such situations and set the schedule. Developers who become experienced may or may not keep to the schedule, but it doesn't have a positive effect on companies, especially small ones like startups.
If a developer's schedule isn't kept, and if a problem arises despite the developer's efforts, you should accept and acknowledge the developer's explanations as much as possible, so that they can set the schedule from the company's perspective in the future. Also, they will show a more positive reaction to our business, leading to responses like "I'll try, even though it seems difficult" rather than "It can't be done, it will take a long time."
Understanding the Developer Mindset and Effective Schedule Management
When developing, planners and managers often say, "That's the developer's mindset..." In particular, this expression is often heard when they show a negative reaction or present a conservative schedule during the schedule estimation process. However, developers don't take this attitude from the beginning.
The Developer's Schedule Estimation Method and the Formation of a Defensive Attitude
Generally, when a new feature development is requested, the planner or manager asks, "How long will it take to develop this feature?" The developer carefully estimates the schedule and answers, but unexpected problems often arise during the actual development. However, if the development schedule is delayed, the developer often bears the burden of "You set the schedule, so you have to take responsibility."
As this experience repeats, developers become more conservative in their schedule estimation. For example, they may increase the estimated time by 1.5 to 2 times, or they may choose to assume the most negative scenarios and answer accordingly. This is not a simple defense mechanism, but a rational response formed through experience. It is the result of learning that schedule adjustments are necessary, considering the many unexpected variables in the actual development process.
Experienced Developers' Schedule Prediction and the Startup Environment
Developers with experience consider these variables and estimate the schedule more realistically. However, a high schedule adherence rate does not necessarily have a positive effect on small companies like startups. This is because if developers set overly conservative schedules, the company's ability to respond quickly may be reduced.
In a startup, quick execution and appropriate risk management are important. Therefore, if the development schedule is delayed, it is important to acknowledge it and respond flexibly if the developer has made sufficient efforts but unavoidable problems have occurred. Rather than blaming the developer with "Why was the schedule delayed?", an approach of "What problems were there, and how can we solve them?" is needed.
Creating a Positive Culture for Collaboration with Developers
To prevent developers from taking an overly defensive attitude, it is necessary to create a culture that accepts and acknowledges the developer's explanations when the schedule is delayed, rather than rejecting them unconditionally. That way, developers will also consider the company's perspective more when setting schedules and can be more proactive in their work.
For example, it is important to encourage developers to respond with "I'll try, even though it seems difficult" instead of saying "It can't be done, it will take a long time." To do this, it is necessary to create a collaborative environment based on trust and avoid a culture that excessively criticizes failure. Supporting developers to have a positive attitude towards new challenges will ultimately help the company's growth.
Conclusion
The phrase 'developer mindset' is often used in a negative sense, but in fact, it is a realistic response formed through experience. For effective collaboration, it is important to understand the developer's schedule estimation method and not to overly burden the responsibility for schedule delays. Through this, both developers and the company can move forward in a positive direction.
