Author: Alexis

The Boston Product Management Association hosted a meetup at HubSpot yesterday about the collaboration between Product Management and Engineering. Chatting with a few people before the start of the event, it sounded like there was a need for a productive tension between the two roles. Here are a few notes from the discussion about that productive tension.

Michael Woonton facilitated the panel composed of Sophie Higgs and Stuart Layton from Hubspot, Adam Buggia and Bryan Dunn from Localytics, and Kylie Brennan and John Siemering from Wayfair.

In the first 5 seconds, a panelist explains his role as ensuring that every member of the team understands what the “North Star” was. They are using OKRs (Objectives and Key Results) to reach that shared understanding and to ensure the focus on the customers.

For context, all the panelists are working with self-directed small teams. The vocabulary differs from each other, some are calling them agile teams, others scrum teams, and others squads, but the focus of one team delivering end to end a specific area is similar.

Another panelist highlighted the fuzzy separation of roles between the product manager and the engineering manager. The blurred separation makes their collaboration better and avoids the “threw over the wall” effect of a more classic division of the roles.

Investing in the relationship between the product manager and the engineering manager is crucial to make the collaboration sustainable and effective. Learning to speak each other language helps to find common ground on aspects that seem to traditionally opposed product management and engineering. “Do we want more new features?”; “Do we want to resolve our technical debt?” are not questions they are asking. They are not working on technical debt for the sake of it, but for advancing the resolution of a problem for a customer.
Speed is the critical aspect highlighted by all. Speed to get problems solved faster. Speed for the users of the products.

One of the product managers mentioned that with his engineering background, he noticed that his own technical knowledge could be a limiting factor. When he believes something is not possible, he could even avoid submitting the problems to the engineering team. He realized that as technology evolves fast, his limiting beliefs were sometimes wrong.

The roadmap represents the best guess at solving the right problems right now. Adjusting regularly the assumptions and continuously evolve the roadmap is part of the game. The roadmap will not present a list of features, but the business outcomes positioned in the business context, and they nearly all agreed that OKRs is the way to share objectives between teams and foster collaboration. The only caveat was on being cautious not to lose the vision and the associated narrative [which is the way OKRs are supposed to work anyway].

Dependencies between teams are a lack of communication. The communication needs to make visible the connection between the business outcomes and the contributions of the different teams. Once again, OKRs are a way to ensure that several teams understand their contributions to the same Key Result.

On the topic of dependencies, one of the panelists mentioned Conway’s law, as a reminder of the connection between your organizational structure and the product you build.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
Conway’s Law

Continuing on dependencies, I appreciate the honesty of one participant explaining how her team tried to solve by itself a problem that should have been addressed by another team. The process of learning the skills they did not have was at the same time interesting, and a big waste for the company as the other team could have solved the problem faster, if only they understood how important it was.

Who gets to hear the feedback of the customers, was another question unifying the panelists. Having the team hearing directly the feedback from the customers is beneficial. Having the team working directly with the support organization, and feeling the pain of customers help them to find a faster way to solve important pain points.

A question from the audience was around legacy and technical debt. Hearing the question, I thought it was more a “legacy organization” question in a company where product management and engineering were in opposition instead of collaborating on shared goals.

What are your thoughts on this productive tension between product management and engineering?

The Matrix of Principles is a reflection tool to capture how stakeholders understand Deming’s 14 Management Principles.

Reflecting on the management principles enables the team to share their beliefs on management, to share their views on where the organization is, and to identify areas for improvement.

Follow the few steps below

• Take a blank sheet of paper, or use a whiteboard,
• Draw a 2×2 matrix,
• The horizontal axis represents your agreement with the principle. On the right, you agree; on the left, you disagree,
• The vertical axis represents how the principle is applied to your organization. “Applied” at the top, “not applied” at the bottom,
• You will now position Deming’s 14 Management Principles by placing their numbers on a 2×2 matrix. Each team member uses a different color.
• After placing each principle, the facilitator asks the outliers to explain their position.
• The facilitator asks the group if it inspires some ideas for the team.

You can use the tool as a self-reflection one. As a facilitator, it is useful to try the exercise first by yourself to be able to pick the principles that will most resonate with your team.

There is one assignment per chapter in the book Changing Your Team From The Inside. The Matrix of Principles is the assignment from the chapter two.

The practice is available in the Open Practice Library. You can find other great practices in the library and you can even contribute to it!

 

In Measure What Matters, John Doerr speaks about the quality prized by Andy Grove: collective accountability, fearless risktaking, measurable achievements. John explains that Google studied 180 teams using five questions. The internal project code name was Project Aristotle.

The results? Standout performances correlated with affirmative answers to these questions:

• Structure and clarity: Are goals, roles and execution plans on our team clear?
• Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
• Meaning of work: Are we working on something that is personally important for each of us?
• Dependability: Can we count on each other to do high-quality work on time?
• Impact of work: Do we fundamentally believe that the work we are doing matters?

A few weeks back, I decided to test the five questions with a team during their quarterly face to face meeting. I used the length of the meeting room as a scale and identified graduations with sticky notes on the wall from zero at one end of the meeting room to ten on the other end.

I asked everybody to stand up and explained the rules. I will ask questions, the more you agree, the closer to ten you need to be, the more you disagree, the closer to zero you need to be.

We started with a few questions just to warm-up the group and to have opportunities to clarify the rules. And then, I began to ask the five questions.

First one about structure and clarity, two people moved to five and six, all the others looked at how the boss will react, and one ask a clarifying question: When you say “our team,” what do you mean? I clarified, the team is the people that are in this room now. The rest of the people are moving between seven and nine.

