How balena Embraces Conway’s Law at Scale


This post is by Mackey Craven from Openview Labs


Click here to view on the original site: Original Post




According to Conway’s Law, organizations which design systems can only produce designs that mimic the communication structure of the organization. When Melvin Conway coined his term in 1967, he probably couldn’t imagine all the ways that idea might apply in the future. The fact is, the product you build and the organization you build aren’t that different and can’t really be separated. Case in point: I recently interviewed Alexandros Marinos, Founder & CEO of balena—one of the newest members of the OV portfolio—about their approach to both team and product development. They hold the same core values for both:
  • Be humble
  • Take into account what is being done
  • Learn as much as you can
  • But also be first principles and open to solutions that worked in another context.
The balena team is all about being open to different kinds of solutions because they are working to support people
are building out an entirely new market. Their particular customer is the fleet owner, a person who creates and manages a fleet of devices. The fleet can be anything from drones to screens—anything that is a computer, but doesn’t necessarily have a user on it. Being on the cutting edge, these entrepreneurs that balena helps are having to build everything themselves and solve several problems at once. As a result, they often fail. Luckily—for them and for balena, they were able to see the bat signal the entrepreneurs sent up crying out for better infrastructure to support their efforts.

Building Your Organization Like a Product

Once balena focused on what they wanted to build, they found themselves having to combine two worlds organizationally. On the one hand, they were launching a startup; and on the other, they were a remote company by necessity because they didn’t have the budget to build a big local team. So, their approach to building out the team wasn’t unlike what a software architect would do when building a backend system. You put a few servers together, it starts working, and then you get more traffic, which creates a bottleneck. So you identify the bottleneck, you fix the problem and you scale up to the next level and keep going. Of course, they didn’t want to build their organization or their business on a pile of hacks that would collapse under its own weight, so they were mindful about the whole system at each step of their evolution. Their primary directives were to be incremental and practical—both with their product and their team. While they’ve never had any qualms about going to the furthest reaches of research or academia for inspiration, the rule is that whatever they build is held to the standard of having to actually work. To ensure that this happens, they have intentionally built a very open and collaborative culture that encourages questions at every level. New team members are often intimidated by just how frequently people raise challenges, even to Alexandros’ ideas. Alexandros told a story of an entrepreneur friend of his who came as his guest to one of balena’s annual summit meetings, and how surprised he was that people were “being super harsh” and challenging Alexandros “on the spot” during his keynote. Alexandros explained, “That’s not a bug. It’s a feature.” It’s all part of balena’s approach to design and making sure that everything they create is able to deliver value as quickly and thoroughly as possible.

Focusing on the Building Blocks, Not the Outcome

Another strategy that complements the open, collaborative and questioning structure is one they adopted from W. Edwards Deming, known as the father of lean manufacturing. Inspired by his work with the Japanese after WWII, Deming advised against manning people by the numbers. Rather than setting targets for people to hit, he advocated for focusing people’s attention and efforts on the foundational tasks that would drive the desired outcomes. Because of this, balena has a no-commission approach to their commercial structure. Instead of having a commercial team that is looking to maximize the number of sales—which can become a pretty abstract idea—they have a team that is focused on doing the right thing for the customer. It’s a pretty controversial break from tradition, but they’ve seen strong success with the model. It’s similar to the concept behind the French chess term of en passant, which describes a move that takes an indirect approach to capturing a pawn. It’s a great metaphor for the idea that you can’t pursue happiness directly. Instead, you pursue the tangible things that will bring you the intangible—you pursue meaning, good relationships, a purpose and then you wake up one day and realize you’ve achieved happiness. The balena team doesn’t go directly after revenue. They believe that’s an unsustainable path. Instead, they focus on customer success and making sure their business model is delivering the value it needs to. They encourage our people to follow their short-term instincts to do the right thing in the moment for the customer; and they’ve found that this strategy leads to long-term success and stability.

Rallying Around a Product-led Approach

This idea of letting people focus on their best instincts is a key to balena’s product-led (PLG) approach. They didn’t start out as a PLG company. In the early days, they brought in some sales talent, but it created friction and tension. The sales team came in with a traditional, modular sales playbook, but that didn’t mesh with the rest of the product, which had been running in a more systemic way. In the end, they hit a breaking point where they had to choose. They could either focus on sales and compromise on product, or they could go product-led and compromise the commercial approach. They chose PLG, and that turned out to be the right decision. The way balena thinks about it, there shouldn’t even be a dichotomy between product-led and a more traditional go-to-market strategy. Again, it’s about being able to see the parallels between building a product and building an organization. If you build something into a product, and it doesn’t help you, you remove it. Same thing with how you build out your organization—if you try a particular approach (in balena’s case, traditional sales), and it doesn’t move you in the direction you want to go, you need to switch things up.

Bringing All the Pieces Together to Craft Success

Balena is always looking for ways to pull all these ideas together in a way that benefits their product, customers and company. One small example of how this works is the way they designed and developed a scheduler that helps them coordinate meetings with their remote, distributed team. In retrospect, it makes perfect sense, but it’s not something you’ll find in any standard practice handbook—yet. Their remote team covers the globe—from New Zealand to Vietnam to Georgia to locations in South Africa, and all across Europe and North America. To say this poses some scheduling challenges is a grand understatement. Their internal structure revolves around the notion of the project. They pull together the relevant contributors and assemble a collaborative team that functions with the help of a single, designated coordinator. This model means that projects are fluid, with people joining and dropping off throughout the process as they are needed. In addition, external factors are constantly changing, including people moving time zones, and daylight savings time, etc. This can create a nightmare for people in the coordination role who want to have project check-ins with the full team at a regular time. The logistics are practically unmanageable. You could spend your whole day figuring out who can come early, who can stay late, who can switch another call. And because they are so widely distributed, you could end up asking people to meet at 10PM or 4AM their time, which isn’t something they want to ask of anyone on the team. They realized this was a constrained optimization problem, so they formalized it as that kind of problem and applied some existing technology (like the Microsoft Z3 optimizer and later Google’s OR tools) to build a solution that minimizes for pain. So, depending on where you are, which time zone you’re in, and your preferred work hours, their scheduler tries to figure out which meeting times will make you suffer the least. They achieved a double-digit improvement in pain reduction, and then they found that running it for 5 minutes gives you one type of solution, but if you let it run for 500 minutes, you get an additional 5% decrease in pain. This solution isn’t core to balena’s company’s mission, but it does represent who they are and how they want to work. It allows somebody to have dinner with their kids or fit in the workout that’s going to keep them healthy over the long term. The ripple effect of giving their team this tool is very positive. By demonstrating that they care about each member of our team and doing everything they can to make their lives better, they’re a more productive operation, they don’t lose good people, and they’re better able to execute on their company’s broader mission. So, coming back to Conway’s Law, if organizations which design systems can only produce designs that mimic the communication structure of the organization, then it’s deeply important to understand how your company’s communication structure works. It comes back to the idea of focusing on doing the right thing that’s right in front of you, instead of chasing the conceptual idea on the horizon. And in balena’s case, it’s about solving the real problems that need to be solved. The post How balena Embraces Conway’s Law at Scale appeared first on OpenView.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.