As the Head of Engineering at Datavant, I often work with folks outside our engineering team. I recently shared this list with other leaders at Datavant to help them build better relationships with the engineers they work with regularly.
Running an engineering team is about balancing three kinds of work
First, there is new feature development. This is what our customers care about. We want to spend as much time on this as possible! This is the tip of the proverbial iceberg. Under the surface of the water are the other two kinds of work.
The second type of work is maintenance of existing features. This is the “tax” we have to pay to maintain a feature we’ve already shipped. It consists of increased testing costs, increased development time because of interactions with the existing code, and knowledge sharing overhead across the team. Often, this cost is not explicit, but rather is paid implicitly in increased development time for features.
When maintenance work gets too high, we can invest in refactors & other productivity improvements that will pay off in reduced maintenance costs. This is the third type of work.
Source code alone isn’t very valuable
The ability to modify code & create new code is critical. When a company invests in building software, it gets two resulting assets: 1/ the source code for that product, and 2/ business context in the heads of engineers (which is distinct from skill/career growth). The value of (2) is easily overlooked by non-engineers, and is often larger than the value of (1). A team that has built domain knowledge can ship faster.
A corollary is that you are continually balancing delivering work now and expanding the team’s future capacity to deliver (by building domain knowledge, investing in hiring, training, mentorship, etc).
Engineers require maker time
Writing code and fixing bugs requires large uninterrupted blocks of “Maker Time”. It requires holding lots of context in your head about the data structures in your program, and there is some overhead to establish that context. Paul Graham wrote the definitive essay on this. In this model, a 30-minute meeting doesn’t just reduce productivity in a 2-hr block by 25%, it reduces it by essentially 100% … it cuts it into two smaller blocks that are each too small to do this work.
Shipping code is a team sport
A lone engineer heroically building a product is largely a myth — an engineering team gives feedback via design reviews & code reviews. Even projects that would seem to be independent are often coupled together via source repositories, code-level dependencies, shared infrastructure, etc. Your changes can break a feature someone else was working on, or require another engineer to refactor their work to incorporate yours. Much of modern DevOps is about trying to minimize this dependence.
The first version is always the easiest
The overhead to ship increases as a project grows. For v1, there are no design constraints, backwards compatibility or tech debt. After you ship v1, you need to ensure new changes don’t break existing scenarios, maintain interfaces that your customers have gotten used to, and work around the suboptimal design decisions you made early-on. Testing overhead also grows as you frequently add new tests, and rarely remove existing ones.
To the engineers reading this, I hope this list equips you with talking points to build better cross-functional relationships. And to the non-engineers, I hope this helps you better understand your engineering counterparts. Datavant is hiring for engineers who are smart, nice, and get things done.
.svg)
