Ultimately the future of any endeavor will be determined solely by good people doing good work, supported by or in despite of their circumstances. A good owner, designer, and developer can build great software, no matter what the process or team structure – should they care enough to do it.

However, their efforts will be accelerated for stymied by the environment in which they operate and the degree of success attainable is determined significantly by the philosophy of its leaders.

Philosophy, intentional or otherwise, is implicit in everything thought, seen and done. To understand the philosophical spectrum and how this might impact the future of your project, consider the following antithetical approaches to engineering management.

At one end of the spectrum, the head manager accrues as much power as possible in order to dictate the everyone’s necessary behavior. This ensures total control and, therefore, the ability to precisely predict both near and long-term outcomes.

On the other, servant-leaders attempt to empower their followers as much as possible for their pursuit of near-term goals. A clearly communicated strategy guides tactics but this is expected to change as new things are learned. Intense collaboration and individual autonomy are highly encouraged and interfered with only when really necessary. Some messiness in tactical outcomes is expected as the known cost of constant innovation, learning, and improvement.

On one end of the spectrum, management ‘owns’ everything to minimize chaos. ‘The Schedule’ – delivery dates, what’s in each delivery, and who will work on what are all determined as far in advance as possible and then locked down. Changes to The Schedule should be rare and are perceived very negatively. Promises by engineers become increasingly padded to avoid the incurred backlash when they learn something new that would force them to revise estimates upward (and impact The Schedule).

On the other end of the spectrum, each individual is encouraged to develop an owner-mentality, becoming more deeply invested in understanding the inputs and in ensuring the right outcomes. The pace of new feature delivery remains regimented (time-boxed) but good-enough-quality outputs are committed to in small chunks. Leaders’ trust in individual contributors and contributors’ ownership-style engagement arms them with the freedom and information necessary to constantly adjust the level of necessary quality in their specific area of concern. It also ensures that open and honest commitments are made with constantly increasing accuracy. New, unforeseen information is embraced as a vital nugget for priority optimization in advance of the next planned commitment. Changes to the long-range schedule are viewed positively because individual-owners know these changes will lead to working software that more closely reflects actual customer and system user needs.

On one end of the spectrum, back and forth communication between system users and ‘the customer’ is tightly controlled. Only thoroughly adjudicated and scrubbed changes of any kind will make it into the system. All exhibits of the system will be planned out many months in advance. This way, customer perception and expectations are ensured to be lock-tight. This minimizes any adverse impact to The Schedule.

On the other end of the spectrum, new channels of communication between the customer and system users are frequently devised so that tight feedback loops can be established. This enables better prioritization and, consequently, better improvements to the system, all the time. Demos are performed weekly so that the latest system improvements are showcased as soon as possible. Showcases maintain close accountability between engineering and the customer while also creating positive morale. Morale is constantly reinvigorated by a feeling of accomplishment and finished work.

The list goes on and on.

These alternative approaches and their long term results are as different as night and day. Since the early 2000s, the differences have been documented thoroughly by industry and academia. As a result, cost and efficiency oriented start-ups doing bleeding edge product development all list jobs that request skills and experience with “Scrum”, “Lean”, “Six Sigma,” “Kanban”, etc while large, old government contracts list jobs that require “Full-lifecycle SDLC, PMP, etc.”

So which philosophy is your project currently using and which has the highest chance of success? It’s up to you.