Uncategorized

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!


Recognition: One of Team Magnet’s Masterminds

Recognition: One of Team Magnet's Masterminds (Image by http://www.sxc.hu/)

Background

At Magnet Forensics, I lead an awesome team of people with the mission of creating forensics software to help investigators around the world solve crimes. We’re stacked with incredible people–and not only on the team I’m on, but company-wide. We do a great job of recognizing our achievements as an organization and as a team, but also on an individual level. If someone has gone above and beyond, we don’t keep that a secret.

I’ve been trying to make more of a conscious effort to recognize the people I work with, especially in ways that are unique to my own style. I think recognizing people in person is important, but you also need to consider your setting. Sometimes recognition in a public forum isn’t actually appreciated or isn’t nearly as effective as appreciating in a one-on-one setting. I find even for myself that I get uncomfortable when being recognized in a public setting.

With that said, I wanted to recognize an individual I work with without shining too much of a spotlight directly her. Thank you, Christine, for all of your hard work.

Broken Retrospectives

At Magnet, we try to adhere to some agile philosophies.  It lets us pivot pretty quickly to customer needs–which keeps them quite happy–and still lets us deliver rock solid software. We develop in short cycles called “sprints” and at the end of every sprint we have a retrospective to look back at what worked well and what didn’t. That way in the next sprint we can make improvements. Keep the good stuff, drop the broken stuff and try out a thing or two that’s new. This is excellent for continuous improvement unless…

They don’t work.

We would run our retrospectives religiously, but it seemed like nobody really wanted to be there. It was a seemingly forced meeting where I felt a lot of the time I was trying to stir up conversation. By the end of the meeting, just about everyone would have chimed in, but there weren’t a lot of ideas being generated. It was long, boring, and didn’t accomplish any of the goals we wanted it to. Thus, our development cycles stayed basically the same for a while. They worked and they didn’t appear to be broken enough that people wanted to see change.

Things remained the same until I received some input from Christine. When Christine read an article on LinkedIn called I Like, I Wish, I Wonder, she thought it might have some positive carry-over to our development process. If Christine thought that it might spark a change in our retrospectives, that was more change than I was hearing from the team in general (including myself, to be fair). So I decided we’d give it a shot.

Annnd we haven’t looked back since.

I won’t go too in-depth on how I Like, I Wish, I Wonder has rocked our retrospective world because I want to save that for a separate write-up. The point is that it did, and it’s all thanks to Christine for digging it up for us. We’ve started to completely overhaul different aspects of our development process now that retrospectives are effective. I really started to realize just how big of an impact it had when I was explaining some of the development process changes to our CEO. I remember thinking “Wow… If we wouldn’t have switched our retrospective process, we’d be nowhere near as efficient”.

So, thank you for the retrospective idea, Christine. For anyone else looking to flip retrospectives around, try out the I Like, I Wish, I Wonder scheme.

Personalities

I can imagine a lot of people in the development world don’t think too much about personalities. I know I didn’t. Sure, everyone is different. Everyone has their own effective ways of communicating, things they like, things they don’t like, and optimal situations for working. I get it. Now let me go do my work and you go do your work. In an ideal world, you just assume everyone can figure out everyone else that they’re working with, and things will just be fine. Except things are never ideal, and it never hurts to put in a bit more effort to make sure you can get your team up to speed.

So we tried something out. I worked with my HR manager (read: communicated a potential scenario for our development team, let her run free with her awesome creative ideas, and then helped her where she needed it) to roll out a Myers-Briggs personality test for a small sub-team of our development team. If you aren’t familiar with the tests or the concept, check out the link and read up on it! We figured it would be best to try this kind of thing out on a small part of the team to see if they would find value in it, and if so, we’d try the whole team.

After we rolled out the Myers-Briggs results with the small team, the benefits were immediately noticeable. We didn’t even have to leave the room before seeing the benefits. We knew there was some potential here, so we were already excited to try it out with the rest of the team. With everyone being aware of how other individuals may act and react when communicating and working, it makes a big difference in how particular scenarios are approached.

