1. Managing Expectations
Get the freedom to do your job right

2. Who am I
Product Developer - Systems Architect - Freelancer - Development Manager
Past experience
Senior Developer for Cleverbug
Lecturer at the Digital Skills Academy
Director of Tercet, software development consultancy
Software Development Manager for OliveMedia
Barry O Sullivan

3. What I’m going to talk about
Understanding client/managers expectations
Why expectations go so wrong
How to manage expectations so that . . .
1. There’s less stress
2. You have more discretion
3. You get to do a better job

4. What I’m not going to talk about
Managing expectations is not about . . .
● Always getting your way
● Never having to do any work
● Taking them for all their worth
It is about collaboration, not exploitation.

5. Expectations
When our expectations are set, a promise is made that the future will be a
certain way.
If things don’t turn out that way, we get upset and we feel like we’ve been
mislead. This damages trust.
Expectations are made of two parts
What you’ll get and when you’ll get it
What you’ll deliver When you’ll deliver it
Deliverables Deadlines

6. When expectations go wrong
You get given a feature set and a deadline.
There is no discussion, you just have to do it in the timeframe decided.
Management/clients expects it to be done, on time and bug free.
This is pure fantasy
and yet it keeps happening again and again.

7. Why does this happen?
“If you want to fix something, you have to understand it.”
Two worlds, two different mindsets.
Clients (Managers)
Non-technical, but want to help
Must hit milestones mindset
Want to impress their boss
Can feel powerless
Developers
Want time alone to work
Assume shared knowledge
Overly Optimistic
Want to impress their peers

8. What do we want to happen instead
Now you know where you are, so where do you want to go?
We want
1. Less stress
2. More focus
3. Personal accomplishment
4. Personal discretion
We want to do a better job

9. How to manage expectations
Lessons learned from years of mistakes

10. The ground rules: Setting the tone
How you talk about development to clients sets the tone. Whenever you
communicate, keep these points in mind.
1. Software is difficult
2. We are not a wizards
3. We are not machines
more time/people != more code
4. Things go wrong in software and that’s ok
5. We want the same thing, results
6. Be positive

11. Figure out their expectations
Your boss has existing expectations, what are they?
● Ask to have a chat about the project
● Talk to them about past projects
● Ask them what went well and what didn’t
This will help you figure out if they’ve done this before or not and if they have any
existing expectations.

12. Building Trust
If you want them to listen to you, they have to trust you.
How do you build trust?
● Become the expert in their eyes
● Don't bullshit them, tell the truth
● Be open about issues/problems
● Ask the right questions
eg. (Is there anything else I need know?)

13. Under Promise, over Deliver
Never agree to do work on the spot
Never over promise
● Agree to the bare minimum that they are are happy with
● Resist the urge to mention your cool ideas and improvements
Add polish
● Add the little bells and whistles you thought you'd be nice (and easy)
● Showcase it, highlighting these features (don’t mention how easy it was)

14. Estimates
“How long will it take you to make this thing you’ve never thought of before?”
Some tips for dealing with estimates
1. Never estimate on the spot
2. Ignore their estimates
3. Never negotiate with yourself
4. Padding is mandatory
Estimates are guesses. The less you know about what you’re building, the less
accurate your estimates will be. Accept that estimates are guesses, not targets.
How long is a piece of string?

15. Remember, you’re the domain expert
Your job isn’t to do what they say, it’s to bring value to the business.
You are not a machine that does what you’re told, you are an expert with hard won
valuable knowledge and experience.
If you start acting like the expert, you’ll be treated as such.
Remember, you are the expert. You have the experience, they do not, so use it.
Trust yourself to make decisions and others will do the same.

16. Managing Information
The people that hired you don’t know everything.
Infact, that’s exactly why they hired you, because they don’t know how to do your
job and don’t want to know.
They can’t be expected to make the right decisions outside of their domain. That’s
why part of your job is to filter the information they get.
Information Sanitisation
● Share information that will enable the right decisions
● Keep information that will protect the company from poor decisions.

17. Managing Information
Enabling the right decisions
Share information important to their domain. How your deadlines are doing, what’s
changed and what’s getting in the way. Just tell it how it is.
eg.
● What you’re working on
● Sprint status
● Resources issues
● Velocity issues
● Staffing issues
● Scope changes

18. Managing Information
Protecting them from bad decisions
Don’t share everything, there are some things they don’t need to know.
There are things we have to do, to do our job, these can be viewed as “waste”
eg.
● Automated Testing
● Refactoring
● Code Quality/Clarity
● Estimate padding
● Experimental coding

19. Speak their language
When talking to management, listen to how they speak and mirror that language.
Remember, they don’t understand your domain, so constantly mentioning technical
phrases will make them feel stupid and they’ll get defensive.
You want them to understand you and appreciate your input.
Don’t get defensive. Explain your position calmly and accurately.

20. Speak their language, an example
Poor:
“We need to refactor the codebase, it’s too just messy and ugly, our coders don’t
like working in it. We need to ensure code quality.”
● Uses language from your domain, not theirs, so it’s hard to understand
● Appeals to something important to you and unimportant to them (code quality)
Good:
“Our code’s current state is buggy. It’s slowing us down, which is affecting
deadlines, and it’s getting worse week by week. We need to tackle this issue.”
● Doesn’t use any confusing, domain specific language, so it’s easy to understand
● Explains how it will affect the business

21. It’s an investment
It takes time, but it's a worthwhile investment
It becomes second nature after while
It can have amazing results
If you’re not willing to put in the effort, things won’t get better.
This skill lasts a lifetime

22. TL;DR: The key points
Under Promise Over Deliver
+
Speak their language
+
Earn their trust
+
Trust yourself to be the domain expert

23. Q&A
“Judge a man by his questions rather than by his answers.”
- Voltaire
“I needed content for this slide, so I added quotes.”
- Barry O Sullivan