Tag: teamwork

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!


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


Team Theme – Weekly Article Dump

Team Theme - Weekly Article Dump (Image from http://www.sxc.hu/)

Articles

  • The Real Reason People Won’t Change: Admittedly, when I read this article on my phone the full posting wasn’t available to me. I was only able to read the first page of the article, but the concept was enough to get me interested. “Competing commitments”. Heard of it? I hadn’t but it seems to explain a lot. Competing commitments are, as you might have expected, commitments to things that are in conflict. The article has a ton of examples, but the concept of competing commitments offers insight as to why some people seem stubborn in their ways, despite everything else being lined up for success. A simple example might be someone who is a die-hard advocate of the project they are working on and really wants it to succeed. However, they’re actually inhibiting the success of the project because they aren’t comfortable with their role in relation to teammate. As a result, the team suffers and then the project suffers, but their alignment to wanting the project to succeed is in the right spot. Now that I have full access to the article, I’m certainly going back and reading through the whole thing.
  • Want to be Extremely, Wildly, Radically Successful?: I really appreciated the perspective of Joel Peterson in this article. There’s a million and one books and articles online about how to be successful. They all have titles just like this one. They’re all a bit over the top and unrealistic: “The one thing you need to do to be successful”, “The shortcut to success”, “5 simple steps to being the most successful human being in the universe”. There’s no shortcut to success. All the articles and books that offer information on being successful are doing just that: offering information. You need to make a habit out of doing things that make you successful. Live it. Day in, day out. And it’s not going to happen overnight.
  • The Problem With “There’s a Problem”: This is one my own, so it’s another shameless plug. This post was all about, in my opinion, the right way to tell someone about a problem. If you simply just tell someone that something is broken, doesn’t work, or isn’t right and that’s all that you do, you’re slacking. Everyone, especially in a startup, has a million and one things to do. If you’re about to offload some problem onto someone, at least do your part and get some context around the problem. Better yet, generate some potential solutions so that you’re going to people with solutions, not problems.
  • The Most Powerful Habit You Can Imagine: A colleague of mine shared this article earlier this week, and I felt I had to do my part to share it as well. In this article, Bruce Kasanoff outlines some traits to making your leadership skills more effective. By introducing some compassion and treating people like people, you can have a big impact. People will align more with you and want to work with you. It’s hard to resent your leader or manager when they’re the type of person who fights for you around the clock. You can greatly improve your team mechanics by not acting like an overlord robot.
  • Leadership Tips from The Voice: This article was a bit unique compared to the rest, but I thought it was a cool parallel. Jackie Lauer from Axeltree put this one together. She uses a music performer’s traits as a comparison to a good leader. The highlights? Be fearless. If everything you do is calculated to eliminate all risks, you’ll never fail, and you’ll never learn from it. You need to be a human with the people you lead. Know your strengths and your weaknesses. Build a team that’s strong where you’re weak.
  • The 6 Types of Thinkers to Seek for Your Team: Katya Andresen defines six variations of how people think and how they’re important in a team. She’s not claiming that you need six people (one with each way of thinking) to be successful but rather an individual can have a variety of these perspectives. The interesting part is that if you look at her list and compare it to your current team, you can probably fit each team member into one or two of those types of thinkers. Pretty neat!
  • The Town BlackBerry Built: Is Anything Left?: This isn’t an article… but a video! Our CEO of Magnet Forensics, Adam Belsher, is featured throughout most of this video. Myself and a few colleagues actually have some cameo appearances too, which I thought was pretty cool too. For anyone outside of Waterloo that hears about all the RIM/Blackberry talk, they often have a different perspective of the town than the people living here. Waterloo has an absolutely incredible startup community, and regardless of how good or bad Blackberry is doing, it’ll continue to thrive. As Adam said, it’d be silly if you’re looking to expand your team or business and you’re not even considering Waterloo.
  • 2 Mental Exercises For Battling “It Won’t Work” Syndrome: In startups (or any company really), generating new ideas is a big part of innovating. With any idea, there needs to be a choice to act on it or not. This article is about how some ideas are simply just dismissed without actually giving them a chance. it might be worth trying these exercises out with your team if you feel there isn’t a good environment for nurturing ideas.
  • Infighting is Toxic and Probably Running Rampant at Your Company: What is infighting and how is it killing your company? Let Daniel Roth tell you. In his article, Daniel talks about how competing against each other inside your company can be poisonous. Why not work together towards your common goal against your common competition? If you truly want your company to be successful, you need to put aside your personal agenda.
  • The One Belief That Is Holding Back Your Career: Like the infighting article, Fred Kofman‘s article has a similar perspective. Stop thinking about the goals of individual components of the company. If they are not working toward the common goal of the company, they are not operating effectively. An excellent example is given int he article: The aim of the defense of a soccer team is not to stop the other team from scoring. Their goal, like the rest of their team, is to win. Taking defensive action is how they accomplish that. However, if they’re down one point and the clock is running out, you can bet they won’t just crowd around their end trying to stop any more goals from being scored.

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


Recognition – Weekly Article Dump

Recognition - Weekly Article Dump (Image from http://www.sxc.hu/)

Recognition – Weekly Article Dump

Not all of the articles this week touch on recognition, and to be honest, I didn’t pick it as a theme for the articles either. Recognition is more a topic of discussion that’s come up over the last week at Magnet Forensics, where I work. Being a team lead and part of the management team at Magnet, I’m often part of conversations about motivation. Providing recognition is an excellent way to motivate your staff and shows that you truly appreciate them. We’ve been trying to get better at recognizing staff for doing an awesome job–especially because we have so many awesome people working with us. It’s pretty obvious with our Profit Hot 50 placement that we’ve got some kick-ass people.

Recognition, whether it’s one-on-one or in a public setting, has a huge impact. I don’t even mean recognition in the form of compensation (e.g. bonus or salary raise). Just giving someone recognition for the awesome work they’ve done–plain and simple. It’s a great way to let someone know that their hard work and commitment isn’t going unnoticed. Sure, if they’re developing products, making sales, or acquiring leads there are certain metrics that indicate they’re doing a great job, but recognition is that additional feedback you can provide to really drive the point home. It motivates people and often has a bigger impact than providing compensation.

I want to make a conscious effort to try and recognize some of my colleagues on Dev Leader, going forward, when the opportunity presents itself. I’m always learning from the people I work with and there’s always something great I can say about them. Why not give them a public acknowledgement?

I also have a little surprise coming from a friend and colleague of mine, Tayfun Uzun, early next week, so keep your eyes open for that!

Articles

  • Job Titles and Responsibilities: Last week I wrote about my thoughts on the true role of job titles. As soon as you start to look at your job title as something that defines your limits, you’re on the wrong path. Your job title should define what you’re responsible for, but it’s by no means supposed to put limits on what you can do. Check it out and let me know what you think! Do you feel like job titles should keep people to only a certain set of tasks? Do you feel like having set responsibilities is useful at all?
  • How Strong Is Your Bench: Having a successful company is all about having the right people on board. Sylvia Hewlett writes about what it means to have a rock solid roster within your company. Some of the things include avoiding hiring clones of people exactly like yourself and instead trying to diversify the skill sets within your company. Absolutely true!
  • 8 Steps for Engineering Leaders to Keep the Peace: There seems to be a natural tendency for engineers or people implementing components of a product to push back on product managers or people who decide how a product/service should be. Steven Sinofsky discusses the importance of being an effective engineering leader and ensuring proper communication between engineering leaders and people like PMs or founders. Open and transparent communication is key and helps remind the other party that you do in fact have the same end-goal.
  • Top Tips To Being a Great Mentor: In this article, James Caan provides four key points for being a better mentor. Patience, honesty, positivity, and focus are the four pillars that James describes. Patience and honesty, in my opinion, are the most important but I certainly agree with all four!
  • Leading a Customer-Centric Transformation: Hopefully it’s not surprising, but customers are what your business should be geared toward. As a result, it makes sense that leading customer-centric employees would be beneficial. Don Peppers outlines six things to focus on to make this transformation necessary. It ties in with my post on avoiding organizational silos.
  • The Dark Side Of Software Development That No One Talks About: Don’t be scared that this article mentions software development if you’re not a programmer! It touches on some great points about having a career in software development, so even if you’re not a developer yourself, it sheds some light on some more broad issues. John Sonmez writes about why software developers seem like jerks sometimes and what you can do about it. It seems to boil down to intelligence being a deciding factor for how well you program, so lording your intelligence over other people makes you superior. And because our own intelligence is something we all hold personally, we can get defensive about it pretty easily. John suggests that part of the solution is trying to simplify aspects of software development.
  • How to Win Loyalty From Other People: To be a successful leader, the people you lead need to be loyal to you. Deepak Chopra writes about seven suggestions for building up loyalty and among them “abstaining from disloyalty” is one of my favourites. If you act differently behind people’s backs compared to when you’re leading them, it may come back to bite you later. It’s also crucial to pay attention to each individual’s personal differences to ensure they feel understood.
  • Strategies for Dealing with Randomness in BusinessDon Peppers twice on the list this week! Things in life and business aren’t always predictable for us. It’s just how things are. Are you properly set up to deal with uncertainty in your business though? Remain agile!
  • 10 Quotes All Entrepreneurs Should Memorize: How about some quotes to motivate you? Joel Peterson lists 10 great quotes for entrepreneurs, but I think they carry over to anyone working in a startup. Don’t be afraid to fail and keep moving forward to improve!
  • The Two Biggest Distractions – And What to Do About Them: Distractions are ever-increasing in the workplace, but have you ever considered the differences between the different types of distractions? Daniel Goleman discusses two very different types of distractions: sensory and emotional. I hadn’t really noticed it, but often we find ourselves consciously trying to avoid sensory distractions. If our phone lights up or we get an email notification, we either give in or we make an effort to try and reduce the effect of these distractions. But an emotional distraction is much worse. If something tweaks your emotions the wrong way at work, it often has a bigger impact and it’s usually unexpected.

My take away point for this week regarding recognition: Do it early and do it often. 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.


It’s Our Code

Background

I’m sure what I’m about to talk about here doesn’t just relate to programming–it relates to any team-based project where everyone works on a small portion of the big picture. My experiences are primarily geared toward writing code in teams, so try to find parallels in your own work/experiences if you’re not a programmer. Anyway, enough of that.

When someone puts a lot of effort into something, they’ll often take great pride in the finished product. Of course, it’s great that they do! They’ve slaved away at something at work for days, weeks, or months, and it’s finally working/implemented. Other people are using it and it’s doing its job as expected. Awesome!

What kinds of things could possibly go sour here? If you have experience working in teams to complete a project, you might have some ideas.

Ownership

You don’t own anything. You don’t own a single sentence or character you type and share with your team. You don’t own the title you came up with for the document, the name of a class or interface in your code, the conventions for indenting your variable declarations, the overall file & folder structure of your code, or even the Powerpoint you want to show to the sales and marketing department. If you’re on a team, you’re creating content for your team and your team assumes ownership of it (technically, I guess your company owns everything you do… but… stick with me on this one for a bit).

Ownership becomes a big problem in team environments. Person A worked on Item X, so Person A is assumed to be the owner of Item X. Now every time someone wants to use Item X, they need Person A. Simple? Yeah, that’s a simple system, but it’s absurd. Why don’t I just work on the most important part of the project, encrypt it, and secure my job for the rest of eternity? It’s hard to swallow sometimes, especially after pouring a lot of time and effort into something, but when you’re part of a team you should always be working in order to create things for your team. This has two major benefits:

  • You’ll adjust your perspective to be that of your entire team when you’re making something. (i.e. Am I working to their standards? Am I using their conventions? Can someone else understand what I’m writing here? Will this be easy for them to use? Can someone easily come along and modify my work to improve it in the future? etc…)
  • You remove the people bottleneck.

Ask the Experts

Instead of ownership, people should be considering “expertise”. What’s the difference? Well, someone who owns something is entirely responsible for it. If you want to use it, you ask the one owner. If you want to change it, you ask the one owner. If someone asks you about it, you better direct them to the one owner. The one owner becomes the bottleneck for whatever they own.

An expert is someone who has extensive knowledge in the area and there can be more than one. If you want to use something, you consult one of the experts for proper usage. If you want to modify it, you consult the experts. If someone asks you about it, you can direct them to any of the experts. See the difference? You widen (or eliminate?!) the bottleneck. You increase how robust your team is in terms of responsibilities.

What happens if Bob is sick for a week and he’s the only one who knows how to use the data layer when a big customer bug comes in? What happens when your co-op student who wrote your patented fizz-buzz algorithm leaves to go back to school and no other developer knows how to maintain the code? If there’s only one owner in each of these situations, you’re in a bad spot. If there are several experts who are knowledgeable in the area of code in question, you’re laughing.

Keep in mind, there aren’t only changes in your development staff–your code base is dynamic too.

Code Changes

One huge benefit that software has over almost any other product is that it’s dynamic. You can build something now that works, that may not work next week, that can be fixed the week after, and then later completely rewritten the week after that… and… well… you get the idea. Sure. I know you’re capable of thinking of situations where this doesn’t work with software or products that can somehow get the same benefit, but I’m not contesting that. The point is that software is (usually) flexible and dynamic and you need to treat it like that.

When a group of people has control over software, they can guide the direction it grows in. You get multiple people who are knowledgeable in the direction that the software can take and you leverage the group’s knowledge and experience collectively. Obviously consulting every single person on the team to change a single line of code is overkill, but at least you can find a happy medium in terms of architectural and API changes.

Your code changes because unless you executed the waterfall approach to programming 100% perfectly, your architecture is likely going to change. It’s just a fact of life. But there’s absolutely no reason to freak out. Embrace it. You’ve written unit tests for a reason, right? You’ve used interfaces and designed a nice clean API to decouple your code and make such changes easy. Duh! So don’t worry! You have a couple experts in the area of code that needs to change, so either they can tackle the changes or guide one of your more junior developers.

The same thing should hold true for any process or on-going project that is dynamic. Take measures to ensure that changes in the project or workflow can be done by anyone and don’t jeopardize the whole operation.

Tips

Here’s an assortment of tips (and hopefully some parallels for the non-programming types):

  • Use some sort of revision control. When something bad happens with your work, you always want the ability to press a figurative undo button. Look into something like Git, Subversion, or Mercurial. There are others out there too! Source control software isn’t just great for programmers… If you’re collaborating on a document of any kind, you can leverage source control to manage the revisions of the document.
  • Use tools that allow working on things in parallel. Again, source control helps here for programmers… but find solutions that mirror this. Look at Google Docs! You can literally work with people at the exact same time!
  • Practice and embrace the fact that you don’t own anything… It all belongs to your team, collectively. Keep that in mind or your team may start finding better team players! You want everyone to feel like what they are working on is for the team.
  • When you have something that’s dynamic and changes (like code), take the necessary steps to facilitate and embrace changes. Take precautions to ensure changes don’t mess everything up (unit test & code review!)

Summary

When you’re working in a team, you need to be thinking about your team. What you’re working on belongs to your team and shouldn’t be treated as your personal pet project that you control. This works best when you have multiple “experts” that have knowledge in a given area that can make changes or guide others to make the required changes. If you’re working on something that is dynamic or changes often, you can ease some pains by planning for change. Don’t resist it and fall apart when changes finally happen.


  • 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