At SJ Consulting (SJC), the phrase “employees are heard” isn’t just a slogan—it’s how work gets done.
Our work-culture is to actively encourage input from all of our team members, but more than that, we recognize, adapt, and implement changes based on what people say.
The result?
Our team feels respected, projects that run smoother, and as a company we continue to evolve through collaboration.
While discussing this week's article,one of our team members shared the example of how he was allowed to approach project management in Asana and it perfectly captures this ethos.
Step 1: Automating Asana with Purpose
When SJC first adopted Asana for project management, the standard features alone weren’t quite enough. That’s when one employee stepped up—not just to use the tool, but to transform it - he agreed to be our “Asana Guru”.
After a conversation where Sean (our founder and CEO) expressed a desire to automate workflows, our Asana Guru took the idea and ran with it. He didn’t just execute instructions— he researched how Asana rules and automations worked, experimented with various setups, and implemented custom rules tailored to the team’s needs.
The result?
A system that not only worked, but worked well for SJC. Automation turned Asana into a living, breathing part of the company’s day-to-day operations, making task management smoother and smarter.
This process wasn’t about top-down orders. It was about listening, collaborating, and creating together. Even when Sean’s initial request wasn’t feasible within Asana’s framework, the response wasn’t “no”—it was “here’s how we can make it work.” That solution-first mindset was welcomed and appreciated.
Step 2: When One Size Doesn’t Fit All - Adapt Again
SJC had a standard Asana workflow—tasks moved from “To Do” to “In Progress,” with clearly defined states like “Needs Review” or “Waiting for Feedback.”
But for our Dev, who was overseeing a complex web app with multiple modules, this structure wasn’t working…
Our structure didn’t fit his workflow, and regardless of how hard he tried to make it fit - not everything can be stored in the same box - and not every workflow is the same.
Tracking progress by task status didn’t give him a clear view of how each module was developing. His feedback was straightforward: the current setup was making it difficult to manage the project effectively.
Instead of arguing or forcing the standard process, our Asana Guru listened.
Together, they redesigned the workflow from scratch—categorizing tasks by functional module (like “Brokers,” “Routes,” or “Development”) rather than by status. The task states were still tracked, but the project view now made sense for this specific kind of work.
This wasn't just a tweak—it was a complete reimagining of how Asana could be used. And it happened because someone said, “This isn’t working,” and someone else responded, “Let’s fix it.”
Changing the Workflow, Not the Voice
What makes this story powerful is what didn’t happen:
Nobody panicked because we needed to change a change. There was no pushback. No defensiveness. No insistence on sticking with the default process.
Instead, we embraced feedback as an opportunity to improve—and that openness extended even to future possibilities.
Because at SJC, changing the workflow isn’t seen as changing the rules—it’s seen as respecting the work itself and the people doing it.
Employees Are Heard. Full Stop.
At SJ Consulting, being heard isn’t about sitting in a feedback session. It’s about what happens next. It’s about saying “this isn’t working” and being met with “let’s build something better.” It’s about having your ideas implemented, your perspective respected, and your contributions reflected in the tools and processes you use every day.
We have all been in situations where a change is requested an denied because a manager doesn’t sign off and believes everyone should be able to work within the system. In this story, Sean listened, and opened the floor for the change to be made if it was something that would work.
Sean didn’t personally make the change, he didn’t instruct the change, and he didn’t micromanage the change - instead he practiced Kaizen.
He trusted the Asana Guru to know what he was doing when he agreed, and he trusted his Dev to know what he needed to do in order to ensure there was transparency of feedback - and his employees got what they needed because the whole team listened rather than deferring to the norm or a manager.
