I am in an organization where too many non-technical professionals are there. These people are carrying good functional knowledge and expert in business and operations. But when it comes to Automation or learning technical skills they take back seat.

I have given a challenge to motivate people to learn coding and explain them advantages of techno-functional role.

Teaching them coding is not a challenge. The biggest challenge is making them realize that these new skills will help in their career to grow. When I spoke to some of them they say "whatever you are saying is good, but who has time for these learning sessions?"

How can I help motivate people to take time from their busy schedule and attend our coding sessions?

  • 13
    Why do you need non-programmers to code? People who can't and aren't interested produce horrible, unmaintainable and generally unproductive code. – Magisch Aug 23 '16 at 9:11
  • 7
    Sounds like your organization hired the wrong people. – Steven Pessall Aug 23 '16 at 9:37
  • 3
    Getting buy-in typically requires some decision making capability or standing in the organization and based on the naivety in your post I'm guessing that you have neither and are fairly junior. If that's the case it isn't your problem and you should escalate instead. – Lilienthal Aug 23 '16 at 10:40
  • 3
    Tell them you will learn to play the trombone if they learn to code. There is good scientific evidence to show that learning a musical instrument can stimulate parts of the brain that assist in programming, so will help develop your career. Sounds irresistable, right? – Laconic Droid Aug 23 '16 at 11:18
  • 5
    "I am in an organization where too many non-technical professionals are there. " - too many? If you have too many, get rid of some. – WorkerDrone Aug 23 '16 at 12:04

The goal of everyone learning to code is a noble one, but it's just not a good one for the vast majority of companies.

Various companies have tried releasing tools which allow the "normal office person" to create their own solutions - which is why we have stuff like Visual Basic, macros in Office, etc etc. And those solutions are the bane of any software developer's life.

They are unmaintainable, missing the basics of modern coding principles, and lead to problems further down the line - pretty much every company has that one spreadsheet that performs some core, mystical function that no one wants to touch...

Software development is more than coding - to test properly and consistently, the developer should be using unit testing, which means the developer should be splitting their code up using inversion of control, which means the developer needs to know isolation and other principles. So it's down the rabbit hole you go.

And then comes the supporting system that a good software developer needs to have - source control, analysis tools, coding standards. Further down the rabbit hole.

No, you don't want everyone coding.

But the people you are talking about can still be helpful, they can still take part and you can still access that knowledge.

Get them to learn a specification language - get them to define their needs and wants in something that looks like code, but which can be directly translated to code, and something which can be used to test the produced code.

I use something called SpecFlow for this, and it can be used successfully by most non-developers out there, because its syntax is this:

Scenario: Add two numbers
    Given I have entered 50 into the calculator
    And I have also entered 70 into the calculator
    When I press add
    Then the result should be 120 on the screen

Getting end users in a business using something like SpecFlow means you can directly take the specification for a new feature or application and build software from it. It means you can then directly see if the end product matches the specification, because you also derive your tests from the specification.

Get everyone writing specifications - that's what they want to do anyway, they just normally do it in a meeting or via email or a Word document. If you get them using a formal specification language, they become much closer to the action, they get to define what they want in more exact terms, and they get much better feed back from the developers following the specification.

| improve this answer | |

Programming isn't easy. That's why it pays so well. Many people are incompetent even after obtaining a computer science degree. And it's not crappy complex programming languages that make it hard. There's an inherent complexity in business process automation that is independent of the tools available. And it's not that programming is only taught in some school in Xanadu. There are thousands of tutorials and online books that can teach basic programming to anyone interested. It's completely unrealistic for your company to expect employees who have never shown any interest in programming to somehow be capable of automating work processes after a few hours training.

It's a common story: I need to hire programmers but I can't get anyone for the way below market rate I want to pay.

Of course, according to Forbes, I could be wrong.

| improve this answer | |
  • 2
    +1 I have made a career out of cleaning up messes made by "bargain basement" programmers and super-users – Old_Lamplighter Aug 23 '16 at 14:22

A common problem for "why won't my employees learn X when it's so beneficial!" is that:

  • Often X takes a lot of time
  • Almost always, schedules/workloads are not adjusted in light of the above

In fact it sounds like this is exactly the case for your colleagues:

"whatever you are saying is good, but who has time for these learning sessions"

You need to get support of leadership and management in order to reduce workloads enough that these employees no longer can use this excuse.

Otherwise you are basically, in effect, asking:

  • "Hey, I know this is a really time consuming task that will take months and you might not even be interested, but trust me it's good for you - why don't you stay late and put in extra hours and it'll pay off and you'll maybe at some point in the future have a much lower workload!"

I don't know who tasked you with this but talk with them. Give them the feedback you have received and ask them how to proceed forward.

Additionally, if you really want to succeed at getting people to code, get this on people's goals and expectations so that their managers are encouraging them to learn it.

| improve this answer | |

Show them

If you really want to only teach them some basic knowledge to help automate tasks. Then take a task that is normally tedious or lengthy and show them how you can complete that more easily with code. Write a short program whilst talking to them as they need to relate the time it took you to solve the task.

If you can't find something that is relevant to them and simple enough to do then the premise is flawed and you are trying to teach people too much who aren't interested in the area with not enough immediate benefit.

However I'm a little bit skeptical how much that is useful can be taught to someone uninterested in a short space of time, there are a lot of concepts that non-programmers do not have that will severely limit their understanding of what they are doing.

| improve this answer | |
  • +1 "I'm a little bit skeptical how much that is useful can be taught to someone uninterested" Me too! – WorkerDrone Aug 23 '16 at 11:59

