💡 You are not your team’s umbrella (and more)
You are not your team’s umbrella
Two recent articles about engineering management stuck with me because they complement each other well to articulate a leadership philosophy I’ve held for a long time, but haven’t been able to put into words effectively.
First, in The Disappointment Frontier James Stanier expands on a controversial quote: “leadership is disappointing people at a rate they can absorb.” He talks about how keeping teams in a “bubble of protection” (where you act as the “umbrella” for bad news) never ends well. And even though managing disappointment is a core leadership skill, it is typically overlooked when training new managers. It’s worth reading the whole article, but here is a key point:
Managing a team of any size—from a handful of people to a whole company—is a continual balance between trying to empower people to achieve what they want (interesting projects, plentiful opportunities, a plethora of pay increases and promotions) whilst navigating a conflicting reality that doesn’t always want to give it to them. As such, there is a lot of truth to the quote at the beginning of the article. Leadership is about disappointing people at a rate they can absorb. In fact, I think that I’ve likely spent far more time on mitigation of disappointment or on managing expectations than I have on being motivational in my management career.
James goes on to give some really good advice on how to manage disappointment well. The second article is Will Larson’s Unexpected Anti-Patterns for Engineering Leaders , in which he also discusses the dangers of the “umbrella” approach:
The more senior the teams I’ve worked with, the more I’ve come to believe that protecting your team from reality just makes things worse for them in the long term. Larson now tries to throw his team into the gory details much more quickly. “In the past, I used to think I was energizing my team by sparing them the details. But now it feels like lying to them,” he says. On a tactical level, Larson adjusted this habit by buffering less information. “That means even if it’s disappointing for folks, I’d rather them process news bit by bit, rather than deal with a huge ocean of mess all in one moment.”
Obviously you are not going to tell your team every little thing that happens in your day and your meetings. But the idea that we should shield our teams from the realities of an organization is fundamentally flawed and ultimately does a huge disservice to people. If we hide the context of our decisions or guidance we lose the trust of our team—and once that happens, all is lost. This approach also stunts growth. If we don’t prepare people for how organizations work, their eventual exposure to reality will be a huge shock and we would’ve lost out on the opportunity to coach them slowly over time.
I once received some performance review feedback that I am “too transparent” with my teams, and I need to dial that down a bit. I respectfully declined. I don’t know of any other way to be—both as a human and as a manager. I also firmly believe I would be a worse people manager if I adopted that feedback.
That said, transparency is a skill. One I’ve cultivated for many years, and will likely never fully master. How and when you say things matter, and it takes time to learn those nuances. The above articles give some great advice on how to start that journey with your teams. So I encourage you to give transparency a try. I think you’ll find that you immediately become partners with your team members, as opposed to just their “boss.” And you will make magic together once that happens.
Generative AI Is Not Going To Build Your Engineering Team For You
Charity Majors makes some really interesting points about the consequences of “replacing” junior engineers with AI:
By not hiring and training up junior engineers, we are cannibalizing our own future. We need to stop doing that. People act like writing code is the hard part of software. It is not. It never has been, it never will be. Writing code is the easiest part of software engineering, and it’s getting easier by the day. The hard parts are what you do with that code—operating it, understanding it, extending it, and governing it over its entire lifecycle.
Also:
To state the supremely obvious: giving code review feedback to a junior engineer is not like editing generated code. Your effort is worth more when it is invested into someone else’s apprenticeship. It’s an opportunity to pass on the lessons you’ve learned in your own career. Even just the act of framing your feedback to explain and convey your message forces you to think through the problem in a more rigorous way, and has a way of helping you understand the material more deeply. And adding a junior engineer to your team will immediately change team dynamics. It creates an environment where asking questions is normalized and encouraged, where teaching as well as learning is a constant.
Lots more in the full article, it’s well worth a full read.
Invested in the WFH argument? Home in on the evidence
I really don’t know how much more data we need about this . It’s almost as if RTO is not about productivity at all…
Bloom and Han reported last week in the journal Nature that, over the subsequent two years, hybrid workers showed no difference in performance grades or promotion prospects compared to office-bound colleagues; the company’s computer engineers, for example, did not differ in their coding output across the two groups.
Hybrid workers, however, reported higher job satisfaction and were less likely to quit, especially if they were non-managers, female, or had long commutes. The authors conclude that “a hybrid schedule with two days a week working from home does not damage performance”, adding the result would probably extend to other organisations.
Can Every Sales-Driven Company be Transformed to Being Product-Led?
Some solid points in this article from Jason Knight . On product-led vs. sales-led (but could also refer to engineering-led) organizations:
To be honest, my strong opinion is that if you have to worry about who’s “leading” anything, then you’ve got bigger problems to worry about than who’s leading. If your entire company is aligned around what’s important and how to get there, then anyone could “lead” you there. This is supposed to be a collaboration, not a dictatorship. If one team “leads” and others don’t agree with where they’re being led, fix that! I generally find that misalignment is one of the most important problems to solve in any struggling company.
Hard agree with that one. I don’t believe in “healthy tension” between product and engineering. Just like I shy away from the traditional hierarchical view of “bosses tell employees what to do”. Whether it’s Product and Engineering or Manager and Teammate… it’s about partnership and helping each other (and the company) grow. We have to reframe this idea that adversarial relationships somehow create better teams and products.
Why the mysterious love affair between video games and giant elevators may begin with Akira
This is a fun bit of gaming history :
The thing about games, particularly Japanese games, is that they exist in a symbiotic relationship with manga and anime. When I spoke to Uemura-san, the engineer of the NES, he said ‘Once hardware developed to the point where you could actually draw characters, designers had to figure out what to make. Subconsciously they turned to things they’d absorbed from anime and manga. We were sort of blessed in the sense that foreigners hadn’t seen the things we were basing our ideas on.’
What the Challenger Disaster Proved
Emma Sarappo has a fascinating review of a new book about the Challenger space disaster (gift article). It is the first global disaster I was old enough to witness and experience in real time, and I’ve never been able to get those images out of my head. This review (and book) shines a horrifying light on the many human failures (mainly due to hubris) that resulted in this tragedy:
These issues—faulty O-rings, foam strikes—were understandable. Theoretically, with study and ingenuity, they were fixable. The problem was not really a lack of technical knowledge. Instead, human fallibility from top to bottom was at issue: a toxic combination of financial stress, managerial pressure, a growing tolerance for risk, and an unwillingness to cause disruption and slow down scheduled launches.
(Side note, tell me that last sentence doesn’t remind you of software development sometimes…)
Also, the astronauts knew what was happening:
The astronaut assisting them into place and finishing final preflight checks “looked down into her face and saw that her Girl Scout pluck had deserted her,” he writes. “In her eyes he saw neither excitement nor anticipation, but recognized only one emotion: terror.” She would fly for 73 seconds before the shuttle broke apart in a fireball and a cloud of smoke. After that gut-wrenching instant, and more seconds of stunned silence, a NASA public-affairs officer would speak the understatement that would become famous: “Obviously a major malfunction.”
Thanks for reading Elezea! If you find these resources useful, I’d be grateful if you could share the blog with someone you like.
Got feedback? Send me an email.
PS. You look nice today 👌