Menu

Explorations On Leadership

Big +1 from me on James Whatley’s thoughts on leadership in the latest edition of his Five things on a Friday newsletter:

Demonstrating that you as a leader are imperfect, that you get things wrong; that you are fallible—and doing so in a way that shows that it’s safe to open up and be vulnerable—enables and creates the feeling of psychological safety. You’re saying “I, the person who is meant to be leading this team, can be vulnerable therefore this place, this team, that we all work in, is a place where you can feel safe to be vulnerable too.”

On empowered teams vs. feature factories at sales-led organizations

I think this is a really insightful comment (LinkedIn) by Ben Erez about the realities of being a PM in a sales-led organization. It’s worth reading his whole argument because it’s definitely a spicy take. But the crux of it is that sales-led organizations cannot function with empowered product teams (I think everyone who reads this blog knows what I mean by that, but just in case, here’s a refresher).

Here’s a key part of Ben’s argument, and the really spicy part:

I think sales-led companies should embrace the feature factory culture fully; stop evaluating PMs by their strategic contribution (a weight off the PMs shoulders given they never get time for strategic work anyway) and start rewarding PMs based on how many features they ship that the sales leaders care about. This will align the PMs in your org to think and work the way the sales team (and CEO) wants them to work. It’ll kill many unhealthy tensions in the org and get people rowing in the same direction.

Would I want to work in that environment? Probably not.

But most b2b SaaS companies are already sales-led. And there are thousands of PMs in those environments who feel the tension I’ve described. So I think most b2b SaaS PMs would celebrate their company embracing their feature factory and just calling it what it is.

Could this be seen as defeatist? Maybe. But I also think that the “just calling it what it is” part of the argument is really key here. It doesn’t serve anyone—not the product, not the company, and certainly not its customers—to pretend you have an empowered product culture when you do not. So remove the pretense, and just be honest about who you are.

If you want to become an empowered organization, that’s great! But that’s a transformation that has to come from the executive level, and it’s not a short or easy process. So go on that journey, yes! But until then, be honest about what the organization is, make expectations clear to PMs, and reward them accordingly.

The anatomy of a people-first job ad

I love all the advice Charlotte Carnehl gives in The anatomy of a people-first job ad. If you’re about to go into a hiring phase, definitely bookmark this one for when it’s time to write the job description. One example:

When looking for a new job, it’s not only the position and responsibilities that are part of the package, but also the people I’ll be working with. So please tell me in your job ad: Who will be my manager? Who will I work and interact with most? Once I know, I can learn more about my potential future colleagues, and look at their writing or social media posts—just like you will do your research about me. 

In IndieWeb interactions: what builds connection?

Tracy Durnell brings up a good point about the importance of “lightweight interactions” in our digital communication. I remember the blowback against these kinds of “reaction messages” when they first became a thing. But I think Tracy is right that in a lot of ways, they keep our relationships strong:

The idea that lightweight interactions like a thumbs up or a “love it” comment are not valuable has, I suspect, grown out of a distrust of corporate-owned social media platforms mediating, coopting, and commodifying our interactions and engagements with each other. But, start learning about relationships and community and you quickly realize that these little exchanges are the glue that bonds us together. That relationships are built on repeated interactions, and that they must be maintained through continued interactions.

Flop rock: inside the underground floppy disk music scene

I love stories like this. Turns out there’s a sort-of movement of music being released on floppy disk… I will have to watch it from afar with admiration though. I’m already collecting vinyl and CDs so this is probably not a good idea for me.

There are almost 2,300 floppy releases listed on Discogs.com, most of which are electronic, but other genres include hip-hop, a smattering of classical and jazz, a bunch of metal subgenres, and “non-music” like experimental field recordings from Norway and spoken word from China. In 2018, Rolling Stone covered a “mini-boom” of vaporwave releases on floppies, noting that the lo-fi, lobit nature of vaporwave was an obvious match for the storage constraints of the 3.5-inch.

How Asana and Slack’s meeting purges have paid off

The importance of async work and cutting down on meetings to allow for more Deep Work time won’t be new to regular readers of the blog. And yet I can’t resist sharing another article about it… How Asana and Slack’s meeting purges have paid off has the usual methods and recommendations in it (although “Meeting Rest” is a new one to me—read the article for details).

Instead what I want to focus on here is a few pull quotes about the results companies report once they were able to successful reduce their meetings. Here’s Asana:

A few months later meeting lengths had shrunk. Most 30-minute meetings were converted to 15 minutes, some weekly meetings were moved to every other week or month, and others were deleted entirely. That meant each person was saving an average of 11 hours per month, totaling about 3.5 workweeks per year.

And:

The 60 participants saved 265 hours per month in total when reducing unproductive recurring meetings. In the aftermath of our meeting reset, employees are much more strategic and thoughtful about removing items from meeting agendas that can be effectively handled asynchronously.

From Remote:

By cutting down on meetings, we’re not just saving time. We’re also empowering our teams to work on their own schedules. This gives our employees a sense of autonomy and keeps them motivated, fostering a culture of productivity and efficiency.

And finally, Typeform:

We sent another engagement form to the team to see how they were feeling after we made these changes. The ‘ways of working’ score went up more than 10 points. Trimming our meeting time has helped our employees and our customers, which is really satisfying.

It’s worth the effort, friends. Re-evaluate the need for all those meetings. Embrace async. It leads to happier employees and more effective communication in permanent places that can be referenced in the future. And, importantly, it leads to higher quality products because no one has to rush through “actual work” after all their meetings are finally done for the day.

Evolving our organization: introducing Engineering Managers and Engineering Leads

I’ve been digging into different ways to structure engineering teams a bit, and I like this take on the different roles of Engineering Managers and Engineering Leads:

It became obvious that in most cases it’s too much for one person to manage people (growth, performance and motivation), along with driving technical execution. At the same time, in most teams, we had one or more senior developers on whom Tech Lead could rely and delegate architecture decisions, quality, mentorship, etc… We decided to give these engineers roles to make them recognized in the company for their impact, also to improve communication channels, and to help team and product leads. We introduced the role of Engineering Lead to have a major influence on how we build products. Additionally, we replaced the Tech Lead role with the Engineering Manager role, which gave more focus on people and team management (“who”).

It also reminded me of Lara Hogan’s excellent post on how Engineering Managers and Engineering Leads work with Product:

What if everybody did everything right?

Here’s Lorin Hochstein with another great post about the practice of learning from software incidents. He asks, What if everybody did everything right?

An alternative lens for making sense of an incident is to ask the question “how did this incident happen, assuming that everybody did everything right?” In other words, assume that everybody whose actions contributed to the incident made the best possible decision based on the information they had, and the constraints and incentives that were imposed upon them.

More

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. ...
  7. 192