How do you bridge the generational gap between managers and developers?

Question

Typically, managers tend to be older and have more experience than the developers working under them.

While young developers are often more knowledgeable about "newer" technologies/patterns (like .NET, Rails, SOLID, etc.), managers are more familiar with older technologies (COBOL, ASP). However, the manager often has proven experience in problem solving and providing value to the customer. Furthermore, many of the principles of good programming remain static.

This generational gap can produce tension between the manager and the developer. A developer may feel that the manager has no idea what they are talking about and is outdated, while the manager feels the developer is naive and just going along with the current tech fads.

How can this generational gap be bridged so that there is a healthy trust and respect between developers and managers even across age differences? How have you dealt with this issue?

Answer 1

Respect for others is a basic character trait that good programmers have. Your default position should be "what can I learn from this person?", however old they are, and not are they qualified to do my job, but are they qualified to do their job.

The technology may have changed but many of the problems surrounding it hasn't. Requirements are still flexible, estimates are still hard, and the real world still doesn't map to computers that well.

On a technical level data from external sources is still not to be trusted (in any sense), the bug still isn't in the compiler and that new technology still isn't going solve all your problems.

Speaking as a manager the toughest things are understanding what you don't know (or did know that's no longer right) and letting go. At most you're going to spend 5 or 10 hours a week hands on. That's never going to be enough to keep pace with the guy spending 40 hours plus a week coding, however big your head start.

You need to deal with that, move on and let the kids get on with what they're good at. Challenge them about what they're doing from time to time politely, just to make sure they're not bullshitting you (and hey, you might learn something) but you need to trust them.

As a young programmer, the thing to understand is that looking at it from the perspective of the specifics of the technology is wrong. The specifics simply aren't that important for two reasons.

First, over the next 20 years you're going to come into contact with new stuff and you're going to find that each extra thing is easier to learn than the last thing. And as that happens, you're going to see that what you did before, even though it's different, is still helping you. You can probably see it already, just in a couple of years, just from your first couple of languages or technologies.

And most of that's never going to change - those concepts, those foundations, that basic understanding. And that's what your manager - assuming he has been there and done that - has and why even though he has no idea what a singleton or a factory is, why he still has something useful to add.

Second, most of the problems aren't in the technology, they're outside it. You shouldn't be looking for your manager to solve technical problems for you (after all if he could why would he need you?). You should be looking at how he makes it easier for you to solve them.

It's easy to just look at the trouble he dumps on your desk, but sometimes you need to think about how much trouble has never made it into the same room as you because he squashed it at the door, and understand that it's not about how we solve the problems, it's about working out which problems we actually solve.

Answer 2

Be respectful of others.

If you don't understand what they are talking about then ask questions.

Learn as much as you reasonably can about the other person's technical background.

When conflict arises, find a moderator - whether it's a coworker or Stack Overflow.

Answer 3

It's all about team selection.

You need to pick up people who have genuine respect for the young and for the old, and who are genuinely interested in learning from both to make their work better.

I've been lucky I've worked with such people (middle-aged) who were eager to learn things from me. I paid them back in the same way. It worked like a charm.

While it is easier to change your ways while you're young, it is clearly more difficult when you've reached a respectful age (so I have heard). But the age is not an obstacle, the attitude however is.

You need both parties to show respect for each other and act accordingly. It might not be easy to achieve for somebody in the management position because there is no intrinsic motivation to get along with the people who are below you.

What about arranging for regular technical meetings to exchange knowledge? The young will be encouraged to talk about modern developments, the old will be asked to share their experience. Somehow it may work out and better relationships will be born.

Answer 4

In my opinion, the best way to help bridge this (and many other) gap is with communication.

If a manager opens the lines of communication from the beginning, then a younger developer can voice their concerns and suggestions, understand the manager's reasoning, and most importantly they can feel like part of the process.

Yes, it might take more time and effort than saying 'we are going to do it this way b/c I said so' but at the end of the day, both managers and devs can learn something from this process.

