Managing priorities and handling expectations after two babies

In December last year, as the world was about to celebrate one more revolution around the sun, we welcomed a new client into our little family. This new client was needy, annoying and had the charming quality of asking for milk. This made the entire BAU team tizzy, as this new client needs additional support and guidance. While the older client was now much more stable and required less attention, he still needed support and guidance. Not to mention, with the understanding of his sandbox, he needed to know more about the world, the planet, animals and dinosaurs.

Yes, we now have two babies.

Every day is an adventure as I juggle the demands of my little ones. With his constant need for attention and affection, the new baby requires me to be fully present, much like a new client needing extra care. Meanwhile, my older child, full of curiosity and questions, thrives on exploration and learning, reminding me that nurturing their imagination is just as crucial. I constantly adapt our routines to ensure both kids feel cherished, whether it's storytelling sessions about dinosaurs or playful interactions that encourage learning about the world around them.

Drawing parallels to the real world and the office world, there have been cases in my career when more than one client sought attention or needed to do their tasks. If we change perspective and look from the client's perspective, their work is essential for them, and as with my babies, their need to seek attention is valid and essential.

So, to solve this conundrum, I do what I always do: I look into my quiver of Agile tools and methods to help with the problem.

So, let's look at some of Agile's tools to handle multiple stakeholders and babies.

1. Prioritisation with Backlog Management: Create a backlog that outlines tasks for both clients. Prioritise these tasks based on urgency and importance. For example, if the new client needs immediate attention, please focus on their needs first while still allocating time for the older client. Things like nail trimming and haircuts are weekly and monthly and, therefore, get added to the backlog based on their duration. Anything to do with milk requires a special skill, so having immediate access to the mummy is paramount.

2. Daily Stand-Ups: Hold brief daily meetings (stand-ups) to discuss clients' progress, roadblocks, and needs. This can help keep the team aligned and facilitate quick adjustments to support the new client's demands while ensuring the older client feels valued. We have sit-downs at the breakfast table and before bed to discuss options for changing our approach.

3. Sprints: Organise work into sprints—short, time-boxed periods where specific tasks are completed. This approach allows for regular reassessment of priorities and enables teams to adapt to the shifting needs of both clients. As most tasks in baby rearing are repetitive, estimating the work in each sprint becomes much easier. There are occasional time-box activities that get added to the backlog, like illness and discomforts that are added to the backlog.

4. Feedback Loops: Establish a feedback mechanism to gather insights from both clients regularly. This can help you understand their changing needs and adapt your strategies accordingly. For instance, if the new client finds the milk-related support insufficient, he will bawl a lot until the milk supply increases.

5. Collaboration: Involve all team members in the process. You can encourage collaboration to brainstorm creative solutions that meet clients' needs. This might include sharing ideas for new classes for the elder one, like driving to swimming or drama class or working on extra chew time for the teething little one.

6. Retrospectives: After each sprint, hold retrospectives to discuss what worked well and what didn't. This reflection will help identify areas for improvement in managing clients and adapt strategies for better results. We don't collaborate on the retrospective front, as most of what didn't work came from the team members.

7. Flexibility: I would like you to maintain flexibility to adjust your approaches as needed. The Agile methodology thrives on adaptability, so be ready to pivot your strategies based on changing demands. This article took me three additional days, as it was deemed low priority for the last sprint.

It was a stretch for me to apply agile principles to managing babies, but jokes aside, the principles are helpful if you have two stakeholders. Are you having difficulty with your Salesforce implementation? Or do you believe your consultant is taking gibberish when you ask him questions?

Send me a message to discuss how we can collaborate to make your implementation successful, Sforce Ninja style.

AI Use: Using Grammarly AI to correct grammar and ChatGpt to create image.

Read More

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

The Moaning of Life #3 The Complex Question of Finding Where You Belong

Many years ago, author Shweta Taneja asked a pertinent question at the launch of her Krishna graphic novel. If a writer is born in one country and emigrates to another, which country does the writer belong to? She talked about Neil Gaiman, born in the UK and later emigrating to the United States. My lord and mentor Ricky Gervais lives in a US and UK mansion with a concierge and security team. He identifies himself as belonging to both countries.

This is the question I have been struggling with for a while now.

We always think of Albert Einstein as the founder of the theory of relativity, but only some acknowledge his country of origin; it's not common knowledge. 

So, does it matter which country you belong to? This question has come up a lot in recent days.

I have spent most of my life in India, visiting and working in multiple cities.

 

My friends in Delhi, Bangalore and Mumbai still swear by our good times and for the bad times. It has come to that once you identify a country, do you have to remember a city to be associated with? For me, the city to be associated with most is Bangalore; the casual racist auto-driver, the city rooted in tech, and the Blackberry police officers are all etched in my memory. 

I also vividly remember standing early in the morning, watching the Republic Day parade in Delhi, eating ras-malai paratha in the paratha gully in Chandni Chowk, meditating in a monastery in Manipur, binge drinking at Titos in Goa, eating a cheese club sandwich in Mumbai, visiting the Mahabalipuram temple in Chennai.

But then I also have vivid memories of eating the best pizza in Europe outside Italy, visiting the chocolate museum in Belgium, consuming a brownie in a coffeeshop in Amsterdam, scuba diving in Malta, of the gogo bar in Thailand and, of course, eating Turkish Delight at Istanbul bazaar but I never called these places home. I do not find solace in this place; I am a completely different person on a holiday.

So the question comes back to haunts: does it matter which country you belong to?

Some of my more right-leaning friends will scream that only one country matters, and it is the country they are born in. It could be Mother Russia or Mother India. They will try to convince me that I must be upright and stand for the country. Some other countries will want you to enlist in their armies when you turn eighteen.

Then again, a few days ago, a young lady opened a coffee shop trying to sell me Arabic coffee, a heap of coffee powder in very little water. My spoon was stuck vertically in the cup as I tried to gulp down the monstrosity. I have never been to Syria, where the girl was and was now seeking asylum in the United Kingdom, so I wonder if her claims were valid. She left behind everything she owned and knocked on the door of the United Kingdom, hoping they opened it for her. 

Her first act of freedom was to make that horrendous cup of coffee, which I gulped down with a smile to not let her down.

The bottom line is that the answer to which country one belongs to is complex. Some people feel deeply connected to their country of origin, while others find a sense of belonging in the country they currently reside in. For some, home is not a place but a feeling, a state of mind. As for me, I am still figuring out where I belong, and it's okay not to have a definite answer.

But here is a definite answer: after months of paperwork, endless queues, and drinking copious amounts of coffee, two days after I turned thirty-seven, I finally caved in, and I am now a citizen of the Great British Empire. I still guzzle tonnes of coffee like before, eat the spiciest meat you can find, and listen to desi Hip Hop Rap. And I still don't know where I belong.

Ultimately, the question of which country you belong to is a lot like trying to find Waldo in a crowded picture. You may have to search long and hard, but in the end, you realise that Waldo was inside you all along. So, if you're still struggling to find which country you belong to, just look inside yourself, and you'll find the answer. Or, you know, go on a world tour, eat good food, sip some coffee, and let the answer come naturally. 

After all, life is too short to take things too seriously.

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