Credit: Rikobest
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 were not 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 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 here are ones I wish someone had shared with me in my moments of frustration with upper management earlier in my career.
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 are not 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 should not 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:
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 coat-tails. 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 it is that person, as opposed to other external factors outside of their control, causing failure to occur.
Another observation I have seen play out is that it is very difficult 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 does not 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 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.
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 email messages, 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 cannot go to all of the team meetings. You cannot 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 difficult transition, however, if you are used to being in control. It is also a place where things can go really wrong.
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 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 do not 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 micro-managing 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.
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 do not 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?
Leadership is difficult. 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
on queue.acm.org
A Conversation with Joel Spolsky
http://queue.acm.org/detail.cfm?id=1281887
People and Process
James Champy
http://queue.acm.org/detail.cfm?id=1122687
Nine Things I Didn't Know I Would Learn Being an Engineer Manager
Kate Matsudaira
http://queue.acm.org/detail.cfm?id=2935693
Copyright held by author. Publication rights licensed to ACM.
Request permission to publish from [email protected]
The Digital Library is published by the Association for Computing Machinery. Copyright © 2018 ACM, Inc.
No entries found
