"Development of any product is not important. Development of the man is important, and for that, you need to involve him in the process of development."
SWE vs. FDE
A typical SWE role is a relay race where the baton is passed from company executives > engineering managers > product managers > SWEs > sales > customer support. The framework or features are then built and handed over to sales and customer support to ensure the intended end-user is content with the originally scoped product. They capture end-user feedback and report back to the PMs, and the relay race starts again. We have to account for the many biases that get absorbed in this process, leading us to stray from the user's growth.
But let's remember: solving user needs is the sole reason we started building in the first place.
What needs to change? The person responsible for building these tools often never interacts with the user. In typical SWE companies, human insights are often mislabeled or misunderstood as user feedback. But it turns out the insights are much more than feedback—a different approach is needed. One should involve the tool builder (the SWE, in our case) to merge with the user: to interview them, ask questions, explore discussions, and identify and scope their business problems. To accomplish this, I believe FDEs need to have three key human values: 1) low ego, 2) high collaboration, and 3) accountability. Low ego leads to a bias check, high collaboration leads to a high density of actionable work, and accountability guarantees customer outcomes. You must hold yourself accountable for the end results of your customers' businesses. FDEs need to view themselves as owners of their customers' businesses. You are the CEO, but with zero authority.
The delivery mechanism in our industry is often tasteless and does not care for the best experience for our customers. Quoting Ted Mabrey's definition of what inspired Palantir to adopt the FDE Model (for lack of a better explanation): " The FDE role was famously inspired by Karp’s observation of how excellent French restaurants operate. The waitstaff is an intrinsic part of the kitchen. If you want to order the wrong wine with the fish, the waitstaff will simply tell you no. In order to provide the best experience the delivery mechanism has to be a part of the product, it has to be opinionated, and it has to own that in this case the customer is going to get the best meal even if they don’t know how to ask for it. "
The underlying value that ties all this together is empathy. So we need to pay attention and show genuine empathy for our customers. The most important data a business generates are its decisions, the rationale, and their consequences. There's a saying: "Software that isn't getting better is getting worse." Early in my software journey, when I was switching from C to C++, the concept of OOP was introduced. Our high school professor cemented this thought in our minds: that our approach to writing code must now change. From writing code for procedure-oriented programming to writing code for object-oriented programming. We were to ask ourselves the question, "For whom are we writing this code?" rather than, "What needs to be done, step by step?" We were to find relationships between objects to make the same outcome achievable. In turn, I want to relate this to our software industry. The industry has become a procedure- oriented industry. The law of the land needs to change, and I want to dedicate my time and effort to solving this problem.
When an intellectual tech professional was asked, "Is the lack of a Magnificent Seven-equivalent Indian company due to an insufficient focus on consumer needs, and are individuals working in tech in India less empathetic toward their users and consumers?" they answered that the culture is different here; the mentality does not allow for this bandwidth to take shape. I firmly believe that to create a sufficient offset, the culture needs to change, and it is no simple task. It will take time and effort but is a necessary evil that demands to be taken down. The mentality shift is drastic; in a way, we are flowing against the current of the river by not holding ourselves to 'good enough' standards. Change takes time, and culture is built with an effort for change.
Why I Want to Be a FDE at Your Organization?
Data comes in awkward shapes and sizes, often siloed and inconsistent with our expectations. For enterprises, the kryptonite is extracting the exact use cases for their customers from this situation. It is a hard job. I want to meet your customers where they are and help reduce the gap between them and your technical team. I want to be dynamic and impactful to the growth we embark on by managing organizational alignment, technical aptitude, user adoption, reimagining technology-enabled business processes, and, most importantly, achieving 'outcome-market fit' (not just product-market fit).
In tech, questions come first, and good questions originate from people. In a way, the age of AI for consumers is an age of questions. I feel I have a pretty good knack for it. I love conversing with people and asking questions; I feel I'm having an insightful conversation and making the most of the time I have with them. I want to be in the most resource-constrained environment of your organization and develop from there. What we need now isn’t new technology, but people who can ask better questions. I believe I can strive in this role and build on my potential.
My contrarian take is that we are directionless in tech. A lot of the people I interact with, myself included for a long period, upon self-reflection, want to learn technology and are working hard to keep up. The thought process is that "learning technology will lead to something," without knowing what problems they want to solve. I wasted a lot of my time chasing this. Every time tech changes, new norms are created, and we rush toward the current trend to secure some form of monetary gain. The result is professionals jumping into the industry with practical skills but without problem awareness, industry understanding, and/or self-reflection. This structure is designed to demand depth without direction.
I am committed to the customer and the customer alone. My aim is to be an empty vessel when I interact with them, allowing me to absorb insights unknown to the individual themselves. I want to use my technical soundness to—emphasizing again—be the bridge between your most critical users and your technical team. Therefore, I want to understand your mission and its pain points. I am, in fact, a missionary, not a mercenary.
I have taken my learnings from observing Palantir and from a handful of hobbits who have solved crucial problems and created intrinsic value for the world.