Projectstance: shared beliefs at Atomic

Atomic has strong opinions about how to do projects, and we have practices that are so deeply a part of our culture that they are taken for granted internally. There’s a common way we approach all the projects we do, whether it’s embedded, desktop or web, in any of the many domains in which we work. I’ve known this for a while, but I’ve never had a good word for it. Watching one of our younger developers on a recent project gave me that word.

People at Atomic have a strong projectstance.

Project stance is a riff on lifestance. A life stance is the beliefs a person accepts as of ultimate importance, and the commitments and practice of working those beliefs out in living.

The project that inspired this term was small. A health care customer of ours asked for help automating an error-prone and tedious data entry chore. The project was to use Intersystem’s Ensemble, a 3rd party integration tool, to develop a simple web app to manage immunization lots in Epic, the EMR our client recently adopted. A secondary goal of the project was to evaluate the integration tool as a platform for future web app development. The web app itself was quite simple: a login page and a single form with a half dozen validated fields.

Justin came into the project with no prior knowledge of the tools or the environment. He worked on-site at our customer’s office. He worked closely with one of their smart, experienced and strongly-opinionated and generally skeptical integration specialists.

Justin’s been with us for just over three years, and out of school for just over two. He’s worked on a variety of projects at Atomic, in teams of two to six. He’s not been expected to lead a project before, and hasn’t been trained or explicitly mentored in project management. In short, he’s a smart guy, and a skilled developer, with relatively little professional or project management experience.

I kicked off the project with a short description of the problem and a simple admonition to Justin— even though this was a small project, and was being done partly to evaluate the technology platform, to be sure to run this like any other project we’d tackle. I then stepped back and monitored, but didn’t advise or intervene or “manage”. I was close enough to the situation to step in if necessary if things weren’t going well, but it was clear to everyone involved that I wasn’t part of this project.

Justin’s first question was, “who is our user?” followed immediately by, “when can we meet her?” He already knew who the customer was, in the sense of who hired us, but he recognized instantly he needed access to the actual target user of what he was building. It was such a simple project that he could easily have “just jumped in.”

Without my prompting, by the first day of the project, Justin had decomposed and estimated tasks and begun managing them with our standard tool. The project took 5 weeks total. That’s short enough that you could probably get away with ad-hoc management practices. But that’s not the way we roll, and I guess he didn’t even consider the ad-hoc approach.

By the end of the first full week Justin published an iteration report for the customer. He included a short video clip of the working, bare-bones application to make it easier for the customer to see and understand the progress made.

The final observation that inspired me to coin the term projectstance—my “ah hah” moment—was the approach to testing and design that Justin took. Justin came in to the project assuming he had to show that what he developed was correct and complete. The only question was how specifically he’d go about doing that. Our customer hadn’t been doing any test automation. No one was even sure it could be done with this tool and language. He could easily have gone with the local status-quo: ad-hoc, manual testing. And the project was small enough that ignoring good design principles (single responsibility, separation of business logic and interface, as examples) wouldn’t have been seen as irresponsible. After all, it was “just one form and a login page.”

Building a monolithic, manually tested web app, even a simple one, wasn’t satisfactory to him. It wouldn’t satisfy his need to prove what he’d built was correct. It wouldn’t give him the confidence his work could be confidently extended in the future. And he sure didn’t feel good spending customer budget on repetitive manual testing. Those forces pushed him to look for a responsible, efficient way to test what he’d built. What he discovered was available, and what he built on top of that, took advantage of features of the underlying language that no one at our customer had previously even been aware of. He approached this project assuming he’d find a way to test responsibly, and he ended up with a very satisfactory design and lightweight test framework that paid off on this project—and will continue to payoff for future projects.

Innovation in services comes from people who care. The projectstance that we’ve developed at Atomic gives even our young developers a place to stand, a perspective, and practices to put our strongly held beliefs into action.