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

Rock Star Programmers - 5 Traits I See As Winners

In my heart, I’ll always consider myself a professional software developer.  I began writing code at the ripe old age of 12.  While I don’t write code on a daily basis anymore – the sin of being ‘management’ – I still write code at night to keep my skills fresh and to ensure that I can sit in a room with my development team and understand the conversation and hopefully add value.  While at one time, I considered myself an expert in the languages I used (don’t ask, they are all now ancient).  I realize now that I can still write good code – but because I don’t do it day in day out, I don’t kid myself in thinking that I’m the whiz kid anymore.  I’m not.  I’ve got team members that are extremely talented and I’ll give them praise any chance I get.

So what makes a great developer?

Over the years I’ve watched a lot of developers come and go in the shops where I’ve worked.  Some of these folks couldn’t code if their life depended on it and didn’t last long.  Others made it look effortless – producing code that was simple, easy to read and just seemed to work.  So what made these developers different, what did they do different than everyone else?

Patience

Some programmers get their assignment and without asking any questions start pounding out the code.  They’ll quickly listen to what is needed or skim the requirements and get to work.  They’re dismissive of further explanation, and are quick to say that they know what the users want better than the users of the system.

The best programmers take their time.  They actually read thru both the requirements documentation and the technical designs if they exist, or they’ll spend time interviewing the user to understand what the true problem is and what issue is being solved.  They are not only concerned about what it is that is wanted, but they take time to understand what isn’t wanted or needed in the solution.  These developers think not only about the specific assignment but want to understand how it fits into the whole puzzle.  Are there parts of the system that operate ahead of their piece – what do those parts of the system do to the data before it gets into the code that they are writing?  Are there parts of the system that will need the output of the code that they are writing?  How do they ensure that the data is validated before it leaves their code and is handed off to code written by another team member?

Lifelong Learner

Coasters – they drive me nuts!  These are the folks that think they know everything and that they are better than everyone else on the team.  They scoff at junior developers and will tell them that there is nothing that they can learn from such a junior team member.  The Coasters are forgetting that anyone can be a teacher.

On the other hand, I love lifelong learners.  These are the developers that are constantly pushing themselves to learn new technology, understand how to use the language they are developing in more efficiently.  They are constantly reviewing everyone’s code and are not afraid to take a chunk of code, walk over to the person that wrote it and ask them to walk them thru the code so that they understand what is happening.  They aren’t afraid when someone critiques their code and in fact actively pass their code around to others on the team to be examined.  When you run into them in the breakroom or walking thru the office, they will begin telling you about the new scripting language they are playing with or some new solution/tool/framework that might make the team more efficient.  Give these folks room to play – they will make your team better and find unique solutions to some of the toughest problems you have.

Commitment to Excellence

We know these folks – the developers that quickly write their code and then throw it over the wall for someone else to test.  They’re not concerned about what happens downstream – heck, they’re not even concerned about what happens within the code they just wrote.  They spend more time fixing their code than they spent quickly writing the code – in this instance, speed does not win the race.

Flip that around now.  The best programmers take their code personally!  They view their code as a direct reflection on themselves.  The best programmers will actually create their battle plan prior to writing any code – understanding exactly how they will test what is being created or modified to ensure that it works within the complete workflow.  Reviewing all of the incoming data, understanding what they should and shouldn’t expect.  Reviewing all of the output and integration points and understanding how the data can be manipulated and what are false values or boundaries of the data.  They will write small chunks of code or use scripts to test the code they are creating/modifying.  They are not only implementing unit testing, but are thinking through integration and regression testing along the way and then executing prior to handing off the code.

Passion

Look, if you don’t like your job – find something else to do.  We know these folks, they slouch in, plop down, ignore their fellow team members, don’t offer to help others, won’t bring new ideas to the table, won’t participate in meetings – team or otherwise and won’t do anything but exactly what they're told.  Are you kidding me!

Now, show me someone who is passionate about what it is they do!  Yeah, that’s the ticket!  I love these folks – they live and breathe to be the best coders out there!  They’ll call themselves a geek – and view it as a sign of honor!  They aren’t afraid to tackle the most complex parts of a project.  They find a way to practice their skillset – just like the best musicians.  If they’re given a particularly difficult task, they’ll try 2 or 3 different solutions to find the one that works best.  They are disappointed in themselves when they miss a deadline or someone finds a bug in their code – but they are the first to step up and take critique.  They view critique as a lesson along the way, will actually listen to it and attempt to learn from that criticism.  They will throw themselves at new technology when asked – and in a lot of instances without being asked – so that they can become more efficient.  You’re hired!

Self Sufficient

There are days I’ve pulled my hair out because someone will tell me that they hit a wall and couldn’t get any further.  When I ask them what the issue is, they tell me they’re waiting on answers to clarify some problem in the code or with the requirements/design.  When I ask them what they’ve done to solve the problem, I get a blank stare after they tell me they sent an email out 2 days ago.  Really, you couldn’t find it in yourself to stand up, walk to the other side of the building and get an answer?  Ugh – do I really look like I want to play baby sitter!

Now the best programmers are bull dogs!  They hit an issue and they are tracking down the best way to get the answer.  Sometimes that is tracking down someone internally, sometimes that is looking on the net to find a solution to a particular programming problem, and sometimes that is asking a team mate sitting a few seats away.  They are not afraid to ask questions and understand that communication can be used to solve issues!  If the issue is big enough, they don’t hesitate to escalate the issue – but usually have a couple of different options to resolve the problem.

Wrap Up

These have not been presented in any particular order, but they do represent the traits that I see in the best developers.  They are traits I attempted to show when my main role was to sling code every day and that I hope I still possess in the role that I currently play.

What are the traits that you see within the best developers you have on your team?  Let’s keep the conversation going!
 

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

It's NOT all about you, it's about the Team!

I'm not a success without the people on my team!  Flat and simple - if they aren't succeeding, then I'm failing.  As a leader inside the organization, it's one of my responsibilities to look out for the needs of my team and find ways to make them successful.  I can't guarantee them success every time, but I need to find ways for them to succeed more than they fail and within their failure, I need to recognize that I own some of that failure.

I've seen people that have been great contributors on the team suddenly put themselves in a position where they look like they are going to hit the wall.  I've had to step in-front of them and prevent the smash up that is about to occur.  Sometimes these discussions can be difficult, because they don't want to admit that they are about to fail.  Sometimes there is a look of pure relief on their face when someone steps in and says - hey, I'm here to help.

One of the first projects I worked on after becoming a manager was a fairly mundane project needed within the organization - there were several pieces of the software being developed and one of the pieces was being held up because there was nobody else to work the issue.  I made the decision that I would jump in and work the issue myself.  At this point, my boss asked me why I was working on the code.  I explained to him my logic and he began to ask questions:

• If  you're working on the code - who's going to keep track of all the pieces that are moving within this effort and make sure overall we're on target?
• If you're working on the code - who are your engineers going to escalate the issue to when there's a problem and how will you manage those issues?
• If you're working on the code - who's going to keep myself and the rest of that management team aware of the status, issues, risks and plans?

There were several other questions - but you get the general sense of the conversation,  I was young and eager and for every question he had, I had an answer, me!  My manager made it clear to me that this was not the right answer and that I was going to end up hitting the wall.  I assured him, that I would be able to handle all of it and went on my merry way.

Soon, I began to trip up on myself - at first it was missing a status report here and there, not escalating an issue that needed to be escalated.  Then the impacts grew - I wasn't paying attention to all of the different moving parts and coordinating the delivery.  I hit the wall.  My boss looked me in the eye and asked me what I was going to do to clean it up.  I had failed!  Luckily, he reached out and helped clean up the mess and get the project back on track.  But what he taught me happened after all the pieces had been put back together and the project was again running forward.  He sat me down, told me that this time he had allowed me to fail and had helped me out so that I could learn what not to do going forward!  The next time this happened, if I let it happen, I would need to clean up the mess by myself.

Where to start?  First I learned as a manager, it's tough to be the one in the details and still be the one coordinating everything else that needs to be done.  Two, I learned that sometimes it's alright to let people fail.  Three, I learned that when somebody does fail, you have to be there to pick them up and help them get back on track - give them the ability to learn.

Now in some instances - the failures begin to outweigh the successes and you come to the moment of truth.  Is there a way that I can make this person successful, or have they proven that they are incapable of performing within the role that they've been hired for - a difficult decision.

As leaders - either formal supervisors/managers or informal project managers - it's not enough just to do the tactical parts of the job.  It's essential that we work work with the people we touch in the organization and help lift them up.  Only if we truly give them the tools and skills they need to perform their role and prepare them for more difficult responsibilities in their future, will we reap the rewards and succeed within our own role.

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

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