What Toilet-Training my toddler Taught Me about change management

It was a Tuesday afternoon, and I had just finished a grueling design authority session when I smelled something foul. My poker-trained eyes spotted a tell on my toddler's face: He was about to soil his pants.
I then ran behind my toddler, begging him to use the toilet. Trying various methods of persuasion, I begged him to use the toilet. This scene was familiar in our house ever since my partner and I began training him to use the toilet. He giggled, darting around like it was a game of tag. As I finally caught up to him and we triumphantly reached the bathroom, I realized this chaotic scene had uncanny parallels to change management in the workplace. It's not the act in itself but the various persuasion techniques and changing behavior embedded in my toddler's whole life.
Here are some of the lessons my toddler taught me in change management.

Change Takes Time

Just as toddlers need time to adjust to potty use, employees and team members need time to adapt to changes. Rushing the process can lead to setbacks. Start small but determined steps.

Celebrate Small Wins

Recognize and celebrate every small success. Positive reinforcement encourages continued progress. Show them the benefits of the new ways and bring out the shiny numbers, outstanding reports, and dashboards.

Clear Instructions

Toddlers need clear, simple instructions, and so do team members. Avoid jargon and ensure everyone understands their role and the steps involved. Make a video walkthrough that users can refer to whenever they want. I have also found that clear instructions or how-to pages work better than a twenty-minute video.

Adjust Your Approach

What works for one toddler may not work for another. Similarly, different team members may respond better to various strategies. Be prepared to adjust your approach as needed. Some are quick to adopt change, others are slow to pick up stuff, and there is progress as long as we move forward.

Provide Support

Just as toddlers need support and reassurance, so do team members. Offer training, resources, and emotional support throughout the change process.
Establish Routines: Consistent routines help toddlers feel secure, and they do the same for employees. Establishing predictable processes can reduce anxiety and resistance.

Encourage Independence

Giving toddlers the autonomy to try things independently builds confidence. Similarly, empowering employees to take ownership of their roles and contributions can foster a sense of responsibility and engagement.
These are some lessons I drew parallels with training the kid to use the toilet.

No one likes change, not when you have become comfortable and compliant in your daily routine. However, as technology evolves, so does the need for change, and with a proper change management strategy in place, technology can succeed in being adopted.
This Tuesday, the adoption rate was 75%, meaning we successfully used the toilet three out of four times. This demonstrates the effectiveness of our approach and the progress we're making.

TLDR using generative AI:

Trying to potty-train my toddler taught me valuable lessons in change management, like celebrating small wins, providing clear instructions, and being prepared for setbacks. Like toilet training, change takes time and patience, but progress can be made with the right approach—even if it's not always a perfect success!

Read More

Two arguments for a single-org strategy and one for multi-org

Photo by Direct Media on StockSnap

It was a general catchup meeting with a stakeholder, we discussed about the health of their salesforce, about how different teams are doing and then the stakeholder mentioned something that made my ears standup, "We have audited our instances and turns out we have 5 Salesforce Org, what do you think is ideal?"

A deep breath. This question has come up more than once: the bigger the organization, the more complex the question gets; we discussed the health of their salesforce and how different teams are doing, and then the stakeholder mentioned something that made my ears stand, "We have audited our instances and it.

Many years ago, I was asked to look into an client with close to 8 Salesforce instances. One was just there to work on Ncino, and the rest were customized by different regions according to their needs. But when we analyzed the business model of all the regions, they were doing the exact same thing with different configurations.

So, that becomes the first argument for having a single organization across multiple regions and business units.

1. If your company aims to streamline processes and coordinate among different business units, consider using a single-org approach.

Each salesforce org is expensive, and the money increases exponentially as the number of users grow.

In a single-org structure, as multiple business units join a single organization, the complexity of maintaining the organization increases. In this case, there has to be a Global Center of Excellence and a governance body responsible for setting up guardrails in the organization.

However, if planned for the start, when the project is greenfield, there are guardrails set for multiple business units on how to use the objects, set up naming conventions and prepare to dedicate some time cleaning up tech debt, the org can be used for better. This approach needs additional time and effort to prepare the org to accommodate multiple business lines. This is a architecturally significant decision and the right way to do it.

2. Would it be more cost-effective to have a multi-org or put in additional effort to set up a COE for multiple business lines and regions?

Having multi-org will mean having costs multiplied across different orgs. All of them will need maintaining and teams to manage. Every enterprise company has a integration strategy, what will be the integration strategy for different salesforce data? What about master-data-management, if there are systems that manage master-data, will that data be replicated across the different orgs. Who handles conflicts in data?

You will also have to think about the different users who will need separate licensing for different orgs.

3. If you have independent business units with individual budgets that do not rely on each other, does it make sense to manage their own Salesforce instance?

