Storytime - The Impossible Assignment

It has been nearly a decade since the original Storytime with Auntie Aja. In that time, I’ve collected many more stories about working and managing in tech.

I’ve also gained new perspectives on many of the stories from my early career. I sometimes wish I could go back and share what I’ve learned with my younger self. Sadly, time machines still don’t exist, so I’ll share here and hope it helps someone else.

The impossible assignment

This story takes place early in my career when I was working as a tester. At the start of the planning cycle, I was pulled aside and told I was getting a special assignment working with just one developer.

Our assignment was to automate the processing of a particular ticket queue. Most of the tickets needed no action. Some got sent to an automated process for further handling. And some required the support team to step in and intervene. Today, we’d probably use an LLM for this type of thing, but it was the mid-2000s, so we built a decision tree.

Once we had the architecture decided, I started preparing my test data. The tickets were all plain text. In my overeager youth, I decided this meant I needed to learn Perl. I bought the Camel Book and, two days later, knew enough Perl to parse the stream of tickets and build up a labeled set of test data and a test harness.

The dev and I started iterating and fine-tuning the decision tree. While we worked, I monitored the queue for any interesting edge cases I could add to our test data. After a few weeks, we had a system that could correctly process all the tickets coming into the queue. And we documented the rules used to make the decisions. I was so proud of myself.

A few days after we finished, I was in a 1:1 with my grandboss. He asked what I had been working on. I shared our recent success with our queue processing tool. He responded with something like, “Oh, that project. Yeah, we all thought that was impossible. Good on you for figuring it out.” He then shared that while I was working, they’d hired a vendor to build a solution. The vendor solution was less accurate than what we built. In the end, the company chose the vendor solution.

So, what did I learn from this experience?

Not all assignments are good assignments

The most important thing I learned from that situation was that not all assignments were good assignments.

I thought this was a good assignment. It was special. It was technologically interesting. I got to show off my tech skills and write code. I also knew that if we were successful, we would save the company a lot of money and help protect the brand’s reputation. All of that made it seem like doing this well would reflect well on me.

But in the end, it was a bad assignment. It didn’t help my career. The work wasn’t valuable to the people above me. They’d decided we’d fail before we even began. They struggled to believe us even when presented with evidence that our solution was cheaper and more accurate than the alternative. At review time, I wrote, “strong work on a canceled project.”

With more experience, I know to be wary of “special” assignments that are understaffed. I’m also cautious of work that doesn’t “look like” what the rest of the team was doing. While I was learning Perl and building test harnesses, my peers were doing manual software testing. That made it harder to compare my work to theirs and show how it contributed to shared team goals.

Bad assignments can have good parts

Even though this was a bad assignment, there were some good parts. Most importantly, it started my transition from test to dev. It also reignited my interest in automated software testing as a way to reduce feedback time and prevent regressions.

I also got to learn Perl on this project. Knowing Perl made it easy to pick up Ruby a few years later. And Ruby unlocked much of my current career.

Learning Perl in only a few days made me confident that I could keep up with new technology trends and learn whatever skills I needed for a project.

This project was also my first exposure to super-basic AI in the real world. Since then, I’ve built several other systems like this, most recently for the demo I worked on for I/O 2022.

Don’t assign impossible work to your team

My experience with an “impossible” project influences how I manage my team. Simply put, I won’t assign impossible work. That shouldn’t need to be said, and it shouldn’t be a thing that happens, but it does. So, I look out for tasks that seem extremely unlikely to succeed.

I also try not to assign work that will be thrown away or won’t be valued by those above me in our leadership chain. This can be hard. Sometimes, projects get canceled with no warning. But I do my best. That often means moving slowly to see how things evolve or doing some investigation myself before offering a project to a team member. When I’m unsure about the long-term prospects for a project, I offer it to the more senior members of my team, and I’m clear about the risks I see.

I strive to keep my management 1-liners phrased as positives. So instead of “don’t assign impossible work” and “don’t assign throw away work,” I say, “Don’t offer projects unless there’s a reasonable chance of success.”

Also, it is easier to say no to bad assignments if you are a bit overloaded or a bit understaffed. “I’ll get to that after I complete these higher priority items” is, after all, the business way of saying no. But even if you can’t blame your workload, there are ways to politely decline assignments that “aren’t aligned with our career goals and the direction we’re taking the team.”