Throughout my career as a software developer I've seen many different ways of building products — from engineering driven to stakeholder driven, from well structured processes to no process at all, from large teams to solo efforts — and rarely does everything go smoothly.
I remember working at a company where the products followed well defined, periodical update cycles, and the team was very experienced with strong domain knowledge and knew the product well. On paper it all seemed like a well-oiled machine. Yet, there were always issues during development. The finger pointing as release dates approached was inevitable, and many times these issues weren’t one person’s fault, but rather the result of poor planning and poor execution.
Even these days, in a world where nearly every software company claims to follow some sort of agile approach, it’s still typical that features have to be rewritten to accommodate unforeseen scenarios or poorly thought out workflows.
A while back, soon after joining Rocket Insights, I worked on a project where I had an amazing experience. The product definition, design, and development worked in unison, amplifying what the individual efforts could produce. It was eye opening. For the first time I realized how dysfunctional such interactions generally are, and how accustomed many of us have become to being part of that mess.
As such, I thought I would share my thoughts on what I’ve seen that makes a difference. Maybe others can learn from this and hopefully improve the quality of their products while perhaps reducing development failures.
So, in keeping with the recipe metaphor, there are three "ingredients" I’d like to explore:
- The team: Designers, engineers, researchers.
- The managers: Product managers, project managers, product owners and stakeholders.
- The opening: Project setup and planning, from getting the team together and diving into the project details.
The Team
First and foremost, having the right team is essential. But, what is the right team?
When seen from afar — as my colleague Dave Witting recently wrote — a strong team composition is fundamental. Dave talks about three personality traits required for a team to be successful: people that can “make it up”, “make it real", and “make it reoccur”. When seen from a more personal level though, we can rescue other aspects that are sometimes ignored or overlooked when forming a team.
We often look for people that excel at what they do. We weigh seniority and domain experience very highly (as if having done something for a long time automatically makes one great at it) over other less tangible qualities like personality, eclecticism, communication skills, passion, and ability to collaborate with other team members. When talking about software development, I often say that knowing how to write code is only 25% of someone’s value in a team. It might seem slightly exaggerated, but I believe that curiosity, humility, a positive attitude, ability to listen, communicate, learn, and the willingness to adapt and go beyond the defined role, are the real key.
About ten years ago, I was leading a team with two other developers. Let’s call one of them Jon. He was a great guy, a nice person, had 15 to 20 years of experience as a software engineer and had worked for the top companies in the field. At the time, we were working on a secret project that would replace the backend for all the company’s existing products. The architecture we developed was different from what he had done in the past, and for some reason it never clicked for Jon. We spent weeks working together, trying to get on the same page. Yet, he ended up leaving the company. On paper, he had all the best qualities, but in practice he didn’t adapt to what the team needed.
Unless you are building something boring that’s well understood and has been done a million times before, it’s likely that there will be many surprises along the way. Most projects present unique situations, and while a framework or methodology might help with those, it won’t necessarily address the idiosyncrasies found in real life. It’s up to the team to turn these situations into opportunities which would otherwise be missed if the team doesn’t have flexibility, adaptability, and the correct disposition. Additionally, for a methodology to be successful, the team must have a deep understanding of the underlying reasons behind it. Only then can the team be able to adapt to a given situation instead of just following a recipe.
My approach as a member of a team is simple and consistent with how I see and approach any relationship:
- Be there – Always show up, and on time.
- Listen – Get to know the team, their views, needs, strengths, and weaknesses.
- Learn – Try to learn as much as possible about the project, the users, the motivations and goals.
- Communicate – Voice any ideas, thoughts, or concerns you may have.
- Trust – Do your part, and most importantly, trust that others will do theirs.
If each team member does this, and assuming the team composition is balanced, then things will flow smoothly and the team will be able to adapt to the many unforeseen situations that plague most projects.
The Managers
When you have a team with those qualities, and you can trust that they will do their part for the project to succeed, then it’s up to the managers to let the team do what they do best. How far would a top runner get with their feet tied together, or if they had to drag a heavy iron ball throughout their journey? A manager has these powers, and often — unknowingly — slows down progress and blocks otherwise good initiatives. There are plenty of articles and books about what makes a great manager and I do not intend to dive deep into the subject. Instead, I’d like to to point out how common it is for projects to fail not because of the team, but because of the fears, limitations, or carelessness of those that own or manage the project.
The best managers I’ve worked with are somewhat like phantoms — detached, selfless, always there but never in the way. They are always one step ahead, anticipating any potential needs but not imposing what they believe is needed. They never limit the pace or direction of a project by their own understanding. I see many parallels to parenting, and I’m of the view that there’s nothing stronger than building a great relationship of love and trust, after which everything else follows naturally.
At Rocket, we work on small teams that are self regulating and with little to no day-to-day management. We start with an amazing team that we trust, so there’s no need for guardrails or rigid processes, or managers that add overhead and hurdles that slow down progress and lower morale. We are there to enable the team to do their best and to serve as an external point of support if needed.
The Opening
Leading with an initial exploratory phase to any project can help the team have a shared understanding of the goals, the product, the users, and in general get a complete picture of the project at different levels. One of the common problems we see is that the team is stuck without clarity on what the first steps are to get to some end point. At Rocket, we try to always start with one or more Discovery, Design or Architecture Sprints, to help prioritize features and tasks. This allows the team to focus on what will have the most impact, validate a product or idea, and uncover different end user pain points.
The really cool thing about it is that one or two weeks are enough to prove if an idea is bound to fail, or at the very least reduce future surprises. I’ve been on a couple of Design Sprints where the outcome was not in line with the expected results. It’s tough to end on a dull note, but it’s also the best proof of the value these sprints provide. Additionally, it isn’t that a discrepancy between the expected outcome and the tests means the project is over, but rather that there’s more need for exploration, redefinition, and re-focusing of efforts before the build phase begins.
Besides the tangible and known benefits mentioned above, these early sprints can also help with team bonding and to improve trust and communication not only within the immediate team, but with the stakeholders too. This helps promote transparency and remove communication hurdles that can do more harm than good.
There is definitely a context where these sprints fit naturally, such as when a team is tasked with a new product or new feature, or when there are different players that must interact and coordinate to get something to happen. On the other hand, it seems less useful to do a Discovery Sprint when working on a stable product with a well defined process of incremental improvements and features, but the concepts behind it can go beyond proving the value of a product or idea. The sprint can take multiple forms depending on the project and team needs.
In some ways, this initial phase reflects Rocket’s interdisciplinary approach to building products. We’ve learned from performing hundreds of Design Sprints, extracting what’s valuable under different circumstances, and modifying the sprint to fit the specific project needs.
Bringing Everything Together
I believe you need all three of these ingredients for a project to be successful. The weakest link often weighs down the other two, reducing the potential of success. You might have a strong team and a great product, but the manager doesn’t let the team do their thing. In that case, the process will suffer and the development cycle will be long and painful. Or you may have a great team, great manager, and great product idea, but perhaps the idea is not fully developed. You can hope that everything will magically get solved during development because of the iterative approach. It might, but it might also take many iterations to get to learn that the initial premise was doomed.
There is no magic wand to turn ideas into success stories, but at least for the building phase, the thoughts above can be almost magical. At Rocket, we certainly don’t have the magic wand, but here’s what we do have: a focus on people — people that we like to work with and most importantly, people that we trust — and on enabling them to do their best. From there, everything else falls into place.
