The Magic of Engineering Leadership
Software engineering isn't magic, and neither is engineering leadership. Too often organizations leave engineering teams to fend for themselves when it comes to basic tools, techniques, and practices. A good leader makes decisions, leads from the front edge of those decisions, and then listens to their team to iterate and improve over time. But how can a new leader approach an existing organization to make a positive impact?
This article will explore some strategies for effective engineering leadership focusing on three key areas: building and growing effective teams, evolving development practices, and planning for future growth. I'll also talk about what qualities such a leader should possess. Spoiler: it has nothing to do with job titles.
I'm new here.
Before we jump into the strategies themselves, let's talk about how a leader determines what to change. The first step is an initial assessment of current practices, people, processes (distinct from "practices"), and plans. No, I don't call these the four P's, that's silly. Identifying how things function in an organization is critical, and should not be rushed. To quote The Princess Bride:
"...you rush a miracle man, you get rotten miracles."
And in some cases, a miracle is exactly what we're talking about. Turning around a floundering engineering organization is often miracle-level work. Luckily, most of the time that's not the level we're really talking about. Even so, rushing the initial assessment can lead to uninformed decision-making or arbitrary change. Both of those will exacerbate existing problems and introduce new ones.
So how do you know what things are really like in the organization? It's an obvious answer that sadly many leaders (new and old) ignore: talk to the people.
But let's dig into that, what do I mean by "the people"? I mean everyone. Set up short sessions with anyone and everyone - that means the engineers, designers, product (or project) managers, recruiters, sales people (for product organizations), other leaders - heck, I'd even interview the administrative staff. Why so many? Because you want the most detailed picture possible, and everyone in the organization has some interaction with the extended software development lifecycle - that is, the cycle that includes more than just requirement -> code -> test -> deploy -> feedback -> repeat.
You might wonder how the front desk administrative staff could possibly be helpful in this assessment. Guess who sees everyone that comes in and out of the office? That's right, they do. They see people's faces. They know when the office is stressed. And they know when the staff is burnt out. Just imagine what else you could learn by talking to other people around the office.
When performing this survey you need to stay focused. You will learn much more information than is relevant to your upcoming endeavors. So what are you really looking for? Focus on:
- information relating to recruiting, vetting, hiring, and onboarding
- technical capabilities and alignment with known technical challenges
- the flow of product and project information through the people and teams
- current tools and software development lifecycle steps
- known and potential technical debt and inefficiencies
Conversations must be open and honest. This applies to every interaction, not just during your initial assessment. As a leader, you must develop a good rapport with people on your team, and across other teams. Starting from a position of honesty and forthrightness will promote the free-flow of information throughout the organization.
Building and Growing Empowered Teams
Having the most amazing development lifecycle and tools is pointless if you don't have smart, adaptable engineers. Technology changes too fast to assume that your lifecycle or tools won't change. Instead, plan on it. And hire people that you trust to change with the times and who feel empowered to help drive that change.
Depending on what the initial assessment finds, a good first place to start for a new engineering leader may be the recruiting and hiring practices. Is your sourcing limited to online platforms? Do you get out into the community and meet actual engineers? What is your message to those candidates? Are you looking for "rockstars" or "ninjas" or "10X developers"? If you are, then you're doing it wrong. Hire good people with good ideas and good practices. Let them grow, and empower them to become the rockstar you need. If you hire a "rockstar" to start, they'll behave like one - and no one wants to be around that.
Companies must encourage their engineers to be a part of their community, and leaders must support these activities in any way they can. Your goal should be a diverse workforce of talents and backgrounds. That requires looking for people outside of the traditional four-year universities. It also means actively engaging with developer communities for traditionally disenfranchised groups.
So if you aren't hiring rockstars, how do you build an amazing team? To start, you hire good people, and people that are willing to learn and adapt. Use them. Listen to them. Trust them. Build a mentorship program to grow junior engineers into mid-level rockstars, and then grow those rockstars into the engineering leadership of tomorrow.
Beyond building the team, a leader must be able to demonstrate the qualities you desire - and do so as a member of the team, not from the outside. You as a leader must show good development practices (yes, that means getting your hands back on the keyboard). You should be communicating your complex vision simply and adapting to change as it happens. You need to be designing the development process with your team, not for them, and showing empathy in every interaction.
Side Note on Onboarding
The ability to get a new team member integrated and productive quickly can directly impact both employee and management satisfaction. Proper onboarding will help reduce short term turnover and ensure that new work can be spun up quickly. In addition, it will help to establish more consistent engineering practices across the team. Onboarding here means more than just getting someone a computer. It's the process for integrating into team culture, accessing tools used internally, integration into the development lifecycle workflow, and gaining familiarity with the codebase. Consider a buddy system and pair programming to get new engineers productive fast.
Evolving Development Practices
Having a strong team means having a lot of strong opinions. This is good, and should be celebrated, not avoided. Encourage engineers of all levels to contribute to the development of the process itself. Junior engineers can have valuable insight into what works and doesn't from the ground level. Don't dismiss opinions simply because of the level or seniority of the person.
Take an iterative approach when changing the development process and practices. Just as our project development has become agile, so should our own change management. Base decisions on evidence, observed success or failure, and don't be afraid to incorporate new innovations quickly. Will they always work? Of course not, but if you implement an agile, iterative approach to your development practices, then course correcting can be swift and painless.
One of the most difficult processes for an engineering team can be the technical review of new code being merged in. Many leaders (engineering or otherwise) will push for features and fixes to be done as fast as possible. This is a mistake. Rushing software development will build technical debt and ultimately result in more time necessary for future development efforts.
So how do you avoid this trap? You have a set of best practices which routinely get reviewed and iterated on, and then you establish mechanisms for reviewing code to ensure it follows these best practices. Do not sacrifice this process for speed. And be willing to throw away code and start over when it doesn't meet the standard or doesn't solve the problem. This may sound harsh, but if you reduce the time from user story assignment to code review, and simplify complex tasks as much as possible, it will result in better code without overburdening reviewers or adding excessive time.
Planning for the Future
Technical debt can crush an engineering organization. And I want to be very clear: every organization has debt. If you think yours doesn't, then I suggest a hard look in the mirror. The main difference between a high-performing engineering team and one stuck in the mire is keeping this debt in check. A good engineering leader will have a plan for managing this debt. Having a sound technical review process is one way, but the organization must also be willing to dedicate time and resources to paying down this debt.
So how do you manage it? The first step is just like we talked about before. You must identify and assess areas of debt, whether that is code, process, or skill set. Review recruiting and hiring practices to build the skill set. Iterate on the development processes to ensure new debt is minimal. And implement good technical review practices to manage code being merged in.
But what about the existing debt? Dedicate time to reducing it. Hold a hackathon to rebuild pieces of infrastructure. Pause new feature development for a week and let engineers pick what they feel are the most critical areas to focus on. And make tackling debt a routine business practice. When a code file is touched, require that certain things are checked to incrementally reduce potential issues.
Finally, a good engineering leader will look at emerging trends in software development and allow their team to do the same. This doesn't mean asking people to learn and research on their weekends. It means giving them time to explore and improve as a member of your team.
Take what you learn and share that with the community. Demonstrate leadership beyond your organization and watch as the smart engineers discover your team on their own and seek out positions with you. This is how you build a sustainably growing engineering team.
Organizational Leaders: Seek out your next engineering leader and ask them how they will address these areas. Are they willing to fully participate in the development process, or do they just want to manage people? Will they be able to shape your organization for the future, or just maintain status quo?
Engineering Leaders: Share your thoughts with the world. We all become better leaders when we share our thoughts and accept feedback to continuously iterate on our process.
Software Engineers: Demand better from your leadership. Never settle for inefficient processes, tools, or systems. Look for opportunities to grow and become the next generation of engineering leaders. What would you do differently?