Tag: Teams

What Does an Engineering Manager Do?

This is a question that I see get asked all of the time and I figured I’d chime in on my perspective on it. Specifically, this is with the perspective of a software engineering manager in a tech organization. So, what are the primary responsibilities of an engineering manager at a tech company? Well before I dive in, I’ll explain my background and then I’ll offer up my perspective about the key parts to an engineering manager role.

My Background as an Engineering Manager

First off, here’s full disclosure that I have only been an engineering manager at two different companies. However with that said, I have been an engineering manager at two extremely different types of organizations for just under a decade now. My role at Magnet Forensics as an engineering manager started off as a team-leadership role when we were still a scrappy startup. As we hired on more folks, I helped lead small teams (sometimes 10+ but generally settled around 4-8) as a mix of software engineers and software testers. I was fortunate enough to grow along with our product offering, but only until shortly before I left was I still writing code regularly and managing small teams.

At Microsoft, I’m responsible for a team of under ten direct reports and I have several remote “dotted-line” reports (i.e. they have their own manager, but they’re working with my direct reports as a cohesive team). The work we do is nothing like my previous role, but what’s common is that we have some business requirements, some constraints, and really smart engineers working towards working through these challenges. A fundamental difference is that at Microsoft my team is entirely composed of engineers and no other dedicated roles (i.e. software testers). We carry out work differently but my focuses in my role are very similar.

A lot of my philosophies around management and leadership boil down to focusing on servant leadership. That’s not to say this is the only way an engineering manager can be successful, but as I discuss the focus areas this will likely shine through.

Engineering Manager Roles Are Different Everywhere

I think this is the first critical thing to call out, so if you’re going to take anything from this it’s the following:

An engineering manager at one organization may have very different expectations placed upon them compared to another organization, so if you're pursuing a career at a company as an engineering manager, research and understand how that company structures this role.

This might not be obvious to some people, but it’s true and it’s worth the time to understand. Some organizations place the emphasis of an engineering manager entirely around people interactions and career progression. Some have a large focus on managing projects while others have expectations that an engineering manager is directly contributing to the code base. If you’re interested in this type of role, hopefully you know where your interests and strengths are (and if not, I urge you to reflect and think about this!) so that when you’re evaluating organizations you can find a good fit.

Engineering Managers Put People First

Well in my opinion at least, the good ones do. The people that engineering managers lead are the most important part of their role. Ensuring that their team is engaged, working on challenging problems, learning, has access to the tools and resources they need, feeling supported in their career, etc… All of these aspects are the primary part of the role. They’re all intertwined and influence each other so finding the right set of challenges can ensure people are learning, but different challenges might be more engaging. And while something might be more engaging, it might not be well-suited for someone progressing at their particular career stage.

While all of these things are focus areas for all of the individuals on the team, an engineering manager also needs to keep in mind that… they’re individuals! In order to be effective they need to ensure that they’re leveraging situational leadership and truly working with people one on one. It’s something that’s easily overlooked by many even though it might feel glaringly obvious when you read it. Different people are at different points in their career. Different people appreciate different types of recognition. Different people are motivated by different challenges or learning opportunities. There’s different perspectives. Different career history. Different culture. Everyone is different. An engineering manager truly needs to understand this to be an effective leader because a cookie-cutter approach to trying to lead a diverse team won’t go very far.

It’s important to note that even in roles where the engineering manager has a technical individual contribution portion of their regular work, the overall effectiveness of the team will outweigh individual contributions. It can certainly be a trap especially if the engineering manager is highly technical and productive in the technical domain, but trying to remain a multiplier for the overall effectiveness of the team should be paramount. Between ramping up more junior people to be more effective, giving principal level engineers opportunities to focus on design and strategy, or finding new advanced challenges for senior engineers, finding the right way to bring out effectiveness in the team through situational leadership is the goal here.

Engineering Managers Understand Business Needs

There’s an element to the engineering manager role that is focused on a blend between project and product management. For clarity, I define (in a short version) project management as the process of managing time and resource allocation pertaining to work efforts and product management as interpreting customer requirements as work efforts. These two things together allow an engineering manager to understand shifting timelines and understanding changes in business priorities. It can be very difficult to lead a team if the engineering manager lacks the ability to coordinate the team members effectively or adjust to roadmap changes (as inevitably happens).

