Recapturing our Youth!

This has been an interesting period in my life. My wife and I recently moved our youngest son out of the house into his dorm, so that he could begin his college experience. It was a really incredible day, seeing his excitement and watching him and all the other kids in the dorm move in. Yes, we were busy setting up the room and getting all of his stuff tucked away. Yet, while all this was occurring kids were wandering the halls beginning to meet each other. The excitement was visible, everywhere!

Over the last couple of weeks, he has made it a mission to visit each of the floors in his dorm, using a Frisbee to start up conversations and get to know the people he now lives with. He has wandered into other dorms in an effort to get introduced to more people and build his social network. He and his friends have introduced themselves to people tailgating the football games and expanded their social circles. He seems to be on a mission to get to know as many people as he possibly can – yes, he thrives on social experiences.

Looking back at my own experience as I made the transition from home to college, I remember the fear, the excitement and the fun of leaving home, meeting new people and having new experiences. It got me thinking about how change is viewed in the office, let’s just say it is not necessarily a positive within our teams.

Let me walk thru a recent experience – over the last year we have been introducing the use of Kanbans as a tool to visualize enterprise project activity across the organization and within my teams using team stand-ups to talk thru the tactical daily promises. Our daily stand-up meetings are focused on simple communication – what did you promise yesterday/did you deliver, what roadblocks are you encountering and who needs to jump in to help remove the roadblocks and what are you promising for tomorrow. Can we move the card on the Kanban? Yes, we are crawling before we walk, walking before we run and running before we try and leap. These are things that many folks within the organization and within my teams have advocated over the last several years.

We are not fully Agile, not sure if we will ever get there, but we are trying to use some of the tactics within projects where it makes sense for us.

What I find interesting is the pushback we have received along the way. I was expecting some of this, but was surprised when some of the very people promoting Agile techniques began to resist the actual implementation of some of these techniques. Some of it came down to – well if you aren’t going to implement and adhere to the entire Agile principles, than how do you expect me to get onboard. Other times it came down to, well I’m not really comfortable trying this in-front of other people.

I get it, we hate change. But when did that shift occur? Again, I look back to my sons as they grew up. They constantly were experiencing change, each year asking to take on new responsibilities. Tackling new topics at school, meeting new teachers, being a part of school sports, taking on roles within the student council. Outside of school, trying various sports when they were younger and then adjusting to changes as they progressed with their athletic talents. Sometimes taking on leadership roles, other times acting in support roles. They grasped for these opportunities, not expecting failure and looking for the next challenge.

Yet, somewhere in our path to adulthood, we start to resist change. We like the stability of knowing what it is we are doing, what comes next and who does what. The funny thing is we talk about change, until it happens to us.

Ultimately, we need to be agents of change for the companies we work for today. In the past, there were periods where businesses did not need to worry about rapid change. That dynamic is no longer true, businesses must continually evaluate the products and services that they are providing, the competitive pressure of local and international competitors. If you’re not constantly ensuring that you are serving your customers, your customers will walk away.

I encourage you to recapture that spirit of youth where you wanted change. Where you weren’t afraid to accept change. If our businesses are going to succeed, we need to continually change to adjust to the needs of our customers.

If you'd like more information on my background: LinkedIn Profile

Staying Out Of The Weeds!

As a manager, you can’t be successful if you are always injecting yourself into the tactical decisions being made within your team! This is called micro-management and will demoralize your team members and sooner or later, will drive your best team members out of the organization. Turnover is expensive and makes you less effective as a manager.

So why is it we as managers struggle with this? Why do we keep injecting ourselves into decisions that don’t need our input? Don’t read on if you don’t want to look in a mirror.  

One word – fear!

We jump to the conclusion that our assessment of the situation is unique, that only we can solve the problem and that if we don’t provide direction to the team that they will fail. I hate to say this, but if you don’t trust your team to make the tactical decisions, than you’ve hired the wrong people, you’re not mentoring them properly and you’re not providing them a path for success.

Most managers work their way into management by showing success as an individual contributor. When they make the leap into their first leadership position, they continue to think as an individual contributor versus taking responsibility and delivering as a team. Over time, great managers figure out the change and begin to operate differently. Unfortunately, there are some managers that never figure this out and not only harm their own team, but harm the extended team. Ultimately, this can lead to breakdowns  that impact your customers.

