hobofromabroad

It sounds more like the team is rather inexperienced for that kind of work environment.

Communication, the overarching priorities and alignment are super important. I work for a German insurance company and we rolled out crazy amounts of stuff over the last two years and started a re-org that is actually going well.

Also, emotional investment can be quite problematic. All the teams need to work on the overall goal. Having people fixated on their golden toy is a good way to crash into a hard wall.

That's because there are other legal reasons to keep that kind of data.

But that isn't a reason to keep all kinds of data related to a user account.

Monetary transactions, claim data for insurances, but not support requests for instance.

That might be true for startups. But larger business organizations are far better of creating a specific heterogeneous team with data scientist, data engineer and ops in one. At least starting out. That way, there is inherent knowledge transfer. You are not artificially limiting your hiring pool and can actually get some T shaped folks being experts in a certain domain.

Later on you can then build more specific teams or even more cross functional ones.

Of course, if you only want feel the waters and check if DS use cases are viable at all, consider getting a (few) freelancers and but a somewhat technically inclined person in charge. If that's a success use it to get funding for a proper team.

I agree and disagree. We deploy our models via Cloud Foundry which has support for Anaconda.

Model building is done in AWS with access to Anaconda.

Usually we have an environment.yml for the REST API and one for model building.

This makes modeling -> deployment cycle fairly easy, if not perfect.

You can also use pip and env, but you have to make sure that all important dependencies are specified sufficiently specific. But that's also the case for Anaconda. (For instance, we had a problem in the API with a x.x.y release of greenlet or gevent since we only specified x.x)

For R, well use packrat. R IMHO has the problem of many different algorithms with different APIs. Yes, there are tools like caret, but 'you' will run into problems with the underlying implementations eventually. sklearn makes things easier here, at least most of the time.

I would also prefer R for EDA. But I don't like splitting eda and modeling that way, since there can be subtle differences in how data is read which can lead to hard to find problems later on. (Yes, you could use something like feather)

I also thing that tooling for python is much nicer, pytest, black, VSCode python integration just seem more mature.

I'm only getting a blank website?

For instance: a lot of us want one cable to connect display, keyboard, mouse, power to the laptop (aka some device)?

> > (1) all employees are trusted and unmeasured, but you have to tap people on the shoulder every once in a while to confirm that they're on track. Naturally, this is easier if everyone is on-site.

> I don't get it - shouldn't one-on-ones and regular progress check-ins (be those standups, metrics (This is your #2), whatever) give you that information? None of those are easier when on-site. In fact, given today's move towards open offices, any form of 1:1 collaboration is easier remotely where you don't have to fight for precious meeting room space.

This is not quite the case everywhere. We have agile 5-8 person offices and people are still supposed to walk out for longer phone calls occupying one of the smaller meeting rooms.

But I actually like that different teams can mix a lot easier.

But then the question becomes what generation +1 wants?

This is probably going to be nearly as big a problem as the engineering one.

The problem with these models is that you have to be careful that your are not modeling something that incorporates a trend.

And if you have any kind of seasonality you a dataset with a large enough timeframe. (At least more than a year.)

Nonetheless, LightGBM and xgboost are also commonly used in the insurance sector.

They are still somewhat problematic for conversion rates in a highly dynamic market though.

Very nice photos!

How did you handle food, money etc?

But honestly, I would probably be too chicken shit to do a tour like that.

There are also companies like The Flow that offer that data directly from mobile devices via an app.

SAS ist still quite a big thing in the insurance sector, at least in Europe.

But the more Data Science focused roles (vs. Pure actuarial roles) are going more and more with R or Python.