Showing posts with label learning. Show all posts
Showing posts with label learning. Show all posts

Thursday, July 24, 2025

The spiral of overwhelm in leadership

I wanted to write this down because I’ve recently found myself in that familiar place again, the silent spiral that creeps in when I keep saying yes to everything that comes my way, lose sight of my priorities, and suddenly find myself face-to-face with the little monster - imposter syndrome.

This is my way of capturing the moment not to avoid it next time, but to remind myself to pause not to stop, but to reset. To be more self-aware, and to consciously choose how I respond when it happens again because I know it will.

Being in a leadership role often means being in the middle of many moving parts like  initiatives, priorities, actions, conversations and decision making. It can be quite fulfilling, but also extremely overwhelming. And sometimes, it’s not the workload that gets you it’s the way it spirals and creates the loop that you get stuck in.

What does that even mean?

You start with a clear focus and set of priorities. But as requests come in urgent things, people needing support, quick decisions, production incidents, you start saying yes naturally. You become reactive. One yes leads to another, and before you know it, you’re juggling too many things at once. Your WIP (work in progress) limit has long been crossed, but you’re still running without realising it.

This then leads to that all-too-familiar feeling of overwhelm. And when that settles in, it doesn’t stop there it comes in your way of your self-confidence. Suddenly, that quiet voice from that little monster in your head grows louder: “Am I making any real impact? Am I even doing a good job?”

It will create a lot of frustration because none of those doubts are true. But they still show up. And if you don’t catch the spiral early, it feeds itself. The more anxious you feel, the harder it is to think clearly or take a pause or to make the right decision.

So, what do you do when you catch yourself in this spiral?

For me, I’ve found a couple of things that help.

The first is my brag document a space where I regularly record wins, big and small. Sometimes I paste screenshots of kind messages, feedback, or things I’m proud of. When I start to spiral, I go back to it. It’s my gentle reminder: You’ve done great work. You’ve added value. You can do this again.

The second is something Katrina Clokie introduced me to which I'm excited to try: the idea of creating a rule book. I’m just getting started with this, but I love the intention behind it. Your rule book is a set of guiding principles for how you work especially when things get chaotic. So some of the rules that  I'm going to include in my personal rule book to start with are:

  • Don’t work on more than 3 things at a time
  • Practice saying no or not now regularly
  • Pause and reset when overwhelmed
  • Focus and revisit on the “why” of the task
  • Remember: not everything is urgent

These aren’t the only rules to follow, or the list might be different in some time or the list might grow as I start using it. And I know that it's more of a toolkit that I can use and come back to when I'm back in the sprial stiuation. It's useful to have such rulebook especially because when are you are stuck in those situations it's hard to think so having such pre written list as a rule book helps to refer back to.

I’m still learning how to hold space for myself during the overwhelming days. But I’ve come to believe that leadership isn’t about avoiding those moments — it’s about knowing how to pause, stop and reset.

This blog is for a reminder and a reference for myself.

What about you? What’s in your toolkit when you find yourself in these situations? I’d love to hear.

My First LeadDev LDX3 2025 Experience - Day 2

I finally had some time to reflect and capture my Day 2 highlights. The energy on Day 2 was just as energetic as it was for Day 1, but I decided to take things at a slightly slower pace intentionally.

I kept some time aside from my day to explore the sponsor booths and speak with the vendors. Many of the names were completely new to me, so I was curious to learn about them. Slowing down helped me absorb more. 



Leader or Engineer? Navigating Our Technical Identity Crisis by Marcus Gardiner

The first talk I attended on Day 2 was by Marcus Gardiner Technical Capabitity Head at Softwire, and wow this one really resonated with me. The theme of navigating identity between leadership and technical expertise is something I’ve constantly reflected on in my own journey as a quality engineering leader.

Marcus opened the talk with a series of thought-provoking questions that many of us have asked ourselves at some point:

  • Am I a leader or am I an engineer? Am I technical enough? Am I of value?
  • The best version of you as a leader means not meeting your full potential as an engineer. And the best version of you as an engineer means not meeting your full potential as a leader.

