When we loses our temper and/or say something unkind or unconstructive, three things tend to be true:
(1) Losing our temper diminished the long term value of our message.
(2) Our reasons for being upset were not completely wrong.
(3) Our reasons for being upset were not completely right.
I’ve been thinking about these ideas of late and attempting to internalize them. When I do remember them, I respond more constructively than I would have otherwise.
More reminders to self needed.
For the best part of 7 years between 2013 and 2020, the report card for Manchester United Football club would have read “Below expectations.”
If we factored in over 500 million dollars of investment in players over these years, the report card would then say “Significantly below expectations.”
Then, in Jan 2020, one player joined this expensively assembled underperforming squad. And, in the 37 premier league games that have followed, he has scored 21 goals and 16 assists.
Manchester United were struggling in 6th place when he joined. His presence propelled the team to an unlikely 3rd place finish at the end of the season. And, he has continued to inspire the team this season to be genuine title contenders.
I wrote about Bruno 6 months after he signed.
Before he was signed, Bruno Fernandes wouldn’t have been mentioned in a list of the top 10 or 20 or even 50 players on the planet. How, then, was this transformation possible?
It turned out he just brought the kind of skills the team needed at the time with a willingness to work very hard and show up to every game and practice session with a great attitude and the desire to win.
It has been fascinating to watch the transformative effect of this one player’s arrival on a massive football club. And, that he did it with a great combination of skill, heart, and attitude makes it all the more inspiring.
It is a great reminder of the effect this combination can have on any team.
If he can do it, perhaps… just perhaps… so can we.
I will be the first to admit that I had my doubts about whether this transformation would last. Was it just a honeymoon period?
But, one year later, it is still going strong.
Inspiring.
I like keeping our photos organized on Dropbox. Each year has a folder with sub-folders that speak to various phases in the year. Our favorite photos and videos are copied into another “favorites” folder that I sync to photos app on our phones.
I used to look forward to this sorting exercise every six months. It was nice to relive memories and pick our favorite photos and videos.
Somewhere down the line, this became a chore. I think it was after our second child was born. It was hard to find a quiet half-day to do this. There were also many more photos and videos to sort. It became a task.
So, I asked my wife to pitch in to help. But, I soon realized I liked doing it myself. That solution didn’t feel right.
After working through last year’s photos and videos over the holidays, I figured it was time to do something different. My new weekly routine involves sorting photos and videos every weekend.
I’ve done this for five weeks now and doing this in small chunks has made a world of a difference. It feels easy and approachable. Most importantly, it is fun again.
It is a reminder of the power of breaking down last tasks into small ones. It reminded me of the “Bird by bird” story.
“Thirty years ago my older brother, who was ten years old at the time, was trying to get a report on birds written that he’d had three months to write. It was due the next day.
We were out at our family cabin in Bolinas, and he was at the kitchen table close to tears, surrounded by binder paper and pencils and unopened books on birds, immobilized by the hugeness of the task ahead.
Then my father sat down beside him, put his arm around my brother’s shoulder, and said, ‘Bird by bird, buddy. Just take it bird by bird.’”
If you catch yourself saying “this is my #1 priority” from time to time, a good question to ask yourself – “Would you stop whatever you are doing at any point during the week to take a call about this?”
If the answer is yes, it is your #1 priority.
If it is no, do yourself and those around you a favor and stop calling it that.
“What is delayed is not denied” is one of legendary basketball player and coach Dawn Staley’s favorite maxims.
It resonated with me because there’s so much belief packed in those 6 words. Failure, after all, is not the falling down. It is the staying down.
It also beautifully captures something I’ve observed time and time again. Things that we or folks we know care about often don’t happen in the timeline we expect (or hope). But, a combination of time, learning, and an abundance of hunger make good outcomes inevitable.
What is delayed is not denied.
“Spend less time mourning your friend and instead go ahead and make one.”
“You have buried someone you love. Now look for someone to love.”
Seneca’s notes on loss resonated deeply.
I was reminded of a post I wrote a while back on a similar theme. It was called “Mourn them not. Miss them not. Celebrate them do.” I looked it up to realize that post was written a full decade ago.
I had two reactions – holy moly, that’s a long time ago. And, it is amazing how fresh the idea was despite being a decade ago.
It was around that time that I had gotten to better understand the nature of loss. By then, I had seen up close how different responses to a loss can be from folks within the same family. I had also experienced the after-effects of these responses for a decade.
The conclusion I came to was the same as Seneca’s (or the Jedi order – whichever you prefer). After the initial period of grief and mourning, folks who used the pain from the loss to inspire themselves to be grateful for the people around them transformed how they lived their lives. Folks who didn’t were stuck in a rut of denial and self pity.
“Spend less time mourning your friend and instead go ahead and make one.”
It is a powerful idea.
We don’t talk about dealing with loss enough.
The degree to which a company cares about your call is inversely proportional to the number of times you hear – “your call is important to us.”
It works this way in our relationships – both professional and personal – too.
Care shows up in action. And, our emotional intelligence is proportional to our ability to ignore what is said and pay attention to what is done.
And, on the flipside, if we’re saying “we care” or “we are invested,” let’s make sure it shows up in our actions.
A note for new subscribers: This post is part of a series on my notes on technology product management (this is what I do for a living). You might notice that these posts often link to older posts in the series on LinkedIn even though they are all available on this blog. That is intended for folks who only want to follow future product management related posts. Finally, for all those of you who don’t build tech products for a living, I believe many of these notes have broader applicability. And, I hope you find that to be the case as well…
A quick overview of what we’ve covered on “Notes on Product Management” so far –
There are many variants of IC product management roles. Some are heavily customer facing and involve spending a lot of time with marketing, business development, and sales. Many require heavy collaboration with design. Some others have a strong data component.
But, the one common feature across every IC PM role is collaborating with an engineering team. Not only is this is also one of the biggest levers we have in our attempts to solve for velocity, this relation is also central to our day-to-day happiness as PMs. As I shared in “Solving for Feasibilty,” improving our ability as product managers can solve velocity problems we have ~50% of the time. And, the way to do that is by building habits that step-change our collaboration with our engineering team.
As collaboration with engineering is so fundamental to an IC product management role, we’re going to go back to the basics. We will take the 4 core skills we’ve discussed at length – problem finding, problem solving, selling, and building effective teams – and break these down into a collection of habits.
(1) Problem finding: Engage engineering leads early
(2) Selling: Explain “why” – every IC should know why their work matters
(3) Building effective teams: Be a great partner
(4) Problem solving: As this is the most used skill in our collaboration with engineering teams, we’ll cover habits that are important as part of prioritization and development in today’s post. We’ll cover releases in the next post.
(1) Problem finding: Engage engineering leads early
“Engage your cross-functional partners late” – said no cross functional partner ever. :-) This applies to engineering leads as well.
Over time, you’ll have experience partnering with various kinds of engineering leads. I’ve come to think of 3 leaps engineering leads make –
While some leads make these leaps in previous roles, others can make these leaps when we partner with them and engage them in our thought process. That, in turn, results in them pushing us to become better product managers. They do this by ensuring we understand the impact of our decisions.
For example, when our engineering leads push us on whether we feel our problem statements are strong, they’re reminding us of the cost of getting these wrong. I’ve spoken with irate engineering managers who’ve spent months building a product only to realize the product wouldn’t see the light of day.
It doesn’t matter that the reason is executive misalignment or that customers hate the idea of the product. From their perspective, it is months of wasted effort and damaged morale. And rightly so. Product development is expensive. The more we can do to catch problems early, the less the cost of the process.
Engage your engineering leads early.
(2) Selling: Explain “why” – every IC should know why their work matters
A traveler was once passing a man cutting a big rock. She asked him what he was up to. “I’m cutting this rock” – he said.
After walking a few yards, she saw a second man working on another big rock. When she asked him what he was doing, he said – “I am building a roof.”
A few yards further, she saw a third man working on a similarly large rock. As she was still curious what was going on, she asked him as well. “I’m helping build a Jedi temple*” – the third man responded. “It is going to be beautiful when we’re done.”
(*He wasn’t using a light saber – in case you’re wondering)
I think this story is a useful way to think about whether you’re doing a good job selling. If every IC engineer on your team can explain what you are working toward and why their work matters, you’re in good shape.
Else, keep at it. Explain why till you are tired of explaining why. You’ll be surprised just how much of an impact it has. You’ll find team members giving an extra 10% that you never thought possible here and another extra 10% there.
Inspired teams do inspired work.
(3) Building effective teams: Be a great partner to IC engineers
We will be covering building effective teams in more detail in future posts. This section is focused on being a great partner to your IC engineers. And, you can do that by paying attention to the context, trust, and communication trifecta.
The context-trust-communication trifecta is a simple way to think about the health of your team. They are like three legs of a tripod. Understanding this helps us understand why the majority of teams are dysfunctional. Teams work only when all 3 of these are healthy.
(a) Provide Context: In addition to sharing why what you do matters, use team meetings to share context. This includes any change in priorities that you’ve heard from the leadership, any key changes in strategy in the broader organization, important pattern changes in business metrics, and/or updates about related initiatives that partner teams are working on. Encourage engineering leads and other cross-functional partners to do the same. Shared context helps everyone make more informed decisions.
(b) Invest in building Trust: Invest one team meeting every quarter/few months to do something different. Play a fun game or organize an ice-breaker. The most powerful exercise involve members of the team sharing their stories. Getting to know each others helps build understanding and trust.
(c) Prioritize communication and responsiveness: IC engineering time is the most valuable time in software companies. Internalizing that idea means ensuring IC engineers on your product team are never blocked. While good problem finding and product specs help us with this, we’ll also need to be available for our engineers as problem solving partners when they face inevitable blocking issues.
This is why co-location is powerful for product teams. No amount of structured communication can replace walking over to a partner’s desk and solving the problem on a whiteboard. But, as we’re all in a virtual world for the next months, committing to a reasonable response time on Slack/email is an important replacement.
This doesn’t mean reacting to every ping and never making time for deep thought. It just means setting clear expectations on when you’re unavailable and responding to folks every few hours to ensure no one is blocked.
As I mentioned at the start of this section, all of the above constitute the basics of building a healthy partnership with our IC engineers. We’ll cover this in more detail in future posts.
4) Problem solving:
a) Prioritization – Invest in foundations/problem prevention (a.k.a “Be a Lannister and pay off your tech debts” in a post on “5 habits that build a high velocity product team” )
When was the last time your team had an urgent bug? I assume you celebrated the folks who burned the midnight oil to solve it?
Acknowledging and appreciating such efforts is good. But, we provide more leverage to our teams when we use such issues to prioritize upstream/preventative bets. Attempting to squeeze every inch of engineering capacity in the quarter to move metrics is a short-term efficiency focused game. The goal isn’t efficiency, it is leverage.
To enable high velocity product development, we need to free engineering time from constantly dealing with urgent issues. And, we can do do that by marking off a proportion of our engineering capacity for foundational efforts.
This investment turns out to be one of the easiest things we can do to help create happy engineering teams. Such efforts don’t just reduce painful on-call shifts (they do that). They are often the source of intellectually stimulating work that can often provide leverage to other engineering teams as well.
Finally, while we can run with a ~25% allocation as a rule-of-thumb, this can go up in some quarters depending on the nature of the team. Typically, the more backend work involved, the more it is likely we’ll need to make large investments and ensure the engineering team has the space and autonomy to build scalable systems.
b) Development:
i) Aim for leverage
Efficiency is minimizing effort for a given impact. Leverage is maximizing impact for a given effort.
Aiming for leverage means 2 things in the development phase –
When Jeff Bezos mandated that every Amazon team would expose their data and functionality via APIs in 2002, he explicitly prioritized leverage at Amazon.
Of course, Amazon’s example won’t be relevant to every company and team. You are not going to be able to prioritize leverage if you are barely managing to survive or struggling to find product market fit. Shortcuts are inevitable.
But, every shortcut racks up tech debt. So, if you have the luxury to take a bit of extra time to build it right or are part of a large company where a leveraged solution can have massive cross-team impact, it is worth the wait.
ii) Document everything
You’ve probably done lot of documentation in the problem finding stage – with a strategy doc, roadmap, and a product spec. But, for large product releases, I’ve found it helpful to have an additional doc – a “plan” spreadsheet.
Unless you’ve got superhuman attention to detail, you’ll inevitable find a need to incorporate more business logic as you discover various edge/stress cases. These edge/stress cases may just be lines on a document to a PM. But, to an engineer, it could be the start of years of pain when services breakdown, angry users flood the support channels, and when executives criticize the craftsmanship of the product. Stress cases are important and we need to be as thoughtful about our decision making in dealing with these as with our P0 product requirements.
Every time you make a decision or update the logic, document it in your plan spreadsheet along with other decisions you make as you move towards a major release. We’ll spend more time on this spreadsheet in the next post.
The process will ensure you don’t make one-off decisions in a slack thread that is buried somewhere. It will also force you to simplify business logic and variants. That, in turn, will reduce long term maintenance costs and improve your team’s velocity.
c) Ramp/Release: This area is large enough to warrant its own post. So, we’ll cover this next week.
I hope this was helpful.
A Learning a Day 