Software development is a route that is loaded with unknowns. We’re building new stuff, so mistakes are inevitable. Having a senior developer in a leadership role on board will help us avoid some issues, as well as deal with other challenges. Ultimately, he or she will be the driving force behind a project.
We’ve become accustomed to seeing double-cab trucks near construction sites. This is because they’re great for transporting tools and materials needed for minor work, removing excess materials from construction sites and, more often than not, transporting a group of three to six guys. There will usually be a few youngsters in such a group with exceptional physical strength and endurance. A few will have had enough experience to deal with a variety of difficult situations on a regular basis. But most importantly, the group will have a leader with the necessary experience and abilities to guide the group through unexpected problems. Things just don’t work well without this person.
Software development is analogous in certain ways. We also have teams of 5 to 9 developers, each backed by a leader with just the perfect mix of expertise, communication skills and technical brilliance to get things moving.
Ability to see things in perspective
The team leader has a birds-eye view of both the problem being solved and the software being developed. He engages to clarify the project’s specifications. He is the one who knows and understands the story and its acceptance criteria. If he doesn’t, he’ll figure out how to get the answers and share them with the rest of the team. He’ll know how to explain ideas and technical options, allowing decision makers and teams to defer difficult decisions until some of the uncertanties have been settled.
Master in right-engineering
In a few projects, a team lead has probably seen both under-engineered and over-engineered code fail. In contrast to lower-level developers, a competent team leader will be excited about simplicity.
A team lead’s primary concern focuses on the long-term implications of architectural decisions, such as development speed, maintainability, performance and scalability. They are passionate about creating the right-engineered system, the one that’s complicated just enough to get the job done.
Not long ago, I witnessed a client discussing microservices architecture in order to improve the performance of a long-running operation. They were bumping into a few bottlenecks throughout a monolithic system that could do a lot of things but was slow to generate monthly statements. It seemed strange that the major motivation for moving from monolithic to a microservices-based design was to increase performance, so a colleague gave a few more options, such as event-driven and space-based architecture.
After a half-hour discussion, it was decided that a microservices architecture would not be a good choice and that space-based architecture would be a better option. But that isn’t the point; the point is that the colleague was aware of the options and had a simple model – a handy comparison table – on hand. He had attended a conference on another continent a few years back to get it. The conference had been just one piece of a puzzle that he had been putting together on his path towards becoming a team lead.
The software project team in this tale found the perfect thing at precisely the right time, all thanks to the presence of a suitable person. When you have a good team leader, these kinds of things happen all the time.
Years don’t always bring the right experience
What is the best way for us to track down such a person?
To put it another way, what will I need to become such a person or to foster the emergence of one in my company?
We can all agree that team leaders should have a lot of hands-on experience with software development. The issue is that “a lot” is a somewhat ambiguous term; for some, it means 5 years of practice, while for others it means at least 10 years.
Is the number of years you’ve worked a good indicator of your skill level?
Getting back to the example on the construction site, if you’ve been laying bricks for two decades, you’ve probably developed some muscle memory, but that alone does not qualify you to supervise a construction site.
In the software business, if developers in a static company continue to work on the same old technology for, say, 20 years, they will become older juniors, not seniors.
Coding tricky rather than everyday stuff
Being the most experienced person in a team does not give a team lead the right to act like a boss, check every detail that individuals code or micromanage in some other way. The role requires taking a step back, articulating needs at a higher level, and accepting that what other people contribute may not be what you would have done yourself.
Team leads must be sharp thinkers who can jump in and solve problems promptly while also empowering their teams to do the same. If the team leader does any coding, it should be the challenging work that the rest of the team avoids. He is not going to say, “not my job.”
When deciding what will and will not work, an experienced team lead will have developed a gut feeling or intuition. They’ll know what to do, or know someone who would know, or they’ll know what to look up on the Internet. They’ll regularly save time and effort for their team by introducing to their colleagues, or helping them to select, a library that has been used on another project.
Focus on people and processes
Software development is a collaborative effort and getting a group to work together necessarily involves a thorough understanding of people. Because things can go wrong on a project or within a team, and it’s crucial to avoid getting caught up in the blame game by attempting to pinpoint those who are to blame for the errors. Instead of punishing their colleagues for making mistakes, good leaders encourage them to try again.
A good team lead will use his technical knowledge, experience, and communication skills to promote code reviews, and pair programming and other practices that enhance knowledge sharing and collective code ownership. If a business’s core logic has been changed, for example, he’ll enjoy leading everyone through the code.
A good team lead will also encourage his team to use daily builds, unit tests and containers while constantly looking for ways to improve the process. He’ll step into an overseer role without hesitation, even though it may mean doing more management and mentoring than coding.
Senior in a leadership position
In many circumstances, the best team leader isn’t necessarily the most capable individual contributor. His core value is that he has a comprehensive and systematic understanding of people as well as the full technology stack.
Team leaders can adjust perspectives and are less likely to be caught off guard by new trends, rivals or changing requirements.
If you don’t have such a leader on your team from the beginning of a project, you will suffer.
You’ll be missing out on the person in the back who can explain expectations, roles and responsibilities, as well as steer junior, intermediate and senior developers to project outcomes, effectively communicating client needs to the development team while maintaining the integrity of the original plan.