This really stuck with me. He explained that we often try to be everything at once, be it a technical expert, architect, team lead, business partner, and it does sound good, but it’s a one-way road to imposter syndrome and burnout. He spoke about the danger of drifting instead of deciding. When we don’t actively choose our path, we try to hold on to every identity we’ve ever had. But in doing so, we spread ourselves thin and lose clarity on who we want to become.

Marcus shared four different ways to be technical leaders:
  • engineer
  • architect
  • team lead
  • business partner

 

He mentioned that many might want to be all of these at once. It does sound great, but it's a one-way trip to imposter syndrome and burnout if you try to do everything.

One metaphor that Marcus shared was about how farmers in India dealt with monkeys raiding their crops. They’d drill holes in coconuts and place a banana inside. The monkey would reach in, grab the banana, but wouldn’t be able to pull its hand out while holding it. All it had to do was let go to escape—but it didn’t. It held on with a death grip and trapped itself.

“I was holding on to the comfort of my engineering title and knowledge, rather than embracing my new role.”

We all have deep-running insecurity about being “technical enough”. Many of us hold onto old versions of ourselves, whether that’s being ‘technical enough’ or feeling like we need to prove our value when in reality, letting go might be the key to growing into the roles we’re in now.

Marcus reminded us that our job title is just a temporary badge you’re wearing. It’s not who we are. It’s not the position we need to defend. And it's not permanent. It's not YOU.

What idea of your own self are you holding on to a little too tightly? The industry is still going to need expert leaders and expert engineers. Be part of or form a peer coaching group. Don’t hold onto your image of yourself with a death grip. 

View each new role as an experiment that you choose for your own values & reasons. It’s your story. 

And left us with this beautiful closing thought:

“Choose lightly. And then choose again.”

A truly powerful talk that gave me the space to pause and rethink how I see myself and the choices I make.

The million dollar bug: Quality leadership lessons from costly failures by Christine Pinto


This talk was special for many reasons, it was one of the very few testing related sessions at LeadDev, and it was delivered by Christine Pinto, someone I know and respect from the testing community. It felt refreshing to hear a topic that I'm passionate about being discussed on a leadership stage. 

Christine framed the talk as a four‑chapter journey:

  • Mythology: How faulty narratives undermine quality strategy
  • Mathematics: What quality actually costs and how those costs compound
  • Mechanisms: Practical frameworks that turn quality into competitive advantage
  • Metamorphosis: Why quality leadership isn’t a checklist, it’s a mindset

She began by challenging common myths that undermines quality efforts especially the belief that teams must choose between speed and quality. Using real-world examples, she showed how this mindset leads to reactive firefighting, where engineers are caught in patching loops instead of innovating. Rather than slowing teams down, quality should be the foundation that enables speed.


Next came the cost of quality and how invisible risks compound over time, draining momentum, trust, and innovation. Christine described how poor quality decisions often lead to a downward spiral, and once that begins, recovery becomes harder. It reinforced the idea that quality failures never stay small but from the chain reaction which can build up to the death spiral. No body wants to bet on a system that is constantly breaking . Now how do you break this loop so she went onto the chapter three

The third chapter focused on practical mechanisms to make quality visible and actionable. She explained how binary thinking like deciding if something is "ready or not" doesn’t work in complex systems. Instead, she introduced approaches like quality confidence matrices and risk-aware discussions that help teams evaluate impact and uncertainty early. Christine emphased on early conversations and reframing technical issues in ways that resonate with business leaders.

Christine emphasised that there is no need of a new process , there is a need to have better conversations earlier. and as quality leaders your role is not to answer all of these but to create the culture where peopple feel safe to ask them. It is about making risk visible because quality discussions die in translation.She gave brilliant examples , if you say oauth callback intermittenly fails for new users, it sounds like a testing ticket for a jira sprint but not for a leadership meeting. But if you say instead we are seeing a customer churn risk in onboarding , now your're on the boardromm , yourre talking about conversion growth. . Its not about exxagerating the situation but making it more relevant. Translate like a strrategist from tech framing to strategic framing. 



She also mentioned that while most companies only realise they are “on fire” after a post-mortem, the best teams run pre-mortems they surface potential risks before they become costly failures.


