Your company wants you to be competent (if not brilliant) with your programming tools. But even in the best of times, Management is reluctant to pay for training classes, tech conferences, or even a programming book. Here's a few suggestions that might, might get your manager to approve the expense.
One outcome from my latest blog post, When the Job Changes But the Programmer Doesn't, was that I learned from the reader comments (both here and on reddit) that — at least in the experience of many programmers — formal training just doesn't happen. Management laughs if you ask to put a programming book on your expense report. A tech conference? You must be kidding. Developers are, too often, left on their own to sink or swim.
I admit this surprised me, as I've been lucky enough to work for people who value education. While I haven't gotten every course I've asked for, my primary training difficulties came from working as a telecommuter (I wasn't in the office when they scheduled classes). As a tech industry journalist I go to plenty of conferences, usually to report on them, but certainly I can (and do) listen to presentations to learn. Travel budgets are always tight, even when times are good, but at least there's an expectation that of course I have to keep learning.
To a large degree the availability of training (for this context, I include books and conferences as well as hands-on classes, as we all learn differently) is a matter of company culture. If the company cares, they'll find a way to get you trained. And if they don't care, no amount of wheedling will convince them to pry the money out of the budget. You probably don't know which kind of company it is unless you actively ask about it in the job interview.
Or so it seemed. To check that assumption, I asked several developers and other IT folks to suggest ways to can convince the boss to pay for developer training. Specifically, I wanted suggestions that they knew worked, not just something that sounded good on paper.
Books should be easy, right? Ha!
I once worked at a then-relatively-large software firm that created an actual library. They purchased just about every relevant programming book possible. Employees could check out the book just as if it were from a public library, except that it was just upstairs. The company only paid for the book once.
At the time, it was a marvelous solution. There was no way I could afford every book available, and since this was long before Amazon reviews I had little idea of which were worthwhile. At the very least, it let me try out a book before I invested in my own tech library, and it was sure handy when I needed an obscure reference. (Nowadays, some of that obscurity need may be met by a subscription to the wonderful online tech books site Safari, but my own book collection scares people. Why do they always ask, "Have you actually read all those books?" Well yeah, and I wrote a few, too.)
Before you rush to drop "Start a Library!" in the Suggestion Box, keep in mind that not every developer sees a company library as an advantage. Developer Alexei Zheglov strongly believes that developers spend more time with a book if it's on their desks, not on a common shelf (or worse, on a different floor). "While organizing a programmer's library sounds like a reasonable cost-cutting move, it cuts benefits more than it cuts costs," he says.
Selling Training to Management: Do it in their terms.
When you want to convince the boss to let you attend a tech conference, the first thing to do is ratchet your own expectations into place. It's not just a question of whether the company culture encourages continuous learning, but what your education means to their bottom line.
For example, software developer Ray Vega points out, "The 'culture' of the company is dedicated by how it makes money and who is responsible for helping to making that money." In general, he says, software companies whose product is technology-based tend to be better at providing and paying for skill improvement resources for tech employees. When the technology workers training is closely related to company revenue, it's easier to get the boss to listen. However, Vega adds, "If you work on an application that has no direct association with how the company makes money (for example, an internal time tracking application for an insurance company) then it will certainly be an uphill battle."
Also be aware of your company's budget cycles. In some companies, companies are more open-minded to extra spending during the last trimester (for "use it or lose it" budgets). In others, the budget is completely consumed by the end of the year, and it doesn't matter if this training class will fit you with angel wings.
You might want to work on the assumption that your company cares about your personal development. Maybe it does. And as Daniel Tunkelang, chief scientist at Endeca says, "An employer who shows no such concern will pay a price in employee productivity and loyalty." But it's obvious that plenty of employers are willing to pay that price. Or you might be as clever as consultant Paul Oldfield, who got it written explicitly in his job description that it's part of his job to bring industry good practice knowledge into the organization. "That has helped in many ways; it means I'm spending about half my time educating in one way or another, even while doing other work," he says. "Whatever I do becomes collaborative and educational if there's any opportunity for it to become so."
Instead, no matter how the conversation happens, put all the attention on what they get out of sending you across town or across the country. This an ROI conversation. "You have to show what value the training will bring to the company or your team," says Java, Linux, and open-source practitioner and evangelist Viraf Karai. Here's a few arguments that might help do so.
Offer to share materials and experiences with the rest of the team upon your return. Hosting a brown-bag lunch session spreads the new techniques around and reviews relevant content you learned at the workshop. From the boss's viewpoint, that means that everyone gets training for the cost of sending one person; and the team probably will like the opportunity to find out about the newest stuff. (If they don't, don't say mention that to the boss.) In addition, points out QA engineer Michael Furmaniuk, presenting the information to the team and anyone else interested afterwards gets you both training and presentation skills.
Another common selling point, says professional trainer Carl Pritchard is for an employee get a commitment from the trainer for some practical deliverable that could be used or modified by the organization (such as tools or templates).
It can be hard to sell "awareness," but in some shops perhaps you can strike fear into the boss—at least if you have some scary statistics handy. Rob Cheyne, CEO of Safelight Security Advisors says he's taught over 8,000 developers, architects and managers world-wide. "People who do not think about security every day are simply not aware of many of the issues that directly impact their applications. MITRE's common weakness enumeration (CWE) list contains over 700 common security flaws, and there are thousands of ways that these manifest in your applications. You cannot fix what you are not aware of."
One suggestion I liked was to talk to the Bean Counter who'd have to approve the training budget, but first query her about the certifications she needs to keep up. Many professions have their own continuing education requirements, and you can dangle this conference as an example of the way you keep up with yours. (I'd credit the person who gave me this suggestion but I managed to somehow lose it; sorry.)
Consider showing commitment by paying for some training yourself (suggested by a developer whom I first met at a tech conference). "Bottom line: You are the commodity being sold, and it's ultimately up to you to make sure that commodity is worth buying," he says.
A few more (with particular thanks to Karai who supplied several of these):
- Explain: I've heard that technology XYZ is being offered during this seminar. Everything I've read indicates that our software will be more reliable/faster/cheaper to build if we start using it.
- This training/seminar will help me to learn techniques to modernize our software. I believe that we are behind the technology curve and soon we'll find it hard to attract good candidates to work on our team with our creaky software stack.
- Our competitors are using this technology and we aren't. They seem to be successful in shipping reliable software quickly. Let me help our company catch up with them and possibly even overtake them by learning technology X or Y at this seminar.
- At this seminar, I will learn about technologies X, Y, and Z, all of which are open-source. I will then help you to implement it here and get rid of [proprietary technology] which will save us $xxx per year in licensing fees.
- So we've been having a hard time finding finding qualified candidates? Let me go to this seminar, learn some technologies which we've been meaning to implement anyway and network with some promising candidates. This seminar always attracts great tech folks.
- Give examples on what went wrong in your projects that year and how this training would help you improve in that area. (Personally I think that one would need a careful touch.)
- Do the math. find out from your developers what they need to know, and how much is it slowing them down (e.g. I spend X time Googling Java sites about Y). Multiply developer complete rate times the time spent Googling (this is more than the salary... there's overhead, so estimate salary times 1.5 if all else fails). Calculate time saved.
- Training doesn't have to cost us an arm and a leg. Some vendors offer free developer days.
- Your course can go on your boss' accomplishments at the end of the year for his review: "Trained staff to improve results." This is a win/win, pointed out the woman who privately offered the suggestion. "If the team is good, this is why the team is good; if the team is bad, this is how your wise boss fixed it, proactively."
- In a tight economy, you can give training in lieu of a higher raise.
If all else fails, you can try the argument that Glenn Phillips, president of computer consulting firm Forté uses. "Some of our new clients say, 'What if I train them and the leave?'" Phillips says. "I respond, 'What if you don’t train them and they stay?' It always gets a pause, reflection and an apparent 'Aha' moment."
Have any of these worked for you—or fallen flat? Share the effective arguments, and help other developers get to a conference by posting your suggestions in the comments. I'm sure that one of them will buy you a beer in gratitude.