Tag: management

Objectives & Key Results: First Steps to OKRs

At a Glance – What are OKRs?

If you’ve arrived at this post, you’ve probably heard of OKRs but maybe you’re looking for a bit more of an introduction to them. Not to worry! We’ll keep this light and practical for getting started.

OKRs are a framework for helping define, communicate, and measure progress towards goals. Their intention is to not be specifically top-down, but instead there’s goal setting and transparency that works both ways. Objectives, the ‘O’ in OKRs, are essentially single sentence that communicates what you’re trying to achieve. These should drive the point home at a high level, and there’s nothing wrong with making them feel exciting. Key Results, the ‘KR’ part of OKRs, are the metrics that you will be using to gauge how successful you are to achieving your objective. Usually you group about 3-5 KR’s with an objective, but if you’re just getting started with this I don’t think there’s any issue with trying to just nail down ONE. It might be trickier than you think!

Here’s a little example to demonstrate:

Have a world class service that operates at the speed of light, as measured by:

  • Decreasing response latency on API A from 100ms to 60 ms
  • Increasing throughput on API B from 10 MB/sec to 20 MB/sec

In the example above, the first line is the objective. For this OKR, the objective indicates that we’re interested in having a FAST service. The two line items are the key result portion of this OKR and they both describe two different metrics that we’re looking to improve in very specific ways. It’s also important to mention that like with any good set of goal setting, OKRs are timeboxed. In your work environment, you might do these annually, semi annually, quarterly, or some other interval that allows your team to make progress.

A Closer Look at Key Results, the KRs of OKRs

One of the most important parts about setting your KRs is that these should be measurable and specific with a start and end measure. These are supposed to be used to gauge your success when reflecting back to see if you accomplished your objective, so it’s important that they represent something you can measure. And you’ve probably heard something like “You get what you measure” before and this is VERY true for OKRs. If you put a set of metrics in front of a team and tell them to optimize them, generally you’ll get results specific to those measures! If they don’t actually tie back to represent your objective well, you might get awesome progress but for the wrong reasons.

Another call out is that KRs should not be binary. For example, going from 0 to 1, on to off, or going from a feature not landed to feature landed don’t really make good KRs. These might be specific tasks you need to do to help influence the metrics, but they don’t lend themselves well for progression. Why? Consider an example where you might do 99% of the work in your time period and miss landing the feature that enables allllll the goodness for your change that gets you that huge performance boost. From the KR perspective, that’s still a 0% improvement until it’s landed. How were you tracking your progression to reaching your goal if the entire time you were pinned at 0% progress? How does your team feel to have 0% on target after all the hard work that went into something? How do your stakeholders feel when it’s the last week of your period and you’re still trending at 0%? Nobody is saying it’s easy to avoid, it’s just that it’s not very helpful to pick KRs like this. It’s also helpful to think through situations like this and maybe find ways where you can incrementally deliver functionality to avoid these all-or-nothing situations in general! So ideally, your measurements should be on a sliding scale that allow you to demonstrate progress towards a goal.

Finally, the KR’s you pick for your OKRs should be ambitious but achievable. One of the major purposes of using OKRs is getting alignment to drive change in an area, so the “spirit” of the KRs you’ve picked should be understood. If people find these KRs too easy, then you’re not necessarily getting the most effectiveness out of setting up OKRs to help rally progress in an area. However, if they’re too challenging this might be demotivating if people feel they can’t make any progress. I personally think that aggressive KRs can be great if your team can truly influence the KR metrics in meaningful ways.

… What If There Aren’t Metrics Yet?

Right, so if this is all making sense so far you might be thinking through some potential scenarios relative to your job/team/product/service and thinking “I’d love to improve X, but… we haven’t been measuring anything. How can we even have OKRs if we can’t measure? Isn’t that a requirement?”. Technically, you’re right. But not to worry! We all have to start somewhere.