Managing separate Salesforce orgs for independent business units with individual budgets can be a good idea. This approach can provide each unit with more control over their processes and data management. It can also help to prevent data overlap and confusion between different departments. However, weighing the costs of managing multiple instances against the benefits of having separate orgs is essential. Additionally, it is crucial to ensure that the data can be easily shared across instances, if necessary, to maintain a cohesive view of the customer across the organization. Ultimately, the decision to manage separate Salesforce instances should be based on each business unit's specific needs and goals.Other factors to consider include budgets, timelines, and regulatory requirements to use multiple Salesforce orgs; however, those factors are not architecturally significant but more process-driven

We looked deep into the client org and realized that out of the 8, they could get rid of three of their salesforce instance and port their existing code and logic into one- master instance. Its been three years now and last I heard, they are down to three saving them a lot of money and not replicating their process.

What has your experience been managing multiple Salesforce instances for different business units, and how has it impacted your organization's processes and costs? Are you baffled by the expensive consultants who throw tech jargon your way? Drop me a note; maybe I can help.

TL;DR: Chat GPT generated summary:

The article discusses the pros and cons of using a single Salesforce org versus multiple orgs for different business units. The decision should be based on specific needs and goals of each business unit, budgets, timelines, and regulatory requirements. Ultimately, it is essential to weigh the costs of managing multiple instances against the benefits of having separate orgs. The article concludes by stating that deep analysis of the client org can help to reduce the number of Salesforce instances and save money while improving processes.

Read More

When nothing else works- Kobayashi Maru

Photo by Startup Stock Photos on Stocksnap.io

The environment was tense and nerve-wracking. Freshly dry-cleaned suit, neatly creased pants and lightly gelled hair, everything I could prepare for a new job was engineered for perfection. I even had a brand new ball pen with a brand of the technology I was here to consult about. The funny thing about the pen last evening: I travelled one and a half hours on the sweaty London Tube, battling my fear of bed bugs. As I said, I had everything engineered to perfection.

I was eager to impress my clients with my skills, but also aware that I could quickly end up in the doghouse. I approached the challenge with the same confidence level as a penguin in a tuxedo - not exactly built for success, but willing to waddle forward anyway.

I was the 21st team member; the last twenty filled multiple positions across the development spectrum. The project template was nothing new; Someone sold the idea of twenty people at different levels to the client. They bought it. There was just one problem - no solid requirements or plan. A vague idea that all the lines of business had to go live together.

This situation is not new. 

We have often landed in a position like this, where the client has a sliver of an idea; they have paid Salesforce billing but need to figure out where to begin. A Solution Architect is only as good of a help as the requirement provided for the project. There is only a solution if there are requirements.

It is a no-win situation- a Kobayashi Maru.

The Kobayashi Maru is a Star Trek training exercise designed to test Star-fleet Academy cadets' character in a no-win scenario. The test is famously unbeatable and is designed to evaluate how cadets handle a situation without a clear solution.

Captain Kirk famously beat Kobayashi Maru by reprogramming the simulation and winning the no-win situation.

And there is a lesson here. When there are no requirements but a vague idea of a project, there is a need to bring the concept of a minimum viable product. 

A minimum viable product is a basic version of a product with enough features to satisfy early customers and gather feedback for future development. This vital process allows clients to validate their vague ideas, reduce development costs, and make informed decisions on what features to prioritise. With an MVP, we can test the waters before investing heavily in development. 

More importantly, we can get a team of twenty-one moving in a direction. Planning an MVP is a small portion in the grand scheme of things, but it's a start. The stakeholders get something solid in their hands; they have a system to feel and explore, bringing out the picture even more clearly. The ever-daunting task becomes bearable, manageable and achievable. 

Suddenly, we see the end goal in sight.  

So, have you ever found yourself in a Kobayashi Maru situation before? How did you handle it? Let me know in the comments below!

TL;DR

- When I was starting a new job as a Tech Architect, the project had no solid requirements or plan, just a vague idea.

- We created a minimum viable product scope to validate vague ideas, reduce development costs, and make informed decisions on what features to prioritise.

- Planning an MVP is a small portion in the grand scheme of things, but it's a start.

- The stakeholders get something solid in their hands, making the ever-daunting task bearable, manageable, and achievable.

Read More

An algorithm to make the perfect coffee

The warm aroma of freshly brewed coffee fills the air, and as I take my first sip, I can't help but feel a sense of calm wash over me. The world outside is still and quiet, as if it's holding its breath, waiting for the hustle and bustle of the week to begin. You take a moment to reflect on the past week and set intentions for the weekend ahead while enjoying your coffee. It's a small yet meaningful ritual that sets the tone for the rest of your day. It's Friday after all.

A fellow developer had recently commented, "Why do I need to know about maps and sets? Flows will do most of the job for us..."

Why must we study programming fundamentals when we have a very powerful platform like salesforce focused on less or no code? And that is where the sip of beautiful coffee mingled on the tongue, and an answer came to the fore. We get so many good coffee machines in the market, then why do we need to learn how to make filter coffee?

We get amazing pod machines, professional coffee machines and even traditional press machines, so why do we still need to understand the basics of making coffee?

