So, we nailed the product. Ataccama ONE made data instantly available to humans and machines as high-quality data products, with governance and compliance ensured automatically. Our customers love it, market analysts love it, and every year we’re landing new customers at a rate we’ve only dreamed of.
Be sure about one thing though — this is only the beginning. There’s just a huge untapped potential ahead of us, and so much more we can’t even see yet. It’s all there for us to discover along the way. When man set out to land on the moon, it was just a stepping stone to what lay beyond. A big one, to be sure, but far from the end. And this is exactly what’s happening with us. We made a giant leap forward, both as a company and as individuals… but it’s just the start of something even bigger. 🚀
Ataccama used to be a growth company. And as we grew, our expenses and size of our team were growing right along with us.
Our setup at the time couldn’t handle the strain. We had to make changes. Big ones. If we wanted to reach our goals, we had to look at things from a completely new perspective. Instead of walking a linear path, we had to go exponential. Instead of growing, we had to start scaling.
Tipping the scale
Everything we did had to conform to this new philosophy now. It wasn’t about small local fixes anymore, tweaking things here and there… We had to put a hard stop to habits we’d had for ages because they’d never measure up, no matter how much we tried to improve or optimize. Instead, we had to go back to the drawing board. We had to be sure that any solution we came up with would have to scale out of the box.
Here’s an example: let’s say we’ve developed a new feature. Going forward, we have to be sure this feature could be used by thousands of users, independently, without overwhelming our support and project teams with tickets. Or that our Product-as-a-Service team would be able to offer and operate this feature for hundreds of customers. Or that the rest of the company would be aware of this new feature, and consultants would know how to use it. The scale mindset needs to govern everything we do — building a new feature, defining a new process, defining a new organization setup…everything.
Making end-to-end meet
“Most importantly, we wanted to empower our people. We wanted to set clear boundaries and just say what needed to be done — the how would be completely up to them.”
As we were growing, we started hiring a lot of top-notch engineers, designers, UX researchers, and product managers. The best front-end, back-end, design, you name it — we had it. To make all these brilliant minds feel connected, we put a horizontal organizational structure in place to help them work together and share their expertise. Sadly, somewhere along the way we also lost the end-to-end ownership of the product…you know, the thing we actually sell.
Our mostly monolithic architecture was coupling technical, organizational and process things together, starting from the code, to builds, to testing and release, leading to a lot of dead ends and miscommunication. Even the teams developing their own services had to keep up with the pace of the slowest one. None of it could scale. Even though we were growing almost 100% year over year by an engineering headcount, we were becoming less and less effective.
People started settling into a “task” mindset — once their part was done they’d hand it over to someone else, passing the buck further and further. Pretty soon, this conveyor-belt development style started cracking. Production incidents started popping up, unplanned work and unfixed bugs were mounting, and our engineers were jumping in left and right in a panic to fix everything. Our delivery speed and quality was dropping, our user experience was suffering, and worst of all, our people actually started to feel disconnected.
For us, the only way to move forward and reach our goals was to establish a completely new organizational structure. We envisioned a team of empowered experts, people that take full ownership and end-to-end responsibility of a specific part of the product. An empowered team that doesn’t care only if the UI’s looking nice, but also about how the customer will install the product, whether the performance is up to scratch, and whether the user can configure it themselves with the materials we provide them. An empowered team that goes beyond even the software itself, an empowered team that cares about how we sell the product, how we promote it, how we demo it, how we train users, and so much more. The product is not just the software — it’s the entire customer experience. This empowered team is fully aware of that, and acts accordingly.
On top of this, we wanted to prevent coupling in our new structure. And we couldn’t forget Conway’s law when thinking about our own systems, either: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
Ultimately, we wanted to establish total top-down and bottom-up alignment. We wanted full transparency into what our people are working on right now, who’s working on it, and precisely how it contributes to fulfilling our goals. We wanted dedicated capacity for focused, uninterrupted work, real work that drives product innovation. Most importantly, we wanted to empower our people. We wanted to set clear boundaries and just say what needed to be done — the how would be completely up to them.
And you know what? We did it. And we’re pretty happy with how we did it. Next time, we’ll tell you exactly how we pulled it off, and what our Missions and Spaceports actually are.
Curious to find out more about our new department structure? Head over to our SpaceUP blog and see how we’re actually putting all these ideas into practice every day!
Want to see how it all fits together firsthand? Ready to blast off with us on our next big Mission? Check out our open positions listings around the globe on our (new!) job portal!