And when organizations have dedicated roles for either/both project and/or product managers, it’s still beneficial for the engineering manager to have a deep understanding of both of these. If not solely responsible, they will generally still be actively coordinating with these roles. Effectively, the engineering manager helps represent the team to these roles by relaying team status and needs while also bringing feedback back to the team to adjust as necessary. Depending on the size and complexity of the organization, an engineering manager may spend a large portion of their time actively collaborating with individuals in product and project management positions across a variety of intersecting teams.

Engineering Managers Are Technical

Some might say this isn’t a must, and while I agree it may not be a must, I think it’s really valuable! So I like looking at this as a spectrum to make it a bit more understandable. On one end of the spectrum there are individuals that can jump right in and be an active individual contributor with an extremely high degree of effectiveness. In software, this could look like someone that can work in the codebase to add features or fix bugs or otherwise has a high-degree of understanding of all of the systems working together. On the other end of the spectrum, there are individuals that understand the domain just enough to check the box for understanding the business needs. In my experience, there generally seems to be an inverse relationship between how technical an engineering manager is and how well they focus on the people on the team. It’s not a rule though. I think the really good ones keep up the technical focus without skipping a beat on all the people-related responsibilities.

And it’s a tricky balance. The more time spent working with people and coordinating with other stakeholders, the less time there is for individual contribution. In many engineering manager roles, there isn’t even an expectation of individual contribution so it’s especially hard to keep up on the technical details. The engineering managers that I’ve seen balance this well may not be so far on the technical side of the spectrum that they can dive into the codebase, but they have an overall architectural view. They can also understand and relay technical aspects from team members to other stakeholders, and similarly apply stakeholder feedback with more technical context when communicating back with the team.

Aside from some of the obvious benefits technical skills bring to communication and coordination, I think an aspect that is overlooked comes down to trust and respect of team members. In my personal experience, I have seen engineering managers get buy in from team members when they can prove they understand the technical challenges the team has to work through. Suddenly the engineering manager becomes much more relatable and in those delicate situations where an authoritative decision must be made, it’s easier to get behind it when you trust the person understands the technical details.

While not every engineering manager role may define expectations around technical aspects, I do think that it’s extremely beneficial.

In Summary

To recap, everything discussed is my perspective from my career as an engineering manager and software developer. It’s not the only way, but I think it touches on three of the most important aspects:

  • Focus on enabling people on the team to do their best work
  • Understand project and product requirements to translate between the team and stakeholders
  • Have a thorough technical understanding of the domain to tie this all together

Microsoft: Welcome to Your New Future!

Microsoft logo

2020 has been an interesting year for everyone, without a doubt. For me, 2020 involved a career change that wasn’t something I was expecting at the start of the year. I had been comfortable with my past employer, Magnet Forensics, for just shy of 8 years and had the opportunity to work on many high-impact projects as part of a mission to help with saving children and assisting law enforcement. But at the end of August, I started my first day in my next adventure with Microsoft.

I wanted to write a couple of posts about getting up and running at Microsoft so I figured I’d start with some high level points. This post will be focused on what it was like to join a tech giant after helping scale a startup to hundreds of people internationally.

Meeting the Team and Colleagues

My hiring manager at Microsoft had a list of people he thought would be great for me to reach out to. Forerunners would be the team I’ll be managing and then connections for different functions I would be interfacing with. As well, the list included complimentary teams we’d be working with. Coming from a place where I had the luxury of being around since the beginning of the engineering department, it was a new experience for me to be the outsider… However, this list of initial connections was a great way for me to get oriented.

And well if you didn’t know… Microsoft is big. Really big. So this was an extremely intimidating experience for me. But as soon as I logged into Microsoft Teams I got a message from one of the engineering managers that interviewed me. And I mean literally as soon as I logged in because I didn’t even know where the notification sound came from! And it was an incredibly welcoming message that stuck out to me because this reinforced with me that I wasn’t just a number in a hiring process to fill a seat. Shortly after, I received a message from an old university friend on Microsoft Teams that was congratulating me on my new role and welcoming me to Microsoft. I could feel the tension easing up as I was feeling like I had some great connections already.

So I started sending out the emails to introduce myself and of course it felt awkward saying “Hi I’m the new guy… I know you’re super busy but can you set aside some time so I can get to know a bit more about you and how we’ll interact?” But you know what? Every single person was enthusiastic to welcome me and get something put in our calendar to chat further. Every. Single. One. I haven’t felt so welcomed before. Just another big-tech-stereotype that I had demystified for myself and I couldn’t be happier about it as I started my first day.

Microsoft: Consistent Values

