6 Misconceptions About Working with Atomic

I attended a community event where I had a conversation with a startup founder who had ample funding. When he asked about my role, I mentioned that I manage one of Atomic Object's software consultancy offices in Ann Arbor. To my surprise, his immediate response was, "We prefer not to outsource anything." Intrigued, I inquired further to understand his reasons. However, it became evident that his understanding of Atomic's value prop was inaccurate in several ways.

Below are some reasons I've heard over the years regarding why a company doesn't work with outside firms on product development. Some of these objections came from my favorite clients.

"You have to spell everything out for them."

This sounds terrible. No one wants a vendor who can't think for themselves. While I agree that there are some dev shops you'd have to spell everything out for, that's not the case with Atomic. There is a reason we don't call ourselves a "dev shop." If what you want is a bunch of code monkeys, we aren't your solution. You should expect more from an Atomic team.

All our team members have "consultant" in their title. That's because they can take high-level instruction, break it down into an overall strategy that's achievable within a given timeline, and align it with our client's business goals.

One of the reasons we prefer to deploy cross-functional teams with all our clients is that it gives our effort on their behalf balanced innovation. According to Roger Martin, all innovative products have a balance of desirability, feasibility, and viability. On a typical Atomic team, we have designers (desireability), engineers (viability), and product owners (viability).

In a typical agile sprint, our teams make hundreds of micro-decisions on behalf of our clients. If they felt they'd have to spell everything out for us in each moment, I can understand why they wouldn't want to work with us! Fortunately, our clients usually sync up with our teams at the beginning of a sprint to provide high-level direction and prioritization of work. Then they swing back at the end of the sprint to view a demo of the sprint's results. This working arrangement allows our clients to focus on other parts of their business.

I understand the pain that many startup founders (including myself) have experienced with having to spell out requirements in excruciating detail to a vendor who may or may not "get" it. However, that is not the case with an Atomic team.

"If we used a vendor, we would lose institutional knowledge."

In my experience, founders don't properly evaluate two things about institutional knowledge:

• importance
• retention ability

Let's talk about each of these in turn.

Importance

I think founders fear being stuck with a vendor work product no one wants to work on or maintain. But if you work with a vendor who values quality, clean code, and leaving things better than they found them, a codebase should be very easy to onboard into. If all institutional knowledge refers to is "the ability to take ownership over a product", then I just don't think this is an issue with Atomic teams.

When you work with Atomic, you are working with a group of engineers who have collectively built 100s of products. Over that time, they've learned a lot about how to ramp into an old code base, make it better, and make swift progress. Because of this depth of experience, they know how to create a software product that others can maintain, extend, and continue working easily on after they are gone.

All of our teams are also perfectly happy to work side-by-side with our client's developers. In fact, many of our clients have told me that they felt like working with Atomic upskilled their employees. We commonly see client developers work with us for a couple of sprints at the end of an engagement. Afterward, they are completely capable of taking over the codebase once we ramp off. In my experience over a couple of decades, institutional knowledge is easily acquired as long as the work product is high quality.

Retention Ability

Founders often believe that by doing everything "in-house" they preserve institutional knowledge about their product and codebase within their organization. But what happens when their employees inevitably leave for other jobs? Turnover in the tech industry can't be tracked exactly, but any startup founder should be able to come up with an exact number given a specific time frame. However, most industry studies track turnover in the technology industry between 10% and 20%. It's reasonable to assume that institutional knowledge is leaving any startup at an all-time high clip!

At Atomic, we pride ourselves in having many consultants with long tenure and a turnover rate that is roughly half the national average. There are much better odds that a founder's institutional knowledge will persist at Atomic longer than at their own company! As a 22-year-old company, we're a longevity outlier within the tech sector. It's quite likely that when you need our help, the team who worked on your project (and therefore has that institutional knowledge) will still be around to help. Don't think of working with Atomic as losing institutional knowledge. Think of us as the "institutional knowledge safety deposit box" you put in another organization to diversify your investment location.

"We are co-located and therefore more efficient."

A lot of our friends and competitors in the product development consultancy vertical went remote during the pandemic. They got out of their leases and left their offices. They no longer work co-located — if they ever did in the first place. As I have written before, I believe that they are making decisions in the short term that will have long-term deterministic effects.

At Atomic, we've decided that co-location is our future. We believe that work is more meaningful, efficient, and innovative in person. We also offer our team members the flexibility they need to have a life outside of work. It's a great balance where we expect our teams to make decisions in the best interests of their clients, their team, and themselves. So when a startup founder tells me that they are co-located, I give them a high five and say, "Us too!"

"We are agile and can change directions as needed by our customers."

To be honest, I can't imagine a team more flexible than an Atomic team. From our contracting down to how we manage an agile process, we're flexible about what we end up building.

A few years ago, we had a client who came to us with an untested hypothesis of what the next feature set for his ed-tech startup would be. We worked out a ranged budget for what it would take to complete a version of the work that we could get out into the market. But before we started development, we deployed one of our designers to run a couple of days of user interviews with our client's customers to see what they thought about the new feature set.

It turns out no one was interested in the new feature set. However, we were able to pull some insights out of those interviews into a new feature set. We built out a proposal to our client backed by their clients' insights and ended up building a completely new product. In the ensuing years, that new feature set promoted product loyalty, financial predictability, and new revenue for our client — all on the same budget we'd previously agreed upon.

"We work faster than vendors."

I have worked with enough technology startups over the last 20 years to believe that this is true... over the first 50% of a product buildout. I've seen startup team after startup team move fast, incur "strategic technical debt" as a result, and then end up hitting an efficiency wall as the unintended bugs siphon off productivity.

My colleague Mike Marsiglia put it incredibly well:

I’ve noticed that this inflection point happens when an application grows to a size that is too large for a single developer to know all the side effects that a product change will cause. At that point, the rate of functionality delivered quickly reduces and eventually levels out. Each subsequent new feature leads to a series of application bugs that manifest throughout the entire system.

Our teams do tend to appear slow in the first 10-25% of a project. This occurs because they are setting the foundation for quality. They are focusing on an overarching plan that will result in an engaging, successful product launch. They are building out automated testing suites, building alignment around thoughtful architecture, and making a technology choice that will work in our client's long-term interests. Building this quality foundation enables teams to go fast in the long run.

"We understand our vertical and don't have to explain it to anyone."

This objection is a funny one. Most startups are in high-growth mode and are presumably orienting new employees to their vertical all the time. A startup client could just give Atomic that same orientation, and I am certain we'd be good to hit the ground running.

On the other hand, our teams have worked in dozens of verticals. They are experts at becoming experts very quickly. Our teams take on new information, ask tough questions, and lock in on a new problem space. They also bring with them all the lessons they've learned from working in other verticals. This new information is a bonus to our startup clients they might not know anything about. Bringing new ideas from logistics to aerospace, for example, could be a key source of innovation for a high-growth startup.

Because all of our folks are generalists, they've probably worked with dozens of technologies a startup's staff may have zero experience with. Our staff will be able to make suggestions informed by their experience around technology choice and architecture that our client's team doesn't have time or interest in.

If a founder wants to build their product and team in a bubble of their own making, I guess that's their choice. However, I believe that the smartest founders understand when to get outside help to increase quality, throughput, and chances of success. Taking on a quality vendor team can allow a founder to do what they do best: focus on getting market traction, closing that next funding round, and managing the business.

‍