So, why do we need to break away from the detail? Shouldn’t we ensure that the team is successfully delivering against the active projects? Well, yes, you need to ensure that the team is delivering against active projects and work, but that doesn’t mean you have to manage the blow by blow of every activity underway within the team. Your primary role as a leader of the team is to remove roadblocks before they impact the team and to act as an escalation point when the team hits a roadblock that they are not able to overcome using standard processes and procedures.

Removing roadblocks before they impact the team - say what? Yes, as the leader of your team, you should be looking at the status information being fed to you and looking at patterns that indicate trouble may be on the way and looking for ways to mitigate those issues. This means you have to correlate the information being fed to you and looking out in front of the team. Sometimes this is listening to the risks and issues being identified by the team, sometimes this is seeing a pattern being reported by multiple sources within the team, sometimes this is listening to folks outside the team that will be impacted by the work product. However you receive the information, it is your job to work ahead of the team and resolve the issue so that they can continue to deliver to the department, the overall organization and your customers - internal and external.

Additionally, when they come to you with an issue that can not be resolved within the team, they are looking to you to pave the way forward. You need to reach outside of the standard silos within your organization and outside the organization to find solutions that allow the team to get back on track and deliver. Sometimes that is going to require you to think outside the box and change the parameters - your job is to find a win, win, win situation. A win for the customer - internal or external - that will rely on the end product from your team, a win for the organization by staying on time, under budget and with the necessary quality constraints, and a win for the team by giving the success they seek.

Nobody on your team consciously wakes up in the morning and makes the decision to fail! These folks are working to make their dreams come true, to care for their families and to make a difference. Your job is to give them the opportunity to succeed.

And I’m not saying, you’ll always succeed at removing the roadblocks. But your team needs to at least see you making the effort to help them find success. They want to know that you’re in it with them.

Being a leader of your team is not easy! But the more your stay in the details and forget about what your team really needs from you, the higher the risks are for their failure and ultimately your failure.

I’ve worked for micro managers. It’s not fun! They prevent success and they drive good people out of an organization. Look in the mirror and ask yourself, what am I doing today that will help my team succeed?

If you'd like more information on my background: LinkedIn Profile

Agile? Waterfall? - Pick Carefully or Pay the Price!

Managing projects across an enterprise is an art as well as a science. There are several well known paradigms used by organizations across the world - waterfall to agile with variations in-between. I have always told those that have asked that there is not one silver bullet to magically solve the project management puzzle. In fact, my recommendations to people have always been to create a project management paradigm that fits the culture and needs of the organization.

My teams work in an industry that is heavily regulated by state and federal agencies and also must conform to several industry governing entities that set standards within the payments space. Many of the projects that we work on are implementing standard interfaces between the various payment networks, acquirer, issuers and other players within the financial industry space. Implementing these interfaces is a technical exercise with very little to no user interface. You either get the spec right or the money doesn't move. These initiatives really are not setup to be run utilizing agile techniques.

Now, let me shift over to some of the other initiatives we run within the organization. Our mobile and internet applications. As you can probably guess, these applications have significant user interfaces. These project efforts can utilize and benefit from agile techniques that can give our 'user representatives' much quicker access to potential solutions as well as drive increased cooperation between the development, user and quality assurance teams. This is a place where our teams are experimenting with agile techniques as a way to accelerate delivery through the development channel.

One organization utilizing different project management paradigms based on the unique needs of the initiative!

I'm running at this from two different directions at the same time:

1. I'm working with our project management organization to review our overall defined lifecycle to recommend changes that will allow projects that might benefit from being run utilizing agile techniques to take advantage of a slimmed down process.  We still need to figure out how to satisfy the documentation requirements of the various state/federal agencies and industry governing bodies, but overall, they are supportive of our desire to create multiple lanes that can be managed differently based on the overall risk of the effort.
2. I'm encouraging our project managers and team members to challenge the process. When working any individual initiative within the overall portfolio to make recommendations to skip various project artifacts, project steps or entire slices of the overall project lifecycle. The key is to document the decision as to why decisions are being made to skip certain pieces of the lifecycle based on risk and impacts to the overall effort.

