Wednesday, April 22, 2026

Fix the Problem, Not the Person

 What if the problem is not the person—but the way we are seeing them?

Once, I was taking a session for a group of women employees working in an IT firm. We were discussing the practical challenges they face while leading teams.

One team lead shared a concern. She said one of her team members consistently delayed work, resisted changes, and was not open to the solutions she proposed.

I asked her what she thought was the reason behind his behavior.

She said, “He is older than me, and I feel he doesn’t like working under a woman leader.”

I paused for a moment.

While this is a concern that many women leaders bring up in workplaces, I usually don’t go with the first explanation that comes up. Not because it is invalid but because I want them to find clarity before arriving at a conclusion. At the same time, I also want to ensure we don’t label people based on generalized beliefs.

So I asked her, “Do you have any evidence that he dislikes working under you? Has he said it directly, or have you heard it from someone?”

She said no. She added that from his body language, she felt it.

I gently explored that further.

Sometimes, when a person avoids eye contact, leans back, or responds with minimal words, it can appear as disinterest or resistance. But those same cues could also mean something else—lack of clarity, disengagement from the task, or even personal stress.

Body language can give us signals—but it doesn’t always reveal the full story.

For a conclusion, we need patterns, conversations, and supporting incidents.

So I asked her again, “Can you recall any specific incident that clearly points to this?”

She paused. Thought for a while. And then said, “No… but he delays work and resists my ideas.”

I asked, “Then how did this thought come in?”

She said, “I was discussing this with a few friends, and they mentioned that generally men don’t prefer working under women leaders. And I started noticing his expressions more from that lens.”

That was the moment.

It wasn’t a fact. It was an interpretation—shaped by external opinions and reinforced by selective observation.

And once we label the person, we stop looking at the problem.

We don’t just see the person—we see them through a lens we have already created.

So the shift is not always to change the person—but to change the lens through which we are looking.

From there, we moved the conversation toward the problem itself.

If the issue is delay—have a one-on-one conversation to understand the reason behind it.

If the issue is resistance—ask for his perspective. What does he think would work better? Discuss the pros and risks together.

And if the behavior continues, move from assumptions to structure.

Create a simple framework for the team:
Clear task allocation
Defined timelines
Regular follow-ups
A transparent escalation process

And just as important—acknowledge completion.

A simple appreciation message or email when work is delivered on time creates balance. It reinforces what is working—not just what is not.

When appreciation and escalation both exist within a system, feedback stops feeling personal. It becomes part of a process.

So even when you escalate, it is not seen as an attack on the person—but as a response to the problem.

Because in the workplace, we cannot always change people.

But we can change how we understand, approach, and respond to situations.

The moment we label a person, we limit our ability to solve the problem.

But when we shift our focus to the situation, we open up possibilities.

So the next time something feels difficult, pause.

Ask yourself

Am I trying to fix the person? Or am I trying to understand the problem?

Because clarity begins not in changing others

But in changing the way we see.


Thursday, April 16, 2026

From Technology Leadership to Supporting Mid-Career Women

Over the years, while working in technology and leading complex programs, I noticed something that stayed with me. Many capable women in mid-career were doing solid work, delivering results, and carrying significant responsibilities — yet they often felt unseen or unsure of their next step. It wasn’t about lack of capability.

Often it was a mix of things: 

• years of pressure slowly affecting confidence 

• communication that didn’t fully reflect their capability

• navigating workplaces where visibility matters as much as performance. 

Alongside my corporate journey, my long association with Toastmasters and my interest in psychology, mindfulness, and coaching made me reflect deeply on how inner clarity and professional presence shape leadership growth.

Over time, this led me to bring these threads together — supporting mid-career women in rediscovering confidence, strengthening leadership presence, and navigating career transitions with greater clarity. In this space, I’ll be sharing reflections from corporate life, communication, leadership development, and the inner work that often goes unseen. Looking forward to the conversations ahead.


 

