Description
This session focuses on transforming traditional organizational structures where development, operations, and other teams work in isolation and do not . By breaking down these silos, organizations can foster better communication, collaboration, and ultimately, a culture of continuous improvement.
Emiliano Rodríguez – RevOps Architect, Go Nimbly. With 7 years of Salesforce experience and 27 certifications, I’m passionate about DevOps and its impact on development efficiency and quality. At Go Nimbly I love breaking silos and helping top SaaS companies streamline deployments, improve release management and scaling their systems.
Transcript
Perfect. Okay.
This is working? Perfect.
Hi.
I would like to first start saying thank you for taking the time to attend this conference. Thank you for Giza for inviting me. It's been great working with you guys, and especially to attend this session.
I'm gonna talk a little bit about today about how we can build a real DevOps culture on our teams that actually unite them and drives real results.
To start, I want to introduce myself. These cool guys call Emiliano. I'm from a small country in South America that's called Uruguay, not Paraguay. We get confused a lot.
Featuring Argentina, I'm Brazil, and I work as a revenue operations architect and self resolution architect at Go Nimbly. This is a revenue operations consultancy firm.
For those of those that are not kinda into the RevOps space, what we basically do is help marketing, sales, and go to market teams build their own systems and basically streamline processes.
Most of these processes living on the Salesforce platform, so that means that we basically work with sales, marketing cloud, service cloud, CPQ that we don't like too much, but we work a lot.
And that's basically us. These are some of the customers that we work with and we are really proud of.
Before we dive in, I would like to start asking everyone this question and raise a hand if you have faced this.
Have you ever worked on a project where one team had no clue what the other team was doing?
I want to see some hands.
I know.
Everyone here has faced this situation in the past, at least one in their life, and nobody likes it. We know that when this happens, this is when the chaos begins, teams on the line, and we get the worst results.
In this session, what we're gonna do, I'm gonna talk a lot a little bit about why this happened, how we can fix it, and how we can create a real DevOps culture on our teams.
But before we start to talk about everything, we need to start defining what is DevOps.
DevOps has two concept, different concept when I start talking with my customers. The first one, when they don't know anything about DevOps, is perfect, new process, now I need to put more work into my job.
The second one is that basically we're gonna talk everything about Gits, CICD, and automation deployments, automated deployments.
And the reality is that, yes, DevOps takes some process and time at the beginning, and it's supported by a bunch of different tools and technologies like Git, pipelines, CICD between others.
But I can bring this I want to bring this idea to these people that we are here. You can have the best pipelines in there, but if your dev teams keep shipping code to QA without giving them any context, they're gonna cross it. If your operation folks feels that you're not listening to them or they feel blindsided, they are not gonna trust your shiny new features, and this can go on and on affecting the whole organization, not trusting the system that they use daily, basically.
For me, DevOps is more than pipelines. DevOps is about the tools, the peoples, and the processes being aligned together towards a common goal and trusting on each other.
And I really want to focus on this word, trust, because from my point of view, trust is the backbone on any successful level of process. Without trust, collaboration doesn't exist, processes slow down, and alignment becomes impossible across all of your different teams.
And you know what is the biggest barrier for alignment teams and people?
Silos.
Silos are the biggest barrier in any good company culture. The worst thing is that ninety percent of the companies that we work with suffer from this, but they are not aware of it.
When we start working with a new company, usually, we take some key stakeholders and power users from the system and managers, and we ask the following question.
Do you feel that your teams are truly working together towards a common goal or they're just existing under the same corporate roof?
We usually get some mixed feelings about this because nobody wants to say, oh, we have a silo issue or teams are not collaborating between each other. But the reality is that as you get to start asking more and more questions about it, you are gonna find that, basically, you have at least some of the silos issues.
But the question is what caused these silos on your company?
Spoiler alert, usually is your company on success.
As your company keeps growing, you start to hire more and more people.
Because you are growing, you don't have usually the right onboarding for them. So what happens is that they don't have the full context about the company, what we do, and what other teams are working on. And because you start to hire more and more people, usually, that people has some degree of specialization.
That means that they're appointed to being the person that works on, for example, on customer success only. And they start to having, like, this vision tunnel vision about, oh, I only work on customer success. I don't care about what sales, marketing, or other teams are doing.
Because now you have more specialized people, that usually leads to have a specific business focus unit. So now that specialized people is talking only with another specialized people, and, basically, they are not interacting with other teams.
And because you have different teams now, that means that they have their own KPIs and incentive mechanisms.
So, basically, they are pursuing their own goals, and they don't pursue the company goal as a whole.
But what is the way best way to know if a company has any of these issues? Some looking for some of these signs. Is one of these teams generating valuable and actionable information and not sharing it widely with other team members?
Do you feel that they'll you see a lack of collaboration between them? I'm not talking about only about sharing documentation.
I'm talking about sharing a skill set. Group a bunch of different people folks from different teams to drive a new role for the company. Do you feel that they're using some misalignment language? And by misalignment, I'm talking about I don't know what they are doing over there when they're referring to different teams, which you don't talk that much with that team. We are not on the same page with that team.
Do you see them competing with each other?
By this, I'm talking about, like, showing off they don't work and trying to downplay other teams' work.
And do you hear them talking about team by by incident identity? By this, I'm talking about referring them as my team, my sales team, my marketing team.
I'm gonna talk talking about my team, my sales team. And I really want to, take a moment to ask Apple.
Basically, what I'm gonna do is I want to ask everyone here to pull up their phone and answer a small question. Do you see any of these silos issues on your company?
See a lot of people responding.
Okay, so let's take a look at the different results.
So what we see in most of the company is the lack of collaboration. This is a real common scenario because teams are focusing on their own thing.
We are seeing team bias identity, everything like that. Basically, what we are seeing is the lack of collaboration is the most common syndrome thing that we can see on most of the companies.
Usually, what they are doing is we are creating actionable documentation or implementing a new process on our system, and we are not really sharing that with other teams.
The team based identity is a really big one too that we see in a lot of companies. Basically, these teams are only focusing on their own thing and they're proud of their own work and not the work as a company itself.
So that's something to take care of. And what is causing these silos? Well, we agree is that we increase new specialization.
It is really common because we hire people to do specific tasks and they are only focusing on those.
I want to move to the other thing.
Cool.
What we usually see is that all these silos symptoms and cultural things are leading to what are product and processes silos too.
What we are referring to, basically, is that this is a real example of one of, like, of the customers that we work with. And when we started working with them, basically, we did that question about, do you think that your team is truly collaborating with each other? And the password was instantly, yes, they are collaborating.
But as we started reviewing the process, basically, what we devised, like, we have four different teams working on that moment.
We have product, marketing, revenue operations, and the another consultancy framework.
For product, for task tracking, they were using linear. Marketing was using Asana. RevOps was using Notion projects and solve first cases.
And the other consultancy company was using Jira.
For tracking changes, product, because they're more tech savvy, they were using GitHub. Marketing was using a spreadsheet. RevOps was using Notion pages, and the other consultancy company was using Confluence.
For deploying changes, product was using GitHub actions and sell for CLI. They have their own CI process. They were not using Gear Set at the moment. Marketing was using Change Sets, RevOps was using Change Sets, and the other consultancy company was using Change Sets, and even sometimes we're creating everything on production.
Pretty obvious how this can damage not only the company culture, but also your overall success because let's be honest, when this happens, it's a mess. Everyone is working on their own work. They are not collaborating with each other. That usually leads to a lot of rework, blocking work from different teams, overriding data points. That is a key thing that happens always.
And it's really a mess.
The biggest question that we usually get is, like, what is the issue with this? And the reality is that it leads to a lot of finger pointing because now teams basically are having issues when they interact with each other and they start saying, is the product team fault for not testing properly? Is operation does it block in everything at the last minute? These blame games keeps on and on and kills morale, slows delivery, and even worse, at some point, the teams stop to work together because just they just expect the other team is gonna be a pain to work with.
These silos are not created intentionally.
Nobody wants these to be the culture of a company.
But ignoring them doesn't make them go away. In fact, it usually makes them worse.
The good news is that once you identify these silos, you are halfway of solving them.
But the next question that we usually get is like, okay, I know I have some issues. How I can get the developers, operations, QA, or even high level managers on board with having a DevOps culture at my work.
The first thing that we need to be aware of is that we're gonna be working with people and teams.
The first thing that we need to start asking is what they're caring about. For example, dev wants to have usually speed and creativity freedom. Operations might be caring about uptime and stability.
QA usually wants to have time to test everything end to end. And managers must be caring about deadlines and budget. The key is to show each group how DevOps culture is going to make their life a little bit easier.
For example, let's start asking or telling our dev how the integrated workflows are gonna reduce late night fire drills.
Talk with operations that they're gonna be involved earlier so they don't need to fix last minute surprises.
Talk with QA how they can collaborate from the beginning instead of being the last gate before the point changes to UAT on production.
For management, highlight metrics like fewer rollbacks, faster releases, and happier customers.
By hitting those unique pain points, you are gonna help to see everyone here that DevOps isn't extra overhead. Instead, it's a solution to the issues that they face daily.
And I don't I know that I talk a a lot about trust, but, really, for us, trust is gonna be the foundation of any process. And we have seen a lot of trust being gained using GearSet across the teams.
So how we can execute this on our teams with some actionable steps?
At Goonymely, basically, we use a four step process. Basically, we start crawling, then we walk, then we run, and then we fly.
That is really effective when you have teams that have never interacted with DevOps or basically that they have one of the silos issues.
And we are gonna start slowly with some baby steps. Basically, to gain the trust over the teams or allow them to explore the solutions and the processes, what we need to do is build a foundation. And the foundation is gonna be built with backups.
Backups, basically what it's gonna allow us is to set a space where team members can make some mistakes, but they're not gonna punish them.
Thinking about this way, we can have metadata backups, and that means that if we deploy a flow or overwrite something, basically, we can restore to a prior version. And the more important ones are data backups Because if they deploy something, an automation that is wrong or not working as expected and they override a data point, we are gonna be able to restore that and keep the business working.
What we need to agree is to have on the project side a unified task tool. As we were seeing on on the previous sample, we have four different teams working on four different tools to track their work. Basically, we need to agree that we are gonna use a unified task tool and this task tool is gonna give us a three sixty view of all the teams and different operations people that is working there that is gonna deploy changes to Salesforce.
When we have this unified task tool, what we're gonna introduce is like a task refinement process. This is a fancy name to say that we are gonna have some sessions where we're gonna have different team members from sales, marketing, or any operation team that is making changes, and we're gonna discuss the work that we are gonna do. This is gonna give them the space to collaborate and start giving feedback to each other and avoid things like marketing once you use a field on the contact level to, I don't know, define, for example, I don't know, specific KPI, and then sales wanted to use the same field with the same different value to define something completely different. Giving the space to the teams on this specific session is gonna allow a lot of feedback and start setting the foundation of the collaboration.
Related to the environments, basically, what we need to do is introduce the concept of a developer org. I cannot tell you how many of the customers that we work.
In the best case scenario, they have a partial sandbox only, but they don't have a clue about their org or they're making changes in production directly.
So we are gonna start building this foundation of, hey, we have different environments that are responsible of different things.
Dev is gonna have all the in flight work. QA is gonna have everything that is in flight that needs to be tested, and production is gonna be, or basically, the final gate.
To move changes because we are introducing gearset to them, basically, we are gonna start with org to org deployment.
I know this is not perfect, but org to org gives them the space to basically start playing with the tool and see all the features that we have.
So what we're going to do is move changes from there to QA via or to our deployment and then from QA to production via or to our deployment.
This usually takes between three and six months to the different teams to start exploring with the tool, getting used to move everything to a unified task tool, and talk about, like, and introduce a task refinement process and everything. Once they get used to this, basically, we they can start to work. And work what is gonna introduce, basically, a little more activities that they're gonna have and different responsibilities.
For projects, we are gonna introduce the concept of sprints, and sprint is a fancy name that we're gonna put in. What is important about this is that they're gonna have a space where they're gonna agree all this work is gonna be executed in a specific period of time or in a specific number of weeks, days, whatever.
And we are gonna agree on specific days that we are gonna use for deployment.
It's important to have specific days for deployment because what we want to do is introduce the concept of using release notes for the team. Because these teams have not collaborated in the past with each other and they have not shared the information broadly with other teams, allowing them to have a specific day for deployment means that they can gather all the different tasks that they're pushing into production and create create release notes about those and sharing it with other teams, the whole company, so everyone is aware of all the changes that we are pushing.
For environments, basically, we're introducing moving from one dev org to multiple dev org environments.
And this will allow each consultant, dev, and QA person, and especially administrators to basically work on their own environment and not touch anything or block in other team members.
We are gonna keep our QA sandboxed and, of course, crawl.
But to move changes, basically, what we're gonna do is introduce the concept of pipelines.
This process usually takes a lot of time because we are saying six months because we're introducing the concept of virtual control, branching strategy that they're gonna use the new compare and deploy tools, but they're gonna be on specific feature branches. And we are gonna introduce the concept of automated deployment.
What we have seen is that people is kind of afraid when you automate the deployment or the deletion of something. So basically what we are saying is that for this stage, what we are gonna do is the automated deployment only is gonna deploy new and change things.
If you want to delete something, you need to do that as a post deployment step.
This, again, takes around like six months.
And after the team has get used to this, what we're gonna do is introduce the concept of a unified documentation tool.
By unified documentation tool, take take into consideration that we have all these different tools that we spoke before. And now we want to centralize all the data of all the changes that are happening in our system into one place.
We are gonna introduce the concept of retrospectives.
What we are gonna do on retros basically is allow the team to give feedback and start building their own DevOps culture.
I'm talking about they can, give feedback about how deploy things, how they track different changes, how they are introducing different gates for quality code, and things like that.
For environments, we are introducing the UAT.
We don't do this on the previous step because it's usually a lot to digest. But on this step, they're gonna have the concept of UAT.
And so so we are going to have the gauge of, like, dev, QA, UAT, and production on UAT.
Final users are going to test everything and give the thumbs up before it goes into production. This is, like, a fine prereview thing before they go into production.
And to move changes, basically what we're gonna do is track pause and pre deployment steps on GearSet. This is an all new tool, basically, but we have seen that it's really useful because now when you move things between different environments, what is happening is that you have a place where you can visualize everything. So it's really good to track pre deployment steps and have a unified view.
And then when they're ready to fly, basically, here the sky is the limit, to be honest. And I don't know if I should call it like an additional step or is when your team is ready to implement or iterate over the process and implement as many things and automate as many things as they want.
We have seen customers, for example, implement the automated release notes with notebooks LLM, creating podcasts with the content of the release notes. Really useful to create that engagement with the different stakeholders.
And to move changes, basically, because at this moment, everyone that is involved in the process is owning it and fostering on your organization.
So instead of having a Delta deployment, you can deploy your full repo and everything that is not gonna be there is gonna get lost. That is gonna basically punish anyone that is not following the process. And it's really gonna enable the end to end process to track all the changes that are happening in your organization.
And with two minutes left before I wrap up this session, what I would like to do is, like, summarize a little bit of this presentation into four takeaways that I would like everyone to take home.
The first one is that DevOps is not only about the pipelines and the automated deployments that we have on our company.
It's about creating a mindset of shared responsibilities for everyone that is involved in the process.
The second one is that breaking down silos, to break those, basically, we really need to foster a collaboration mindset, allowing feedback, having shared channels, and allowing every team to express what is important for them and let the voice of them be here.
Trust will be the backbone of any foundation of every DevOps culture and any culture of your company.
Teams need to feel that you have their back.
If they feel it that way, they are more open to adopt new processes and new tools on your organization.
And the last one is that transformation is not gonna be something that happened overnight.
It's happened one small step at a time. You need to be consistent and celebrate every baby step because with some time, that is gonna allow your team to work, run, or even fly at the end of the day.
And with nothing much to say, I would like to thank everyone for taking the time to come here and hear me out. And I hope we are on time.
Thank you.