This is what works in the enterprise that I currently work for. 

On a regular basis, I have to sit across the table from auditors and prove to them that all of the appropriate documentation has been generated. That there is traceability though the project effort from requirements, through design and testing. I have to show them our implementation and fallback plans as well as prove that those plans were followed during actual implementations. Our auditors will randomly pick projects and then go through all of the documentation and measure it against the documented lifecycle to ensure that it's all there. If something is missing, there has to be proof - either through project meeting notes or via change requests - that show the decision was made to skip the document/project step(s). This proof also needs to discuss the risk to the product, the enterprise, our financial institutions, acquirers and/or processors. It is the goal of our project management organization to manage these risk issues and ensure that we are safeguarding our ability to process payment transactions and move money within the payments space.

In past lives with other organizations I've run the gamut from running lifecycles that are even more formal than the one my teams currently use to running very informal lifecycles similar to the agile paradigm. The key is understanding the culture of the organization, the risk tolerance within the organization and the  time to market pressures within the industry.  As leaders within your organization, it's your job to discuss these issues and build processes that match the particular needs of your organization, manage the risk to the organization and your customers and build a project lifecycle paradigm that can deliver.

If you'd like more information on my background: LinkedIn Profile

Picking your own Path!

I’ve been around the block for a while now.  Later this month I’ll turn 51 – which means I’ve seen all sorts of things during my career.  I’m lucky – I love what I do and I knew I wanted to be in software development very early in my life.  I touched my first keyboard when I was 12 and began programming in Basic on a DEC PDP 11/70.  And if that alone doesn’t date me, my first programs were created on punch cards and teletype terminals – yep a keyboard with green bar paper running through it that would physically type out the commands entered and responses would come back and print on the green bar paper.  The smartphone I have in my pocket has significantly more power than that first computer I used.  My Nana always used to joke that I was going to fry my brain working on those ‘computers’!

I also knew at a young age that I eventually wanted to be in management.  I had grown up watching my dad run various companies – some failed, others were successful.  While I was in high school, my dad started the final company that he would run – it became very successful and provided him with years of enjoyment until he retired several years back.  Exposure to these companies and the environment in which my brothers, sisters and I grew up in made me realize that at some point in my life I wanted to be in a leadership position – I wanted to run the world!  If I had only known then the growth I would need to be in the position that I hold today!

So why am I rambling on about my early career?  Well, at one point, I had several people attempt to convince me not to move from development into a management role.  I was reminded of this recently because someone that I’m acting as mentor to, is having the same experience.

Moving into management is tough for someone who is in a technical role.  I’m not saying it isn’t tough for other professions – it probably is.  That said, I’m speaking from the personal transition I went through.  I was used to being the one in control – at the end of the day, I could look back at the success I’d had that day pounding out the code.  I was good at what I did – I liked the tough technical problems and my managers relied on me to solve problems.  I absolutely enjoyed being a developer – it was fun, I got to solve problems, I got to play with new stuff that nobody had ever seen, I was recognized for being a person that could just get stuff done.

Eventually, I got to the point where I decided I wanted to transition into a management role.  As I began to tell people that management was something that I wanted to try.  I got feedback from all over the place that I should just stay where I was at, to eventually become a lead or an architect.  Many folks had an opinion to share and staying technical seemed to be the theme behind most of the comments.

Well, for me, it came down to what I wanted not what other people wanted for me!  This is important; you can’t let someone else determine your path forward.  If you know what you want to do with your career, then you have to make it happen.  You can blindly sit there and wait for someone to notice you and maybe give you the opportunity, or you can take proactive steps that will get you into the position you want to be in.

I recently sat down with someone who is contemplating making a similar move in their career.  We had previously discussed this “change” in their career and I know that the individual has communicated with their boss about finding a path between their current role and into a management role.  This individual than began to tell me of all the feedback they were getting from all over the place on why they should stay in the role that they are in.

