Leadership

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

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!


One on One Evolution

Background

I’m a “middle manager” where I work, but that means a whole bunch of things. My everyday tasks primarily consist of programming, but I do a bunch of work to interface with other departments and teams, and I play a role in managing people on… well, the “people” side of things. For the latter part, I refer to that as people leadership.

I think it’s pretty easy to look at some of the aspects of people leadership and dismiss them as “fluffy” or needless… I consider myself a logical/technical thinker, so I have that frame of mind sometimes. However, I do see the value in actually being able to support my team so that they can operate at the best of their abilities. I try to find ways to do that without it seeming to them like I’m doing “fluffy leadership things”, and in turn, I don’t feel that way about it either. With that in mind, I had previously set out with ways to accommodate team feedback in a way that works best for them.

One on Ones: The Early Days

I worked with my HR manager a couple of years back to establish a one on one template that I could use with the developers on my team. The goal was to be able to identify points of conversation since the last time we met, the individual’s current situation (both positive and concerns), and then identify goals. Ideally, the individual is able to fill this out on the form in as much detail as necessary for us to be able to have a conversation about it later.

I didn’t want this to seem like a chore for people so I’ve tried to identify why this is useful for the individual and for myself. For the individual, it gives them an avenue to discuss anything that’s becoming a problem over the period of a few weeks (i.e. something not obvious all at once) or be able to identify successes in their work. It also allows them to reflect on their goals that they want to set in their career, current projects, or even things outside of work (because improving your abilities outside of work is a good thing too). For me, it provides better insight into the trend of problems people are experiencing, their contributions to their current projects, and even helps me see where people are at with their career goals. Both parties are able to benefit from these!

I’ve left it open in the past as to how people submit them. Written? Sure. Digital? Sure. Whatever is easiest for the individual provided I can get it a couple of days before we meet. I’ve also left it open ended as to how much of the form they fill in. Based on the trends, I think people see value in having more content but sometimes the goal setting is a bit of a grey area. People might be between setting different goals and want to wait to discuss those things. The best part is, I don’t need to hassle the team to fill in more… They just do a great job of providing information for me!

One on Ones: Continuous Improvement

I’m all for continuous improvement in our development processes that we have as well as our management processes. With that said, we’ve made a few tweaks to the one on ones recently that I think have had a great positive impact.

  • Digitized: I’ve got everyone on board with digitizing their one on ones. This is incredibly handy for being able to search for content later on (instead of sifting through paper), so I get a huge benefit from it. Each individual can probably benefit from this too if their ever looking for things we discussed. Archiving digital documents has so many benefits over the paper counterparts that it’s hard to imagine going back to these mostly being paper-based. I can easily print off copies for the individual if they lose them (or if I lose them) and it makes life easier for me at year end. I can quickly scan over documents on my computer to get a good overview of a person’s year right on my laptop.
  • Nick’s Notes: A little tweak to the one on one process is that with the digital copies, I can put in highlighted notes. This allows me to get down my feedback to the individuals before we meet. In the past, I requested documents a couple of days before we meet so I can try to action what I can ahead of time. However, adding my notes and getting it back to the individual before we meet let’s them know things I want to dive deeper on. It gives them an opportunity to prepare their thoughts, and from what I’ve heard, this is really beneficial for them. The other positive thing is that it let’s me provide them kudos on certain things that I don’t necessarily need to spend a lot of time talking about them with one on one. It’s improved the efficiency of our meetings, and I think it benefits both sides.

What’s Next?

I’ll be honest in that I don’t have any next steps planned for these one on ones. But that’s okay! I’m going to let a few more rounds of these go through before I try to tweak the process. This let’s me get a feel for how the changes are playing out and then from there I can see where I might need to make some improvements.

If you don’t have a semi-structured system in place for your one on ones, I highly recommend it! Make it something you can at least get a feel for how successful they are. If you can gauge their effectiveness, then you can try to tweak the process over time to improve it! You’ll benefit from the information, and your team will benefit from you providing support for them.


There’s Nothing Wrong With Failing

Fail!

Failure to Communicate

