Article summary
Atomic’s success ultimately depends on our client’s success, and their success turns on much more than the quality of the software we build. This drives a lot of our business decisions:
- We brought design practices and designers into Atomic back in 2007 to help our clients determine the right thing to build.
- We start every project by digging into the business ecosystem and our client’s business goals — that understanding helps our teams contribute valuable new ideas and guides development priorities.
- We’re as diligent with deployment and hosting as we are with programming and design.
- We offer beneficial support agreements.
In short, we take a broad view of what’s necessary for market success and provide help well beyond programming.
Software Is Never Done
One challenge all of our clients face stems from the fact that software is never done. That’s not to say that you can’t predict, in time or budget, when you’ll be able to deploy your product, just that there will always be more you need or want to do. Hopefully you’re successful, and you have users asking for new features. You’ll probably have a roadmap for future releases. The environment in which your software lives will inevitably change, creating a need for maintenance. On rare occasions (for Atomic at least), you may even uncover a bug that needs to be squashed. Once the heavy lifting of a first release is done, the need for development drops dramatically, but it doesn’t go to zero.
For our larger clients with their own developers and IT staff, we work closely with those stakeholders to ensure a smooth transition to internal teams. A project lead from one of our corporate partners has observed that we are effective at this transition because we apply the same sort of human-centered design approach that we use in product design.
The problem of maintenance is more challenging for our smaller, entrepreneurial clients. For these clients we’ve developed two offerings over the years that help them make the transition to a software company. The first is a one-day workshop that provides an overview and a whole bunch of questions on what it means to be a software company. Our second offering is talent development and technology and practice transfer. We help our startup clients vet — and sometimes even recruit — their first software developer hire, and we make that person part of the project team.
Incubating New Talent
By bringing the client’s first tech hire into the team during the development of the first release, we ensure that this person is intimately familiar with the architecture of the application, the code base, the testing strategy, deployment and hosting. They receive hands-on training in our development practices and process. They come out ready to support, maintain, and extend their application. Assuming things went well, they have good relations with Atomic developers and designers. This in turn helps for future work in which we may be involved, or for consulting and support between major development phases. Assuming they master and continue our development practices and process, the two companies have good alignment for future collaboration.
We usually suggest making that first hire mid-way through the development of the first release, particularly if the hire will be a less-experienced person. This lets Atomic to make the best choices for the project and doesn’t delay project start, while allowing time for the new hire to absorb and master all aspects of the product.
When we’re done, our client has an employee that can be highly responsive, knows the product and code base, is less expensive for the steady state, has good relationships in Atomic for future heavy lifting, and has backup to call to consult on particularly tricky situations. We’ve used this approach successfully for Bloomfire, The Common, Catalog Choice, Blue Medora, Workr, and Varsity News Network.
While we give up some service revenue with this strategy, we gain more in the long-run by increasing the odds of our client’s success.