Monday, April 6, 2026

Revisiting ControlAltConstruct: From Coding to Coaching

 “Sometimes, the things we start quietly end up shaping who we become.”

I started this blog years ago as a simple space to document my learnings  from the IT industry, technical experiences, problem-solving, and the work I was doing day to day. There was no larger plan. Just a quiet intention to write and reflect.

The name ControlAltConstruct came from a simple thought. While “Control Alt Delete” is about resetting, I was always more drawn to building—reconstructing, rethinking, and creating something new from what already exists. That idea stayed with me, even as my journey evolved.

When I started my career, my focus was clear—learn, build, deliver. As a developer, I worked on backend systems, UI, and solving technical problems. But over time, I found myself thinking beyond execution. I was more curious about why things worked—or didn’t.

I began to notice that many challenges weren’t purely technical.
Delays weren’t just timelines.
Misalignment wasn’t just requirements.
Conflicts weren’t just processes.

There was always something deeper—people, communication, and context.

This curiosity led me to explore roles beyond development—into consulting, product coordination, and solution architecture. Along the way, a mentor introduced me to StrengthsFinder, which helped me see that my strengths lay not just in building systems, but in connecting ideas and people.

That insight shaped my path toward program management, where I eventually moved into a Senior Program Manager role.

And then, as life often does, priorities shifted—and writing paused.

Recently, I revisited my blog—not just to read, but to reconnect. What once started as a technical journal had quietly become a reflection of my thinking journey.

Today, my work has evolved further into coaching, training, and working closely with people, behavior, and growth. And it doesn’t feel like a departure from my past—it feels like a continuation.

The same curiosity that once asked, “How does this system work?” now asks,
“How do people think, respond, and grow within systems?”

Coming back to this space is not about starting over.
It is about continuing—with more clarity and intention.

This blog may not follow a single theme anymore. It will reflect real experiences, observations, and insights from both systems and people.

Because growth isn’t always about doing something entirely new.
Sometimes, it’s about revisiting what we already know—and seeing it differently.

This space is not about resetting.
It is about reconstructing.

And this time, I’m choosing to do it consciously.

When was the last time you went back to something you had left behind—and saw it differently?

Wednesday, July 10, 2019

AWS vs. Azure vs. Google: What’s Best for You?




AWS pros and cons

                   As mentioned before, the reasons for picking one vendor over another will differ for each customer. But there are aspects of the competing clouds that will offer benefits in certain circumstances.The breadth and depth of the AWS offering is seen as a plus for AWS.

AWS had a head start on the competition, building out its suite of cloud services since 2006. All of these are built to be enterprise-friendly so that they will appeal to CIOs as well as its core audience of developers.The vendor ranks highly on platform configuration options, monitoring and policy features, security and reliability. Its partner ecosystem and general product strategy are also seen as market leading, and its AWS Marketplace has a large number of third-party software services.

Another of the benefits of the AWS cloud is its openness and flexibility. For example, Transport for London - which also relies on Azure in other parts of its operations - has used AWS to meet spikes in demand for its online services such as its Journey Planner tool.However, one area AWS falls short to some degree is with its hybrid cloud strategy. Unlike Microsoft, AWS has tended to be dismissive of the benefits of on-premise private clouds. Many organisations prefer to keep sensitive data within their own data centres - such as those in the financial sector - using public clouds for other purposes. At the same time, this clearly has not deterred many customers from using AWS as part of their cloud strategy, regardless of whether they plan to move all systems to the cloud or not.

Another downside to AWS is the scale of its offering. While this is an attraction in many senses, it can be difficult at times to navigate the large numbers of features that are on offer, and some see AWS as being a complex vendor to manage.

Microsoft Azure pros and cons

                The big pull for Azure is where Microsoft already has a strong footing within an organisation and can easily play a role in helping those companies transition to the cloud. Azure naturally links well with key Microsoft on-premise systems such as Windows Server, System Center and Active Directory.In addition, while both AWS and Azure have PaaS capabilities, this is a particular strength of Microsoft’s.

