How can I deal with non-operations research managers?

Question

I am doing an internship in a company. The aim is to solve scheduling problems in the industry (a variant of the resource-constrained project scheduling problem). By the end of the internship, they will offer me a job opportunity. I will need to treat other constraints and different objective functions. I am a little bit hesitant to accept.

Unfortunately, the company has no experience in operations research, maths, or even algorithms. Basically, it's a web development company. The challenge is that managers are totally unaware of the complexity of the work I am doing. They think that adding a constraint is as easy as adding a button in an interface. For example, adding the multi-skill or multi-site details is not so straightforward. Sometimes, we need to restart from scratch.

I am concerned that instead of understanding that the problems are of a complex nature (especially with large scale data), I will be judged unfairly. They are tending to measure the efficiency of delivering work by comparing me to web developers.

How can I deal with similar situations? How can I convince people with no operations research/math/algorithm background that things are not as simple as they thought?

_{A user stated that this site is not for career advice. Unfortunately, users of other career advice sites will not understand the challenges I am facing. I hope the post will be maintained.}

PS: I am not saying that web development is a "stupid" thing or anything like that. I am saying that it seems like adding things in web development is way simpler.

Answer 1

First, I understand the question, and I personally think it is appropriate for this forum.

Second, if they do offer you a job, there should be some discussion of compensation, duties and so on. That would be the time to explain to them that seemingly small, benign changes to an optimization model can have drastic effects on run time, possibly warranting a fundamentally different approach. If possible, you might come armed with one or two published examples, or testimonials from optimization pros, preferably consultants or software designers ("real people") as opposed to academics. If the conversation leaves you thinking that they still have unrealistic expectations about changes, I would suggest sitting on their offer for as long as possible while looking for a better job. Ultimately, though, a job is better than no job, and if you accept the job and they do heap unreasonable expectations on you, you can always opt to leave voluntarily and take a different job.

Answer 2

I'll answer this from an employer's perspective.

Technical ability is a necessary but not sufficient condition - the skill I value the most in my employees is their ability to manage expectations. I am also very mindful of the fact that most people can't do this well at all.

People higher up the chain have better oversight of what needs to be done, why, and by when. It is perfectly ok for something to take a long time, it is definitely not ok for management to be blindsided by this. If a task is going to take longer than expected, management needs to know asap, because they have oversight of the entire project. Some things they might choose to do if they do know:

• Hire more people
• Reassign more people to work on the project
• Hire an experienced contractor for a short time to help out
• Cut features to meet the deadline
• Postpone the project until more critical things are completed
• Cancel the project altogether

These are all management-level decisions that can only be made if management is aware of the reality of a situation.

The macro-level problem here is that employees typically think that their responsibility is to come up with a "how", but this is not the case. Management & employees are supposed to work together to come up with a "how" that fits the "what" and the "when".

A sign of a good manager is that they understand how hard this is, and they are upfront with you about how this is going to work, what exactly is expected of you, and how they are going to evaluate your progress. You will agree on time estimates, in the beginning you will get it wrong, you will have honest conversations about why, and a good manager will help you understand how to manage your time and expectations better. A bad manager will tell you "make sure this never happens again or else", without telling you what to do about it.

For instance, when I need something done, I will sit down with the person who will be responsible for it, we will discuss to define what work will be done exactly (or what work needs to be done to figure out what to do in the first place), and at the end I will ask them how long they think it's going to take. I will also give them an idea of the greater picture by letting them know how their task fits into the greater sequence of tasks that other people are doing, and how other crucial things done by other people depend on the timely completion of their work.

As a rule of thumb, for junior people I will assume it will take at least 3-5 times their estimate (sometimes 10x), for senior people about 2x, and for team leads it's usually done about as quickly as they predict, because they add the multiplier themselves.

I should also point out that this is the part of the job most people struggle with the most, as being able to manage time and expectations well is not something universities prepare us for - it typically comes with experience. This is a very high-level skill, even experienced people can be shockingly bad at this. In industry terms, this makes the difference between a team lead and a senior person.

So, from a practical point of view, what does this tell us about your situation:

• Managing expectations is 100% your responsibility, especially if you are the only person at the company with a particular skillset. No-one has the knowledge to set proper timelines except for you.
• You are most definitely not expected to be able to do this well straight out of uni. You are however expected to be proactive in improving your ability to do this well. Just be mindful that this is a life-long process, it doesn't happen overnight, and that's ok.
• It 100% ok to tell your manager that you don't believe you can do what they ask in the time they want you to do it. A good employee does this routinely, and a great employee will suggest how to adjust the project's objectives to fit the management's timeline.
• You will only be judged unfairly in two cases: (i) if you don't manage expectations well, which is up to you, and (ii) if you have a bad manager, in which case you should probably find a different job.
• As a junior professional, always multiply the time you think you need by 5, until you start to feel confident about your ability to estimate time well.

