I’m going to tell you a story about how I almost failed as a manager.  I say almost because it was only because of Bob Smith that I recovered and really understood the error of my ways.    Bob is a factious character because the innocent should be protected.  However, the situation is real and the lesson is a good one that I would like to pass on. 

One of my first experiences managing development teams was an incredible opportunity. I was young, enthusiastic and motivated.  I inherited a team of folks with great capabilities but a relaxed attitude towards owning issues.  I’m positive we were not the first shop to experience this!  During the first few weeks of taking over this team I hired Bob as a replacement for a team member who left just before I took over.  Bob was my first hire.  Bob is an incredible technician.  He knows code, architecture and the urgency of our craft.    

I think I’m preaching to the choir when I say that inevitably there will be an issue in IT.  I, as a young manager, experienced this within two weeks of Bob coming on board.  I remember it clearly.  The guy Bob replaced left a code base and an architecture platform that, well, let’s just say was suboptimal.  I called everyone into a room and said this is the ‘hottest’ issue.  Let’s dedicate all our resources to getting this solved.  I got a lot of blank stares.  Bob however, was the guy on the beat.  Within five minutes he knew what to do, how to solve it and what needed to happen.  I was in love.

We were a young shop and there were about two more ‘major’ issues that came up within the next six weeks.  Each time I leaned on Bob.  He was my go-to guy to fix the issues that the team couldn’t address, with his help we  satisfied the customers and pleased the execs.  Then came the dreaded lunch!  Bob and I went out to lunch and he let me know that he was thinking about leaving the company.  Imagine my face at this point.  Bob was my get it done guy.  However, it was exactly why Bob wanted to go.

Bob had other ambitions.  None of them having to do with fire fighting others misfortunes.  Bob was a team player, but in his words (Bob doesn’t speak the best English so this is the best translation)  he said “I’m always willing help out, but you need to help others know how to win”.  Prolific need I say more!

What I learned from Bob is that teams need to learn how to fail as much as they need to learn how to succeed.  Winning feels good, I think that anyone that’s been a part of a winning team can sense what a winning team ‘feels’ like.  You just know.  Failure is the same.  You just know when something doesn’t feel right.  Winning and losing is intrinsic in our psyche. 

Failure is painful but inevitable in our business, just as much as success is.  The problem is that most people, as a team, don’t know what it’s like to manage through ‘failures’. It’s not natural.   We naturally separate into individuals when we sense failure.  The whole ‘It’s someone else's problem’ is a common reaction.  Arguably it’s a healthy reaction designed to help us cope.  However, in our business, the business of providing technology, it’s a toxic attitude because we can only solve problems as a team. 

Bob taught me that when a crisis occurs hold the team accountable.  The easy way out is always rely on Bob to fix the situation. Bob is not the long-term fix.  The team needs to know what pulling yourself from failure ‘feels’ like just as much as they understand what success ‘feels’ like.  Just like people know what ‘winning’ and ‘failure’ feels like, your team needs to understand what pulling success from the jaws of defeat feels like so they can repeat the behavior each time something goes wrong.  It's like muscle memory!

I have an opening for a Data Warehouse/ Inmformatics manager and two openings for SSRS report developers.  Please contact me if interested.

No Recruiters please!!!

The last few year have been terrible.  It doesn’t matter what industry you’re in, your education level or place of residency.  The latest economic down-turn has been rough on all of us.  However, there are signs of an upturn and you need to be prepared for it.  How do you position your teams to respond and meet the demand of your business?  Getting smart about outsourcing might be the key!

The next upturn is going to present a few realities that you will need to come to terms with.  The first, is that  your company has ‘right-sized’ your organization at some point.  Translation, you have less resources than you did before the bust.  The second is that the economy is starting to pick-up.  Translation, you will lose talent.  The third, and most important, is that your company will want to be ahead of the curve and implement technologies and products so that they can gain the most by the upswing. 