Personally, I believe getting started with OKRs is the most important part. No metrics yet? Instead, spend time to figure out what you WOULD want. Then, start building the measurements out and try making your improvements as you’re figuring out how to measure things. Is that breaking the rules? Yup, you bet it is. Is it going to be a learning experience and something you can improve on next time? Absolutely. Remember, the “spirit” of the OKRs you’re using is to help drive change.

Going through the OKR process is still a useful exercise, helping you to envision what success criteria might look like. While you may not have rock-solid super granular metrics now, maybe there’s some other things you can infer in the short term to guide you! You don’t have performance telemetry being reported with awesome dashboards? No sweat. You’ve been hearing from customers about 10x per week now that performance isn’t up to par? Great! Start with that. Your goal is to try making improvements such that you hear on average 6x reports about performance per week, and in the meantime, you’re going to start building out that awesome performance telemetry and dashboard. A rough metric might be better than no metric, and maybe next time you want to focus on this, you’ll be in WAY better shape with your new telemetry.

As you’re building metrics out, consider if they something the stakeholders care about. OKRs ideally focus on some understandable business value. Another important aspect is if these metrics are something that change-drivers (i.e. maybe the engineers or other roles on your team) can influence. If people are investing all this time and effort to help influence metrics but the actual measure is something they don’t directly affect, it can be frustrating. Ideally, your metrics are something with clear business value AND something your team feels they can directly influence.

Another thing to consider is if something warrants a rolling-average or trend compared to a value at a single point in time for the metric to be measured. Often times with things like services you might be concerned with trends, and in order to avoid statistical blips or other factors causing noise in your measurements, it might make sense to average your measurements out to smooth the numbers! Continuing with our performance example, if you reached your target one week because you measured your service over a holiday when nobody was using it and the small amount of traffic therefore looked incredible, that might not be a great representation of your actual progress. Conversely, if there was some type of outage or incident that caused your measures to temporarily be outliers, you shouldn’t toss in the towel and give up! Rolling averages can be your friend here but ultimately this is something you’ll want to think through.

Finally… Just Get Started With OKRs!

We just talked about all these “rules” for good KR’s, but especially when you’re getting started, you won’t get it “right” the first time. That’s okay. It’s going to take time, practice, refinement, and building out new measurement methods you might not have yet! Until you’re in the groove of setting up good OKRs, think about what the “spirit” of the OKR is supposed to be. Focus on how your objectives and key results will motivate your team to drive change in the areas that matter.

When you’re creating your next set of KRs, reflect on the previous ones! Continuously improve! Were your goals too easy? Too hard? Were you “gaming” the metrics or did your metrics line up with the “spirit” of the KRs? Did the metrics truly tie back to the objective in the end? Were those responsible for delivering changes empowered by the KRs? There’s so many things to reflect on and try to make sure you’re doing better next time. It’s definitely a process.

At a minimum, OKRs should help focus the team’s attention… And that’s a win even if you don’t have the most perfect metrics and clear-cut objectives. Try some things out. Reflect on your success. Get better. Repeat. You got this!


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.


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.


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.


Charity Water – Weekly Article Dump

My 24th Birthday Wish - Charity: Water

Charity Water

We have a lot of pretty awesome people at Magnet Forensics, and every day I’m reminded just how awesome. A colleague of mine, Danielle Braun, had what I thought was an incredible idea for her birthday. For Danielle’s birthday, she’s not asking for more new clothes, for her parents to get her a car, for help with paying off tuition, or for some new fancy tech gadgets. But she’s not asking for nothing. Danielle is asking for your support with Charity: Water this year.

Charity: Water is a non-profit organization with the goal of bringing clean water to people in developing nations that don’t have access to it. Reading their mission page probably opens your eyes a fair bit about the lack of access to drinking water in other countries. They’re not about some complex and elaborate plan to revolutionize access to clean drinking water. However, they do have a simple and straight forward approach. Donate a little bit of money and they can install wells, rain catchments, and filters in areas without access to clean water. Your small contribution can make a huge impact on other peoples’ lives.

