1 on 1 With Engineering Leaders: Engineering Leadership Coach Mathias Meyer


Codecademy for Business and our friends at Code Climate have been meeting with engineering leaders to talk about their career journeys, leadership tactics, and their advice for the next generation of engineers in an interview series, 1 on 1 with Engineering Leaders.

This week, Hillary Nussbaum of Code Climate speaks with Engineering Coach Mathias Meyer. You can check out previous interviews in the series at the following links:

Here on the Codecademy blog, Mathias shares advice for those that are considering careers in engineering or engineering management. Head over to the Code Climate blog for more from this week’s interview, including Mathias’s thoughts on the difference between authority and leadership.

Q: What interested you about engineering when you were just starting out?

When I went to university, I actually wanted to focus on digital media — things like Photoshop, web design, Illustrator, those kinds of things. But then just had to acknowledge that I have no talent whatsoever on the creative side for that particular stuff.

In my third semester, I started playing with C++ and with databases, and that’s when it clicked. That’s when I found it interesting. Today, some people would say, “Wow, C++, that’s a weird language to get interested in programming with.” But it was fun for me at the time. I just found an interest in building things.

Q: What advice do you have for people who might be considering a career in engineering?

My recommendation here would be to always keep an eye on the business and to always make sure that you understand the business that you work in and work for, that you understand the customer, that you even talk to the customer, to make sure to understand what you’re building, how it’s used by the customer, and also how it’s useful to the customer.

I’ve never found anything more powerful than talking to customers myself — or having engineers talking to private customers — and helping every party understand what’s been built and what a customer is using, or how a customer is benefiting.

It’s not really engineering advice. But if you work in an organization, if you work for a business, always keep an interest in what the business is doing and what the customer is doing and how what you’re building benefits both.

Q: What advice do you have for engineers who are considering management one day?

There are three things that I would recommend to new managers, and most of them are not traditional people management things.

One of them is to have or learn patience, because things take a long time. The people that report to you, the people that you work with, they’re going to make mistakes. You’re going to make mistakes as a future manager — it’s the only way to learn. That can get frustrating really quickly, especially as an engineer. You’re used to debugging things. You find a bug, you fix the bug, you deploy it to production, and you’re done. Ideally, that takes a day, maybe an hour, maybe a week. But in management, any “bug” fix that you deploy in your organization or in your team might take months for you to see if it actually worked.

The second one is curiosity. I think as a manager, you run into a lot of situations, or at least that was my experience, where I was like, “Huh, I wonder why that is.” I found it very useful to just keep diving into whatever I found and just digging deeper, asking people sometimes why, sometimes how, sometimes what, just to figure out what was going on. So there was a lot of asking questions involved and just gathering information, forming some sort of hypothesis of what could be going on. I think curiosity is very, very useful, because asking questions is a big part of the job — just to make sure you understand people and that people understand you.

The third one is writing. I think writing is an undervalued skill, especially in management. A lot of what management is, is communication. Communicating orally in one-on-ones or in meetings is necessary, but it’s not always the most efficient way. It also has the downside that people will remember things differently, even if it’s just two or four weeks ago. I’ve found that when something important happens, you write it down to share it with other people, you write it down for yourself, just so you remember in the future what happened, and it’s just a lot easier to come back to. I think any already-experienced manager will have had a situation where communication didn’t go as well, and people on their team had different opinions of what was discussed at a particular meeting — what decision was made four weeks ago, and why it was made. The simplest thing for that is to just write things down and to be proactive in communicating.

For more about Mathias’s career journey and leadership strategies, head over to the Code Climate blog.

Related articles

7 articles

Should I Learn C++?

By Michael Shashoua

Trying to decide if you should invest the time and energy into learning C++? Here are some factors that could impact your decision.