So this post will be pretty short, but I wanted to quickly touch on a workplace experience that happened the other day. I was approached by a colleague (who’s perspective I really value) about the way some of us on the team were discussing a series of events. This individual was really concerned that we kept calling it a failure, and in this person’s mind, we hadn’t truly failed at anything. We had done an experiment in terms of tackling a development problem and the team had reached a critical mass where we declared “enough is enough, this is a failure”. I became concerned because I wanted to make sure this person and I were on the same page.

I couldn’t totally wrap my ahead around why this person was so concerned about calling it a failure. In my opinion, all the evidence was there to call it a failure! But I guess that was just a failure on my part to communicate properly. I think that there was a work culture gap where this person was viewing our declaration of a failure as something really negative, whereas a lot of us were really just marking it as a point of realization to not continue along with something. All of the reasons this person offered up for why our experiment was not a failure were true. We hadn’t missed a deadline to ship and we had a plan for how to work around it. That sounds like success, right?

I guess the communication breakdown was really this: There’s nothing wrong with failing. We tried something and we’ve identified that it’s not working. That’s a failure. What makes us successful? Being able to identify our failures, learn from them, and improve going forward. And that’s exactly what we’re doing. Acknowledging a failure and planning how we can be better next time around.

So with that said… You should be failing when you push the boundaries. Just make sure you learn from your failures.


Hack The North

Hack The North

Hack The North… What The Hack Is That?

Hack The North is Canada’s largest international hackathon. It’s big. It’s bad. It’s awesome. Okay, but what does that even mean?

The idea is that 1000 people get together from all over the world in an event where they’re given 36 hours to create amazing technology hacks. There’s a lack of sleep but no lack of amazing ideas and hacked together proof of concepts that show incredible innovation. Sponsors are present to hand out prizes for best usage of their product or API to competitors as well as mentor them and provide help with problem solving. This year, Hack The North was hosted at The University of Waterloo.

Bro, Do You Even Hack?!

This was my first time ever at a hackathon. I’ve participated in the Ontario Engineering Competition (OEC) which is much smaller scale event with a similar structure–A bunch of students get together and have to come up with a design to solve a problem. I even ran OEC in 2010 with some schoolmates (you might know them at Thalmic Labs) which was a blast. However, this weekend I was sitting on the other side of the table.

I got to hang out with a group of my colleagues at Hack The North at the Magnet Forensics booth. We had a great time representing our company and meeting tons of incredible students from all over the world. We provided assistance where we could with some of the challenges that students were facing, and spoke to them about the important role that our software plays in the life of a forensic examiner/investigator.

What’d You See There?

When I first showed up at Hack The North, it was around 9:00 on Friday night. I got there just in time for the opening ceremonies, which I thought were great. They had live Q&A with a former Facebook employee who has “made it” in the software industry and intros from some of the major sponsors at the event.

Hack The North - Opening Ceremonies

Everyone getting settled for the opening ceremonies at Hack The North.

From that point on, I spent the rest of the time hanging around the Magnet booth… But that doesn’t mean I didn’t see anything awesome. We had people from all over the place coming by to talk to us and pick up some Magnet swag. We handed out an incredible amount of stress balls and couldn’t seem to keep a sufficient supply of them coming. We had our stickers showing up on everything from fuzzy viking hats to laptops to shirts to megaphones. You name it, our stickers made it onto it.

Hack The North - Magnet Viking

Akshay Joshi decorated his hat with Magnet stickers!

Hack The North - Magnet Megaphone

One of the Hack The North organizers was sporting a Magnet sticker on his megaphone.

On the last day of Hack The North, we had participants coming up to our booth to demonstrate some of their awesome hacks. We got to see how Thalmic’s Myo was being incorporated or how other vendors’ APIs were being leveraged to do some really awesome things. We were really impressed with some of the things we saw.

What’s Next?

I think even after the first night of being at Hack The North I was trying to think of what we could do next time or if we even wanted to come back… The answer to the latter was quickly an “absolutely yes!”, so I’m pretty confident we’ll be making an appearance at Hack The North again. There were so many great people at this even that we spoke with that it would be silly not to go back.

