From Intern to Product Owner: Mile GrnCarov

Berlin-based MB.ioneer Mile GrnCarov pulls back the curtain on his journey since 2019. 

Testing out new things can be adventurous, but Mile doesn’t shy away from that – whether it’s on a personal or professional level. In 2019 at the age of 22, he moved from Bulgaria to Berlin to start a new job and a new life at

The beginnings as an intern

“While I was in university, I knew that I wanted to work in tech, mainly in marketing but I was open to try anything via an internship, so I applied to,” he says. “I started as a growth and marketing intern, working with the Bertha team – a product that helps users to find the best gas station and enables them to pay for their gas from the app.”

Mile describes the move from Bulgaria to Germany, especially Berlin as quite a change. But after graduating in Business Administration and Political Science at an international university with a busy environment, starting at felt like a continuation of the journey he was already on. 

“I never felt out of place here. I remember one of the first meetings that I ever went into, I heard so many ideas flying around from everybody, people showing what they’ve done over the sprints and everyone immediately taking action on specific tasks. And I thought: This is the atmosphere that would be cool to spend a lot of time in.”

“I quickly realized that this role was not just traditional marketing, but also data insights, UI/UX, and product development and we got to do everything from scratch.” In the eight-month internship, Mile created big marketing campaigns and developed product strategies to improve the retention rate or general user flow with a lot of data experimentation. He implemented new tools and tested out different acquisition channels for the product – from Instagram, and YouTube to even outdoor car cinemas. 

“One thing I like about is that you get entrusted with so many different responsibilities from the beginning. That helped my transition from being a young professional or an intern to working full-time. The responsibilities were already given to me and I was allowed to run small and big projects by myself”. 

Becoming a Product Owner

After working as a Growth Specialist for the Bertha and Mercedes me Service app, becoming a product owner for Fuel & Pay in 2021 felt like a natural progression for him. Fuel & Pay is a product for the Mercedes Me app, allowing Mercedes drivers to pay for gas with the app and the Headunit system in the car. “Everything that I was doing before, was in a way leading me to this new role. In my growth role, I was already trying to organize new initiatives and trying to get different team members to move together to create something. Being a product owner seemed at the beginning something that’s a larger scale of what I was already doing.” 

Following the mentorship of other MB.ioneers, who were sending him all sorts of books, articles, and YouTube videos to prepare for his exams, Mile admits that: “Nothing really got me as prepared as actually starting to do the role itself.” He started shadowing other Product Owners at the company, joined meetings, and looked through their documentation to understand the dynamics and impact of the role in practice. 

When asking him what he specifically likes about being a Product Owner, he refers to the fact that: “It feels like every sprint you get to start a fresh page and try and do it better this time or try it at least differently. So it’s like a constant iteration of the work we do together.”

Exploring things & being inspired

One of his passions outside of work is producing visual content for himself. It ranges from work-related topics such as explaining new marketing tools to simple things in life he enjoys like making coffee – something that keeps him inspired to explore new things:

“It’s a culmination of experiences and content I consume every day and it drives me in my daily work life too. I don’t like to separate work and life too much. The two areas are more supportive than balancing each other out.”

Testing out new things can be adventurous but for many like Mile, it can lead to finding purposes, and arriving at new homes on a professional but also a personal level. In the end, it always feels like a mind-broadening experience. 

If you want to know more about our company or MB.ioneers, make sure to follow us on LinkedInYouTube, and Instagram!

Meet the MB.ioneer Season 1 Recap

Ask our MB.ioneers what this company is about and they will tell you one thing: People. 

In our Meet The MB.ioneer – Series, we introduce our people by asking them quick-fire questions about their roles, what they like, and how they would describe their jobs to their grandmas. Season 1 is finally wrapped up now and here you can have a glimpse of the MB.ioneers who drive our company. If you don’t want to miss out more content – just subscribe to our YouTube channel!

#MeetTheMBioneer Season 1 Recap


Check out what kind of testing Margarida prefers and what you will always find on her desktop!


João calls himself “one of many Joaos” and describes in this episode what a typical day at work for a Site Reliability Engineer looks like. 


 A lot of coding, a lot of meetings and a lot of fun – Ana Martins speaks about her life at and the most memorable experience so far. 


Karina is a legend who is in the company for about six years already. Find out what she is doing as a Program Lead and how many meetings she is doing on a daily basis. 


In this episode, you will hear what Marius does when he starts his day at 04:15 am and why he has a love for scrunchy cables. 


Filipa not only likes to talk about her cat, but is also a passionate UI/UX designer who would love to ride a giraffe. 


“There’s the thing called the internet.” This is how Product Lead Tasnim would start explaining the role to her grandmother. Click on the video to see what else she would say about her job. 


People’s person Carlos joined the tribe just recently and knows exactly how to help his team to deliver the best of their work. 


Meet Snehaa in the last episode: A Product Owner who makes sure to be the bridge between different teams and stakeholders. 

You will meet more MB.ioneers in the second season which is already in production. To stay tuned, just give us a like and subscribe on YouTube!

You Might Not Need Module Federation: Orchestrate your Microfrontends at Runtime with Import Maps


Managing microfrontends in a complex feature-rich app can become a tedious task and easily turn it into a Frankenstein’s monster when there’s no clear strategy involved.

Using third-party tools like Webpack Module Federation helps to streamline the building and loading of microfrontends, but leads to vendor lock-in, which can be a problem.

Import Maps can be seen as a web native alternative to Webpack Module Federation to manage microfrontends at runtime. In this article, we will:

• Explore the concept of Import Maps

• Build a demo app

• Summarize the pros & cons

Import Maps in a nutshell

The concept of Import Maps was born in 2018 and made its long way until it was declared a new web standard implemented by Chrome in 2021 and some other browsers.

Import Maps let you define a JSON where the keys are ES module names and the values are versioned/digested file paths, for example:

