How I Approach My Job: The Tool Is the Easy Part

Dec 8, 2025

A couple of weeks ago, I wrote about what a Solutions Engineer actually does. I talked about how the job is really about translating fuzzy business wants into concrete technical solutions. But I didn’t really get into how I actually do that.

So, let’s talk about process.

My guiding philosophy is pretty simple: tools should make your first job easier, not become a second job.

I have a pretty simple rule: if you have to do something more than once, it should (almost always) have a process or a runbook. This isn’t process for process’s sake. It’s about cognitive load. I want to prevent people from having to re-solve a problem that someone else has already solved. Good process frees people up to work on new problems, rather than getting stuck resolving old ones over and over again. There’s that urban myth about why Steve Jobs always wore a black turtleneck, so he’d never have to waste any cognitive cycles deciding what to wear. Same idea. Automate and document the repetitive stuff so you can focus on the interesting stuff.

We’ve all worked in those organizations where the “process” feels like a punishment. You know the ones—where you spend more time updating Jira tickets, filling out twelve required fields, and navigating approval chains than you do actually writing code. That’s when a tool becomes a burden. It becomes bureaucracy for bureaucracy’s sake.

But the flip side isn’t much better. I’ve worked at places that treated any form of process like the enemy. “We’re too busy actually working, we’ll document it later.” Cool. Except you never got around to it and now only Dave knows how the entire process to deploy vehicles on test runs works, and Dave left the company for a new gig, and now that process is broken (a not entirely fictional story).

You’ve got to find that balance. Enough structure to keep things from falling apart, but not so much that people spend more time fighting with tools than doing the work.

Get To Know Your Customers (Even if Those Customers Are Your Coworkers)

At Aurora, especially during my first year, I spent a lot of time just shadowing teams. Sitting in on standups, watching how they actually used their tools, asking where things got stuck. I’d literally tell them “treat me like I am a fresh, junior engineer and you are trying to get me up to speed ASAP, the same process you’d use for onboarding them.” You learn a lot more about how work actually flows by watching people do it than by asking them to describe it.

For a few key teams, we set up standing bi-weekly meetings. This wasn’t about answering support tickets—it was about proactive engagement. They knew they had a dedicated slot to discuss their processes, identify bottlenecks, and iterate on improvements, rather than just throwing one-off requests over the fence. In a perfect world, no one would ever have to come to me with a broken process. I’d proactively go to them with suggestions on how to improve things. The real world is never so easy, of course. But that’s always the goal.

But sometimes people do come to me. When a stakeholder says, “We need a new Jira project for the Marketing team,” or “We need a better way to track bugs,” they usually have a specific solution in mind. And usually, that solution is way overengineered and very optimistic.

The Process of Designing a Process

Here is the mental process I use to go from “We need a thing” to a working, scalable workflow.

Step 1: Ignore the “Solution,” Find the Problem

The first thing I do is annoying. I ask “Why?” about five times.

“We need a new field on this screen.” “Why?” “So we can track which vendor is working on the ticket.” “Why isn’t the existing ‘Vendor’ field working?” “Oh, nobody uses that one because it’s a free text field and the data is messy.”

Boom. So the request was “add a field,” but the problem was “data consistency.” If I had just added the field, we’d have two messy fields instead of one. The solution here isn’t a new field; it’s changing the existing one to a dropdown or connecting it to a database of assets.

My goal in this phase is to stop thinking about Jira or Confluence or Trello or whatever tool we’re using, and just understand the flow of information. Who has it? Who needs it? What happens in between?

Step 2: What Is the Happy Path?

Once I know the problem, I want to diagram the solution. I’m a big fan of Lucidchart. I find that big, simple diagrams are much better for this than walls of text. Lots of squares and arrows.

1. Request comes in.
2. Manager approves it.
3. Team does the work.
4. Customer is happy.

This is usually what the stakeholder thinks the workflow is. It’s clean, linear, and simple. It’s also a lie.

Step 3: Okay, What Can Go Wrong?

This is where the “Engineering” part of Solutions Engineer comes in. I start poking holes in the Happy Path. I trace through the solution, the different paths it can take, etc.

What happens if the manager is on vacation? What if the request is incomplete? What if Legal needs to review it? What if someone changes their mind halfway through?

This isn’t just theorycraft. I learned to ask these questions the hard way. Early in my career, I built a bug triage workflow for an engineering team. Looked great on paper. Bug comes in, gets triaged by severity, assigned to a developer, fixed, done. What I didn’t ask about was security. Turns out any bug that touched authentication or user data needed to be escalated to the security team before anyone else even looked at it—and definitely before it got logged in a system that junior devs could access. Any bug reported by an enterprise customer needed to CC their account manager. And anything marked “critical” needed a Slack ping to the on-call lead within 15 minutes, not whenever someone happened to check the queue. The workflow went live on a Monday. By Wednesday we had a security bug sitting in the general backlog and a very unhappy account manager finding out about a customer-reported issue from the customer themselves.

Now I ask about escalation paths obsessively. I assume every workflow has at least three exception paths I haven’t thought of yet. A workflow that only handles the best-case scenario will break the first time something weird happens. And something weird always happens.

Step 4: Ship Ugly, Iterate Fast

This is the hardest sell. I almost never build the “perfect” complex workflow on day one. I build the MVP.

I start with the simplest version that solves the core problem. It intentionally doesn’t have all the fancy automations yet and all the different branches yet. But it works, and it gets people using the system.

And once people are actually using it, once it’s no longer just an idea in some manager’s head, you find out where the real bottlenecks and pain points are. What actually needs to have a little complexity added to it.

Tools as External Brains

I have pretty severe ADHD. And one of the biggest lessons I’ve learned is that relying on willpower or memory is a recipe for stress and panic.

For me, way more than any medication, the thing that actually helps me the most is externalizing my executive function. I have to have routines. I have to write things down. I track my habits. I have to schedule everything. If it’s not in the calendar, it doesn’t exist. If the steps aren’t written down, I will skip one. I live my personal life out of Notion and Google Calendar.

I bring this same overall idea to the solutions I design.

When I build a process for a team, I’m essentially trying to build an external brain for them. I want to reduce the cognitive load required to do the job. I don’t want you to have to remember to ask Legal for approval; I want the workflow to automatically transition the ticket to “Legal Review” and ping the lawyer for you. And I absolutely don’t want a heavy process that adds to the amount of things you have to remember to do and keep track of.

A good process removes the mental friction of “what do I do next?” so you can focus all your brainpower on the actual work.

Ideally, the tools should just get out of the way. If I’ve done my job properly, the process becomes almost invisible. You shouldn’t be fighting the tool; you should be barely noticing it’s there as it quietly guides you down the path of least resistance.

It’s Not About the Tools

Notice I haven’t mentioned Jira workflows, screens, or schemes yet? That’s because the tool is the easy part. Configuring Jira is just clicking buttons. Designing a process that humans will actually follow without hating their lives? That’s the job.

If you can get the people part right, if you understand the why and design a flow that actually makes their lives easier, the Jira configuration takes an afternoon. The three weeks and multiple meetings before that is what’s important.

Since I probably won’t post again until 2026: