Selling F# to stakeholders - how?
The F# development community is awesome when it comes to promoting itself at macro level with resources such as F# for fun and profit, F# Workshop, The F# Software Foundation, and open source projects such as the Visual F# Power Tools. I've also found them very supportive on Twitter and when asking vendors to support the language.
This post though, this post, is about selling F# at micro level. Most of the tips will use F# as an example, but obviously they can be applied to other areas.
Note: I may or may not have been listening to Katy Perry's song 'This Is How We Do' on repeat while writing this post. Regardless, I ask, no, I insist that you listen to it too in order to set the correct ambience.
Why should I read this?
I've always been surprised at how poor many developers are when it comes to selling technology options to their colleagues or stakeholders. Throughout my career I've either been marginally talented, or incredibly lucky (likely some denomination of both) when it comes to getting people onside with the technologies I want to use to solve a problem.
All of the tips in this post can be applied to other technologies, but I'm going to give them a F# spin as I often find when talking to people or presenting if I even mention F# people ask questions about how to convince others to get behind the language.
I'm going to be talking as a consultant, because that is my day job. Even so these tips are just as applicable elsewhere.
But what I really hope, is that if you are a former, current, or future client that you stop reading here.
It is said that if you know your enemies and know yourself, you will not be imperiled in a hundred battles; if you do not know your enemies but do know yourself, you will win one and lose one; if you do not know your enemies nor yourself, you will be imperiled in every single battle. - Sun Tzu
Clearly, the people you are trying to convince are not your enemies, far from it. However, this famous quote from Sun Tzu really sums up the embodiment of how to best convince people to your way of thought.
Understand the lay of the land
Even if you have been working in your current environment for a long period of time, you might not actually understand it. This is an entire blog post in itself, but to summarize the key areas of what makes up an environment.
- The key stakeholders. Not everyone is equal in an organization, and often the people at the top are not the important ones to influence, but it is the people below them that they rely on to make their decisions.
- Figure out their inclinations (e.g. technical, business, personality, pragmatism) and try to work within them as opposed to running up against them.
- If the organization has any, consider the factions. Be careful who you side with, and equally, be careful about always siding with the same faction continually. I'm not saying never do this, but as in all things, understand the consequences.
- AKA, politics
- Look at / find out the history of the organization, most of the decisions of the present you will find embedded in the past.
- In particular look for what the mistakes of the past have been. For example, something introduced that the organization considers a mistake, or situations where someone tried and failed to invoke change.
F# - For many organizations picking up a new language is something that they would consider huge risk. You need to look at the people more willing to adopt something new and win them over. By all means, talk about the technical upsides of F#, but unlike many technology choices there is no tangible benefit to business stakeholders so you need to focus on the other benefits in regards to reduced bugs and productivity gains.
Top-down or bottom-up?
You're probably familiar with this in terms of design, but I'm talking about how you approach the organization in regards to the initiative(s) you are trying to propose. Generally one angle is more likely to reap more success than the other, and often you should attack both at once.
When talking to management consider what the key benefits that will interest them, as well as the potential drawbacks. Business stakeholders tend to be more interested in tangible benefits and typically have concerns around on-going costs, licensing, architectural / infrastructural impacts, risk, how it can be phased in, and impact on customers.
While developers obviously care about tangible benefits, they tend to be more focused on the non-tangible benefits than business stakeholders. Their concerns revolve around different issues. How quickly are they going to pick this up? Will this make their jobs easier or more difficult? Is it something they are going to enjoy working with, or is it going to be a PITA?
Things will move more quickly with management being the key driver, however, there is something to be said about a groundswell movement behind an initative.
F# - You're probably going to have more luck approaching things from bottom down. Certainly, there are important benefits to F# that impact directly on the business, particularly around productivity, scalability, and maintainability. But those benefits are going to reasonate far more with a developer.
How I met your mother
How you were brought into the organization has a huge impact on how quickly you are going to be able to invoke change. If we're talking about a vehicle, we're talking about your acceleration.
If you were brought in as a subject matter expert as opposed to a general development resource this will give you more credibility initially.
If you were head-hunted, or asked to help the organization (as opposed to just applying to a job advertisement) then this will give you a lot more impetus for change.
Credibility is the currency of invoking change.
You are surrounded by intellectuals. Intellectuals rarely take things at face value and often double check information that they are presented with.
Don't skirt around issues, and certainly don't hide anything. Present legitimate alternate options. The more up front you are about alternatives and drawbacks to the approach you are suggesting the more it boosts your credibility, and people are willing to have belief that this is in fact the best option.
F# - By all means talk up how awesome F# is when compared to the other .Net languages. But at least mention other functional languages or paradigms. For example, could Reactive Extensions do a sufficent job? And talk about F# and its poor tooling. Give credible examples on where F# excels, and when it doesn't do as well as contemporary C#.
Earn that credibility
Most of the credibility you are going to earn is not through what you say, but what you do. You'll gain credibility for doing things that may be completely outside of what you are trying to achieve.
Earn that credibility, store it up, and then use it to drive the change you are looking for.
F# - When working on more mundane tasks, consider using and then promoting the functional programming that is available to you in C#. It could be through using a functional programming style, showcasing the power of immutability, elegantly using LINQ / lambda expressions, or tapping into some Reactive Extensions. Not only will you record some wins, but the way in which you do it will be noticed.
It's better to ask forgiveness than permission
You might be wrong
Not everyone sees from your perspective. And you rarely have the full picture. Technology and methodology choices often have pro's and con's and you may not be weighing them up objectively (we're all human, I'm just as guilty of that as anyone) and as I need to re-iterate again, you probably don't have the full picture.
Just because it is the right technology choice, does not make it the right choice.
You're asking people to take a risk
Chances are depending on whatever decision is being made it isn't going to be you footing the bill, left with the screaming baby, or bearing the long term scars. (Yes even if you are a permanent employee)
One of the best ways you can encourage people to take that risk, is to take that risk with them. There have been many occasions where I have invested my own personal time in a technology working on a proof of concept before presenting it to the business because I considered it worth the risk. Not only does it show you are committed, but it also gives the business something tangible they can look at.
And you know what works better than doing the work yourself? Leveraging a colleagues efforts. Thanks Daniel Chambers! :)
F# - If you're into F# chances are your first forays with it have been on personal projects. Talk about them with colleagues and even better, show them! If you are working on something that you think would be much better in F#, write a port and prove it!
Play your cards to your chest
Occasionally I will propose things that I have no intention of fighting for. Some people (see the lay of the land) just want to make their presence felt. Give them their wins.
Likewise, be objective as to whats important. Sometimes you may want a particular piece to be included in the scope of change. Think really hard about if it is worth potentially sacrificing the larger scope of change that you are fighting for. Be prepared to give up some of the smaller pieces for the greater good.
F# - The biggest battle is to get people to use F#. Don't sacrifice it by fighting over frameworks. Advise and let people draw their own conclusions. You want everyone to feel like it is a joint team effort, not you leading the charge.
There is no convincing everyone
Sometimes in this world you meet people so stubborn there is no convincing them. Even with Columbus sailing around the world, and our advances in space technology there are likely still people out there in the modern world who believe that the world is flat.
It's a war, not a battle
AKA the conclusion.
One of the common mistakes I see is developers getting frustrated when their initial sally didn't meet the success they were anticipating. Convincing people to make the right decision is often like hunting. It involves a lot of observing, waiting, and then quick action at the right moments.
Be patient, and never get upset.
When I first come into a new organization I just sit and watch - often for weeks. I do my work using their processes and their way of doing things. I keep notes and keep track of what is going on. I may make the occasional small suggestion (unless something is being particularly painful) but I keep the bulk of my thoughts to myself. I look at where improvements can be made, but more importantly I also consider how and when to try and introduce them.
F# - You can look at phasing it in slowly. Scott Wlaschin has a fantastic article with great tips on how you can start introducing F# into your work without impacting production code.
For to win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill. - Sun Tzu
But the golden rule is this - What would Katy do?