Software Engineering Managers Need to be Technologists
Putting the Engineer Back in Software Engineering Manager
I don’t have time to develop. I’m too busy attending meetings. I’ve got status updates to attend to. I develop budgets and staffing plans. Development is for developers. I’m a strategist, not a tactician.
These, among many others, are common lines uttered by software engineering managers. Are you one of these managers? How often do you practice software engineering? The likelihood of a response similar to ones mentioned above will be directly correlated with the size of the organization. The bigger the organization, the more likely it is that your Software Engineering Manager title should simply be shortened to ‘Manager’. Because it’s quite likely that your software engineering skills are stuck back in time, somewhere around the day you got promoted from being a Software Engineer. You are a modern-day Rip Van Winkle.
Each day of creating budgets, getting and providing status updates, and staff planning is getting you further from your roots as a respected technologist. Now when you open your mouth in an attempt to impart technological wisdom, your engineers roll their eyes. What you used to do “back in the good-old days” is no longer relevant. While you may be good at status updates and schedules, your technology skills have become obsolete.
Maybe you don’t consider this tale a sad one. You may no longer be interested in the technical side of software development. You may feel comfortable with your current role as a non-technical manager. Maybe technology requires too much effort to keep up with the constant changes.
The Rules are Changing
While the non-technical (or slightly technical) manager was a model that has worked in the past, its usefulness as a management model is fast decreasing. When your software engineering organization is filled with non-technical leaders, you will see the following rules.
Non-Technical Management Rule # 1: Create a strong centralized architecture group that is required to weigh in on just about every technical decision that gets made.
When the engineering manager is not technical enough to own technical decisions, then another policing mechanism is required. The architecture group is needed to keep software engineers from being dangerous. However, it creates serious operational bottlenecks for just about every team in the organization. Additionally, these architecture groups often became a source of political strife. It often creates friction between the architects and the developers. In some cases, the “ivory-tower” architects aren’t required to do much actual coding, and they also become out-of-touch with the latest technological innovation.
Non-Technical Management Rule # 2: Ask for lots of status updates from the software engineers.
There is a key difference between a software engineering manager who understands the technologies used by their team, and one who doesn’t. The technological-savvy manager is able to infer from his team the project status during the course of daily operations. They don’t need to waste significant amounts of developer time trying to understand what everyone is specifically working on and how the project is progressing.
The Old Rules Are No Longer Relevant
There is one key thing that is wrong with both of these rules. They take too much time! With the speed at which technology changes, we don’t have the luxury of allowing key decisions to be held up for weeks and months. It doesn’t matter if the reason is architectural group politics or just too large of a work backlog.
The same goes for too many status updates. If your manager is constantly looking for status updates from developers, it’s an incredible amount of time lost that could have been used developing new features to make customers happy. Aside from the lost time taken for the status update, there is additional cost of continually breaking a developer’s flow through constant interruptions. This cost is probably greater than the cost of the actual status update.
Customers are extremely whimsical, especially when it comes to technology-related user experience. If your competitors can get features out faster than you can, you’ll quickly line up in the race to the bottom.
There is a very interesting blog post at https://www.nginx.com/blog/adopting-microservices-at-netflix-lessons-for-team-and-process-design/ regarding Adrian Cockcroft’s idea from his time at Netflix stating that it is better to Optimize for Speed, not Efficiency. His idea is that it is better to get features out as fast as you can, so that you can quickly react to market feedback. Instead of trying to optimize your technological architecture in a way that supports every possible use of a particular service, you may end up creating two similar services for differing use cases. However, it’s better to overlap if it helps get the features out faster.
Large Software Engineering Organizations are Noticing
While it has taken a while for large organizations to realize that the traditional approach to developing software is changing, they are starting to take notice. It has become cliché for large companies to claim to be the “world’s largest startup.” Everybody wants to be like a startup.
I have one observation about startups. They don’t have too many non-technical software managers. Everyone in the technology organization is deeply embedded in technology. One of the reasons startups are so nimble is that they are not mired down with layers of non-technical management bureaucracy. Leaders at all levels are technology-savvy and empowered to make and own technological decisions.
While not every large organization that claims to operate like a startup actually does, there have been some that have made some progress. Notably, of the organizations making progress in this area, most of them have taken steps to make sure their software engineering managers are more technically-focused.
The New Rules for Software Engineering Managers
If you are a software engineering manager who wants to remain relevant in the incredibly fast-paced technology industry, you need to continue to invest time and energy into your technology skills. You need to know what technologies are currently trending. You will need a solid understanding of what problems they solve, and which problems they don’t. You’ll need to understand the contexts that they are useful. You’ll need the ability to conduct intelligent conversations about the pluses and minuses of various architectural decisions. In short, if you are a software engineering manager that came from a software engineering background, you can’t forget what got you here.