Having not worked for a “big tech company” before, I think that like many people that have lived startup and small business life I made a lot of assumptions about what things might be like. After all, Microsoft has been around since… forever! I’ve been using Windows and Microsoft products since I was physically able to use a computer (which if you took a wild guess was at a very early age). We all know big tech companies only have small pockets of really awesome people… and everything is super corporate with a million layers of bureaucracy… And everything feels like a battle against “the system” just so you can get your opinion heard and….

Okay, so none of that was even remotely close to true. And it was VERY obvious from day one that through *all* levels that there is a homogeneous mission and vision. When the CEO talks about diversity and inclusion and then you see it coming up in the training, and coming up from different levels of leadership, and then directly in your conversations with peers ALL within the first couple of days… You know Microsoft has done something right to nail culture.

This is simply one example that I’m using that I feel would probably hit home with many of us, and I share it because while I could speculate that big corporations might just say they want to focus on this kind of thing in a media or press release, I was shocked (in a positive way) just how much emphasis is put into something that the company believes is a priority. Especially at the scale of the organization. These company-wide goals to focus in certain areas penetrate all levels of the organization and in such a way that you don’t feel “forced” into it, but rather you feel empowered and motivated to be part of the solution and have an influence in it.

Wrapping Up

I think that everything I had hoped was true from my initial talks with the recruiter right through to interviewing with the team was proven to be true right from my starting day at Microsoft. My fears of big-tech-bureaucracy and stagnated perspectives of a behemoth company (and actually more on this to come!) were shut down right away. All of this was such reassuring news as I was getting set up.

While switching companies in tech might not feel like a big deal to some people, for me this has been a completely different life path, and as I mentioned at the start it wasn’t one that I could have easily envisioned for myself. In my previous role I was challenged. I had responsibilities and expertise. I was part of an incredibly important mission. I managed teams of people I loved working with and had colleagues I’d consider to be some of my best friends.

But I was also comfortable. And on that note, I’ll be discussing why I believe that Microsoft is the perfect opportunity for me to challenge myself and help take on a growth mindset.


ProjectXyz: Why I Started A Team For My Hobby Project

ProjectXyz - Why I Started a Team

Who Needs A Team?!

I’ve been building RPG backends for as long as I’ve been able to code. I think my first one that I made for my grade 11 class is the only RPG that I “finished”… It was text-based and all you could do was fight AI via clicking attack, buy better weapons, level up, and repeat. It was also 10000 lines of VB6 code and so brutal that I couldn’t add anything to it without copying hundreds of lines of code.

Since then, I’ve had the itch. I keep rewriting this thing. I keep taking “Text RPG” (super cool and catchy, I know) and rewriting it. I had my first visual representation of this game called Macerus (here’s another rewrite for unity), which is actually how I landed my first co-op job. But every time I’d get so far, I’d decide I needed to rewrite it because I had messed up the architecture in some way and refactoring would be too much work.

My latest attempt is called ProjecyXyz, because I can’t come up with names. And funny enough, I just Googled it while writing this article and there’s actually a company with the same name… So maybe I’ll have to get more creative. ProjectXyz is supposed to be a very generic RPG game framework that allows new systems, mechanics, and game content to be dropped in, in addition to being independent of a front end for rendering.

It’s also something I’ve been making on my own. Because I’ve been making RPG backends on my own for years now. So who needs to have a team, right?

Too Much Pride For A Team

I think initially I wanted to do this all on my own because of pride. I also don’t think it was something I was conscious about except for the fact I looked at this project as my baby and something I could control the development of. I wasn’t consciously telling myself “I have to do this on my own so that I’m better than other people” or anything silly like that.

But why would I go ask others for help? They don’t code like me. They don’t have the same investment into this idea as me. They aren’t as passionate. They might have their own ideas for how to do things too! How could I have someone like that working on MY project?

Those are all pretty naive reasons for considering to work alone though. Sure, this is my pet project and I’m going to likely feel more attached to it than anyone else. That’s probably expected. It doesn’t mean that I can’t find people that are super interested in working on something like this. They could be totally passionate about learning different aspects of creating an RPG backend.

As for having their own ideas… That’s probably one of the BIGGEST reasons in FAVOUR of having a team! It’s easy to get scared about having other people put their ideas into something you feel like is “yours”. It might have taken a few years of working in the industry (currently just passed 6 years of working at Magnet Forensics), but it’s actually very common for other people to be contributing ideas into code bases you’re working on. It happens every day. Sometimes you have design meetings or code reviews or general architectural discussions and your idea ISN’T the one that’s picked. That’s cool! As long as everyone is striving for extensible and testable code, we can make changes if we need to going forward. You don’t need to make every decision and sometimes it’s much better that way. Other people are smart too 😉

