Concluding the year 2023 with an exceptional and delightful vacation in Geilo, Norway, truly felt like a journey to a winter wonderland. The snow-covered landscapes, the crisp, cold air, and the overall magical atmosphere were breathtaking. This vacation will be one of my most cherished memories. Wishing everyone a Happy 2024 filled with joy, adventures, and wonderful moments!
On my trip to Geilo, Norway, I tried skiing for the first time and it was amazing. This article is not to share about my vacation, But I want to talk about how my experience is similar to the way companies focus on Product Lead, Engineering Lead, or partnerships Lead operations.
Scenario:
Four of us walked into the skiing area and found a spot where we could sit and get ready to ski, like putting on our ski boots and skis. I saw that one of the bench legs was broken, but it still held up just enough for us to sit and prepare for our skiing adventure.
With many kids, including mine, coming to enjoy skiing, I thought fixing the bench would be important. The repair was simple — just nailing a new wooden rod, something we could easily do with the toolkit in our car. I believed it was important to fix it to avoid any accidents from the broken bench leg. Although other benches were around, they were all occupied at the moment.
The first guy said, “Hey, we don’t need to fix this. There are other benches we can wait for. Let’s not waste time and energy in this cold.”
The second guy said, “We’re here to ski, not to fix benches. Let’s just manage with this broken one for now.”
The third guy said, “Sure, we could fix it, but if we use a new wooden rod, it won’t match the others in color. It might look a bit odd.”
Later, I was thinking about the situation and it came into my mind how we manage business and technical requirements in our projects.
It made me wonder if we just focus on the immediate tasks without considering the ‘now’, ‘next’, and ‘later’ aspects or impact if we ignore the problems or tech debt that we found, can our product truly evolve and grow as we intend, or will it struggle to progress in the future or will it lead to start from the scratch?
Software development organizations operate by product and engineering roadmaps, but in different ways of prioritizing requirements; such as;
- Engineering Lead Organization: Prioritize requirements under the engineering landscape.
- Product Lead Organization: Prioritize requirements under the product landscape.
- Partnership Lead Organization: Prioritize requirements between balancing both engineering and product landscape.
Engineering Lead Organization
Tech Lead/Architect: This bench is broken, I am going to fix it because I see a risk of accidents in the future.
Engineering Manager: Yes, that is true, it is a safety issue, what do you need from me?
The fix is done.
Product Manager: You guys spend the time fixing the bench, so we don’t have time to ski.
Product Lead Organization
Tech Lead/Architect: This bench is broken, should I fix it? because I see a risk of accidents in the future?
Product Owner: Sits in a proper bench and says “No, we need to get ready for skiing, but you go ahead and manage with a broken bench and get ready”
Engineering Manager: Hmm, fixing is good because it is a safety issue, but can we manage it for now or what is the impact? The Product Owner can decide what needs to be done.
or, Let’s get the fix for that added to our backlog and discuss further as we cannot ignore the safety issue.
Partnership Lead Organization
Tech Lead/Architect: This bench is broken, we should probably fix this soon because I see a risk of accidents in the future.
Engineering Manager: Agree that we cannot ignore safety issues. What are the options that we see here?
Product Owner: Assess the problem and say “This is not in our current plan, Is it really needed now?”
Tech Lead/Architect: Describe the impact and available solutions to fix the problem and also explain the technical debts if we go for a temporary fix.
more discussions going on, and conclude considering both product and business roadmaps.
What do we need?
Well, We need more teamwork and it is important because we will be lost somewhere down the line if everyone not going in the same direction and also, if everyone not going in the same phase.
Another important thing is that product and engineering will not always aligned and sometimes they are mutually exclusive. So the best way to go forward towards the end goal is collaboration. something more than that is each party needs to understand that;
Product requests WHAT and Engineering decides HOW.
I would say a partnership is a pleasant approach to a solution, but within the partnership, some methodologies provide some inconsistency, Because of that, it does not work as expected.
For example, in agile and scrum approaches, You can do whatever you want, This does not provide what is expected from a partnership when you do not have to take ownership or the responsibilities.
Shared Ownership/Responsibilities model
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master. — Scrum Guide 2020
The above is not true for me in product development, We need a catered approach to product development for better deliveries and scalable engineering solutions.
Why? Here it is simply.
In complex environments, what will happen is unknown. — Scrum Guide 2020
Only what has already happened may be used for forward-looking decision-making. — Scrum Guide 2020
Note: read more The Role of an Architects in Scrum: Collaborators, Stakeholders, and Visionaries
How?
It could be a 50/50 or 70/30 partnership model or a mix of them that we can decide on spring planning and refining. Because sometimes we need to cover the groundwork and base architecture for the scalable platform.
Now, how do we make both technical and product parties have areas of ownership?
My approach will be, to overlap the technical and product ownership. I believe it will not make a mess of confusion in your planned work. It is just to make a line between accountability and responsibility.
Let’s look back to our golden statement;
Product requests WHAT and Engineering decides HOW.
Implies that Engineering will be RESPONSIBLE and the Product will be ACCOUNTABLE for something.
What should engineering be responsible for?
- Laying the groundwork for a platform.
- Platform health.
- Security of the platform.
- Scalability, reliability, and extendibility of the platform, etc…
What should the product be accountable for?
Well, it is the PRODUCT itself.
We could split the ownership as below and both product and engineering parties need to respect each other’s roadmaps and collaborate towards it.
I have seen that product plans can go wrong when
Product managers make technical decisions or overlook technical issues. Unfortunately, top management often doesn’t realize this until it’s difficult to correct.
To address this, technical leadership and architects should proactively inform top management about these issues. To set things right, architects need to think ahead and consider both the product and business roadmaps.
And
Architects and Tech Leads are highly focused on technical aspects, often prioritizing technical excellence in their platforms or solutions. This focus can sometimes limit their flexibility in discussing with product owners to find a balanced approach.
To address this, it is beneficial for tech enthusiasts to participate in more workshops that align with business roadmaps. This will enable them to develop solutions that effectively balance the most critical requirements with those of lesser importance. If your organization is having agile coaches, they will have to do a job here to help teams.
You can read more about my thoughts here. Rethinking Agile: The Need for True Agility in Leadership
When everyone shares the responsibility for planning and doing tasks, things can get slow if the team isn’t working well together. It’s important to get everyone moving in the same direction and working together towards the same goal. In my next article, I’ll talk about how to do this.
Don’t forget to clap if this is useful or gives you some insights to improve your process of product development.