I let this individual pour it all out on the table.  Then I asked them, "who cares what everyone else wants, when you look at yourself, what is it that you ultimately want to do with yourself?"  Now, I fully recognize that this individual is really good in their current role – and I mean really good.  That said, how happy are they going to be in the future if they at least didn't try?  This individual didn't hesitate, looked across the table and said, “I know I’m meant to be a manager!”  My reply, “Then why are you letting other people create doubts about what you can become?”

I have no doubt that this individual will experience some challenges moving out of the role they currently play and into a management role.  I also have no doubt that this individual will be successful in either role.  I also know the people this individual works for will provide the support needed to transition into the new role – they've done it with other folks on the team!

Sometimes you can’t listen to those around you and you need to chart your own course.  Don't be afraid to make a change and when you make the decision - proactively take steps to make it happen!

See more about my life in technology via: http://anidea4today.blogspot.com/

Practicing What We Preach …

This week, I got a small dose of humble pie from our CIO.  I was in his office discussing the difficult time that one of my teams was having filling a key position.  Finding someone is critical to the success of this team and it has been difficult finding candidates that would be able to come in, hit the ground running and make a difference.  We have key criteria for this position, and I’m not willing to budge – this is one of those times where I don’t have the luxury of training someone, I need someone with a specific skillset and experience.

Before everyone goes all crazy on me for speaking out both sides of my mouth, I normally utilize a very aggressive internship program to fill open positions within my team.  It is rare that I hire experienced candidates.  When I do, I am very specific about what I am looking for and I stick to my guns.  I won’t hire someone just for the convenience of filling the role, I will wait until I find a candidate who fits the needs that I have and that be a net positive for the team.  I’ve bent in the past when I felt I just needed to get a body in the door, and it’s a painful experience.

So, then, let’s get back to the story.  I’m sitting in-front of my boss – our CIO – explaining what steps I’ve taken and where we are at in the process.  He’s letting me vent and as we get close to wrapping up this part of the discussion he asks a simple question, ‘Have you considered hiring someone remote?’

Whack – right to the center of the forehead!  Ok, so you need to understand for the last several years, I’ve been the most vocal proponent inside the organization to allow our team members to work remotely.  We have successfully introduced it into my teams and this has slowly crept into a couple of other areas of the company.  This has been allowed in a very limited fashion, but has proved to be successful enough that a key member of our team moved to another state and organizationally, nobody questioned his ability to continue working for us when he asked if he could do so prior to moving.

Additionally, via an acquisition several years back, one of my teams is split geographically with the manager located at our main facility with half of his team and the other half all working in disparate locations across the southern US.

So there I am the biggest proponent of getting people to work remotely sitting there in front of my boss looking like a fool! Organizationally, we are ready to expand this program.  In fact our COO has recently spoken about the need to show flexibility in where our teams are located.

What could I say, but, ‘You’re right! I guess it’s time for me to step up to the plate and take the next step and push this program forward!’

As leaders within an organization, we have to remember the things that we are fighting for and when given the chance, we need to implement those changes into the organization.  Our bosses expect it of us and we expect it of the people that report up through us – we need to remember, the same rules apply to us.

If you'd like more information on my background: LinkedIn Profile

Dysfunction within the Team - Breaking down the barriers!

Sometimes I'm left surprised when an issue hits my desk and I begin to work backwards to find out what happened.  In too many instances, I can trace it back to follow-through.  Someone in the organization knew something, or was assigned to do something and for some reason forgot.  What's even more irritating is when I'm the guilty party!

Recently, I was rightfully called out by one of my peers for not communicating a decision impacting a critical project out through the organization.  She had every right to call me out on the lack of communication.  It was my error and I could do nothing but agree with her and acknowledge the failure.  I like to pride myself on the fact that have strong communication skills and working relationships with my peers, and so I take this one personally.  There are many excuses that I could use - I'm too busy as we move several key projects into production ahead of our year end production freeze; the Project Manager should have communicated that out to the team.  Ultimately, I made the decision and I had the responsibility to communicate the decision across the organization - especially when that decision was going to put pressure on other teams across the organization.

This is not unique to myself.  As I began to explore at the beginning of this post, too often I look at the root cause of an issue and it all goes back to someone knew and didn't think to share that knowledge.

