Elevator Pitch
Have you ever had a conversation with someone where both of you make agreements, set expectations, time goes by and the results were different than agreed/expected?
I refer to this as:
"Dealing with people is like dealing with the command line for the first time, You give a command arguments/options assuming you know what you will get and then you realize it is not that easy."
Why is it not easy?
You don't understand the purpose of a certain command and by default its options/arguments. In short, you don't understand the intent.
Why call it "uptime driven development"?
Very likely they will both be right in a sense.
Which sense?
They will both know what it is expected from them.
Ok? So what?
We just need to bridge the gap on how this reflects in tasks, business goals, objectives, timelines, etc.
The way I would simplify it is this:
A value stream map (or several) of interconnected dependencies, each dependency with its own uptime as a "living" graph showing how it affects the overall uptime.
In the case of multiple stream maps, how they affect the overall uptimes.
You may say: "But I'm not a developer/Project Manager... I have no uptime"
Uptime is
How often can people request something from you, how long it will take you to complete it and under which circumstances (Ceteris paribus).
Uptime driven development tenants
Sometimes people fall under fallacies and forget that EVERYTHING IS A REMIX, I will not go over this in much detail since this is an elevator pitch, But I will leave you with a link to what I mean:
https://vimeo.com/139094998
Other interesting topics that may help communicate my intent are:
I refer to this as:
"Dealing with people is like dealing with the command line for the first time, You give a command arguments/options assuming you know what you will get and then you realize it is not that easy."
Why is it not easy?
You don't understand the purpose of a certain command and by default its options/arguments. In short, you don't understand the intent.
Why call it "uptime driven development"?
- Because it is simple.
- Because it makes people try to define it and come to pretty accurate conclusions from the get go.
- Pretty accurate doesn't mean people understand the point
- Because people don't understand the point I think an exercise will help.
- You tell a Project Manager we are doing "uptime driven development" and let this person define what it means from their point of view.
- You tell an Engineer we are doing "uptime driven development" and let this person define what it means from their point of view.
Very likely they will both be right in a sense.
Which sense?
They will both know what it is expected from them.
Ok? So what?
We just need to bridge the gap on how this reflects in tasks, business goals, objectives, timelines, etc.
The way I would simplify it is this:
A value stream map (or several) of interconnected dependencies, each dependency with its own uptime as a "living" graph showing how it affects the overall uptime.
In the case of multiple stream maps, how they affect the overall uptimes.
You may say: "But I'm not a developer/Project Manager... I have no uptime"
Uptime is
How often can people request something from you, how long it will take you to complete it and under which circumstances (Ceteris paribus).
Uptime driven development tenants
- Recognize intent first
- Empathize
- Establish rapport
- Ask questions
- Be open to questions
- Transmitter/source and receiver/destination need to do this. More info at "Models of communication" and "Communication theory"
- No fallacies.
- Respect human drive and personal satisfaction. Which humans obtain through:
- Autonomy
- Mastery
- Purpose
- More on this at "RSA ANIMATE: Drive: The surprising truth about what motivates us"
Sometimes people fall under fallacies and forget that EVERYTHING IS A REMIX, I will not go over this in much detail since this is an elevator pitch, But I will leave you with a link to what I mean:
https://vimeo.com/139094998
Other interesting topics that may help communicate my intent are:
Comments