The Soft Side of Software

  Download PDF version of this article PDF

Views from the Top

Try to see things from a manager's perspective.

Kate Matsudaira


I can remember the very first software project I worked on. Back then, most programming was for shrink-wrapped software that would spend years in development (since you released only every few years and had long dev cycles because patching bugs was so costly).

For two years I worked on a project, and when it finally shipped, I can remember our VP talking about the launch. I had never had much exposure to him (I was new, a grad straight out of school), but I remember his speech about the launch clearly. He talked about some of the key features and mentioned a few of the people involved.

At the time, I had the impression he was out of touch; the people he recognized weren't the ones who had contributed the most code, and the features he called out were important but not the ones that had been the major engineering challenges. I can remember thinking, "How can he not know what is going on in his team?".

Of course, now, almost 20 years later, my perspective is quite different.

I have had the opportunity to manage very large teams, including some even bigger than the 400-person organization I was part of during that first project of my career. Now it makes perfect sense to me why he might not have known the biggest challenges or top contributors for a specific project.

The view at the top is different. And having been on both sides of the org chart, I have a new perspective.

The lessons below are ones I wish someone had shared with me in my moments of frustration with upper management earlier in my career.

 

Lesson 1: There are only a few levers to effect change

You know that a good leader empowers his or her people. It is the leader's job to guide them, but also to trust them. This means allowing them to make mistakes. Frequently there are no right answers, and sometimes managers can go down the wrong path.

When things aren't going right, these senior leaders have a limited number of options to make a change. Long term, it is not effective to step in and micromanage their direct reports, or even worse, the people on their direct reports' teams. This is not scalable, and it is expected that these experienced people shouldn't need that level of management and direction.

Instead, leaders look for ways to get high-performing, trusted managers in a position to help them reach their goals. Generally, this is done in three ways:

Start and stop projects. If a project isn't going well, a leader can cancel it and reinvest the resources elsewhere. If something isn't working, the leader can staff a new project to fix it.

Reorg. This is probably one of the most painful experiences for members of a team. It can be so upsetting to have your manager or your manager's manager move out of your chain of command, especially if you have worked to build strong relationships with them. In large organizations, however, changing the structure of a team is one of the best ways for leaders to improve alignment and strategically place their top people in positions to help them achieve better results.

Hire, or fire, the leadership team. If someone isn't performing, or the team isn't moving in the right direction, a highly effective course correction is to bring in fresh energy. Of course, this is harder to do because...

 

Lesson 2: The more people under a manager, the more challenging it is to judge their effectiveness

One of my favorite questions to ask is how long it takes to tell if a VP is mediocre or great. The answer can be quite challenging to determine because a lot of a leader's success (or failure) can be attributed to his or her team, not to the leader.

If you have strong managers under you, then it is easy to ride on their coattails. They make sure things are moving in the right direction and that good things are happening. Conversely, if you have poor performers, it can take a while to coach them or manage them out of your organization. The deeper the hierarchy, the more levels of indirection there are. Judging a VP isn't like judging a software engineer where you can at least observe his or her output and contributions directly.

Of course, the signs of a bad leader are not always immediately obvious—delivery on substantial projects often takes months or years, and attrition/retention tends to be a lagging indicator.

This is why bad leadership can be in place for years before changes are made. It can actually take that long to prove that it is that person, as opposed to other external factors outside of their control, causing failure to occur.

 

Lesson 3: Interviewing senior leaders is hard to do

Another observation that I have seen play out is that it is very hard to hire senior leadership (and because of Lesson 2, it can take a while to know if you did it right or made a mistake).

There are plenty of pitfalls in conducting job interviews, but the task becomes more challenging with executive leadership because there isn't a set of skills that is easy to test. How do you test influence? Sure, you can proxy it with a set of questions, but spending a few hours with a candidate doesn't always indicate accurately if he or she will be successful in the role.

That is why many companies focus on the candidate's experience and track record. Personal references and endorsements can also play a large part.

Perhaps the biggest reason that this is hard, though, is that leading a group of people effectively is dependent on so many factors: the team culture, the organizational goals, and, of course, the individual personalities. What worked really well for one person in one environment doesn't always translate to a new place. That is why adaptability and flexibility are important traits to look for during the hiring process, not just past successes.

 

Lesson 4: Split and delegate

