A QA Story: How Strategic Rule-Bending Outpaced Rigid Compliance

Once upon a time, there was a QA group at a large IT company. The group was split into two teams of six QA analysts. Each team had a manager. Both managers joined the company on the same day. The two managers couldn’t be more different in personality.

Graham was a talented programmer who was promoted to manager. Unfortunately for his team, he saw everything as binary or “if-then-else” cases.

Miles was a programmer, but had been promoted into management years earlier. His primary concern was for his team’s well-being, and he did what he could to support them, occasionally bending the rules.

Both teams were equipped with comparably aged equipment. Aged was the correct term, because these computers were well past the end-of-life stage. The managers were aware of the situation and had plans to upgrade as soon as they received permission for the expenditure.

Instead of approval, the managers were told they could not purchase any equipment. A cost-cutting initiative was implemented, and that included computer equipment. Graham took this as a blocking condition and told his team to deal with it as best they could.

Miles submitted his equipment request anyway. Instead of requesting one computer for each team member, he doubled down and requested 12 computers. His request was rejected, but he refused to stop at the initial “no.” The first response for capital expenditures was always “no,” even when times were flush. After each rejection, he submitted a new request until the man in charge of purchasing relented and called Miles.

“There’s no way you’re getting a dozen new computers,” said the purchaser.

“The bare minimum my team needs is 10,” Miles responded. “We’ll make do with 10, but that’s what we need.”

“I’ll give you eight,” said the purchaser.

“I’ll talk to my team and see if we can manage with eight,” said Miles.

Miles never spoke with his team about the computers. An hour later, Miles called the purchaser and accepted his offer of eight computers. That was two computers more than his team needed. Miles took care of his team, and the purchaser felt good that he saved the company the cost of four computers.

When the new hardware arrived, the second team took note of the rejoicing in the cube pod next to them. Astonished and envious of the new computers, the second team went to Graham and asked him to put in his request. Graham refused. The cost-cutting measure included computers, so it was not logical to ask.

One team member did an analysis of the cost of keeping ancient machines that broke down and stalled work. Even though the analysis proved a ROI within one month, Graham refused to budge. There would be no rejoicing in the second pod.

Armed with new computers, the first team delivered their work much faster than the second team. This was noticed by senior leadership, who misinterpreted it as the difference in the team’s dedication and their leader’s management skills.

In the end, Graham went back to programming. Miles was promoted to vice president and led the satellite office. He continued to use his wiles to support his staff, and the staff worked happily ever after. Until the Big RIF.


Moral of the Story:

Following the rules may keep you safe, but challenging them—strategically and with purpose—can drive real change. Leadership is not about blind obedience; it’s about knowing when to push, whom to persuade, and how to advocate for your team.

Bob Thomas