Marcus Wermuth

Almost two years ago, I fell into becoming a manager.

In my past career, I never thought that this would happen. Most of my life I’ve been a maker: working as an engineer, solving technical problems and building apps, products, or just circuit boards.

People management was a huge change. I learned a lot of things the hard way through trial and error, success and failure — but also by reading a lot: books about management, stories about teams and culture, and articles by others who went through the same transition from maker to manager as I did.

I thought I’d take the chance to return the favour by writing about the five things that helped me transition from maker to manager and to level up and grow into my management position.

1. Say good-bye to your work .. and say hello to your team

I know this is a really tricky one: to stop doing what you’ve been doing for the past several years, and what also ultimately got you to this point in your career. Here’s the perspective that I needed to embrace:

Becoming a manager is not a promotion, it is a career change.

Viewing it this way, change is normalized. In my case, I realized that, after a while, coding became a distraction for me. At the beginning of this shift, I was still shipping features and bug fixes while also doing 1:1s with the team on a weekly basis. I couldn’t fully concentrate on one or the other, and that resulted in me doing a bad job in both areas. Both areas are important, but you have to choose one. In my case, I chose the team, and not the code.

As a manager you need to put the company first, your team second, and your team members last.

Now this may sound harsh, but in practice, it leads to the best outcomes for everyone involved. For example, let’s say you mixed up the order of these priorities: you put team members first and the company last. You could easily find yourself with an amazing team, building something that doesn’t move the needle in any way for the company. Or worse, you could end up with a group of empowered individuals, each going off on their own way and not producing much valuable work.

It is incredibly important for you as a manager to understand the higher-level vision of your company. You need to know where the ship needs to sail. Only then can you help your team get there and help them grow into the right direction.

2. Own your education

This one is probably pretty straightforward and could be said about any role or any job. But it is still worth mentioning especially in a career shift similar to mine, going from maker to manager.

I always use this quote from Albert Einstein to highlight how important learning is for us humans (just replace “moving” with “learning”).

Life is like riding a bicycle, in order to keep your balance you must keep moving

The main thing I did in my first few weeks and months was to read, read, read. I needed to learn what management actually is. What are some effective management styles? How do I facilitate great 1:1s? How can I be a great manager without ending up micro-managing everything?

I learned how important it is to be open and honest, and to build trust in my team, and to encourage discussions.

I learned more about everyone in my team, what they like and don’t like. What is their work style? Do they flourish in chaotic situations or dread them? All these details are important to understand, to help each individual grow and perform at their best.

I learned about the different processes we had or were missing at Buffer. Your job as a manager is it to make the life of your team easier and to move obstacles out of their way. So knowing how things are done and where you can improve them is highly important.

Here are a couple of books I would encourage everyone to read, who leads a team or manages one: 

Managing Humans by Michael Loop Really insightful for first time managers, and learning what’s its all about, and foremost learn that it is all about humans.

The Manager’s Path by Camille Fournier Awesome overview of the what roles an engineering team normally has and what the expectations in those job might be.

The 5 Dysfunctions of a Team by Patrick Lencioni I would call this my favorite book, when it comes to building great teams. Although it is written in a fable style, it is so insightful, and so resourceful! Really recommend this to everyone who works in a team.

3. Build your Megazord

What is a Megazord you might ask?

Maybe some of you grown up in the 90s or know the Power Rangers? Well the Megazord is the big robot they create together when they need to fight a bigger more powerful enemy. They could never fight an enemy that big alone, so they come together and form this huge, invincible machine.

We all know that the sum is always bigger than the parts. It’s true for Power Rangers. It’s true for management.

In other words, as you’re making the transition from maker to manager, it’s vital that you create a support network.

Find people who will push you out of your comfort zone and show you a new way of doing things. Surround yourself with people from different backgrounds and with different experiences. Find psychologists, design leaders, or even a kitchen chef. Understanding how others approach problems or find solutions is so key in broadening your horizon!

And there was even an easy way for me to do so. I signed up to two Slack Communities at the beginning of my transition. Just by learning how others approach those things or just learning that bigger companies or more experienced leaders still struggle with similar problems was super helpful to me.

Go ahead and sign up to them, learn from the community, return the favour and share your learnings and struggles too:

• Rands Leadership Slack
• Engineering Manager Slack
• The Water Cooler

(Bonus: You can also learn a lot by reaching out on LinkedIn to those in similar roles. I gained a lot from this!)

4. Don’t do it all

This fourth point is something I just discovered recently, and it opened my mind. We all know that delegation becomes more important the more people you might lead or the more work you have on your hands.

Delegating sounds easy, right? I just tell everyone what to do!

Well I thought so too, but I discovered that it is not easy, and that it requires active work to do delegation the right way.

I thought I was doing great in my job, everything was going well, then I discovered this article by Camille Fournier: When Being “Helpful” Is Actually Hurting. (Notice the airquotes around “helpful.”)

This article opened my eyes! I wasn’t doing bad, but there were a lot of improvements I took from this article. The biggest learning, which I have written in front of me on a sticky-note at my desk, is:

