For my job for the foreseeable future I will be managing someone else. They are about thirty years older than me, quite experienced technically, and will be doing technical tasks at my direction, and they specified in the interview that they don't like micromanagement.

They are technically skilled in a different technical area from me, and are coming on for a deadline in a couple of months, so speedily doing the task is important. I am more used to managing people who need direction in my technical area, and less used to managing technically skilled employees, or employees who are much older than me and so have generally wider experience.

My basic idea of how to manage them for the project is to give them some goal posts of what I want them to achieve and to meet once a week to check up, and generally give them freedom outside that time because they are much more experienced, but I am not sure this is the best practice idea, or if I should be doing something different. I don't really have a clear idea of if I should be doing more, or if there's a standard practice.

A good answer will give a clear idea of a reasonable way for me to manage them that avoids being offensive or causing any drama. They seem to be excellent technically and we vibed fine when meeting before, so past answers assuming a conflict or a lack of technical skill don't apply.

  • 4
    Why would they need any different management than other develpers, with the only wrinkle being that you have, possibly, a lot less questions to answer/check upon?
    – Aida Paul
    Commented Jun 30, 2023 at 18:20
  • 2
    Why not just review the project and tasks with him, inform him of his deliverables and responsibilities, ask him if he needs clarification, directions, or guidance, and then let him get to work. Schedule a progress meeting as often as you feel is needed. I don't see a conundrum here.
    – joeqwerty
    Commented Jun 30, 2023 at 18:40
  • I haven't managed other developers, so I wouldn't know.
    – Nepene Nep
    Commented Jun 30, 2023 at 19:46
  • @TymoteuszPaul Because if you treat an experienced senior developer like a clueless junior they will be majorly pissed of at you and react accordingly.
    – quarague
    Commented Jul 1, 2023 at 6:58
  • Lots of good ideas here but bottom line - let them know you are there to support them, make it clear they can reach out any time for support and guidance but otherwise they are free to forge their own way, ask them for a weekly update but don't dictate the format.
    – deep64blue
    Commented Jul 1, 2023 at 13:38

6 Answers 6


It is not really clear what your job is - are you a manager of people, or of projects - so this is very general advice.

"Give some goal posts and lots of freedom" sounds rather vague, because even a very experience person cannot really guess what the company wants to accomplish. So if this a project with a deadline, there should be things like roadmaps, milestones, definitions of done, agreed up processes etc.

Do a proper onboarding to the project - again this not age specific, but if they are not properly introduced to what you need to accomplish, and how your team (I assume there is a team) typically works, they will have to fill in the gaps based on prior experience, which in the best case is inefficient and in a worst case will set them up for failure. Do not assume that being experienced with technology means to be experienced with every possible project goal or team setup.

As the single age specific bit, don't be condescending, but don't be deferential, either. If you are paid to be their boss then behave like their boss, not like someone who is making vague suggestions. Do not judge them by their age, and do not allow them to judge you by yours. "Managing old people" is not really a thing (and more importantly it is not a legal thing, do not discriminate based in age), managing people is.

  • 1
    "If you are paid to be their boss then behave like their boss" - sometimes that may only bring contradictions to the fore, depending on what people think "being the boss" means in a particular context. I think I understand that you're trying to urge confidence, but that confidence may arise naturally once the OP is more clear on the question how should I properly relate to this technical employee?. To urge relating "like a boss" would give no greater guidance than saying a car should be driven "like a boss".
    – Steve
    Commented Jul 1, 2023 at 8:45
  • @Steve I could have phrased this better, but what I meant was not just confidence, it also means that being someones manager includes specific tasks - setting goals, marshaling resources etc. And since the buck stops with you, it also includes making decisions and being responsible for them, even if you feel uncomfortable ordering somebody around. I think I just failed to convey my thoughts properly in my second language (I did not intend "boss" to be an idiom but a job description), so thanks for pointing that out. Commented Jul 1, 2023 at 9:44
  • Well it's very unlikely that a healthy relationship with your own technical staff would amount to "ordering somebody around" - often only the technical specialist will know when, how, and in what order things must be done - so it would be quite proper if the OP felt uncomfortable in doing so. I think this is amongst the ways "like a boss" could lead to the wrong mentality.
    – Steve
    Commented Jul 1, 2023 at 11:32

I don't see the problem here. Treat them like any other employee.

Have them watch the pointless HR trainings. Help them get setup on their computer (Show them where the dev environment setup guide is, what teams communication method is used, that kind of thing). Tell them what their responsibilities are, show them their task board, and assign them an introductory task to familiarize them with the code base.

Only difference is that I would expect a lot less handholding/stupid questions... and a lot more good questions/ why the *** was it done that way?...


