Dealing with cultural change in an old department

Question

I am a young software developer and part of an administrative team. There is one other software developer, the rest of the team does administration of our vast server-environment. The average age in my team is ~55 years, I am the youngest member. The other young person in the team is 39, the rest is older than 50.

I noticed that the whole team isn't very recent in various aspects. They usually do not perform any kind of project management, they get some input from the teamleaders and do their stuff. They use a really old and crufty Lotus-Notes Database for about everything from changes to education. That things is insane, everyone complains about it and no one from that team is able to teach me how to use it. The software developers do not use version control, they do not perform automated testing and there is no documentation.

My manager told me I should help him driving change in this team, as he has recognized, this is a problem. The department wants to attract more young people, or we will have a problem when all the old people are going to retire.

Here it is getting really frustrating for me: Everytime I present my coworkers something new they could benefit from (e.g. git-Versioning for the developers, kanban-boards for better organisation) they seem to search for arguments against it. The most heard argument is "It worked until now, why would we change this? Yes it is inefficient, but we worked that way for 30 years." Its really frustrating me - I am not making any progress and the way they work is killing my creativity.

I think this is less about tools and processes and more about resistance to change. Many of the people here seem to work towards there retirement and do not see a necessity to change in their remaining years at work.

Other people already advised me to change the department, but I am not one to give up lightly. Does someone have ideas how to deal with issues like that?

Answer 1

A company can take one of several approaches to motivating employees:

• Seniority based rewards

• Achievement based rewards

My guess that your current workplace used the first approach. When you do this in development you often end up retaining employees who don't have the skills or the motivation to pursue higher paying positions in different companies. These sort of people are not the types to take a plunge, and learn new techs. Not without a kick in the butt.

In all honesty, it may be far too late to reform them. I would suggest that you and your boss sit down, assess the situation from a technological and workforce viewpoint, and realistically asses your situation and goals.

First and foremost, just how poorly maintained, documented, and written is your current software? If you were to bring in a brand new team of young devs would they be able to figure it out in a reasonable time-frame? My guess is that they probably wouldn't. This leaves you in a very vulnerable position if someone were to suddenly pass away, or retire due to medical reasons, and you need to point that out. (it will lend an air of urgency to your suggestions, and maybe foster you more managerial support).

Second, just how much longer do you expect some of these people to stick around? More importantly, can you afford to keep paying them to do their job in a mediocre fashion until whenever they wish to part ways with your company? Probably not, because every day of doing things the old fashioned way is digging the company into a deeper hole.

It's good to be aware of your options, and limitations before you start making sweeping changes. Essentially, the conclusions should be that you need to change sooner rather than later, that you need to bring in new talent, attempt to train the existing team, and possibly be prepared to fight them on the changes (or even let them go) if they oppose you (the management team). Needless to say, your boss's full support is needed here.

That being said, here's what I would propose:

1. Incentives to learn new technologies

These guys are probably too old and set in their ways to change willingly. At this point you can either order them to start using a new system - which would probably lead to a lot of resentment, or offer an incentive for them to "upgrade" their knowledge.

Set up mandatory workshops to train them in using a new technology (such as GitHub). Have them sit down with you for a day of training, but sweeten the pot by offering them a free lunch, etc. That way they won't feel like they're "wasting" their personal time learning "newfangled" and needlessly complicated technologies.

You might introduce a bonus system for those who master a new technology. The rewards should probably not be monetary, but still fairly valuable. Are they into bowling or golf? How about golf clubs, or bags? Gift certificates to a local lunch hot-spot, or maybe an extra vacation day.

