Interview with Mosesraj R

‘How to drive excellence to business?’ This is one of the most discussed topics among leaders and managers today. We found insightful information to pave roadmap to achieve business excellence while interviewing Mosesraj R, Associate Vice-President, CIO and Head of Excellence, Brillio.

In our interview we spoke about current state of business Agility in India, challenges in building a quality-centric organization, and his mantras of driving excellence to business to mention a few.

Q1. How would you like to get introduced to the uninitiated? What motivates you to drive business excellence?

Moses:  I would like to be remembered as a person who said only what he did in reality.  So would like to be introduced as a person who strived to drive changes that improved life of people in an enterprise. Solving real world problems motivates me. I like to tell stories and inspire people to adopt to better practices and tools.

Q2. What is the current state business Agility in India as per your experiences?

Moses: Business Agility is definitely moving North. Newer technologies that offer faster development, intense competition coupled with Agile mindset is driving this for better.  Possibilities are numerous and so is openness to use technology to solve real world problems. However, there are still challenge in measuring value, moving at speed of business, architecture for Agility etc.

Q3. Please mention 3 major challenges in training and enabling people to improve capability of  organization, and build a quality-centric culture? How to address those challenges?

Moses: A motivated cohesive team is critical for success as a team.  It is not about Agile methodology but aligning the entire value chain to be Agile. In an IT services organization like ours, we have teams formed for every engagement that needs to start performing quickly and deal with a new set of business and client IT teams that add to the variability. This challenge is predominant in most IT services organization. There are no easy ways of addressing but this is what I have found it to work. Organize an Engineering team that would lead the customer in thinking and delivery. Engineering team is in the control of the IT services organization. Hence investing in them to structure them right, have right processes, tools and training helps them to build trust and take the customer partners along.

The second challenge I see is the value paradigm. How can we do work that changes lives of end users and not what they ask or perceived as a need. 42% of start-ups fail not because they aren’t Agile but because they developed products that are not the real need. Collectively we need to enable the team to measure value upfront. This challenge can only be addressed by elevating the role of product owner to understand ground realities and designing solutions.  This would mean, product owner should be able to get to root of reality, understand what really causes the barrier for users, stitch the technology solution, work with stakeholders who matter and build the solution. Upfront product owner should be able to qualify that real-world barriers are being broken with the new solution. Design thinking can come handy for product owners in this regard.

If I have to pick a third challenge, I suppose it is about the measurability of the engineering solution. “Left to itself things only decay is the principle of entropy. Similarly, aspects never measured and acted upon, will keep deteriorating”. Rolling ice gathers more mass. So is a product where holistic quality is not monitored. Brillio has developed a product called BOLT that helps the team visualize their entire progress, code quality, build quality. Functional quality in one window.  Most of these measurements are automated giving better confidence on measures. Training the teams to look through the solutions will help in developing great solutions.

Q4.How important it is to set challenges for a team as a Leader? Challenge vs Motivation, what’s your pick and why?

Moses: I think Challenge and Motivation go together. Without challenges it is difficult to motivate. Here is how I think motivation works.  When purpose is tall, challenges increase. Precious metals are found deep beneath the surface, so are taller purposes. Purposes like products with great UX, lightning speed delivery, amazing product performance, products that break real world barriers doesn’t come easy by any chance.  When the team connects themselves to these purposes, motivation is a given. It is important to help the team to win some battles. I would like to recount a recent incident. At Brillio we developed a product called “OnTheGo” to help people do most of their daily tasks in one click taking not more than 2 or 3 seconds.  In a townhall for one of the units, when the fresh entrants to the organization were asked to come up with a talk about what is good in the organization, they chose OnTheGo, the mobile app of the organization. When we came to know, the entire development team was sent to attend the event. This was a great motivation for the team as the development team was always challenged to make a difference to people through their solution. Sustained excellence always pays back.

Q5. As per your experiences of implementing Agile in Service/Product Company, what is one critical thing that Agile misses?

Moses: I suppose being focussed on value is the single most attribute of success of a product. Teams may get speed, adopt ceremonies well etc. but may end up not addressing the real need. Need drives everything. If the team can start experimenting to address the real need and figure out a success mantra early for their context, I suppose success is much higher.   

