How to Build Effective Cross Functional Eng Teams
The Art of Breaking Down Siloes
We are super excited to mix things up at Software Snack Bites today with a guest blog post by Karim Fanous, VP Eng at StrongDM, Dremio, Qumulo, and more. This post will focus on building effective cross functional engineering teams. If you enjoy Karim’s writing and advice, I highly recommend you subscribe to his Substack where he writes about all things engineering, startup, and coding!
In this post, I will cover some of the critical interactions between engineering and other organizations. I will describe why these interactions are important, how they occur and common mistakes I’ve encountered. We will focus on three main interactions between engineering and the following organizations: product management, people operations, and sales.
Eng <-> PM
How Do They Collaborate
If there’s one organization that engineering has the most interactions with, it is product management. This interaction is critical to the success of the company. The duo of Engineering & PM, are broadly speaking, responsible for what (PM) to build and how (Eng). The ideal interaction, which I will very briefly summarize here as it warrants an entire post of its own, can be succinctly captured by the following statement. Product and engineering need to land “the now” and plan “the next”.
Landing “the now”, implies collaborating on completing or releasing whatever features are being actively worked on. Examples of these collaboration points could be scope negotiation, timeline adjustments, GTM enablement for new product or feature launches and so on.
The most obvious point of collaboration, in planning “the next”, is assessing tradeoffs. I will posit that your organization, much like most startups, is resource constrained on the engineering side. This means that there’s much more work that you want to do relative to your ability to do the work. Prioritization is key. However, prioritization cannot happen in a vacuum. If you’re trying to prioritize a list of features to build, one of the key questions you want to answer is cost, or engineering time. Engineers collaborate with PMs to answer the cost and trade off questions to be best they can. Engineering estimates are notoriously hard and fuzzy. The scope of this collaboration is not just limited to estimating a list of features the PM team wishes to build. It should extend to technical tradeoffs and importantly, engineers providing their own list of work-items. The latter typically fall under the bucket of technical debt, internal tooling, etc. The bandwidth of the engineering team should not be entirely allocated to building new features and maintaining existing ones. Investing in engineering specific work (tooling, testing,..etc) is also important to build a successful product.
This was a very brief overview of healthy collaboration between PM and engineering. As I mentioned earlier, this collaboration warrants an entire post if not more.
Common Mistakes
Lack of investment in a PM function is a common pitfall. I’ve observed this at the early stages of a startup, seed and series-A. The engineers are furiously working on a prototype or launching the v1 product with the lack of a PM function that is trying to validate what they are building. The PM function could be an explicit PM persona, the CEO or otherwise. The intent is there must be someone concerned with validating what the engineers are building and doing so from day 1. The opportunity cost of building the wrong product or feature can be catastrophic, especially in the early days of a startup.
Another mistake I see is one I call “stonewalling engineering” This typically manifests by PM, and in fairness engineering leadership, not allocating sufficient resources for engineering work-items. The intent of this work is to give engineers a voice in the investments they need to do to maintain a clean and sustainable code-base. Engineering needs to have a voice on what to build and why. I’ve often witnessed this tension arise post series-A, typically when the code-base has grown to some decent size or when a shipped prototype has outlived its life expectancy!
Arguably the most common mistake I’ve seen, spanning all stages of a startup, is the lack of clarity on decision making between PM and Engineering. At one extreme, I’ve witnessed PMs boss an engineering team and dictate what needs to be built and how. Similarly, at the other extreme I’ve seen engineers treat PMs as project managers, simply helping them plan their work. Both are wrong. The best model between both requires joint accountability and clear decision making powers. That requires a healthy dose of collaboration as alluded to earlier, and some clear decision making boundaries. PMs are responsible for what to build and why. Engineers on the other hand are responsible for how to build it, which includes all the technical tradeoffs, staffing. They are also responsible for when, meaning when is the feature/product ready for release.
Eng <-> People
How Do They Collaborate
The second most common point of collaboration between engineering and other organizations has been in my experience, with the People team. Some of these points of collaboration are obvious and likely ubiquitous, namely recruiting. However, there are many more manners in which both organizations should collaborate.
The intent of the collaboration between the Engineering and People organizations is twofold. First, is to attract the very best talent to the company. Second, is to retain that talent. Those two goals require that both organizations work very well together. Additionally, most of the work to enable these two outcomes will be done by the engineering organization, especially in the early (pre series-B) stages of a startup. There are many pitfalls though that stand in the way of realizing these outcomes.
Common Mistakes
Perhaps the most critical mistake I’ve seen startups do is to not invest in a People team early enough. I use the word People team intentionally, because it implies more than recruiting. You need to invest in a People team that can enable the attraction and retention of the best talent for all parts of the organization. And you need to do so early enough, before the startup scales. In my experience if your headcount is ~100 and you’ve only invested in the recruiting function, which is not atypical, then you’ve gone too far.
The second mistake I’ve seen is to assume that the People function is entirely responsible for both of the outcomes I alluded to earlier. This typically manifests itself when the startup is about to scale which tends to happen post series-A.
Let’s start with recruiting. The engineering organization is responsible for defining the sourcing criteria - the archetype to hire for - and the interview structure including the debriefing process. Your recruiting team might be very capable of sourcing for engineers, but they likely aren’t able to source the right engineers for your team. Engineering must define the sourcing criteria to the recruiting team. Not only should they do so, but I’ve often found it critical to establish joint sourcing sessions between both organizations. These sessions are meant to teach your recruiting team the patterns and traits of a good engineering candidate for your team.
Another problem I’ve witnessed is the lack of investment in proper People programs, especially as the startup starts to scale post series-B. As the startup grows, it will have attracted employees of various backgrounds and tenures. At some point, programs addressing feedback, career growth and compensation have to be established. The People team must take the lead at establishing those, but has to do so in conjunction with the Engineering team. I’ve seen some of these programs developed with no input form the Engineering team, which doesn’t yield desired results. Engineers need to collaborate with the People team to define the traits that make a good engineer as well as the growth stages - career ladder - for the engineering team.
Eng <-> Sales
How Do They Collaborate
The relationship between engineering and sales tends to grow over time. In the early days of a startup, the engineering team constitutes the majority of the headcount. It’s not uncommon to not have a sales team beyond the founders. In time, and as the startup attains product market fit, typically post series-A, the startup starts to invest in GTM functions.
The earliest collaboration points between sales and engineering tend to occur during that initial scaling period. As the sales team starts to scale, they start encountering new customer segments who might have use cases or requirements that aren’t immediately aligned with the current capabilities of the product. Sales obviously wants to win these deals, which can introduce an interesting point of tension with product and engineering. I call this point “feature deal making”.
Common Mistakes
The most common and critical problem in the collaboration between sales and engineering, especially when handling one-off features to help win deals, is the lack of a common and agreed upon decision making framework. On the one hand sales wants to win the deal in hand. However, engineering and product management want to ensure that the opportunity cost is actually worth it. The cost of winning that deal needs to be commensurate with the effort and the opportunity cost of not working on a plethora of other features. Therefore, there must exist a framework that helps address this tension. Not only do both sides need to come to agreement on what that framework is, but they must disagree and commit. Sales need to know that sometimes the answer to a one-off feature will be “no” and therefore risk losing the deal. Engineering also need to acknowledge that sometimes they will have to be redirected from what they are presently working on to work on a feature that enables sales to win a deal. I cover this framework and more in this article.
Conclusion
An engineering team does a whole lot more than simply write code. In this article, I only covered three of the organizations that engineering collaborate with, but there are more than those three.
The main takeaway I want to impart is the following. Every collaboration with another organization represents an opportunity and a challenge. Before you embark on the collaboration, spend time with your counterparty to understand the desired outcomes of the collaboration and how to enable those. This alignment is crucial to yield a productive and healthy relationship. The more productive these collaborations are the better for the engineering organization and the company as a whole.
Some stuff I really enjoyed reading this week:
This is the best podcast on health that I’ve listened to so far from Andrew Huberman. It covers specific methods of improving sleep, diet, exercise, types of exercise, nutrition, when to eat more carbs vs not, etc. Perhaps the most important thing I could ever listen to and now need to rep-listen and take copious notes
Good read from Peter Attia on why wearing a continuous glucose monitor for everyone regardless of diabetes is important. And also why glucose variability matters more than absolute glucose levels.
My favorite low carb, high fiber & protein muffin recipe!
Why SASE networks are increasing in importance and will be a large area of enterprise spend in the future.