Tag: Problem

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


The Problem With “There’s a Problem”

"There's a Problem! (Image from http://www.sxc.hu/)

Problem?

If you’ve ever had a job, as I’m sure anyone reading this has, you’ve probably been on the one side of this situation before. You tell your supervisor/leader/manager/someone-responsible-for-the-thing-with-the-problem that simply, “There’s a problem”. If you’re in or have been in one of those positions I just listed, I’m sure you’ve been on the receiving end of it. But as I said, you probably did the same thing at one point so don’t go holding it against anyone just yet.

What’s the big deal with telling someone there’s a problem? I mean, don’t you think someone should know if something is going wrong? Especially if they’re the one in charge of it! We can’t continue operation with this problem. We can’t release the product to the customer with this thing missing or broken. We can’t sell our product or service with this part of the process being dysfunctional or unreliable. Someone needs to know.

The problem is not sharing the fact that something is wrong. The underlying issue is simply stopping at “there’s a problem”.

Leader’s Perspective: Keep Focus

You’re in a leadership or management position. Without getting into a big leadership vs management debate, one of your primary functions is delegating tasks out to team members. You’re ultimately going to be responsible for project if it fails, so hearing about issues isn’t necessarily a bad thing. So what’s the concern?

Problem?

When someone comes up to you to let you know that there’s an issue, the next logical step is finding out what needs to be done. Now, if you only know that there’s an issue and there’s no additional information or plan of attack provided, it’s all on you to find out how to approach it. Realistically, that’s not so bad. After all, you’re likely in your current position because you’re good at this kind of stuff. However, there are two things to be concerned about:

  • Do you pull yourself off from whatever you’re doing and try to address the problem?
  • Do you need to go find someone to delegate this issue to?

I mentioned delegation is one of your primary functions, so the reason these two things are a concern is because they conflict. They both take up your time. When you’re told that something goes wrong, your brain likely spins up and starts thinking about the how and the why. Then you start thinking about how to fix it. You know the project, the system, or the process inside and out. You could probably find a way to fix it if you put your nose to the grindstone for a bit. But is it the most effective use of time?

Maybe it is. Maybe it isn’t. If it’s not, now you need to start thinking of your team’s status. You know John and Jane are both on something else that’s mission critical for the project to be delivered on time, and they’re your number one and two options for the skill sets required to tackle this. Do you pull one of them off? Do you maybe ask Tim who has some experience with this and is working on something that’s a low priority? Hold on… How can you even know who’s best suited for the problem if you don’t actually even know anything more than the fact that there’s an issue!

Someone–either you or a team member–is going to have to investigate this problem. Why wasn’t any of this done already?

Team Member’s Perspective: Bad Habits

You’re the member of a team and you play a critical role (as do your teammates). Everyone’s time is valuable, so you and everyone else should be keeping this in mind. You’ve stumbled upon an issue and it’s looking like it’s pretty nasty.

Being on the development team, you remember from your standup meeting that John had recently fixed a bug in a similar area. You should go talk to him because he likely has some insight as to what’s going on. On the sales team, you know that Tim had to try and work with a customer from the same country last week, so maybe he can offer some assistance with some of the legalities. Regardless of what team you’re on or what your core role is, having knowledge of what people are doing around you can certainly benefit in this kind of scenario.

But what should you do even before that? Here’s a little list:

  • Is the problem reproducible? Was it just off-chance that it happened? Did you try again?
  • What other things do you think are affected by this? Have you investigated?
  • Do you know what’s wrong? Do you know what’s completely expected, or do you just know that something isn’t completely right?
  • Have you come up with a potential solution? What about a secondary solution?
  • Did you try searching the Internet, a knowledge base, or any other easily-accessible resource as a first step?

What’s great about the items in this list? These are all things you can do or consider on your own before involving anyone else. As soon as you drag someone else into it, now it’s the time of multiple people. Acquire the information that you can and analyze the situation before going to other people. It’s a bad habit to get into where you see a warning sign, toss your hands up in despair, and go tell someone else so they can deal with it.

It may not be in your job title, but taking this kind of responsibility when approaching problems makes it so much easier on everyone that gets involved. It increases the efficiency of the team when you can provide information and context when looking for a solution.

Summary

Things go wrong. It sucks, but nothing is perfect. It affects the staff responsible for projects, processes, and teams. It can teach you to avoid analyzing problems if you simply notify someone without digging a bit deeper.

Consider being on the receiving end of just being told of a problem. What are the first things you’re going to ask to get more information? Try answering these questions yourself before escalating the issue.

Finally, as a leader, it’s your responsibility to identify this type of behaviour. Don’t get mad at your teammates for doing it. They might not even realize that they’re doing it! Have the conversation with them where you tell them that in the future, things will go much more smoothly if they can provide a bit more context to you. Of course, don’t just tell them that there’s a problem.


  • 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