The Most Knowledgeable Professor Had Empty Classrooms - Why ?

During my college days, there was a professor who was considered one of the most academically accomplished faculty members in the college.

He had earned multiple doctorates, spent years immersed in research, and possessed an extraordinary depth of knowledge in his field.

If knowledge alone determined success as a teacher, his classroom should have been overflowing with students.

Yet many seats remained empty. One day, someone asked a group of students:

"Why don't you attend his classes? He's one of the most knowledgeable professors in the college."

A student replied:

"He may know a lot, but I don't understand how that knowledge is useful to me. If I can't connect with what he's teaching, why would I attend?"

That response stayed with me for years.

At that time, I thought it was simply a student's opinion about a professor.

But as I grew into roles involving coaching, teaching, training, and communication, I realized it was revealing something much deeper.

The professor's challenge wasn't a lack of knowledge.

It was the gap between what he knew and what his students were able to understand, relate to, and apply.

Over time, I began noticing the same pattern everywhere.

Experts struggle to influence.

Leaders struggle to inspire.

Businesses struggle to connect with customers.

Coaches struggle to create breakthroughs.

Not because they lack knowledge, but because knowledge alone is not enough.

Whether you are a leader, coach, teacher, trainer, consultant, or entrepreneur, your impact depends on three things:

1. What you communicate - The value, relevance, and usefulness of your message.

2. How you communicate it - Your ability to make ideas simple, relatable, and meaningful.

3. Whether it creates the intended result ? Does it help people understand, take action, solve a problem, or improve their lives?

Many professionals spend years building expertise.

But expertise without communication creates confusion.

Communication without clarity creates noise.

And communication that does not produce results remains information -not transformation.

People don't respond to how much you know.

They respond to how clearly you help them understand, apply, and benefit from what you know.

The true measure of communication is not the message you deliver.

It is the result it creates.

What are your thoughts? Have you ever met someone who was highly knowledgeable but struggled to make their knowledge meaningful to others?

#Leadership #Communication #Coaching #Teaching #Learning #PersonalDevelopment #Influence #PublicSpeaking #LeadershipDevelopment #ProfessionalGrowth

The Leadership Blind Spot That Drives Talent Away

 

Recently, one of my mentees was given an opportunity she was genuinely excited about.

She was an experienced corporate trainer and subject matter expert with a strong track record of helping professionals improve their communication skills. When a company invited her to train one of their employee batches, it seemed like a perfect fit.

Her mock session was well received. The participants connected with her teaching style, and the Company Head appreciated the value she could bring to the organization.

Everything seemed to be falling into place.

Yet within a few weeks, she walked away from the assignment.

What happened next reveals a leadership blind spot that causes many organizations to lose talented people without even realizing it.

The issue wasn't with the participants. They were engaged and eager to learn. Nor was it with the Company Head, who had recognized her expertise from the beginning.

The challenge emerged elsewhere.

The day-to-day oversight of the training had been assigned to an administrative staff member with limited exposure to both the subject matter and the training profession itself.

Rather than supporting the training process, he frequently questioned her skills, methods, and decisions. Over time, the focus shifted away from participant learning and toward repeatedly evaluating the trainer herself.

Whenever the administrative staff member raised concerns about her performance, she asked what specifically needed improvement so that she could make the necessary changes. However, clear and actionable feedback was rarely shared. The responses remained vague, making it difficult to understand what needed attention or how to address it.

For any professional, that can be exhausting—especially when the person raising those concerns lacks the expertise needed to assess the work fairly.

As the weeks passed, what began as an exciting opportunity gradually became an emotionally draining experience. Instead of focusing her energy on helping participants learn, she found herself dealing with issues that had little to do with the training itself.

Eventually, she made the decision to step away, as she finally understood,

"The issue was no longer about training. It was about the environment surrounding the training."

The leadership team had entrusted the day-to-day oversight of the program to someone who lacked the subject matter expertise needed to properly evaluate the work being done.

Rather than spend her time proving her worth or challenging management decisions, she chose to move on.

Some battles are won by staying. Others are won by knowing when to leave.

This experience highlights a few important lessons for leaders:

Hiring the right talent is only the first step. Retaining that talent requires the right environment.

Subject matter experts should be supported by people who understand the work well enough to evaluate it fairly.

