How we’re building a culture of serving each other while serving our customers.
In the nascent stage of a new company, the goals of a young Engineering Team are simply to ship new products (fast) and to iterate in a way that continues to meet customers’ needs. The team is small, can maintain continuous conversation within itself and with other company leaders, can divide responsibilities, and can organize according to whatever structures and habits best facilitate the work.
As the Engineering Team grows with the company, responsibilities divide and sub-teams form. In our case, we call these sub-teams “Pods.” Each Pod is relatively autonomous and develops its own working culture and habits, and can more or less continue to act like its own nascent Engineering Team. The Pod works in the way that it needs to work in order to ship the product it owns.
At some point along the way, there are enough people in enough Pods that an “Engineering Group” emerges. Over the course of several years of working together, individuals adapt to each others’ working preferences and efficiencies, and Pod cultures start to become more fixed.
Fixed cultures can be good: they can be a sign that Pods have found the most efficient way to work together to generate value for customers. Fixed cultures can also present challenges.
There is a risk that innovation can stagnate due to lack of cross-pollination, Pod cultures can come to stand at odds with the culture of the entire Engineering Group, and of course, working on the same types of projects for too long can contribute to burnout. Finally, if Pod ownership lanes become too rigid, things invariably come up that seem to fall in between well-defined lanes.
Or, think of it like a physical factory. If everybody in the Eng Group is dedicated to building and shipping products, whose job is it to keep the factory running, to address internal proposals, build new tools, expand current tools, and in general provide the support necessary to improve engineer quality of life?
Before you respond with, “It’s the job of the DevOps Pod!”* let’s consider a few things…
*For non-technical readers, DevOps is a cultural movement that’s centered around expanding the developer’s view of the software lifecycle beyond just writing code. Expanding that understanding to span from design to implementation to building to deploying to operational concerns to observability is what closes the feedback loop between what developers write and how that delivers value, which in turn gives developers the agency they need to become more effective in improving the systems around them.
First, we care a lot about individual career growth and the options available to our engineers.
We want to build into our structure the potential for fluidity in an individual career journey. It is often true at Datavant that people who become an Engineering Manager move back to an Individual Contributor role. We try to think about the engineering career journey not as a single ladder, but as many possible staircases.
Second, like any other Pod, the DevOps Pod also has to prioritize its work, often selecting for the broadest impact.
If a problem sits somewhere in between “I can add this time-saving internal feature in an hour during the course of developing a feature for a customer,” and “This is a problem the entire Eng Group is dealing with regularly,” it’s very possible that this problem will persist and become “just the way things are.”
An added consideration is that many of these kinds of problems don’t show an immediate result for having been solved. If solving one of these thorny in-between problems created immediate value, it would be rolled into shipping a feature for a customer. In efficiency-oriented environments, it can be a big mental hurdle to decide to take the time to tackle problems with long-tail results when there are literally dozens of immediate-impact problems to solve.
For example: CI/CD Performance
When we push code, it goes through a peer review process. During the peer review process, we run tests on the code to determine changes that need to be made. After that is an approval process and a subsequent process for deploying the code to various environments. Once deployed, it gets checked again. This entire cycle is known as the Continuous Integration / Continuous Delivery (CI/CD) performance cycle.
Imagine making one feature that accelerated this feedback loop, like building a better local Python virtual environment. This is precisely one of those “in between” issues that’s not part of building a feature for a customer, but may not ever rise to “high priority level” for a DevOps Pod.
We could address this problem in a few ways:
- Give it to the DevOps Pod anyway!!
This resolves the “between lanes” problem, but as mentioned, has the potential to become a second or third-tier priority on that Pod’s to-do list. Continuing to drop problems like this on the DevOps Pod also does little to break down (and in fact potentially reinforces) any mental separations or informal boundaries that may exist between Pods. - Have a Pod pause their customer-facing work to work on it.
This could be a refreshing change of pace for that Pod, unless they don’t actually want to work on this problem, in which case it becomes an onerous and potentially demoralizing assignment. It is also potentially highly problematic for customers (and therefor for the business) if a Pod that is usually focused on shipping customer features simply…stops. - Create a “guild” or “working group.”
This would allow people from various Pods to decide to come together to solve these between-lane problems. But how do we determine how to distribute the split time for individuals contributing to their Pod and individuals contributing to their “guild”? Also, how do we establish “guild accountability”?
Enter the “Dev Productivity Pod”
Unlike the rest of our Pods, the Dev Productivity Pod is an opt-in Pod and rotational by design. Engineers step out of their usual Pod, work on an engineer-life-improving project (without splitting their focus) for a limited period of time, then return to their regular Pod (or interview for a new Pod assignment!) Some advantages offered by this structure are:
- Engineers without previous leadership experience can take on a Tech Lead role.
- Engineers can work on projects outside of their usual focus area and develop new skills to take back to their regular Pod.
- The rotational structure democratizes the focus of the Pod. Instead of having a top-down dictation of project priorities, engineers who see an opportunity to make an improvement can make it happen.
- Engineers who don’t usually work together get a chance to work together, potentially in a completely different work formation, which in the long run significantly increases the potential for cultural and technical cross-pollination.
- Pod Managers are compelled to adopt a longer horizon line and think about things like succession planning on projects as they might be rotating individuals on and off of projects every quarter.
- It offers a potential “ramp-up” space for new grads to acclimate to Datavant culture and learn the business from the inside.
- It improves our overall onboarding habits by creating a “desirable churn” between Pods.
- It offers a chance for veteran Datavanters to take on a new “Day 1 Project”.
- It can be a tool to combat burnout.
- The entire Engineering Group begins to regard themselves as their own customers.
The importance of this last item cannot be overstated. One of Datavant’s core values is that we are “Customer Obsessed.” That’s a great value for any business to have, but how do we accomplish it? How does it play out in real life? One way to be “customer obsessed” could be to engage in obsessive finger pointing when something goes wrong for a customer (as things do!) But if we turn the mirror back on ourselves and see our own team as our customers, then the narrative begins to shift from, “Why hasn’t your team fixed this?” to, “I want to help fix this.”
Thinking about serving the needs of our own team cultivates empathy. It destroys “entrenched-lane thinking.” It builds a team-cohesion that can easily get lost if we only ever work in product-optimized formations.
As an Engineering Group, it’s critical that we align on a north star while also understanding the boundaries of ownership along our path towards that north star. A set of values are a great starting point for creating this alignment, and can even act as tie breakers in moments of difficult decision making, but a set of values stops being useful the moment it starts to degrade into a set of thought-eliminating cliches. We see the DevProductivity Pod as just one out-of-the-box interpretation of one of our Core Values that also makes life better on the inside.
By Dave Chen and Nicholas DeMaison.
About the authors
Dave Chen joined Datavant as an Engineering Manager in February 2023, and is currently Manager of the Pipelines Pod. Connect with Dave via LinkedIn.
Nicholas DeMaison writes for Datavant, where he works on the Strategic Communications team and leads talent branding initiatives. Connect with Nick via LinkedIn.
We’re hiring remotely across teams. Check out our open positions.
.svg)
