Ultimately group success of any kind is determined by good people doing good work. Period. A good sponsor, 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 management environment in which they operate. In this respect, the degree of their success and rate at which they achieve it is largely determined by the philosophy of their leaders.
Philosophy, intentional or otherwise, is implicit in every group thought, witness and deed. To get a glimpse of 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 leader manages his resources by accruing as much power as possible. In this way, they can better dictate necessary group behavior with the intent of more precisely predicting 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. This and the contributors’ ownership-style of engagement arms them with the freedom and information necessary to constantly adjust the precise quality needed for their specific area of concern.
Trust coupled with ownership mentality 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 are 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.
Comments