Finally, to answer the OR-specific part of your question, unfortunately it's unlikely that you'll be able to communicate the complexity to a non-optimisation person. You should of course try to communicate that this is complicated stuff, but at the end of the day the people employing you should trust you, especially if you are the only person with the know-how, which by definition makes you the resident expert. If the expert says X needs two months, and they do deliver X in two months, everyone is happy. If management says "we don't have two months for X, we have 1 week", then it is the expert's job to stick to their guns and suggest alternatives.

If, despite your efforts, management is still being unreasonable, it's time to find a new job.

Answer 3

From what I could understand, here is my recommendation for you. Suppose I was on your place starting intern, then I would be setting up my few initial sessions with the manager or team lead to clear out the deliverables. For me, this includes: scoping out the problem, setting solution domain, listing out possible challenges in solving and finally the applicability of deployed solution all of this with the timeline that aligns between both of you.

This kind of planning can help you tackle any later unexpected challenges that you may not wish to encounter.

Answer 4

1. I want to point out that since the company is a web development one, there are probably some computer engineering or computer science graduates in the workforce (perhaps, even in the top-level management). A common area between computer engineering/science with operations research is algorithms and the theory of complexity. Hence, while many computer engineering/science have no background in OR, they understand many OR concepts and tools such as branch and bound, dynamic programming, and metaheuristics, to name a few. Since you are working on scheduling problems, you have a good chance that there is a body of knowledge on the theoretical performance of algorithms and the complexity of the problem under investigation. I suggest you discuss these common grounds over coffee breaks and technical meetings to familiarize people with what you do.

2. Please note that operations research has a very versatile set of tools. If you want fast solutions, you have both metaheuristics and constraint programming at your disposal. Both methodologies are very common for solving scheduling problems.

3. I believe web development is the gateway to many projects in other fields. Many companies think that they have a process or database problem and they want to solve it (automate the process or have access to data) with a web-based solution. However, often there are other problems, which might require other disciplines such as operations research, analytics, industrial engineering, business analysis, etc. So unless the company is just working on web design for sites, I would not be worried about the relevance or importance of your job there.

Answer 5

First of all, if they want to offer you a job it is because they see value in what you are doing, well done!

Since you are the only one with your background it is important that you see yourself as your own "project manager", which requires you to build additional skills besides the pure OR skills. Those skills will also be very valuable for you to create value using OR in the future. I will focus on the part in your question around handling the complexity of OR.

Communicate the risk

Operations Research work is more "riskier" than most web development, which also makes it different to manage. There are more uncertainties which makes it more difficult to make estimates and plan further out in time. You should identify and communicate what the current risks in your project are.

• Computational risk: You add something to the model that significantly influences the computation time in a way that would make the tool unusable and you need to find a way to speed it up.
• Problem risk: Are you solving the right problem, so the solutions are valuable for the users. For example, if you add a new constraint you need to understand if that always is the case that this constraint is valid, or there are situations where you want to violate it.
• Value risk: Will the solution create the value expected. Can the customer capture the value, and will the solution fit into their current decision processes.

Mitigate the risk

When you have identified the risks you also need to show a clear plan on how you are mitigating it and ongoingly communicate how you will spend your time. Having a "roadmap" that is aligned with your stakeholders will help you create buy-in and avoid having to answer again and again when they can expect some work to be done.

• De-risking: See how you can remove the risks by diving further into the problem. It could be building a proof of concept (POC) of a new addition to the model, conducting user interviews, or talking to experts.
• Research vs. development: Be explicit around when you are de-risking and exploring if something will work, vs. making code production-ready and doing more standard development work such as reading data or coding a front-end. When you have a task around adding a new constraint, you can split it a task around understanding the implications on the model e.g. building a proof-of-concept, and another task of making it production-ready, adding unit-tests, etc. It can be difficult to estimate the research work, but you should be able to create good estimates of the remaining work.
• Proactively communicate delays in a roadmap: If a task grows, you should communicate as early as possible. If you have highlighted the risks upfront this will also be easier. When there is a delay you will need to postpone other tasks, and you should ensure to align the priorities with your stakeholders so you have buy-in.

---

Finally, I would suggest trying to find some internal project managers who can support you in how to deal with your stakeholders and communicate around the work you are doing. You might also be able to create some interesting analyses along the way that will create value for your company or its customers. Having some of these "wins" along the way can help you create momentum and an understanding of the value you are bringing. Best of luck!

Answer 6

Being just out of college and the only one in an organization with knowledge in a field is scary. Your bosses will not understand what is hard and what is easy about your job. The other posts about managing expectations are excellent in this regard. You will not get guidance from somebody experienced in the area, which is important to learn what is really important on the job as opposed to what is taught in school. You have also said this is not a core competency for the company.

It is an opportunity to fail spectacularly or to grow spectacularly. You are essentially working in a startup within the company. If nothing blows up in your face in the next few years you will have a lot wider experience than others in your field at your age. If the area becomes more important to the company, you might have a large staff reporting to you. If something does blow up in your face you may be fired, but you will have attractive things on your resume. Be on the lookout for opportunities for training, both within your field and in management, as you will be doing that and it isn't taught in technical school.