Managing someone does NOT require knowing their job.

You aren't being asked to develop this person, or to critique their work. Your job as a manager is to give them a system to work in that allows them to thrive.

  • Manage tasks and direction
  • take updates, provide updates up the chain
  • break down barriers to their success

None of this requires you to actually know what they are doing. Let's take an analogy. I once managed a machine shop. I took Manufacturing Processes as an ME, which means I know what a mill, lathe, etc. are, but hardly how to use them at any level of proficiency. The machinists knew their jobs and certainly didn't need me to tell them feed or spindle rates. I was there to mostly be between those who would make their life hard and them. Managing them consisted of sitting on a work table while they worked and listening to things that they needed. God help some yahoo engineer who thinks they need to give direction to a machinist. I manage software engineers the same way today. They know their world, my job is to help them in the bigger environment.


The answer to this question really depends a lot on how the engineer likes to work.

For me, personally, I like my Managers to be a technical sounding board - that is, I like to bounce ideas off them and see which ones stick or what issues they forsee.

Other people I've worked with like a more mission-lead management style. For example a Network engineer that I enjoyed working with hated it when I came to him with what I thought would be the network solution - his line was 'Don't architect it for me, tell me what you want to achieve and let me figure out the best way to do it' - so for working with him (albeit, not managing him) - if I wanted something - I'd tell him what I wanted to happen, then let him make it happen.

Other people like more regular catch-ups to make sure they are on-track - things like daily stand-ups or a Monday morning meeting to set the agenda for the week etc.

If you are worried about seniority and life experience - there's two bits of advice I would give:

1: Listen. Chances are if they are a good engineer, they might know a thing or two and so listening to what they have to say is a good idea. I mean this is broadly true of any management position that they should listen to their staff, but especially for technical management. People can tolerate having their ideas heard and told 'no' if there is a good technical reason why. People hate being dismissed out-of-hand.

2: But don't let your brains fall out. Think critically. An Engineer tells you that the testing procedure is bunk and that you should do it this way. Are they right or wrong? Well My Dad (An engineer) once did this to a younger engineer - the scenario was that there were two load forces that went in the same direction on a structure. The young engineer wanted to test each load. My Dad pointed out that since they could occur at the same time and were in the same direction, a simpler test would be to test the structure for the maximum peak load. In this instance, it was the right call. But in another instance (say the loads occurred at different parts of the structure) it might not be. So be prepared to challenge the Engineer on the technical aspects.

So to recap - find out how your engineer likes to work, listen to what they say, but remember to think critically about what they say.


If you're managing someone outside your own area of technical expertise, then that's an interface that usually exists at the most senior levels of management in a particular organisation.

There are two capacities in which technical specialists are typically retained under non-specialists. One is to oversee (or personally perform) operational activity which requires technically-informed management, which the higher manager doesn't possess. The other is to convey information, advice, and judgment to other managers who don't have a deep technical understanding themselves but need that support.

The general impression from the question is that this person acts mainly in the first capacity, not the second.

Ideally any technical manager working under a non-technical manager will have good communication skills, but bear in mind it isn't always the case that technical specialists have been selected for their ability to communicate - especially if they were hired primarily to do certain work themselves, not primarily to advise others about it (where skills and experience in communication would have seemed central at hiring-time).

Avoid the temptation to become too involved in detailed technical decisions or justifications, because the definition of a technical occupation is usually that it can't be casually understood or explained.

You will often have to manage not by drawing in information to make decisions yourself, but supplying information to inform the decision-making of the technical manager.

Avoid breakdowns of trust by overruling - or appearing prepared to overrule - on questions where there doesn't seem to be a meeting of minds.

If apparent disagreements arise which seem to be down to differences in understanding, let the issue continue rather than forcing resolutions on the spot.

If there is a desire to learn something about the technical subject, remember that communication itself will require time and effort to be allocated.

Finally, if the technical subject is "software development" (I'm not clear from comments whether that is the case or not), then avoid the assumption that timeframes on tasks will be as predictable as they are for most other kinds of activity, or that progress will be inexorably forwards.


Treat them as any other but always take their experience with a grain of salt until they have proved themselves a bit. I know plenty of engineers with decades of experience who are mediocre or worse engineers.

So give them something easy to achieve, follow their progress, and see how they get on with it.

  • 1
    I've known people with 25 years experience, and I've known people with the same 1 year of experience 25 times over!
    – Theodore
    Commented Jun 30, 2023 at 20:59
  • @Theodore I know people with a decades experience of failure
    – Kilisi
    Commented Jun 30, 2023 at 21:19

You must log in to answer this question.

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