Q6. Share your 2 mantras to drive excellence to business?

Moses: Mantra 1 – Listen intensely to user problems/challenges and see through their words, the ground realities. Value is built by breaking real world barriers and not always by doing what people say or ask.

Mantra 2 – Excellence is never an accident. It has to be built, innovated and sustained.

Q7. What are the signs of poor alignment of team with business goals? How can we overcome such situations?

Moses: Siamese twins is one of the best story for alignment. When one of the twin suffers, the next invariably suffers. This is a good parallel for alignment. It is important to understand that lack of alignment is more felt in pain and the quickness of the pain being felt.  For example, if the users aren’t getting the value, how quick can the feedback reach the engineering team and the team does something about it. In general, do few things, design for value upfront and measure the value continually. Alignment is a logical outcome if this value paradigm is managed properly.

Q8. One thing you would like to advise the new generation of Change Agents, Agile Enthusiasts, and Business Leaders.

Moses: Design for value and measure value – embrace design thinking. To ensure increasing value delivery, look at the entire value chain, identify constraints and streamline continually.  You will make an impact.

 

 

Mosesraj heads Brillio’s IT and agile functions and has been instrumental in driving cloud adoption, modernization of infrastructure and driving excellence in software delivery. With 20 years of career experience, he has led multiple change management initiatives to drive better delivery to customers. Prior to Brillio, he has worked with Infosys Technologies and with MRF Tyres. He is a B.E. in Mechanical Engineering from Government College of Engineering, Salem and has a master’s degree M.S. in Software Systems from BITS.

Interview with Roman Pichler

Roman Pichler is one of the leading voices in Agile Product Management space, having expertise in digital products. He is an Author, Trainer & Consultant on Lean, Agile and Scrum. We interviewed Roman to know about his journey in Agile Product Management, myths about Product Owner’s role and what he wishes for Agile Community. Let us take you through our conversation covering varied topics;

Q1. To begin with, please tell us what inspired or motivated you to start your journey in the area of Agile Product Management? Why do you think it can make work better?

Roman: When I began working with product managers in 2001 while introducing Extreme Programming at a healthcare company, product and Agile seemed worlds apart. The product management practices I encountered were very old-school and waterfall. I had a similar experience when I taught Scrum to product managers at a telco company in 2004. Back then I thought that product management would have to be reinvented to take full advantage of an Agile way of working. Luckily, this turned out to be unnecessary. But I still think that the profession has tremendously changed over the last ten years influenced by Scrum, Lean Startup, and Business Model Generation.

Q2. How can one be a balanced Product Leader instead of being a Feature Broker or Product Dictator?

Roman: A balanced product leader is someone who actively listens to and collaborates with the stakeholders but is not afraid to make a decision when no agreement can be reached. To put it differently, a balanced leader is neither a feature broker nor a product dictator—neither a product person who relies on others to come up with ideas, mediates between different parties, and tries to broker a deal, nor someone who assumes that she or he knows best what needs to be done, makes all the product decisions, and expects others to fall in line.

Q3. Please share 5 myths about Product Owner’s role existing in today’s world. Why do you call them myths?

Roman: Here are some common mistakes I see people make;

1) The product owner is a tactical role responsible for managing the product backlog and working with the dev team. The strategic product decisions are made by someone else. The opposite is true in my mind: To maximise the value a product creates, product owners should lead the strategic and tactical product decisions, should be outward and inwards-facing.

2) A product owner is a type of project manager or team lead in Scrum. Product owners should manage their products, not the team and process. Agile development teams should be self-organising, and every product owner should have a qualified Scrum Master or coach at her/his side to support the team, teach the process, and facilitate organisational changes.

3) You become a product owner simply by attending a two-day training course. In reality, becoming a competent product owner is a learning journey that requires the individual to acquire and deepen a whole range of skills. This usually takes months and years, not days.

4) A product owner asks the stakeholders for requirements and gets the dev team to implement them. The opposite is true: Product owner and team are responsible for innovation. They regularly validate their ideas and collect user and stakeholder feedback and data on product increments.

