Thinking like a manager

Posted by Ancestry Team on September 16, 2015 in Technical Management

One of the biggest shifts for me when I moved from a software engineer role into management was how to think like a manager. Things I never considered as an engineer were suddenly a top priority for me. For those experiencing a similar transition, I have identified two important considerations to help shape your mindset from a follower to a leader and identify how you, as a manager, can add value to your company.

1) Cultivate your team, not just your projects and technology

A big shift for me came in terms of people. I was less and less responsible for producing code itself; now I was responsible for helping people grow by developing strong team leads that think about their teams’ development processes, work well in a cross-functional team, make tradeoffs, help team members achieve career goals, and so on. This was more nebulous, in part because when teams are doing well, little or no management intervention is needed, and so it was easy to feel superfluous. Recognizing the need to shift my thinking was a good step in the right direction for me to better understand the way I should be adding to company value.

2) Your goal is to add value to the company, not just complete tasks

As a software engineer, it was sometimes a challenge to make a direct connection between something I was working on and company revenues, but when I was writing code, I could see functionality come to fruition because of something I had built. One of my current emphases is to take this a step further and think about the value my team adds to the company.

I am not just asking whether my teams are efficient and working well together, I am also asking whether the things they are working on are the right things for them and for the company, and whether the organization structures and resources being invested are the right ones for what the company is trying to achieve. The time scale for measuring value gets longer, which can be challenging some days.

In an agile team, members can also gauge value in terms of how the team is functioning: do we have multiple people familiar with any given bit of code? Is our sprint velocity increasing? What’s happening with our bug count? How much technical debt are we taking on? These types of measurements and more also help me have a sense of the value I am adding.

These considerations have helped me transition into my role as a manager. Some days, I have to remember that there are lots of ways to measure value, and we’re all still figuring out which ways are best. But sometimes I feel like I make a breakthrough: a conversation with another manager leads to a smart decision, I help a team resolve a particular problem they’ve been struggling with, or I promote something that has clear benefit. Those days are great. But on other days, I have to remember that there are lots of ways to measure value, and we’re all still figuring out which ways are the right ones for now.

For those who have made similar transitions, what are some new approaches and attitudes you have developed to become a better manager?

Comments

  1. Brad Stone
    September 18, 2015 at 5:49 pm

    Nice article, Christopher. Moving from technologist to manager/leader is definitely a shift – and not one that is good for many technologists. Anyone that has spent time in a technical field probably has seen a skilled technologist that was “promoted” and turned out to be a terrible manager who hated their job.

    Here are some tips that I have found to be helpful as a leader of talented technology teams.

    1. Serve others – not yourself. Search for ways to make your team successful by removing roadblocks, obtaining necessary resources and supporting innovative ideas. Leaders shine in the reflected light of their team’s success. Significant contributions should be shared – identifying the contributor(s) by name when appropriate. This should go without saying, but in case a new manager is reading this, leaders NEVER take credit for a team member’s contribution.

    2. Make work fun by getting to know everyone on your team. When you really know your team members, you can not only help them be more successful at work, but also make the workplace more enjoyable for everyone. What are their hobbies? What do they like doing with their family? What are some challenges that may impact a “normal” work schedule (e.g. handicapped child)?

    3. Establish communication lines between teams. As a leader, you will have visibility into other teams that your team members will not. Look for opportunities to build relationships between teams that will help both to be successful. Examples include connecting developers with the operations team, or connecting developers with the security team. I encourage my technologists to spend time listening to calls at the Service Desk. They always come away with a renewed appreciation of the Service Desk agents – and they bring back a whole list of changes that they personally can make to minimize support calls for their products.

    4. When the inevitable mistakes happen, turn them into learning experiences. OK, the system crashed and was down for 20 minutes during peak hours. That is really bad. Instead of finding someone to blame, help the team learn from the mistake by encouraging open communication and conducting formal root cause analysis. Once the root causes are identified (there are almost always more than one), then implement changes in technology or processes to ensure that mistake can’t happen again. As a leader, be prepared to take the heavy flack that could be demoralizing to a less seasoned team member. Remember that a team member that makes a really big, yet honest mistake will have valuable knowledge about how not to repeat something like that again. Don’t let them go!

    5. Help the worst team member succeed. You know the guy that is always picked last for teams. He has a reputation for not producing or for not being a team player. What is the reason? Perhaps he needs technical training. Perhaps he needs soft skills coaching. Perhaps he is in a job he hates and would rather be somewhere else. We had a project manager that was doing the work, but was not really shining and was frankly grumpy. We learned that he really wanted to be a network engineer, but had never had the opportunity to learn the basic skills to get in the door. We created a mentoring relationship and gave him 20 hours a week to sit with the engineers and learn. He is now a stellar employee and one of our experts in wireless networking – and he loves his job.

    Hopefully these tips will help others who are experiencing the shift from technologist to a manager/leader.

    – Brad

    Reply

Join the Discussion

We really do appreciate your feedback, and ask that you please be respectful to other commenters and authors. Any abusive comments may be moderated. For help with a specific problem, please contact customer service.