I have recently delved into the concept of technical debt through a series of articles, among which this insightful piece by the esteemed Martin Fowler stood out. In his article, Fowler describes the Technical Debt Quadrant and also references the observations of Uncle Bob regarding messy code and its relation to technical debt. These discussions resonated a lot with my own past experiences. Reflecting on these discussions, I've recognized a key concern in my technical leadership career: ensuring that my teams engage in prudent software development.

In recent projects, I've encountered a significant amount of legacy code. The challenge, however, wasn't the legacy code itself but rather its disorganized and messy state. To illustrate that, I encountered methods that spanned thousands of lines of code and files containing literally +5K lines of code — a clear testament to the level of disorder. Unfortunately, the existing engineering culture at that time referred to that mess as "technical debt”. Simply, it was not!

Ward Cunningham, years ago, defined "technical debt" as the necessary engineering trade-offs made to meet pressing business requirements and customer needs, often under tight schedules. There is nothing wrong with assuming suboptimal solutions in order to accelerate product releases. That is part of the game while developing software specially for business purposes. However, a method with 4K lines of code 😨 should never be considered in that category. As the wise Uncle Bob affirmed, "A mess is not a technical debt. A mess is just a mess.”

Technical debt, a part of our ongoing trade-offs in software engineering, should not be an excuse for poor code quality. True technical debt arises from genuine project constraints and should offer a clear benefit for the impending release, entailing reasonable risks and being manageable.

Why Might Teams Write Messy Code?

In my experience, I have observed teams descending into disorder due to two primary factors: irrational decision-making and poor work ethics. Often, the intense pressure of meeting business demands and adhering to tight release schedules can lead teams, especially those with less experience, to abandon rational planning. In their haste, they may end up implementing solutions without proper process or discipline. This approach inevitably results in losses, not just for the team, but for the entire organization.

Poor work ethics is another significant contributor to messy outcomes in software development. Factors like laziness and unprofessionalism are at the core of poor work ethics. Theses factors can be deeply rooted in the culture of the organization by the people building it up. Dealing with this type of challenge extends beyond the scope of engineering techniques. Addressing them effectively requires a cultural shift within the organization, which usually involve replacing individuals who perpetuate these negative behaviors.

Working Towards Clean Technical Debt

To achieve this, technical leaders and managers must empower teams to work on the basis of prudent software development. From Fowler's Technical Debt Quadrant, we can figure that a prudent debt aligns with the concept of technical debts. By deliberating taking a debt, a team should be prudent on whether an earlier release pays off or its costs will be irrationally high. In that sense, the consequences of debts will tend to be wisely beneficial and manageable to pay them down.

Managing Technical Debt Effectively

Effective management of technical debt requires a proactive approach. The first step is to acknowledge and document technical debt as it occurs. This involves keeping a record of where and why compromises are made, and the anticipated impact. Regularly reviewing and prioritizing technical debt during project iterations can help ensure that it doesn't accumulate unchecked. This process allows teams to make informed decisions about when and how to address technical debt.

Additionally, implementing good developemnt practices and standards is crucial. RFCs (Request for Comments), Design reviews, Code reviews, Pair programming, and adherence to design patterns can significantly reduce the introduction of messy code. Such practices also promote knowledge sharing and collective code ownership, which are vital for maintaining code quality over time.

Cultivating Prudent Software Development

Creating a culture of prudent software development involves more than just technical practices; it requires a shift in the engineering mindset. Encourage teams to take a long-term view of their work and understand the future implications of their coding choices. Robust engineering processes like Request for Comments (RFCs) and Architecture Decision Records (ADRs) are essential tools for establishing long-term visions and documenting key decisions, thereby facilitating world-class software development.

Emphasizing the importance of sustainable development and continuous learning can also help cultivate a prudent culture. Investing in training and professional development will equip teams with the hard and soft skills they need to make prudent decisions under pressure.

Moreover, it’s essential to establish an environment where team members feel empowered to voice concerns about potential technical debt. Open communication and a blame-free culture can help in identifying issues early and addressing them before they escalate.

In conclusion, while technical debt is an inherent part of software development, its management is critical. By distinguishing between prudent technical debt and messy code, and fostering a culture that values sustainable and thoughtful development practices, teams can deliver high-quality software that meets business needs without compromising future maintainability and scalability of the entire organization.

Back in 2021, I became an Engineering Manager at QuintoAndar, a well-known real estate tech-company in Brazil. That was an exciting opportunity for me to explore a new career path in management and further develop my leadership skills. Since then, I have also worked as a manager at Rei do Pitaco and Inventa Shop, both early-stage Brazilian startups. All of these experiences taught me valuable lessons about managing, but specially leading tech teams.

Each of those companies had a different approach to software engineering and product development. This allowed me to grow as a manager by exposing myself to various organizational scenarios and expectations for the role. Therefore, before delving into the specifics of this post, it's important to recognize that every organization you work for will have its own perspectives on leadership roles. I have learned that many of these perspectives are deeply connected to the company's values and culture. The journey will be much simpler if your perspectives are aligned with those of the company.