When you move from being an individual contributor to a manager, you have to deal with the challenge of managing work. It becomes your responsibility to report on progress and handle status. In a small software team, this is easy: you just show up to stand-ups, collect status emails, or create a lightweight way to poll your team.

As your org gets bigger, however, it becomes too much for you as one person to keep everything in your head. You can't go to all of the team meetings. You can't be present for every decision. And you have to learn to trust your leadership and delegate responsibility.

This is a good thing overall—by sharing the responsibility, you give others the chance to lead and you allow your team to grow. It can be a tough transition, however, if you are used to being in control. It is also a place where things can go really wrong.

If you don't have a good way of verifying details, or diving deep into areas, too much abstraction can result in unforeseen problems (which are the worst kind). To avoid this, you have to figure out checks and balances—how can you get enough oversight to have high confidence in the work being delegated, without micromanaging every detail yourself?

The most effective strategy I have seen in these circumstances is to set up regular reviews with team leadership to surface issues and help you stay involved with the day-to-day processes of the team.

 

Lesson 5: Be the beacon of hope

While it is true that misery loves company, no one loves working for a leader who doesn't portray confidence in the team's trajectory and success. People want to be inspired, and as their leader, it is your job to give them the motivation and vision to perform.

This means that even when things are bad, or you feel frustrated, you don't let it show. You need to be the person who is positive and who helps motivate people to do their best. If you don't, then who will?

 

Conclusion

Leadership is hard. None of us comes to work to do a bad job, and there are always ways we can be better. So, when you have a leader who isn't meeting your expectations, maybe try reframing the situation and looking at things a little differently from the top down.

 

Related articles

A Conversation with Joel Spolsky
What it takes to build a good software company
http://queue.acm.org/detail.cfm?id=1281887

People and Process
Minimizing the pain of business process change
James Champy, Perot Systems
http://queue.acm.org/detail.cfm?id=1122687

Nine Things I Didn't Know I Would Learn Being an Engineer Manager
Many of the skills aren't technical at all.
Kate Matsudaira
http://queue.acm.org/detail.cfm?id=2935693

Kate Matsudaira is an experienced technology leader. She worked in big companies such as Microsoft and Amazon and three successful startups (Decide acquired by eBay, Moz, and Delve Networks acquired by Limelight) before starting her own company, Popforms (https://popforms.com/), which was acquired by Safari Books. Having spent her early career as a software engineer, she is deeply technical and has done leading work on distributed systems, cloud computing, and mobile. She has experience managing entire product teams and research scientists, and has built her own profitable business. She is a published author, keynote speaker, and has been honored with awards such as Seattle's Top 40 under 40. She sits on the board of acmqueue and maintains a personal blog at katemats.com.

Copyright © 2017 held by owner/author. Publication rights licensed to ACM.

acmqueue

Originally published in Queue vol. 15, no. 5
Comment on this article in the ACM Digital Library





More related articles:

Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler - DevEx: What Actually Drives Productivity
Developer experience focuses on the lived experience of developers and the points of friction they encounter in their everyday work. In addition to improving productivity, DevEx drives business performance through increased efficiency, product quality, and employee retention. This paper provides a practical framework for understanding DevEx, and presents a measurement framework that combines feedback from developers with data about the engineering systems they interact with. These two frameworks provide leaders with clear, actionable insights into what to measure and where to focus in order to improve developer productivity.


Jenna Butler, Catherine Yeh - Walk a Mile in Their Shoes
Covid has changed how people work in many ways, but many of the outcomes have been paradoxical in nature. What works for one person may not work for the next (or even the same person the next day), and we have yet to figure out how to predict exactly what will work for everyone. As you saw in the composite personas described here, some people struggle with isolation and loneliness, have a hard time connecting socially with their teams, or find the time pressures of hybrid work with remote teams to be overwhelming. Others relish this newfound way of working, enjoying more time with family, greater flexibility to exercise during the day, a better work/life balance, and a stronger desire to contribute to the world.


Bridget Kromhout - Containers Will Not Fix Your Broken Culture (and Other Hard Truths)
We focus so often on technical anti-patterns, neglecting similar problems inside our social structures. Spoiler alert: the solutions to many difficulties that seem technical can be found by examining our interactions with others. Let’s talk about five things you’ll want to know when working with those pesky creatures known as humans.





© ACM, Inc. All Rights Reserved.