If feedback is expected, it should be clear, specific, and actionable.

When capable professionals spend more time defending their value than doing their work, disengagement is inevitable.

Not every talented professional leaves because of a better opportunity. Sometimes they leave because the environment no longer allows them to do their best work.

Good people are hard to find. Losing them to preventable leadership blind spots is a cost no organization can afford.

#Leadership #TalentRetention #WorkplaceCulture #Management #HR

Save your energy

Not every disagreement needs a response.

Save Your Energy

One of the most valuable leadership lessons I've learned is this:

Not every opinion needs a response.

Not every disagreement needs a defense.

Not every conversation needs to become a debate.

As leaders, coaches, mentors, and professionals, we often spend too much energy trying to convince people who are not ready to listen.

Real growth rarely comes from winning arguments.

It comes from curiosity, openness, and experience.

Energy is a limited resource.

Invest it where there is willingness to learn, willingness to explore, and willingness to grow.

Sometimes the wisest thing you can do is simple:

Save your energy.

 

When a Fly Falls in Tea… and When It Falls in Ghee

 

A simple old saying carries a surprisingly deep lesson about human behavior.

When a fly falls into tea, people often throw away the tea.

But when a fly falls into ghee, people usually remove the fly and preserve the ghee.

Why?

Because people instinctively protect what they perceive as more valuable.

The same pattern quietly exists in workplaces too.

Sometimes, during conflicts, organizations choose to protect:

• high performers,
• influential employees,
• profitable clients,
• senior leadership,
• or internal politics…

while someone with less influence becomes replaceable overnight.

It may not always be fair. But it reveals an uncomfortable truth about how value is perceived.

This doesn’t apply only to companies.

It happens in friendships, partnerships, and even families: people often fight harder to preserve what they emotionally or materially value most.

But there is another important lesson hidden here.

Your worth should not be measured only by how others treat you.

A person ignored in one room may be deeply respected in another. Sometimes value is not absent — it is simply unrecognized.

Still, the world often protects what it considers valuable.

So instead of waiting for appreciation from everyone around us, perhaps the wiser path is to grow, contribute, and become so valuable that our presence is difficult to replace.

Not through arrogance. Not through status alone. But through character, skill, reliability, integrity, and the ability to make a meaningful difference wherever we are.

Because in many situations, value changes how people respond.

And when we continue to evolve, contribute, and improve ourselves, our presence becomes far more difficult to replace.

#leadership #workplacepsychology #humanbehavior #selfgrowth #emotionalintelligence #careerdevelopment #personaldevelopment #mindset #professionalgrowth #workplaceculture #linkedinindia #selfawareness #growthmindset #lifelessons #communication

 

The Hidden Cost of Busy Leadership

 

Not every leadership challenge comes from lack of effort. Many come from lack of clarity.

A lot of leaders today are exhausted. Not because the work is too much — but because the direction is unclear.

So they compensate with activity.

More meetings. More follow-ups. More urgency. More pressure.

But here’s the truth: Activity creates the illusion of leadership. Clarity creates actual leadership.

When a leader lacks clarity: • Teams become dependent instead of decisive • Communication becomes reactive instead of intentional • Everything feels urgent, but nothing feels aligned

And slowly, people stop taking ownership — because they’re too busy trying to understand what matters.

Strong leadership is quiet in a different way.

It looks like: • Fewer instructions, clearer intent • Less control, more ownership • Less noise, more direction

Because when people are clear — they don’t need constant management.

They move.

You can run faster. Or you can lead clearer.

Only one of them actually scales.

#Leadership #Management #Clarity #WorkCulture #TeamLeadership #ProfessionalGrowth #LeadershipMindset #Execution

 

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.

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.

 

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?

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.

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.

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.

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.

SWIFT System

                   
                     With an International Debit Card, money can be withdrawn at any where in world, the card holder need not have an account with the card issuing financial institution. How this happens?
SWIFT in Investment Banking Settlements: As given by Investopedia SWIFT stands for the Society for Worldwide Interbank Financial Telecommunications. It is a messaging network that financial institutions use to securely transmit information and instructions through a standardized system of codes.