I think next year we’d like to participate even more. We learned a lot about the different ways that we could get involved, so things like speaking sessions or workshops would be awesome to get people involved with. We’ll definitely have more stress balls and unique giveaways to please the masses!

Thanks to everyone who made it out to Hack The North. Stay in touch with us! We’d love to hear more from you.

Hack The North - Kelly and Nick

Kelly and I with our #Truth T-shirts and other Magnet gear on at our booth!


Continuous Improvement – One on One Tweaks (Pt. 2)

Continuous Improvement - One on One Tweaks (Pt. 2)

Continuing With Continuous Improvement

I wrote about continuous improvement before and how I’ve been trying to tie that into my leadership role through changes to my one on one process. To recap, at our organization we try to roll continuous improvement into most things that we do. We’re well aware that we’re not going to get things perfect the first time, so as long as we have a process in place to learn, reflect, and adapt, then we can make changes to better our situation. It’s something that’s ongoing and it doesn’t really have an end. So long as your organization is growing and changing over time, or the environment in which your organization is changing over time, having continuous improvement baked into your culture is key to success.

Previously, I mentioned that at Magnet Forensics I hold regular one on ones with my team members. I made a tweak to them that included summarizing notes before holding the one on ones and saw a great improvement. I felt that for now this would be a positive change that I’d like to continue on with. I’ll keep reflecting on whether or not this makes sense over time.

What’s next, then?

Recognition

Recognition is something that I think is fundamental to keeping people engaged, but it looks different for everyone. When I comment on things or share things on social media, I often reflect on how recognition is incredibly important. It’s been a goal of mine to try and do a better job at recognizing my team members for the hard work they’re always putting in.

That was my next hack for continuous improvement. How could I leverage my one on one time to do a better job at recognition? Well, if recognizing my team for things they do is high on my priority list, then it should fall high on the one on one discussion list. The first thing, actually.

So now that I create a summary of topics to go over in our one on ones, I reflect on what my team members say they work on and I toss in other stuff they may not have mentioned. Did they have big accomplishments in our sprint? Did they have things outside of work? Did they have tweaks they suggested for the team to try? Accomplish goals they set for themselves? I try to gather that information and comment on a couple of things at the start of our one on ones now.

I want the team to know that their hard work and their success does not go unnoticed and that they should all keep working to the best of their abilities.

Results?

I’ve only been doing this recently, so I can’t quite say that I’ve noticed big differences. In my opinion, the team has been entering a solid groove over the past few months but it’s hard for me to say whether or not these one on one changes had any impact. I like to think that they did. I’ve heard from several people that they’re really happy with where the team is at.

Has this brought about anything negative? Were there any cons to rolling out this change? I’d say no, not at all. It’s no extra effort for me to reflect on what accomplishments each team member has add. I mean, I’m not writing out lengthy documentation on each accomplishment, but I jot down a couple of points on what I want to call out. I think if anything, that quick exercise has been really positive for myself, if not for the other team member.

So, in the end, I think this small tweak has been a positive change for me in terms of doing a better job of recognizing the team. I also hope that the team has a better understanding that myself and others do see their hard work and efforts.

Keep on it, Team Magnet!


Continuous Improvement – One on One Tweaks

Continuous Improvement - One on One Tweaks

Continuous Improvement – Baby Steps!

Our development team at Magnet Forensics focuses a lot on continuous improvement. It’s one of the things baked into a retrospective often performed in agile software shops. It’s all about acknowledging that no system or process is going to be perfect and that as your landscape changes, a lot of other things will too.

The concept of continuous improvement isn’t limited to just the software we make or the processes we put in place for doing so. You can apply it to anything that’s repeated over time where you can measure positive and negative changes. I figured it was time to apply it to my leadership practices.

The One on One

I lead a team of software developers at Magnet, but I’m not the boss of any of them. They’re all equally my peers and we’re all working toward a common goal. One of my responsibilities is to meet with my team regularly to touch base with them. What are things they’ve been working on? What concerns do they have with the current state of things? What’s going well for them? What sort of goals are they setting?

