Engineering Management
Key Questions
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?
Fixed Price vs. Time & Materials: How to contract for software without getting ripped off.
How to read a vendor proposal: Spotting the padding.
Learning Objectives
Learning Objectives
Track your progress as you learn
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).