SWIFT SYSTEM

                     The service of Telex is too slow and had no standardized format for the data it transfers, added up to an inefficient system apart from its insecurity. In order to solve the demerits of Telex services seven major international banks gathered together to discuss a suitable replacement of telex in the year 1974. After three years, in 1977, a society was formed and 230 member banks from 5 countries started operation of SWIFT. SWIFT has now more than 10000 members worldwide (more than 200 countries) handles more than 15 million messages daily. Any financial institution who holds a banking license can become a member of SWIFT by paying a joining fee and service charge for each message sent.

                  Using these messages, banks can exchange data for funds transfer between financial institutions. SWIFT enables customers to automate and standardise financial transactions, thereby lowering costs, reducing operational risk and eliminating inefficiencies from their operations.
Although there are other messaging services available such as Fedwire, Ripple and CHIPS, SWIFT maintains its dominant market position. It does this by continually investing in innovation and adding new message codes to further facilitate funds transfer and straight through processing. One recent initiative introduced by SWIFT is the Global Payments Innovation (gpi) which aims to increase the speed, predictability and transparency of cross-border payments.

                 Business to business wire transfers through banks have always been slow and costly despite technological advances which have seen other areas in the payments industry progress. Over 90 leading transaction banks from Europe, Asia Pacific, Africa and the Americas are already signed up to the SWIFT gpi initiative which is now in operation. The first phase of the SWIFT gpi focuses on B2B payments. The goal is to help corporates to improve supplier relations whilst achieving greater treasury efficiencies by enhancing the payments service:
• Beneficiaries will now receive same day access to payments instead of waiting periods of several days.
• Businesses will know in advance how much a bank transfer will cost adding further transparency to fees in the transfer process.
• End to end payments tracking through a cloud based service will allow easy tracing of funds from initiation through intermediary banks to the recipient bank account. Message notification that funds have reached the beneficiary account will also be sent to the payer.

               Swift Code is a standard format of Bank Identifier Codes (BIC) and it is unique identification code for a particular bank. These codes are used when transferring money between banks, particularly for international wire transfers. Banks also used the codes for exchanging other messages between them.

The Swift code consists of 8 or 11 characters. When 8-digits code is given, it refers to the primary office. The code formatted as below;

AAAA BB CC DDD
First 4 characters - bank code (only letters)
Next 2 characters - ISO 3166-1 alpha-2 country code (only letters)
Next 2 characters - location code (letters and digits) (passive participant will have "1" in the second character)
Last 3 characters - branch code, optional ('XXX' for primary office) (letters and digits)

SWIFT is solely a carrier of messages. It does not hold funds nor does it manage accounts on behalf of customers, nor does it store financial information on an on-going basis. As a data carrier, SWIFT transports messages between two financial institutions. This activity involves the secure exchange of proprietary data while ensuring its confidentiality and integrity.

There are four key areas that SWIFT services fall under within the financial marketplace. They are Securities, Treasury and Derivatives, Trade Services, and Payments & Cash Management.
SWIFT messages consist of five blocks of data including three headers, message content, and a trailer. They are identified in a consistent manner. They all start with the literal ‘MT’ which denotes Message Type. This is followed by a 3-digit number that denotes the message type, category, and group.

MT103 for example, is a SWIFT payment message type used in cash transfers specifically for cross border / international wire transfer and is predominately used between Banks and Non-Bank Financial Institutions. MT103 is used to make a single payment and it has a large number of options to describe exactly how the payment should be (for example, determining the beneficiary account and sender bank details).Few other multiple standard file formats used are EDIFACT, ANSI X12, SAP and ISO 20022 XML formats.

Facebook Dark Launching Technique

