Team structures and technology: A key to success

Over fifty years have passed since the introduction of Conway's Law, and it still rings true, especially for technology driven businesses:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

- Conway's Law

I have seen this principle at play (at least to some degree) in every company that I have been at, and in almost every department that I have interacted with inside of those companies. In some cases, changes to the organizational or reporting structure actually highlight the need to, or serve as the catalyst to champion a redesign of a legacy system (or set of systems).

Awareness of the link between organizational design decisions and the technical structure of artifacts that an organization produces can also be something of a curse to people that have a vision and opinionated enthusiasm for building great products. Inside of a mature organization with a crystalline reporting structure, projects to build or expand products that may lead to a divergence from that communication structure can be an uphill battle and may lead to people on execution teams (product managers, developers, designers, analysts, etc.) becoming demotivated or burning out.

That's why, at Railz, we took note of this principle and from the outset, we set up our engineering organizational structure to be a mirror of the technical structure we designed for the products that we were building (or going to build), rather than just throwing developers into a totally flat organizational structure (like most startups do) and hoping for the best.

This has allowed for a high degree of specialization, modularization, clarity, and buy in, across the engineering teams. At Railz, the entire data team (which owns data analysis, data engineering, and data science capabilities) is integrated into the engineering team with full membership. For the majority of new deliverables (integrations with new Accounting Software Providers [ASPs], for instance), the teams work hand in hand.

This allows back-end developers on the engineering team to specialize in tech like Typescript, Node, and optimize for speed to integrate with our ASPs and save responses from their APIs or SDKs in formats like JSON & XML without spending too much time on the actual data inside the payload). Data analysts work closely with the Product team (both of which have deep knowledge of accounting data [what it means and how to use it]) to determine how to best map data from ASPs to our Railz normalized schema (and iterate on that schema when necessary.) Some ASPs have very divergent ways of presenting the same data, and there need to be many transformations along the way. These specs are then given to the data engineers and data scientists, who are able to specialize in tech like R and Python to build and maintain highly robust code that processes the payload responses, normalizes them to our schema, calculates statistics and runs the data through models for Railz Analytics as appropriate, and finally outputs the data into the appropriate data stores. The back-end developers can then take the clean data and send it back through the API as needed, and the front-end developers determine how to best use and display that information on Railz Dashboard. All teams work closely with our DevOps team to ensure neat deployment processes and high scalability as we onboard new customers with thousands of new businesses.

To prevent the type of crystallization that would impede future growth, we have also been consciously evolving this engineering structure to match what we are building and how we are growing, as well as the new technology that we are adding to our stack. Engineers have been promoted across the organization as they demonstrate potential and make impacts. People organization is a big focus at Railz, and is a key to our current and future success.