The one on ones that we have setup are just another version of continuous improvement. It’s up to me to help empower the team to drive that continuous improvement, so I need to facilitate them wherever I can. Often this isn’t a case of “okay, I’ll do that for you” but a “yes, I encourage you to proceed with that” type of scenario. The next time we meet up, I check in to see if they were able to make headway with the goals they had set up and we try to change things up if they’ve hit roadblocks.

No Change, No Improvement

I had been taking the same approach to one-on-ones for a while. I decided it was time for a change. If it didn’t work, it’s okay… I could always try something else. I had a good baseline to measure from, so I felt comfortable trying something different.

One on ones often consisted of my team members handing me a sheet of past actions, concerns, and status of goals before we’d jump into a quick 20 minute meeting together. I’d go over the sheet with them and we’d add in any missing areas and solidify goals for next time. But I wanted a change here. How helpful can I be if I get this sheet as we go into the room together?

I started asking to get these sheets ahead of time and started paraphrasing the whole sheet into a few bullet points. A small and simple change. But what impact did this have?

Most one on ones went from maxing out 20 minutes to only taking around 10 minutes to cover the most important topics. Additionally, it felt like we could really deep dive on topics because I was prepared with some sort of background questions or information to help progress through roadblocks. Myself and my team member could blast through the important pieces of information and then at the end, if I’d check to make sure there’s nothing we’d missed going over. If I had accidentally omitted something, we’d have almost another 10 minutes to at least start discussing it.

Trade Off?

I have an engineering background, so for me it’s all about pros and cons. What was the trade-off for doing this?

The first thing is that initially it seemed like I was asking for the sheets super early. Maybe it still feels like I’m asking for them early. I try to get them by the weekend before the week where I start scheduling one on ones, so sometimes it feels like people had less than a month to fill them out. Is it a problem really? Maybe not. Maybe it just means there’s less stuff to try and cram into there. I think the benefit of being able to go into the meeting with more information on my end can make it more productive.

The second thing is that since I paraphrase the sheet, I might miss something that my team member wanted to go over. However, because the time is used so much more effectively, we’re often able to cover anything  that was missed with time to spare. I think there’s enough trust in the team for them to know that if I miss something that it’s not because I wanted to dodge a question or topic.

I think the positive changes this brought about have certainly outweighed the drawbacks. I think I’ll make this a permanent part of my one on one setup… Until continuous improvement suggests I should try something new!


Leadership: What Does It Mean? – Weekly Article Dump

Leadership: What Does It Mean? - Weekly Article Dump

Leadership

Everyone has their own variation of what leadership means. For me, leadership means empowering others to accomplish their goals and providing assistance when they need it. There were a few articles that came up on LinkedIn this week that I wanted to share with everyone and discuss how they fit into my perspective on leadership.

