Interviewing our FailQonf Speaker Jeena James | Testing in Start-ups, Share the learned, Own Thinking

Jeena James

Each of our FailQonf Speakers has years of experience behind them and a crazy amount of knowledge acquired over those years. It would be bad on our part if we restrict their stories to only their FailQonf sessions. We are as eager as you all to know them and their journey better, and hence this Interview Series.

We had a few questions in mind for which we wished to get answers for, from all of them, and there were questions we designed based on the little research we did on their work and life. We enjoyed the process and now as we have the answers with us, we are enjoying it even more. We are sure you will enjoy this interview too.


In this Interview, I (Sayali Kulkarni) took the opportunity to ask our FailQonf Speaker Jeena James a few questions about Failures, Lessons learned, and a part of their amazing work in the Industry. We thank Jeena for their time to answer these, and for sharing a part of their life with us.

About Jeena James: Jeena James leads the WebPageTest business unit at Catchpoint (https://www.catchpoint.com), and drives the developer-focused efforts across product, engineering, marketing, partnerships, and operations. Jeena actively mentors and coaches working professionals, leaders, and startup founders. She holds a Bachelor of Science degree in Economics, Mathematics, and Statistics from St. Xavier’s College, Kolkata.

Linkedin | Twitter


Sayali: How do you usually inject a seriousness towards quality in the startups you mentor in a world where most startups see Testing as an Expense than an Investment?
Jeena: Questions I ask to understand where the startup or the company is at in their product and business lifecycle

  1. Understand what their company offers, and what stage of their growth they are in currently? And where they want to be 1 yr- 5 yrs 10yrs from now.
  2. Look at what customers are talking about their product/services (app store reviews, g2, product hunt, etc.). Check regional as well if it’s a global company.
  3. How is the team currently set up? What are the non-negotiables for the company?
  4. Who addresses customer issues? Are there plans to try and scale them as they get more users? What is their cost of solving an issue/bug in production? Could it have been detected before launch?
We then talk about our personal experiences with sites and apps and when something doesn’t work as they intended or is buggy. What was the cost of that personal experience, and did we keep going back to that buggy site or app or did we find an alternative? Think: What do you do?
 
Check if they’ve seen this data point or a variation of it (this one is from DeepSource) and discuss how they can set up a culture of testing throughout the SDLC and not just at one point and once. Another visual that helps is the Shift-left one to focus on testing at an early stage and throughout and not wait for your valuable users to be the ones complaining sending screenshots!
 
Testing in Start-ups
 
 
 
We discuss what tools and platforms are out there, and how to spot legit ones with the help of product-led and community-driven insights. Companies that focus on beyond just a pass or fail of a test but dig into some root causes behind the performance that they can then hand off to the other team with relevant information, see better and quicker resolutions in the long run. The conversations are mainly focused on how to build effective systems and not just a checklist of a one-time check before launching a feature, an update, or fixing a bug.
 

Sayali: Any experience you would want to share wherein you learned from someone’s failure and based on that lesson you actually avoided a similar failure at work?
Jeena: Sharing the learning first – If you are a leader of the project/team, then make sure you are clear and consistent about the goals for the team and work with the team to develop a strong execution plan. Help team members to connect their work to the goals and contributions. If you are a contributor to the project or own parts of it, you better ask a lot of questions to get clarity on the goals and help derive solutions. Why this goal, why now, why this approach, how can we make sure we meet the needs, etc.

I learned the impact a big decision not backed by a strong execution plan can have on someone’s career through an experience in Google India where my entire team was uprooted from one city to another for one reason – be closer to the decision-makers for the Indian market. Sounds straightforward but it really uprooted the morale of my team and me because there was no clear ‘how will we specifically grow our business’ conversation. There was also some level of uncertainty and mistrust with the leadership team because we weren’t candid or transparent with each other. We had a strong team of hard-working and amazing colleagues. Within a few months, most of the original team members quit.
 

With this experience, I made efforts to be extra communicative when it comes to rationales for big decisions and how we will attain our goals in light of or in spite of those decisions. I was able to apply this in my next role (yes, I too moved out of that team) when we had to take a big decision to either dissolve a team or build it up with the right goals and execution plan in place. I started putting together the business reason for why our platform was important for our customers, and how the level/quality of service can be revised or tiered, but not removed completely. I also started speaking about it consistently and showing data from customer calls, business growth, and direct + indirect impact on the main revenue product that our platform supported. One of our Directors paid attention to these and gave me the opportunity to build up the team and establish a sound business plan. We hired some of the most talented folks in the organization and that business has continued to thrive over the years. 

Don’t take something at face value because different folks have different motivations for making their decisions. Do your own thinking. 


Sayali: Have there been any failures that made your professional life better? Any lessons learned from the same.
Jeena: The word failure is a loaded word. We tend to use the word ‘failure’ more instead of just saying ‘I tried something and I failed at achieving my desired outcome this time.’ I’ve made plenty of small and large decisions along with my career and not achieved what I or the team was looking for. But each one helped me embrace the unknowns in a new project, or in a new team/company and improved the Quality and Speed of my decision-making. I weigh the intensity and impact of a project not completed, a goal not accomplished, or a milestone not covered by looking at: 

  1. Were the goals and objectives of the project set accurately? Were they clear to me, and my team members? Is it a top-down goal or is there room for bottoms up too? 
  2. Does everyone working on that project understand the role they play in achieving the outcomes we want individually and collectively? 
  3. Did we check on the status on a regular basis? Did we celebrate the small wins? 
  4. Did we pre-empt big issues and solve them before they hit our end users? See if 1 or more people could work together to mitigate these than placing the entire burden of an issue on say just 1 engineer. 
  5. How quickly did we make decisions and pivot when we faced unforeseen issues? 
  6. Did I create space for people to share feedback with me and/or the team on how we could do things better?
  7. Successful or not – did we do a good post-mortem of learnings about what we did well, and what we could have improved? 

Sayali: What is the most interesting failure you have experienced, which kicked hard, but once you learned from it you achieved double of what was expected in the next attempts?
Jeena:
Don’t look at the surface-level information, dig deeper. The data or the test you have may show you superficial results, but if you do a more holistic check, you may see inconsistencies and cracks. More importantly, if you have already made the decision to go forward with that data, then make sure you set up a stress test or pattern recognition so that you can pivot faster if and when things fail. 

During my career, I once made a decision based on what was on paper, and some hearsay experiences on growth and potential. I noticed some areas that were inconsistent but was so excited about the actual work my team and I were doing, that I missed seeing bigger issues creeping up. However, we managed to make the most of what we could do for the team and the business. I truly believe the lessons my team and I learned along that journey have helped shape where we are today, and hopefully spot potential fails miles ahead. 
 
Ever since that experience, I’ve made a conscious effort to seek and share direct communication and feedback, set up the right systems, and expect the same from folks we work with. As well as be open about actual outcomes and contributions. This pays dividends – I’m grateful to work at a kickass company like Catchpoint where the teams have already built strong systems, are transparent with our employees, and encourage open communication!  
 

We hope you enjoyed reading this amazing interview. Let us know your thoughts in the Comments section.

We can guarantee that you are going to enjoy FailQonf even more. Have yourself enrolled here if you have not done it so far. Please note there is a Free Pass option for the ones who cannot afford the Paid one in these difficult times. See you there.

About the Host:

Sayali is working with the iLink Digital, Pune as Senior Technical Specialist – Software Testing. She is a dedicated, passionate tester with a curious mind.

Linkedin | Twitter

Written by

Leave a Reply

Your email address will not be published.

Related Posts

Software Testing Courses at Thrive EdSchool

Advertisement (Know More)

Get Top Community News

    Top Event and other The Test Tribe updates to your Inbox.

     

    Categories

    Tags