The challenge as an IT manager is how do you ‘ramp-up’ for the upswing?  You will face the challenge of fleeting talent as well as increased demand.  You need to develop a resource strategy that is scalable and forgivable.  So what is the solution.  Outsourcing.

Outsourcing is probably the one word that will have all IT pros see red.  I think it’s a natural reaction giving the recent experiences of most IT pros.  However, now is the time to leverage the ‘right-size’ outsource solution so that you can continue to meet the demands of your company’s IT demands and best position your team.

So what is this mythical outsourcing phenomenon I speak of?  It’s coming to the realization that you don’t have enough team capacity nor the time or energy to meet the current needs.  You don’t want to bring on full-timers that you will have to layoff  when the demand levels off, you owe your employees more than that for sure.  So now is the time to start to develop outsourcing relationships.  And make no mistake.  These arrangements are relationships. 

Develop Level 1 Outsourcing

Phase one of an outsourcing relationship is simple.  Get some contractors in that your team manages.  Not all firms love this arrangement, but guess what, the economy is tough and they will do it.  The benefit is that you can release or add contractors as your demand requires.  You don’t have to lay anyone off, and the vendors begin to learn what your standards are and what you expect.  You can also use this to see what the strengths and weaknesses of each vendor are.  I call this the ‘getting to know you phase’.  The main advantage is that you can increase the capacity of your team without having to hire an FTE.

Develop Level 2 Outsourcing

This level is a bit more challenging and requires you to have a level of trust.  You have gotten to know a vendor and now want to outsource a project because your team just does not have the capacity to complete it when the business needs it.  It is critical that you make this distinction.  This is not about cost savings, it’s about increased capacity.  Your team needs to have tight control, good project definition and good management in place.  When considering moving to this stage I recommend giving a vendor the easiest or best defined project you have.  At this point your success is tied to theirs and theirs to yours.  I recommend managing risk though the statement of work, verifying work with your own QA resources and assigning your own technical resource to oversee the project. 

The best strategy when negotiating this: Fixed Bid.  Why fixed bid?  Fixed bid is a shared risk.  Each party has skin in the game.  They want to make a profit, you want the project completed.  It puts you and the vendor in a shared  risk relationship. 

Develop Level 3 Outsourcing

I know what you are thinking, level 3 outsourcing is complete project outsourcing.  Something I’ve learned through trial and error is not an optimal solution.  Level 3 is all about reducing cost and freeing up resources.  It’s not project driven.  When you get to level 3 you should be looking to outsource the remedial tasks that your full-time staff does day-to-day. Also known as application maintenance.  At level 3 you want to move maintenance to a lower cost resource so your internal resources can continue to spend time managing Level 2 while keeping IP in-house!

The economy is picking up.  Now is the time to start implementing these strategies!

Interviewing technical people can be challenging.  What is the right mix of experience and ambition?  What level of expertise do you need?  I’ve built several technical teams and I will tell you that the ‘magic’ always starts with the core team.  These are the folks that will set the standard for your team.  So how do you find these folks?

Iceberg Test

There are thousands of books out there that discuss interviewing techniques.  All guaranteed to help you find the perfect candidate.   The main issue I find with these techniques is that they are perfectly inept at discovering true IT talent.  So what makes a candidate a great find?  A passion for technology.  This can take many forms.  Some candidates blog.  Some are always learning new technologies.  And others have ‘side interests’, read: side businesses.  

The most difficult thing about interviewing candidates is pulling this information out.  I think most people are taught as young adults or professionals that talking about your external interests during an interview is taboo.  I disagree.  As a hiring manager I want to see that you live, breath and consume your profession.  And for me, finding out about your outside work is pivotal in that determination.

This is how I came up with the iceberg test.  Based on my experience a solid technologist will only have about a third of their relevant experience represented on a resume.  The challenge is to find out if there exists a layer of experience that is not represented.  If you have the good fortune to come across a technologist that passes the iceberg test I would highly recommend you seriously consider extending an offer.