I kid you not this is how almost all software development plans are created. Watch the video…
The Expert, A Hilarious Sketch About the Pain of Being the Only Engineer in a Business Meeting
Ask yourself:
- Are you developing software this way?
Then, ask yourself:
- What’s the desired impact on the organization and how will 7 red lines accomplish it?
- Is the impact worthwhile, will it be worth the investment?
- What alternatives are there to 7 red lines?
- What if 7 red lines don’t work? When will we find out? Will the engineer be able to tell us before they are fully created?
- What if the engineer was tasked with the desired impact and not 7 red lines?
- What happens when an organization has a culture of focusing on inputs and not outcomes (desired impact)?
- If we get in the habit of obsessing over tasks, are we more or less likely to think about outcomes? What impact is this likely to have on making worthwhile investments?
My thoughts:
- In reality this meeting ususally takes place in the form of a telephone call where the client calls the “business manager” and asks for 7 red lines, who then calls the supposed “project manager” and asks for 8 red lines, who then tells the “engineer” to make 9 red lines.
- In any game of telephone the message never arrives intact.
- There’s no engineering going on if the decisions have already been made.
- Why hire an engineer/expert if we don’t want them to help decide?
- Simply put, the fastest way to get feedback on whether a task (like 7 red lines) will have the desired impact, is to talk about the desired impact and let the engineers provide their expertise.
- Even better, don’t ask for 7 red lines, ask for the desired impact.
- When 7 red lines have no impact, the engineer will be asked to make 7 blue lines, without a single thought about the desired impact.