Tag: team

Intrapreneurship – Guest Blog by Tayfun Uzun

Intrapreneurship - Guest Blog by Tayfun Uzun (Photo by www.sxc.hu)

Last week I mentioned a colleague of mine, Tayfun Uzun, had a little surprise. He’s put together a great write up on intrapreneurship and what it means to be an intrapreneur.

The importance of Intrapreneurship

Innovation is the life-blood of any organization; we have all heard it and one way or another understand it. Actually, let me rephrase that. Revenue is the life-blood of any organization, but innovation begets revenue. One big movement in large companies is the idea of intraprenuership, the act of behaving like an entrepreneur within an established organization. Intrapreneurship is baked into your culture–it starts from your first hires in a start-up and needs to persist as you grow. It is not something that you can take a two day course and learn, much like entrepreneurship.

Why do you need intrapreneurship? Well, innovation is what sells. Companies have come and gone because they were stuck in the status quo, not innovating and thus becoming stale. The status quo is boring and demotivating. While these companies make great case studies, they do little to motivate the people involved. Intrapreneurship instills the drive, creativity and urgency into your employees. You can either have one person be an innovator or you can make the entire organization live and breathe innovation.

So, how do you foster an environment where your employees can feel comfortable being intrapreneurs? There are a few things I have found effective to get people out of their shell and try different things.

Be Agile

Following the agile model of iterative product development allows you to be able to test your innovations more frequently and get feedback quickly. This is a key component to intraprenuership. The waterfall methodology doesn’t allow time to tweak ideas and prototypes often resulting on those projects being scrapped for high priority planned projects. With agile you can time-box your innovation, forcing the intraprenuers to feel the same pressure an entrepreneur would feel when building products. A good way to do this is having regularly scheduled hack-a-thons where employees can work on their own innovations for a set period of time.

Encourage and Lead by Example

If you are the founder this one is easier than you think. As a leader, people look up to you and imitate you. As the founder, it is not uncommon for your employees to want to be entrepreneurial like you. Just listen to their ideas. No. Actually listen. I get it–you are the visionary, the entrepreneur–but there is value in hearing and seeing the prototypes being developed by intrapreneurs. Imagine injecting your entrepreneurial spirit into each one of your employees, because that is what you are doing by listening and providing them the platform to innovate.

By providing the means for your employees to become intrapreneurs, you are indirectly improving their day-to-day planned work. It allows them to view what they may consider mundane tasks in a different light and become solution-based thinkers. I often think of innovation as a prize–I am glad to do the grunt work as long as I get to innovate frequently–and in turn this affects how motivated I am as an employee.

Don’t Bet The Farm

If you are gaining traction, don’t pivot. Slowly start empowering the intrapreneurs to be product visionaries too. A good rule, (over)used in agile, is the 80/20 rule. In your next project, try to have 20% innovation driven by the intrapreneurs in your organization, while 80% are planned features. A good way to do this is to take out one or two features that you have planned for a sprint/release, and let the intrapreneurs research and build something. This is a good way to foster creative thinking and innovation with little risk.

Tayfun Uzun was one of the first software engineers at Magnet Forensics and currently is the Product Development Manager, responsible for the Software Engineering team.


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.


PROFIT HOT 50 – Weekly Article Dump

Magnet Forensics - Ranked #7 in Profit Hot 50!

PROFIT HOT 50

It’s with great honour that I can say the company I’m part of, Magnet Forensics, has achieved the 7th place in the Profit Hot 50 rankings for 2013. Last year Magnet Forensics was also on the list ranked at number 16th, but we’ve shown ourselves up by moving a full 9 positions! Our ranking in the Profit Hot 50 is even more impressive considering we’re the only company from Kitchener-Waterloo region in Ontario–Known for it’s incredible startup community and success stories–that made the list. We’re excited and tremendously proud of our accomplishments, but it’s certainly going to be quite the challenge for us to move up in rank next year. It’s a challenge we’re all ready to take on though. You can check out the ranking over here or at the official Profit Guide posting.

Articles