Answer 5

How to Win Friends and Influence People has some excellent suggestions:

Fundamental Techniques in Handling People

1. Don't criticize, condemn, or complain.
2. Give honest and sincere appreciation.
3. Arouse in the other person an eager want.

Six Ways to Make People Like You

1. Become genuinely interested in other people.
2. Smile.
3. Remember that a person's name is, to him or her, the sweetest and most important sound in any language.
4. Be a good listener. Encourage others to talk about themselves.
5. Talk in the terms of the other person's interest.
6. Make the other person feel important and do it sincerely.

Twelve Ways to Win People to Your Way of Thinking

1. Avoid arguments.
2. Show respect for the other person's opinions. Never tell someone that he or she is wrong.
3. If you're wrong, admit it quickly and emphatically.
4. Begin in a friendly way.
5. Start with questions to which the other person will answer yes.
6. Let the other person do the talking.
7. Let the other person feel the idea is his/hers.
8. Try honestly to see things from the other person's point of view.
9. Sympathize with the other person.
10. Appeal to noble motives.
11. Dramatize your ideas.
12. Throw down a challenge; don't talk negatively when a person is absent; talk only about the positive.

Be a Leader: How to Change People Without Giving Offense or Arousing Resentment

1. Begin with praise and honest appreciation.
2. Talk about your own mistakes first.
3. Call attention to other people's mistakes indirectly.
4. Ask questions instead of directly giving orders.
5. Let the other person save face.
6. Praise every improvement.
7. Give the other person a fine reputation to live up to.
8. Encourage them by making their faults seem easy to correct.
9. Make the other person happy about doing what you suggest.

Granted that the book was written in 1937, it is amazing how well it all holds up even today.

Answer 6

Many companies that I have worked with have system architects. One of the key roles of the architect is to evaluate "newer" technologies/patterns and make "fit" recommendations for the company. A list of approved technologies is then made available to all developers. From this list, developers are free to choose any technology/pattern that they deem neccessary for project success. In these companies, managers are usually kept out of the implementation details and focus more on other aspects of the project such as resource allocation.

Answer 7

Knowing what people's areas of expertise and trusting in each other's abilities help.

I will give advice to my manager about who to assign on a specific task and he'll give me advice on how to implement something or other but we both know that the final word is his in resource allocation and mine in development.

When there's an age and culture gap between developers, that could be trickier, but in every larger group there's someone who can link the group together and is accepted and liked by most members. If you're a manager, find these persons and value them highly. They can be your golden ticket to successful team cohesion.

Answer 8

Actually it is a manager's responsibility to build trust and respect - manager should earn a respect from the team and manager must trust his team.

Also good manager always learns about tools and technologies that his team is using.

Answer 9

I find that it's just like the parent-child syndrome. The kid thinks the parent can't possibly relate to them. The parent wants the kid to avoid the same mistakes they made. In reality the only way we truly understand something is through experience. Sometimes we're lucky and we figure out sooner than later that our parents have a point.

A good developer realizes that there's a lot to learn from someone who has been in the field longer than them. A good manager realizes that the best way to relate to their reports is to stay current. It's the core premise of my contribution to 97 Things Every Architect Should Know (replace Architect with development Manager). Even if you don't develop as part of your 9-5, you should always stay current with development trends as a manager. And if you have a manager who hasn't developed before, you're probably at the wrong company.

By the way for interesting proof of nothing new under the sun. Pick up Eric Evan's Book (Domain Driven Design) and Compare/Contrast with Peter Coad's Object Models: Strategies, Patterns, and Applications Coad's book was written in 96, Evans in 2003 (with barely any reference to Coad). If in 7 years, we can forget that the same thing has been said before, just think what can happen in 20?

Answer 10

If a younger developer feels their older manager is out of date with current technologies (or even the other way around) I suggest they invite their older team-member to join them at a developers conference to learn about the latest programming trends. That would be a great team-building event and a chance to bond socially, as well as a chance to catch up on current technologies.