February 25, 2022
Marco Rodriguez met the Compoze Labs team as a business analyst contracted to the same client project. There he stood out as a person who wanted to innovate and do things better. In a recent conversation, he breaks down how he views his role as a business analyst, how it breaks from the standard mould, and shares some of his perspectives on improving the industry.
The label itself means different things to different people. Really, the work can fall under many different names, but it usually comes down to being a link between the multiple types of people involved in a project and implementing a strategic vision for increasing efficiency within an organization. When I started, the role was mostly business and not that technical. I would start by gathering requirements for a particular project and guiding the conversation when discovery needed to happen, changes needed to be understood, and quality needed to be improved. Throughout my six and a half years in that position, I evolved into the role that I play today which is just as much technical as it is business-oriented.
There’s several things. One is including more technical considerations into my work. In a lot of places, the business analyst relies too much on other roles like architects or tech leads to discover and shape ideas. Obviously, those roles are paramount when the time comes, and they can do things I can’t, but I can understand and communicate technical ideas without involving them prematurely.
Another part of this evolution is the inclusion of design and UX direction. This is another area where a BA doesn’t need to rely so heavily on a third party to drive the conversation and shape the work that needs to get done.
A third piece of growing into this role was finding ways to maximize my own efficiency. I find it incredibly important to find a process that strikes the right balance between well-supported, structured approaches and the freedom to adjust the rules of engagement to the particular needs of a client and the corresponding teams.
Established companies have processes and rules that might be easy to implement at a large scale but may not fit every project and every circumstance, and can ultimately become too restrictive. On the other end of that spectrum, an organization might be so new or small that they lack enough restrictions, which, yeah, opens up possibilities, but it could mean you then lack the internal direction and support to capitalize on new, process improvement opportunities.
In this position, it is key to be able to think abstractly about all the pieces that make up a problem. I connect them together and line up the appropriate resources to solve it incrementally. I’m never going to be an expert in any one domain, but I know enough to know when to involve other people and that saves a lot of time.
“In this position, it is key to be able to think abstractly about all the pieces that make up a problem. I connect them together and line up the appropriate resources to solve it incrementally. I’m never going to be an expert in any one domain, but I know enough to know when to involve other people and that saves a lot of time.“
– Marco Rodriguez
In the way I am dreaming up this new venture, the technical side of this work has two dimensions:
First is leveraging technology that is already out there and considering the ultimate goal you would like to see achieved. For example, if the goal is to have a great e-commerce site, the thought process should be customer-driven and you should consider the options that already exist and would allow you to quickly provide the services a customer needs to get your products. And it is more than just finding services that are out there for you to use; it is just as important that you sort through the competing options, choose the most optimal one, and implement it in the best way.
The second dimension is asking what doesn’t exist yet and could be created to make things easier. A lot of companies (and individuals) don’t invest in this area enough. It’s always worth investing in internal innovation, in custom tools, in custom pipelines and workflows that make things easier for specific projects and specific teams. The way I see it, business analytics has to recognize the importance of both existing and potential technology solutions.
I was expecting to hear more about spreadsheets full of sales data and how to push the business forward by reducing operational costs and making more sales, but it sounds like this role is much more creative than that.
What you’re describing does exist, but it makes me wonder, when an organization “has the data”, do they actually have what they need? Do you have the right information or just a giant snapshot that you have to somehow make sense of? At a superficial level, yeah, it’s gathering data points about the business and letting that data drive decisions that will hopefully improve the business, but there is a lot that has to happen before the “data” becomes helpful. A lot of my job is questioning the norms of how we do our work to try to discover better ways to achieve our goals.
This stems back to those two dimensions of technology a BA has to consider. In order to acquire quality data with which to make business decisions, there is a lot that has to be in place first. You need to have the right tools (and there are right tools) implemented correctly and tracking the right information, and if you are developing something on your own you have to think about what you are trying to get out of it besides just completing some task.
The data collection and employment strategies vary quite a bit based on the project context (what is being sold, who is buying it, where in the world and through what channels things are happening, etc), but what I would like to see more across the board is an internal examination about how clients themselves (or by extension any partners or agencies they use) are executing the work they are aiming for. Not so much about how the work they are doing is affecting their business, but about how well any given piece of work is being done.
A good example of this is one of my most recent clients, who is actively interested in tracking the difference between what we estimate a piece of development will take (in terms of man-hours) and what it actually ends up taking. Up until now, no one seemed interested in tracking and studying that difference overtime; if a task is estimated to take 20 hours and it actually takes 25, we usually say “oh it’s just 5 hours” and move on.
Merchants are often so preoccupied with publishing changes as soon as they can, they don’t stop to analyze the efficiency of the work it took to make those changes. That kind of information over long periods of time can drive much more impactful, overarching decisions. Being informed is the first part of driving positive change, and that’s why I think it’s just as important to look inwards as it is to look outward.
It depends on what we mean by “product lifecycle”. Certainly a product could be a tangible good being sold, but it could also be something like a website, application, or a component of an integration map. Agencies often think of what they do as a service – they provide time and expertise – and don’t see their work as product development. However, many of those services that are developed could, in fact, be considered a product, because at the end of the day that which is launched is static until the next time a change is deployed. What happens between those changes is what I would loosely consider to be the lifecycle. However, multiple development cycles could happen between each change released to the public, and the frequency of those deployments could range from daily to annually, but technically, every time a change is released to the public a new product is released. This question is interesting because if a BA does their job well enough up in the beginning of the development cycle, their involvement throughout the rest of the cycle is actually minimized. The job of a BA is to tee everyone up for success by clearly defining objectives, establishing how the dev team needs to work together, and getting everyone on board with the best solutions. From there it is a relay between the members of the dev team to produce something and for the business analyst to check in periodically and make sure things are going as planned. At the end of the development cycle, the last thing to do is to test and verify that what needs to happen is in fact happening. Sometimes that is done by a quality assurance team, sometimes it is automated, but I also believe in being personally involved in vetting whatever was created. This not only ensures a quality product but holds people accountable and creates traceability of where mistakes happen as a way of preparing the business for future projects. In an ideal world, all of that testing would be done by machines, though we are still a few years away from that.
The future is ripe with potential for improvements in systems integrations. Good or bad, automation is necessary for the future we are moving towards. It’s possible to minimize the work done by project managers, quality assurance, and product testing. Even in the development cycle, there is a lot that can be optimized.
Where work can be done better by a machine, automation will allow the people currently in those positions to work more creatively and solve new kinds of problems. While we are still a few years out from that, a key step in getting there is just making sure you have the right data to inform the teams building new software.
This type of work will expose us to brand new challenges, enable us to understand the data that exists in our pipelines, and push us to build new frameworks to help draw meaning out of it all. It all plays a part in finding innovation in spaces we can’t yet imagine.
Beyond that, I see the potential for integrating work and real-life in a way that feels more natural. Most of my time in general is spent thinking about things; I think about work all day, but I also think about many other things all day.
I start my morning with something productive that doesn’t involve a screen and then go back and forth throughout the day doing things for work and other personal projects. A job that is independent and creative lends itself well to that kind of holistic approach.
If you would like to get Marco to help lead your next project, you can visit his consulting site humbird.solutions. And if you are in need of expert software development and integrations who partner with awesome business analysts like Marco, send a message in the box below!