Have you ever wondered why some of your friends get to see the latest Facebook messenger or Gmail upgrade before you do? Why do some people get to play with the newest features weeks before others? And, why do these features sometimes disappear within a week? The answer is a dark launch.

                          Facebook and Google, along with many leading tech giants, use dark launches to gradually release and test new features to a small set of their users before releasing to everyone. This lets them see if you love it or hate it and assess how it impacts their system’s performance. Facebook calls their dark launching tool “Gatekeeper” because it controls consumer access to each new feature.Dark launching is the process of gradually rolling out production-ready features to a select set of users before a full release. This allows development teams to get user feedback early on, test bugs, and also stress test infrastructure performance. A direct result of continuous delivery, this method of release helps in faster, more iterative releases that ensure that application performance does not get affected and that the release is well received by customers.

                       It is called a dark launch because these feature launches are typically not publicized, but rather, they are stealthily rolled out to 1 percent, then 5 percent, then 30 percent of users and so on. Sometimes, a new feature will dark launch for a few days and then you will never see it again. Likely, this is because it did not perform well or the company just wanted to get some initial feedback to guide development.In 2011, Facebook rolled out a slew of new features – timeline, ticker and music functionalities – to its 500 million users spread across the globe. The huge traffic that was generated on Facebook following the release led to a server meltdown. The features that were rolled out garnered mixed response from users which led to inconclusive results of the effectiveness of the new features, leaving them with no actionable insights.This led to an evaluation and reassessment of strategies, resulting in Facebook coming up with the Dark Launching Technique. Using the DevOps principles, Facebook created the following methodology for the launch of its new releases.

During Dark Launch one deployment pipeline is turned on to deploy the new features to a select set of users. The remaining hundreds of pipelines are all turned off at this point. The specific user base on which the features have been deployed are continuously monitored to collect feedback and identify bugs. These bugs and feedback will be incorporated in development, tested and deployed on the same user base until the features becomes stable. Once stability is achieved, the features will be gradually deployed on other user bases by turning on other deployment pipelines.             

                      Facebook does this by wrapping code in a feature flag or feature toggle which is used to control who gets to see the new feature and when. This exposes pain points and areas of the application’s infrastructure that needs attention prior to the full-fledged launch while still simulating the full effect of launching the code to users. Once the features are stable, they are deployed to the rest of the users over multiple releases. 

                     This way Facebook has a controlled or stable mechanism for developing new functionality to its massive user base. On the contrary if the feature does not get a good response they have an option to rollback on their deployments altogether. This also helps them to prepare their servers for deployment as they can predict the user activity on their website and they can scale up their servers accordingly. 

                    Facebook, Amazon, Netflix and Google, along with many leading tech giants, use dark launches to gradually release and test new features to a small set of their users before releasing to everyone.The intention of DevOps is to create better-quality software more quickly and with more reliability while inviting greater communication and collaboration between teams. It is also an automation process that allows quick, safe and high quality software development and release while keeping all the stakeholders in the loop. This is the real reason why DevOps is seeing an all-time high adoption leading to increasing career opportunities in DevOps.

CI/CD - A Overview

Continuous Integration is the practice of continuously integrating the changes made to the project and testing them accordingly at least on a daily basis or more frequently.Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Providing your users with the best possible software is always the number one priority. But doing so in the fast-paced, ever-changing technology landscape we live in isn’t a simple task. As soon as an update is deployed, it seems like the need for the next is already here. This has been a constant battle of development teams for decades. The introduction of DevOps was a great start, the need to become even more efficient still remains.

Enter: continuous delivery (CD), which is the process of ensuring your software is always ready for deployment. It goes hand-in-hand with the DevOps and agile movement. Deployments are available with the push of a button, and rollbacks (when necessary) are seamless.

When your build is fast and well-automated, you build and test the whole system more frequently. You catch bugs earlier and, as a result, spend less time debugging. You integrate your software frequently without relying on complex background build systems, which reduces integration problems.

Behind every great CD pipeline is a well-oiled continuous integration (CI) pipeline. CI is the process of developers pushing code early and often into a code repository for automated integration testing. The idea is that every piece of code sent to the repository will be tested within minutes and flagged if any errors occur. If an error does occur, that now becomes the main priority of the developer.

Without continuous integration, back-tracking errors can be a tedious and time-consuming process, and it’s easy to get lost in the maze of code changes. Integrating as early and often as possible makes it easier to identify where the error occurs. CI also reduces the risk of having errors flare up further down the CD pipeline.

While the specific CI process can vary slightly based on a team’s preference, the essential steps are:

1.Build code

2.Send code to repository

3.Test code

4.Send back errors

5.Fix code

6.Repeat step 2 and 3


Testing Process

Once cleared through the code repository tests, the next step is to send your code to more expansive staging and production tests. Once again, the key here is automation. For an effective CD pipeline, little to no effort should be going into these tests, allowing your team to focus on development in the CI stage. The tests performed through the stage typically include regression tests (making sure the application works) and performance tests (making sure the application works efficiently).

