1. Stakeholder definition
1.1. A lot of DS work revolves around people
1.2. Actively involved in a project
1.3. Affected by its outcome
1.4. Can influence its outcome
2. Communicate effectively
2.1. Understand stakeholder's goals
2.1.1. The same analysis could be received well or poorly!
2.1.2. Do this as quickly as possible
2.1.2.1. Ask directly: "what's important to you?"
2.1.2.2. Ask around
2.1.2.3. Infer motivation from their actions
2.1.3. Build a mental model of the stakeholder
2.1.4. If you have to deliver news that he/she won't receive well, call in reinforcements
2.1.4.1. Manager or senior team member
2.1.4.2. Otherwise, try to frame the conversation as a collaboration: think how you can be on the same side as the stakeholder
2.1.5. KPIs are often the easiest way to understand stakeholder's goals quickly
2.1.6. The more you align your project with what the stakeholder is asking for, the less likely the project will be to fail
2.2. Communicate constantly
2.2.1. For a DS, almost always the case that they're not communicating enough
2.2.2. Stakeholders thrive on communication
2.2.2.1. How is the project meeting expected timeline?
2.2.2.2. How is the project progressing?
2.2.2.3. How is the work done so far helpful to business?
2.2.3. Create a recurring meeting on the calendar
2.2.3.1. 1. List of updates to timeline
2.2.3.2. 2. What is going well or poorly
2.2.3.3. 3. Parts of your work to share
2.2.3.4. 4. Suggested next steps
2.2.4. E-mail stakeholders directly as needed
2.2.4.1. If in doubt, run by your manager first
2.2.5. Adjust based on stakeholders
2.2.5.1. Businesspeople will be happy to provide direction and collaboration. Cannot provide actual data or technical help.
2.2.5.2. Engineers will show uncertainty about project decisions
2.2.5.3. Executives are extremely busy and can only help in the beginning to set broad goals, and at the end to see conclusion
2.3. Be consistent
2.3.1. Businesses thrive on delivering a consistent product
2.3.2. You're a mini-business within your org
2.3.2.1. Customers: stakeholders
2.3.2.2. If you don't serve them well, they will stop asking you for help
2.3.3. Standardize where possible
2.3.3.1. Analysis: start with same style of objective and data, and end with similar conclusions and next steps
2.3.3.2. Have one file type for your analyses, stored in the same place each time
2.3.3.3. Use same colors and templates as much as possible
2.3.3.4. Have consistent APIs
2.3.3.4.1. Input
2.3.3.4.2. Output
2.3.3.4.3. Authentication
2.3.3.5. Standardizing these will allow you to focus on more interesting DS work
2.4. Prioritize work
2.4.1. Work types
2.4.1.1. Quick tasks that come directly from stakeholders
2.4.1.1.1. It's a distraction from more important work
2.4.1.2. Long-term projects for the business
2.4.1.2.1. Can take weeks or months to finish, but not always urgent
2.4.1.3. Ideas you think have a long-term benefit
2.4.1.3.1. No one is asking for this work, but it feels important
2.4.2. Ask before you pick a task
2.4.2.1. Will this work have an impact?
2.4.2.2. Will this work do something new?
2.4.3. Innovative and impactful
2.4.3.1. Best combination
2.4.3.2. But not many company projects fall into this category
2.4.3.2.1. Not enough data
2.4.3.2.2. Not enough signal
2.4.3.2.3. Not a business group with enough clout
2.4.3.2.4. Complex or unique problem
2.4.3.3. If you do find a project in this category, do everything you can to nurture it
2.4.4. Not innovative but impactful
2.4.4.1. As much as possible, try to take on these projects
2.4.4.2. Your job is to provide value to the company
2.4.4.3. It's a valuable skill to tolerate this kind of valuable-but-not-interesting work
2.4.5. Innovative but not impactful
2.4.5.1. Can be ivory towers
2.4.5.1.1. You will spend months or years holed up
2.4.5.1.2. But the work will end up unused
2.4.5.2. Huge time and money sinks for DS teams
2.4.5.3. You might feel it'll be used when you complete it
2.4.5.3.1. In practice, if you can't see an immediate use, stakeholders probably won't either
2.4.6. Neither innovative nor impactful
2.4.6.1. Classic example: frequently updated report that isn't automated and takes a long time to make, yet nobody bothers to read
2.5. Create a relationship
3. Stakeholder types
3.1. Businesspeople
3.1.1. Little tech background
3.1.2. Often highly engaged
3.1.3. Not just do the model, make sure they understand and trust it
3.1.4. Difficulties when they don't accept model results
3.2. Engineers
3.2.1. Difficulties around the uncertainty of DS work
3.2.1.1. What data you'll end up needing
3.2.1.2. What the output will be
3.2.1.3. Whether the idea will be feasible
3.2.2. Can be taken aback by how little DS can promise early on
3.3. Executives
3.3.1. Generally want to get to the point and understand implications immediately
3.3.2. Trouble tends to happen when work is presented that is unclear or incomplete
3.4. Your manager
3.4.1. In general, should be guiding and mentoring you on your project
3.4.2. Main difference is that you can let your guard down and show some vulnerability
3.4.3. Give clear updates, communicate continuously and deliver presentable work
3.4.4. When having trouble, open up to your manager first