In the final chapter, Christine shared real transformation stories from companies like Spotify and Amazon. Each took a different path to scale quality whether through automation or team autonomy but the common thread was that they made quality a growth engine, not a bottleneck. These examples highlighted that there’s no single blueprint or playbook, but what matters most is embedding ownership and making quality a shared responsibility across the organisation.

This talk was a strong reminder that quality isn’t just a practice—it’s a mindset and a leadership responsibility. Christine ended the talk with closing statement of quality is speed and quality is your competitive advantage. It was inspiring to see this message land so clearly at a conference like LeadDev.

Theory to action: Architecting and implementing your team operating system by Meg Adams

Another brilliant talk from Day 2. Meg used a really helpful analogy of a team operating system something I hadn’t thought about in this way before.

She started with a problem that I’ve seen too: people often feel disconnected from what’s happening outside their own teams. Especially in cross-functional projects, it’s common to hear things like, “I don’t know what that team is working on.”

Meg had asked people how they might solve this visibility problem. They shared some great ideas:

  • More demos
  • Celebration forums
  • Personal relationships
  • Team rotations
  • Cross-team mentorship
  • Better alignment meetings

All of these ideas worked but not just because they were good on their own. They worked because they fit that team’s specific way of working, their structure, their people, and their culture. What worked for one team wouldn’t automatically work for another as it depends on context. That’s when Meg introduced the idea of the team operating system (OS).

She defined a system as a group of connected parts working toward a shared goal. A team OS is made up of people, structure, setting, and norms all working together, whether we design it or not. If we don’t design our OS, then one just forms on its own by default.

Meg gave us a great framework to document our current OS. She shared a template too (bit.ly/os-template), so we could look at our own teams and reflect honestly.

She walked us through each of the four parts of a team OS:

1. People

Every person brings their own background - communication style, habits, values, past experiences, even power dynamics. All of this shapes the team in different ways.

2. Structure

This is about how we spend our time and how we organise it. Are our calendars showing what we truly value? If we say we value learning or focus time but there’s no time blocked for it then we may not really value it in practice. Structure includes meetings, events, and business rhythms (like planning or reviews).

3. Setting

This includes our environment:

  • Physical (remote or office?)
  • Digital (Slack, Jira, Zoom, etc.)
  • Time zones and working hours
  • The energy or tone in the space

4. Norms

These are the rules we follow, both spoken and unspoken.
Some are written in onboarding docs. Others are learned just by watching how the team behaves. Meg encouraged us to observe without assumptions. Do people speak up when there’s a blocker? Is conflict welcomed or avoided? Who talks in meetings? Is it a safe space?

By writing these things down—not what we wish was happening, but what’s actually happening—we get a real snapshot of the team’s current OS. Not a big vision statement, just a clear picture of reality.

Meg then talked about how we can improve our team OS in three steps:

  • Act on small wins
  • Debug the real issues
  • Keep iterating and improving

She closed the talk with a powerful message: every team already has an operating system. The real question is did we design it, or did it just happen? To be true architects of our team culture, we need to start by documenting what exists today, and build from there.

This talk gave me so many practical ideas. More than that, it helped me see team dynamics as something we can shape intentionally not just react to.

That's a wrap on my reflections from Day 2 of LeadDev LDX3 a day filled with amazing talks, inspiring ideas, meaning conversaitons. Until next time, LeadDev!

Wednesday, June 18, 2025

My First LeadDev LDX3 2025 Experience - Day 1

 I’ve been trying to attend LeadDev for the last three years. I’ve submitted CFPs every time, hoping to be selected as a speaker, but it hasn’t happened yet. I’m not giving up, though; I’ll keep trying. This year, I finally got the chance to attend in person, and it felt special. Big thanks to CFC for making this happen.

As it was my first time attending LeadDev, I wanted to be well-prepared and make the most of the experience. Checked my travel route, laid out my notebook and favourite pen (yes, I still love handwritten notes!). The organisers had an app where I could plan my schedule in advance. That really helped me as it meant I didn’t have to make last-minute decisions during the day and could just focus on being present. I found that really useful. 

I spent some time looking up the talks and the speakers ahead of time and built my schedule based on what I was most interested in. The event had three main stages—Ways of Working, Organisational Leadership, and Technical Strategy. There was also a Solutions Stage with vendor demos, community spaces, office hours, and a chance to meet authors. I didn’t manage to attend everything, but I’ll share what I experienced.