There are people who are programmers, there are people who can't program, and there are people who know just enough to be dangerous. You don't want to create people who know just enough to be dangerous.

And technical teams are used to speaking to non-programmers. That's part of their job. It's like going to a French restaurant in an English-speaking country and trying to order in French. With limited French, the French restaurant owner will understand you better if you talk English. If you try to learn the programmers' language, you will only get things wrong and confuse everyone, unless you learn an awful lot.

| improve this answer | |
  • 1
    +1 for "just enough to be dangerous" I cannot tell you how true that is. I've spent 3 months trying to unravel a huge mess designed by someone who knew just enough to be dangerous. – Old_Lamplighter Aug 23 '16 at 13:56
  • 1
    @RichardU and sometimes those are people with computer science degrees and ten years of work experience. – HLGEM Aug 23 '16 at 21:19
  • @HGLEM You're not kidding. I'm a maintenance coder more than a developer, and I've cleaned up all kind of messes. The worst is a "clever" programmer who is so clever he does all of his calculations in one massive formula. No documentation, of course. – Old_Lamplighter Aug 24 '16 at 9:14

So, your problem is what we call a lack of "buy in".

People are resistant to change, some typical complaints are:

  • "We've been doing it this way all along, NOW they want us to do it this way, it makes no sense!"
  • "I'm too busy, I've got no time for this!"
  • "I really don't see how this applies to me"

The way to overcome this is to quantify and qualify the advantages over the disadvantages. If you do not, you will experience the same resistance you are experiencing now.

You can offer someone a Lamborghini, but if they're happy in their rusted out old Yugo, they won't drive the new car. It's the same in business.

If you argue that the Lamborghini can get them from point A to point B, they'll argue back that so too, can the Yugo. You need to sell them on what is important to THEM, not what is important to you.

Use analogies, put it in terms that they can understand and dramatize your ideas. You can have the best idea in the world, but if you don't sell it in any way other than saying "This is the best idea in the world, why can't you see it?", you're not going to get many people to adopt it.

Coding is hard, coding correctly is harder. You're asking for people to invest their time without a visible payoff. while they're learning, they're going to be frustrated and initially it's going to take them more time to do their jobs than it is taking them now. Again, use analogies "You have to address that before anything else. You have to stop driving to put gas in your car, you need to change the oil so it continues to run, you need to maintain your skills in order to make you efficient at your job. If you change your oil, you'll have less maintenance, if you automate your job, you'll have less errors.

Sell it, and then DEMONSTRATE it. Design some automation for a tedious and/or difficult task. Demonstrate it to the team. Ask them if they like it. Ask them if it saves time. Get feedback and buy-in or they won't agree to anything.

| improve this answer | |

I am in an organization where too many non-technical professionals are there. These people are carrying good functional knowledge and expert in business and operations. But when it comes to Automation or learning technical skills they take back seat.

If this is your attitude, its no wonder they don't want to attend your class. You give the impression that only coding is of value. Why would an accountant want to learn automation skills? Why would a sales person? These things are totally irrelevant to their day-to-day jobs. Why on earth do you think there are too many people in your company who do not code. Every company above a 1 person start-up needs people in fields other than development. They are experts in their fields and have no interest in yours just as you don't really want to learn how to be an accountant. What benefit do they get to learning this? In fact, they mat be right, there is no benefit to them in most cases.

Software development is difficult, it takes a particular mind set to be successful and this is not the mind set it takes to be successful in Sales or Human Resources, etc. Not only do these people not want to learn coding, many of them will not be able to do it successfully.

If you think teaching them coding is not a challenge, then likely you have never taught coding to people who were not suited to do it. I can remember trying to teach a woman to query a database (Which had just become part of her job) and she just couldn't grasp the concept of things like WHERE state = 'CA'. It wasn't that she wasn't trying; she was paying me out of her own pocket because she needed to learn this to keep her job. But she just couldn't understand the concepts. Not the syntax, the concepts behind the syntax.

In addition, likely most of these people already are spending 40 hours or more a week doing their actual job. Just when are they supposed to do this training? Which of their deadlines are you going to move so that they have time available? If I am a junior accountant and enjoy my professional field, isn't it a better use of any free time studying to be a CPA than taking programming classes?

If you think they are going to do something like this in a Lunch and Learn, well that is just unrealistic. (Well frankly only someone naive falls for the lunch and learn stuff anyway, if is important to the company, it is work and is done on work time.) Many of these people already work through lunch or have a need to leave for lunch or want the break they are entitled to by law in most places. A lot of them can't schedule a specific lunch time as it depends on their duties especially if their job function requires coverage at all times.

If you have been tasked to do this, then you need first to talk to the person who tasked this and figure out what business problem it is trying to solve.

If there is a need for trained people to be business analysts and be a bridge between the business experts and the technical folks, then you offer them promotions to the job (and nice salary increases) if they want to convert. Then you let people who are interested apply for those jobs and remove their usual duties full-time while they attend your classes on what they need with the promotion predicated on passing the class. Now your class contains the people interested in learning something, they have the incentive of a promotion and pay raise, and they have the time available.

If you want people to do their own automation instead of paying for developers, well that is just a bad idea. For one it will take longer, the result will be less maintainable and it will cost real developers their jobs as well as some of the people who are currently doing the job. MAybe you don't care if someone gets fired because you automated a task, I assure you though that they are thinking about it and worried it might be them or a co-worker they have worked with for years.

You need to push back against this if this is the case. It is not only bad for your company, it is bad for our profession and for your future salary levels.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged .