“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.
“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.”
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 –
Good engineering leads understand the the details and are hyper focused on shipping quality product within agreed upon timelines
Strong engineering leads add the ability to communicate well and also manage to be flexible to changes in plans
Great engineering leads understand user problems, our strategy, and objectives so well that they shape product requirements in meaningful ways
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.
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 –
You build leverageable products: You pay attention to pieces of the product that can be reused in other places. If you’re building an “upload photo” screen, can that be reused in other parts of the product? Or, if you are building an onboarding flow with a series of steps, can you build it as a platform? That would enable other use cases to easily modify the flow when they need to.
You use leverageable solutions: This means reusing what already exists where possible. This will mean being a bit flexible on your plans. You may not get everything you want in a common component. But, if you do commit to it, you will now have multiple teams committed to improving it. Doing this will save valuable engineering time and create leverage across multiple engineering teams. The effects of this leverage compounds with the size of your organization.
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.
We were trying to cross the road with the kids – everyone on our respective bikes. Just as it was all clear for pedestrians/bikes to cross, our older kid experienced trouble getting started. As there were only a few seconds left, I decided we needed to turn back and wait for the next round.
So, I turned back to the sidewalk, parked my bike, got to her, picked her up, and got her back.
Through this process, there was a car waiting to turn right. They saw this charade on the road and decided that the appropriate response was to scream at me.
So, as I turned back and apologized to them, I became aware of some serious screaming and gesticulating.
More screaming ensued as I went back to get our child back.
I think they were trying to explain that they wanted to turn quickly and that I was wasting their time. I have to assume they were in a burning hurry. I hope it wasn’t an emergency where 10 seconds made the difference between life and death.
Then again, it probably wasn’t.
In a world where everything is instant, it is more common than ever to not want to wait.
As I am in the process of adopting stoicism as my philosophy of life, I was reflecting on what I could have done better from a stoic point of view.
I think I did well to not succumb to anger. But, I was flustered and annoyed and missed the opportunity to respond with calm, grace, and humor.
A year after winning the women’s world cup, the US women’s soccer team were knocked out without a medal at the Olympics in Rio.
It was fascinating to hear Coach Jill Ellis reflect about the importance of that defeat. It galvanized her to remake the team. Yes, they had only been world champions a year ago. But, it was time to change. New players had to be brought into the setup and new tactics had to be tried.
It is a lesson that never gets old in professional sports. Great teams can dominate for 2-3 year periods. But, they often hit a wall after that. Everything that used to work just doesn’t seem to work as well anymore.
Great managers/coaches who manage to win while staying at the same place longer than 2-3 years become experts at evolving their teams.
It is an important lesson in our lives too. If we’ve had a good run doing what we’re doing for the past 12-18 months, it is probably time to think about where we want to go and what we need to do to remake ourselves.
Two years ago, a trainer at the gym explained I was lifting weights all wrong. I was taking the lazy approach and bending to lift weights instead of squatting.
This didn’t apply just to weights at the gym of course. I was clearly doing this at home too.
A good friend was spending time with a physiotherapist at the same time as he was recovering from issues with his knee. This physio recommended the same approach for routine tasks at home as well – e.g. loading the dishwasher. He shared this lesson with me at about the same time.
I remember writing about it after these conversations hoping to change how I lifted weights and take better care of my back and knees.
Prior to learning this approach, I used to experience occasional pain in the back after lifting something heavy for a sustained period or after a long bout of ironing.
Luckily, their advice stuck with me and I’ve done my best to avoid the lazy approach to lifting things since. And, in the two following years, such instances/pain/niggles have almost entirely disappeared.
An idea that isn’t taught enough (if at all) in schools – the outsized impact a positive attitude has on our ability to solve problems.
The same problem can look tractable or insurmountable depending on how we decide to approach it. The transformation of the same situation in our heads is magical.
“Now commencement speakers are also expected to give some advice. They give grand advice, and they give some useful tips. The most common grand advice they give is for you to be yourself. It is an odd piece of advice to give people dressed identically, but you should—you should be yourself. But you should understand what that means.
Unless you are perfect, it does not mean – don’t make any changes. In a certain sense, you should not be yourself. You should try to become something better. People say ‘be yourself’ because they want you to resist the impulse to conform to what others want you to be. But you can’t be yourself if you don’t learn who you are, and you can’t learn who you are unless you think about it.
The Greek philosopher Socrates said, ‘The unexamined life is not worth living.’ And while ‘just do it’ might be a good motto for some things, it’s not a good motto when it’s trying to figure out how to live your life that is before you. And one important clue to living a good life is to not to try to live the good life. The best way to lose the values that are central to who you are is frankly not to think about them at all.” | John Roberts, US Supreme Court Justice at Cardigan Mountain School
There are three wise nuggets in this excerpt.
First, “Be yourself” is advice that shouldn’t be taken at face value. Be yourself so you don’t conform and follow someone else’s dogma. But, don’t let that get in the way of becoming the best version of yourself.
Second, don’t let life happen to you. Be intentional about what you value and how you live in accordance to those values. Make those values virtues.
Finally, as Viktor Frankl explained, don’t aim at success – the more you aim at it and make it a target, the more you are going to miss it. For success, like happiness, cannot be pursued; it must ensue.
And it only does so as the unintended side effect of one’s personal dedication to a cause greater than oneself or as the by-product of one’s surrender to a person other than oneself.
A Learning a Day 