🧡 The day started with a lovely catch-up with Christine Pinto. We’ve met before, but it’s always such a joy to connect in person, especially with someone who’s part of the quality community I deeply value.




Day 1 kicked off with the session I attended first: “How to Keep Everyone Happy (on a Shoestring)?” by Neslihan Şirin Saygılı.

Neslihan shared her journey managing teams without formal management training, facing many real-world constraints: limited budget, limited headcount, limited time, limited life and the added pressure when C-level executives want Friday launches. She described these as “dominoes vs avalanches,” highlighting how small issues can cascade into bigger crises if not managed well.

Her approach starts with taking a wide view. She created a “happiness sparse matrix”. She also talked about “rotating priorities” like pizza trade-offs where each sprint prioritises a different team’s needs, with a “time currency” paid upfront(people respected the fairness)



A bigger perspective came from framing the challenge as a “constraint satisfaction problem,” one without a perfect numerical solution but solvable through heuristics and teamwork. She reminded us it’s okay to have “good enough” plans, It's better to be 70% right today than than 100% right too late. Keep the stakeholders informed all the time.

Her practical advice included focusing on root causes, not blaming individuals, and fixo ne thing fully, not 10 things badly. Keep the big picture, don't let the crisis blind you to the others. She encouraged establishing some principles like casual coffee breaks, sharing credit, listening, being accessible, and supporting personal growth through books and side projects to keep the “emotional bank account” topped up.

Quote from Regina Phalange:

“Our experiences are similar in pattern but unique in detail. I believe we need tailored solutions.”

Managing tech crisis on a shoestring isn’t about being a hero, but being a human.

What resonated most with me was how much this isn’t about having all the answers or being perfect. It’s about understanding the real, messy challenges teams face every day and finding practical, human ways to navigate them and you don't have to do it alone, find help!

The next session I attended was “Better Software, Faster” by Laura Tacho.

Laura opened strong with a clear message: “We need to think about using AI on an organisational level to see the organisational benefits.” She quickly made it clear that AI isn’t about producing more lines of code—because we already know lines of code aren’t a meaningful measure. Instead, it’s about improving the developer experience.

She described how many leaders right now are sitting in a “disappointment gap”—expecting AI to replace engineers or bring instant transformation, but the reality doesn’t match the hype. That contrast was summed up with humour: “The milk is actually shaving cream,” which got a good laugh in the room.

This hype around AI is the biggest barrier for adoption. Engineers might even start seeing it as competition, which only builds more resistance. But as Laura pointed out: data beats hype—every time. Leaders need to set realistic expectations about what AI can and can’t do, and be able to explain those clearly to boards, execs, and development teams alike. While AI can be transformative, that’s not what most companies are seeing in their day-to-day work—yet.

Quote from Brian Houck (SPACE framework co-author):
“The hype around AI is in many ways the biggest barrier for adoption.”

She shared stats showing that advanced organisations in the top quartile have about 60% adoption of AI tools on a daily or weekly basis—but there’s still a huge gap between them and the rest. Laura stressed that if you invest the effort and resources into AI adoption, usage will go up. The average reported time savings is already about 3 hours and 45 minutes per developer per week in the first half of 2025.

Still, she was honest about how hard it is to lead in this space right now. The landscape is evolving rapidly, and many leaders feel like they’re constantly guessing. But we’re not alone in that. Laura wants to equip us to show up with clarity and confidence, especially when it comes to separating hype from what’s actually happening.

She reminded us that we have a hard job to do as organisational leaders. Our role and responsibility is to educate around the hype. It’s easy to get distracted by shiny new tools, but when leadership asks “what are we doing with AI?” — we need to have a clear, honest answer. And when we ask “what does it actually take to build better software?” — the answer isn’t just writing code faster. It’s making sure the code is reliable, maintainable, and valuable.

Laura outlined two things we need to do this well:

  1. A common definition of engineering performance
  2. Clarity on how AI is influencing that performance

We also need AI-specific measures, not just the usual engineering metrics.

Despite all the newness, she reminded us that the fundamentals of software delivery still hold—collaboration, fast time to market, quality, reliability, and security. AI might help accelerate delivery, but without care, it can also accelerate the wrong things. We need to protect our organisations from delayed damage, like producing more poor-quality code, faster.

