5 Smarter Ways for Non-Technical Folks to Work with Engineering
Practical strategies for building trust, alignment, and momentum with technical teams
As my work with non-engineering leaders and founders continues to ramp up, one of the most consistent challenges I hear from them is about effectively collaborating with engineering and technical teams, especially if there is no technical cofounder or advisor they can lean on.
While I do believe that finding a good fractional technical leader can be incredibly beneficial to long-term success, if you’re super early or budget constrained, I did want to provide 5 tips that enable you to level up with engineering until that time comes.
#1: T-Shirts: Not Just For Your Wardrobe
The challenge: If you're non-technical, it may oftentimes feel like a blind leap of faith when engineering tells you how long a particular task will take. This becomes even more challenging with hourly contractors whose incentives aren't aligned since they maximize income by maximizing hours.
What to do: Start with a t-shirt sizing system where you ask engineering to size work according to a scale of S, M, L, XL. This:
Gives you visibility without the complexity of precise numbers
Builds trust through understanding their reasoning, e.g. "this is medium because it is similar to the login feature we built last month"
Creates a shared language over time and enables pattern tracking that helps your planning
#2: Sometimes a different garment is needed
The challenge: Even with t-shirt sizing, not everything goes to plan. Something estimated as Small can become Large once implementation begins, or perhaps what was built doesn't work as intended.
What to do: As a non-technical person, if you don’t have a technical advisor who can assist, I still encourage you to jump in on creative problem-solving and not to leave it solely to engineering to handle.
Your business perspective brings fresh eyes to the problem. You can help them step back and avoid sunk cost thinking by diving into whether the assumptions that underpinned the initial solution are even still valid. Is there an alternative idea you can verbalize that might be good enough for now? Sometimes you stumble onto something even better than originally intended.
#3: You need both a dressing room and a runway
The challenge: Prelaunch, it’s common to have a single environment for your application. However, once you have launched with real users, your engineering team needs a "safe" place to implement and test changes without impacting those hard-won users. “We’ll be careful” is not a strategy.
What to do: Have your technical team create a distinct test environment that accurately represents your application. Do this before launch, but even earlier if you can. It can be surprisingly difficult to recreate your application with its 3rd party tools, configs, APIs, etc. I’ve seen this delay launch dates when teams face unexpected issues getting what was already built ready for production.
Pair this with a simple deployment and rollback plan that documents how to get your application from the dressing room to the runway, as well how to return to the previous working version quickly if needed.
These plans are something I often help non-technical founders with, as it can be tricky to craft something simple and approachable that is also effective.
#4: I don’t know how to fasten this fancy belt
The challenge: I often hear from non-technical founders that they wished they had a better understanding of how their product actually works under the hood.
What to do: Modern AI tools make documentation faster and easier than ever to create and consume. Request that your engineering team start to generate easy-to-read documentation (system flows, third-party dependencies, etc) that show how things work.
Couple this with asking for unit and integration tests that validate functionality before users see them and you start to protect your product and users from the impacts of critical technical knowledge going out the door unexpectedly due to team churn.
Better yet, an incredibly powerful unlock for non-technical folks is the ability to couple this documentation with AI to generate a Q&A tool which they can query to help them make more informed product decisions and improve their communication with engineering.
#5: Completing the look
The challenge: You now have all the pieces: your sizing system (t-shirts), backup plans (alternative garments), environments (dressing room + runway), and documentation (the fancy belt), but how do you ensure everything works together seamlessly?
What to do: If you haven’t already, establish regular "outfit checks" (stand-ups) that tie everything together through consistent touchpoints. These create predictable communication patterns, catch issues before they escalate, and help maintain shared alignment on priorities.
The key is brevity and focus. This isn’t about micromanaging and should feel like an enabler for engineering rather than an additional burden. This approach is vastly superior to simply throwing tasks over the wall and waiting for results.
If establishing and maintaining these practices feels overwhelming, consider finding a fractional technical leader like myself, who can help implement and guide these processes until you're ready to bring on full-time technical leadership.