<script type="importmap">
    "imports": {
      "my-component": ""

Such mapping can be resolved directly in the browser, so you can build apps with ES modules without the need for transpiling or bundling. This frees you from needing Vite, Webpack, npm, or similar.

Import maps allow us to write:

import 'my-component';

instead of the following:

import '';

and let the browser resolve the actual path at runtime.

Advanced Import Maps features

You can reuse an import specifier (for example lodash below) to refer to different versions of the same library by using scopes. This allows you to change the meaning of an import within that given scope. As a result, any module in the path will be using lodash-es version 3.9.3 while all other modules will use version 4.17.21.

<script type="importmap">
    "imports": {
      "my-component": "",
      // allows import { my-component } from "component-library" syntax
      "component-library/": "",
      "lodash": "", ⬅
      "lazyload": "IntersectionObserver" in window ? "./lazyload.js" : "./lazyload-fallback.js",
    "scopes": {
      "": {
        "lodash": "" ⬅

You can also construct an import map dynamically based on conditions: the example above taken from this article shows how you can load different modules based on the support of IntersectionObserver API.

Demo app

In this article, we bring the idea of Import Maps further by placing an Import Map between the host app and microfrontends and applying the dependency inversion principle. This makes the host app not directly dependent on a concrete microfrontend version or its location, but rather on its abstraction via name or alias.

We are going to build an online store that has only one, but highly customizable assortment type: T-shirt.

Step 1: Outline the Architecture

There is an arbitrary number of microfrontends that are assigned to the development teams, each of them is free to choose the tech stack, build and CI/CD tools. The “only” constraint is to make sure each build pipeline produces 3 artefacts: ESM bundleManifest and other Static Assets.

The lightweight Nest.js Import Map Resolver server has two main roles: store and update the importmap, but also handle the submission of JS assets. Single-spa has a similar solution available.

The Publisher will read your Manifest, extract the bundle filename as well as externalized dependencies and publish them to the Import Map Resolver.

The Assets Server is used as a Web-enabled storage to host JS assets. To store images, videos, and other assets we can choose an arbitrary Storage, for example, an Amazon S3 bucket. CDN is used to serve third-party libs and frameworks as ES modules, a good one is

ESM bundle

Your production-ready application ESM bundle is generated by Webpack, Vite, Rollup or any other bundler of your choice. For simplicity of the setup, CSS Injected By JS plugin for Vite is used along with the scoped styles to build a single ES module with injected CSS.

If your build produces more than one bundle (for example, due to code splitting), you have two options:

  • concatenate them after the build, for example via concat
  • alter the Publisher to loop over the multiple entry chunks and add the prefix, e.g.: my-component:mainmy-component:polyfill, and so on.


This is a JSON file that contains the mapping of non-hashed asset filenames to their hashed versions and, if you are using Vite, you just need to add manifest: true to your Vite config. This will produce the following file in the /dist of your project:

  "main.js": {
    "file": "assets/index.fb458d74.js",
    "isEntry": true
  "views/cart.js": {
    "file": "assets/foo.869aea0d.js"

The generated Manifest will be used by the Publisher to know the mapping of your microfrontend unique name to its ESM bundle.

Static assets

Everything else, such as images, videos and other static files required by your microfrontend.

Step 2: Define the UI and split into microfrontends

Our online store demo app will have three views: Home, Product & Cart:

Vue is used as a core “metaframework” to have out-of-the-box routing, simple state management with Pinia and Vite as a bundler. It is not necessary at all to use the “metaframework”, moreover, during the build, you’ll get errors from Vite’s internal import-analysis plugin because of unresolved imports (good news, there is a solution for that, see “Challenges → Metaframework”).

To demonstrate how several microfrontends can co-exist together on the same page, they are built with four different frameworks. To make each app’s setup look similar, Vite template presets are used to generate Vue, React, Lit and Svelte microfrontends that are compiled into Web Components. You may consider splitting your app by functional area and building your microfrontends around business domains, such as Order, Product, etc.

Step 3: Build the app

The full source of the Demo app can be found here.

Common problems & solutions

Take control away from the bundler when resolving imports

How do bundlers work? If you ignore the implementation details and go to the highest level of abstraction, they concatenate all the jungle of JS modules and put them into one big chunk, that is minified, uglified, and tree-shaked to get rid of unused code. Simple concatenation wouldn’t work. You need to indicate the entry point and make sure you don’t have modules that import themselves – cyclic dependencies. Most of the bundlers solve this by building an abstract syntax tree. For example, Rollup does it with Acorn.

Using micro-frontends resolved via Import Maps introduces a challenge for your bundler that should normally know your dependencies at compile time, not at runtime. We need to tell Rollup to stop building the tree once a dependency from the Import Map is met and make the current module a leaf node.

Luckily, Vite, Rollup and Webpack have options to take control away from the bundler and let the browser resolve the specified imports by providing their names in the configuration.

import { defineConfig } from "vite";

export default defineConfig({
  build: {
    rollupOptions: {
      external: [

Load import map dynamically

Specs say that “any import maps must be present and successfully fetched before any module resolution is done”. Essentially, it means that the importmap must be inserted in the DOM earlier than any other async script.

Vite is internally using build-html plugin, that produces index.html with the entry point added via <script type="module" src="bundle.js> tag to the <head> section. This is not what we want. Instead, we would like to execute a script that will fetch the import map first, add it to the page, and then load the app script.

To build a custom index.html the Async Import Map plugin for Vite was created that is internally using Rollup Plugin HTML. The plugin extracts the entry point script from the list of generated assets (by lookup for isEntry: true), stashes it, loads the import map from the specified URL and then unstashes and appends the entry point script, giving control back to your app.

See full source here.

Shared state and communication

Eventually, there are only 6 ways to share the state across microfrontends:

  • Windowed Observable uses the global window object as the medium to share the data, often wrapped into a pub-sub library
  • Web storage, such as Local Storage, Session Storage or Cookies
  • URL via query / params
  • In-memory (e.g. Redux)
  • Backend (session or persisted state)
  • Props and Custom events / Callbacks

Everything else you may come across could be just an abstraction on top of these methods. Here is a good summary of their pros and cons.

Since the goal is to use as many native web capabilities and avoid vendor lock-in, we can stick to Props & Custom Events. One important note to mention: to let an event “escape” from the Shadow DOM, we need to set bubbles: true and composed: true. This way we make sure events propagate through the parent-child as well as the shadow tree hierarchy. A nice explanation can be found here.

  new CustomEvent("select-color", {
    bubbles: true,
    composed: true,
    detail: 'blue',

Shared dependencies

To share your microfrontend dependencies, you can declare them as “external” by providing them in the configuration as follows:

import { defineConfig } from "vite";

export default defineConfig({
  build: {
    rollupOptions: {
      external: ["react", "react-dom", "react-to-webcomponent"],
      output: {
        globals: {
          react: "react",
          reactDom: "react-dom",
          reactToWebComponent: "react-to-webcomponent",

Here we are telling Rollup to not bundle React dependencies as well as to provide global variables for them.

But how do we deal with dependency mismatches when one or more microfrontends are using the same lib, but with different versions? Let’s say Footer and Header are two React major versions apart. As mentioned before, we can use scopes:

<script type="importmap">
    "imports": {
      "header": "/path/to/header/index.5475c608.js",
      "footer": "/path/to/footer/index.6087f008.js",
      "react": ""
    "scopes": {
      "/path/to/header/": {
        "react": ""
      "/path/to/footer/": {
        "react": ""

Alternatively, we can provide different import specifiers:

<script type="importmap">
    "imports": {
      "header": "/path/to/header/index.5475c608.js",
      "footer": "/path/to/footer/index.6087f008.js",
      "react@16": "",
      "react@18": "",

If you need some sophisticated logic to build your import map, Import Map Resolver is the place to put it. Let’s say one of your microfrontends publishes its new version that uses react@17.0.1, but you already have react@17.0.0 in your importmap. In this case, the Import Map Resolver would remove an older version and replace it with the newest one. It is one minor version ahead, assuming backward compatibility is guaranteed.

Library microfrontend

Microfrontends can be published as a Custom Components library.

Example using Vite and Svelte:

import { defineConfig } from 'vite';
import { svelte } from '@sveltejs/vite-plugin-svelte';

export default defineConfig({
  build: {
    rollupOptions: {
      input: [
  plugins: [
      compilerOptions: {
        customElement: true,

This will produce two separate chunks, one for the Header and one for the Footer. Vite supports library Mode for Vue and other frameworks.

Without going into each library configuration details, the general principle is to alter your main.ts entry point (or each of your entry points if they are many) in a way you’d like to expose your microfrontend defined as a Custom Element.

import MyComponent from '.src/my-component';

customElements.define("my-component", componentWrapperFn(MyComponent));

where componentWrapperFn is a function provided by your (or a third-party) library that returns a custom element constructor that extends HTMLElement. It could be native defineCustomElement in the case of Vue or third-party reactToWebComponent from react-to-webcomponentHere (and also here) is a great summary of how to build Web Components with different libraries and frameworks.


As mentioned in the section Demo app, a metaframework is used to glue the microfrontends together. Choosing no framework is also a valid option. Import Maps perfectly support this case by resolving imports directly in the browser. The choice of using Vue is mainly to avoid writing boilerplate code for routing and make the container components lean, having little to no low-level DOM manipulation. There is a good article explaining why we need the container components and how to structure them.


Routing between container components/pages is covered by the metaframework in case you are using one. If not, you can opt for Navigo as a simple dependency-free JS router.

In rare cases, when you need navigation within individual microfrontends this is where it gets tricky: at the end, you only have one address bar. You can map the flattened structure of your compound URL state (for example, map and to to enable two-level routing with the help of your framework. There is a library for Angular that uses URL Serializer to intercept and manipulate browser URLs.

That being said, this approach also introduces an unwanted tight coupling among microfrontends: the host app shouldn’t know the details of individual microfrontends routing. When a team needs to change or add a new URL, the host app would need to be adjusted and redeployed. Instead, try avoiding two-level routing at the stage of application design. To better understand all the consequences of this approach, you may want to read the book Micro Frontends in Action by Michael Geers, chapter “App shell with two-level routing”.


Let’s summarize all the benefits that Import Maps offer:

• flexibility for microfrontend teams (each team can have its own tech stack, CI/CD, coding guidelines, infrastructure: everything before final artefacts are built)

• easy step-by-step migration of existing codebases by replacing components or entire pages with microfrontends

• the host app is lean and detached from the development of microfrontends and focuses on the composition of pages, providing the data and handling events

• the host app is not aware neither of the existence nor the implementation details of your microfrontends: the only “contract” is the API of your microfrontend (props/events)

• import map entries are lazy-loaded: no JS is downloaded before you actually import()

• you may not need any build tools at all: import maps work in the browser at runtime

• it takes seconds to update your app (by changing entry in the import map)

• it takes seconds to rollback


Let’s summarize all the drawbacks that the usage of Import Maps brings:

• import Maps are not supported in some browsers, however, there are polyfills

• the overall amount of bytes downloaded when using microfrontends in comparison to monolith is unavoidably higher. Even though you can externalize and share your app dependencies, you cannot avoid eventual code duplication in individual microfrontends

• not suitable for small and medium size projects where single core framework would be a better fit


Using Module Federation in comparison to Import Maps has a major drawback, which is vendor lock-in, that makes your product dependent on another product: Webpack. All your micro-frontends as well as your host app must comply with it and be on the correct version. You also cannot avoid the compilation step, while Import Maps can be used directly in the browser.

At the same time, new web standards are emerging and replacing the need for third-party products. While the standard is being developed further, getting new features, such as multiple import map support and programmatic API, you can already start using them now with the help of ES Module Shims or System JS.

Photo by AltumCode on Unsplash


For us, it is important that we share what we discover interesting in the world. Which articles we read especially in relation to programming and our work environment. Therefore, we actively share articles with you.

The result is a list of the top five articles created from the interactions with the articles shared by you as MB.ioneers.


1. What if we can just play games and learn something new while playing? Find out here with a very extensive list of web applications with which you can learn through play.

2. An article that deals with the difference between the variable types “any” and “unknown”, explains them with an example and shows the advantages.

3. Attention! Be careful when using the dot operator and reflect on whether destructuring the values is possible and makes more sense.

4. What are pitfalls when using NPM or how do you deal with upgrades?

5. It’s this time of the year again that open source maintainers love because of Hacktoberfest! It’s usually a nice time of the year to look to contribute to OSS because everyone is doing, so maintainers are usually very active in approving and interacting with your PRs. Start actively participating in the open-source community and find the first simple steps here!

But please read for yourself and stay curious.


by Roman Guivan who has just started a multi-part Pixi.js game tutorial. follow him on his journey.

and Barbara Jöbstl with a Unix command cheat sheet which is perceived by the community as very complete.

A big thank you to all those who actively share articles with their colleagues at You guys are great.

Sabine Geithner: “Bertha Benz is a developer.”

Sabine Geithner works as the Lead Link Mobile Engineering at She combines 13 years of experience, working in different leadership roles from Project Management, Online Marketing to Software Development.

Until recently, she worked as an iOS developer for the Bertha app. In her current position, she is in charge of hiring the right mobile developers to drive the mobile strategy of the company, fostering a culture of knowledge-sharing and providing an environment for professional growth for mobile developers.In her second role as People Promoter she helps MB.ioneers set meaningful professional development goals and supports them to achieve these goals. 

Sabine’s career starts with her studies. She owns a university diploma in Biotechnology. The requirement for her first semester was an introduction to Java class. It may seem that Sabine has a bit of unusual career background, although it is not uncommon to find people with diverse backgrounds in software development.

In this interview, we want to find out what makes tech jobs interesting to women and how we can inspire young girls to strive towards such jobs. Hello, Sabine!

You’ve had quite the unconventional career journey—what did your start as a Developer look like?

My journey to software development kicked off when I turned 30 and looked back at my life where I was and where I wanted to be. At that time, I was working as Head of Online Marketing and Consumer Insights. My responsibilities included: writing HTML for our SEO landing pages, as well as analyzing consumer data to get valuable insights. So, I had already learned some web development and was using my rudimentary programming skills, for things like writing VBA scripts for my Excel Sheets and SQL statements for MS Access. 

I realized I actually liked programming and wanted to learn more. I started to look for classes online and in Berlin, where I live. Coincidentally, an in-person program called Rails Girls Berlin (now called Code Curious) had just started. They offered free programming workshops for women. I had missed their first workshop, but I liked their idea so much that I offered to join the organizer team and support with marketing. This was the turning point!

What made you decide to completely pursue a career in tech?

By organizing the mentioned workshops for Code Curious I was able to witness women of all backgrounds quitting their jobs and pursuing successful careers as software developers. It was so inspiring that I decided to leave my own job, spend a few months learning with online courses, find myself an internship, and become a software developer. I was 31 years old when I took that step.

What are some of the challenges you have faced in your career?

When I started seriously considering software development as a career, I received some unwelcome comments from people. They said things like “You won’t be able to learn this so fast. You are learning the wrong programming language. You should learn [insert a preferred language] instead. I would never hire someone who hasn’t been writing code since they were little.” I could have easily been discouraged by their words. Luckily, I like to prove people wrong and understood it as a challenge to show them: it can be done and I will do it.

In the early years of my career, I sometimes wasn’t taken as seriously as my male counterparts and had to have several critical conversations confronting people with their behavior. Often they were completely shocked that they behaved this way and every-time things improved significantly afterwards. I wish I didn’t have to jump into these conversations, however, I can only encourage everyone (especially younger women) to confront such behavior. It helped me, and no one should ever feel intimidated and helpless.

What are some of the positive experiences you have gained throughout your career?

There were positive ones that encouraged and supported me to pursue my dream of becoming a Developer. For example, most of the coaches for Rails Girls Berlin were men and the whole Ruby community was actively working towards increasing the number of women in their field. Also, the people who gave me my very first iOS internship were super trusting in my abilities (I had only done online courses before that) and made me feel at home and welcome in the Developer scene.

There are also many men at — who understand the value a diverse workforce adds to our team culture and performance and are actively working on hiring more diverse people.

What does a day-in-the-life at look like for you?

There is little to no routine in software development. A “typical day” could look like this:

The day kicks off with a meeting that we call Stand-Up, where everyone gives an update on the progress of their current tasks. We also discuss blockers or topics that need more clarification and then talk about what we plan on doing today. Afterwards, everyone starts working on current tasks. If we work on a new feature, we will meet to talk about how to approach the problem.

These conversations can stretch over several teams, including backend and design. We talk through different approaches or give feedback to someone else’s result. At the end of the day, we publish the code we wrote to the whole codebase and have a coworker give us feedback on our solution. We also create a new internal version, that the team can use to test the new features we implemented during the day.

Let’s take a look at the bigger picture. According to a 2019 study by the UK Department of Education, parents and teachers are less likely to be encourage girls to study STEM subjects. Since only 3% of females say a career in technology is their first choice, a lower female participation in STEM fields equates to fewer female role models for girls.

Why could (or should) women be interested in becoming a Developer?

Let‘s stop putting people into boxes. The job is interesting for anyone who loves logic, no matter the gender. However, I’ve also observed that children’s interests are largely formed by their environment. If you offer girls only dolls and boys only cars, it’s no surprise they end up having a preference for one. I don’t have kids of my own, but I know that my interest in science was sparked at a very young age by getting microscopes and physics toys, so I give the same toys to my nieces. 

Qualities of high-performing teams are made up of a wide breadth of holistic skills, such as empathy, sensitivity, creativity, and more! Regardless of gender, many roles benefit from having these qualities, e.g. the Plant, the Coordinator, and the Teamworker in Belbin’s model of Team Roles. Thus, I am certain that anyone can be interested in becoming a Developer but success does not depend on your gender.  

What is the benefit of working in the tech industry?

Oh, there are many! From a lifestyle perspective, I think no other job allows for more freedom. Working remotely and asynchronously at weird hours has been common for software developers for a long time. This is absolutely perfect for those who want to have lots of freedom or need to juggle jobs and family. It’s also easy to find a job because software developers are always in demand—and always will be!

For me — the biggest benefit is actually the effect it has on your brain. When I started out, it really felt like my brain was growing. I mean it! You often need to keep a lot of thoughts and ideas in your head in order to figure out how to solve an issue. On top of that, it’s a job that requires life-long learning and keeps you mentally fit in the long-term.

Let’s talk about needed skills and interests. What do you think is the most important strength for software developers to ‘develop’?

According to a study published in Nature, the most important strength for software developers is fluid reasoning and memory capacity (the ability to solve problems with logic and to keep several solutions/ideas in your head) followed by language ability. Funnily enough, numeracy (being good at Mathematics) has the lowest correlation with programming abilities.

However, being a successful software developer requires more than just being able to write good code. Developers need to be able to communicate their ideas to their client, their colleagues, and their boss. Communication skills are key. And of course, if you juggle several projects, you need to be organized, too. These skills become more and more important the more seniority you gain, the more you interact with stakeholders and the more projects you juggle at the same time.

How can I start getting into developing? 

  • To figure out if coding is their interest, I recommend codecademy. It’s a gamified way to learn basic programming principles and highly addictive to people who like logical challenges. 
  • For taking a step further, there are plenty of online platforms that offer pretty good courses, many of which are free. For example, most courses on coursera can be attended without paying. I started 7 years ago with team treehouse. I really liked their curriculum back then and it helped me stay motivated. You are learning software development by working on small projects that grow bit by bit and it is extremely rewarding to see the result so quickly.
  • To go the academic way, there is even a women-only Computer Science study course offered by the HTW in Berlin.
  • There are also meetups (e.g. code curious, women who code, women techmakers) in bigger cities where women in tech help others get into and continue learning software development.

What can I do as a parent to bring this professional field closer to my child and spark their interest?

  • For parents of young children, there are also plenty of opportunities. There is the where kids can learn programming while building or playing a game.
  • Some toys help children practice logical thinking and learn the basics of computer instructions, e.g. Osmo.
  • There are hardware kits, like Kano, that allow kids to assemble their own computers and gives them an insight into how computers work.
  • And don’t forget free meetups and workshops (often called “Coder Dojo”) for kids in bigger cities where they can learn coding in a group.
  • One of the founders of Rails Girls Berlin also wrote a children’s book for girls called “Hello Ruby,” which also has a website to help parents with their kids quest to conquer the world with code.

What is your wish for the future of women in tech?

I hope that more women consider software development as a career and find more and more representation in their teams, at conferences and in technical leadership positions. My wish is that we can at one point drop the “female” in-front of the introduction and refer to people who happen to identify as female, just as “software developer” or “CTO” instead of “female software developer” or “female CTO”.

And lastly…why this headline? Why do you think Bertha Benz would be a Developer and active in mobile engineering today?

The headline is 100 percent correct. Bertha Benz would be a software engineer because she was a woman who valued freedom and independence and wasn’t afraid of entering a male-dominated area.

Want to support and inspire women for tech professions, want to change the game, and know talented women who need to become developers?

Share this article

Way Forward: Digital House Product-Centric Organization

Mercedes-Benz AG and strengthen their product teams within the “Digital House” initiative – realizing a product-centric organization. 

Customers expect the best digital products and services worldwide. Hence,
Mercedes-Benz aims at strengthening its operational e-commerce environments on an international level. Therefore, they will enhance the collaboration with by scaling digital deliveries for e-commerce and online sales even further. 

The goal of the “Digital House” (a joint initiative of Mercedes-Benz AG and is to optimize the business units behind the company’s digital sales and marketing platforms and channels by restructuring them to the upcoming and growing needs of markets and regions worldwide. Within this context of digital products for Sales & Marketing, Mercedes-Benz AG will continue focusing on business and market enabling, strategic portfolio management and respective phase measurements, while will be responsible for the development and operation of digital products even more independently. Within the next two years, will strengthen its digital product teams in Lisbon, Portugal. The Lisbon site will become the development core unit and a dedicated product organization that focuses on scalable product organization, vehicle leads, and sales-generating products. More than 100 additional digital product development positions will be established at in Lisbon. The core of the alignment is a product-oriented organization with the aim of concentrating digital product responsibilities for online sales according to a clear business strategy.