As a leader of 25 young’ish software developers I’ve come to realize that the lack of history is both a blessing and a curse. > If I’m a leader that is serving

As a leader of 25 young’ish software developers I’ve come to realize that the lack of history is both a blessing and a curse. > If I’m a leader that is serving a team of people doing manufacturing work, there are scientifically proven processes and techniques that can be readily trained and applied. And someone who learns those manufacturing management techniques can reliably boost team productivity. The same cannot be said for software leaders Leadership is one thing, process of work something else. Using techniques from manufacturing is one of the most effective ways of improving output and quality of a software team. The Lean principles matches up quite quite well with the work of producing software. This, however, does not in any way imply that you should treat devs (or people in general) like machines. Work process is incredibly important to create a professional and able organization - leading people here without infringing on their motivation, continuous learning and control is what management is about (to me at least). Many of my young devs have not lived through the 90s and 00 with it’s projects and outsourcing/off-shoring strategies. They’ve landed in the aftermath of an agile revolution turned a beast in it self. They’ve seen nothing else and are forced to accept it. My job is to have them level up and pick the cherries out of the mess we’re in. Have them make it theirs - have them own the process. Agile, in my mind, is about professionalism, ownership and accountability on behalf of the devs. Give them the freedom to claim the above and an insane output can be achieved while having fun. Simple but clear process should surround this work, but the ”why” have to be internalized by the team.