Articles

  • Does Your Team Work With You Or For You?Kwame Manu-Antwi opens up the article in an interesting fashion. When I read the title of the article, I figured this was going to be the typical leadership vs management debate. However, Kwame goes into describing a scenario where he had a humbling experience from one of his team that made some sacrifices for him. This was truly an example of working for him.

    The entire second half of the article shares a bunch of leadership traits that I think are really beneficial.  For example, being transparent and encouraging growth in your team members. I think the point that is being made in this article, although I don’t personally feel like it was made as obvious as it could have been, is that as a leader, if you want to feel like your team is willing to make sacrifices (for you, or for the team) then practicing being an excellent leader is the way to get there. Thus, the tips he provides to do so!I’d say there’s a lot of takeaway in his bulleted leadership points.

    If you’re an experienced leader then it’s probably mostly stuff you’ve heard before. However, it never hurts to be reminded of great leadership responsibilities!

  • How Do I Hire A Good Employee: Insights on Leadership Traits: In this article Kendall Matthews talks about the specific things he looks for when interviewing. It’s not about how picking the smartest person in the world or the most skilled person according to Kendall. It’s all about finding people that have that curious drive that can think on their feet. Have you given into the status quo?

    When it comes to leadership and hiring, your responsible for building out a well rounded team. In my opinion sometimes this will require hiring the smartest or most skilled person, but more often than not, you’re just looking for go getters. People that are curious by nature and always looking to push the boundaries make great candidates for your team because they’re adaptable. This means you don’t need to go finding someone with the perfect skill set because you can hire the person that’s willing to evolve into that person.

    Again, it’s not a blanket rule in my perspective. Sometimes your team will require that super-skilled person to be up and running from day one. Being a good leader in charge of hiring requires you to understand your teams needs though.

  • Can Skipping a Meeting Make You a Better Leader?: I find that Ilya Pozin always has some interesting articles up on LinkedIn. If you don’t follow him yet, I suggest you do! This article is all about shaking things up to align them to your leadership strategy (and not just accepting meeting invites and then not showing up).The first part of the article is really about taking charge of your daily routine. If you get into work and your ready to make a big dent in your todo list, then moving meetings until later in the day might have a huge  benefit. Similarly, it helps you plan out and prioritize the rest of your day. For me, I plan the night before and since I’m still largely a developer, I find that if I have meetings in the middle of the day when I’m in my groove then that’s when I have the biggest problems. Try tweaking when your meetings are to suit your leadership style.

    The second part of this article talks about the idea of a devil’s advocate and is personally my favourite part. I can’t stress enough how important healthy debate is for continuously improving. I had a colleague the other day say that he doesn’t like how often he hears “because it’s always been that way”. I jokingly responded, “because we’ve always said that”! But the point is, he’s not sticking to the status quo and doesn’t want to settle. I had another colleague argue against my perspective even more recently, and it really got me thinking about how our perspectives were different and where we might need to go next. Healthy debate is awesome. Your goal is not to put your “opponent’s” face in the dirt, but to understand their perspective as much as possible and ensure they get your perspective as much as possible.

  • Heisenberg Developers: In his article, Mike Hadlow talks about how a new (what seems to be scrum-based approach?) was introduced to a software development team and how it negatively impacted them. Mike’s argument? The process that was put in place took away autonomy from developers–they should be given free reign to implement a feature as they see fit.

    While the general consensus in the comments on his blog indicates that people agree, I actually don’t. I’m well aligned to the first two sentences in his closing paragraph (autonomy and fine grained management) being important, but I think direction is incredibly important. In an agile shop, often the customer proposes features to go into the product (and when the customer isn’t available, product owners acting on behalf of the customer propose the features) and the developers work to get them done. Maybe this wasn’t the implication of the blog post, but I don’t think it makes sense to just let developers randomly choose which of the features to work on next and decide on their own how to do it.

    What works better, in my opinion? Have product owners provide acceptance criteria for what would make the feature successful. Have software testers and software developers mull over the acceptance criteria and bounce ideas back off of the product owners. Did they think of how that would affect feature B? Do they realize it will be a support or regression testing nightmare unless feature C is in place? What’s my point? Collaboration. The article doesn’t even mention it. It’s only about how process takes away from the artistic nature of programming. I feel like people should stick to hobby programming if it’s art they want to express, but when it comes time to business, it’s about delivering rock solid features that the customer wants.

    Back to estimating and tasking out features. Why break a feature down? What’s good about doing it that way? If you hit road blocks or need to pivot, it’s great to have a part of a feature done and realize that in it’s current state it might be classified as acceptable for a deliverable. Maybe it doesn’t match the original acceptance criteria, but perhaps the pivot involves adjusting that and now it’s acceptable. Task breakdown brings insight to the people working on the feature. What’s involved in making it? How are you going to test it? How are you going to support it?

    Autonomy is important. But I think that there needs to be some level of process in place for leadership in management to have insight as to what’s taking place, and there needs to be enough autonomy for developers and testers to do their job to the best of their ability. Sometimes the time invested in collaborating is one of the best investments in your development team.

  • Why The Golden Rule SucksJoaquin Roca has an awesome article on “The Golden Rule” and why it doesn’t apply in leadership. Joaquin starts by discussing why building a diverse team is incredibly important and why you should take advantage of the tensions it can create. So why does The Golden Rule suck? Well… not everyone is like you and not everyone wants to be engaged the same way you are. Everyone is different and it’s important to adapt your ways to the person you are engaging with–especially when your team is diverse. There’s also a cool leadership quiz that he has posted at the top of the article!
  • Did I Make a Mistake in Promoting This Person?!: This article is about something that happens in the tech world all too often. Caroline Samne talks about how skilled professionals are promoted into leadership in management positions–except they don’t have any expertise in this area. I’m actually a prime example of this. I was hired on as a developer early on at Magnet Forensics, and before expanding the team, I was chosen for a leadership position without any past experience. However, like the article says, I had great mentorship through our HR manager and I was empowered to seek learning opportunities to grow in this space. The moral of the story is, just because someone is skilled at X, it doesn’t mean they’ll turn out to be a great (people) leader in this space. Leadership just doesn’t work magically like that.
  • Corporate Hackathons: Lessons LearntChristophe Spoerry‘s article is all about hackathons. It’s a great way to spur some innovation in your organization if you’re allowing it to happen naturally. He shares his learnings from past experiences such as having leaders with past experience in hackathons present and having teams and/or themes picked out ahead of time. Once the hackathon starts, you don’t want to be wasting time with logistics… You want to be participating! Discuss what the outcome of the hackathon will be. Who’s going to take ownership over what was created? How will the outcomes be shared with the other participants or the rest of the organization? Get hackin’!