One of the downsides, however, has been a series of outages over the years. Gartner analyst Lydia Leong has recommended considering disaster recovery capabilities away from Azure for critical applications hosted in the cloud. AWS isn't immune to downtime, though, suffering a major S3 outage of its own in March 2017.As part of its 2017 IaaS global Magic Quadrant, Gartner states that its clients have had issues with "technical support, documentation, training and breadth of the ISV partner ecosystem" - but the company has been steadily working on these areas.

Whereas AWS provides users with many options for supporting other platforms, Azure can be somewhat restrictive in comparison. If you want to run anything other than Windows Server then Azure might not be the best solution, but Microsoft has been willing to embrace open source platforms, if a little slowly. For example, the company has been busy extending its support for Linux operating systems in 2017.


Google Cloud Platform pros and cons

              Google has a good track record with innovative cloud-native companies and has a good standing in the open source community, but has traditionally struggled to break into the enterprise market.Its go-to-market strategy has been focused on proving itself on smaller, innovative projects at large organisations, rather than becoming a strategic cloud partner. Increasing the breadth of its partnerships and supporting pre-cloud businesses and IT processes will need to become focus areas if it wants to attract more traditional enterprises.

The company is certainly betting big on its machine learning tools, with the company's internal AI expertise and popular TensorFlow framework as selling points in what is set to become a key battleground.

It has also proved itself more than an AWS copycat, launching innovative features in the machine learning space as well as its BigQuery analytics engine, and the Cloud Spanner distributed database.It is also worth noting that Google has the smallest footprint of global instances of the big three.

The best public cloud vendor for you is going to depend on your needs and your workloads. In fact, the best vendor for some of your projects might not be the best vendor for others of your projects. Many experts believe that the majority of enterprises will pursue a multi-cloud strategy in the near future either in an effort to prevent vendor lock-in or in an effort to match workloads with the best available service.

• The AWS Choice: You can’t go wrong with AWS due to its rich collection of tools and services and massive scale. The only reason not to choose Amazon is if you want a more personal relationship, something a small boutique shop can offer. At its size, it’s hard for Amazon to have a close relationship with every customer, but there are resellers and consultants who can offer that type of attentive focus.

• The Azure Choice: Microsoft’s greatest appeal is, of course, to Microsoft shops. All of your existing .Net code will work on Azure, your Server environment will connect to Azure, and you will find it easy to migrate on-premises apps. If you want Linux, DevOps, or bare metal, however, Microsoft would not be the ideal choice. It offers Linux but it takes a back seat in priority to Windows. DevOps is primarily a Linux/open source play, again, something Microsoft does not specialize in.

• The Google Choice: Google is growing quickly but is a work in progress. Its offerings were meager and it didn’t have a legacy background in dealing with businesses. But it is fully committed and plowed billions into its cloud efforts. And it is partnered with Cisco, which does know the enterprise. The people who should look at Google now are the ones who looked a year ago and didn’t like what they saw. They might be surprised. Google has built its cloud on its strength, which is scale and machine learning. it’s clearly worth a look.


Bottom line: Certain types of companies will be more attracted to certain cloud vendors. So again, if your firm runs Windows and a lot of Microsoft software, you'll probably want to investigate Azure. If you are a small, Web-based startup looking to scale quickly, you might want to take a good look at Google Cloud Platform. And if you are looking for the provider with the broadest catalog of services and worldwide reach, AWS will probably be right for you.



Wednesday, June 12, 2019

Four types of risk management technology



An Overview about the Risk management Technologies we can use ,

1. Risk Dashboards

Dashboards are probably the easiest type of technology to put in place, and many enterprise project management tools come with this feature. You can create risk dashboards manually, but it’s a time-consuming process that results in a report that is out of date from the moment it’s finished.

2. Automated Processes


A further type of tech that you can adopt for risk management is automating processes through workflows within a tool.This means that your process of risk identification, assessment, management, monitor, control and escalation is managed through a single process within a tool. You document a risk in the tool, assign it to the right person to assess and they will automatically get a notification that they have work to do.


3. Risk Assessment Tools

You can use software tools to help with risk assessment too. This increases the likelihood that risks are assessed in the same way, against the same model. In turn, this makes it easier to compare risks across program or portfolio level and have confidence that they really are comparable.Basic risk assessment tools are often included in enterprise project management solutions. Add the impact and probability of the risk into the tool and it will generate a RAG (red/amber/green) status for the risk. This is a simple assessment tool that you can do manually, but managing it in the tool increases standardization.


4. Advanced Risk Management Tools

Risk management software tools can take your risk management even further. They can do risk modelling, run scenarios and flag problems through early warning indicators in your reporting. When the data is in the tool, advanced risk management tech can take the heavy lifting out of managing your risks. This functionality is sometimes available in your enterprise systems, and available as standalone products too.


Risk is about uncertainty. If you put a framework around that uncertainty, then you effectively de-risk your project. And that means you can move much more confidently to achieve your project goals. By identifying and managing a comprehensive list of project risks, unpleasant surprises and barriers can be reduced and golden opportunities discovered. The risk management process also helps to resolve problems when they occur, because those problems have been envisaged, and plans to treat them have already been developed and agreed. You avoid impulsive reactions and going into “fire-fighting” mode to rectify problems that could have been anticipated. This makes for happier, less stressed project teams and stakeholders. The end result is that you minimize the impacts of project threats and capture the opportunities that occur.



Saturday, May 18, 2019

Risk Management


 As a project manager or team member, you manage risk on a daily basis; it’s one of the most important things you do. If you learn how to apply a systematic risk management process, and put into action the core 5 risk management process steps, then your projects will run more smoothly and be a positive experience for everyone involved.

A common definition of risk is an uncertain event that if it occurs, can have a positive or negative effect on a project’s goals. The potential for a risk to have a positive or negative effect is an important concept. Why? Because it is natural to fall into the trap of thinking that risks have inherently negative effects. If you are also open to those risks that create positive opportunities, you can make your project smarter, streamlined and more profitable. Think of the adage –“Accept the inevitable and turn it to your advantage.” That is what you do when you mine project risks to create opportunities.


Risk Management is a five step process:

Step 1: Identify the Risk.

Step 2: Analyze the risk.

Step 3: Evaluate or Rank the Risk.

Step 4: Treat the Risk.

Step 5: Monitor and Review the risk.


RISK ANALYSIS


All risks identified will be assessed to identify the range of possible project outcomes. Qualification will be used to determine which risks are the top risks to pursue and respond to and which risks can be ignored.

Qualitative Risk Analysis

The probability and impact of occurrence for each identified risk will be assessed by the project manager, with input from the project team using the following approach:

Probability

•            High – Greater than <70%> probability of occurrence

•            Medium – Between <30%> and <70%> probability of occurrence

•            Low – Below <30%> probability of occurrence

Probability

•            High – Risk that has the potential to greatly impact project cost, project schedule or performance

•            Medium – Risk that has the potential to slightly impact project cost, project schedule or performance

•            Low – Risk that has relatively little impact on cost, schedule or performance

Risks that fall within the RED and YELLOW zones will have risk response planning which may include both a risk mitigation and a risk contingency plan.

Quantitative Risk Analysis

Analysis of risk events that have been prioritized using the qualitative risk analysis process and their affect on project activities will be estimated, a numerical rating applied to each risk based on this analysis, and then documented in this section of the risk management plan.


RISK RESPONSE PLANNING

Each major risk (those falling in the Red & Yellow zones) will be assigned to a project team member for monitoring purposes to ensure that the risk will not “fall through the cracks”.