Just like how you need a proper structure to make a good cup of coffee, developers need to use proper data structures to manage and organize data in Salesforce effectively. In other words, Salesforce platform, flows are like the tools and equipment that help you make a perfect cup of coffee. You will get a tool to effectively replace one part of the coffee making process, but that should only aid your journey in making coffee.

And tools will break-down or wear out, what will remain is your knowledge. And that is why we keep the bare-bones as is. And that is why, even if Salesforce provides us with a nice shiny tool to build our processes, to model data, knowing the data structures is as much essential as knowing the tool itself.

Knowing that an array starts from zero is as much essential as knowing you can call a flow from another flow. If the goal is to make the system as efficient as we can, we have to use all the tools we have. And sometimes, we only get boiling water for our coffee.

And since I did write about the algorithm for making the perfect coffee, here it follows.

1. Boil water in a kettle or on a stove.
2. Grind coffee beans.
3. Put a coffee filter or cheesecloth into a funnel or strainer and set it over your coffee mug or carafe.
4. Put the ground coffee into the filter.
5. Slowly pour the hot water over the coffee grounds in the filter.
6. Let the coffee steep for 3-5 minutes.
7. Remove the filter or cheesecloth from the funnel or strainer, and discard the used grounds.
8. Give your coffee a quick stir, add any desired milk or sweetener, and enjoy!

This is a bare-bone of making a coffee.

Happy Friday.

Read More

What I learned from automating my house during the pandemic

An empty mind is an engineer's workshop. That saying is as old as time. Two things happened simultaneously in 2020 - The Pandemic hit, causing many jobs in IT to move from working from the office to working from home. We were expecting a baby and therefore had to take additional precautions, which meant a complete disconnect from human civilization, barring the occasional video calls.

The second thing during this period was moving into a brand-new flat. As you scour through manuals from Ikea, you start understanding the patterns. You can see which manual is copy pasted from other manuals; you can empathize with the manual-making team and how overworked they are to churn out new assembly guides for every new piece of furniture in the market.

That was when I looked at the house carefully and asked a pertinent question, why in the 22nd century, do we need switches? The light control is a stone-age activity; you move from your position, drop what you are doing, reach this non-descript mechanical plastic breaker circuit, and hit it with a click, causing the course to complete, and electricity passes through. Humans came to the moon in 1969; we have Voyager about to go to the outer edges of the solar system. Humans now can launch not one or two but 104 satellites in orbit with the mathematical precision in mm, so why on earn should I drop my cup of frothy coffee, rise and walk to the small plastic thingy on the wall to get more light in the room?

So I went complete hardware mode and picked up intelligent devices. 

1. For GU10 Spotlights, I used the INNR multi-coloured bulbs for living areas connected with Hue Bridge.
2. For the Screw Bulbs, I used TP-Link TAPO Yellow bulbs for the bedroom.
3. For the smart blinds, I used Louvolite electronic blinds that can be configured and used the Louvolite hub.
4. I have a Cubo AI camera for the nursery with motion sensing that detects when the baby moves closer to the edge of his cot.
5. Everyone has a robotic hoover in the house, but if you haven't, I recommend you get one. For the robotic hoover, I have used the Ecovacs Deebot 920 for automatic cleaning and mopping the house.
6. For orchestration, I had Alexa Echo for ages, but I decided to upgrade to Alexa Show, which is wall-mounted for the new house. Having Alexa Show, which is mounted on the wall, gave a sense of a control panel for the whole place when we did not want to use the voice command.

Here are some of the most comical takeaways I experienced along the way:

Compatibility is Key (But Not Always Easy): I quickly learned that compatibility is crucial for a smooth-running smart home. But, when I thought I had everything set up perfectly, one of my devices would suddenly go rogue and refuse to play nice with the others. It was like trying to herd cats, but with technology.

The Joy of Voice Integration (or the Lack Thereof): Integrating my smart lights and blinds with Alexa was much fun - when it worked. But, when Alexa refused to listen to me or misheard my commands, it was like talking to a stubborn child who wouldn't listen.

Scheduling and Automation: Setting up schedules and automation for my smart lights and blinds was a real hoot. I felt like a mad scientist, coming up with elaborate plans to outsmart my devices. Of course, they usually didn't follow my commands, but it was still a good laugh.

Debugging and Troubleshooting: This was where the real fun began. Debugging and troubleshooting my smart lights and blinds was like trying to solve a mystery, complete with red herrings and false leads. As a result, I learned to be creative in my troubleshooting methods, like shaking the device, shouting at it, or even trying to bribe it with treats (kidding, of course).

In conclusion, automating the lights and blinds in my home was a hilarious adventure filled with laughs, frustration, and much learning. 

And as I write this article, I can ask Alexa to turn on my living room lights or close the blinds without moving an inch from my seat; that gives a sense of power.

P.s. Many of my devices happened before Matter protocol came into being. Therefore, my devices were already orchestrated before 'matter', and consequently, it didn't affect me.

Read More