Four Jira Tickets

An updated software-development retelling of the old three envelope joke.

The new VP of Engineering let out a satisfied sigh. It was her first day in her new job, and she’d just completed the company onboarding. She logged into Jira, intending to browse the current work in flight. She was surprised to discover that there were already four tickets assigned to her.

She opened the first ticket.

Summary: A message from your predecessor

Description: Congratulations on your new role! Inevitably, there will come a time when things are going badly and the CEO seems to have it out for you. The next three tickets contain the advice that my predecessor gave me, and that served me well here. Don’t pick up a ticket until you are at a loss for what to do, only pick up one ticket at a time, and pick up the tickets in order.

The VP read the advice and smiled. It was kind of her predecessor to leave her the tickets. But she wasn’t too worried about the CEO having it out for her. She’d been hired for a reason, after all. She was confident she had his full support and could handle anything the organization could throw at her. She marked the ticket resolved and went about her day.

For the first couple of months it seemed the VP could do no wrong, but eventually the honeymoon was over. Quality problems caused customer complaints and support escalations. The engineers hated the Product organization's roadmap. The Head of Product complained to the CEO, and the CEO ramped up pressure to ship more features faster. Six months to the day after she started, the VP was at her wits end. An email notified her about another escalated Jira ticket, and she suddenly remembered the Jira ticket from her predecessor. She looked at the remaining three tickets in her queue. The subjects read simply “One,” “Two,” and “Three.”

She opened “One.” It contained a single line: “Centralize everything that is decentralized.”

“Huh,” she thought. “OK…”

She thought about it, and decided it was sound advice. So she reorganized engineering. Her newly appointed Quality Director took the reins on the test strategy and vowed to improve quality. The newly formed maintenance team got to work on the customer-reported bugs. The new Platform team worked to standardize and automate environment management. The new DevOps team was set to automate the deployment pipeline. The remaining developers were able to focus on the roadmap.

The CEO was pleased. “Good work!” he said in their next one-on-one. “I knew you could make that department of yours work more effectively!”

Things went well for a while, but eventually it became apparent that the new structure hadn’t been a silver bullet after all. The maintenance team was introducing as many bugs as they fixed, the quality team was finding lots of bugs but had no ability to do anything to address the underlying source of the quality problems, the Platform team had built a castle in the sky, the DevOps team spent all their time wrestling the platform that didn’t seem to do what they needed, and the remaining developers were struggling to implement new features in an inherently unstable code base (plus they still hated the roadmap).

Once again the VP found herself with her head in her hands, a sense of futility and despair weighing heavy on her soul. At a loss for what to do, she decided it was time for the next ticket. She opened “Two.” It was also a single line: “Decentralize everything that is centralized.”

She nodded at the wisdom. The centralized groups weren’t really working. It had been a good thought, but change was needed. So she reorganized again. All the specialized teams were dissolved, the team members now assigned to a squad. Each squad would own responsibility for their code from cradle to grave, including tests, quality, environments, and tooling.

The change was not universally popular, but overall it was well received. The Head of Product was particularly pleased, saying "I never did think it was a good idea to take so many developers away from feature development." Over the next couple of months even the skeptics had to admit the new structure seemed to address the most pressing issues in the organization. Bug counts and cycle times went down. The VP thought that at last she'd found the right structure. She silently praised the wisdom of her predecessor.

Six months later, the VP found herself despairing once again. The reduced bug counts turned out to be an illusion. The squads just weren't bothering to file tickets, but the quality wasn't any better. Worse, each squad operated so independently that addressing any issue or releasing any feature that required inter-squad coordination was next to impossible. The Product organization was breathing down her neck, the CEO was beyond frustrated, and she had no idea how to address a recent uptick in customer complaints and support escalations.

Time for the third Jira ticket, she decided. So she opened “Three.”

Like "One" and "Two," "Three" contained a single line: “Prepare four tickets.”