Thank you, Christine, for making differences in personality something to be cognizant of and then supporting our roll-out of Myers-Briggs. For anyone reading this that manages a team or is part of one… Consider the personality types of the people you work with. Maybe you don’t need a formalized Myers-Briggs plan, but it’s worth raising awareness of it.

Thank You, Christine

Christine, you’ve made a lot of great contributions to the team and I’d like to thank you for them. Our development processes have been able to greatly improve thanks to your initial suggestion. I’m sure we would have adapted over time, but your suggested tweaks have certainly acted as a catalyst. Your furthered support with the personality type analysis and subsequent rollout was also greatly appreciated. You were able to participate in our mini-experiment and offered great feedback to turn it into a success for the entire team.

Thank you. I’m looking forward to what this year will bring!


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


Code Smells – Issue Number 3

Code Smells – Issue Number 3 (Image by http://www.sxc.hu/)

Code Smells

Welcome to the third edition of Code Smells! Periodically I’ll be posting about how to detect code smells and what they mean in terms of the big picture of your code. The previous installment can be found right here.

What’s a code smell? Wikipedia says it perfectly:

In computer programming, code smell is any symptom in the source code of a program that possibly indicates a deeper problem. Code smells are usually not bugs—they are not technically incorrect and don’t currently prevent the program from functioning. Instead, they indicate weaknesses in design that may be slowing down development or increasing the risk of bugs or failures in the future.

These code smells are often based on my own opinion and experience with programming. If you disagree with what I’m saying in my post, please don’t hesitate to post a comment. I’d love to clarify anything I may have worded poorly and discuss your perspective–especially if you have a completely different take on things!

The Stink List

Code Smell #7: Using exceptions to control logical flow. This is a pretty nasty path to get into and a bad code smell to stumble upon. Luckily, it’s generally relatively easy to improve. Using exception handling to control logical flow is, in general, misleading. It’s relying on a mechanism used to catch unexpected errors in order to direct the flow of your program. Often times we can use things like if statements to check for these conditions before throwing exceptions.

A common scenario where I see this is parsing. I’ll illustrate this code smell with a little C# example:


var input = "This is not a number";
try
{
  var parsed = int.Parse(input);
  DoSuccessfulStuff(parsed);
}
catch (Exception)
{
  DoFailStuff();
}

It seems a bit contrived, but I’ve seen lots of code written like this–and you know what? This works. It gets the job done. However, there are other mechanisms built-in to .NET that let us do parsing a little bit nicer:


var input = "This is not a number";
int parsed;

if (int.TryParse(input, out parsed))
{
  DoSuccessfulStuff(parsed);
}
else
{
  DoFailStuff();
}

The second set of code doesn’t need to catch exceptions to know that the parsing wasn’t successful. It may not be obvious from this example but throwing and catching exceptions can be quite expensive compared to a few logical sanity checks instead (and before getting into a debate on this, just know the impact it has on your program. I’ve had things go from taking several seconds to multiple minutes, but there are certainly cases where performance will be negligible).

The additional kicker in my contrived example is using the base Exception class to create what a colleague of mine refers to as Pokemon Exception Handlers. Thus, even if you didn’t want to restructure your code, using a specific exception type would:

  • Indicate to other programmers what you’re trying to accomplish
  • Not swallow other potential problems and have them go unseen

Now, this code smell isn’t always possible to avoid entirely. If you’re interfacing with third party components, sometimes you do have to rely on catching exceptions that you can’t otherwise check for ahead of time. If you don’t have the code, you can’t know for every path how/when/why exceptions will be thrown. The same thing could be said when running within an environment where state cannot be guaranteed. Sometimes it’s just necessary. In this case, I would suggest that instead of using Pokemon Exception Handlers, you try to catch the specific exceptions you know you need to watch out for.

Takeaway:

  • If a simple logic check can be used instead of throwing/catching exceptions, it’s likely a better bet.
  • Try to avoid exception handlers that catch all exceptions. Something nasty might sneak by as a result of it.
  • Interfacing with some code or working working in certain environments means you have to rely on exception logic. Take a deep breath and move on.

Code Smell #8: Having an object hierarchy that requires many very light weight classes. Object oriented programming and how object hierarchies are structured are pretty complicated topics of discussion, so I’m not about to try and over simplify it with discussion of this code smell. This is mostly something I’ve gathered from my own programming experience, so I’ll try to illustrate with examples that parallel things I would have come across.

When I’m building an object hierarchy, sometimes it’s not really apparent just how big and complicated it might get. I might start off with a base class and two child classes of it. Over time, the top three levels in my hierarchy have all turned into some sort of class abstraction, and I don’t hit concrete implementations until a few levels down hte hierarchy. Not a big deal–Sometimes it’s just hard to tell where things will go. When things get to the point where in order to introduce a new class and functionality all I need to do is inherit a class and override a single property or method, that’s a bit of a red flag for me.

On the surface, this seems pretty cool. The hierarchy is apparently solidified enough that extending it is really simple if all I need is a single property or method replacement. So why is this a code smell?

In my opinion, it has to do with the duplication of code. If I end up having many child classes (where child in this case represents the child-most class of my mature object hierarchy) that differ only by a single property or method, then I should look at how these classes are being constructed. I wrote recently about how I used lambda expressions to refactor similar code with classes that differed by a single method. My solution, in this case, was to examine the factory that created my classes. Instead of having 10’s of different child classes with a bunch of boilerplate code, I had one factory that could specify the code that differentiated each class.

The benefit of this?

  • Keep class hierarchies from ballooning our of control. Changing an API down the road can mean making changes in many spots.
  • Reduce duplication of boilerplate code. This might be the code required to define a simple constructor or override a getter property.

This is only one small example, but if you get into this situation in your class hierarchy, I’d recommend investigating to see if you can refactor in a similar approach. Maybe your class hierarchy is incredibly mature and isn’t changing much. If that’s the case, you may not even want to touch it. So be it. If you’re still actively adding classes to your hierarchy, it may be better to try analyzing it sooner rather than later.

Takeaway:

  • Object oriented design is a complex topic of discussion.
  • There’s no one perfect way to make your class hierarchies.
  • Having many child classes that differ by a property/method or two may be worth checking for refactoring opportunities.

Summary

I hope you enjoyed this issue of Code Smells. As always, it’d be great to open the floor to discussion. I don’t believe in absolutes, so identifying code smells is not meant to be me preaching some made up laws of programming. Let me know your thoughts on these code smells or share code smells of your own!


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


Lead by Example and Emulate Ideal

Lead by Example and Emulate Ideal (Image by http://www.sxc.hu/)

Background

Leadership has become a big focus for me as I start to grow more into my role at Magnet Forensics. As a developer, I feel like it’s easy to gain basic knowledge and experience with unfamiliar programming territory just by surfing The Internet. With leadership, that’s certainly not the case for me.

What’s my most recent realization? Lead by example if you expect anyone to take you seriously. As a young leader (and with little professional experience in a leadership role), I think this becomes especially important. When you lead by example, you’re showing others that you’re really behind what you’re preaching.

Lead by Example: A Simple How-to

Maybe it’s obvious, but I really don’t think I’m over simplifying my message when I say it. To lead by example, you just do what you expect other people to do. Obvious, right? If you’ve been working for long enough, you’ve probably had a boss that you thought was doing a poor job. There’s many reasons for this, and I don’t want to turn this into a negative-dwelling-unhappy-rant party, but one such reason is it felt like they were just passing down orders to you.

What’s more disengaging than having someone that’s locked up in a room come out every couple of hours to assign you a new task? This boss of yours was doing a poor job of demonstrating meaning to you. Why was doing what he or she was telling you to do was the right thing-the thing that’s going to help get the company to the next step? He or she was not using what I would now call leadership rule #1: lead by example.

Okay. So you’ve envisioned the times when it sucked. We’re off to a good start, because hopefully things can only look up from here. What would you have done differently if you were in your old boss’s shoes and you wanted to inspire an alternate-universe-you to do a good job? There’s probably a handful of things you can think of (and for certain people with certain bosses, maybe that handful is multiple gorilla-sized handfuls).

What if your boss, your manager, or your leader had actually sat down with you and guided you through their expectations? What if the first time through a particular task you sat together and worked through it as a team? What if there was nothing left unclear and you could truly get behind what you were being told? I’m sure you wouldn’t feel resentful of the almighty boss throwing down orders like lightning bolts from the heavens if that was the case.

But why? Here are a few reasons:

  • The clarity of expectations becomes established. There’s a lot less guessing work. Being able to establish clear expectations at work is key to building trust and having successful teams.
  • You buy in. When someone can lead by example, they’re proving to you why they value something. It’s a lot easier to get behind them compared to someone else who has never proved their knowledge, skills, or experience to you.
  • It becomes more like a peer relationship when receiving work. Initially, you feel like you’re shadowing someone that you can more easily relate to. When it comes time to take the reins, you don’t feel like you’re pulling your manager in a carriage behind you.

Emulate Ideal

As a leader, you’d be shocked if you realized just how much of an effect you have on other people. You don’t have to be the CEO or manage 100 teams of 100 people to have the influence either. The even more surprising part? A lot of your influence is actually not a conscious effort on your part. Boom.

The reason I’m suggesting that as a leader you should be emulating ideal is because people will pick up on it. People see how you act, whether good or bad, and will learn to emulate your own behavior. If you’re a hard worker who gets things done, your teammates will learn that that’s what drives the team’s success. If you’re always putting down people’s work, then it will be the norm for nobody to really have an appreciation for the work of others. If you’re watching YouTube and surfing the net all day, that’s now acceptable behavior for everyone else. Repeatedly show up late for or flake out on meetings? Don’t be surprised if meetings become less effective. Constantly encouraging people and acknowledging their successes? You’ll start to see others praising each other. These might be generalizations of course, but if everything else is aligned I’m sure you’ll see these kinds of trends.

This truly is often overlooked. Once you’ve gained respect from people and you have their attention, your actions will have a big impact. So now instead of expecting your team members to act in accordance of what you think is ideal, why not live it out yourself? They’ll automatically start making the transition, especially if you’ve clearly communicated your expectations to them.

Summary

You get the most buy in from others when you lead by example, and you’ll become much more effective as a manager or leader. You have your own expectations of what ideal is, so it’s important to communicate them with your team (Side note: expectations go both ways. Make sure your team’s expectations of an ideal leader are properly communicated to you). One of the best ways you can communicate your expectations through leading by example regularly, and you drive the point home by emulating your definition of ideal.

Extras

If you’re looking for a bit more on how and why to lead by example, consider these links:


Host Migration… Hang In There!

Well this is super embarrassing… But I had to do an emergency host migration from my Raspberry Pi to a more reliable service. It appears as though my Raspberry Pi is no longer with us. Quite a shame.

Anyway, my apologies for the downtime. Hang in there!

EDIT: Getting closer… I think all the posts are back up… New theme… I’m busy re-configuring plugins and then I have to go try and update all the missing graphics. Ugh. On the bright side, the site should be about 5x faster.

EDIT2: Just fixed up a handful of pictures. Not totally jazzed to go through them all right now, but I at least updated my popular articles. It’s definitely been a treat getting back up and running.


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.


Leadership Reads – Weekly Article Dump

Leadership Reading - Provided by Stock Free Images

Great Leadership Reads

Here’s a collection of articles I’ve shared over the past week on social media outlets. There’s a lot of great leadership reads this time around!

  • If You Don’t Treat Your Interns Right, You are Mean…and Stupid: This is a great post by Nancy Lublin that talks about something many full-time people share a common (and usually lousy) perspective on: interns. In my opinion, if you aren’t going to treat your interns well, you shouldn’t be hiring them. One key take away point from the article is ensuring that you treat your internship programs as something real and meaningful. Now, as a computer engineering graduate from the University of Waterloo and from being part of the leadership staff at Magnet Forensics, I’ve seen both sides of the story. Companies should treat their interns well, but interns should also realize companies are giving them the opportunity to be part of something great. It can be a win-win situation if both sides put in the time, effort, and dedication… but it can also be a lose-lose if approached poorly.
  • Does your company culture resemble jungle warfare?: Barry Salzberg talks about office politics in this article. Key take away points? Be aware of the politics but don’t participate. Work together as a company toward your mission and embrace your company values. There’s no room for politics if you want your company to achieve greatness. Politics only interfere and hinder the business.
  • At Home This Weekend? Try This!: Presenting… The Weekend CEO Challenge from Steve Tappin! I thought this article was a pretty cool perspective on how some top CEOs are spending their weeekends. Interested in doing any of these things over the weekend? Do you already do some of these things?
  • Resist the “Us vs. Them” Mindset: Daniel Goleman shares a quote about embracing an “us” vs “them” mindset. Look for the common goals you share with others and embrace them together. Work together and stop viewing others as enemies. It’s hard to be successful if you’re always worrying about thwarting your enemies, so why not rally your friends and work as a team?
  • It’s Time to Change Your Outlook on Change: Change isn’t a problem, according to Daniel Burrus. The problem is the fact that we sometimes fear change despite the fact that we’re built for it. In order to handle change well and be able to embrace it, we need to practice anticipating it. Stop leading blindly and acting surprised when things don’t go as planned… Start being proactive and paying attention to warning signs.
  • The Great Office Space Debate Rages On: Jennifer Merritt talks about a topic that’s been going back and forth for some time now: office layouts. It used to be the norm for companies to have cubicles and offices on the peripherals of a floor. Now the open concept offices have gained tons of traction and companies are even going to extremes and not having fixed work placements. What’s your opinion on office layout?
  • Four Things to Ask Yourself Before Arguing: Rita King addresses four really good things to ask yourself before you consider getting heated over what someone’s said or done. We’ve all been in a situation where someone’s done something to get us fired up, but is it really worth it? If you can manage it, try asking yourself the questions Rita discusses (are you listening? are you repeating patterns? do you understand the other person’s perspective? is there anything to be gained?) and perhaps you can cool yourself off before ruining your own day/week/month.
  • Change Your Habits with a Good Checklist: Habits aren’t easy to change. John Ryan writes about how you can use checklists to start enforcing good habits! Worth a shot at least, right? 🙂
  • Culture Quartet: 4 Steps to Unify Your Company: In this article, Dan Khabie talks about the merger of two companies and how culture played a large role in the success of the merger. Your workplace culture is essential for creating the right atmosphere for people to be productive and work well together. Teams thrive when the culture in the workplace is positive and places value on the employees.
  • The Truth About Best Practices: Liz Ryan discusses the how best practices can be like falling into a trap. Just because there is a best practice or certain metrics are a some sort of golden standard, it doesn’t mean you should blindly follow along. Does the process make sense for your company? Your team? Do the metrics make sense for your industry? Your market? At this current time? Focus on what matters and don’t get distracted.
  • Did You Make The Most of Your Mid-Year Review?: What makes a mid-year review useful? Linda Descano discusses four major points that include having an engaged conversation between both leader/manager and employee, constructive feedback for the employee to work on, and what goals are and how they can be accomplished. If you find reviews to be a time waster, is it because they’re not being conducted well? Are they a waste because nobody is engaged? Or are there other reasons that mid-year reviews feel like they aren’t useful?
  • Do You Find It Difficult to Claim Your Authority?: Judith Sherven, PhD addresses some common reasons why people often don’t consider themselves authorities. It’s a shame too, because it can hold people back from their full potential. If you have great experiences, skills, or you’re knowledgeable in a particular area, why wouldn’t you consider yourself an authority?
  • Where Are You on the Leadership Continuum?: When people consider good leaders, they often describe common traits. Joel Peterson points out that these traits often have varying meanings depending on the person using them. I’d recommend going through his list because it’s pretty interesting to see two very opposing descriptions for the same trait. You might even notice that a trait you would use to describe a leader is actually commonly described by others in a very different way. Definitely interesting!
  • Making Stone Soup: How to Really Make Collaborative Innovation Work Where You Work: Jeff DeGraff discusses some key points for having effective collaborative innovation. Setting high impact targets, recruiting domain experts, making multiple attempts, and learning from your experiences are all major points that DeGraff discusses. There’s also a playlist of videos discussing innovation, so there’s lots of content to absorb 🙂

Hope you enjoyed! Remember to follow on popular social media outlets to get these updates through the week!

Nick Cosentino – LinkedIn
Nick Cosentino – Twitter
Dev Leader – Facebook
Dev Leader – Google+


  • 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