For each major risk, one of the following approaches will be selected to address it:

•            Avoid – eliminate the threat by eliminating the cause

•            Mitigate – Identify ways to reduce the probability or the impact of the risk

•            Accept – Nothing will be done

•            Transfer – Make another party responsible for the risk (buy insurance, outsourcing, etc.)


For each risk that will be mitigated, the project team will identify ways to prevent the risk from occurring or reduce its impact or probability of occurring. This may include prototyping, adding tasks to the project schedule, adding resources, etc.

For each major risk that is to be mitigated or that is accepted, a course of action will be outlined for the event that the risk does materialize in order to minimize its impact.

Tuesday, April 23, 2019

DevOps Case Study




                               Agile is a set of values and principles about how to produce i.e. develop software. For Example,if you have some ideas and you want to turn those ideas into working software, you can use the Agile values and principles as a way to do that. But, that software might only be working on a developer’s laptop or in a test environment. You want a way to quickly, easily and repeatably move that software into production infrastructure, in a safe and simple way. To do that you need DevOps tools and techniques.Though the implementation of DevOps is always in sync with Agile methodologies, there is a clear difference between the two. The principles of Agile are associated to seamless production or development of a piece of software. On the other hand, DevOps deals with development, followed by deployment of the software, ensuring faster turnaround time, minimum errors, and reliability.

Much has been written about what DevOps is, but not a lot has been said about what it can do for an organization. The trending software development approach has many quantifiable technical and business benefits, including shorter development cycles, increased deployment frequency, and faster time to market. But because it relies so heavily on increased communication, collaboration, and innovation, it can also be a catalyst for cultural change within an organization.

1.ETSY

Etsy is a peer-to-peer e-commerce website focused on handmade or vintage items and supplies, as well as unique factory-manufactured items.For its first several years, Etsy struggled with slow, painful site updates that frequently caused the site to go down. In addition to frustrating visitors, any downtime impacted sales for Etsy's millions of users who sold goods through the online marketplace and risked driving them to a competitor.

With the help of a new technical management team, Etsy transitioned from its waterfall model, which produced four-hour full-site deployments twice weekly, to a more agile approach. Today, it has a fully automated deployment pipeline, and its continuous delivery practices have reportedly resulted in more than 50 deployments a day with fewer disruptions. And though Etsy has no DevOps group per se, its commitment to collaboration across teams has made the company a model of the DevOps framework.


2.Fidelity Worldwide Investment

Fidelity Worldwide Investment had several business units developing software applications and was burdened with legacy release processes that placed huge demands on its teams. Apps were deployed manually across hundreds of servers, with each app requiring customization. Manually introduced errors frequently broke the process.When it came time to develop a critical trading application with a firm launch date, the organization knew its error-prone manual process would jeopardize the project. Fidelity used the opportunity to embrace a DevOps approach and implement an automated software release framework that would enable it to meet the rollout schedule.That solution resulted in more than $2.3 million per year in cost avoidance for that app alone. Since then, the Fidelity team has automated the release of dozens of applications, reducing release times from two to three days to one to two hours and decreasing test-team downtime. The process has also made it easier to display regulatory compliance and has enabled predictable release schedules that stakeholders can rely on.


3.Sony Pictures Entertainment's Digital Media Group

(DMG) faced significant challenges delivering a software system to manage entertainment assets for end users. Manual processes and other hurdles typically resulted in a months-long delay between completion of software development and delivery.To smooth out this "last mile," DMG implemented an automated cloud delivery system composed of open source tools and SaaS solutions. Since adopting a continuous delivery model, DMG has cut down its months-long delivery time to just minutes. This allowed developers to focus on adding features and reduced idle resources and associated costs.



Fix the Problem, Not the Person

  What if the problem is not the person—but the way we are seeing them? Once, I was taking a session for a group of women employees working ...