The document outlines strategies for pitching software development initiatives and fostering culture change within organizations. It emphasizes the importance of addressing fears and resistance from leaders and team members, advocating for a structured approach to developing new habits and implementing changes smoothly. Essential components for a project pitch include executive summaries, business needs, success criteria, and engaging sponsors to effectively communicate the rationale for change.

1. How to Pitch a Software
Development Initiative and
Ignite Culture Change

2. Ike Ellis @ike_ellis
www.ikeellis.com
Microsoft MVP
Chairperson of the San Diego TIG
Book co-author – Developing Azure Solutions
Upcoming course on Azure Databricks
Crafting Bytes
We’re hiring Data Experts!
www.craftingbytes.com

3. The challenges of culture change
• Personal
• Team
• Company
• Societal

7. Lee Kuan Yew

10. Netflix Famous Culture Slide Deck
https://www.slideshare.net/reed2001/culture-1798664

12. https://dev-qlpr.pantheonsite.io/fast-facts/#isms

13. How do I convince a reluctant
leader that we should go to
DevOps for the database?
How do I fix a cowboy culture?

14. Convince a leader of the need of
DevOps and change the culture?
This is very difficult!!!

15. That’s a culture change that you are
solely in charge of.
How was that?
Those of you who were successful,
was it easy?

16. So how do you get someone else to
change?

17. You can’t hire, promote, or fire a
reluctant boss
So what do we do?

18. Bad Consultants

19. Every boss (and in fact everyone)
listens to the same radio station

20. What’s
In
It
For
Me

21. Every leader I’ve ever met has the same
few things in common:
• A lingering project
• A lingering problem
• A publicly embarrassing event

22. So tune in to the radio station and
calm their fear
• We can deliver faster
• We’ll deliver more frequently
• We’ll have fewer bugs
• We’ll have more success

23. How do we convince reluctant
team members?

24. Change is hard!
Developing new habits are hard!

25. People fear change

26. Phrases of Fear
• We tried that and we failed
• That will never work here
• This is just the latest fad,our processes are tried and true
• Our company is always 10 years behind the industry
• I have too much to do and this will slow me down
• Just another kitchy program that will eat up all our time

27. But we can address their fears and slowly
introduce change so that they are
comfortable with it

28. Steps to developing new habits:
Step 1: Focus on One New Habit at a time
Step 2: Form a new habit? Commit to 30 days per new habit
Step 3: Anchor Your New Habit to an Established Habit.
Step 4: Take Baby Steps. Don’t be too hard if you misstep or
step backward…stay determined to baby step forward
Step 5: Make a Plan for Obstacles.
Step 6: Create Accountability for Your Habit.
Step 7: Reward Important Milestones.
Step 8: Build a New Identity.

29. CULTURE TIP: Make Posters

34. Culture TIP: Throw a Pizza Party!

35. Culture TIP: $15 Tee Shirts!

36. Culture TIP: Fire someone

37. Culture TIP: Make a new logo

38. Culture TIP: Bathroom signs
LEARN ON THE LOO!
• Teach DevOps Best Practices
• Teach how to use Source Control
• Teach good testing techniques
• Teach culture

39. Standardizing source code only
Pros
• Provides audit trail of
development changes
• Manages collaboration
of team members
• Standardizes coding
practices
Cons
• Manual database code
validation, testing, and
deployments
• Requires a custom process
to prevent environment drift

40. Elevator pitch template:
“We are doing _____ so that
_____.”

41. “We should standardize
database code and automate
deployments to reduce feature
time to market.”

42. SQL Provision adds speed & safety
• Rapidly refresh development databases with
real-world datasets
• Easily support dedicated environments that
isolate changes made in branches and allow
experimentation
• Mask sensitive data upon image creation

43. Should monitoring be in your initial project?
Pros
• Visibility into production
health
• SQL Monitor shows when
deployments have occurred,
making it easy to track
customer impact (good and
bad) of changes
Cons
• If an external team in
your organization already
controls monitoring,
proposing a change may
be tricky

45. In a supported POC, ask for
guidance from Redgate
• Crafting executive summary
• Industry standards for success criteria
• Sample schedules & help keeping the team on track

46. Elements of a technical project pitch
• Executive Summary
• Business Need
• Solution to be Proven
• Success Criteria and
Long-Term Gains
• Prerequisites
• Schedule
• Team
• Other Resources
• Risks

47. Project Schedule
Keeps your team moving in sync
Helps key stakeholders understand
• Target project duration
• Key milestones
• Proof of concept schedule and core meetings

48. Identify and approach potential
sponsors
Who might this project resonate with in your organization?
• C-Level
• Executive & Senior Managers
• Department Heads

50. Key actions for a sponsor
• Help build a coalition of managers and peers
• Be visible to employees throughout the project
• Communicate the ‘why’ of the change to employees
https://www.prosci.com/resources/articles/change-sponsor-checklist

51. Messages from sponsors
Engage with employees with face-to-face messaging
• Video and recordings work when in-person isn’t possible,
these are more effective than emails alone
Answer questions about the business issues
• “Why is this change happening?”
• “What is the risk of not changing?”
https://www.prosci.com/resources/articles/change-management-communication-checklist

52. The goal of a Proof of Concept is
demonstrating that the tools achieve your
success criteria

53. Choose your technical champions
This team will:
• Explore methodologies to standardize database code
and choose the best approach for your teams
• Set up a proof of concept (POC), safely outside of
production
• Explore and test automation for provisioning, builds
(code validation) and change deployment

54. A rule for any POC
• It must be safe for the team to make a big
mess during the process
•
It must be safe to fail and start over and try
again

55. Avoid these anti-patterns
• Causes of failed proof-of-concepts
• Not a joint venture
• Key stakeholders not involved
• Think it will be more labor
intensive than it is
• Developers leading without
manager buy-in
• Too much focus on tech benefit vs
business benefit
• Biting off too much at a time

56. Once scoped, kick off any
required security assessments

58. A POC doesn’t take 2 months of
sustained work
The two-three month timeline applies if:
• Your internal point team has other duties
• You only get a few hours of their time each week
Dedicated resource teams have completed Standardize,
Automate & Protect POCs in two weeks

59. SDLC process changes to map

60. Support practices to map
• What team on-call rotations are needed?
• How to avoid single-points of failure in the team?
• How/when to escalate to subject matter experts?

61. Shifting change approval left
• Shifting change review and approval to earlier in
the development cycle speeds you up
• First steps: can standard (pre-approved) changes
help get you started?
• Sponsorship: this is one place where a sponsor
who can help you build a coalition will help

62. Completing your Proof of Concept
• Collate results from POC and implementation plan
• Finalize licensing
• Set target implementation date and schedule first call
and support session
• Internal presentations about business benefits

63. When an executive sponsor has been
involved from the start, POC sign-off and
completion goes very smoothly

64. Any questions?
Ike Ellis @ike_ellis
www.ikeellis.com
Microsoft MVP
Chairperson of the San Diego TIG
Book co-author – Developing Azure Solutions
Upcoming course on Azure Databricks
Crafting Bytes
We’re hiring Data Experts!
www.craftingbytes.com

65. 314
Redgaters and
counting
19
years old
202,000
customers
2m
SQL Server Central
and Simple Talk users
91%
of the Fortune 100 use
our tools
6m
website visits each
year
1286
product releases last
year
70
User Groups
sponsored
About Redgate