Search for a command to run...
What it's like after 5+ years
I'm a solutions engineer lead, GitHub Star, Director of WomenDevsSG, and co founder of ragTech. I work at the intersection of tech, systems, and leadership, and this blog is where I share my journey through all three. Expect honest reflections, real experiences, and thoughts that are still forming rather than polished career advice.
No comments yet. Be the first to comment.
It’s a spin-off of the classic Taboo game and we call it Techie Taboo. The idea is simple: you have to explain a tech word (for example, Impact) without using the five taboo words on the card. That’s it. Simple, fun, and surprisingly effective, espec...
The Art of Systems Thinking
That's why your personal brand matters, I'll convince you in this article
Understanding how AI was weaponized in the Anthropic breach and what we can do to stay safe in a world where attacks are now running at machine speed
In the beginning of every ragTech episode, you may have heard one of our co-hosts, Victoria, introducing herself as a Solutions Engineer, but you may be thinking:
“So… what does a solutions engineer even do?”
“Is that role more technical or client‑facing?”
“Sounds kinda like a product manager?”
So watch our video to see her describing her work in action! Or… read this article! Enjoy!
It took me over five years in the role to feel like I could answer these in detail. Today, I want to give you a peek into my day-to-day, how I’ve grown throughout my time in the role, and why I sometimes see myself more as a technical product manager who codes.
At its essence, my role is about connecting both sides of the equation: technical systems and real-world needs.
I act as a bridge between:
Sales & Business: helping close complex deals by understanding customer pain from a technical lens
Product & Engineering: feeding field insights, prototyping workflows, and advocating for priority fixes
Clients: serving as a trusted technical advisor during integration planning and beyond
Internal Operations: identifying repetitive tasks and building internal automations or lightweight tools
Yes, a lot of what I do overlaps with technical product management: I define problems, map out user flows, help prioritize roadmap items, and guide delivery across multiple teams.
Disclaimer: The scope of a solutions engineer role may differ across different companies as well as in different regions. Always important to ask about the role in more detail when interviewing.
I say “typical” in quotes because every day tends to be a remix of architecture, client sessions, engineering deep dives, and coaching. Here’s how a day might go:
I start with a quiet moment to:
Scan alerts or dashboards for client-facing systems
Review queries or error logs from clients or internal teams
Check emails from previous engagements and send follow-ups if needed
Check schedule for the today and prepare to lead stand-up
Catch up on the status of internal experiments like improving onboarding workflows or data auditing between platforms or even testing new products/tools
This is probably the time when I’m with my cup of tea and I silent my notifications to focus on deep work. I’ve learned that the first hour often sets the tone for the rest of the day.
If I use it to get ahead of potential issues or mentally prepare for client and team interactions, my energy will less likely to drain quickly until the end of the day.
Stand-up. For a Solutions Engineer Lead like me, not every day would be a stand-up with engineering teams. Some days, it would be a sales review meeting, other days it would be a team catchup where I help unblock my fellow solution engineers, clarify client-request priorities, and encourage reflections like:
What's the user problem here? Could this request affect multiple clients later?
I try to keep these sessions short and sharp, but meaningful. It’s not just about going through a checklist of tasks, but more about creating space for the team to surface challenges, whether it’s a technical bottleneck, a difficult customer conversation, or uncertainty about next steps.
I’ll often facilitate by asking probing questions, reframing problems, or connecting teammates to someone in engineering or product who can help. Sometimes, this slot becomes more strategic: we’ll talk about upcoming launches, review adoption numbers from a recent rollout, or share lessons learned from a client demo that went particularly well (or badly haha). My role is part cheerleader, part translator, and part problem-solver, making sure the team feels aligned, motivated, and supported before diving into the rest of the day.
Honestly, this aspect of the role is not the easiest for me since I was not a very people-oriented person to begin with. I used to gravitate more toward the technical side such as debugging, building workflows and optimizing systems where success felt more concrete and measurable. But leading stand-ups and facilitating discussions pushed me to develop new muscles: listening actively, reading the room, and understanding what motivates different personalities. Definitely a skill I’m still sharpening, but it has become one of the most rewarding parts of my mornings.
Due to the nature of the role, my work requires a variety set of skills from technical know-how to clear communication and problem-solving, but my favourite part of the role is when I’m in deep work such as:
Drafting or refining integration proposals and diagrams
Writing documentation on implementation best practices and edge cases
Partnering with account teams on deals involving custom flows or complex reconciliation logic
Parachuting into code or workflow builders when needed to unblock the team
Prototyping internal automations to save hours across ops workflows
Reviewing some code PRs across various teams and giving inputs on the direction of the product
This chunk is where I feel most product-minded: not just suggesting, but implementing, iterating, and planning how a solution scales. It’s the stretch of the day where I get to zoom out, think critically about the bigger picture, and then zoom right back in to execute on the details.
Client-facing time. This window is often reserved for demos, requirement-gathering calls, or follow-up sessions with clients who are in the middle of an implementation. The conversations can vary a lot: one hour I might be walking through with a client how our solution integrates with their existing systems, and the next I could be troubleshooting a specific workflow that isn’t behaving as expected in production.
Clients often come in with a request that sounds purely technical, but the real problem usually sits at the intersection of business process, user experience, and system design. My job is to ask the right questions, reframe issues in a way that makes sense to both technical and non-technical stakeholders, and show how we can bridge the gap.
Example scenarios:
Planning integrations with a payments client expanding into new regions
Advising on failed transaction retry logic or webhook handling for a fintech partner
Leading a technical design session around reconciliation flows and notification triggers
This is usually a flexible block where I switch between leadership, technical, and operational priorities. It often goes toward:
Coaching junior SEs on solution design, client communication, or managing stakeholder expectations
Working on internal innovation projects, whether that’s experimenting with a new integration pattern, building accelerators for common client use cases, or prototyping internal tools
Reviewing demos and solution design documents to make sure they’re aligned with both client needs and technical feasibility
Reviewing code PRs from engineering, especially if they touch areas where I’ve been deeply involved in design or past implementations
Reviewing the sales pipeline alongside account managers, to understand which opportunities might need SE support and where we should allocate resources
Troubleshooting and debugging unexpected issues that crop up from client escalations or monitoring alerts
Keeping a close eye on recently onboarded clients to ensure adoption is smooth and there aren’t early signs of friction
This block rarely looks the same two days in a row, but it’s where I get to balance the “zoomed out” perspective of the business with the “hands-on” problem-solving that first drew me to the role.
Some afternoons lean heavily people-focused, where I’m mentoring or coordinating with cross-functional partners. Others are deeply technical, with me buried in logs, code, or workflows. Either way, this part of the day is about making sure both the team and the solutions we deliver are set up for long-term success.
If inspiration strikes or I’ve got extra energy, I’ll spend some time on things that don’t always fit neatly into the workday but still move the team forward:
Writing internal docs or sharing team retrospectives
Sketching ideas to reduce onboarding friction or improve tooling
Exploring new technology or system designs that might help us scale
Always thinking in systems, how small improvements ripple across impact
This isn’t mandatory work, and I try to keep boundaries so I don’t burn out, but sometimes the quiet evening hours are when the best ideas surface. It’s when I can step away from the constant flow of meetings, messages, and requests, and just think.
So that’s an overview on what a day looks like for a Solutions Engineer Lead. Never a boring day, I think. Some people have told me that it must be hard being in this role because of the constant gear switching and knowing which tasks to prioritize can seem daunting.
I think I adjusted to this part of the role pretty easily thanks to the Eisenhower Matrix, which I mentioned a few times before in this blog. With that, let’s step back from the hour-by-hour view and look at the core responsibilities of this role, as that is also a common question I received from my readers.
| Area | What That Looks Like |
| Client Solutions | Designing scalable architectures, guiding integrations, troubleshooting edge cases |
| Internal Tools | Prototyping automations, building lightweight tools, reducing manual operations |
| Leadership | Mentoring, setting technical standards, advocating cross-functionally |
| Innovation | Owning process improvements, testing new ideas, automating repetitive workflows |
| Cross-functional Work | Closely collaborating with Sales, Product, Engineering, Marketing |
When planning for this article, I didn’t really plan to include this section since it is a personal reflection and may not be relevant to readers who just want to understand the role. Still, I decided to add this because sometimes the most useful insight comes from how you grow into the role, not just what you do in it.
In Year 1, my work was mostly reactive. I joined calls, fixed client issues, supported integrations, and learned to juggle multiple requests coming at me from all directions. If a client had a problem, I solved it. If an integration broke, I patched it. There was a kind of immediacy and urgency that defined every day and I loved the adrenaline of “figuring it out.” But I often felt like I was just a step behind, always responding rather than shaping outcomes.
Fast forward to Year 5, and things look very different. Now I find myself:
Anticipating common issues before they escalate and designing preventive tooling. For example, I built a small automation that flags inconsistencies in client data overnight, so the team can address them before clients even notice.
Coaching teammates to handle common requests independently. I remember one junior SE who kept pinging me for small configuration questions so I wrote documention on common patterns and requests, and now they solve most of those requests without needing me.
Building templates and automations so others don’t have to start from scratch. That one workflow template I created for onboarding new clients has saved the team hours each week and reduced errors.
Influencing roadmap decisions with first-hand client insights. Sometimes it’s as simple as proactively pointing out that a seemingly small request from a client actually impacts dozens of other customers, nudging product to prioritize it.
Thinking in systems, not just completing individual tasks. I’m no longer just “fixing things,” I’m looking at the ripple effects: how a small change here can save time, reduce friction, or prevent errors elsewhere.
The greatest value I bring isn’t in how much I can personally fix issues. It’s in how much I can empower others, build solutions that scale, and drive systemic change. And honestly, this shift from being reactive to thinking systemically is what makes this role so satisfying now.
So, to all of you who’ve ever asked what I do as a Solutions Engineer Lead… I hope this paints a clearer picture. It’s a mix of:
Solving complex technical problems while understanding the client’s needs
Coaching and empowering team so the impact multiplies beyond what I can do alone
Anticipating issues and building systems, templates, and automations that make workflows smoother
Collaborating across teams to influence product and roadmap decisions
And yes, a fair amount of “organized chaos” that keeps every day unpredictable and interesting
I often describe it as:
“Being a technical product manager who can code, teach, sell, and debug while translating between humans and machines.”
If you’re in tech and looking for a path that blends problem solving, impact, and human connection, solutions engineering might just be the beautifully chaotic middle ground you didn’t know you’d enjoy.
Thanks for reading! If you have more questions about what this role looks like day-to-day or want to chat about breaking into solutions engineering, feel free to reach out! Cheers!
