I’ve mentioned this surge talk by Bryan Cantrill a time or two in previous posts, and I’d like to take a deeper dive into his management philosophy and possible ways to take ownership of scaling ourselves as engineering leaders (you can find the talk on Youtube here).
First, the problem: the inefficiency, lack of team confidence and trust, and poor product/project outcomes resulting from software managers/leaders that do not have first-hand development or engineering experience. This is the classic middle management vs software engineers as management dilemma. As Mr. Cantrill put it so succinctly, “those who have not developed software cannot possible appreciate the degree of unknown unknowns in novel software development”.
Second, historical cause. In the past, the situation was widespread for two main reasons that I can see; one – traditional business hierarchies were not flat, which created a false ‘need’ for middle managers on software projects in the first place, and two – many companies employed a single ladder (as opposed to a dual ladder) system of career advancement, where engineers would end up leaving their posts at some point because the next pay grade up was management, and not engineering or development. The heyday of Silicon Valley had a positive impact on many of these issues, showing by example that engineers could not only manage other engineers, but self-manage independent of any middle management. Sadly, a fair bit of the industry landscape is still mired in old models of thinking about management and leadership. All is not lost, there are some very concrete ways to improve the system, and yourself regardless of whether you’re an engineer or a non-technical manager.
Third, lasting effect. Some of you might be thinking that it would be better to shut up and commence with the teeth gritting; software development is a business and by definition requires a complicated (often redundant) oversight/management system. Let’s consider some of the drawbacks to that perspective: loss of engineering talent, lack of trust and confidence in team/project leadership (which severely affects team morale), and negative incentive to produce great quality work. To be fair, we should also consider the positives…hmmm there don’t seem to be any.
Lastly, the big question: how can we level up? Since there are two primary use cases, let’s start with how non-technical/engineer managers and leaders can level themselves up and finish with software developers and engineers.
Non-technical/engineer managers:
- Build shit.
- Be technically literate. That means going beyond knowing the right buzz words about the development you’re supervising and actually understanding the languages, tools, and platforms being used.
- Regularly try and contribute to the code base, QA, or really any technical facet of the projects you manage. Don’t hyperventilate, this doesn’t mean take ownership of complex systems, it simply means having your hands a LITTLE dirty ALL of the time.
- Establish regular code reviews and PARTICIPATE. See #2.
- Build more shit.
Software engineers:
- Seek out management certifications and trainings. Learn what has been done, what does and doesn’t work, and adapt it to your needs.
- Show don’t tell. Constantly look for opportunities to prove your system (whatever that may be) works in the real world. There is nothing more persuasive than having a working example when told that it simply can’t be done.
- Most importantly, lead everyday and BE LEAD. Eventually you will have the experience to do away with middle management on your development projects, or at least mitigate their implementation where not needed.
Small changes to an organizations hierarchy and management implementation can go a long way. I’ve said it before and I’ll say it again, the software industry is largely a community, and can craft its own future as it sees fit, from the micro/startup to the macro/enterprise level.
PARADIGM SHIFT DEVELOPMENT 