This episode is for anyone who wants to effectively orchestrate a development process without becoming the butt of their team’s water-cooler jokes. It's more attainable than you think, because it's all about process. Don't be a Bill Lumbergh - be awesome. Written and read by Jonathan Solórzano-Hamilton: https://twitter.com/jhsolor Original article: https://fcc.im/2GW6xFX Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: Laurence Peter formulated the principle that “managers rise to the level of their incompetence” in 1969. In particular, non-technical leaders have earned a poor reputation with software developers. Office Space depicts the non-technical manager in Bill Lumbergh, pictured above. Dilbert provides the classic “Pointy-Haired Boss.” This article is for anyone who wants to effectively orchestrate a development process without becoming the butt of your team’s water-cooler jokes. I’ll share what I’ve learned over the years managing development and release processes as a manager and software architect at UCLA and Stanford University. The biggest lesson I’ve learned is that the key to sustaining successful software releases is completely non-technical. It’s about process. Some aspects of a development process benefit from technical know-how, but it’s not required. Successfully releasing software into production is much more a question of robust process architecture than design or code alone. For the purpose of this article, we’ll assume you’ve already agreed to start building something. The product approval pipeline is a different process. Today we’re focusing on getting the agreed-upon product from concept to production. What to build Your team needs to assemble a clear roadmap for their code. Architects and manufacturers use blueprints. You should too. Your roadmap should include a set of schematics which each fulfill a different purpose. These schematics differ for individual applications. A user-interface mock-up, application architecture diagram, and business process model are common. More detailed component diagrams such as Unified Modeling Language (UML) diagrams and flow models are often useful as well. Technical expertise lets you use these schematics to critique your team’s architecture and ensure they’re on the right track. Even without technical skill, these schematics will be critical. You can use them to drive productive conversations about product completion. No more will you have to draw a “% complete” out of thin air or best-guess from the development team. You can track the status of each item on the diagram to determine how close the app is to completion. You can also project future velocity based on how quickly the team completed prior components. There is no “right” amount of pre-development documentation, but there is one wrong amount: none. Work out with your team what constitutes an acceptable roadmap before they start coding. The first checkpoint in your development process will be to review this documentation and ensure they’ve met this agreement. What not to build Your team can’t build everything. Nor should they. You need to ensure that your developers have a laser focus on what they actually need to build. Why are you building this app in the first place? Define the key differentiation from existing products. 80% of your team’s time should go toward supporting that differentiation. The schematics you should now have will be helpful here. Does your application include a logging component? A sign-up and login process? There are already excellent free, open-source software (FOSS) frameworks in most languages for these components. Some are available under extremely permissive licenses. Tesla provides a great illustration of this concept. Their first key differentiator was to use a lithium-ion battery to make electric cars competitive with gas. Lithium-ion achieved this by reducing battery weight and increasing range. The first Tesl