Please consider helping Danielle out with her goal of raising money for clean drinking water. A little bit goes a long way with Charity: Water.

Articles

  • Guest Post: 7 Deadly Sins: How to Successfully “Cross The Chasm” By Avoiding These Mistakes: In Geoffrey Moore’s article, we get to revisit some of the great learnings in Crossing the Chasm. If you haven’t read the book, although it’s a bit old now, it’s still a solid read. This post was a great reminder of a lot of the things the book talks about. It’s important to know where your business sits in the chasm model so that you know what you should be focusing on. Too many companies focus on the right things at the wrong times and have terrible missteps. Check it out (and the original book too)!
  • Holiday Gifts EVERY Employee Secretly Wants: Dharmesh Shah is a guy who always seems to have an awesome perspective to share. There are a few things that despite someone’s level of performance, length of employment, or amount of skill should be deserved.  Often these are overlooked either by grumpy managers or because perhaps the person may not have been a top performer. In Dharmesh’s opinion, that shouldn’t be a factor. The holidays are a perfect time to remind ourselves to recognize all of our employees’ accomplishments and treat them with respect. If you aren’t already, maybe this article is the little wake-up call you need.
  • 6 Things Really Thoughtful Leaders Do: Nothing groundbreaking here, but like the article says, this time of year is great for reflecting. Do you consider yourself a thoughtful leader? Do you observe the people around you, how they interact, and how things are flowing at work? Do you take the time to reflect on things you’ve done, how you’ve acted, or even how employees may have improved in areas you’ve discussed with them? There’s a handful of great reminders in this article that I would suggest you check out!
  • 14 Code Refactoring smells you can easily sense and What you can do about it?:  This week’s first programming article! Except… Well… This one is about the management side of programming. How do you know if your software team’s code is in a real stinky spot? This doesn’t necessarily mean your developers write bad code. It could just mean that you need to hit the brakes a bit and go revisit some problem areas in the code. This article talks about some of the warning signs.
  • What Makes A Good Manager? 7 Things To Ask Before You Promote: Does it make sense to give anyone you’re promoting a management position? Probably not. Seems obvious when you ask it like that, right? The unfortunate truth is that a lot of companies take the simple path and for anyone they want to promote, they throw a management position their way. Some people just don’t make great managers. This article talks about the qualities you want to look for in managers. Maybe the person you’re looking to promote won’t make a good manager *now*, but if it’s something they can put time and effort into building the skills and experience towards, it could still happen.
  • 10 Major Causes for Failure in Leadership: While lists of things to do are always nice, having a list of things to definitely not do is also helpful. Here’s one of them. Some of the leadership-don’ts I liked on this list were being too good to serve your followers, using your “authority”, and fear of competition. I think those are a few that are easy for people to forget, and there at the top of my list of leadership-don’ts. Read some more great points in the article!

Please take some time to help Danielle out with her goal. Any contribution helps. Remember to follow Dev Leader on social media outlets to get these updates through the week. Thanks!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Performance Reviews – Weekly Article Dump

