How I Moved My Team to a Task Tracker and Almost Got Fired

Hi! My name is Lyosha. A year ago, I took on the task of moving our digital agency team to a task tracker.

We had 15 people: designers, developers, content writers, project managers. Everything was urgent, as it always is at an agency. Before that, we somehow managed: tasks flew around in Telegram, feedback went there too, and we held syncs twice a week.

Then big clients came along, and the founder said it was time to bring order. I was appointed team lead and asked to implement a system.

In short: a month later we lost a "golden" client because of task chaos. And I was the one who took the blame.

Why I Thought I Could Implement a Task Tracker

I had already worked with task trackers before — Trello, Asana, Notion, and had some encounters with Jira. In some projects everything worked smoothly, but there were also cases where teams ignored the system or suffered from overload and bureaucracy.

The most painful experience was in big tech: to understand who was doing what, we held calls just to decipher tickets.

So when the founder asked if I could handle the implementation, I answered without hesitation: of course. I know how not to do it — so I'll do it better.

In my mind, I was already painting a beautiful picture: tasks moving through stages on their own, employees getting reminders, everything structured, transparent, automated. And the founder and I would just check dashboards and calmly head off to presales. In short, the plan was beautiful.

And now, point by point: where exactly I messed up and what it led to.

Point 1. I Set the Wrong Goal

I started seemingly on the right track: I mapped out the process to understand where we were losing time and missing deadlines, drew a couple of mind maps.

And at that moment I missed the main question: why are we implementing a task tracker at all?

What I did. I latched onto the idea of perfect process order and tried to digitize everything at once, whatever that meant. And, spoiler alert, I got the same chaos — but now on dashboards.

What I should have done. Set a clear, measurable goal. Here's a good one: "at least 80% of tasks go through the task tracker; all agreements and information about these tasks can be found within the tasks themselves." That kind of result is clear to the team and easy to verify.

Point 2. I Chose an Overly Complex Task Tracker

Our agency always lived in Telegram. That's where clients were, edits, memes at 1 AM. It made sense to pick a tracker that would preserve that rhythm.

What I did. I decided we needed software "built for future scaling." And I chose a management system that "could do absolutely everything" — from accounting to marketing analytics. I created detailed guides and, together with tech support, started building templates and "useful" triggers.

Here's a spoiler: if the service developer promises support in setting up the service for your needs — that's a bad sign. It means you won't figure it out without support going forward either.

The same goes for all those guides. If you can't just pick it up and start working without special training, prepare for the team to ignore the transition to the new software entirely.

What I should have done. Find the simplest possible service that would be understandable to those who've never worked with trackers. "If you yourself can't master the service in an hour, don't expect the team to master it in a month."

But as practice showed, it wasn't just about the service. I would have messed things up further anyway.

Point 3. I Meddled in the Team's Work

When you launch new software, it's important not to throw people into rigid rules.

What I did. From day one I set up total control: I forced everyone to move everything from chats to cards, personally edited statuses, set up dependencies, went into DMs asking "where is this?" and "why wasn't this updated?"

Within a couple of weeks, our syncs turned into interrogations. I would silently open the board and begin:

• Is this task still alive?
• Who's doing it? Where's the approval history?

I was gradually boiling over, but the team was also at its limit.

First came growing irritation — people started expressing dissatisfaction in chats.

Then came open protest. The frontend developer started ignoring my messages, and then simply said he wouldn't even open the tracker until his workload was reduced or he got an assistant.

I decided not to pressure him. Naturally, this was bound to raise questions from the rest of the team.

New side effects appeared. People knew that writing in the general chat was "against protocol" (which I periodically reminded them of), so they started moving everything into DMs. If before I could at least see everything in the general flow and pull out the needed information, now it was smeared across different conversations.

On weekends I manually compiled reports for the client, because roughly a third of tasks weren't in the tracker at all, and another third had outdated statuses.

What I should have done.

1) Calmly hold a team call, explain why we need a task tracker, and how it will simplify everyone's work.

2) Start with the simplest thing. Create a maximally simple board with the basic process and invite the team. A board without bells and whistles or automations — just basic statuses: assignee, deadline, priority. For the convenience of all newcomers, create a task template with all the necessary statuses so nothing gets forgotten.

3) During the first week, just observe how tasks move and whether discussions are happening. Learn not to poke people in DMs, but to get information from the system.

For example, now I simply open the activity feed and see how a person works within the system. And I monitor overall team progress through summaries — dynamic reports in the form of columns right on the board.

I set up three summaries that aggregate from all relevant projects:

• New tasks for the week;
• Tasks with missed deadlines;
• Tasks whose chats have active discussions.

Point 4. I Was Harsh and Overcomplicated Things

I understood that I wasn't coping. It was my first leadership position, and there were too many tasks. But I couldn't let go of control — after all, I was the one who implemented all of this.

What I did. See point 3, essentially.

What I should have done. Use planning meetings to discuss work and plans based on the tracker, rather than having conversations and tasks separately, creating two parallel realities.

Also, I believe it's very important to immediately discuss maximally simple rules:

• We discuss tasks only within the system. An additional plus — if it has its own messenger and task chats, this helps engage the team.
• If something is agreed upon outside the tracker, for example with a client — by end of day, document it in the task chat. However you want, even by copy-paste — the important thing is that it doesn't get lost.
• There are statuses that nobody can skip. A task must always have assignees and a deadline.
• Tasks on the board should be roughly the same "size" — all the small stuff goes into subtasks.

Point 5. I Didn't Engage the Team

I treated maintaining tasks in the tracker as people's obligation. And I reminded everyone about it every time.

What I should have done. Involve employees at the tool selection stage. A simple framework like PDCA could have immediately given structure to our conversations:

• P (plan) — discussed the problem,
• D (do) — tried a new approach,
• C (check) — verified if it works,
• A (act) — consolidated the result.

Add motivation: thank people for ideas about working in the new system, recognize the proactive ones. Even small incentives like treats would have supported engagement.

What It All Led To

About a month after my "implementation," we screwed up on a project for a very expensive client where every word went through a PR department.

In the evening, the editor received an urgent correction — remove a mention of a partner under NDA from the text. She forwarded it to the author in a DM, and in the morning the layout designer took the old text from the task and published it on the site.

I was calmly sipping my coffee, getting ready for yet another call, when a huge angry message from the client landed.

We urgently fixed everything while simultaneously apologizing to the client. But the next day the customer put the project on pause.

The boss gave me two weeks to get things in order, otherwise — say goodbye to my position.

And so we've come full circle.

I had to simplify everything I had overcomplicated. I turned off all automations, removed 10 statuses, reduced the number of required fields. I apologized to the team. I brought in a freelance assistant to go through task cards and verify statuses. I was afraid to bother people myself — people who were somehow miraculously still delivering high quality work.

The processes came back to life a bit. The founder saw that the system was somewhat working, and I stayed. But it was no longer a victory. I was so exhausted and disappointed in myself that three months later I left on my own.

We still talk with the old team; I even brought some of them into my freelance projects. And one colleague (now a friend) showed me a screenshot of how they were creating secret chat groups for "normal work" behind my back.

I laugh, of course, but more with bitterness.

Now, a year later, I believe that experience was only beneficial. And now I understand processes and people better. But I'll be honest — I arrived at a banal thought: "any software should fit into the team's work, not the other way around."

I hope my anti-case was useful and perhaps gave you food for thought.

Tell me — how did your "implementations" of new tools go? With love or through pain?