SAs as solution owners

As the name itself suggests, SAs have ownership of their solution. It’s their creation. They designed it and they will be the ones who will have the final say. This has its own pros and cons. A solution is generally based on a quick POC. As the POC is not detailed enough, there might be challenges that are faced by the developer in the later stages of development. This is when the SA is called and asked for an alternative way to get the specific task done. Owning the solution means that no one else can make any changes to it unless it is reviewed and approved by the SA—their blessing is needed. That doesn’t mean recommendations are not welcome. The SA should practice a collaborative approach to recommendations and work toward the greater good.

Ownership comes with a lot of glory and fame. Your name is registered in all the documents as an SA, and everyone knows that you were the key to success. But don’t get too excited—the road to fame always goes through a tough path. Let me walk you through a scenario where you are working on finding a solution that you did not design earlier, just to give you a glimpse of what kinds of curveballs you can face while designing a solution.

You have been asked to design an RPA solution where the process involves thousands of Excel sheets. These sheets have many different templates, and those templates are used by customer care and other teams. These Excel templates are stored on a network drive accessible to all teams from many different geographical locations. As we know, once an Excel sheet is open, it gets locked, so there are multiple versions of the same sheet being created by each user. This flaw in the process is due to a limitation in Excel and the fact that the existing process was designed 15 years ago; it never went through digital transformation. You have been asked to automate this process so that bots and humans can work in conjunction with each other.

You start thinking of various viable solutions, but then you realize that those solutions are more time-consuming and need more investment and effort. You keep scratching ideas and you end up nowhere. Then, you get the idea of splitting the problem into small achievable goals. You go to a whiteboard and draw the existing process and then gaze at it for a few minutes. You immediately realize that this process has two main clients to cater to—one is humans and the other is bots. Even if you are the SA responsible for automation, this doesn’t mean you need to solve all problems and issues pertaining to the process. SAs have to work within the scope of the project. The expectation is to design a solution that can be scaled, managed, reused, and does not disrupt the existing process. You decide that before the automation, you will simplify it from a bot’s perspective. You design a workflow that extracts the Excel template into an XML file. This is called decoupling. Once you do that, the human side of the process and the bot can co-exist.

But the question is: why would you go to such lengths to get this done? The answer is that you are the solution owner. You are responsible for designing and owning that till it is deployed to production and even after that. Having the mindset of an owner will take you to those uncharted territories of your mental creativity and unlock them. As the SA, you won’t think about why you should do this, but you know that you are the only one who has to do it.

Keeping the mindset of an owner always gives you the anchor that will keep you going on at times when you think going forward is impossible. The owner is also responsible for any decision, changes, and outcomes of the solution. Be always ready to own them as well and know that it is inevitable. This is a great responsibility and comes with its own challenges, but then you are the one who will be basking in the glory of success once your solution gets to see production. Now, you have already realized that you are not the person who is going to put your solution into production. You have many teams involved in this life cycle.

As an owner, it is your responsibility to see that the solution you designed and the solution that is getting deployed in production are the same. For this reason, you have to be involved in the day-to-day operations of development, testing, user acceptance testing (UAT), and deployment phases. You can’t lose your focus as there will be questions, comments, suggestions, and cutting corners to get the job done. Owning the solution doesn’t mean only owning a diagram on a piece of paper but owning it from an implementation perspective as well. If the team has challenges, then you should know how to help resolve them. Guiding the team in the entire development phase is also your responsibility, or else you shouldn’t be surprised if the end product is different from what you initially designed.

At times, you will face some situations where developers are frustrated to know you designed a solution the way you did, even when there are easier solutions to the given problem. Well, always keep in mind you have designed it that way as it is one of the best ways to do it rather than it being the easiest way, and thinking in that way makes you an SA. Not only developers but other teams might also crib for the same reasons, and you have to defend your solution like your baby—that is what I call ownership.

When I say defend, that doesn’t mean you have to say it is my way or the highway, but always be prepared with rational reasoning and an explanation of why you did what you did. Having the pros and cons or a comparison metric always makes a difference and helps people understand. When you have to defend or explain yourself, talk with facts and figures—just saying that you are the SA and you can do whatever you want doesn’t work and will just be rude. As I mentioned earlier, SAs have to work with many teams, and having the right attitude is the key to having synergy.

Now, let’s talk about some of the challenges aspiring SAs and new upcoming SAs might face. They still tend to be in the persona of their earlier role, and as they might have not faced these types of situations, it is tough to react in the right way. The best thing to do when you go to a meeting where your design is going to be questioned is to be prepared and have all the facts ready to discuss. Now, as we discussed earlier, having the right mindset and attitude helps in confronting this kind of situation. If you made a mistake, own it. Trying to rationalize a mistake is like adding fuel to the fire. It also tarnishes your credibility as an SA. It goes without saying that the more knowledgeable you are, the humbler you become. Ownership is not only for the name and fame but also for your mistakes. A humble acceptance makes you a better SA and helps build a rapport with others.

To summarize, an SA is the owner of the solution, but at the same time, has to get feedback and blessings from other teams and stakeholders to get the design approved. They have to be patient and humble and have an open mind to suggestions.