These tests should confirm that your application works as it should and integrates properly with your existing platform. In many cases, teams will have small user groups test deployments in production-like environments. This gives your team explicit feedback from customers.


To Deploy/Not to Deploy

This is where continuous delivery and continuous deployment fundamentally disagree. In a standard continuous delivery pipeline, once your application is cleared through testing and declared ready for deployment, it sits in a deployment queue. It is not deployed until manually done so. On the contrary, in a continuous deployment pipeline, as soon as an application passes through testing, it is automatically deployed to end-users.

Monitor

Just as DevOps doesn’t end for developers after the code is written, continuous delivery doesn’t end once an application is deployed. Inevitably some applications will have errors, despite all of the testing you worked so hard to automate. This is completely normal. Catching the errors early is critical to the well-being of your application and to the user experience.


CI/CD is a devops best practice because it addresses the misalignment between developers who want to push changes frequently, with operations that want stable applications. With automation in place, developers can push changes more frequently. Operations teams see greater stability because environments have standard configurations, there is continuous testing in the delivery process, environment variables are separated from the application, and rollback procedures are automated.

Agile Vs Scrum

A  Scrum Master works with “A” team. An Agile Coach works with ALL teams, AND executives AND other teams/groups. A Scrum Master ensures that the team is following the Scrum process, doing the ceremonies and behaving the right way.

The Scrum Master’s Role: 

A SM will usually focus on a single team or a couple of teams at most. Anymore and they are highly unlikely to be very effective.


 Their primary focus will be internal by ensuring the team: 


§ Communicates well to each other and stakeholders


§ Collaborates with their Product Owner to deliver work that holds business value


§ Understands and embodies the Agile values and principles set out in the Agile Manifesto 


They will use many of the techniques associated with Agile Coaching, for example: 


§ Training courses to fill in existing skills gaps, e.g. user story writing


§ Facilitating ceremonies such as the retrospectives


§ Mentoring individuals in specific Agile practices as needed

And possibly: 

§ Professional coaching; that is using techniques to guide the individual to uncover answers to their own challenges, rather than imparting knowledge. 


As the SM and the team mature, the SM will understand there are external factors that impact the team. The SM will begin focusing more of their time on these external factors. They become agents of change for their organisations again using some of the skills that would be associated with Agile Coaching. Their focus will still be the team but they will look to how managers and other teams affect the work the team does. This activity could include but is not limited to: 


§ Facilitating/Participating in a Scrum of Scrums ceremony to understand the landscape of the wider department


§ Training other teams in order to build up common skills/knowledge


§ Identifying behaviours in other teams which impact their team, working with other SMs to resolve this 


The Agile Coach’s Role:


 An Agile Coach(*) will work with a number of teams either directly or through the team’s’ management. It is unlikely they will be able to develop the same level of personal relationships with the teams like an SM can, because their scope is set across a much wider area. Instead they will work with the managers and Scrum Masters to increase the overall agility of a number of teams. 

For example: 


An Agile Coach will either be assigned to a set of teams or will spend time observing how work is done within the wider group. Then they will use some of the same skills as a Scrum Master to help these teams improve, for example training. But they will also exhibit other skills that go beyond those of a Scrum Master. For example, an Agile Coach could leverage their advanced skill set, experience and knowledge by sharing concepts such as systems thinking to uncover feature teams. Alternatively a coach could work with a group of managers and HR to design a new reward structure. The skills needed for these organisation/management level challenges are very different to those of a SM.The Agile Coaching Competency framework from the Agile Coaching Institute sums this up well in that the two roles are largely defined by the level of scope and influence. 


An Agile Coach will have a deep knowledge of the practicalities in the agile/lean space, which will be wider and deeper than that of a SM. Additionally, they will have a range of skills in Teaching, Mentoring, Facilitation & Professional Coaching, and their own delivery style which will be a blend of all of these techniques. Finally a coach will be a specialist in one of three domains, Technical, Business or Transformation. Where the Agile Coach specialises will be down to their experience and background. 


For instance an Agile Coach focussing on the technical domain will have deep experience with a range of programming languages, automation, testing, delivery pipelines etc. Whereas an Agile Coach specialising in the Transformation domain will be an expert in systems thinking, organisational design and concepts like theory of constraints and operating model design. 


