Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing expectations

75 views

Published on

Learn to communicate with business owners so you can deliver value without sacrificing required quality.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Managing expectations

  1. 1. Managing Expectations Get the freedom to do your job right
  2. 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. 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. 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. 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. 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. 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. 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. 9. How to manage expectations Lessons learned from years of mistakes
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. TL;DR: The key points Under Promise Over Deliver + Speak their language + Earn their trust + Trust yourself to be the domain expert
  23. 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

×