Episode 16 [SREpath Podcast]
Ash Patel interviews Sreejith Chelanchery who is SVP of Delivery and Infrastructure Engineering at Dotdash Meredith.
Sreejith shares his journey from programming analyst in Bangalore, India, to now being an executive responsible for platform engineering, DevOps, and SRE at a media giant in New York City.
He gives a glimpse into how his team saved his organization over $9 million in cloud computing costs, how they started an internal developer platform well before Backstage was around, and more.
Sreejith also sheds light on how changemakers and advocates like SREs can win over business and other non-technical stakeholders.
You can’t miss this conversation!
Episode Transcript
Ash Patel: Great to have you on, Sreejith. You handle the SRE function at Dotdash Meredith. Can you tell me about you, your company and how you work in the SRE space?
Sreejith Chelanchery: Thank you for having me, Ash. Yes, I work with Dotdash Meredith. We are the largest digital publishing company in the US, potentially even in the world.
We own a large portfolio of brands and we are the umbrella holding company for those brands in producing the digital content that our users love.
My role within the company is as a delivery and infrastructure engineering SVP.. As part of that portfolio, I lead DevOps and SRE engineers as well.
Ash Patel: You’ve had quite a history with the space. You’ve grown into the role. You’ve worked with several companies in helping them establish better practices and software operations. You were at Barclays doing QA and analyst work. You were at Southwest Airlines as a test specialist. At eBay as a test specialist. At Barnes and Noble as a testing…
So testing is a big part of your work.
How did you transition from being in the testing space into something that’s more broadly related to DevOps and SRE?
Sreejith Chelanchery: So essentially, I began my career with Cognizant as a programmer analyst and I was trained in Java. And after that, they put me on a project which required testing expertise and that’s where my actual professional career began.
The first few projects that I worked with was from India, and I worked as a QA analyst with eBay, Southeast Airlines, and after five years in India, I moved to the U.S., and I worked with Barclays and Barnes Noble as a test analyst. So, what helped me in test analyst role was my ability to critically approach what we are building and how we are building applications.
That is a transferable skill even in SRE or infrastructure space how you build applications affect the reliability and resiliency of your applications when you run them in production.
So, I wouldn’t say they are actually very disparate fields. They are very tangential to each other and the skill set are very transferable.
At About.com we were actually looking to build more of traditional DevOps and SRE practices, like seven, eight years ago when I was at about. com.
At the time, our initial project was, how do we get to a cloud provider instead of our traditional data center?
We did not have a team focused on either migrating or having a lot of that expertise. I had some exposure to DevOps practices in building automation for deployments and things like that as part of my test analyst or rather test manager role at the time.
Then I worked with my boss and my team and figured out how do we automate some of those workflows.
And that’s how I got introduced to the SRE practice. I wouldn’t call it SRE at that point. It was more of like DevOps and like more automation at the time.
Ash Patel: So building CI/CD was a big part of your job at About.com. So even if you started off in a more pure test function, you then developed your abilities and helped the company to, for probably the first time, bring about a more sophisticated functionality around continuous integration and continuous development.
And that was around several years ago, right? It was about seven years ago.
Sreejith Chelanchery: Six, seven years ago. That’s right.
Ash Patel: So that was just around the time when DevOps really started to take off.
Sreejith Chelanchery: So again, having grounded a lot of my initial professional experience in testing, CI/CD was something that I was naturally gravitated towards.
Right? Because CI/CD allows you to actually build and deploy applications with confidence into production because you actually have a sense of confidence in what you’re deploying to production having run your application through a series of tests, especially through CI/CD because many, many organizations, many companies say CI/CD in a very lax manner where most of them actually embrace CI/CD as an automated deployment.
But what we thought about was at its core CI/CD should include thoroughly vetted application changes, run through a series of automated tests and make automated deployments without a human involved in the whole process. So we started from packaging the application, deploy a test environment in an automated manner.
Test the application, collect the feedback in a binary form, if all the tests are passed or not. And if all the tests are passed, we actually deploy the application into production again in an automatic manner.
So it’s, it’s pure magic at that point, right?
We built that CI/CD platform six years ago, I would say.
So that truly automated platform. was how we built that SRE aspect of reliability at Dotdash.
Ash Patel: That would have improved your deployment lead time significantly.
There are so many companies still trying to figure out what you just mentioned, and it’s good that you mentioned it because sometimes us in more technical fields think, okay, well, hey, look, DevOps is done.
We need to focus on the next thing. We need to look at how we do AI. But a lot of companies are still figuring out what to do and I think it’s coming down to, even in the state of DevOps report that got released a few days ago, there are still companies who have a change lead time of between a week and a month.
It’s crazy to think that there are companies that still not able to pull it off and that’s why it’s important to have a meticulous function and a method to actually executing on all this. Do you have any thoughts on how some of the low and, say, maybe medium performers in this report could look at improving how they’re doing DevOps, even though it’s been around now for over a decade, they’re still struggling.
Any ideas?
Sreejith Chelanchery: So I think there are many facets of the state of DevOps report that you’re mentioning which are relevant to SRE practices and which are relevant to how you approach deployments altogether, right?
I completely understand where the DORA report comes from, right? Like it’s not about just the lead time, but how often do you deploy, right?
Because that can naturally help you as a business. If you have built the capability, make application changes, as often as you want, that allows you to experiment and let these application features face the users for a prolonged period of time than you would be able to do otherwise. Right?
Like as you mentioned, some of the organizations in the low, mid, mid end of the spectrum take weeks to deploy application changes into production.
That is lost opportunity. You could have actually deployed a change into production a week earlier and gotten true feedback from your user a week earlier. If you had built that capability to deploy more often and deploy with confidence. And I, I emphasize confidence because there’s no point in just deploying for the sake of deployment .
You shouldn’t be looking to actually get called on a Friday night, having made a change, having made an application change on Friday morning, right? Because you want to actually, like take care of application changes with confidence and let go of it once that goes into production.
So going back to your question about how some of the organizations are missing out, this lead time, which has been reduced by having an automated test and automated system to deploy allow you to make those changes multiple times a day if you build it well, right?
Because if your pipeline can actually build package, run test and deploy applications in about an hour, you could potentially deploy multiple changes in a day without any human being involved.
That is a capability that would help make the business respond to changes much more quickly. And that last opportunity is what I would again point out.
If you don’t have that capability, you’re missing out on not being able to deploy changes and respond quickly
Ash Patel: Playing devil’s advocate for a second, I think a few people in some organizations might be saying, well, we don’t need to make changes that often. Our software, it doesn’t change that much. But if you look at responding to customer needs and desires in this day and age, that’s a pretty 2010 kind of perspective on software.
Sreejith Chelanchery: If you think about it, yes, there are probably regulated industries like Boeing, I think. When they released forget the model few years ago, if they had actually tested it well enough, they wouldn’t run into all those troubles that erased billions of market value from the company.
Ash Patel: Oh, you mean the 737 MAX?
Sreejith Chelanchery: Yes. It emanated from not having enough tests and not having enough certification in what they were actually building in that model. So yes, there are regulated industries and specific use cases where you may not be making as much changes as a website.
That’s a very different use case. But if you are a digital business, that’s not the case, right? A lot of your market advantage comes from being able to make these changes quickly and benefiting from having those changes out in front of the user as early as possible. You could run it as an A/B test too, but even then, if you have not tested those features enough, you are falling into the same trap.
So making smaller incremental changes is a powerful paradigm that any organization should embrace.
Ash Patel: And we should always have processes in place that those small, regular changes don’t break in production and make an SRE’s life hard.
I can actually give you an example. My experience in a regulated space. In the healthcare space.
We had a vendor who probably took the idea of deploying changes quite to heart and they were doing changes daily. But it was breaking in production. And it was noticeable to our clinicians.
You never want that to happen. Because if a clinician notices it, they barely notice that they’re even using software. If they notice, that’s trouble. So there always need to be processes and the right kind of people, process and technology in place to make sure that this doesn’t happen.
Sreejith Chelanchery: That’s where it all ties together, right?
Because at the heart of SRE practice is like, how do you facilitate and how do you enable these tiny little changes where they’re not involved in this wider changes, right?
They build a platform that orchestrates such changes at scale.
Again, I am going back to one of my original comments. Releasing with confidence that comes from building a lot of automated test that thoroughly vets the change that you’re deploying into production. And that is also where my experience with testing and care functions comes very handy.
Being able to actually evangelize and advocate for confidence building measures has helped me in my career progression as well. To give you an example, when we acquired Meredith, which was much bigger than us as a digital business in 2021, when we looked at the organization’s software development practices, one of the things that easily stood out for me was how they approached CI/CD.
There was not enough of automated checks and tests in place, so we honed in on that at the senior leadership level. We made sure we are actually investing in building a lot of automated test capabilities as part of our integration measures, and that’s a message that our CFO also even bought in.
Because everyone realized having a true CI/CD allows us to actually embrace making changes and deploying more often. That is at the heart of how I sold it to our executives as well. Obviously, that’s part of the narrative in how you build an SRE function.
Ash Patel: You’ve implemented quite a few practices in just the last few years. I’m looking through a few of the things I’ve written down, and you’ve had some pretty amazing wins in just the last year and a half.
The first one is delivering cost optimizations by consolidating application fleets and migrations with close to 9 million dollars in savings?
So you’ve delivered close to nine million dollars of savings in a year by doing these cost optimizations.
That’s an amazing achievement. I think any organization would be proud to save anywhere near that amount, or even a fraction of that.
Sreejith Chelanchery: I, I don’t disagree, but I don’t think we at the organization can take all of the credit. I have to say, we were in a very fortunate position where the prior technology organization at Ancestral Meredith, were slightly wasteful, if I could use that word in how they utilized infrastructure to support their digital application ecosystem.
So that helped a lot. So there was a lot of low hanging fruits, which we could utilize in completion that cost savings. But even then, as you said, 9 million is a lot of savings. A lot of it came from being able to actually remove redundant application stack as well. And as I said, previously, there was not a lot of emphasis put on removing legacy applications in the previous technology organization.
So being able to focus on removing deprecated application and infrastructure, being able to consolidate the application feeds to only have application that actually has core business value is what allowed us to realize those cost savings.
Another aspect that we actually applied to some of the Meredith tech stack was the financial engineering and as an SRE organization at ancestral Dotdash, we had approached infrastructure orchestration very differently than ancestral Meredith.
We are actually blessed with one of our amazing, a unicorn type of an engineer slash thought leader who actually helped us build a very intelligent pod compaction in the infrastructure that we use. So we placed containers within our compute instances based on how much each application needs and we pack multiple applications into an EC2 based on how much our memory or how much our compute usage is possible for that instances.
That allows us to actually like optimize how we are using cloud infrastructure. Obviously, Kubernetes also has brought in some of those capabilities, but we were doing that even before we embraced Kubernetes.
That approach of forward compaction and optimized infrastructure utilization is also at the heart of how we were able to apply those techniques into ancestral Meredith tech stack and realize the cost savings as well.
Ash Patel: Well, I think it goes without saying that you have a very large footprint in terms of how much infrastructure your organization uses. A lot of people might not have actually heard of Dotdash directly, but they would have engaged with at least one media property in the last few years. Can you give a few examples of media properties that people would have heard of that Dotdash Meredith runs?
Sreejith Chelanchery: Yeah, you’re absolutely right. I think Dotdash Meredith as an umbrella brand don’t have as much of a brand recall .
And that partly that’s because we are a younger company from that perspective compared to a lot of the other publication companies like Conde Nast and Hearst, which has been around for, at least decades or multiple decades.
We have been around as about. com for about two decades, but Dotdash is a incarnation of About.Com that only started seven years ago. So Dotdash Meredith is obviously not a well known brand, but we actually hold household names like people.com, Better Homes and Gardens, Investopedia.com, Worldy, among others.
Our slew of brands actually roll up to about 40 and most of them are actually have a very loyal following like Serious Eats has a very niche and very loyal following in, in the US.
Ash Patel: I have used Investopedia so much, especially during COVID, when we were all trying to figure out what are we actually buying in the stock market? What exactly are we doing now? We’re all trading. So that came in very useful.
I’ve engaged with a Dotdash property without even knowing it was run by your your team. Your team kept it up and running.
Sreejith Chelanchery: That is right. That’s right. And there are many even smaller brands which you come to us for answers. Our focus is providing relevant answers to the users when they have questions in many parts of their life. Like when you are interacting with Spruce, which is our home site.
You are actually basically asking about how do I paint my house? And Google as a gateway leads you into our content. Our quality content is what helps us gain more of the users and more of the traffic from Google.
Not necessarily the brand recall, but the strength of our content in answering the questions that you have at different points of your life.
Ash Patel: That brings up a thought I had in my head. So is SRE about the same age as Dotdash because it started about seven years ago? And that’s when companies, especially in Northeast, in like the New York area, started taking up SRE?
Sreejith Chelanchery: That is a great parallel analogy you brought up. Yeah, I would say yes, right?
Because if you look back when Google started actually publicly talking about SRE as a practice, that is about seven, eight years ago. So there is obviously that parallelism, though it is pure coincidence.
Ash Patel: Right, but it’s still correct to say that you’ve pretty much been with the company since it started implementing SRE more seriously.
Sreejith Chelanchery: Yeah. I think one of the good things about our engineering organization is we notice a lot of the trends in the industry and try to embrace them as much as possible and as applicable as possible.
Having read the Google SRE book, a lot of the engineering leaders bought into what that gives us. in, in terms of building capabilities in driving engineering efficiency.
Engineering efficiency was not a term that anyone had used until I would say at least in the last three years. We thought about engineering efficiency at the time when we embraced SRE.
My CTO would say, like, how do we make our engineers write and test code better. That’s nothing but a proxy to engineering efficiency. So even though you don’t use those terms in how it’s used now, we had been thinking about it much earlier in our journey in adopting SRE. So engineering efficiency was a big part of how we implemented and approached SRE at Dotdash Meredith.
We wanted to actually provide tools to our developers and QA engineers in building and testing applications as seamlessly as possible. Because if you think about it, that is part of engineering efficiency. If engineers are able to actually remove the mental toil of how to get this change tested, that’s a great win.
Similarly, if QA engineers can remove the mental toil of how to deploy those change, how to get those changes deployed into production, how to get it automatically tested. That’s all making these functions more efficient. So engineering efficiency was at the heart of how we approached SRE.
Ash Patel: I was teasing earlier about how you have made a lot of changes in the last year and a half and you’ve had a lot of wins and I think that one of those things was engineering efficiency. You mentioned Spotify backstage, but you didn’t use Spotify backstage. You actually built something yourself.
I’d love to hear more about that if you can share some details.
Sreejith Chelanchery: Yeah, actually, we should probably do a separate podcast only on that. One of my amazing engineering leader was partly responsible for building that application. So while moving to AWS, one thing that we were slightly concerned about was we want our engineers to be able to actually create ephemeral and test environments as much as they need. But at the same time, we wanted to have control over how much infrastructure that gets created and how much of that infrastructure is removed after its usage.
Backstage was obviously not available at the time, and there was no other solution as well.
So we thought about, like, how do we provide a mechanism to our engineering crew in being able to create these test environments and infrastructure that allows them to be more efficient. That’s how we came up with this application called Squadron. And we brainstormed about this for a few days.
And this amazing guy who actually took the problem to its heart, he came up with a Vue. js based application in about a week. He said “Here, Does this help in what you’re thinking about?” Absolutely, because it takes away the infrastructure orchestration from the users completely. You can interact with the web UI and create infrastructure without knowing anything about AWS APIs or how it creates infrastructure behind the scenes.
That was a capability that did not even exist at the time.
At the time, engineers need to know how to create infrastructure in AWS ecosystem using their APIs. This was sort of magical to see. And then we kept building more capabilities into the application to make it what it is today, where we call it Squadron, and that’s our one stop shop.
Where developers, QA engineers, product managers, and designers interact on a day-to-day basis to make their SDLC as easy as it is today.
Ash Patel: I like the name, squadron. Has a really cool ring to it.
Sreejith Chelanchery: The thought was we have an icon for Squadron, which actually like an airplane, right?
It allows you to build all these things in an auto magical fashion, so that, that’s where that name resonates.
Ash Patel: I think a few organizations who make their internal software should get a few tips from you, Sreejith, about naming applications or your team, at least.
Sreejith Chelanchery: Yeah, I wouldn’t take the credit for it if it’s a team, but absolutely, we have a lot of really cool names.
Globe. Selene. Really cool names. A lot of our teams actually put thought into what they name these applications internally and it’s very cool to see that they approach it with that, that amount of seriousness.
Ash Patel: Absolutely. I think it makes a big difference to the usability of that software, the internal software.
If a developer can actually remember it or thinks, Oh, okay, that’s a cool name. They’ll actually remember to use it. If it’s like a dull, like VM spooling system charger, I don’t know, something like that. They probably are not going to click through on and try and use that. They’ll probably try and use something that has an interesting ring to it.
Let’s shift gears for a minute.
I want to ask you about… What do you think is the biggest anti pattern in this space you’ve noticed in the last few years? You’ve been in this space for at least a good seven years, I think, in terms of, I think, testing people switched over quite a bit to SRE and DevOps practices.
So you’ve noticed a few things. What do you think is one anti pattern that really sticks out to you?
Sreejith Chelanchery: The one anti pattern that sticks out to me is tech debt.
Ash Patel: Technical debt? Interesting.
Sreejith Chelanchery: and how we handle it. There is, again, just like many other organizations, we also talk about how we should be organizing tech debt as part of our regular work and regular sprint schedules.
As much as we talk about it, there are always challenges in being able to accommodate close to 20 percent of our engineering capacity towards tech debt on a consistent basis. It’s an uphill battle.
When business needs specific features or specific orchestration capabilities, we always have to pivot, deliver those. And tech debt always gets sting.
As much as we want to actually keep 20 percent of our capacity towards tech debt, that’s one thing that we always struggle.
But one good thing is at the leadership level, we always try to reel it back in when it goes off rail and figure out how do we continue to actually battle tech debt on an ongoing basis.
So I wouldn’t say we are able to do it at a 20 percentage level, but trying to do it consistently is how we are trying to actually solve this.
Ash Patel: You’ve spoken about some of the technical challenges that you’ve addressed. Let’s talk about some of the organizational challenges, like you being an SVP now. You’re dealing with other VPs and SVPs talking about things in engineering. Have you faced any challenges in bringing across what needs to be done to achieve outcomes?
Sreejith Chelanchery: Sure. I think even going back, not necessarily in this current role, but like going back four or five years ago when we truly embraced CI/CD, there was a lot of organizational resistance because yes it is amazing to hear about a new paradigm in CI/CD, but what does it actually give me is what a lot of the organizational leaders think about, right? At least the engineering leadership understood the value of doing CI/CD from the outset. I wouldn’t say outset but at least from the beginning of the journey.
A lot of the business stakeholders saw no value because, okay, we are already running a lot of tests. We are already deploying. What do you mean by CI/CD? What additional capability does that really give us? We are deploying once a week or once in two weeks now. Being able to deploy more than that, do we really care?
But explaining and demonstrating how deploying more frequently is beneficial to them was something that we encountered as organizational resistance in that journey. So like being able to actually talk to the business and making them understand how deploying more often and more frequently allows them to actually see these changes and let the users respond quickly. That was the argument that we used as well. And then they slowly, they bought into it. So I think that’s one of the organizational challenges that I would say we overcame.
Ash Patel: Dealing with business stakeholders, I think in any organization, if they cannot actually see, if they haven’t experienced the technical side of what you’re talking about, it’s very difficult to get it across unless you make it really about what they value. And as you said, you have to show them that, hey, look, if you actually make these changes more often, you can see how the users are actually reacting to what you’re publishing, what you’re putting on the websites.
And if you can do that, you can stay competitive, possibly against social media itself, which is obviously the biggest competition to a media site, in terms of native content.
Sreejith Chelanchery: Absolutely. Our CEO talks about, we actually compete against the platforms like Facebook and other social media sites at this point.
That’s kind of our, our competition. So, yes, you’re right. Like I think for a lot of leaders at the business, engineering changes are scary, I think, and I think that’s the right word to use because that’s because not a lot of them understands how technology works besides what they see right in front of them.
So how we have approached in convincing these business stakeholders is trying to hone in on a few stakeholders who understands technology more than others, build confidence and consensus with them, and then take their help in being the evangelist for a lot of these changes with other business holders. Because they naturally gravitate towards someone who understands business more than a pure engineering or a technology leader.
So going and building a rapport with some of those business leaders with the technical acumen, and then collectively building confidence and selling what we are building to other stakeholders is how we approached that relationship building.
Ash Patel: Takes a lot of experience to get to what you have achieved having to deal with multiple stakeholders. And I suppose you’re several layers above what a typical SRE manager type would be at, so, they’re dealing with a frontline team of engineers. Would you still have some advice for them as to how they can better handle their responsibilities, especially if they’re a new SRE manager or let’s say even higher, a director of SRE or DevOps.
Sreejith Chelanchery: As a pure SRE manager, I’m not entirely sure how my experience would be extremely helpful for them, but I could chime in with what could be useful.
Whether you are a new engineering manager or a new SRE manager, I think looking at changes, looking at whatever you’re trying to bring in as a practice from the point of view of a pure engineering leader versus someone who understands more about business is how you should, you should approach it, right?
Because as a budding, new manager, you’re more internally focused in addressing your engineers and what they understand.
But the faster and the quicker you are able to actually interact with outside stakeholders, the better in being able to be the voice for your own team. Right? So as a budding SRE manager, if you can think about how the practices that you are building as a team would benefit other application engineering teams. That’s a great way to sell your teams win to other stakeholders. I’m not even talking about business, but just look at other application engineers who will be using your platform.
I think right now it’s no longer SRE. I think it’s platform engineering is what I’m hearing, right? Like, again, these are all minor evolutions. I wouldn’t lose sight of what SRE actually brings to the table, right?
It’s that bringing reliability into how you build software. That’s the way I think about it, right? How you build software, how you deploy and monitor your applications in your production system.
That’s essentially what SRE is all about, right?
It’s not whether the title changes or not. So if you can distill some of the best practices, into how you can quickly build your applications, how you can actually quickly test your applications, how you can actually build better observability and better resiliency into your production systems. Talk about those as an SRE manager to your counterparts and even with your team because that will allow them to see from a very different perspective than what you would do as a typical newly minted SRE manager.
So like embracing your practices and looking at it from how it benefits others. This is what I would provide as a tip.
Ash Patel: I think that advice can benefit even more experienced managers, not just in SRE, but I think in general engineering leadership. So that’s great. I love that piece of advice that you’ve given: to be able to deal with outside stakeholders, be able to understand what they’re thinking.
Just to round things up, let’s say there are a few young people wanting to get into the space. Would you be able to give them any advice as to how they could progress in their career in any space in terms of infrastructure and delivery engineering, in terms of DevOps, SRE?
There are so many avenues for them. But how do they start and then continue to progress? Because you’ve done that. And you’ve succeeded. So any words of advice for them?
Sreejith Chelanchery: Sure.
Rather than an advice, I would, I would call it more of a suggestion or a tip. I think one thing that I would, I would say is what problem are you trying to solve? And understanding the problem space, whether you’re a engineer trying to get into this profession or a manager or a leader who are trying to progress in your career, I think that is one suggestion that I would give to anyone who is getting into these fields.
Because if you think about it, by being a SRE engineer, the more you understand what specific problem are you trying to solve, you can come up with better solutions. If you think about the infrastructure orchestration automation, if you know you are dealing with a myriad set of AWS APIs and how you combine them to produce the infrastructure that you need for a cluster.
If you think about it from that perspective It allows you to tie all this together a lot better than actually if you think about, okay, how do I get this EC2 up and then how do I deploy this application, right? Instead of that, if you think about it from a zoomed out position and try to figure out what problem are you trying to solve for your user, for your customers.
That is how I think a lot of you can progress in your career much quickly than just building some of the foundational engineering skill sets.
Look at the problem more holistically and try to figure out how would you solve it better for the user, whether it is engineers, whether it is the other set of customers.
Ash Patel: And I think this is beyond the scope of our conversation, but they should explore more things like lateral thinking and design thinking as to how they can look at a problem and design a solution rather than going, okay, so this is the thing. Let me do this because this is what we’ve always done. That’s just not how it works in engineering… anymore at least.
Sreejith Chelanchery: Don’t look at it as solving a task, but approach it as solving a problem. That’s how I would, I would phrase it.
Not a task, but a problem. Even the smaller task that you’re solving with a entry level engineer has a problem at its heart.
Yes, someone has translated that problem for you, and you are probably looking at it as a task, but try to understand what is the problem at hand and not the task.
It will probably take a few years of your your muscle to build that sort of approach, but never look at it as a task. Look at it as a problem.
Ash Patel: You are a few layers above where people would be hiring engineers, but I’d still like to know how your teams are composed in the delivery and infrastructure engineering part of Dotdash Meredith. Can you explain to me a little bit more about how your teams are set up?
Sreejith Chelanchery: In my current role, I’m more of a lead of a lead than actually directly interacting with engineers, though I still continue to talk to my engineers, to hear what are the challenges that they have on a day to day basis, because that can inform our roadmaps, right?
But going back to your original question, so we try to actually set up teams with functional boundaries, right?
Like even within the SRE space, we look at Developer Experience (DevEx) is a function.
How do you make them more productive is a sub function of developer experience. Then we look at how do you enable delivery capabilities to those engineers?
We call it our delivery engineering function.
So we organize teams based on functional capabilities. These functions are fungible, I would say, and the engineers can also move between teams as they deem fit.
So that’s how we have organized teams within Dotdash Meredith, based on functional boundaries.
Now, going back to onboarding, there are a lot of experiential learning that we think is extremely useful and beneficial to any new engineer who onboards to our teams.
So we have to try to mix theoretical slash knowledge based training plus actual experience based learning.
What I mean by that is we provide a lot of video recording on what our tools are, what our methodologies are. But on top of that, we let new engineers shadow our existing engineers for a certain period of time based on their function and let them do a lot of pair programming as part of their onboarding journey.
That allows them to see how our existing engineering crew solves problems and be in the mix much quickly, directly trying to solve problems by themselves.
We mix a lot of these techniques in how we onboard our engineers.
Ash Patel: It’s so important to have the right processes in place to onboard engineers.
Otherwise, all that investment you’re putting in has gone to waste.
Sreejith, I really appreciate you coming on and sharing your insights from your journey to going from testing all the way to SVP of delivery and infrastructure engineering. Thank you so much.
Sreejith Chelanchery: Thank you, Ash. It was a pleasure.