One big takeaway for me was around aligning the organisation on a shared definition of excellence. Laura introduced DX Core 4, a framework developed by people like Abi Noda and Dr. Nicole Forsgren (from the DORA team), which has already been used by hundreds of companies. It’s been battle-tested, and it shows that Developer Experience (DX) is one of the biggest levers we have to improve engineering performance.

She shared that around 20% of developer time is lost to friction from inefficient tools and poor internal systems. Since time is such a scarce commodity, mapping DX improvements back to saved time and recovered salary makes a solid business case for investing in better developer experience. Biggest wins for utilisation is going from non-using to using AI. Top metric to track in terms of Impact = time savings per week.  AI Measurement Framework = Utilization + Impact + Cost.

As Azra from Block put it:
“These improvements helped us move faster without sacrificing quality or focus.”

Laura wrapped up by debuting an AI Measurement FrameworkThis session was a real eye-opener. It helped me see how, as leaders, we need to take ownership not just of tools and tech, but of the narrative around them. 

Sunday, December 1, 2024

Reflecting on November of Hosting, Speaking, and Connecting

I don’t generally write monthly reviews, but this time I wanted to share about four events from November so I  thought of capturing everything in one place. This post is more of a personal journal to look back on later.  Normally, I share updates about the events I attend or speak through LinkedIn, but I thought it would be a good to compile everything into a blog. 

1. Final Internal Quality Community Event

On November 13th, I hosted the final internal quality community event of the year at my company. Our guest speaker was Jakub Cagiel, who delivered an insightful talk on Quality at Atlassian. Jakub shared Atlassian's approach to quality and their journey to achieve it, focusing on processes that empower developers to own and build quality effectively. Highly recommend this talk, Jakub was an absolutely fantastic speaker. 

This was the sixth event I organized this year as part of our internal quality community at CFC. Here’s a recap of the other incredible sessions. I'm so grateful to all the speakers who agreed to speak.

I enjoyed hosting these events and am very grateful to my colleagues who attended that kept me motivated to continue organizing these sessions. I look forward to continuing these events next year as part of our internal quality community

2. Women in Silicon Roundabout

On November 28th, I attended and spoke at the Women in Silicon Roundabout London conference for the first time. My session, on “Elevate Your Career Through the Power of Networking and Personal Branding,” shared my journey into public speaking and how mentors like Angie Jones and Maaret Pyhäjärvi helped me in my speaking journey. I talked about how I initially had no awareness of testing communities and had never attended a conference. Now, I am involved in several communities and have the opportunity to speak at conferences. I shared about TestBash Brighton 2019 being my first conference and the first community I was introduced to.

In today’s world where layoffs, redundancies and uncertainty, personal branding and networking have more relevant than ever. Watch these short video clips by Kelsey Hightower on how everyone has a personal brand  and Angies Jones on networking

I shared actionable tips and stories about how these skills can open new doors, help you stand out, and elevate your career. 

The audience engagement was excellent, with a full house of 340 participants attending the session. I’m always happy to present this talk at meetups, conferences, or internal events. If you’d like me to present this session to your organization or event, feel free to reach out on LinkedIn.


3. Ministry of Testing Panel

It was an honour to join Jitesh Gosai and  Barry Ehigiator as a panellist on The Testing Planet’s discussion on why shifting left isn’t enough hosted by Gwen Diagram. We kicked started by answering the first question 

What are the limitations of shift-left testing?

For me, when we talk about shifting testing to the left, it often leads to the misinterpretation that it's solely about automating early or starting testing sooner. This perspective can miss the importance of a shift-right approach or a more holistic view. 

 It was an engaging conversation where we explored the challenges of shift-left testing, balancing speed with quality, and identifying gaps in current testing practices. Have a read at this post by Jitesh who has written a detailed summary on the testing planet event here

If you missed it, don’t worry, Testing Planet sessions are available on-demand. Thanks to Ministry of Testing for organising this.

4. The Test Tribe London Meetup

