In my previous post on this subject, I discussed the three stages of using F# in your organisation (Curious, Enthusiast and Adopter) before focusing on those individuals who struggle to transition from Enthusiast to Adopter. We looked at the first step for making the case in your organisation for adopting F#, which outlined how to put an effective plan in place for adoption.
In this post, I want to focus on "pitching" - making the case to your colleagues and bosses to adopt F#. Having a great plan is an important step, but if the message is delivered in the wrong way, it can turn off those people you'll need the support of before you even have a chance to prove the worth of F#.
I've split the tips into two sections - those that relate to you as an individual and your delivery, and the content of the pitch itself.
Attitude and delivery
First, I want to cover the delivery side of things - who you're talking to and how to deliver the message as effectively as possible.
1. Consider your audience
Be aware who you are talking to. Don't only think about what you want to talk about, but what they want to hear. What are their concerns? What is their technical expertise? There's little point going into a meeting talking to a non-technical budget holder and showing them code-focused demos or watching videos of Don Syme talking about computation expressions. Instead, think about what they are interested in.
What are the issues you're facing at the moment and how could F# help address them? For example, have your team been encountering lots of live bugs (you can point to low bug rates of F#)? Or high staff turnover due to not enjoying their day-to-day development (you can point to high developer satisfaction of F#)?
Alternatively, are they concerned about the cost of adoption? Or the risk of what happens if it all goes wrong, or how your team mates will feel about F#?
Ask in advance, and shape your proposal and pitch accordingly. Consider having two separate sessions or splitting the session into two halves to deal with both "sides" of the equation.
2. Pick the right time and place
Choose the right time and atmosphere when you'll have the best change of success. This applies both to the time of day as well as the calendar period! If people are stressed because everyone is in firefighting mode trying to escape the current project, you'll have less chance of people being receptive to trying something new. Similarly, consider the time of day. Are people fresher in the morning - or is everyone swamped first thing and perhaps after lunch is a better time? Do your team hold regular meetings for optimisation / learning opportunities? Do you present this at your desk or in a meeting room with a slide deck and samples?
Think about where and when - the right setting will get everyone into the right frame of mind.
3. Be confident
There's a subtle yet important distinction here in terms of how you frame the discussion and how you explain yourself: You're not asking permission to adopt F#; you're making the case for why you should be adopting it.
- Passive: "I'd like to try using F# on our next project, what do you think?"
- Active: "We need to start investing using F# in our organisation because...."
Asking permission immediately shifts the responsibility to someone else to make the decision for you and appears passive - you're implicitly demonstrating that you don't have confidence yourself in it. Instead, show confidence and move the discussion to considering how the reality will be.
4. Be positive and passionate
There's nothing wrong with showing passion. Demonstrating that you care and believe in what you're saying can go a long way to convincing people that it's worth taking you seriously. There's no need to rant and rave - that's not the passion I'm referring to. I'm talking about showing that you believe in what value adopting F# can bring to your team, and that you're willing to take personal responsibility to help make it a success. This doesn't mean you're the only person responsible, but it does mean you're championing it and will show leadership towards steering things in the right direction.
5. Be prepared for scepticism
Some colleagues may be interested. Others may be worried if they will be able to "get" F#. Others may simply not believe in FP and think that it's a fad. Some scepticism is healthy; it's your job in this moment to listen to people's concerns and questions.
Don't rule questions and concerns out of hand - either address them with facts or examples, or tell them that you'll look into it and get back to them (and make sure that you do!). You can also ask people to simply trust you that their concern won't be an issue - just bear in mind that there you can only use this a limited number of times (even if it's true) before people will lose belief.
Remember: You don't need to convince everyone - and as much as you might want everyone to jump at this, don't expect that to happen. You'll always have a distribution of people that jump at the chance to learn F#, those that are wary but willing, and some that will simply not want to try it out. Focus your energy on the 80% of the audience that are either key to making the decision happen and those that are most likely to be willing to try it out.
The content
I now want to move to looking at the sorts of content you can present, and how to deliver it effectively.
1. Fully prepare your pitch and demos.
Have a structure - even if that's a set of bullet points or topics; don't just walk in and start talking. Consider using a combination of slides and live demos (as long as you have planned them through - if things don't work, your audience will lose confidence). Relate demos and slides to real-world data - ideally, with a domain your team are already working with. Outline the plan you've put together and the colleagues that have worked on it with you; illustrate the way you've mitigated risk and the way you've put a roadmap in place for adoption.
2. Don't forget the basics
You may have spent looking at F# from a number of angles and understand it well enough to talk about it. But don't forget that there are people you'll be talking to that may not have that same level of understanding, so ensure that the basics are well understood and addressed.
For example, you may want to remind people that F# is a general-purpose programming language; that you can write console, back-end, distributed and web applications etc.; that it runs on .NET Core and can interoperate with C# and VB .NET etc.
Explain - or demonstrate - that you can talk to SQL databases or whichever external services and systems you're working with. If you're talking to a technical audience, again consider what the challenges you're facing today. How can F# help with them? Can you show some actual code samples or live demos that can allay concerns? Perhaps talking about how F# can reduce the need for many kinds of unit tests is something that are important to the team.
Ensure everywhere has a common understanding of the basics - this will avoid confusion and lead to other points you make being better understood.
2. Focus on the positives of F#, not the negatives of your current language
We developers are a proud bunch of people. And nothing turns off a fellow developer to something new like being told that the language they've spent the last 5 or 10 years honing their skills on is archaic, fundamentally flawed or somehow otherwise a waste of time. Don't do this: all you'll do is turn people into a defensive mode and even make them feel personally attacked.
Instead, focus on the positives that F# brings to the table and emphasise that this isn't about whether one language is intrinsically better than another, but whether it's the right fit for your team and organisation today.
3. Highlight the key benefits
Explain the positive elements of F#, whilst trying to not sound like a salesman! You can do this in a few ways, such as:
- You can relate benefits to your team and the current struggles they're facing, whether it's a recent bug that would not have occurred in F# or an area that was particularly painful and expensive to develop.
- Highlight new features and tools that the team might not be aware of - for C# developers, these may include things like the REPL, data exploration and analysis, discriminated unions and succinct domain modelling and problem solving, or type providers (these do work on .NET Core, albeit some of them still need to be upgraded). For Python devs, this could be about higher performance computing or running on libraries that are used in production systems 24/7.
Again, empathise with who you're talking to, and frame it in terms they can relate to.
4. Address any elephants in the room
Don't pretend that F# is perfect - it does make trade-offs which means you give up some things in exchange for some benefits. Rather than pretending that they don't exist, address them up-front on your terms. Make it clear what you'll be giving up by moving over to F#, and how you can mitigate against them.
You can explain this as a set of trade-offs - for example, if you talk to a technical audience, you can explain how not having method overloading means that you get super powerful type inference. For a business audience, you can discuss how working in a language that has a smaller population than others means you'll have a competitive edge over those companies and teams. See these blog posts for more examples.
We've identified some of the more common technical concerns here - read through it fully and come up with some others of your own!
5. Explain the costs of not adopting
There are ways to invert the argument as well: what's the impact of not adopting F#? Higher bug rates? Missing out on the opportunity to differentiate yourself from your competitors? Having to rely on third-party vendors instead of taking control of your own destiny?
Ask yourself some standard "sceptical" questions and prepare some answers for them. How would you answer the following questions:
- "How can you code without classes?"
- "None of us are mathemeticians, we won't be able to learn F#!"
- "What use cases do you expect us to use F# - what is it a good fit for?"
- "Our current language already has lambda expressions so we already have FP - there's no need to invest in learning F#."
- "Does Resharper work with F#?"
- "You can't write web apps in F#, can you? What do we do then?"
- "Do you really expect us to just stop what we're doing and rewrite all our code into F# tomorrow? It's going to take months to train up the team!"
- "I've heard that FP languages use lots of memory and are slow. We can't have customers waiting 10 seconds for web page responses."
- "What do we do if we need to quickly get F# devs in on a short-term basis? What if we need support or training?"
And so on.
You'll most likely be able to formulate answers to these questions - think them through beforehand (or drop us a line to ask for advice!). And again: empathise with whom you're talking to.
Summary
In this article I've outlined some key tips for presenting the case for F#. The main elements are to frame the conversation in the correct way - be confident and positive, but importantly be honest and genuine in your desire to use F#, justifying it with points that resonate not just for yourself but with those you are speaking to. Be prepared for common questions, and show you've thought through the main points!
Good luck - and have (fun _ -> ()).