I recognize that some of this is human nature.  In the heat of the moment, decisions will be made that we believe will move the process forward and get the entire organization closer to the end goal.  While that may be the case - follow-up is critical.  Let's face it, we've all sat on the receiving end of some decision that made our lives miserable.  We've had to deal with the fallout when that information comes at the last minute.  I will be the first one to step up and call someone out when they do that to myself or one of my teams - it's only fair that I take the feedback when I'm the one causing the problem.

To allow this type of honest feedback - you need to be willing to trust the teams you work with on a daily basis:

1. Your direct reports
2. Your peers within your supervisors team
3. Your peers across the organization with whom you deal with on a daily basis

One of the best books that I've read on this topic was written by Patrick Lencioni, "The Five Dysfunctions of a Team".

This book leads you through a scenario of how a group of individuals that didn't work or trust each other was transformed into a highly functional team.

I was first introduced to this book, by my current boss - our CIO.  It was the first thing that he wanted me to read after I was hired.  In fact, he sent it to me before I even officially started.  It is now one of my favorite books.  I in turn have required all of my direct reports to read the book.  I encourage my team to be honest with each other and to hold each other accountable in their daily interactions.

We have been hired for a purpose.  We are here to make a difference, to move the ball forward.  That means holding ourselves and others accountable for the deliverables that people throughout the organization rely on so that they can do their job.  We must open ourselves up to others, understand the story that is driving their actions and be prepared to receive open and honest feedback when we fail to live up to our commitments.

Don't get me wrong - this isn't a directive for you to walk around the building pointing fingers at people and telling them they're not doing the job - chances are if you did you'd have a line of people at your desk telling you that you didn't do your job.  What you should do is be willing to engage in a positive open communication.  Explain what you are seeing - you may not have a full understanding of the situation and be prepared to change the direction of the conversation based on what you hear.  If the person truly is responsible for failing to deliver, than it's up to you to find a positive way to work with the person and manage the situation.  Help them help you!

If you'd like more information on my background: LinkedIn Profile

Leadership - Getting Beyond Management!

Are you managing or are you leading?  The two are very different and if you're not leading, you shouldn't be a manager!

Managing is handling the tactical day to day activity within a group of people.  Ensuring that milestones are hit, coordinating activity between your team and other teams, reporting progress, etc.  In short the manager maintains the status quo - acting within the defined processes to keep the business moving.  They manager accomplishes activity due to their authority.

Leading means changing the dynamics to get the best from the processes and people.  A leader inspires the people around them to effect change.  They can establish a vision and know how to tap into individual team members to get them to see the vision and how they can contribute to the overall vision.  Leaders instinctively know what motivates an individual within the team and can appeal to that individual to use their strengths to close the gap between today and where the leader wants to be tomorrow.  Leaders are focused on the longer term vision.

I freely admit that there are moments in time where I must manage - stepping out of my normal role and acting in a more tactical fashion to help the team push something across the finish line.  This isn't a bad thing, and to be quite honest I think as a leader sometimes you need to do this to ensure that you understand what is really happening within your teams.  I also, sometimes by choice, make the decision to drop into meetings I normally would not attend - project status meetings, implementations, integration test sessions.  Not only do I get the benefit of getting to know some of the team members I would otherwise not interact with on a regular basis, but it also gives me a temperature of what is really happening within various projects.

However, my daily focus is, and should be, at a different level within the organization.  My job is to look ahead of the teams and remove roadblocks.  Understand processes that are not working and change those processes.  Identify when changes in the business may require organizational changes within the teams that I manage.  Identify opportunities within the industry and find ways to get ahead of our competitors.  Find ways in which we can change that will improve the experience of our customers.  Working with our Human Resources team to build pipelines to talent pools so that we can fill vacancies or know where we need to go to find resources when we expand our teams.  It's also my responsibility to look beyond the tactical needs of the organization and create the vision for my part of the organization.  Where do we need to be and what and how do I change things to get us there - then driving that vision down and through my organization.

When I first moved into a management role -- I figured my job was to be the tactical expert.  Help my individual team members get stuff done.  Now as a Vice President, I still need to be in tune with my team members and help them get stuff done, but along the way, I've learned being a manager/leader is so much more.

I want my managers to be leaders within their teams and within the organization - no, they don't necessarily have the influence that I have to effect change, but they can lead and drive change within their teams and the processes they interact with/manage:

1. Managers are the closest link to individual Team Members.  They need to be driving the growth of each team member.  One of the mantras that I have within my teams is that you can't get promoted to the next level until your doing the job of the role you want.  In other words, if you want to move from a Software Engineer I to a Software Engineer II, you must demonstrate you can perform the duties of that new role.  It is the Managers job to establish a growth plan with the individual Team Member and guide them/mentor them so that they can see that promotion.  I ask each of the managers within my team to establish individual learning plans with each team member and constantly work those plans with the team member.
2. Managers see the reality of the process works versus the theoretical process that was defined.  I encourage each of my managers and direct reports to constantly provide feedback on what is working and what isn't and most importantly, if they think it is broken, how do we change the process to make it work better.  Even better, if they are working a project and want to try a new way of doing something, let's talk, give it a whirl and see if it gains us anything.
3. Managers are the actual touch points between their department and other departments, I expect them to drive the relationship and identify how to improve communications between not only the departments within my organization, but departments reporting up through my peers.  It is an expectation that they act as a role model to their team members in showing that we can establish positive working relationships between departments - that doesn't mean we always agree, but that we find a way to move the conversation forward in a professional and positive way.

This isn't meant to be an exhaustive tale of how I see my management team playing within their roles, more of a prime to get people to see that they can play more than a tactical role.
 
I once had one of my bosses tell me, "I don't know what it is you do, and quite frankly I don't have the time to figure it out.  When you need something, tell me who I need to talk to and what I need to say."  Was this the worst person I 've worked for, no.   Did I have any respect for this person, no.  While he had the title of Director, he didn't mange, nor did he lead his organization.  He came in in the morning and sat behind a closed door - rarely interacting with any of us.  Luckily, he was gone within 6 months - the company had seen fit to move him into a different role.  I left the organization shortly after that, but have never forgotten those words.

Are you being a leader for our teams?  Are you setting the table and letting people within your organization lead where they can?

If you'd like more information on my background: LinkedIn Profile

On-Boarding - Skip at your own peril!

Once you’ve place that offer out there and the candidate of your dreams has said yes, it’s time to make sure that you smooth their way on board.  You can either let it happen, or you can MAKE IT HAPPEN!

Through previous postings, you’ve probably divined that I’m all about process and on-boarding a new team member demands your attention.  This is the opportunity to show your new team member that you care about them and you want to ensure that they have a comfortable entry into the team.

Most people, no matter how experienced are going to feel some level of discomfort as they take on a new role.  There are new people, unfamiliar places, processes that they’ve become comfortable with will need to be thrown out, the path to get decisions made will change, and the politics of the new place are unknown.  This can make for a very uncomfortable period and can ultimately make the difference of the new team member staying with your organization or fleeing back to somewhere where they are comfortable.  I’ve seen it happen – someone comes in and a few months later is gone.  When you ask why, they say, ‘I just never felt like I fit in’.

First – make sure you’ve sold the job that exists!  If you want someone to run screaming from the building, hire them based on some fantasy version of the job and then stick them with reality.  Not only will you burn bridges with that person, but they’ll tell everyone they know what a horrible place your business is and how incompetent you are.

Next – once they’ve said yes, welcome them to the team.  Follow up the official call with another call a couple of days later, congratulate them on taking up the new role and let them know you’ve already begun planning their first few days in the office.  You can tell them that the team knows about their coming on board and that the team is excited and is looking forward to meeting them.

Now comes the real work – actually build an on-boarding plan for the individual.  This plan should include the following and cover the first couple of weeks:

1. Key contacts for this person and their contact information.
2. Time to tour the facilities and show them where they’ll be spending most of their time.
3. Introductions to fellow team members.
4. Introductions to key contacts.
5. Introduction to your boss.
6. Setup meetings for 1-on-1 time with key people they will work with.
7. Setup meetings for 1-on-1 time with yourself (their manager).
1. These should be daily – initially set for an hour so that you can bring them up to speed on the role that they’ll be playing, then as time goes on these meetings can be shorter, just a touch base to answer questions about people they are meeting, processes they are unfamiliar with, etc.
8. Setup time for training
1. HR training
2. Department training
3. Job specific training
9. Time to show them where they can find key information on your intranet
1. Team documentation
2. Team standards and processes
3. Company information you feel is important
4. Standard training material if available
10. Any other items that are critical to your environment and team