Thanks for reading! Follow Dev Leader on social media outlets to get these updates through the week.


Happy St. Patty’s Day – Weekly Article Dump

Happy St. Patty's Day - Weekly Article Dump (Image by http://www.sxc.hu/)

Happy St. Patty’s Day!

I hope everyone who was celebrating St. Patrick’s Day was able to not only have fun but stay safe doing so. Of course, when there is drinking associated with a holiday it can be easy to get carried away. It’s always a great idea to have driving arrangements or the option to sleep at a friend’s place set up before you head out to celebrate.

This year I was able to celebrate with a handful of my university friends that I don’t get to see as often as I’d like. I haven’t been drinking much at all now for nearly half a year, so I stuck to my one Irish coffee to meet my liquor allowance. We all had a blast discussing where our lives have taken us so far, and it’s great to see everyone doing so well. I was excited to hear that more people are hoping to relocate into or closer to Waterloo!

Happy (belated) St. Patty’s Day everyone, and I hope the recovery has gone smoothly today.

Articles

  • Empower Your Visionaries: Steve Faktor talks to us about who the visionaries are in your company and why you should be empowering them. Steve says that the visionaries within our organizations are frustrated by bureaucracy and will often leave to go start their own Next-Big-Thing. So what should we be doing with them? What can we do with them? Well… challenge them! Challenge them to make their radical ideas a reality. Extend the boundaries you’ve placed on them so that they can try to make their vision a reality and make them feel comfortable with the possibility of failure. Wouldn’t it be great if they’re next big thing was the next big thing for your organization?
  • Don’t Forget Me! Ensuring Distributed Team Members Aren’t Left Out: In this article, Gary Swart touches on how to make sure remote employees are kept engaged. Working remotely can be difficult not only for the person offsite, but for the people that are supposed to interface with the person offsite. Timezone differences, cultural differences (i.e. different holidays, for example), and the fact that you can’t interact in person are all things that make remote team members a lot trickier to work with. Gary suggests using the ICE (Identify, Clarify, and Extend) principle, which he outlines in his post. He also suggests using things like video conferencing so that you can pick up more on body language when you’re meeting remotely and even ensuring that you try to keep your technology homogeneous so that information can be shared easily.
  • Inspire Creativity at Work With All 5 of Your Senses: A good friend of mine shared this with me the other day, and I thought it was worth passing along. Many people don’t pay attention to it, but if you work a traditional office job, you spend a lot of time in the office. Even if you can get a little boost from your environment, it can potentially go a long way over time. This mashable is an infographic about how different colors and ambience in the office can be used to enhance (or restrict) different aspects of your thinking and interaction. If your work environment isn’t playing into your senses, you may be missing out on a positive effect!
  • Great leaders aren’t afraid to take risks: According to Alex Malley, risk taking is a very important part of leadership. He has a handful of suggestions for gearing yourself up for taking risks in your leadership role such as separating the personal aspect of failure from your role. If you’ve set yourself up with talented people, you have open communication with your manager, and you’re prepared for the “worst case”, then you should feel more comfortable taking risks.
  • The complete guide to listening to music at work: I’ve personally given up on listening to music at work during core hours due to the nature of my role (I’ve been told this is “humblebragging“, but realistically I’m just making myself more approachable). However, when I’m cranking through some development work on my own and I know I’m not going to be approached by anyone, I love to turn up some tunes. I thought Adam Pasick had a pretty cool write up about the different aspects of listening to music at work. Essentially, different styles of music may be better for different tasks at work.  I think it’s worth a read if one of the first things you do when you get into the office is strap on your headphones!

