Engineering Management
Questions You'll Answer
What trade-offs and assumptions are we making to build this feature?
Are we building exactly what the spec says, or what the business actually needs?
Is it okay for me (as a business owner) to ask "dumb" technical questions?
How do we ensure developers feel safe challenging a bad requirement?
How do developers work in the "normal" world vs our environment?
Why do vendor costings often sound ludicrous compared to personal experience?
What You'll Learn
Bridge the gap between "Business Requirements" and "Technical Reality"
Understand whether the technical advice you receive is good or trash
Scrutinize billable man-effort, fees, and proposed work by vendors
Create an environment where developers can push back on bad specs
Hard Truths
It is okay, and necessary, for business owners to dive into the technical world. Blind trust is not a strategy.
You can outsource the coding, but you cannot outsource the 'thinking'. If you lack the internal expertise to verify vendor work, you are not a client; you are a hostage.
The 'Bus Factor' applies to vendors too. If only one external company knows how your system works, you don't own the system—they own you.
Developers often make invisible trade-offs and assumptions to get code working. You won't know about them until something breaks in production.
It is not the developer's job to question your business assumptions; they are hired to build your specs into reality. If the spec is flawed, the code will be flawlessly wrong.
There is nothing inherently bad about challenging technical estimates or decisions. It's not micromanagement; it's understanding the constraints.
Reports, guidelines, and restrictions are often written by people with no idea of how the technology works.
Productivity of engineering talent is wasted explaining basic concepts to non-technical people just so they can write reports.
Adding manpower to a late software project makes it later. (Brooks's Law).