Ian J MacIntosh.com

Case Study: SPHERE Technology Solutions

When I arrived at Sphere, I reported directly to the Director of Engineering, who put me in charge of the company’s front-end engineering team of 7 engineers. The team worked on the front-facing side of the company’s web application, built to support the cybersecurity company’s service engagements. The app’s job was to make visual sense of each client’s web of employees, user accounts, user groups, storage devices, databases, etc for data governance auditing and remediation.

Leading Design and Implementation

My job was to lead the web app’s design and implementation, providing a world-class user experience. But as my team's developers built new features and fixed old bugs, the company’s QA team was filing new defects at roughly the same rate. Due to the complex nature of the product, those new issues were necessarily time-consuming to report, explain, and reproduce. We were all swimming upstream.

The company needed a change in technical strategy and engineering standards, so I decided to lead by example. I decided to make my team the best team.

Communication is Priority #1

My top priority with any team is clear communication, which is especially tricky with such a short overlap in working hours between the US and India. I started by scheduling a short daily call at 9am EDT and made it clear that this was more like “Office Hours,” not a daily status report. I enforced the meeting’s scheduled time limit so everyone could show up, get their questions answered, and get home on time.

Next, I moved all the bugs from a giant shared spreadsheet into a formal ticketing system (we picked Jira), talking with management about what we wanted to track and how the work would get done. I kept those conversations simple by keeping them in the context of administrative details, translating them into ticket fields and workflows.

Coaching and Mentoring for Stability

To tackle the app’s technical debt and code quality issues, I added end-to-end testing (Cypress) and worked with the team to make a working agreement: every pull request needed to be backed up with passing tests before being merged, and new functionality would need to be protected with new tests.

I coached the engineers each in one-on-one sessions to teach:

I made sure that whenever a test was flaky or eroded confidence in its legitimacy, we fixed it or removed it entirely until we could stabilize it again: zero tolerance for intermittent tests.

Separately, I worked across the broader engineering organization to build shared coding standards. With an agreement in place I could reformat the entire codebase and normalize all line endings using Prettier and editorconfig. Previously, these tiny discrepancies were making code reviews nearly impossible because engineers had to find “real” changes in a sea of formatting updates that were essentially no-ops.

Shipping Useful Work

Additionally, I built an on-going UX research program to learn what the actual pain points in our application were, with screen recordings of real users trying to perform typical tasks. We exposed glaring problems we’d lost track of, so we could get the basics right before building flashier features.

As we learned more about what work was important, we started setting goals for ourselves to accomplish real work in two week sprints. Not “Close these 14 tickets” or “Deliver 48 story points of work” (more on that in a minute) but things a customer could actually understand, like “Fix the permissions list table” or “Support advanced filtering.”

After delivering it, we’d present it to the organization and our users so they could learn about the work we were doing, and we could learn if what we’d spent time on was actually useful. Those conversations also helped us to discuss what we were going to build next and keep our roadmap up-to-date with new learnings.

Trading “Story Points” for Something That Actually Works

To know what we could commit to, my team evolved away from using “story points” and grew into using statistics to drive and forecast work. Instead of spending time in meetings arguing over whether a ticket was “5 story points” or “7 story points,” the conversation was more like: “Is there a 90% chance this work can get done in 4 days or less?” This allowed the developers to keep themselves honest, later reviewing whether 90% of those tickets actually got done in 4 days or less.

Building a Quality-First Culture

I was still bothered that the “QA Team” was an auxiliary team, as if testing was an afterthought. If we were going to have dedicated quality assurance engineers, they needed to be part of the team and work alongside the implementation engineers, not just picking up whatever got thrown over the fence. I made an agreement with other engineering leaders around the company to try something different: we’d embed a quality assurance engineer in the team for a quarter and measure the difference.

By the end of that quarter, exactly half as many defects had been reported. The benefit of the tighter feedback loop was so obvious that other engineering teams started adopting embedded quality assurance engineers and got similar rewards; closer collaboration with QA put a clear emphasis on quality as a first-class concern. After another quarter, I dug in and verified that the 50% drop wasn’t a fluke: the quarterly defect rate was consistent before the staffing change, and the reduced defect rate continued into later quarters.

Conclusion

The company took notice of all these improvements and before long I began reporting to the Director of Product, who gave me an additional team. I was thrilled to deliver even more wins and help even more engineers deliver their best work, but leading that first transformation was probably my favorite career experience so far.