Tag: process

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

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!


Innovation: Weekly Article Dump

Innovation: Weekly Article Dump (Image by http://www.sxc.hu/)

Innovation and You

There’s no denying innovation is important. You often see startups oozing with innovation completely disrupt a market and consequently, there are tons of people out there with dreams to do the same thing. How do you jack up the innovation level in your company? Why is it that startups seem to be so much better at innovating even though multi-million dollar companies have the people and financial resources to throw at R&D? Why do big companies suck at innovating?

The answer starts with your employees. Empowering your employees to innovate and embedding innovation in the work culture is key to ensuring your company continues to innovate. With big companies, the focus moves from innovation to profit maximization. Over time though, some small team of highly innovative individuals are going to find a way to do it differently or do it better, and the big players will take a hit.

Where does your company sit in the world of innovation? Does innovation come from a select few individuals?

Articles

  • Driving Innovation: This article is all about how to truly drive innovation in your company: It doesn’t come from one person, but rather many people. Arne Sorenson shares five tips for trying to drive innovation among his team members. Coincidentally, my colleague Tayfun actually wrote an innovation piece on a similar topic earlier this week.
  • Are Headphones the New Cubicle?: I thought this post by Richard Moran was pretty interesting and at least worst asking yourself the question (even if you don’t feel like reading the article). Open offices are seemingly the new way to go, but are the benefits of open offices reduced by everyone strapping headphones on? I’m personally a big fan of having an open concept office, but I do think that open communication factor is significantly hurt by having headphones on all day.
  • How to Spot a Great Leader in Four Easy Steps: James Caan says that great leaders are defined by four major things: confidence, intuition, decisiveness, and empathy. I have to agree. People need a leader they can get behind and trust to make good decisions. That leader needs to show confidence when they are making their decisions to really show that they aren’t blindly leading people down path X. However, the empathy part goes really far. After all, you’re dealing with real live people, not machines.
  • Intrapreneurship – Guest Blog by Tayfun Uzun: I’ve already briefly mentioned it here in this post, but my colleague Tayfun from Magnet Forensics wrote his perspective on intrapreneurship and how it drives innovation. It’s all about empowering each individual in the company to be innovative in their own right, and in return, the company itself experiences a boost in innovation. Check it out!
  • University of Waterloo Grad’s Journey To Becoming A Software Engineer: Here’s the part where I toot my own horn a bit. A friend of mine, Meghan Greaves, did a mini-interview with me for a TalentEgg article. It’s about how and when I knew what I wanted to do when I “grew up”, what university in Waterloo was like for me, and my transition into a development leadership role at Magnet Forensics. It was really flattering to have Meghan put this together, so please check it out and give her a shout out on twitter!
  • New Generation of Business: Connecting Employee Loyalty with Customer Loyalty: In this post by Colin Shaw, he dives into the concept of employee ambassadors and how you can build a better business by marrying employee and customer loyalty. Keeping employees engaged through your employee ambassadors will help keep the rest of your employees engaged and believing in the company’s mission.
  • Just Do it – Right from the Start!: Michael Skok provides a high-level walkthrough for startup success. The first thing? The right people. A successful company absolutely requires the right people and that’s where it starts. Keeping a solid workplace culture and empowering your employees are two fundamental things to do as you bring the right people on board. Great article!
  • Look for Advisors Who Can Teach, Not Tell: Hunter Walk shares some advice that certainly makes sense for advisory boards, but I wouldn’t limit it to just that. The idea of being able to teach and not just tell is a parallel to great leadership. Telling people what to do is not as effective as telling people what the goal is and empowering them to get there. It’s much easier to learn and grow if you’re given guidelines but you get to hold the reins.
  • Using Humor in Business: Some Practical AdviceColin Shaw is up again this week with an article on humour in business. I think it’s pretty common that when people think of big corporations they have this vision of straight-faced people in suits carrying brief cases… but is that always the reality? Should it be the reality? Colin talks about how you can leverage humour in the workplace for things such as improving relationships or making ideas more memorable. There’s certainly a balance, but I think Colin doe sa great job explaining it.
  • The # 1 Job of a Leader Is …: If you have grammar OCD then skip to the next link right now. Fair warning! Tom Hood says that to be a true leader, you need to be doing “more better”. What does it mean? It’s simple… do better, only more! Okay, maybe it still sounds kind of strange, but the idea still applies. In order to be a real leader in your domain, you have to keep doing better. You need to innovate, push boundaries, and keep doing things better. Do better than your competitors, and do better than you did in the past.
  • 5 Lessons On How to Build High Impact Teams: Jake Wood talks about what it takes to make a high impact team. What are some of the ingredients? First, you need to know your role and how you fit in with your team. You need to embrace innovation and change. And of course, one of my favourites, “Passion trumps talent, but culture is king”.
  • Why Your Software Development Process Is Broken: In this article by Joe Emison, discusses where control in software products lies and how shifting it between developers and high-level managers can have different effects. On one hand, developers with too much control start to stick in all the fancy new technology because developers love new shiny things, and on the other hand high-level managers create a one-way flow of direction down to developers. His solution is to have a benevolent dictator that lies somewhere in the middle.

Empower your team to innovate and watch your company’s innovation as a whole increase. 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+

You can also check out Dev Leader on FlipBoard.


Cookie Cutters For Projects

Background

When you’re starting work on a new project or organizing a team to accomplish a goal, there’s often a foundation that needs to be established:

  • How is your team structured?
  • What software should we use to help us?
  • How do we set goals?
  • How do we measure our progress
  • … the list goes on.

It’s a common challenge that’s met by anyone organizing a team or setting off to work on something. So do you copy what worked for someone else by using a cookie cutter approach, or do you wing it and see what happens? My approach when faced with two extremes is usually to aim somewhere in the middle.

 

Cookie Cutters

Being a copy-cat and using cookie cutters has some benefits. If something worked for some all-star teams at big successful companies, then why re-invent the wheel? They’ve proven that they have a process that works!

Look at a successful company that’s the same size as yours. Look at a team that’s completed a project that has a lot of parallels to what you’re going to be working on. How did they structure their team? Did they split off into smaller sub teams? Did they have daily meetings to discuss progress? Weekly? Monthly? Are they using some sort of software to assist them in their work? Maybe it’s a ticket tracking software, or some CRM to aid with customer interaction. If it worked for them, why wouldn’t it work for you?

The answer to that is because you aren’t them, you’re not working on the same project, and despite all the parallels you might see, your environment is different.

 

From Scratch

Okay okay… So if we can’t copy people, then let’s just do it all from scratch. Start your project tomorrow by holding a meeting and seeing who wants to work on what. Let people just start tackling parts of the project. Have someone create some software that will help you in accomplishing your goal (after all, you don’t want to copy someone else and use some well-established software). And now that you’ve all set off on working on parts of the project, you should probably just meet whenever you need to. Probably not best to schedule anything, because you don’t even know if you need to meet!

So, that sounds pretty sketchy, right? Clearly doing everything from scratch doesn’t seem ideal… Why re-invent the wheel on things that have been proven to work? Where’s the happy medium?

 

The Happy Medium

The truth is there are aspects to tackling a challenge with a team that have been proven to work. There are processes out there that teams have used successfully, software that has improved team efficiency, and strategies for gauging progress that have been used effectively. So when do you copy and when do you work from scratch?

My personal recommendation is to evaluate your options from the start. Look at what other successful companies are doing. Do they use a waterfall approach to developing products, or are they agile? Are they using particular software products for tracking progress, managing projects, interacting with customers, and/or automating processes? Make a list of those too. How often do they meet with other team members? Why are they meeting at those intervals? What are the pros and cons?

After you come up with your options, start gauging how they might apply to you. Your customer requirements are set in stone for your enormous project? Maybe a waterfall approach is better than being agile. Everyone on your team has success using Git and bad experiences using subversion for their source code… So maybe you start with that. Maybe tasks are changing pretty frequently and it’d be helpful to have frequent updates from team members, so you meet briefly every day for updates. Look at your options and think of why certain ones might be good for you.

Start with something. Try it out. There’s no guarantee you’re going to be right the first time you try things out. Actually, it’s likely you’ll do it wrong. But so what? Find out what works. Find out what doesn’t. Then figure out why something didn’t work, and swap that process for something else. Swap that software for something that fits your needs better. Change what doesn’t work and you’ll converge to a rock solid foundation. But don’t fix what isn’t broken. If your daily meetings have been working well for everyone, then why bother arbitrarily switching them to weekly? If it works, then use it.

 

Summary

Regardless of your approach to getting your challenge completed, I think one thing is important: Have flexibility in your foundation until you find what works. Don’t use certain things because other people say to. Use what you think might work best after you’ve evaluated your options, and then once you’ve had it in place for some time, change what doesn’t work. Use the cookie cutters as a source of information and inspiration for why you might want to try something, but don’t let your entire foundation be built from one big cookie cutter. Use lots of little cookie cutters to make your foundation for overcoming your challenge the best it can be for your team and not someone else’s.


  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

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