I’ll start with a little flex to make my point. During my career as a professional coder, I shipped code in at least 13 different programming languages1. Naturally, I wasn’t an expert in all of those, but I was quite proficient in most. One rule that continued manifesting during all those years was clear: something was gravely amiss whenever the team cared about its specific tech stack more than the product itself. Nevertheless, I’m willing to bet most of your engineering hiring materials cover, along with perks, your particular tech stack and its benefits. You’re probably picking people with a lot of experience in that stack. Both are not necessary, if not plain wrong.
Stuck on Stacks
For most of my career, I kept switching between languages because I always worked on multiple projects simultaneously. It’s mainly the periods during which I was working on one big project where I got too hung up about a specific language or framework. Whenever that happened, I can say in hindsight that I focused on the technology itself more than the product and the problems we aimed to solve.
I’m not saying I didn’t deliver, but when I honestly look back, I can tell not all the decisions were suitable for the company. For example, I created a framework that used bleeding edge capabilities as an internal tool for our team, which ended up literally never being used. It looked good on paper; my manager supported it, but it just wasn’t a good use of our time.
Contrast that with being tech agnostic. I always had languages I felt more comfortable with but didn’t turn down work merely because of the stack. For example, I worked on a startup’s frontend in Dojo to deliver value. Still, eventually, we made the case to rewrite to a more modern framework only when we were demonstrably sure it would create a significant increase in velocity. We switched from Objective-C to Swift when we felt that would accelerate the development enough.
Weakly Held Preferences
To create an impactful product engineering team, you have to make a conscious effort to cut the connection between tech mastery and success. Tech mastery has a tendency to turn into engineering perfectionism that eventually weighs down effective development. Instead, aim for healthy proficiency. Yes, if you’re working on some deep tech, you’d need people who are genuinely experts on a topic. That’s hardly most companies and most engineers within companies.
Thus, don’t screen solely for candidates who are experts in your current tech stack. Talented and motivated seniors learn quickly; juniors are essentially a blank slate with good coaching. Further, stop “selling” the tech stack. Whenever you do that, you establish a misalignment between what the company needs and what the team identifies with. When someone turns into a “Python Engineer,” it’s going to be a lot harder to make them join a task force working on a different stack or remain agile.
Also, make it a habit to “talk business” or demand that technical decisions be communicated in a way that makes clear the impact generated. Thus, rewrites, adopting new frameworks, hiring experts, and investing time in training must be tied to the results we expect to achieve. It’s perfectly fine to do some things solely for the sake of enrichment or as a perk—but let’s be frank about it and not kid ourselves about the value we’ll immediately see.
Practice some tech agnosticism. It can only help in assembling a team that’s more pragmatic than dogmatic. Don’t do tech for tech’s sake.
- I quickly listed those that came to mind: Java, Objective C, C, Python, Perl, Swift, Ruby, JavaScript, TypeScript, C++, Scala, Clojure, and Assembly. ↩︎