The anti-pattern I’d like to explore today is the Ponzi roadmap. It usually starts with the best of intentions but has extremely harmful effects as a company scales.
When a company is in the initial stages and has a small engineering and product team the planning model that emerges is what I call the pooled model. Engineering is considered a pool of resources and usually composed of full-stack engineers. The product is typically small and mostly a monolith, every engineer can work on anything and there are just a few PM’s (maybe just one). Since we are all agile, every quarter the PM comes up with a list of priorities and outcomes, engineering staffs the priority from its pool of engineers and delivers outcomes. The next quarter rolls around and we do this all over again. Engineers move on to working on different things every quarter. This makes perfect sense in a small company – but goes horribly wrong as you start scaling up.
Nothing is more responsible for the good old days than a bad memory – Franklin Pierce Adams
We’ve all read about how culture eats strategy for lunch. The internet is jam-packed with a million blog posts on the superficialities of culture. Its time for some inside baseball with some actual actionable things to watch out for and prevent.
It is absolutely true that the culture of the company dictates how it can adapt to change and eventually succeed. Culture is hugely important, however along the journey from a small company to a midsize company to a large public company, the culture will change. At all these stages, different parts of the company will have different cultures and norms. In fact sometimes within the same team, you will have differences based on where the teams are located and their size.
It’s been 10 years since the 2008 financial crisis. Astute observers will correct me and point out that the crisis actually started in early 2007 when the Bear Stearns High-Grade Structured Credit collapsed. This was the first collapse of a hedge fund that was loaded up to the gills with subprime CDO’s. If you were following FT Alphaville in late 2006/ early 2007, you’d be ahead of the game. The signs were there! Some great coverage to relive and re-read
Imagine the scene, its the end of the day, dinner is done, you are ready to turn in. The last thing you have to do is wash the dishes. Your spouse loads the dishwasher and just as she is heading to bed, she tells you “Honey put the soap in the dishwasher and turn the dishwasher on”
Accountability is a fascinating topic. The textbook definition is “the quality or state of being accountable; especially: an obligation or willingness to accept responsibility or to account for one’s actions”. While a lot has been written about individuals, I’ve found in my experience, the actual mechanics of how to think about team accountability for product teams, pretty lacking. This post is an attempt to describe the framework that has been useful for me. A few of these tips are borrowed from the great executives I’ve had the pleasure to work with and a few are homegrown. Hopefully, this helps somebody who is just starting out or well into their manager/team leader journey.
You’re the first PM at a startup. You are a small company with one product, searching for product market fit. You grind and preserve and you achieve the holy grail of product market fit. CEO walks over and says “It’s time to start scaling, give me a plan, how are you going to scale the product management team? Let’s chat in a few days”. At this moment you are probably thinking “whoa what? team? There is going to be more of me (PMs)?”
How can I do it? So many questions. Where do I start? How do I hire? What do I do?
The Myers Briggs Type indicator (MBTI) is used to understand your personality type. The idea behind the indicator is that if you understand your personality and default preferences then you are able to play to your strengths. In addition, by knowing your team’s preferences, you can communicate better with your teammates and thus become a high performing team.