5 Things I Wish I Knew When I Became a Manager

Home » 5 Things I Wish I Knew When I Became a Manager

Advice for new tech leads.

 

1-ejQC3jCy4KmZTOiA70W2LQ

When I was first given the opportunity to become a tech lead my feelings were of excitement and adventure. I now had the opportunity to create the development process and team structure I had always dreamed of. Yet, shortly after, those feelings became mixed with deep questions about what type of person I needed to become to be a good leader, and what exactly I would need to learn to get there.

It surprised me to find out that there isn’t a lot of practical training and resources for first time managers. Even less for technical teams.

In an attempt to shed light on the subject, here are 5 things I learned as I moved from a developer to a team manager.

1. Leadership Is Not Sexy Work

When you were a sole developer, before you were in a leadership position, you might have imagined what it would be like to lead a team. You might have imagined architecting elaborate systems on the white board with the CTO. Or leading the team to battle a gnarly refactor, with the zeal of a general leading his army into war.

Truth be told, the day-to-day work of a good leader is not glamours. Your days will most likely be consumed by meetings, updating project statuses, planning releases, answering emails, etc. In fact, the best leaders are the ones who can consistently perform these activities, as opposed to managers who squeeze them in on the side.

Making this transition can be especially hard for developers. If you’re like most developers then you view writing code as the only real work. Days spent attending meetings and answering emails left you feeling like you didn’t get any work done. It’s important to come to terms with the idea that you will be writing less code as a leader. Yet this does not have to be an unfavorable discovery.

Programming is one of many skills necessary to run a successful business. Likewise, it takes much more than good code to run a successful team of developers. Stories need prioritizing, roadblocks need to be removed, communication needs to be active with groups outside of the team. Taking care of these tasks for your team can actually have a multiplier effect, making the team as a whole much more efficient (even without you coding!). It’s rewarding to watching the team members grow in their skill-sets, take ownership, and enjoy their jobs more. You will come to believe that the work a leader does for the team is now the real work.

2. Your Job Isn’t To Make All the Decisions

As a new manager it’s easy to believe that running a team means making all the decisions. Yet, there will be many times when it’s best to allow the team to come to a conclusion on their own. Your team’s own self-discovery is a much more genuine source of motivation than orders issued from a boss. In fact, sometimes it’s even best to let the team fail on a small-scale. Retrospectives after a failure can be some of the most productive and change inspiring exercises.

When you give the team members the freedom to make certain decisions it helps inspires ownership and pride in their work. But, you should balancethis freedom by being available to give advice and help remove blockers. Knowing when to step in and when to let the team run with an idea will come with experience and a deep knowledges of each member’s strengths and weaknesses. Google found this specific trait to be a key behavior with itsbest managers.

Here are some specific ideas that can help foster ownership and growth in your team members:

- Let the team choose which tickets they will work on next: Imagine the motivational effect of allowing the team to determine what they believe is most impactful for the company and most inspiring for them to work on. With the caveat that the team engages with the needs of the product and business groups, and that you have veto power if necessary. Yet, don’t be surprised to see the team go the extra mile and show new pride in craftsmanship.

- Turn technical decisions into work tickets: Instead of making the decision between AngularJS or Ember yourself, allow one of the team members to do the research and report back with recommendations.

- Turn questions into a guided team discussion: When a team member comes to you with a good question, often it can become a learning experience for the whole team. In those cases pose the question to the entire team and then just lean back and let a discussion develop. Your only contribution may only be making sure action items are assigned if, in the end, change is agreed upon.

At first glance you may wonder if the team is ready for certain freedoms. Introduce them as a trial. What works for one team does not always work well for other teams.

3. Your Job Isn’t To Make Everyone Like You

As a new manager it’s easy to make the mistake of measuring how well you are doing by how much you believe the team likes you. Wanting to make the team happy is not an intrinsically negative quality. Yet it becomes detrimental when it is a driving force in your relationships with the team. Disapproval from the team can feel uncomfortable and cause you to become an insecure manager that compromises to make each team members happy. Leading in this fashion leaves no room for a consistent development structure–the foundation for any effective team.

When a team member disagrees with your decision take a second to reflect before responding. Separate yourself from your position. Reframe your thinking and message toward what is best for the entire team, as opposed to focusing on making the disapproving team member happy. (Unless, of course, the team member’s point is more in line with the benefit of the team than yours.) Make sure you are a strong listener to the team. Be open to the idea that you will make mistakes in the beginning. Your employees will be your greatest teachers as you learn to lead.

Remember, your worth as a manager is not measured by how much the team likes you with every decision, but by how effective the team is able to perform in the long run.

4. Manage by relationship

Although having a long-term vision for the team is important for instilling process and culture, it’s equally important to develop strong individualrelationships with each member of the team. These relationships will become the source of motivation behind every interaction with your team members.

Why do relationships matter so much?

  1. Relationships are one of the best sources of genuine, long-term motivation to perform well and stick through challenging times.
  2. Humans are complex emotional beings, each with different skills, needs, and expectations. Therefore, each member deserves to be managed as anindividual.
  3. Relationships are the best way to discover and thoroughly understand the skills of your team.

How can you have better relationships with your employees? Spend time with them. There are no shortcuts. Chatting for a few minutes before asking a team member what the status of a project is does not count as fostering a relationship.

Luckily it only takes one tool to become good at relationships—regularly-scheduled, rarely-missed 1 on 1 meetings with each of your employees. If you are not doing them already, this should be the first action you take.

5. The Destiny of Your Team Is In Your Hands

This is an obvious point. yet it’s an important realization to let sink in. You now have the greatest influence on the team’s success and failure. The way you manage directly impacts each team member’s effectiveness and satisfaction in their job. Each team member deserves a core investment on your behalf to develop them to their potential. Likewise, the team deserves to be comprised of high performing members. It’s common knowledge that employees don’t leave companies, they leave managers. So commit to put in time and effort to learn and become the best manager possible.

About jjhageman

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>