1. How to talk to your developers, By Brian Russel Davis and get results.

2. Brian Russel Davis 17 years of Engineering Exp. Masters in Communication Early Pandora Employee CTO of Nurdy Muny, Inc. Creator of PaperChase

3. You Need To Know Are your developers doing a good job? How can you get them to do a better job? How can you get them to work FASTER ? What are they doing anyway ???

4. How to improve communication!

5. Broken Communication 1. Communication was never established. 2. Misunderstood Timelines & Deliverables 3. Emotional history because of #1 and #2 happens because,

6. Communication is 2-Fold The perception of what was said The timing of the communication > notice I didn’t mention *what* was said

7. if u see us like this and we see u like this Perception Problem Perception Problem

8. *Many* things influence perception *Most* of them are out of your control The *More* you try to transcend perceptions and perspective. The *More* problems you cause. Perception

9. –Marianne Williamson “Old Newtonian physics claimed that things have an objective reality separate from our perception of them. Quantum physics, and particularly Heisenberg's Uncertainty Principle, reveal that, as our perception of an object changes, the object itself literally changes.”

10. this is you, “transcending” perception

11. You Say they hear, When is this going to be done? Why are you working so slow? Can you change this little thing for me? Don’t know what I want, so I’m going to drive u nuts. I don’t understand what is taking so long. I have no idea what you do or what it entails.

12. #0 KNOW yourself ( and your bad habits ) You unintentionally exhibit destructive behavior ( even though you think you are being nice, strong, direct or lenient ) Most of these bad habits are nipped in the bud by adopting a development Paradigm. But, be wary of the pitfalls. The Keys To Good Everything

13. How they see YOU! When you are at your worst

14. Because you lack a development Paradigm or an understanding or project management your developers feel “hounded”. They will tend to slack off when they are not under pressure, because it is the only time they get any peace. “Is it done yet?” Mister

15. When you care SO MUCH about every tiny details and don’t allow any room for input you are actually suffocating your developers. They are not robots, they are people — and many times they are creative too. You need to release your grip, just a little. “I Care So Much!” Mrs.

16. You think by creating a crisis your developers will work harder / more. But, ‘more’ when it comes to code is actually ‘bad’ in most cases. Brain surgery is usually a dire emergency but you would never push your your surgeon to work faster, would you? “Fire Drill Emergency” Mister

17. You are very good at pointing out what you DON’T like but you never define what you WANT. You keep your developers in a constant loop, trying to please you without any real guidance. Try looking for working examples of what you like, and mimic them. “I Don’t Like It” Mrs.

18. You seem to think more hours of work = a better project. Developers who don’t get rest aren’t thinking clearly and tend to make silly mistakes. Would you want the captain of your flight flying on 3 hours of sleep. Give your project a realistic timeline, and let your developer have a life. “Work We 24/7” Mister

19. #1 Adopt a Process ( don’t let one adopt you ) Without a ‘way’ of approaching software development your project will fail. Maybe not now but later. ( Standish Group, Chaos Report ) Being intentional with your process doesn’t cost you time, it saves you time. If you don’t choose something, you are choosing something. Usually the least effective thing. The Keys To Good Everything

20. Communication is effective when you do it in a proven Paradigm. The Paradigm accounts for perspective / perception. The Paradigm makes ROOM for diverse perspectives, weakens the power of negative perceptions and strengthens the sense of team. Co-Lab-Or-Ate.

21. Agile Software Development Waterfall Model Lean Software Development Popular Paradigms

22. #2 Own your Paradigm ( you gotta love it ) Try to do everything. Then use the parts that work. Embrace the Paradigm, have fun with it. Don’t give up. The Keys To Good Everything

23. #3 KNOW your developers ( like your family ) Your developers are not all the same. They have different temperaments and their capacity to code is limited and specialized. Become a connoisseur of tech talent, like people are connoisseurs of wine. Understand the small differences between the type of developers. The Keys To Good Everything

24. Likes Order & Organization *Needs* a timeline, tasks and milestones *Wants* to create a timeline, tasks and milestones. Is angered when the structure is broken or violated Type #1a vp of engineering

25. Likes Order & Organization. *Needs* a timeline, tasks and milestones. *Needs* someone else to create timelines, tasks and milestones.. Feels lost when the structure is broken or violated. Type #1b lead engineer

26. Dislikes too much structure. Very creative, and *Needs* space and alone time to create. *Needs* mini projects. Fails when a project is too big. Gets frustrated when pushed too much. Should never / can’t lead a team. Type #2a senior engineer

27. Never complains about anything. But, take on too much. Very creative, but *Needs* space and alone time to create. *Needs* mini projects. Fails when project is too big. Should never / can’t lead a team. Type #2b senior engineer

28. #4 Know when to STOP ( drop and restart ) Law of Diminishing Returns A common sort of example is adding more workers to a job, such as assembling a car on a factory floor. At some point, adding more workers causes problems such as workers getting in each other's way or frequently finding themselves waiting for access to a part. In all of these processes, producing one more unit of output per unit of time will eventually cost increasingly more, due to inputs being used less and less effectively. The Keys To Good Everything

29. When to FIRE a Dev

30. They don’t want to show you the code, or give you access to the repository where the code is saved They don’t want to work with other developers, “they only work alone” The don’t want to get paid according to milestones or results. The keep changing the timeline they created, without your input. RED FLAGS!

31. They insist the bugs / errors you are seeing are only on “your system.” They insist that the project does not need to be tested. They don’t understand how to set up / use different application “environments”, development, staging, production. RED FLAGS!

32. Your SCRUM development meeting last over 30 minutes. SCRUM development meetings should last 15 minutes, 20 tops. Long 1 hour development meetings are signs of a broken process. Your developers are fighting ( verbally ). Fighting isn’t always bad. And don’t assume the person with jr. rank is wrong. Use the Paradigm and listen to the team. You might need YELLOW FLAGS!

33. Summarize