Performance Reviews - Weekly Article Dump (Image by http://www.sxc.hu/)

Performance Reviews

It’s almost the end of the year, and performance reviews for many companies are just around the corner. This will be the first time for me sitting on the other side of a performance review. I’m excited, and to be honest, a little nervous about how it will all play out. I know our HR manager has done an excellent job putting together our initial take on performance reviews, but it’s still going to be up to me to ensure that all aspects of a performance review are communicated properly to my team. It’s definitely going to be an interesting time of year!

I’ve started doing a little bit of reading on performance reviews. From what I can tell, the general consensus is that most performance review systems are flawed and nobody knows the perfect way to do them. That’s kind of scary actually. So, like anything, I started questioning all the aspects of performance reviews that I can think of. So things like: What’s stack ranking? Why do companies stack rank? What are alternatives? What about leveraging teammate-driven reviews? etc… There’s a whole lot for me to learn, so I need to start by questioning everything.

With that said, how do you do performance reviews? Have performance reviews been working at your organization? Do you stick to “the norm”, or do you have your own interesting spin on performance reviews that make them effective for your organization?

Articles

  • Employee retention is not just about pizza lunches and parties: On the surface, things like candy stashes, catered lunch, and all other shiny perks seem like a great way to get and keep employees. However, keeping employees engaged is the sum of what attracts them to the company and what keeps them motivated while they’re working. Recognizing their accomplishments and giving them challenging and meaningful work is an awesome start.
  • 7 Reasons Your Coworkers Hate You: The truth? You probably know at least one person at work who does at least one of the things on this list. The harder truth? You probably do one of these yourself. It’s a pretty cool list put together by Ilya Pozin. I’d suggest a quick look!
  • How To Inspire Your Team on a Daily Basis: In this article by James Caan, he echoes one of the things I wrote about recently. You can’t expect to have a motivated team unless you lead by example. You really shouldn’t expect anything from your tea unless you are going the lengths to demonstrate that your dedication to the team and the team’s goal.
  • humility = high performance and effective leadership: Michelle Smith write about how humility is actually a great leadership characteristic. A couple of the top points in her article include not trying to obtain your own publicity and acknowledge the things you don’t know. The most important, in my opinion, is promoting a spirit of service. You lead because you are trying to provide the team guidance and ensure every team member can work effectively.
  • The Surprising Reason To Set Extremely Short Deadlines: This one might not be the same for all people. I think that anyone that tries to apply this as a blanket statement is probably setting themselves up for failure. How do you feel about short deadlines? Some people tend to work really well under pressure and having short deadlines. For those that do, this article offers a perspective on why. Under pressure, you operate creatively given your restricted set of resources, and you don’t have time to dawdle and let things veer of track. Interesting to read.
  • Eliciting the Truth: Team Culture Surveys: Gary Swart talks about something I think is extremely important for all businesses. Maybe your work culture is established, but where did it come from? It’s easy for people to get together in a room and say “we want to have a culture that looks like X”. It’s harder to actually have the culture you say you want. Gary suggests you do a culture survey to actually see what your work culture is like because… well, who knows better? A few people sitting together in a room, or everyone in the company?
  • You Are Not a Number: With year-end performance reviews and the like coming up, I thought it would be interesting to share this short article by Dara Khosrowshahi. Do you stick to stack ranking? Do you have in-depth conversations with employees about their performance? Have you tried switching things up because the canned approach just wasn’t delivering?
  • Which Leads to More Success, Reward or Encouragement?: Deepak Chopra analyzes the positives and negatives of using rewards and using encouragement as a means of driving success. The takeaway from Deepak’s article is that using rewards is not a sustainable means to motivate your team, and actually tends to create separation within the team. By leveraging encouragement, you can empower your team to work together and self-motivate.

Remember to follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


Deloitte Companies to Watch – Weekly Article Dump

Deloitte Companies to Watch - Weekly Article Dump

Deloitte Companies to Watch

Another impressive accolade for Magnet Forensics! Deloitte has placed Magnet on their top 10 companies to watch list! To qualify for the list, the companies need to be operating for less than five years, be based out of Canada, and put a large portion of their revenue to generating intellectual property. Our CEO, Adam Belsher, had this to say about the award:

“We are honoured to be named one of Deloitte’s Companies-to-Watch. This award recognizes the hard work and dedication of our team. We’re thankful for the success we’ve achieved, and we’re incredibly proud to be contributing to the important work done by our customers who use our solutions to fight crime, enhance public safety, protect companies from fraud and theft, and ensure workplace safety and respect for their employees.”

Magnet Forensics Press & Events

The event was put together very well. It was great to be able to interact with individuals from the other companies and share success stories. I even had a chance to meet up with Stephen Lake of Thalmic Labs and have a good chat with him. I’m going to name-drop him everywhere I go because he’s my old university room/house mate! He also happens to be a incredible person that if you have the chance to meet, you absolutely should. Here’s some coverage on twitter of us talking with our founder Jad Saliba:

We enjoyed the whole night, and we were grateful for Deloitte putting on the event. The entire Magnet team is very proud of our achievements.

Articles

  • What comes first: employee engagement or great work?: A short but interesting article on employee engagement. The author claims that most employees probably start of at their position very motivated and engaged. Over time, an employees engagement drops if their leaders are not proactive in keeping their engagement levels up. By proactively acknowledging the success of your employees, you can keep your team engaged and producing great work.
  • Great Leadership Starts and Ends with This: Jeff Haden put together this quick little article about an answer an audience member gave about what the key to leading people is. Caring. Overly simplified? Well, the individual went on to say that regardless of all of your strategies, plans, and experience, if you can’t prove that you truly care about your team then they aren’t going to buy in. I’m never one to buy into something so absolute, but the takeaway for me is that team members cannot be looked at entirely as resources. Sure, the people on your team affect productivity and in that sense are resources, but forgetting to acknowledge the human side of things is a recipe for failure.
  • 9 Ways to Win Employee Trust: In his article, Geoffrey James put together a great list of nine things to help build trust with your team. I wouldn’t say these are groundbreaking things, but it’s important to be reminded about them. Try reflecting on his list and seeing if you actually do the things you think you do. You might be surprised. Some of the top things on the list for me are ensuring employees’ success is number one on your priorities, listen more than you talk, and walk the walk. Great list!
  • Lambdas: An Example in Refactoring Code: I put out this programming article earlier this week and had some great feedback. In this article, I talk about a real world example of how using lambda expressions in C# really helped when refactoring a piece of code. Some people have never heard of lambdas, and some people seem to hate them. In this case for me, it greatly simplified a set of code and reduced a bunch of extra classes. I definitely owe it to myself to start investigating them a little bit more.
  • Executive Coaching: Bringing Out Greater Leadership: This article is all about taking charge with your leadership. Judith Sherven talks about executive coaching for leaders, but the main points I see in here are around confidence. If you aren’t confident in your ability to lead, motivate, and inspire how can you expect anyone else to be? It ends up becoming a tough balance, because you need to listen and take feedback from your team, but when you make decisions you should do so with confidence.
  • Stop Worrying About Making the Right Decision: Ever heard of paralysis by analysis? This article does a great job of explaining why you shouldn’t let that creep in to your leadership approach. It’s important to make good decisions–there’s no doubt about that. But the reality is that no matter what decision you make, there are certain unknowns that can creep in and potentially have a huge effect on the choices you’ve made. So what’s more important: making the perfect decision, or being able to adapt effectively?
  • Appraising Performance Appraisal: Steven Sinofsky‘s article is a bit of a beast, but it’s a great starting point if you’re reconsidering performance appraisals. Even if you’re totally content with your performance review system, it might be worth reading to spark some ideas. Steven does a great job of pointing out some common pitfalls of typical performance appraisal systems and comments on some things you really need to try and understand before sticking to any one system. I’m not well enough versed in the performance review and/or human resources side of things, but this article certainly has enough to get you questioning the common approaches.
  • Tab Fragment Tutorial: Shameless plug for my Android application that I put out on the Google Play store. It’s the end result of the tutorial I wrote up over here. I think it’s going to blow past my legitimate application for converting units!
  • Does a Good Leader Have To Be Tough?: Deepak Chopra has some seriously great articles. In this article, he analyzes the pros and cons of being a “tough” leader. In short, there are positive takeaways from being a tough leader, but there are a lot of negative aspects to it. Deepak suggests you consider a different approach from tough-soft leadership. By focusing on a hierarchy of needs to be a successful leader, toughness is only one aspect of leadership. A pretty solid read, like all of Deepak’s articles.

Remember to follow Dev Leader on social media outlets to get these updates through the week.

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+
Nick’s CodeProject Articles


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