I’ll put the horn-tooting aside… even though it’s an incredible accomplishment (not sure that I mentioned that already).

  • Don’t Be A Perfectionist: Ilya Pozin discusses the downsides to being a perfectionist. Often, people call themselves perfectionists when they can’t think of some other weakness they might have (you see it a lot in interviews) and because they think it’s a loop-hole in the question. I mean, if your weakness is that you’re perfect… how can that be a weakness, right?! Well in reality, aside form being a cheesy way to answer an otherwise good interview question, perfectionism can certainly be a problem. Especially in a fast-paced startup environment, we’re often not hunting for perfect. We’re hunting for 80% perfect with 20% of the effort. It’s the only way we can keep moving fast and get products or services to our customers. Besides, we don’t know what “perfect” actually is… Our customers do. And if we never get anything to them, how the heck can we ever know what perfect is?
  • How Goofing Off Can Make You More Successful: In this article, Adam Rifkin discusses over work. It’s a great tie in to the articles I shared last week about burnout. Adam talks about why we often find ourselves in situations where we feel like we’re forced to over work to be successful and shared a handful of suggestions for how to avoid it. His top 3: Doing nothing. Socializing. Helping others. Sound counter-intuitive to your poor overworked soul? Well kick back, relax, and have a good read through his post 🙂
  • The New Rules for Career Success: In Dave Kerpen‘s article, he shares some answers from Dan Schawbel about what it means to have a successful career. Among the top points, Dan suggests looking inside your current company before looking for opportunities elsewhere. This is a a key point because instead of becoming a chronic company hopper you can actually look for other great opportunities in the company you’ve already invested yourself in. Additionally, Dan suggests acting like an entrepreneur at your current job. If you’ve already proven yourself successful at your role, look for side projects that can benefit your company.
  • The Part They Don’t Tell You About Startup Team Building: The end result of becoming a good leader is often that you obsolete yourself in your current job. It’s a strange truth about the position: You start off taking on a large workload and then lead others so that they can effectively take on your portion and more. Where does that put you as a leader though? Tomasz Tunguz discusses this leadership role evolution in his article.
  • Raspberry Pi + WordPress => PiPress: This is a bit of a shameless plug, but I thought it might be cool for any tech-savvy bloggers out there who are looking for a bit of a DIY. After reading all over The Internet for how I can use my Raspberry Pi, I discovered I could use it to host a blog. So, for what it’s worth, the text you’re reading right now is coming from a little computer just a tad bigger than a credit card.
  • The 7 Things That Will Stop You Getting Things Done: Do you find there are a lot of things throughout your day that cut into you working efficiently? Bernard Marr has a nice list of things that are likely chewing up your time and a handful of solutions for how you can minimize the effect they have on your life.
  • Business is Over: My New Post-Workday Transition RoutineJeanine O’Donnell uses a BBB acronym for helping her transition from work-mode to home-mode. How do you handle separating your work-life from your home-life? Is there even a separation for you?
  • The Business World Can Tear You Apart – If You Let It: Even after achieving financial success and success in your career, sometimes there’s just something missing. Joel Peterson shares some tips for how you can keep your career focus from taking away from the finer things in life.
  • 6 Ways to Put the Good (Bad and Ugly) in Goodbye—Part II: Last week I shared a post about a great example of how to say to goodbye to your employees when they’re leaving for other opportunities. This post by Chester Elton builds on that with more positive examples, but he also shares some downright terrible ways that people have been “let go” by their employers.
  • Adventures in Cat (and Dog) Sitting: What I Learned about Managing People: If you don’t know what your pets have in common with your employees, Whitney Johnson can help you out with that. Why is this comparison necessary? Well if you think about how some people treat their pets (letting them out for walks, feeding them when they need it, belly rubs, petting, etc…) there are a lot of parallels with your employees… Well, there should be. Your employees deserve a good environment to work in, being acknowledged for their hard work, and having engaging work.

That’s it for this week! I hope you checked out the Profit Hot 50 article I mentioned above. Follow Dev Leader on popular 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