Healthy engineering organizations make a lot of technical decisions. Many of those decisions
impact multiple teams (Frontend, Backend) and functions (Engineering, Product, Customer Success, Finance).
It’s normal to either feel like you’re moving too slow (“too many stakeholders in every decision”) or
that your reckless pace creates frequent rework as issues are discovered late
(“this problem would have been obvious if you’d just talked to Security first”).
Successful organizations make an explicit tradeoff between quick and comprehensive technology decisions,
and the Tech Spec is a key tool for documenting and facilitating that tradeoff,
along with reviewing your Tech Specs in some sort of Tech Spec Review.
As you think through using Tech Specs, remember that while all
engineering organizations have a Tech Spec template, the template itself is specific
to each organization. Earlier stage companies may find this template too heavy,
whereas larger companies may find that it ignores many key topics.
As you look at the proposed template,
consider if some other alternative formats suggested in Other Tech Spec Formats might be a better starting point,
and always remember that the best template is the one that matches your organization’s particular tradeoff
between decision velocity and decision quality.
Based on the feedback in Tech Spec Review, make a decision on whether to
adopt, refine, or throw out the proposal
Now you’re done!
At many companies, the Tech Spec format gets overloaded with too many concerns.
A project once blew up cloud costs, and now every project has to detail their projections for future cloud costs.
Being succesful depends on maintaining a thoughtful balance between navigating and ignoring bureaucracy,
and what specifically makes sense for your company will vary a bit. Sometimes you’re better off ignoring some
On the other hand, if you’re leading the process of designing a Tech Spec format, you should push back on
folks who try to add too many concerns to the template. It’s far more important that folks are documenting things
at all than that they document things comprehensively. Too many requirements means folks will try to avoid writing
There are many different Tech Spec formats, play around with them to find one that
works well for you, whether it’s
or something else entirely
Would you like an email when new interviews are posted?