The startup and venture capital game hinges on one simple idea: growth. Investors invest in order to get a sizeable return. For that to happen, companies need to grow. But grow what exactly? Revenue? Number of employees? The cloud provider bill?
And by the way, is that the same as scaling?
Growth means adding resources at the same rate that you're adding revenue. Scale is about adding revenue at a rapid rate while adding resources at an incremental rate. (source)
The promise of tech businesses is leveraging the technology to achieve a lot more with a lot less. But how many startups really live up to that promise? Sadly, most just grow but do not scale. And slowly but surely the walls start closing in.
As Twain said, "history doesn't repeat itself, but it rhymes". With some (often fleeting) form of product-market fit comes more cash (to grow, of course), more cash means more people, which means more stuff can be done in parallel... soon enough, communication and collaboration is a nightmare, everyone "aligning" and "syncing" all the time, getting very little done yet slowly burning the candle on both ends. The CEO complains that everything was much faster and easier in the good old days, while that cash everyone celebrated a few months ago is steadily syphoned into the hands of Google, Facebook and Amazon.
When all else fails, "Agile" to the rescue. Unfortunately, the starting point is usually to look at it as a silver bullet for all collaboration problems – a panacea, to use yet another buzzword. As the thinking goes, if only we use this "Scrum" or "Kanban" thing (like that other successful company over there), we'll ship so much more and be golden. Thinking critically is harder than following a recipe, and everyone is busy anyway.
The reality is that building product is hard. It's not just about shipping product, but importantly about what product to ship. Product Management is at the core of this, yet it's one of the most ambiguous roles in tech companies. And the more people you throw at the problem, the harder it gets. Human nature gets in the way, and it gets very messy, very quickly.
All of this yapping to introduce a new feature here on The Evolutionary Manager where we do our best to get deeper at the question of how to build products effectively. In this first instalment, I talk to Mohammed Rizwan, currently a Senior Product Manager at Hotjar. I had the pleasure of working in the past with Riz (as he's known among friends) at two different companies where he donned both the PM and Agile Coach hats. Incidentally, he's one of the most knowledgeable people I know when it comes to Product Management.
Without further ado, please enjoy this conversation about Agile, product development and high performing teams.
No business owner would shrug at the idea of being "agile" but few probably know it originally came from engineers (with the Agile Manifesto), not project or product managers. What are some of the biggest misconceptions you feel companies still have regarding "agile"?
Riz: Two major misconceptions spring to mind. Firstly, is that when you look at how those founding Engineers arrived at the Manifesto, they looked to different lightweight methods of creating software that already existed, and merged those ideas. And so whether an organisation calls their way of working Scrum or Kanban or anything else, the essence of “Agile” is that it should be lightweight. Unfortunately, too many organisations miss this. And what you end up with is business leaders, Product Managers and Project Managers working the same way they’ve always worked: big projects, long roadmaps and little cross-discipline collaboration, all punctuated with Agile-looking ceremonies such as standups, planning sessions and retrospectives.
The second misconception reveals itself whenever I ask teams and leaders in organisations why they want to be “more Agile”. Without fail, the answer is that they want to be “faster”. And more specifically, that they would like the implementation speed - that is, the work the Engineers do - to be executed quicker than it is so that the business can hit its deadlines with a higher success rate. This expectation is doomed from the start as it ignores a very basic truth: Engineers are knowledge workers. And as Tom DeMarco points out in Slack, “Think rate is fixed”. And so, if organisations want to be faster, they actually need to find ways to enable their knowledge workers to think with more clarity and focus. And the way to achieve this? Well, with lightweight methods of course.
Patrick Lencioni, author of Five Dysfunctions of a Team, argues that "Genuine teamwork in most organizations remains as elusive as it has ever been." Why do you think this is?
Riz: I would agree, and I would add that Patrick Lencioni pays too much respect to organisations: by saying genuine teamwork remains “elusive”, he’s implying that those organisations are at least looking for such teamwork in the first place. In my experience, this is very far from the truth. We could spend the rest of this Q&A discussing the many reasons for this, but a key cause of this is the belief that through great individual contributions we’ll see great team outcomes. And so, if you look at the incentives in most organisations, they are based purely on a per-individual basis. For example, an Engineer is rewarded for vastly different work to a Product Designer. The side-effect of this is that the members in a team are now working towards different goals and outcomes; if those goals do not align, we see a scenario in which teammates aren’t working together at all, and in the worst cases, are working against each other.
What key attributes have you seen most often characterize high performing teams?
Riz: Of the many I could pick, I feel that there are two complementary attributes which truly separate out the exceptional teams and the others: a shared purpose that everyone really believes in, and a drive for continuous improvement. A shared purpose opens the door to all the benefits we know about speaking with candor, asking for help and being vulnerable. For example, if we are teammates, but we have different roles, it could be tough for me to accept feedback from you, especially if that feedback is critical. However, if I know that we both believe in, and share, the same purpose, then I also understand that the feedback is given without ego or an ulterior motive.
And whilst many teams may feel that they have a shared purpose, very few will pair that with a real programme for continuous improvement. Much like Jeff Bezos’ “Day 1” mantra for Amazon, high performing teams do not let themselves fall into the trap of believing that they’re high performing. Instead, they always believe they can do better and strive to discover the next improvement they can make, no matter how small.
Software development tends to have many blind spots or invisible elements – after all it’s bits, not physical widgets. Yet most teams have classic and painful bottlenecks, such as in code review and QA. How can teams improve visibility on what their actual problems are?
Riz: I’m a big advocate for using cumulative flow diagrams (CFDs) to understand how work flows through a team and to identify where that process can be improved. Fortunately, getting started with this is fairly simple. Firstly, teams should map out every state a piece of work goes through from “Idea” to “Done”. If done correctly, teams will find that most work starts a long time before it ever reaches the development team. Consider the time spent scoping the work, prototyping it and producing designs ready for the team to build with.
Once this has been mapped out, comes the much easier second step - simply count how many items exist in each stage. As long as teams continue counting this regularly - I advocate for a daily count - the CFD will soon start to show trends. For example, an easy way to spot where bottlenecks is simply the stage in the process with the highest number of items. But a CFD can tell you a lot more: lead time, cycle time and throughput are other key metrics the team can look for and use to determine areas for improvement.
Concepts borrowed from Lean Manufacturing, such as small batches and just-in-time can be helpful in software development. However, physical manufacturing is predictable, homogenous and has low variability. Knowledge work is nothing but. What should software development teams model in order to increase the quality of their outcomes?
Riz: Scrum would have teams believe that the way to combat this variability is to strive for predictability; predictable Sprints are considered to be the gateway to a predictable cadence of delivery. It’s no surprise then, that under the illusion of predictability, we run our teams at nearly 100% capacity. And despite experiencing time after time that no two Sprints are alike, teams continue to put effort into striving to be more predictable.
The more fruitful approach is to set ourselves up to embrace variability. And, really, the only way to achieve this is to build slack into the way organisations plan their work. A good example is during quarterly planning: teams lay out items of work which they would expect to spend 8-10 weeks working on, and keep the remainder free to capitalise on opportunities which will almost certainly appear throughout. Such opportunities might come from changes in the market, new learnings from A/B tests or something more extreme, like a worldwide pandemic. But having that capacity to react to such changes is what allows teams to deliver quality and timely outcomes.
Early stage startups that find product-market fit and get a decent round of funding typically hit a wall when it comes to product development. Oftentimes, this is due to project management being mistaken for product management. How should companies effectively think about this shift?
Riz: Product Managers (PMs), for better or worse, tend to expand their responsibilities to fill the gaps left by those around them. And so, if a company is shifting from it’s early-stage startup mentality to one which now has funding and needs to mature, the shift needs to start with the leadership team. Leaders must understand which gaps they need to leave for their PMs to occupy, so that they and the business can thrive. To do this effectively, the role of the Product Manager needs to be understood. Unlike in Scrum, where Product Owners tend to be backlog administrators, PMs are charged with discovering valuable opportunities and defining the solutions to capitalise on them. As such, the company must allow PMs to explore the problem space, discover the right experience to offer customers and iterate their way to the optimal solutions. These tasks are very different to the world of project management, where critical paths, red-amber-green status updates and dependency management are the order of the day. That isn’t to say that project management is not useful; far from it, and I would suggest that if an organisation feels that this skill would be useful, that they go out and hire for someone who has a proven track record in project management, rather than expecting PMs to take this on too.
Teams that understand the economics of what they build (or don't build) are rare. For example, not many understand cost of delay, or opportunity cost. What are examples of things you've seen teams overlook and which end up hurting their outcomes?
Riz: A major one is understanding and framing debt, whether it’s technical, design or other debt. In teams where the presence of some debt is acknowledged, I see one of two things happen. In one scenario, engineers and designers lobby over a sustained period of time for attention to be given to a particular area of the codebase or user experience, and eventually, the business concedes. The bare minimum is done and then there is a return to business as usual, which is to say, a return to the same ways of working that built that debt to begin with.
Fortunately, not every team and organisation operates in this way, so a common alternative approach is to instead discover and scope upcoming product features, and then identify the debt which needs to be paid off to enable those plans. Whilst this sounds like a very sensible approach, it massively delays the business from reaping the value from those upcoming product features quickly, meaning the cost of delay starts to spiral.
Instead, I like to replace any talk of debt with the idea of building an advantage over the competition. Which is to say, if your codebase is healthier than that of others in the same market, then you’re much more likely to win. The same goes with debt that might exist in the design process, your sales process, your customer support function and so on. And the reason your business is more likely to win is because you’ll be able to act on insights with a much shorter lead time whilst also delivering updates to customers with consistent quality.