A SM will have more limited knowledge in these areas due to the scope of their work. For example, a SM could know a lot of techniques required in the Business domain (ie. Product focus) at a team level e.g., helping teams learn how to split user stories or story prioritisation. However, they won’t have the skills to mentor higher level managers in building an agile portfolio or cover the training required for agile budgeting. 

Two similar but distinct roles, complementing each other 

Hopefully from the brief summary above you can see how a SM and Agile Coaches roles will differ. But it is important to remember that these two roles should not negate each other. Just because an organisation has hired an Agile Coach does not mean they would not benefit from dedicated SMs, and vice versa. In fact the most successful applications of agile practices will use a blend of SMs and Agile Coaches in order to bring onboard the range of skills that are needed. The roles then take on a synchronised nature, where the SMs and coaches collaborate in order to further the agile vision of that organisation. 

Top 3 cloud services

In a multi-cloud world, organizations may use different cloud providers for multiple capabilities concurrently. Most of the cloud service providers (CSP) out there offer high-quality services, with excellent availability, high security, good performance, and customer support. But the market is dominated by a top three—Amazon Web Services, Google Cloud, and Microsoft Azure. While these three cloud providers collectively dominate this sphere, their approach to cloud computing is strongly dictated by their background.

Compute, storage, databases and networking


                       For compute, AWS’ main offering is its EC2 instances, which can be tailored with a large number of options. It also provides related services such as Elastic Beanstalk for app deployment, the EC2 Container service, AWS Lambda and Autoscaling.Meanwhile, Azure's compute offering is centred around its Virtual Machines (VMs), with other tools such as Cloud Services and Resource Manager to help deploy applications on the cloud, and its Azure Autoscaling service.

Google's scalable Compute Engine delivers VMs in Google's data centres. They are quick to boot, come with persistent disk storage, promise consistent performance and are highly customisable depending on the needs of the customer.All three cloud providers support relational databases - that's Azure SQL Database, Amazon Relational Database Service, Redshift and Google Cloud SQL) - as well as NoSQL databases with Azure DocumentDB, Amazon DynamoDB and Google Bigtable

AWS storage includes its Simple Storage (S3), Elastic Block Storage (EBS), Elastic File System (EFS), Import/Export large volume data transfer service, Glacier archive backup and Storage Gateway, which integrates with on-premise environments.Microsoft’s offerings include its core Azure Storage service, Azure Blob block storage, as well as Table, Queue and File storage. It also offers Site Recovery, Import Export and Azure Backup.All three typically offer excellent networking capabilities with automated server load balancing and connectivity to on-premise systems.

Pricing

                    Pricing can be a huge attraction for those considering a move to the cloud, and with good reason: there has been a continued downward trend on prices for some time now as the big providers compete. However, making a clear comparison can be tough as all three offer slightly different pricing models, discounts and make frequent price cuts.

All vendors offer free introductory tiers, allowing customers to try their services before they buy, and typically offer credits to attract innovative startups onto their platforms as well as 'always free' tiers with strict usage limits.

For example, Google offers free usage up to 1GB of Google Cloud Datastore capacity, 28 instance hours per day for Google App Engine, one micro sentence per month for Google Compute Engine, 5 GB-months of Google Cloud Storage (regional only), 2 million Cloud Functions per month, 50GB of logs with Stackdriver for monitoring, as well as limited access to products like: Google Cloud Natural Language, Cloud Vision API, Kubernetes Engine and more.

Customers

             A high-profile user base may not be the main reason for choosing your cloud provider, but it can help more cautious organisations understand how the public cloud is benefiting others in their sector.This is clearly a strong point of AWS. It has increasingly taken on large customer deals. For example, although the US Central Intelligence Agency eventually signed a contract with IBM, it awarded AWS a contract to build its private cloud in a one-off deal in 2013, which could be seen as a symbolic moment for potential buyers.

A longstanding AWS customer is Netflix, which eventually decided to shut all of its data centres in a final move to the cloud in 2016. But aside from web pioneers, AWS has been truly successful in convincing more traditional businesses to move to the cloud.UK bank HSBC has opted for Google Cloud for its analytics and machine learning capabilities. However, HSBC is taking a clear multi-cloud approach, partnering with all three providers for different workloads.