I need to stop taking over work in the name of helpfulness

For instance, if you tell someone on your team that you want to look over all the proposals and be the last one to have a say in something, you limit their growth.

As soon as I understood that, I felt bad. Here I was, thinking I was helping. But essentially when I took over someone’s work or helped them out, I was blocking my team from growing!

5. Being productive in a different way

Last but not least, something almost everyone changing jobs has to cope with.

When you work as a maker/engineer, your output is easily measurable. You know what you are doing and you have something to show at the end of a day. Either something written, something working in your app or your website, or even something you can touch. You can say to yourself – “Nice I did something today, I was productive”.

Here is a quick comparison of what I used as a productivity indicator when I was an engineer:

But now as a manager all I had was this:

As you can see in the screenshot above, your calendar automatically fills up, and at the end of a day, you have meetings to show, not features, bug fixes, blog posts, etc. This was pretty hard for me, I didn’t know if I was productive in a day or not. I had nothing to measure it with, until I realized that my job now, is to make the team work, to chat to people and resolve problems and help the team to flourish. The impact of your work as a manager, is not immediately visible, it’ll play out over the long run.

Having patience and trust is key, when shifting jobs from maker to manager. Feel comfortable with what you do. If your team is doing great, you are doing a great job.

---

Over to you

• Have you made the switch from maker to manager? Have you considered it?
• Which type of path do you resonate with more strongly?

It’d be great to hear your thoughts in the comments. I am also happy to chat with people who are really interested in making this transition, or maybe don’t know how to even get to transition. If you are curious just reach out to me!

I often feel the need to explain what my role means. It is not as clear as “I am an iOS Engineer” or “I am a Designer”. There will also be a thousand different description depending on the company people work at. For us here at Buffer being a Mobile Lead means I am doing a mix of the work of an Engineering Manager and a Product Manager. My job is to help the Mobile Team be able to build our products, whatever that might look like. Speaking up for the team, helping with cross-dependencies or personal thoughts. Let’s turn back a little bit.

How did I end up in this role?

Before having a person leading the Mobile Team long-term, it was a shared responsibility between our CTO and us, the Mobile Engineers. Our team was operating mostly on its own, in our own Mobile world. Only connected to the rest of the engineering and product teams through our CTO. We were doing 1:1s with him on a not so regular basis and were receiving news/requests and other important information through that role.

Roughly 1 1/2 year ago, our CTO decided to move on and leave Buffer. That left us in a tricky situation. At that moment I was worried that this would end up in the Mobile Team drifting further and further away from the actual product teams at Buffer. Luckily I was able to join a group of Engineering Leads at that time to form an interim group, chatting about all the things we needed to replace and work on in this transition period. What I did in those meetings, was to always raise my hand and say things like “Whats with Mobile…”, “This is a huge change for us, ….”, “The Mobile Team needs some support for …”, I became kind of an advocate for the team.

In this transition period, the first thing we did shift was, that I started doing 1:1s with the team and keep them connected to the rest of the team. Trying to help the team to feel safe and cared about, was an important aspect of having someone lead the team. I was bridging the gap between the Mobile Team and the rest of Engineering at Buffer. At the same time, I was still working as an Android Developer.

Do you want to be the Mobile Lead?

After a while, we understood that this role is key in getting the Mobile Team even closer to the rest of the company and keep iterating on where and what the Team can do in the future. Step after Step I started to tackle more and more different topics, like advocating in product meetings that we need to consider Mobile too and build features into the API.

This is what I would call the first transition. Supporting the Mobile Engineers and helping them achieve their professional goals and develop opportunities for them to grow.

While advocating for Mobile in Product Meetings, it became clear that there are still untapped areas for how Mobile can make the experience for Buffer better. That is where the second transition happened or is still happening. I am focusing almost 50% of my time now and understanding more about the Mobile Product Environment, what our users want and do on Mobile. This area of my work is still quite new to me, but it excites me as much as the other half of it!

As you can see in the diagram below, my role is the cross section of Product and Engineering Manager. In my day-to-day, I am focusing on what and who is going to build those stories. You can probably imagine that those roles are never perfect circles. So my areas of focus will never be exactly like this. Especially if you consider that almost half of my time I spend with the Engineering Leads on each platform (iOS + Android) to make this process a dialog.

Engineering Manager

The Engineering Manager part of my role is heavily focused on the people management side, and not so much on the technical side. That’s where I work together with the Tech Leads of each platform and rely on their knowledge.

Some points of what I am doing as an Engineering Manager:

• Lead and align the engineering team with the Engineering vision
• Prioritise tasks for the team
• Inspire, mentor, and evaluate the engineering team
• Cultivate our team culture
• Collaborate with cross-functional peers to deliver projects Improve engineering quality and efficiency (e.g. improve workflow, code review, etc.)
• Hire qualified candidates to strengthen company and team

Product Manager

As I mentioned above this is something I am still working on and am figuring out while you read this. A couple of points I’ve already worked on and plan to do:

