Good thoughts from Martin Eriksson on how the PM is not The Boss. From Product Management is a Team Sport:

The bottom line is that everyone in the company owns the product, and its success or failure lie in the hands of everyone who touches it. A product manager’s job is to lead the team to tackle the product challenges together, to get the best out of everyone on the team when building the product, and to provide a gentle hand to keep it all consistent and going in the right direction.

Marty Cagan has some really insightful thoughts (as usual) on autonomous teams in Autonomy vs. Mission:

In healthy teams and organizations, the way we normally reconcile these views [where the team might have one perspective and the leadership might very well have another] is that the leadership has control of two major inputs to the decision process. The first is the overall product vision, and the second are the specific business objectives assigned to each team.

Problems arise if the leadership does not provide clarity on these two critical pieces of context. If they don’t, there’s a vacuum and that leads to real ambiguity over what a team can decide and what they can’t.

The section on how to ensure consistency in design across different teams is also really good:

In the name of empowerment and also speed, my personal preference is to invest in the necessary automation (with pattern libraries and style guides) so that the team can get the design (interaction and visual) mostly right pretty easily, and acknowledge that on occasion, you will incur some “design debt” where we realize that the design needs to be corrected, and that’s fixed as soon as the problem is spotted. I like this approach because the manager of design is still responsible for developing a strong set of designers, but doesn’t have to be in the review cycle for everything (which tends to slow things way down, as well as undermine autonomy).

Jessica McKellar gives some fantastic career, management, and leadership advice in This Is What Impactful Engineering Leadership Looks Like. The interview goes into detail on three main areas:

“When engineering management is done right, you’re focusing on three big things,” she says. “You’re directly supporting the people on your team; you’re managing execution and coordination across teams; and you’re stepping back to observe and evolve the broader organization and its processes as it grows.” 

Even though the interview is focused primarily on engineering teams, it’s applicable to all types of leadership and management. Highly recommended.

In my latest column for A List Apart I discuss our obsession with “managerial tracks” in career development, and propose something different. From Managing and Making: It Doesn’t Have to Be One or the Other:

I think we need a career system that encourages people to oscillate between individual contributor roles and manager roles. Maybe we provide “manager sabbaticals” where a manager becomes an individual contributor on a team for six to nine months. Maybe when a manager goes on vacation, an individual contributor takes on their role for a period of time (or for the duration of an entire project). I don’t know exactly what this looks like yet, but I think it’s important for us to figure it out.

I explain why in the article. I’d also like to point out that my original title for the piece was “Managing and Making: It Doesn’t Have To Be A Dirty Dance”, and it featured this photo:

I’m really glad my editor talked me out of it. It’s not good to make jokes that only people who grew up in the 80s will appreciate.

It’s a good joke, though.

There is so much wisdom in Paul Adams’ Lessons learned from scaling a product team, but my favorite part is the clear articulation of accountability. All companies should have something like this:

• If the analysis of the problem to be solved is incorrect, it’s on the PM. Ensure appropriate research is done.

• If the design doesn’t address the problem, it’s on the Designer. Ensure you understand the research and problem.

• If the design solves the problem, but doesn’t fit with Intercom, deliver best practices, or is otherwise weak, it’s on the Designer. Ensure you understand our beliefs, patterns and principles.

• If engineering doesn’t deliver what was designed, or delivers it late, it’s on the Eng Lead. Ensure you understand the problem being solved and design, plan appropriately and accurately before writing code.

• If it goes out with too many bugs and broken use cases it’s on the PM. Ensure the team test realistic usage and edge cases.

• If the team is spending too much time on fixing bugs and not adding new value per our roadmap, it’s on the Eng Lead. Ensure each project improves overall code quality.

• If we don’t know how it performed, it’s on the PM. Ensure success criteria are defined and instrumented.

• If it doesn’t solve the problem, it’s on the PM. Ensure there is a plan to improve product changes that don’t fully solve the problem.

In other words, the buck mostly stops with Product Management…

There are lots of great points in Chris Hardie’s Distributed vs. In-Person Teams, an article on the challenges and opportunities of remote work. But this part, in particular, stood out because I’ve experienced it myself:

Having some remote workers is harder than being fully local or fully distributed. […] This dual approach is probably a recipe for disaster when it comes to building shared vision and common culture in an organization. If there are team members who have a daily experience of being in the same space together and sharing all of the quirks and benefits of that, remote workers will almost always feel excluded in some way, culturally, logistically or both. When only part of the team is forced to consider the implications of having a distributed group, an unfair burden falls to the remote worker to keep their needs in front of everyone else. At best it adds a weird kind of tension to team relationships, and without incredible discipline and initiative, it probably won’t work in the long run.

This gets even worse when the remote workers are in different time zones. The remote workers are almost always the ones who have to give up their evenings to do Skype calls.

In Avoiding product management whiplash Hemal Kuntawala describes the constant context-switching that PMs need to do as they move from strategy to execution and back:

Each phase of product development requires a different perspective, almost a different mindset. At one end of the scale you have a big-picture view of the world, like looking at the market you’re in and hypothesising new value propositions. At the other end you have nitty-gritty details like the pixels and font-sizes of your UI.

I like the gentle slopes of the sine wave he uses as illustration, although I think in reality the back-and-forth is a lot less gentle…

Marysol Elorriaga discusses the challenges of implementing Lean methodologies in large companies in Getting buy-in while moving at rocket speed. One of the guiding principles is to “Release early and show results”:

