> 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?
I'm not sure how much I agree with that part.
One of the "child" companies of the company I'm working for has run in to some trouble. There's definitely a culture of "putting on a happy face", as described above, but it gets tough to believe when you know something is wrong. None of the C-levels would give details.
Recently the board president showed up at an IT meeting and said "They're in deep shit guys," and spelled the whole dire situation out for us.
That was inspiring. Everyone in the room was motivated to "fix" it.
Conversely, I've also been part of a company where leadership did nothing but talk about how much we're going to grow, all the way up until half the staff got laid off in one fell swoop. It wasn't motivating or inspiring at all. It was actually deeply concerning.
I don't think this is as easy to sum up by simply saying "when things are bad, or you feel frustrated, you don't let it show."
I think the author's point wasn't to suggest leaders should paper over problems, but that leaders shouldn't stoop to complaining or letting their frustration show in front of their reports. They can be frank and truthful with employees, while still remaining confident that the challenges can be overcome.
I much prefer leaders who let their anxiety known to me than those that project absolute confidence that whatever problems can be overcome. I can trust the former, I can’t trust the latter at all, and it’s super easy to tell.
> ...when things are bad, or you feel frustrated, you don't let it show. You need to be the person who is positive ...
I agree that this sounds more like denial than grit. Maybe it wasn't intended, but I've also seen it in real life. And besides being bad leadership, it's sometimes unethical (dishonest and harmful).
Its all about authenticity. On average, the more positive a picture a leader paints of the future, the better, as long as it’s believable and rooted in truth.
There’s huge latitude to give a more positive or negative vibe while still staying reasonably within the constraints of facts.
Some people are so charismatic they don’t even need to respect the constraints, but a lot of times that doesn’t end well.
Meanwhile, the advice is to sugar coat bad situations, which is certainly a flavor of dishonesty.
The tier of management matters here. The boss you are eye-to-eye with should put pragmatism before sunshine. The boss' boss and above are all probably better off being pathologically positive in front of their direct report's subordinates each.
Your immediate boss really should tune into the personality of their team members both individually and in aggregate in group settings. With luck, you were hand-picked by your boss and that means aspects of your personality are preferred, aka: culture fit. Sardonic cynical attitudes are reasonable, when trading humor and letting off steam, which boosts morale, but as with all performance, timing is everything, and good teammates understand this implicitly.
If shit is getting real, people owe it to each other to deliver solid news and not bullshit whitewash, but in group settings rumor mills are deadly, and information has to be controlled to prevent panics.
Good captains go down with the ship. They signal when to use the life boats. Would you rather have a boss who is sunshine all day, right up until the moment they fly the coop, and are never seen again? In practice this is almost invariably a really bad thing. Because even if your boss sucked, their boss will fill the intervening position with almost anyone (declining in-group promotions), and permit them next manager to reshape their team of direct reports as needed, which can disintegrate into a slow motion bloodbath of firings.
The reverse of a manager's disappearing act is the mass layoff, surprising a large class of subordinates (your boss disappears because, in fact, the company disappears as you lose your job). The inverse of a manager's disappearing act is he subordinate rage-quitting (a single subordinate employee disappearing, without other employees depending on their role is reasonable and conscionable, although stress is still induced by such an event).
I hope we were agreeing, we seem to share some viewpoints and I definitely do not think sugarcoating, which has its own connotations, is a best practice.
It all sounds like imprecise tight rope walking but I think there are basic tests. People can be skeptical talking to you, but when they leave is the word bullshit still active in their mind? For me that means the message was not delivered well.
It all has real consequences too. When any group of people face adversity, there’s no magic to make it all better. But final result can be objectively better or worse based solely on quality of communication, or even just basic respect for people.
> 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?
A way to loose trust. The best managers I had were open about problems. Overtime, I got sick of being told how great everything is when we were drawing in problems.
> 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.
(The author then goes on to suggest that this is normal, and expected, and correct, and that the leader wasn't actually out of touch.)
This bit bothered me, and she didn't really justify it all that much. Obviously "the most code" and "the major engineering challenges" won't necessarily translate directly to the features that the customers want most, or that drive the most revenue or sales growth.
But if several people have done some of the most technically challenging work that was necessary for the product's success, don't they deserve some recognition? And is it not the fault of their direct managers & middle management for not floating those accomplishments up the chain? Obviously not everyone can receive a shout-out, but at the end of the day none of this would be possible without the people at the bottom actually doing the work of building.
I feel like this kind of out-of-touch-ness is exactly what causes individual contributors to feel unappreciated even when they do things that -- at their level -- are truly difficult and extraordinary.
> ...is it not the fault of their direct managers & middle management for not floating those accomplishments up the chain?
If that's the only way upper management gets that info, I guess. But, especially in software, there are plenty of ways to get that info in addition to letting subjective takes float up the management chain.
At the dumbest level, you can look at code metrics (still not great), but just knowing the product (software) and evaluating it yourself is a great idea. What restaurant manager never eats the food or inspects the walk-in?
Am I reading this right? "So, when you have a leader who isn't meeting your expectations", it's because he or she is out of touch? They don't know what is going on with their team because they can't, but even if they did, they couldn't do anything productive about it anyway?
(The only things senior managers can do is "Start and stop projects," "Reorg," or "Hire, or fire, the leadership team." I've been through all three; the last isn't done often enough and the first two are some of the reasons I have a series of failed projects on my resume.)
TL;DR there's nothing wrong with the way we structure our workplaces that can't be fixed by suppressing your own feelings and identifying with management and ownership.
In a lot of ways, this Leader, LeaderLeader thing is lot like Factory and FactoryFactory patterns in java. That FactoryFactory conversation came out when enterprise java was at its peak and everyone else were preaching that was the standard way of doing things. Then nodejs, rails and functional programming entered mainstream and it made java look very very complex and naturally everyone embraced simplicity and java itself could learn to be simple. It is possible the same is true for technology management.
There are a lot of underlying assumptions here. Like for e.g. This many layers are necessary. There is a right way to be a technology Leader or LeaderLeader and Technology Leader has some awesome supernatural powers to make things happen.
I am not sure if there is a great recipe for managing successful products/teams, if there were one, a lot of people with a lot of money would have done it by themselves with out need for "startups" to innovate. After some point, companies like Google and Microsoft tend to grow mostly by acquiring someone else, usually startups and there is very less LeaderLeader pattern in startups.
I am not too sure how much impactful the LeaderLeader pattern is in tech world. But as a creator of things for other people to use, it might be a better approach to see things from your user's perspective. It appears appealing to that many layers of organization leader hierarchy is a drain on human creative energy.
> 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.
IMO the burden is on the people who's job it is to manage people to ask the people they manage what their perspective is on an issue. Managers who do a bad job because they don't care what their employees think have no business managing people.
Can I ask 5 people what their perspective is? Sure. 15? It's getting tough, but maybe. 50? Not really.
And so you delegate. Which means you get filtered information. Detecting which filters work well and which don't is tricky. It's not that managers "don't care", it's that they genuinely don't know and haven't figured out they don't know yet.
You can short-circuit that by telling them. Sure, getting the info is their job, but pushing it their way might get them the info faster. Just saying "but it's their job" is not helpful.
> "Can I ask 5 people what their perspective is? Sure. 15? It's getting tough, but maybe. 50? Not really."
Don't make one person in charge of 50 people then (at least, not their direct line manager).
Management where your only option is delegation is not very effective, in my experience. You have to be able to choose when to delegate and when to step in. The only way that works is when the teams are small enough that a single individual knows enough about what's going on to know when to change their leadership approach.
Furthermore, of all the managers I've worked under, the most effective ones all have one thing in common... they're protective of their team. This protection only seems to work when a manager understands what their team is going through. Consider a scenario where a management meeting is taking place and a manager from another department is complaining about how long your team is taking to complete a task. If your manager doesn't understand what your team is going through, what's the best answer your manager can give? That they'll "look into it". That may sound reasonable, but it puts your team on the back foot from the start.
Effective team protection brings a few key benefits... it builds loyalty, it reduces stress on team members, it focuses energy on key tasks rather than trying to do everything all at once. Managers who don't protect their teams may as well not turn up. If they're just another voice adding to the cacophony of demands, then they could be doing more harm than good.
> Don't make one person in charge of 50 people then (at least, not their direct line manager).
Which is, literally, delegation. Yes, front-line managers should have some understanding of what their people go through, and have direct lines with all of them. But the article didn't refer to frontline managers only. In fact, the opening example was about a VP. (I'd argue that it's mostly not about frontline managers - the title is badly chosen)
But even when you're a frontline manager, "step in" is not really a good option. Unless your team is tiny, inserting yourself into actual execution means you just created a huge schedule hazard for your team.
For better or worse, as a manager, you work through others. Your direct impact is very limited - your main job is allowing others to have maximum impact. (Protecting your team falls under that rubric - shield people from administrative noise, so they can do their actual job)
And in the end it really is "their job." It may not be helpful but it's reality. It's why your job is hard and it's something you need to accept and deal with in a way that doesn't demean, marginalize and slow down the people you serve.
If you are the employee wondering "why don't they act on this", that's still not a helpful take. Neither for you - nothing will change - nor for the manager, who might miss out on critical info.
Which is why good managers usually make sure that people are aware what the escalation paths are, and how to use them.
And why they keep hammering on the point that "not my job" is not helpful - because they (should) know that they operate on necessarily incomplete information, and that they make mistakes they're not aware of that are immediately obvious to people on the front lines.
The conundrum of management. It's your job, but you can't do it all by yourself.
Not quite. In the example given by GP, the idea was that understanding what 50 people were going through was not possible. However, it is possible for upper management to build an understanding of what people are going through if line managers are doing their job.
Imagine a company structure where you have 10 teams with direct line managers, where each of the line managers has 9 people in their team. Next, imagine that there are 3 senior managers who the 10 line managers report into. Lastly, there is one CEO that the 3 senior managers report into. In total, excluding the CEO, there are 103 employees. How does the CEO get to understand the operational challenges involving 103 employees? It's simple, the line managers summarise the challenges in their team, the senior managers prioritise which of the challenges to discuss with the CEO. Even if the CEO is hands off in the whole process, it's still possible to understand the difficulties being faced by 103 employees, as not all of those 103 employees will face difficulties that senior management need to get involved in, and when they do each of the managers involved in the communication between the team members and the CEO has an understanding of the details, so can answer questions that the CEO has. Therefore, a manager in charge of 50 or more people can understand the operational challenges faced by those people. From the article...
"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?"."
Would you agree that it's possible for a VP to have better information (assuming the people reporting into him are doing their job properly)? Would you agree that they're likely to be a more effective VP if they did?
> "Unless your team is tiny, inserting yourself into actual execution means you just created a huge schedule hazard for your team."
> Would you agree that it's possible for a VP to have better information (assuming the people reporting into him are doing their job properly)? Would you agree that they're likely to be a more effective VP if they did?
Is it possible? Sure.
Let me posit an alternate scenario: Is it possible that the key features aren't necessarily the ones with the major engineering challenges, and the key contributors aren't the ones churning out code? Is it possible they value things differently than engineers?
As for how you become a schedule hazard: As the number of people reporting to you increases, you are spending more and more time on management tasks instead of technical tasks. And, to add insult to injury, you'll have more unplanned demands on your time. Your available time becomes less, and it become unpredictable. Putting yourself on the critical path means creating risk.
<4 reports -> you're still able to significantly contribute engineering wise
<8 reports -> your output is diminished, but you can usually at least guarantee a fixed quantum of time (50%, 20%, however much you can set aside)
8-12 reports -> things become dicey in terms of scheduling. If you take on responsibilities on the critical path, be prepared that you might need to put in long hours if anything unexpected pops on your radar. You also impact your ability to work on strategy.
>12 reports -> You can scratch out the occasional fix for completely noncritical issues. And half of the time, you'll need to hand off the fix anyways.
>15 reports -> Congrats. You need to start thinking about building managers to take on some of the load of running the team. Building actual artifacts is something you dream of, but don't get to do.
Obviously, not hard numbers - YMMV. But based on what I've experienced, they work relatively well as rough guidelines. It changes based on the complexity of what you tackle, how mature the product is, and how much time you actually want to invest in managing people.
I think it's perfectly acceptable for managers who are managing many people to utilize the tools that are typically used for aggregating people's opinions in other contexts. They can ask them to fill out a survey, ask them to vote on an issue, or have representatives responsible for representing the opinion of subgroups that they manage.
The right answer for any leader at Director or above is to simply schedule 1:1s with random people from all levels of those you manage directly or indirectly, at least once--if not more--per week.
It's a rather efficient bullshit detector when you have two or more layers down in the organic chart.
I guess I didn't mean to criticize managers who are continuously soliciting feedback through a middleman, just ones who aren't soliciting feedback at all.
Senior leaders have plenty of options to make changes. McDonald's leadership (including Ray Kroc and the McDonald brothers) did lots that wasn't in those categories.
> """
Generally, this is done in three ways:
• Start and stop projects.
• Reorg.
• Hire, or fire, the leadership team
"""
I would hope some management tools would be unique to the industry of the product. These could be applied to literally any organization.
In software, you could, for example, pick an item from the Joel Test and provide carrots and sticks to encourage success in this. And there are plenty of other strategic technical goals you can encourage, like deterministic deployments or engagement with key open source projects.
It's a question of abstraction, at the start of the article she notes that she's run teams of up to 400 people. At that size there are layer-on-layer of people whose job it is manage divisions/groups/teams of people. The person at higher levels of some pyramid has to think very carefully about dropping down into the detail and consequently side-lining some levels of their management chain.
> 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?
I'm not sure how much I agree with that part.
One of the "child" companies of the company I'm working for has run in to some trouble. There's definitely a culture of "putting on a happy face", as described above, but it gets tough to believe when you know something is wrong. None of the C-levels would give details.
Recently the board president showed up at an IT meeting and said "They're in deep shit guys," and spelled the whole dire situation out for us.
That was inspiring. Everyone in the room was motivated to "fix" it.
Conversely, I've also been part of a company where leadership did nothing but talk about how much we're going to grow, all the way up until half the staff got laid off in one fell swoop. It wasn't motivating or inspiring at all. It was actually deeply concerning.
I don't think this is as easy to sum up by simply saying "when things are bad, or you feel frustrated, you don't let it show."