Decision making is a lead developer’s responsibility to choose a course of action and see it through. A sound choice takes critical thinking: consider risk, form a plan, stay level-headed, and avoid acting on unsupported assumptions. The decision is not finished when the plan is announced; check progress and use team feedback to correct course. section 1.3.3
Before and after a decision, ask:
- What does the team know? Share information rather than merely issuing a plan, and gather feedback—including when a quick decision is needed. section 1.3.3 section 1.1.3
- What do stakeholders and end users need? Their feedback can change design, functionality, or the development approach. section 6.2
- How will the options affect the people doing the work? Consider motivation and well-being alongside technical factors and the schedule. section 11.1.2
- Is the plan working? Check in during execution, share information when work drifts, and adjust rather than assuming the original decision settled everything. section 1.3.3
Features or fixes?
A team wanted to repair a frustrating codebase before adding features, but the project schedule still mattered. The lead listened to concerns on both sides, then agreed with the team to fix bugs directly affecting the features underway and address the remaining problems later. The choice balanced delivery with team motivation rather than treating either as irrelevant. section 11.1.2
Confidence matters, but it is not a reason to skip input. When a project was late, one lead spent weeks comparing options and eventually chose the industry-standard option they had considered first. The lesson is to use experience and analysis to make a timely choice, not to wait indefinitely for certainty. Project-management cross-training can broaden that judgment, while mentoring can help others learn to make decisions independently. section 10.1.1 section 7.1 section 9.6