To make the stakeholders feel like they are getting something equally valuable out of taking the “Lean approach”, deliver the MVP early and show results. Ensure that all features to be released can be measured and there is a proper feedback gathering mechanism in place. Ease the concerns of working under the Lean philosophy with weekly dashboards, including customer feedback, learnings from user validation/testing and analytics. Ultimately, having big data and skilled professionals to transform customer feedback and analytics into business insights is a pre-requisite for improvement and innovation.

From the same blog, Elizabeth White gives some advice on embedding a Lean team in a large company in Building the Right Culture in a Lab Environment. It’s especially important to understand that “We are Lean Enterprise – not Lean Start-up”:

Our room is lean but we are surrounded by a waterfall. While we are fully supported by TELUS, and most internal teams want to roll out what we are doing, we are a big company, depending on some serious backend systems. And while I can go on about our fantastic experience and the merits of working in a lean environment, it is important to note, waterfall shouldn’t become taboo either. There will be projects where waterfall methodology makes perfect sense, there are some – much like ours, where a hybrid approach is best and there will be some, where lean, in its purest form, is the correct path.

If you’re thinking of trying a Lean approach in a large company, there’s some great advice in these two articles.

Marty Cagan wrote one of his characteristically great posts in Product vs. IT Mindset. In one particularly harsh section he describes what happens when the people who make decisions about a product are far removed from those who make the product:

In IT mindset companies, accountability frankly is a farce. The people actually working on a project typically have no real say in what they are building, and sometimes even in how it’s built, and even when it’s due. In theory, the leadership team could try to hold the requesting stakeholders accountable for the results, but if they do they immediately hear complaints that they didn’t get what they actually wanted, and because of delays and costs, critical things had to get cut, and so it’s certainly not their fault. So management writes it off as yet another failed technology initiative. In contrast, in a product organization, we are measured by results.

I’ve always felt that this is the biggest challenge to companies as they grow. The further away those who make decisions are from those who build the product, the harder it is to remain customer-focused in the long term.

Just as my 5-year old exits her Dora the Explorer phase (to replace it with “Let it go! Let it gooooo!”), my 2-year old enters hers with the force of a thousand purple monkeys. So, look, I read a lot of Dora books these days. Recently Penny the Pony’s Big Race has been quite the hit. It’s about Dora trying to get her horse to… wait, who am I kidding. I’m sure you care about the plot as much as I do.

Anyway, there’s one part of the story that irritates me way above my average annoyance levels with these books (which is already quite high). Dora, Boots, and Penny are trying to cross a mud pit, but Penny is a bit scared. This is where we pick up the narrative:

Let’s reflect on this for a moment. Penny is scared of jumping across the logs, because she thinks she might slip and fall into the mud. Dora’s proposed solution is infuriating:

Uh-oh! Penny is afraid that the logs might be slippery. Let’s count the logs as she walks across so she won’t be worried.

How is that a good solution? There are a number of things you could do to solve Penny’s fear of the slippery logs. They could walk around the mud pit. They could make sure the logs are more secure. They could give Penny special horse-shoes that increase friction. Look, I don’t know, I’m not an expert at horses jumping over logs, but I’m sure there are people who are, and who could come up with a good solution for the problem. Counting the logs to distract Penny is a pretty superficial and condescending approach to address this particular problem.

The thing is, this is all too often how managers operate in the context of their teams. Oh, you’re unhappy with the culture of the company? Let’s throw a company BBQ. On a Sunday afternoon. You’re concerned that the product development process is not optimal? Let’s hire another development manager. Instead of spending time to understand the cause of the anxiety communicated by team members, managers often rely on distraction or easy answers that give the illusion of a solution, but is nothing more than a way to check a box to say that they “did something.”

I read two really good management articles recently that are relevant here. The first is Gregg Satell’s What To Do While You’re Waiting For Steve Jobs (beware, that’s a Forbes link, so you’re going to have to do a lot of clicking around to dismiss all the things that try to distract you from reading it). He says this about treating people with respect:

If you expect your employees to be motivated to do their jobs well, you’d better treat them with dignity. Leadership is not the art of getting people to do what you want, but inspiring them to want what you want.[…] While many leaders believe that they can bend the organization to their will, that’s rarely true.  Being a jerk doesn’t make you Steve Jobs, it just makes you a jerk.

The second is Lindsay Holmwood’s It’s not a promotion — it’s a career change. It’s a great post and you should read the whole thing, but I want to quote most of the opening in full, because it’s great:

Your job is not to be an engineer. Your job is not to be a manager. Your job is to be a multiplier.

You exist to remove roadblocks and eliminate interruptions for the people you work with. You exist to listen to people (not just hear them!), to build relationships and trust, to deliver bad news, to resolve conflict in a just way.

You exist to think about the bigger picture, ask provoking and sometimes difficult questions, and relate the big picture back to something meaningful, tangible, and actionable to the team.

You exist to advocate for the team, to promote the group and individual achievements, to gaze into unconstructive criticism and see underlying motivations, and sometimes even give up control and make sacrifices you are uncomfortable or disagree with.

You exist to make systemic improvements with the help of the people you work with.

If I could summarize the advice in these articles, and what I’ve personally experienced about good managers vs. bad managers, I’d say this. If someone on your team complains that they’re worried about slippery logs across a mud pit, don’t tell them you’ll count loudly as they jump to distract them from the fear. Instead, take the time to understand the cause of their fear, and help them solve the real problem behind that fear.

In other words, don’t be like Dora. She’s a terrible manager.