Denied Tech Training and Your Bottom Line

It's taken me a while to figure it out, but I think I know why companies ask for passionate programmers. They want you to care because, they know the process of repetition is enough to make you dread your work.

A job posting came up in my feed earlier today. What stuck out was the following, 

"Must be on site! Meetings every day."

I applaud them for their honesty. Being up front is important. It is regrettable that being stuck in meetings is what will make your programmers dread coming to the office. In school we learned to love coding. We didn't learn to build cool things to be in meetings all the time. This highlights bigger issues of trust, communication, and what businesses really value....even tech businesses.

Lets start with the value issue, through the lens of available training. Companies will offer:

• word processing training
• email training
• creativity training
• spreadsheet training
• safety training
• leadership training

Do you notice whats missing? Where is the tech training? It's not there, though the excuses for it's absence certainly rear their heads. What kind?

• developers should train on their own time
• no interest in technology outside of a certain stack
• the accounting office will get back to you later(translation.... nope)
• explain to us why you need it and we'll get back to you(also translation... nope)
• budget still isn't decided yet

Developers, here's the truth your manager doesn't want to tell you. The sales and management team likely doesn't understand what you do. They don't see why the tech stack should change, and are a little afraid that if they can't see you, that you'll slack off.

What your sales team and execs do understand is the bottom line. If you make something they can sell, they want you to keep doing that. Changing what they're selling is a risk. It is less risky to increase the volume of sales on the thing that exists, than to change the process of building, tech stack, or even improve the process. They may have to hire extra developers, and that is an expense that digs into the bottom line.

If you're an accountant or a salesperson, this situation is just a little bit sexy. The developer has made them a cash cow, and they intend to milk that cow. If you're a developer, this is very dangerous. Languages, styles and techniques change fast. When your volume increases and your options tank, there is a solid chance to get stuck.

The accountant/CFO/Salesperson says, "Whoop dee doo! We're making money! We'll pay you, deal with the boredom. It's your problem". Well, in a way they are right.... in the short term. In the medium to long term, the countdown to stagnation has begun. Your top devs are going to stagnate, burn out because of ever expanding volume, and eventually leave.

Accountants/CFO/Salespeople, now I'm talking to you. The stagnation/burn out/jump ship problem, is attached to your bottom line. Replacing high performers is expensive. Knowledge loss removes maneuverability from your product. An angry or disgruntled dev might not leave you all the information on the product. The process of reverse engineering your product will add bugs. There is a solid chance your product will be hobbled.

So, what do we do? Some suggestions:

• Limit the BS meetings. Do you really need to pull your devs into a "praise each other" meeting when your deadline is looming? Not likely.
• When you must have meetings, move non-vital smaller discussions to smaller groups.
• Leave time in your schedule to allow for experimentation and training. It may seem non-vital at first, but it will turn into opportunities for revenue.
• Your sales and bottom line are important. Without your developers you don't have a full product. Lose them at your peril. Your employees don't owe you their health and sanity.

In summary, don't let your short term profits hobble your long term potential. Let your developers grow. Their growth becomes the wealth of the company. Overwork and too many meetings will kill the teams will to innovate. 

You may not understand everything your dev team does, but that doesn't make their impact matter less. Help your team grow, and they will bring the benefits of their learning to your bottom line.