• Set the long-term vision and strategy for the Mobile Product
• Communicate this strategy to all of the relevant participants and stakeholders
• Write together User Stories and Roadmaps
• Make Decisions based on Metrics
• User Research to gain more insights into how the product is used and can be optimized

What does that look like on a daily or weekly basis?

This can all sound a bit generic and it is hard to understand what I actually do day in, day out.

I’ve been really enjoying the variety and differences in my days. It never gets boring. Of course, there are moments when both parts (PM, EM) require full attention. When that happens, it can become a bit struggling but with the right peers and the right support, it is always doable. And ultimately having both views, Product View and Engineering/People View it’s really helpful even in those situations.

Here is a screenshot of my calendar, where you can see how I split up my time on a weekly basis. Staying in the same mindset and not change context every hour is key to not becoming tired fast. I use colors on my calendar to differentiate those areas inspired by Lara Hogan’s article.

• Blue — Product related Calls
• Green — People Management/ One-to-Ones
• Red — Engineering Lead Specific Calls

Overall everything I learned until now in this role has been super helpful in understanding more about building great teams and products. I would never have gone another way.

I hope that this helps to understand what it means to be a Mobile Lead at Buffer. If you have any questions or thoughts please feel free to reach out to me. I would love to chat about this, learn from you or maybe even help you with challenges in your current role.

We at Buffer are a fully distributed team. Managing or keeping a relationship with this kind of setup depends almost completely on the people and the culture.

There is a lot of focus on the whole process of how we can conduct our work. One of the topics about remote work and remote management you’ll always hear or find is trust. Trust in letting your company work completely remotely. But how can you build trust in a company where you only always see the persons you work with on a monitor?

My journey to finding out about trust

I thought a lot about this question and it took me a while to find or experience the answer. I used one of our values here at Buffer: Default to Transparency. Transparency is something we at Buffer value quite a lot. We share our salaries, our business numbers, how we work, and most of our challenges. It is built right into our DNA. In my eyes, transparency can also be seen as being open and honest with everyone inside Buffer but also everyone else outside of it. Looking at past examples, we shared what was happening even though it was not something you would consider good news. Some years back when Buffer was hacked, we were super open about what was happening, what had been breached, and what we are doing against it.

Did this hurt the business? Some users who were concerned about the security, in general, might have left but as soon as we shared our journey through this, people cheered along the way and gave us a lot of motivation that we can fix this and come out stronger. Those moments are the best because it shows that we are honest and want nothing more than the best for the user. Why would we hide it? Why should we not tell the public what happened, what good would that do? — It would make us just less credible.

So is that what trust is all about? Trusting the other party that they’ll always be open and honest with you, and the other way around? In my opinion, this is not far from its definition:

assured reliance on the character, ability, strength, or truth of someone or something one in which confidence is placed

How did that affect my leadership

Personally, in my short career as a Team Lead and Engineering Manager, I am becoming more aware of how important it is to be open and honest. Especially in a confrontation with your team and other co-workers. But it is not something you do easily. Most of us tend to say what makes others feel good, being honest and open on the other hand requires some kind of skill or strength to overcome. I definitely encountered occasions, in my private life and work life, where I thought, should I tell the whole story and be open about it or just tell the necessary thing and let the rest happen?

Almost always I’ve chosen the first option. Tell everything, keep everyone in the loop, and go on. In some cases, I was astounded of how much different the outcome was in comparison to what I expected. All the time for the better, of course:

• Should I mention to my team that there some early higher level product decisions going on? — Yes, of course, there could be some valuable feedback in the thoughts of the specialists in their field like no one else.
• Should I keep my direct report in the loop of the ongoing and process of his promotion on every detail? — Yes, of course, that makes everyone feel safe and knowing what’s going on.
• Should I share in my 1:1 with my manager what I am thinking about this process or how the current flow could be optimized? — Yes as this can add some extra thoughts to her work and maybe help her decide. And even if it doesn’t, you have shared it and don’t need to think about it anymore!

Those are just some basic examples coming to mind. You’ll all probably have many more occasion in which you thought for this millisecond “Should I?”

Giving feedback

Another important fact about being honest and open is that this will make the feedback you give and/or get so much more valuable. If you can give honest feedback (be it positive or negative) on a regular basis and in a good way, everyone will know where they stand and what they can do, and will never be surprised by something. Just share all your thoughts on why you made the decision to give the positive or negative feedback. There will be no question left unanswered, and the other party can use the feedback for what it is without unnecessary anxiety around it. I think the same is to say about receiving feedback. You yourself definitely want to receive something honest from your manager or peer in order to tackle it or be proud of it!

I hope that this post will maybe help you even just in one situation where you may decide to tell it all. Maybe you’ll notice how good it feels and how good the other person will react. If you don’t, maybe you’ll receive some honest news, feedback, or thoughts and understand how it is from the other side. All in all, whether you’re a manager or not, be open and honest with everyone around you. It is for the better of the company and your life in general.