Hiring a couple of new, young, devs and getting them involved in the process might also help, because they would have someone around to answer questions (if their pride doesn't stop them from doing so).

The important thing for your boss to realize is that the changes will take months to pay off. In the beginning productivity might actually drop, while people are getting comfortable with the new processes.

2. Prepare to replace them

Unfortunately some people just don't want to change. They might scoff at your training sessions, and scorn your efforts to bring them into the 21st century. At that point you stop offering the carrot, and reach for the stick.

You may want to hire a few young devs, set up a new programming team in parallel, and get them to start converting your software to a new standard (or implementing new projects strictly in new languages, etc.). This is a very aggressive move, however, and would send a rather threatening message to these older guys.

However, based on how resistant they are to change, and how vulnerable your code base is to their specialized knowledge, you may wish to do it anyway.

The downside here is that as your workforce grows, and so will the company's costs. The atmosphere in the office might also become rather strained depending on how you handle it all. However you can't back down from your course of action. Discuss possible disciplinary actions against devs who outright refuse to follow the new processes. Do they get verbally cautioned? Written up on the second offence? Are you prepared to fire one of them? Discuss these worst case scenarios and reach an understanding. The worst thing you could do is threaten someone that it's your way or the highway, and then fail to follow through with your threats. You will lose all authority if you do this.

Best Approach?

The best approach is likely a combination of these two suggestions.

Encourage these guys to pick up new skill in a positive a manner as possible, but also hire new devs and implement all new projects using modern approaches.

That way you're actively bringing the company's architecture into the present, but you're giving these people a chance to upgrade their skills, rather than simply firing them.

The company's costs will rise dramatically for a period of time, however in the long run they will succeed in renovating their processes and upgrade their technologies.

Answer 2

You're just floating ideas and concepts. And merely floating ideas and concepts before a skeptical audience won't cut it.

You don't have a plan for action.

Tell me how you intend to implement your ideas. At this point, I have no idea if you want to implement everything all at once - that would be inadvisable under almost all circumstances especially if you, the driver behind the change, are inexperienced. Or if are implementing change one change at a time and one step at at time. Which raises the question, what are you implementing first, how are you planning to implement and do you expect to get as a result of the change you implemented? The question as to what resources you need and what resources are available to you does not arise because you don't have any plan at all.

So far as I see, you are not committed to change and you are not even involved in it. All you are doing is flapping your gums. Powerpoint presentations don't count as action.

The only way you're going to have change is to implement enough change to show everyone that change works. They need not only to buy into your ideas, they need to buy you as a change agent. And they won't buy you as a change agent until they see some effectiveness coming from you. You need to convince them that change is good news. You can't do that unless you drive enough change and the change is successful enough to be good news. You have to mentally condition them into thinking that change, with you as the driver, is good news(*)

Your workplace is way behind the times in more ways than one. Pick one way, preferably a way that's easy to improve on. Then improve it enough to do a show and tell.

(*) Lest I come across as all negative to your approach, I'll say that you are doing a good job going over the new concepts to your programmers. The audience is appropriately skeptical - after all, they don't see a path from here to there and you haven't provided a path - but at least, they understand what you want the firm to end up with in terms of change.

Answer 3

There are a number of standard, classical management things that your boss should be doing. If he isn't doing them, there's not much you can do. Your first course of action is to find out what your manager is able to do, and support those steps.

Directives

He has to say "This is the way things are going to be from now on. I expect everyone to comply with this." And he has to mean it. If he's afraid of the team, and can't make his directives stick, you have bigger problems than your coworkers' clock-punching attitude.

Incentives and Consequences

The first sub-team to move their stuff out of Lotus Notes gets a free lunch every week for 3 months, etc.

Anyone who consistently fails to follow source code control processes gets their rights to the code removed, etc.

Budget and Support

He has to provide the tools and the time for people to switch their way of doing things. If everyone feels like they are running on a treadmill, they don't have the luxury of taking a week to learn a new tool, and then to spend 6 months getting proficient in it.

Answer 4

I feel that the other answers are mostly about what your manager can do to get the other people to follow your ideas, so I'm going to focus on what you can do.

I suggest to read Getting Things Done When You’re Only a Grunt at the Joel on Software Blog, as my answer is heavily inspired by it.

Just do it and show your coworkers the advantages

Since your boss is on board with you, ask him for space on a server to set up a git repository, a bug database and a nightly build task. (I feel those are the most important, ymmv). You and him start using these right away. Tell the others you'd like them to join, but don't let it stop you if they're reluctant at first (of course your boss can use stronger words).

If your coworkers manage their sourcecode by passing around zip files, just start a "coworkers" branch in that repository, where you regularly unpack their current zip file, commit it, and merge it into your master branch - on second thought, write a script to do all that.

Use every opportunity that presents itself to show your coworkers how awesome git is, e.g. if you find a bug that somebody introduced recently, say "I saw in the git repo that someone worked on xyz last week, can you help me understand that change?" and then look at the change in your git repo with the coworker who did it and have them answer your question about their changes with the changes right in front of them. Keep in mind some people might not be used to color-on-black terminal diffs so consider using meld or gitk to show them the changes they made. And of course if somebody looses their changes, be helpful and show them how to check out the most recent state from the git repository.

Set up the build system. Get the boss to declare that your master branch is what will get build and shipped. Don't have unit tests yet? Start by passing or failing the builds on whether the build script ran without throwing an error. Add tests as you fix bugs or add new stuff to the system. Don't forget to point it out to your coworkers if a test failed and caused you to find an error before shipping it.

Set up accounts for all your coworkers in the bugtracking system, so you can assign bugs to them and have the system send them email reminders for their bugs. When someone comes to you with a bug, tell them "I'd love to fix that but I'm in the middle of something else, so let's enter it in the bug database so I won't forget." and enter it together. The second time they come with a bug for you to fix, say "Can you enter that in the bug database and assign it to me, please? I'll get to it as soon as possible." Have your boss on board with refusing to fix bugs that are not in the bug database. Be reasonable, you can do that to developers, QA and maybe other departments in your company, but not necessarily to customers.