When developing, planners and managers would sometimes say, "Ugh, that developer mindset..."
What is this developer mindset?
I remember hearing it mainly when developers reacted negatively or defensively to certain developments/issues, but developers don't react that way from the start.
When a development project is brought up and the question "How long will it take?" is asked, and if the feature isn't completed by the date the developer suggests, after experiencing the "You set the schedule" infinite responsibility a few times, they start to set the schedule to 1.5 to 2 times longer, and they tend to answer as negatively as possible.
This is because developers are held solely responsible for situations they couldn't have anticipated before development began, but as time goes by and experience accumulates, they start to "predict" those situations and set schedules accordingly. Developers who become experienced may or may not keep to their schedules, but that doesn't have a positive effect on companies, especially small ones like startups.
When a developer's schedule isn't kept, if a problem arises even though the developer has made an effort, you should accept and acknowledge the developer's explanation 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, and instead of reactions like "That won't work, it'll take a long time," you can get reactions like "It seems difficult, but I'll give it a try."
Understanding the Developer Mindset and Effective Schedule Management
When developing, planners and managers often say, "Ugh, that developer mindset..." In particular, this expression is often heard when developers react negatively or present schedules conservatively during the schedule estimation process. However, developers don't take this attitude from the start.
Developers' Schedule Estimation Methods and the Formation of Defensive Attitudes
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 tend to 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 is repeated, developers become more conservative when estimating schedules. For example, they may increase the estimated time by 1.5 to 2 times, or they may choose to assume the most negative scenario and answer accordingly. This is not a simple defense mechanism, but a reasonable response formed through experience. It is the result of learning that schedule adjustments are necessary, taking into account the many variables in the actual development process.
Experienced Developers' Schedule Predictions and the Startup Environment
Developers with experience consider these variables and estimate schedules more realistically. However, a higher schedule adherence rate does not necessarily have a positive effect on small companies like startups. This is because if developers set schedules too conservatively, the company's ability to respond quickly may be reduced.
In startups, quick execution and appropriate risk management are important. Therefore, if the development schedule is delayed, it is important to acknowledge and flexibly respond if the developer has made sufficient effort but unavoidable problems have occurred. From the developer's perspective, an approach of "What problems were there, and how can we solve them?" is needed rather than the blame of "Why was the schedule delayed?"
Creating a Positive Culture for Collaboration with Developers
To prevent developers from taking overly defensive attitudes, it is necessary to create a culture that accepts and acknowledges the developer's explanations when schedules are delayed, rather than rejecting them unconditionally. By doing so, developers will also consider the company's position 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 give it a try, even though it seems difficult" instead of saying "That won't work, it'll take a long time." To this end, it is essential to create a collaborative environment based on trust and to avoid a culture that excessively criticizes failure. Supporting developers to have a positive attitude towards new challenges will ultimately help the company grow.
Conclusion
The term '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 them with responsibility for schedule delays. Through this, both developers and the company can move forward in a positive direction.