On November 29th, I hosted the second Test Tribe London Meetup. Even though we were a smaller group of 16 people, it was a wonderful evening of meaningful interactions and learning. The first one was hosted on 25th September where Simon Prior gave a talk on "Testing SaaS - Quality in a "Buy not Build" World". 

The Test Tribe community is organizing events in various cities, and when they reached me to help host a meetup in London, I agreed to it. I had never hosted any external events like this before, so I wanted to contribute to the community in a new way. It was an exciting opportunity to be involved being on the other side. We had two amazing speakers for the second meetup:

Lewis even gave away a signed copy of his book to a participant who asked a great question during the Q&A! Lots of discussions over pizza and networking. There will be more meetups by The Test Tribe London Meetup in 2025, so keep an eye out for that.

November was a month of events, from organizing internal events to speaking at conferences and hosting meetups, it was a month filled with opportunities to learn, share, grow, contribute and give back to the community. Apart from these events, I got an opportunity to contribute to Anne-Marie Charret's November Newsletter on Quality Coach Book on the topic of  "Building Cross-Functional expertise in a team"

If you attended any of these events or found the topics interesting, I’d love to hear your thoughts! 

Saturday, December 31, 2022

A Year In Review - 2022

 

It's the time of the year to look back and reflect on what happened during the year 2022. It's not just about reflecting back on growth and success but also to look back at the challenges and various different decisions that helped me to grow throughout this year. The common theme for me this year has been - "Getting out of comfort zone".  I have been doing so many things that were absolutely out of my comfort zone throughout this year and it has definitely helped me to grow in many ways and to learn about my ownself.

  • The year started with settling in at thoughtworks and the project that I was working on. It was a complete new experience to work on such a huge product with 12+ cross functional teams. Initially I was totally lost to get to know so many teams and to understand where I need to focus on. Slowly I got into the flow and focused more on my team and the area of the product that our team owned. I was the only tester on the team, I took this as an opportunity to coach, mentor and influence my team all about quality and testing. The goal was to enable the team so I don't become the bottleneck and be the only person to test the stories/features. It was slow and challenging process of months but it was worth it. I was focusing so much more on the whole holistic testing and all types of testing that was required. Running workshops, organising knowledge sharing sessions, pairing with all different roles and creating a community space for observability are just few of the highlights to mention. So much more that I was able to do and deliver on this team.
  • I wanted to have all my focus on the work I was doing on the team so I had to say no to few conference speaking opportunities which was not easy to say no to but had to. I got an opportunity to speak at XConf Europe in July which was a thoughworks organised conference. This was my first in person conferece since the last one being in 2019. Absolutely new experience of presenting the same talk at 3 different locations in 3 days with Day 1 at Stuttgart, Germany, Day 2 - Manchester, London, Day 3 - Madrid. Here's the link to all the recordings - link and a link to my talk - A Peek into observability from tester's lens.

  •  One of the absosolute hightlight of the year was being invited for a keynote, a dream, a goal that was on my list.

  •  While preparing and working on my keynote since I came to know I'll be delivering a keynote in November , I also started working on a new project which was completely backend and api focused. It was yet again absolutely different experience to work on such project. It was hard to leave the previous team and project that I was working on but I guess that's how a consultants life is going to be like. I was sad to leave my old team but at the same time I was happy and excited to work on the new project with all new challenges. 
  • Finally the time came to deliver my first ever keynote AgileTD Potsdam in November, a very very special one in many ways. A huge thank you to José Díaz who believed in me and entire AgileTD team. I talked about influencing skills, how they can help us build the quality within the teams and  how to develop those skills. Infact more than what I mentioned here, a story of my own experiences. Here's the sneak peek of my keynote on these sketchnotes
    • Sketchnote by Lisi Hocke - Link
    • Sketchnote by Eveline Moolenaars - Link
  • Special thanks and mention to Tristan Lombard and Helen Scott who have helped me throughout this journey of keynote. They have constantly supported and motivated me by continuous feedback from the idea generation phase to dry runs. I am forever thankful to both  💖. A huge thanks to Lisa Crispin for helping me through dry runs and feedbacks. Thank you to Lisi Hocke, Samuel Nitsche and Vera Baum for helping me with your valuable feedback and dry runs that helped me in delivering my keynote. Apart from being a keynote speaker, it was so great to meet Toyer, Marie Drake, Emna Aydi and many more for the first time in person. 
  • I also mentored and met so many people through mentoring platforms like  Mentoring Club and ADPList
  • I got an apportunity to be an AWS Community Builder and was also invited by Manoj Kumar to be a LambdaTest Spartan which I'm so looking forward to contribute and learn from this community. I was also invited to be on a panel by Lambda Test which was a great chance to meet few Spartan's - Link to the panel recording
  • Towards the end of year I started giving more importance to my own health by making sure I do some kind of workout atleast twice a week and eat healthy which I'm going to take this forward for the next year too. 

