Take the 2-minute tour ×

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?

share|improve this question
Question.Add(Coworkers) –  P.Brian.Mackey Jan 19 '11 at 16:44
As time passes, generational gap between managers and developers becomes the other way. –  mouviciel Jan 20 '11 at 10:09
add comment

10 Answers

up vote 15 down vote accepted

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.

share|improve this answer
"What can I learn from this person?" is the best part of this answer. Regardless of age, or any other attribute you should get the most of all work relationships. Hell, my boss helped me purchase a car as he had much more experience doing so. May not always be work related but this can always aid in developing a relationship with said co-worker. –  Chris Jan 19 '11 at 17:01
add comment

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.

share|improve this answer
There is another side to asking question though: "Don't take questions as personal insults." –  biziclop Jan 19 '11 at 16:59
I would consider that part of respecting someone. –  Cyrena Jan 19 '11 at 17:31
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.
  5. Talk in the terms of the other person's interest.

Twelve Ways to Win People to Your Way of Thinking

  1. Avoid arguments.
  3. If you're wrong, admit it quickly and emphatically.
  4. Begin in a friendly way.
  6. Let the other person do the talking.
  9. Sympathize with the other person.
  10. Appeal to noble motives.
  11. Dramatize your ideas.


  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.

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer


