Continental Reviews

Pros

Strong first impressions Great People To Work With Exciting and Innovative Products Flexi Time/Work-life Balance

Cons

No onsite parking so short walk required

Advice to Management

None

Pros

Interesting work Opportunities to travel Reasonable salary Flexible working

Cons

Benefits are below average compared to other companies

Advice to Management

If you want to hire and retain the best people, look at what other engineering companies nearby are doing with their employee benefits

Pros

Part of the big group

Cons

A long list and getting longer

Pros

Really friendly and experienced engineers Development opportunities Everyone is helpful and kind New Location

Cons

Pout Benefits Really bureaucratic mid-level management Nowhere near to any German Conti location (feels like a totaly different company) Pour holiday allowance and pension contribution

Advice to Management

Take care of your engineers - people are leaving Start actually doing what you say you will do Improve training programs (technology is constantly changing) Be more flexible with salary negotiation

Pros

Great benefits, innovative business and flexible working

Cons

Hierarchical structure, with little respect for experience or knowledge. Voices go up heard

Pros

Freedom to act on own initiative, employee tyre discount, company car allowance

Cons

Lack of support, no clear direction, trapped between customer and company.

Advice to Management

More support and direction needed.

Pros

Flexible work environment. Opportunity to move around.

Cons

Not a great place. Low pay .

Pros

Nothing that I can think of.

Cons

Tasks/projects on which people are working on can be changed suddenly and with no prior warning. Line management tells you what your time allocation between projects is (approximately - no explicit figure ever given - it's always 'around' - but that makes it difficult when different projects leads are imposing requests to adequately negotiate). This is especially true when priorities are not clearly laid out. More importantly, the dependencies of the project have not been thought through. You can start working on a task and ask about components/resources you realise you will need and be told that they are coming (documentation is one good example - no documentation available - or, well, maybe the stubs of documentation - e.g., headers of the documentation but no relevant information but you have to use the component - it turns out that the component itself is still evolving - which is why the documentation is still in its infancy). Tools are changed with no warning, no training, no explanation. The only time you realise that there is a new tool is when you've been put on a mailing list and get updates about it - you may not even know what the point of the tool is, what it's meant to be used for or which teams are using the tool - are you getting notifications because you have been assigned to a task/project or is it because someone has decided that at some point you may need to use the tool or work on that task?). There seems to be some power struggles between management. it is not uncommon for questions that you had thought resolved gets brought up a few weeks later by another manager (they will argue that it's in the context of a different project - but then something has failed if a generic component is not generic enough to be used in more than one project - or if the projects who have dependencies on a specific components have not coordinated to make sure that work does not have to be done 3, 4, 5, or more times). My recent favorite was a discussion where an engineer was told to go ahead making certain assumptions as there was a meeting the following day to sort out most of the questions. Is there really not enough work that the task cannot be put on hold for 24-48 hours while the uncertainties are resolved to avoid going up the wrong path or doubling work? Or is this a recognition that for all the talk nothing is going to be resolved? Or is this a preemptive strike to force other stakeholders to be committed to one vision of how a component is to be designed/implemented? In any case, the word I can say is 'chaos'....absolute and utter chaos. Standups are regularly moved around to suit the schedules of the scrum masters (or deputy scrum masters) rather than sticking with the concept of standups being fixed to help develop the communication pattern that is needed. And, post-fact e-mails to justify that agreement had been obtained from the team members even though at least some team members were not consulted.

Advice to Management

I don't know where to start. Closing the site down would probably be a good starting place.