The Times Are Changing in Software Engineering
How we can make the most of it?
—
One thing is certain in the software engineering industry nowadays: it is changing. After intense growth for multiple years, we see retraction and layoffs in most technology companies, rapidly shifting the landscape for engineers and managers.
Without the capacity to add more people to sustain growth, we also see this movement’s natural consequence. Companies need to focus on their engineering department’s efficiency and performance.
While this is expected and, in some ways, positive, it is also a delicate transformation. We can do it in a manner that moves our industry to be more performant and predictable while maintaining innovation, engineers’ fulfillment, and respect for the software craft. Or it can be simplistic, focusing on antiquated concepts, leading to a loss in effectiveness.
We are still at the beginning of this transformation. Unfortunately, the first signs could be better. But before discussing how to approach this challenge, we should discuss software engineering as a discipline.
Software Engineering As We Know It
We have been developing software systems for a while now. While every context is different, and there are still significant advancements to happen in the industry (hello, AI!), most of the software developed by technology companies nowadays follows similar principles. And we mostly know how to build it: focus on the outcome, build iteratively, integrate continuously, write tests, build with high quality, and collaborate.
These principles have been around for decades and should lead to a very effective industry. Still, we sometimes see software engineering treated as pure art over science. If you ask an Engineering Manager where their team spends time, they likely wouldn’t know it. Many teams and companies struggle with quality and are overburdened with issues coming from it. The average engineering executive cannot specify where the multi-million dollar investment in engineering is being applied. If you observe some teams, it is hard for anyone outside of it to understand what work is being done. Sometimes it is hard to even for people inside the team to understand it. In summary, we can do better than that.
On the other hand, software engineering continues to be a highly complex activity. While a good part of any software project is predictable, some are complex and chaotic. A new feature can be simple, but adding it to a high-scale production system without introducing any issues is not. Engineers work with abstract concepts while maintaining context on a large set of constraints. Even deciding what has to be built and aligning it between product, design, and engineering is a complicated effort that requires multiple iterations.
Building software is a high-variation activity; treating it like it isn’t will only lead to a vicious cycle of poor quality and pressure.
Do More with Less
With the context above in mind, the trending phrase in technology is how to “do more with less.” If a company cannot increase its headcount, how will it keep delivering its product and growing? Engineering leaders are now in the hot seat, having to guide the transition and balance the expected needs of their product and the complexities of engineering.
As in any decision, there is a simplistic position. And unfortunately, it is the one being talked about the most. As a result, we now see calls to “be more productive” (which sounds very similar to “work harder”), return to the office as a solution for any problem, and a move of hierarchy-flattening, which is bound to make things worse if poorly applied.
The Challenge With Flattening
Reducing hierarchy to make companies more effective can be positive in some contexts. It is not a new idea either, and companies have applied it in different industries in the past.
However, the challenge I have seen the most with software engineering teams is not that Engineering Managers (EMs) have time on their hands and could use more reports. It is that EMs are putting their primary focus away from their team’s effectiveness. Adding more reports under them, in this case, will only make the situation worse.
Reducing Engineering Management to managing the individuals in a company is the anti-pattern that our industry needs to counteract to achieve more effectiveness. Instead, EMs should be leaders who drive their teams toward results through multiple facets, including technical leadership, organizational alignment, process improvement, individual growth, performance management, and delegation. Adding more reports to a manager without changing this perspective will only amplify the negative pattern.
There are many managers who are not executives. Many people, in other words, are superiors of other people and still do not seriously affect the ability of the organization to perform. […] They are “overseers” in the literal sense of the work. They are managers in that they manage the work of others. But they have neither the responsibility for, not the authority over, the direction, the content, and the quality of the work or the methods of its performance.
Peter Drucker — The Effective Executive
In practice, flattening the hierarchy without changing the EMs perspective will either lead to less effective teams or engineers becoming de-facto managers, having to contribute technically and drive alignment in their work. While the latter is possible, we have long known about managers’ and makers’ schedules. Engineers can be effective leaders, but they will do that to the detriment of their capacity to focus and contribute technically.
A Better Perspective
There is a better way. A more productive version of this transition is to focus on the systems around the software team, making sure they are as effective as possible. And to do that, EMs need to have the time and the support to do it.
In practice, there are actions companies can take to achieve more with less without reducing the quality of their output or of the fulfillment of their employees (pro tip: these are not new ideas):
- Move their focus to team effectiveness rather than individual effectiveness. Incentivize collaboration patterns, review performance based on the team’s impact, and reduce their reliance on individual “rockstars”.
- Empower managers to lead toward effectiveness. Train EMs in team leadership rather than just people management. Provide authority and accountability for the team’s work and results.
- Create an environment where engineers can be more productive. Reduce the reliance on engineers to craft and manage their own projects, resulting in more focus time for technical work and collaboration.
- Drive individual fulfillment and growth through team effectiveness. Create systems that incentivize engineering growth and progression aligned with their team’s results, not only based on individual paths.
Ultimately, understand the software development system and act to improve it. In my experience, the average software engineering team can be much more effective. It just has to work smarter and not harder.
If you have found this content interesting, I write about leading effective software engineering teams.