Few things for 2023 

  • I'm hoping to present the same keynote or even a new keynote talk at any other conference this year. 
  • I want to try my hands with running a workshop as my next goal.
  • I also want to write and share consistently which I have not been doing since last 2 years and I really want to get back on this If I can. 
  • I want to work on being more technically confident tester(If there's anyone who would like to pair with me on this or someone who is looking for an accountability partner please reach me out as I would love to have someone). 
  • I want to focus on improving my existing skills and want to learn new skills.

I'm excited for the next year and thanks for reading this post. Wishing you all a very happy new year 2023!

Monday, January 4, 2021

Reflecting on Year 2020

⚠️ Content warning: This blog contains mention of death 

 The year 2020 - A year filled with a lot of uncertainties, learned whole new definition of being adaptable to the changes, surprises which were both good and bad, a year of learning about all new fears. Year 2020 to me has meant all about empathy and humanity. It's been a mixed year which has entirely changed the way I look at life and the impact has been real.

This year had been a real toll in terms of mental health and adapting to the new way of living with a lot of unexpected situations to face. I almost decided not to write anything about reflecting on this year. But I decided to do it. This is my first blog post in the last 6 months. 

The year started with a lot of excitement and goals that I wanted to achieve. A lot of planning and passion went in for what I wanted to achieve and learn while I was on my Testing Tour. Setting out on Testing Tour was not just about learning topics and sharing but it was more of getting out of my comfort zone. I am so glad I took the courage to do it and it proved to be worth it. I met known and new people from across the world which was an amazing experience. 

I got introduced to the whole new topic of Observability or O11y where Abby Bangser and Shelby Spees has helped me in a way that got me hands-on with so much better understanding and clarity about this topic. Shared my learnings from Testing Tour and Observability at multiple conferences

 I lived in fear since I came to know about Covid-19, fear for my family who live with me and who lived back home in India. I have seen Covid effect really closely. Three of my loved ones caught it one after the other. First my Mom, then my Dad and then my brother. In this battle, I lost my Dad who was my inspiration and role model. This hit me so hard that I'm still trying to recover to come out of that loss and pain 😢 which is never going to heal. These were one of the toughest days I have ever faced.

I still wanted to look back and reflect on the good things that happened to me. 

  • Went on Testing Tour and had 15 different sessions on 15 different topics and blogged about each of those sessions. 
  • I learned about a lot more new topics and tried my hands-on with new tools. I learned about Observability, Performance testing using Jmeter, Microsoft Azure and lot more. 
  • I got an opportunity to be part of Observability for testers series organized by Anne-Marie Charrett along with Lisa Crispin and  Abby Bangser which was a great opportunity to learn and explore more about observability.

  • I gained 1076 followers crossing 1000k followers on  Twitter which for me is a huge number. 
  • I learned to listen to my mental health and say no to few of the opportunities. I had to prioritise myself over other things which I struggled initially but gradually learned that it's absolutely ok to stop and take a break to take care of yourself. 
  • When the entire world went remote, initially I was happy that I will get to work from home but gradually it became challenging to work from home with two kids around as they had their virtual school sessions. Throughout this process, I learnt not to feel guilty for not being able to give full attention to both my kids while they are on their virtual school sessions. Learnt to be patient and adapt to each day as it comes. 
  • Our testing community is not just to learn and share about all things testing but it proved to be supportive during my difficult times which I'm so thankful for. 

Reflecting on all these gave me so much happiness, confidence and pleasure 💫😇. It's always good to look back and see what you have been doing or learning on the way. Looking forward for year 2021 with an attitude of being grateful for what I have. Thanks for your time for stopping by and reading my post 🙂

 

Thursday, June 25, 2020

Observability for Testers : #Session 2

Exciting to be starting the second session of learning "Observability for Testers" 😎. We all were super excited as we had our instances on AWS ready from our previous session. Now that we have our instance it was ready for setting up the DIMA app on it which was one of the main goals for this session. 

The DIMA app is a web app which is built on a microservices architecture. This app allows to upload, display, manipulate and delete the images. This stack also includes the monitoring and observability tool like Kibana, Grafana, Prometheus and Honeycomb. Now that we know a little bit about the app let's start to understand what a microservices architecture is before we get deep dive into the DIMA app architecture. 

Microservices:

I had to give a short introduction about the microservices architecture to everyone. I picked up an easier analogy as an example to give an introduction to microservices architecture. This blogpost seemed to be very helpful that explains very well about introducing this term to someone completely new to this terminology. When I started to learn about microservices I read a lot of blogs by Martin Fowler. 

"Microservices architecture is an architectural style that structures an application as a collection of services. That are highly maintainable, testable, independently deployable and loosely coupled."
                                                                                                                                     
The above definition is from microservices.io. Let's consider an example of a university portal where they have different sections for undergraduate study, postgraduate study, International students, Jobs and courses which serves its own purposes. We can consider these different sections as a simple microservice that serves the business logic and functionality. When we think of building a new feature related to courses or jobs or even maybe for International students, it becomes easier to think of each service and build the functionality for the specific service. Of course, this definitely introduces complexity when we look for testing this as a single service and testing the integration of all these services. Because it doesn't matter whether its a monolith or a microservice or any other type of architecture, for the users it's a single application which they want to use it with ease. 
Few of the examples who use microservices are Netflix, Amazon and eBay. 


Image from https://martinfowler.com/articles/microservices.html
Image from https://martinfowler.com/articles/microservices.htmlAdd caption

Now that we went through a basic understanding of microservices, here's how the structure of DIMA app looks like. Here are the images of architecture and infrastructure took from Abby's GitHub repo.

 Architecture


We can see here there are different services including the GUI and the database : 

  • GUI
  • MongoDB
  • Image Orchestrator
  • Image Holder
  • Image Thumbnail
  • Image flip
  • Image Grayscale
  • Image Size
  • Image Rotator



With all these different services, we need to find out where the problem is so we can figure out what the problem is. So having monitoring and observability tools in place will help anyone to debug the issue. 

After having a little exposure to the architecture and stack we followed the instructions to set up the DIMA  app stack on our instances so we can then trigger requests by adding/deleting/manipulating images and then exploring the logs and traces. 

It was really very helpful to have an understanding of the architecture of the app as it will be helpful while we are looking at the traces or logs and we could see the requests from different services. 
Super looking for the next session as we will get to explore more about logging, tracing and metrics.

Monday, June 8, 2020

Observability for Testers : #Session 1

We all joined this session from different time zones and we were 10 people. The main objective of this session was to build an AWS instance that could be used to build the observability stack created by Abby & Co.  This had a DIMA app which has the capability for uploading, deleting or altering the images. This app is built on microservices architecture which also includes other tools which provided logging, tracing and monitoring. Those tools are Kibana, Grafana, Prometheus, Zipkin and Honeycomb. 

Steps we followed : 


  • The next step was to create IAM user. Identity and Access Management(IAM) enables you to manage access to AWS services and resources securely. Using IAM, we can create and manage AWS users and use permissions to allow and deny their access to AWS resources. An IAM user with admin permissions is not the same thing as the AWS account root user. We need to follow 4 steps to create this user. 
Step 1
Step 1

Step 2

Step 3

Step 3 is optional, we could add the tags and use that as an identifier. It helps keep track of how the resources are being used. It also helps to organize, track or even control the access fo the user. And step 4 is to review the information added and then create the user. 

  • Install docker-machine. Docker machines allow us to create Docker hosts on cloud providers like Azure or AWS. I'm using windows so I used the following command by going to Git Bash. If you using Mac then follow this link for the right command -  https://docs.docker.com/machine/install-machine/


Learning as a group was a very collaborative and fun way to learn, share and tackle the challenges along. After having this session I'm already looking forward to the next session to go through the next steps.