Thanks for reading! Follow Dev Leader on social media outlets to get these updates through the week.


Snow Tubing with Team Magnet – Weekly Article Dump

Snow Tubing with Team Magnet - Weekly Article Dump

Snow Tubing

First off… If you haven’t ever gone snow tubing, get off your computer and get to your nearest snow tubing park.

Now that you’re back from that, we’re all on the same page. Friday was another one of Magnet Forensics‘ staff events and we were fortunate enough to go tubing at Chicopee Tube Park. I hadn’t been snow tubing before–only water tubing–and I haven’t even been on a ski hill or anything for years. To be honest, snow tubing to me seemed like a bit of a glorified crazy-carpet experience which would be fun, but get boring after a couple of runs.

I’ll be the first to admit I was dead wrong. Snow tubing was probably the most awesome way for the entire Magnet family to cut loose this quarter. Most people either love or hate the snow, so finding a big group activity for a company to participate in outside in the Canadian winter can be tricky. Snow tubing was perfect though. It wasn’t too intense that people had to shy away from it and it was exciting enough to keep us entertained for the few hours we were there.

Kelly, you did a great job coordinating the staff event! It was great to see everyone come out and have a blast. Thanks for being awesome, Team Magnet.

Articles

  • The Difference Between Managers and Leaders: In this article by Ilya Pozin, he touches on some of the differences between managing and leading. In my opinion, there’s often the idea that managing people is terrible and leading people is the best thing you can ever do. I get that kind of vibe from this article, so I wanted to point it out right at the beginning. I think that a good way to look at it is like this: Being a manager does not make you a leader, but being a good leader sets you up to be a great manager. Leading and managing are different things, and the better you get at leading the better you can become at managing. With that said, I think the article touches on a lot of great leadership points.
  • 5 Ways to Finish What You Start (and Why You Often Don’t)Susan Perry writes about something that a lot of us likely experience pretty regularly. You pick up something new only to end up abandoning it not too much later. Starting a new project or hobby is exciting and it can be really easy to dive head first into something for this very reason. However, if you find that you always start things and never finish them, it might be worth paying attention to some of Susan’s suggestions.
  • 15 Benefits Of Being An Intelligent Misfit: Isaiah Hankel talks to us about what an “intelligent misfit” is in this article. The idea is that swarm thinking is more about just reacting to things, and that’s not overly beneficial. By being unique and standing out, you actually attract others that are unique like yourself with shared interests. As a result, you end up building a network of people that are truly like you instead of conforming to a group. Isaiah goes on to list 15 benefits to standing out in his article and it’s certainly worth the read.
  • Build the perfect teamPeter Mitchell talks about what ingredients you need to build your perfect team. Establishing a common culture and attitude are things that are definitely among the top. Creating clear goals and objectives for your team will also help pave the way for success. One of the most important parts of creating a team is coming up with complementary skill sets. This can be difficult because you want to create a team with people that think alike but have different skills–and often this is hard for people to separate.
  • Fire, Being Tired.: John Hope Bryant gives us a different perspective on what it means to be tired. He says that it’s not just about lacking energy to do something or not getting enough sleep. Being tired is more about losing interest in something. Why? Well even when you’re run down or low on sleep the things that you’re truly interested in can get you excited. John’s suggestion is stick to things that truly interest you–be honest with yourself. Don’t stay in a job where you’re watching the clock for the end of the day. Find your drive and your motivation.

Follow Dev Leader on social media outlets to get these updates through the week. Thanks!


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