After two-intensive years in the management path, I felt a strong pull back to the hands-on tech side of things, where my true passion lies. Looking back, all of these career and job moves have been a journey of self-discovery, during which I have been able to explore what truly inspires me professionally — the technical aspects of engineering software.

In the software industry, making continuous impact over time goes beyond the realm of code, algorithms, design patterns, and software architecture. As an experienced engineer, you will eventually need to transition from being a software contributor to overseeing not just projects, but also people, processes, and overarching visions. Developing such skills is essential whether you want to stay on a technical track or move into the management path. From what I have seen and experienced, the impact of a Senior Engineer will invariably depend on how they can lead the way through projects, while also helping people and evolving processes. That means ascending to an engineering leadership level which is not solely about mastering the tech craft, but rather a blend of technical prowess, strategic foresight, and nurturing team growth.

Now, deeply immersed in the technical intricacies and drawing from my varied leadership roles, I want to share some of the key attributes and actions that I believe can distinguish ordinary technical leadership from effective technical leadership.

The Realm of Technical Proficiency & Business Acumen

A team invariably looks to its leader for solutions and clarity. It is paramount for technical leaders to serve as a reference for their teams. Regardless of their functional requirements, projects will require well-formed technical decisions that can ensure the basis for supporting expected functionalities of the software.

Two tactics have helped me acquire technical proficiency along the way: first, understanding well-known solutions for common problems; and second, staying up-to-date with the latest approaches in technology, tools, and methodologies from other practitioners in the software industry.

Many day-to-day problems have already been solved using various software design and architecture patterns. As a technical leader, it's crucial to analyze problems effectively, and then choose technical solutions that fit them, rather than the other way around. As you encounter more specific problems, you'll need to specialize your knowledge accordingly and eventually expand your map of solutions to the cutting edge of innovation. In other words, stay tuned about the hypes and embrace the state-of-the-art of the industry.

Furthermore, being deeply involved in the business domain ensures that every decision made is both technically sound and pragmatic. Understanding the big picture of the business and correlating it with technical challenges will ensure dominance in both technology and business. Every decision and line of code should cater to the broader business narrative. As a leader, understanding and aligning with the company's goals ensures that you are not just coding but orchestrating solutions that resonate with real problems in the organization and its products.

Foresight & Continuous Improvement

The journey of a leader often involves envisioning the future. This vision should not only address known challenges but also anticipate the "known unknowns". A "known unknown" refers to something that we are aware we don't know yet. It's a gap in our knowledge that we can identify. In the context of decision-making or problem-solving, "known unknowns" represent factors or variables that we recognize as uncertain or missing but understand that they play a certain role in the situation and have to be addressed at some point.

For example, a software development team is aware that they might face spikes in traffic but doesn't know when these spikes will occur. This is a "known unknown". In such cases, the team needs to come up with proper mechanisms to proactively foresee perspectives for addressing "known unknowns" when they arise (metrics for service monitoring and alerts can help in this case). Properly handling "known unknowns" can prevent chaotic firefighting and ensure the smooth execution of big, challenging projects.

As we move forward, we should avoid complacency. Just as software is ever-evolving, our processes should evolve as well. Regular iteration, identifying inefficiencies, and ensuring that the team's modus operandi evolves with time can make the difference between a good team and a great, effective one. Recurring retrospective rituals, writing postmortems for projects, and using collaborative decision-making processes (like RFCs) can help guide teams to improve their technical quality over time.

Team Empowerment & Growth

Our code, in many ways, is a reflection of our craft, our passion. As technical leaders, standing up for best engineering practices ensures that this reflection shines bright. It’s about ensuring robustness in the product and longevity in the team's efforts. And while processes and code are crucial, the true essence of leadership lies in recognizing and nurturing potential of the individuals in the team. An empowered team is one that's on a continuous learning curve. Engineering leaders must be both catalysts and multipliers of such curve.

As catalysts, engineering leaders can always be seeking opportunities for the other engineers in the team to expand their horizons, be it through new projects, challenging tasks, or tailored training sessions. As multipliers, engineering leaders should always strive to find ways to transfer technical knowledge within the organization. By doing so, their accumulated expertise can be applied by others in similar circumstances.

Technical leadership plays a crucial mentorship role in any organization. It involves not only leading projects, but also boosting soft skills and providing career guidance. These responsibilities are not solely the jobs of management. Ensuring team growth and development is an integral part of the technical leadership position as well.

Technical leadership is not just a title; it's a journey. Like any journey, it may encounter many nuances especially when it comes to the company's culture and values. However, it is ultimately a combination of technical expertise, strategic vision, and genuine care for the team. As we progress in our careers, we should remember that our personal growth is not enough; we must also ensure that our teams grow with us. The growth, epiphanies, and hurdles we face all shape the narrative, along with the code we write.