I’ve never been told by a team member that the on-boarding process was not welcome.  Early in my career, when working at other companies, I had been told that the lack of an on-boarding plan made the team member uncomfortable.  Well, lessons learned.  I hadn’t been shown then and didn’t know what a proper on-boarding plan was and what it could do for the new team member.  I took time to learn and over the years have been involved with companies that were good and companies that were bad at on-boarding new team members.  

When done right, I’ve even had employees compliment me on the on-boarding process.

If you'd like more information on my background: LinkedIn Profile

I Can't Find The Right People - Yeah Right!

I've had several discussions lately with different groups of people about hiring people.  I'm somewhat surprised at the attitudes of some of the decisions being made or expressed in these discussions.  Here are some of the comments I've heard:

1. We'll only hire people that have x years of experience.
2. We'll only hire people that can prove they have experience using xyz framework.
3. We'll only hire people that have a Bachelors degree,
4. We'll only hire people that have a Masters degree.
5. We'll only hire people that are experts in programming multiple languages.
6. We can't afford to hire newbies, it's too distracting.
7. We need programmers who also have experience as system admins?

Maybe we don't have a shortage of qualified applicants; maybe we're being too picky!  You want 7 years of experience, but you won't consider an applicant with 5 or 6 years of experience, really?  Someone can demonstrate that they know how to code and can discuss in detail their contributions to sophisticated development efforts – yet they don’t have a degree and you won’t hire them?  Your organization uses some hot off the press framework, or some framework that isn’t used by 90% of the developers breathing – yet you won’t hire a skilled programmer that has a track record of learning new languages frameworks and give them a few months to come up to speed?  You find a candidate that can develop is several languages – but is missing a key scripting language that your company uses, and you think that passing up this individual because you can’t afford to give them a little time to learn the scripting language – and this is a good idea?  You don’t want to hire new developers right out of college because you can’t afford to distract your staff – meantime, they’re working 70 hrs a week because nobody is there to handle the simple stuff or address the tickets being opened because of errors in the production environment, great choice!

As hiring managers, we’re supposed to be taking into consideration the long term needs and health of our teams.  I find these statements be short sighted at best.  Hiring inexperienced programmers into the organization provides several benefits that we need to be aware of and fight for:

1. They can take over the lower level complexity tasks that do nothing more than distract the more highly paid resources.
2. They can handle production problems that act as a distraction to the entire team.
• Side benefit – this forces these younger developers to learn the ins and outs of the systems that they are supporting so that they can transition into the development team at some point and take on more complex development tasks.

Part of the problem is we are relying on automated applicant tracking systems that filter out everything but an exact match with all of the keywords/buzzwords that we created for the job description.  These systems don’t allow us to find those gems that we can bring into the organization and grow into the next superstar.

How many times have you gone out and hired some superstar, just to have them leave 2 years later?  Sometimes these folks keep moving around because they know they can keep getting a bump in salary.

The real key is to understand the qualities of the people that currently work in your environment.  What makes them stay?  What makes them successful?  You then need to really hone your job descriptions to describe the type of people you want in the organization.  Then you need to adjust the applicant tracking system.  Stop filtering candidates out on skills and find ways to identify candidates based on the real traits you need in the organization.

If you’re a small company – do you really want to hire someone that has a track record of only working in large organizations and has a history of job hopping?  If you need developers that need to be able to meet with non-technical users – shouldn’t you be looking for a developer that has a track record showing that?

I’ll go further – sometimes you need to forget about finding someone with 5 years of experience and focus on finding an entry level programmer that displays a passion for learning, knows how to communicate, has local connections and will become the next rock star in your organization. 

Look at one point, none of us had experience.  Remember how excited we were when we got our first job?  Remember how we tore into any available documentation to learn?  Remember what we felt like when we moved our first code into production?  Someone, at some point, reached down, put their hand out and gave you a chance.  Now it’s your turn!


If you'd like more information on my background: LinkedIn Profile