I am now asking a few clarifying questions asking them to explain their position on the scale. I also encourage them to ask questions. The newcomer in the team suggested that it could help us to use Objectives and Key Results (OKRs) as he was doing in his previous company. An interesting conversation followed, and I am capturing on sticky notes discussion topics for the rest of the meeting.

We continued with the other questions, and people moved faster to their graduations (even with their manager in the room). The conversations focused on what the people need to give a better grade, which gave us plenty of topics to cover in the meeting, restructuring the agenda to better fit in what was essential to the team.

The exercise was useful as it raised the awareness on some aspects that were missing to “really” called this group of people a team.

Try it and let me know!

Earlier this week, I announced the availability of the first edition of Changing Your Team From The Inside. I said in that post that I would tell you the story behind the book.

Back in 2013, I started to think about writing a book about the connection between agile and open source values, principles, practices, and tools. I thought that it would be an inspiration for large IT teams to transform their organization considering the different services they are running as open source projects in a community of distributed developers. As There are still quite a lot of projects that are maintained by one or two individuals, I thought that it would be an excellent opportunity to bring in open source communities practices that will value the work of a team, more than the heroic behavior of individuals. I delivered presentations on that topic, like in 2014, at the OpenStack Summit, in Atlanta, with Frederic Lepied, or in 2015, at the Open Stack Summit, in Vancouver, with Nick Barcet.

During the work on this project, I was struggling with different audiences, and I concluded that it was not the right angle. I aborted the project to work on a more individual-based approach.

A discussion of their values and principles with one of the companies I was working with at that time brought another insight. One of the founders said: “the most important thing is, we want employees to be happy, and with that, we will have happy customers.” This simple sentence drove a lot of research on happiness, so much research, that at some point I even thought that I would write something on that topic. Thanks to Julien Dubois, I keynoted the Drupal Developer Days in 2015 with “Happiness is Coming,” and that well received!

I continued to work around that idea during the next two years, bringing some of the content in several conferences and using it in my day to day work. Working with a company heavily invested in leading OpenStack to success, to provide enterprises with cloud capabilities for their on-premises infrastructure was an excellent source of learning. With Mark McLoughlin, we delivered a presentation in 2016, at the OpenStack Summit in Austin, to cover the idea of the flow of work going from the upstream company to the customers of the product based on the different projects coming from different communities. We wanted to send the message that whatever company you are working with, you don’t wear two different hats, a company hat, and a community hat, you integrate both responsibilities in your day to day work.

The OpenStack community was also a great source of learning with great people like Colette Alexander who founded the Stewardship Working Group to support the technical leaders in the community in the development of their leadership skills. We enjoyed a leadership training provided by ZingTrain in Ann Arbour. (What? A deli delivers training on leadership?)

The travel to Ann Arbour gives the opportunity to Emilien Macchi and me to visit Menlo, the company founded by Richard Sheridan, the author of Joy Inc. I am telling that to highlight that the quest for happiness was significant in that journey of building high impact sustainable organization.

I became progressively convinced that companies needed Transformation Manager because the transformation is not a small improvement. Transformation supposed that you will entirely reconsider the way you work. I started to work on the book. I also began to work on defining the role of a person like this in my company. It slowly became clear that it was not working, we were falling back on the “change agent” role, or the “agile coach” role, or the “improvement person.”
If you are familiar with the 14 management principles of Deming, you know the sole idea of having a person in a transformation manager role is breaking the last one of them:

“Put everybody in the company to work to accomplish the
transformation. The transformation is everybody’s job.”

Like quality should be built in the product and not assess after the fact, the transformation should start from within.

People are the source of change.

The beliefs of people define the value of the organization they are working with. People can change their organization from the inside. And so, I think I found the right angle, providing ideas of approach people could use to foster the change in their organization.

The rest is in the book: Changing Your Team From The Inside.

I am eager to hear from you about what’s working (or not) for you!

 

I heard back today from Claude Aubry the author of the great book on Scrum in French:

Je viens de finir le livre #ChangingYourTeam (from the inside) de @alexismonville et je le recommande vivement. Très inspirant.

— Claude Aubry (@claudeaubry) July 4, 2018

The approximate translation is: I finished the book Changing Your Team From The Inside and I highly recommend it. Very inspiring.

Thank you Claude!

 

 

Thank you to the subscribers to the mailing-list! I appreciate your support!
All the subscribers to the mailing list, before the launch, will receive a 25 % discount on all versions of the book. So please, continue to share with your friends and colleagues!

I am making good progress in finishing the book. The reviewers are doing a great job! Thank you folks! You are all amazing! I feel I am lagging behind, but we are getting there 🙂

Last month, I asked you what versions should be available. I received more answers than expected which is great! Among the responses, a fair number are asking for electronic only, paperback only, or both.

I also discussed with my friend and colleague, Julien Danjou, the author of  The Hacker’s Guide To Python and Scaling Python, on that topic of versions. His two books are available in different versions. The distribution of sales among the versions shows a real interest from readers for this variety.

The conclusion is straightforward, let’s satisfy all the needs with an electronic only, and a paperback and electronic versions.

Julien also told me that many people wanted to have the time to discuss with him about the book, and so he created a version to do precisely that. In your responses, there were several asks we could satisfy with a “team offer” that includes a discussion with the team.

And, there’s more! My friend Laurent Salsé from Fitnet Manager, the ERP for those who don’t like ERP, told me: what about a tool that transforms the recommendations of the book into concrete actions for the team! Definitely interesting!

You have more ideas about the book versions!  If it’s the case, please, send me a note right now and tell me! If nothing comes to mind, just say hello. I like getting to know the people who are interested in reading the book.