Before joining Perituza, I completed a Bachelor’s in Business Administration and a public sector leadership training program. When I joined Perituza as an Associate HR Generalist, my focus was on people and process. Over time, the scope of that work expanded, propelling me into a new range of responsibilities and growth far beyond the typical scope of HR.
More Than One Definition of My Work
Much of that expansion came from taking on work that sat outside a traditional HR role. I worked on our social media presence, took part in filming internal content, and put together competitor benchmarking reports. None of it replaced my HR responsibilities;, it sat alongside them, and each one asked me to get comfortable with a different set of tools and a different way of thinking about a problem before I could do the work well.
That’s the part that mattered more than any individual task: I was becoming more comfortable taking on unfamiliar work and figuring out what I needed to execute it well, rather than staying inside the boundaries of one job description.
Learning to Work with Data
The clearest example of that habit is a workforce analytics dataset I worked on in Power BI. The dataset, previously spread across numerous Excel workbooks, needed structure before anyone could use it properly. Building that structure meant learning Power BI to a level where I could actually work with it, not just open it
Once I’d consolidated the data in SharePoint and worked with my team members to streamline the data entry process moving forward, the more lasting change was in how I approached information afterward.
I started looking at other reports with a different question in mind: what is this data actually meant to tell someone, and is it currently presented in a way that lets them see it? Now, I can take a dataset that isn’t doing its job and turn it into one that is, and that’s a capability I built deliberately, through this kind of work.
You don’t have to stay within the boundaries of where you started.
– Imesha N.
Rethinking Repetitive Work
Power Automate came from a different kind of question. As I started automating manual workflows – beginning with intake processes and company-wide communications – I started noticing how much of it depended on someone remembering to do a manual step, and I began asking whether that step actually needed to stay manual.
Using Power Automate alongside tools like Microsoft Forms, SharePoint and Teams, I built workflows that reduced how much of that work needed direct human intervention. The specifics of any one workflow mattered less than the shift behind it: instead of asking how to get through a manual task faster, I started asking whether the task was where our time was best spent.
Learning to See Beyond the Tools
Somewhere between the dataset I restructured in Power BI and the manual step I automated using Power Automate, something shifted that wasn’t really about either tool specifically. I stopped treating unfamiliar systems as outside my area and started treating them as another part of the problem in front of me, something to understand well enough to use, not something that belonged to someone else’s job description.
What that meant in practice was paying attention to how a process connected end to end, rather than looking at whatever task happened to be mine in isolation. A dataset wasn’t just a dataset; it was part of how information would eventually be understood and used. A manual step wasn’t just a step; it was one link in a process other people were also relying on.
Once I started looking at work that way, it became easier to notice where technology might genuinely help, and easier to accept that I didn’t need to understand every technical detail before I could use it meaningfully. I needed to understand the problem well enough to know what to ask of the tool, and that was usually enough to start.
What Being Technical Means to Me Now
Having a formal technology background isn’t the only route into technical capability. Mine came through a Business Administration degree, an HR role, and a series of problems that had a technical solution once I looked closely enough. I didn’t need to become a developer for that to be true, and I don’t think understanding people and being technical were ever in competition.
What I do now sits across people, business, data and the tools that connect them. That combination is the capability I’ve built, and it didn’t require leaving anything behind to get there.