Passion is Key for a Team

While the “team” I started isn’t an official team, it’s the first time I’ve been very open to having people directly contribute to my pet project. I think one of the most obvious reasons I became comfortable with this is because I found someone that was very passionate about exploring this space.

My colleague and I were talking about some of the concepts in ProjectXyz and where I wanted to go with it. Immediately he expressed interest in map generation and how that’s always been something he wanted to explore. How can maps be procedurally generated? Can we take this concept and generate maps on the fly? What are memory and runtime constraints? How do we represent this information in code? What about persistent storage?

I could immediately tell he was very curious about how a system like this might work. After several conversations with him about how he was starting to hack up some ideas and doing research on different algorithms, I knew he was passionate about it. We discussed working on some of these things together and contributing to the project code that I have, and we’ve been going back and forth for a few weeks now sharing ideas and his progress that he’s making for map generation. I’ve been hands off only really acting as a sounding board for him.

I think having someone passionate like this is critical for a small team. There’s going to be many barriers when working on a challenging project, and it’s easy to get bogged down and lose motivation when you’re stuck. Having additional people that are passionate about seeing progress in your project means you have some support for pushing through those hard times when you might lose motivation. If my colleague comes to me and says “I’ve been stuck on this issue and maps wont generate how I want…”, then I’m more than happy to sit down with him and talk through his algorithm and maybe where there’s an issue. I’m invested in seeing his piece come to fruition. Similarly, if I’m working on something like dynamic item generation for the game and I get stuck, I know he’s there to do the exact same thing. We both want to see this thing working how we intend.

So passion is important for a team. But is it sufficient? Is it the only requirement for adding a team member?

A Team is Built on Trust

Trust! Trust is a huge part of establishing a team because you need to be able to rely on each other. As mentioned, my colleague is passionate about working on this and has an interest in map generation. But what if I had never seen any of his code before? What if I didn’t know if he’s had practice with writing extensible code, testable code, following good design practices, etc… What if?

To be honest, I probably would be pretty nervous about him contributing code. It might be a huge barrier for me. I’d want to review his code and make sure it wasn’t “polluting” my pet project. I’ve re-written this code enough times that I really don’t want to have to think about rewriting it again! If I was nervous about someone contributing code I was going to need to re-write from scratch just to have an extensible design, it might not even be worth it having them contribute in the first place. It might actually create MORE work in the long run. It sounds selfish, but if the goal of adding someone to the team is to provide a net positive effect, then having to re-write code that isn’t up to par might be a deal breaker.

But that’s not the case here. I have multiple years of experience working with this colleague closely on various projects. We align to coding practices but still have our own twist on things. We value the same things in “good” code (extensible and testable). We use many of the same design patterns in similar situations. I’ve seen enough of his code to know that most of the time my comments about it are “oh, have you considered” and not “… you need to rewrite this”.

I can trust that what he wants to contribute will be aligned to my vision. I also can trust that new ideas he introduces are probably awesome new perspective that I hadn’t thought of. I also trust that if we disagree on something, we’re open to discussing it and coming to a resolution. So trust in this case certainly removes the barrier to entry to adding additional people to my hobby project.

Should You Form a Team?

While this was a pretty general article, I just wanted to get you thinking about opening up your hobby project(s) to other people to contribute. This is something I wish I would have considered more seriously early on. Maybe I wouldn’t be re-writing my project for the millionth time!

Some general points:

  • You’re not a “worse” programmer for getting other people contributing. Good programmers need to be able to work with others!
  • Other people can have good ideas too! Sometimes, they’re even better than your own ideas 😉
  • Other people may have more knowledge or interest in areas that need to get work done that you just don’t want to do! Perfect!
  • You’ll want to try and find people passionate about working in the area your project focuses
  • You’ll want to find people that you feel like you can trust so that you’re comfortable with them working on “your baby”
  • Getting help doesn’t mean your code must be “open source”. You can still share private repositories together (i.e. consider BitBucket!)

So what do you think? Is your hobby project kind of stale because you’ve hit enough roadblocks and it’s time to get some more firepower to tackle it?

Share your thoughts below about your experiences with forming teams for your hobby projects!


  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress