Submitted by matt_eaton
on Tue, 05/23/2017 - 02:56 AM
Throughout my career as a technical lead I have been put in charge of many different projects. Everything from mobile, to web, to server side development, and certainly a combination of all the above at the same time. Over the years, as I have grown as a technical leader and engineer, so have the size of the projects that I lead. And if there is one thing that I have learned along the way, it's that technical leadership and team management most certainly make an impact on the success of any project, large or small. And that is why I wanted to write this article, to share some of the tools, management knowledge, and experience I have gained over the years on leading teams of distributed and local engineers to develop successful projects, large and small.
Note, that in writing this article that I really want to try and incorporate experience from both sides of the equation. The first being from the technical leads perspective, and the second being from the engineering developer’s perspective. I think both vantage points offer a very similar but in some cases unique perspective on the situation and as a technical lead, it is advantageous to put yourself in both roles.
Starting Off
Starting off my career as a technical lead I evolved into the role more than anything – as I think most engineers do. You are instructed to develop a specific project that is relatively small, and as time goes on, the project gets larger and larger, and soon you recognize that you need help and more engineers are assigned to the project. Suddenly, whether you recognize it or not, you are in a leadership situation. Now, developing that same project requires a different vantage point than just developing the project to make it functional. It now requires group collaboration and group decisions to become successful, and you as an engineer have transformed your role into a technical leader.
What I have found to be successful throughout my career, when put in leadership situations, is asserting my thoughts and decisions about why certain architectural decisions were made early on in a project and then opening the floor up to your co-workers for suggestions and opinions. This has always been effective in evolving project architecture because no one project, no matter how large or small, should have one person completely dictating the architecture. No one engineer can think of all situations and every edge case. And if your co-workers feel that their opinion is not being heard then this can also lead to project burn-out and a collaboration space with a lot of friction. Always take advice from everyone you are working with, no matter how large or small of a role they play on a team.
During this stage of my career is where I learned to have very thick skin.
During this stage of my career, while I learned to take advice from my co-workers, is also where I learned to have very thick skin. This is incredibly important when evolving into a technical leader because you will take heat and criticism from everyone. I am talking about bosses, co-workers, and most of all, the client or customer that you are working with. This will not always be an easy thing to do, but the most important aspect about getting criticism is that you listen to it and pick out the valuable pieces of criticism. This always is hard, especially if the criticism is projected in an unprofessional way – which can happen at times. The important thing to remember is that everyone has reasons for expressing an opinion and it is up to you as a leader to filter out all the valuable points to use them to enhance your team and the project. Do not ever let your ego get in the way of a great decision or an amazing benefit to the project or your team.
While developing thick skin and taking advice from your co-workers it is also important take coding tips from your fellow engineers. This may seem like the previous advice that I have already discussed, but taking coding advice is just a bit different than taking project leadership advice, in my opinion. For example, I have been in many situations before where I spent a lot of time writing code that I thought was flawless and one of my team members pointed out a weakness in it during a code review. What I have learned is that the most important thing you can do is to engage with that team member to open a larger discussion about the possible weakness among your entire team. That way your architecture point is asserted and so is engineer’s that pointed out the weakness. This can lead to a lot of benefits among your team and the project. First, the possible issue gets more attention. Second, that engineer that is pointing out the issue get their voice heard and gains credibility with the entire team. Third, you as an engineer stand to learn something from the advice of your team. Taking technical advice is a great way to grow yourself as a lead and an engineer.
Managing Large Teams on Large Projects
Managing large teams on large projects is where you as an engineer, or a technical lead, will experience a tremendous amount of growth. If I had to look back and think about what made these large projects successful, I think it would have to be a combination of these four techniques; meeting with your team often, using a strict development methodology, always performing code reviews, and always running new code and features through QA. I have found that these four techniques have always helped to keep larger projects in-order and highly visible to other managing team members who are speaking directly to stakeholders.
Making time to meet with your team can seem like a no-brainer as a technical leader, but I would argue that it is probably the most overlooked aspect of managing technical teams. Things tend to get busy and get away from you, team members could be out of office, team member could be in different time zones, and so you decide not to meet and key aspects start getting lost in the shuffle. I think it is extremely important to keep team meetings at the top of your mind; that way things like team progress, merging strategies, and bug resolution can be discussed in an open forum with as many members as possible, no matter what your team’s availability.
For many cases meeting with team members at least one time a day is realistic, no matter what time zone or where they are at in the world. However, I would stress that at least meeting twice a day is also important if you have a remote team. Going over what each team member’s day looks like in the beginning and end of each day helps grow transparency and accountability for your team. I would even say that on larger projects this technique has proven useful even with teams that I have worked with in the same room at the same location. This at least lets you and other team members know where everyone is at and how they can help if needed. This also let’s team members coordinate merging and branching workflows if multiple branches of the same code are in flux at the same time.
Meeting with your team members twice a day also builds comradery - if you do it right. Some team members will get annoyed with your insistent need to “meetup quick for a check-in,” but the best way to break the ice and loosen up the annoyance factor of this is by revealing something funny. This fun fact could be about an event that happened during the day or possibly revealing a funny fact about yourself. These ice-breakers can also become great transitional pivot point to launch into your actual meeting. One other technique that I have used is to share my “bug of the day” to kick off the check-in. This can be a great ice-breaker because most-likely everyone that you are having a discussion with is a problem solver just like you are and can jumpstart a stagnant conversation into a technical conversation.
Using a strict development methodology has also proven to be a very strong ally in organizing and concurring large projects with large teams.
Using a strict development methodology has also proven to be a very strong ally in organizing and concurring large projects with large teams. My personal preference is to use Agile, but if Waterfall works well for your team and project, then you must stick with what works. I personally prefer Agile over Waterfall for large projects because multiple members of each team are always involved in each story of a project providing feedback and collaborating between themselves. Whereas with Waterfall stories are just blocked and work cannot continue until a team member is brought in and work can pick up again.
Using a software development methodology is key for more than just the approach and the speed in which you complete the project. Using a software development methodology allows an entire organization or division to focus on specific tasks, report progress, and drive towards a common goal. Without a software development methodology tasks and team members become lost, goals become distorted, and often this can lead to scope creep and budgets that way into the red.
As a technical leader and a mentor towards your team it is critical to always have your team perform code reviews. Performing code reviews on any project, large or small, can provide many benefits for not only the project, but the team can see benefits from this as well. First and foremost, performing code reviews just naturally enhances the stability of the product. Large projects can often contain many deep and intricate sections of code that over times has been maintained by sub-teams or a few select engineers. When updating or adding bug fixes to code like this it is important to get all members of the team get to review the pull request as you or your co-workers may not be familiar with a certain section of code.
Performing code reviews helps build knowledge, confidence, and trust among team members.
Performing code reviews helps build knowledge, confidence, and trust among team members. I know that when I started requiring code reviews for my teams that a lot of collaboration and teamwork started evolving. In my experience, I have seen code reviews make junior engineers stronger technically and gives them a lot more confidence when explaining an idea or specific vantage point. I have also seen code reviews give senior engineers the opportunity to take on more of a leadership role among other team members and start naturally leading and mentoring other engineers. This natural exchange of ideas and mentoring that can be a result of code reviews is healthy for your team and can have organic benefits as your team takes on larger and larger projects.
Performing code reviews is critical for teams of small and of medium size. Certain cases in which the team is very large and distributed may not be realistic and can call for alternative approaches. I have seen cases where the code base is so large and the team is so distributed that there is a dedicated research team and many dedicated development teams. That way the development teams can stay on specific development features and the research teams can be preparing code, performing research for the development teams, and performing code reviews from the development teams. From a code review perspective, this also puts a lot of the weight of performing code reviews on the research team, but it does then free up the development teams to focus on features and any new development. This style of development takes a lot of coordination and dedication from technical leads to all work together to make sure that code reviews, feature development, and feature research all is happening at the same time with relatively low impact on the traction of the project.
Performing QA on a project is something that is very important to me as a technical leader. I have worked on projects with and without QA and I certainly value the benefit that this provides to the project. For example, I have worked on many projects large and small where it was expected that the engineers perform their own QA and the product is delivered at specification and held to a checklist of quality assurance items. These projects certainly go fast, but certainly go through many iterations as the product is released and many issues are uncovered in the process. The value that QA brings to a product, through my experience, is the that the product that has been thoroughly vetted and can signed off on from a list of items that the product has been validated against. This lead to a more successful result to the client, a more successful rollout at each iteration, and future room for feature development instead of bug fixes.
Tools of the Trade
Everyone has their preferred set of tools and management programs that they use throughout their software development process - and I am no different. Over the years I have narrowed down the best project management tools to use in different styles of management. For example, if your team is developing software that is open sourced and your team works along-side public contributors, I prefer to use a PivotalTracker, Github, circleCi workflow to manage sprints and stories. However, if you team is working privately amongst an organization, then I much rather use a JIRA, Confluence, BitBucket, and Jenkins workflow to manage sprints. Both are very much the same type of workflow for handling Agile projects, I just prefer PivotalTracker and GitHub for completely open collaboration because I feel like these tools are a lot more familiar to the masses than JIRA and BitBucket. There is certainly nothing wrong with JIRA or BitBucket, but these tools are geared more towards enterprise development.
In summary, after reading this I hope you know a little bit more about what I have found to be successful as a technical leader and project manager for projects of all sizes. Please feel free to reach out and leave a comment if you have a thought that you would like to share or would like to get in-touch with me. Thank you very much for reading!
Member for
3 years 9 monthsLong time mobile team lead with a love for network engineering, security, IoT, oss, writing, wireless, and mobile. Avid runner and determined health nut living in the greater Chicagoland area.