Four Strategies for Successful Tech Leadership
Managing a team is a pretty big responsibility. The most obvious reason is that the leader bears the ultimate responsibility for whether the team’s projects succeed or fail, but underlying that reason is the fact that the leader can either be the glue that holds the team together or the wedge that drives it apart.
One of the primary reasons employees quit their jobs is because they don’t like working for their boss. As the architect and team lead, that boss is effectively me. As such, if I want to keep my developers happy, productive, and here, I need to ensure that I lead in a positive manner that inspires effort and creativity rather than stifles it. Frankly, I want my developers to enjoy working with me. As with all things though, this requires balance. The key is that they enjoy working with me, not that they enjoy hanging around and collecting a paycheck with me. We have a job to do, and we should enjoy doing it, but the job needs to get done.
Here are four strategies important to successful leadership on your tech team:
The first point to understand in how to keep your development team happy is to remember that your team is composed of individuals with individual needs, drives and desires. The extroverts on your team will appreciate you taking the time to ask about their weekend and their kids or pets before moving on into the topic du jour; the introverts and the ultra-goal-oriented might not unless you have a very close rapport with them. Some developers prefer to be handed a set of written requirements and to be set loose; others require a verbal discussion. Some require you to follow up frequently with them to stay on task; others bristle at anything that hints of micromanagement. While you don’t want your treatment of each person to be so different that people misinterpret it as favoritism, there are little tweaks you make to your interaction with each person to respond best to what that individual needs and what helps them be happy and productive.
Another big factor in keeping developers happy is making them feel that their ideas are appreciated and respected. Very few developers will be satisfied in an environment where they do nothing but blindly follow instructions day in and day out. Talk about the “big picture” with the team so they understand the goals of the project and what the business is trying to accomplish, before digging down into the minutiae of individual requirements. (This has the side benefit of helping them answer some of their own questions when figuring out how to implement the solution!) When there are multiple valid options for a technical solution, getting team input on which solution would work best for the project helps build a sense of ownership amongst the team. Besides, collaboration is a great opportunity for learning — for the leader as well as the team members. Always remember that great ideas can come from any member of the team, and don’t be afraid to admit that someone else’s idea was better than yours. Your team will respect you more for adopting one of their ideas (with proper credit) than insisting that you’re the boss and thus will make all the decisions. That said, there will be times when you have additional context than what your team has that favors your decision; so when you do need to “pull rank” do it with kindness and an explanation of other factors.
One of the strongest instincts we as humans have is to be defensive, but as a leader it is very important to resist the temptation to throw members of your team “under the bus” when “attacks” come from outside the team. Credit your team members with the team’s successes and take ownership of the failures on yourself. Never forget the power of a “thank you”; especially when someone has gone above and beyond the call of duty (i.e. worked over the weekend, dealt with a problematic vendor etc.).
Make sure the right people are placed in the right positions. Often times someone who is not successful in a particular role could be very successful if moved into a slightly different role. Attrition is very expensive so if repositioning can solve a problem it is always preferable to replacement. As an example, if you have a developer who is constantly chatting with others and distracting them from their work, consider moving them into a more social role; working directly with clients as an analyst or helping with tech support.
These are just a few of the strategies that have worked for me. I’d love to hear which strategies have worked for you; feel free to share them in the comments!