5) A product owner owns any type of asset ranging from a product portfolio to a component. A product owner owns a product—an asset that creates value for a group of users and for the company. It therefore must create a user benefit or address a user problem, and it must generate one or more measurable business benefits. Individuals who own parts of a product like a feature or component, or who own a product portfolio should not be called product owners. This avoids confusion and create clarity about the core responsibility of a product owner and the required skills.

Q4. What are the challenges you faced while leading through shared goals? How did you overcome the challenges?

Roman: As the person in charge of a product, you are responsible for achieving product success. But to accomplish it, you usually rely on the help of the development team and stakeholders. At the same time, you can’t tell the individuals what to do, and you are typically not in a position to offer a bonus, pay rise, or other incentives. This raises the question of how you can align people. Part of the solution is to establish a set of shared goals—goals that people support and that help you progress your product.

The first trick with shared goals is to identify the right set of goals. I recommend using visionary, strategic, and tactical goals that are aligned and form a chain. The second trick is to get people’s buy-in. Important goals—typically visionary and strategic ones—should be agreed upon. This means that everybody is happy to support them without reservation. Establishing such goals takes time, and it can be tempting to shortcut the decision-making process, set the goal, and ask people to get on with it. But this often leads to lack of support and difficult discussions later on. In the worst case, people follow their own, unaligned goals.

Q5. What inspired you to gather your thoughts and write a book? Tell us one thing that you enjoy most while writing a book and what is the one most taxing thing?

Roman: Writing a book helps me reflect on my experience and consolidate my knowledge. At the same time, I hope that the readers will benefit from the contents! Before I started working on my last book Strategize, I felt that many product people lacked guidance on product strategy, and that there weren’t many books available that focused on strategy and roadmaps for digital products.

I really enjoy the creative act of writing. But working on a book can be challenging—just like any other bigger effort. There are difficult moments and setbacks such as slow progress, low motivation, an early review that indicates that more work is needed, to name just a few. These are great opportunities to learn and grow as a writer, product expert, and human being. But while experiencing these challenges, they don’t feel particularly pleasant, and initially I am not very grateful for the experience!

Q6. According to you, what is the current state of Business Agility and Agile Product Management across globe? How the future looks like?

Roman: I am not sure that my knowledge and experience is necessarily representative, but I think that many businesses still haven’t fully realised what Agile and product are all about. In the worst case, project managers are rebranded as product owners, groups of people are called squads, and there are now chapters and tribes.

But when you take a closer look, little has changed. The product owners are not empowered and don’t have the necessary skills; the organisation is still project-driven; and the teams are not cohesive, self-organising groups but collections of individuals.

Q7. Failure is an inevitable part of life. It is quite possible to fail while innovating. How can one cope up with failure and accept it?

Roman: The solution is to stop seeing failure as something bad, and embrace what some people call a growth mindset. Unfortunately, that’s easier said than done. I find that we can become very attached to success, to achieving and winning. Failure, then, is something we try to avoid, an unfortunate accident, rather than a mandatory part of the journey. But without failure, we don’t learn and grow—neither as individuals, nor as organisations.

Q8. Share 3 things you wish for Agile Community.

Roman: a) Kindness b) collaboration, and c) an open mind.

Q9. One question you think I should have asked you. Please answer that question too.

Roman: A question I often get asked is, how can someone working as a product owner or product manager be more empowered? While part of the answer is to get management support and possibly establish a product management function in the company, there are two things you can do on your own:

First, you can improve our expertise and acquire the relevant knowledge and skills. Knowledge is power as they say, and the more competent you are, the more likely are people to trust and follow you.

Second, you can increase our referent power, which is linked to how we are as a person. Being empathetic, kind, honest, patient, humble, acting with integrity and keeping an open mind will earn you the trust and respect of others. It will make it more likely that people will follow your guidance. What’s more, strengthening these qualities will make you a happier person too. How cool is that?

 

 

Roman Pichler is a leading product management expert specialised in digital products. He has 15 years experience in teaching product managers and product owners, and in helping companies improve their product management function. Roman is the author of the books Strategize and Agile Product Management with Scrum, and he writes a popular blog for product professionals.