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

Estimates - The Buck Stops with You!

Why are people so uncomfortable making a decision?  I admit I scratch my head frequently at some of the issues that land on my plate because someone was uncomfortable making a decision – or because they feel they haven’t accumulated enough information.

This is not a phenomenon unique to my current organization.  I’ve seen it across most organizations that I’ve worked in.  Managers have engrained into people that they are not allowed to make decisions and that they must review everything prior to anything getting done.  YIKES!  And then we wonder why people fail!  Better yet, we wonder why people leave us and move on to a new job – leaving us to spread the workload around to others on the team.

Look, I won’t claim my teams are exempt from this pattern.  But I do try to encourage people to think through problems they are facing and if they are unsure of a direction, at least bring options into the conversation when we sit down to have a discussion.  This at least allows me to see that they have thought through the problem and are attempting to address the issue.  Usually through conversation they’ll come to some type of a conclusion, thank me for the discussion and head back out.

I think where we struggle the most within my current teams is getting people to make estimates on project activity.  This is a personal decision by team members measuring how much work they will be responsible for against requested project activity.  When we first introduced this concept, there was a lot of push-back.  And to be frank, there were a lot of errors in the initial estimates.  But over time, people have grown more confident and are estimates are aligning better with the actuals that we measure over the life of a given project.

We go through regular training with people that are new on our teams.  It really doesn’t matter if they’ve been in development or whether they are new to the ropes.  Most developers have never been trained on how to produce reliable estimates.

So how do you pull together an estimate – well, for one thing, it’s different depending on what stage of the project you’re in: 

1. Discovery Phase: Usually estimates at this stage are done by someone within the management chain along with senior level technology resources.  How?  Well, the truth of the matter is the project scope is looked at in comparison to other projects that have been completed that smell like or look like they have similar impacts.
2. Requirements Phase: Typically this is a minor refinement of the estimate that was given in the Discovery Phase.  Any changes to scope are accounted for and typically there are additional details highlighted that point to previously unconsidered impacts.
3. Technical Design Phase: Now we are putting some meat on the bone.  At this point, technical resources have engaged and identified impacts across current systems/application silos and have also identified where new functionality must be created.  Along with the technical estimates business teams have assessed impacts to current and new processes.  Between the two paths, the full project estimate is considerably more accurate than anything that was put together in the first 2 phases of the lifecycle.
4. Development Phase: Some organizations perform the final detail design in this phase.  If so, this is the last chance to update those estimates both from a technical and business perspective.  This should allow the resources that are going to do the actual work to review the technical designs, identify the specific chunks of code or the business processes that are going to change the final say in what amount of time is necessary to complete project activity.

Rules of the road when it comes to performing estimates:

1. If you’re implementing new technology into your current technology stack – maybe you also need to set aside time to install and integrate the technology.
2. Don’t forget process changes.  Sometimes these changes can be just as critical to the project timeline as the technology changes.  Don’t underestimate the impacts these can have across your teams.
3. Don’t forget testing – and I’m not just talking about QA.  I’m talking about Unit Testing, Integration Testing, Parallel Testing, Performance Testing, Regression Testing, New Feature/Function Testing, and UAT Testing.
4. Don’t forget implementation planning and actual implementation activity.  While the universe may have been created with a big bang – in most instances you are going to see implementation activity spread out over a period of time.  Some implementation activity begins before the code touches production, and some activity happens months after the code is in production – you need to account for all of the activity.
5. Don’t forget to provide a buffer for 3^rd party activity.  I have yet to see a 3^rd party engagement go off without some type of change that has to happen.  The initial timeline provided for the engagement never usually is achieved.

Items for consideration when building the estimates:

• How many screen modifications need to be made?
• How many new screens are there in the project?
• How many web services need to be modified?
• How many new web services are there in the project?
• How many reports/data extracts need to be modified?
• How many new reports/data extracts need to be created.
• How many tables/stored procedures need to be modified?
• How many new tables/stored procedures need to be created?
• How many 3^rd party apps need to be touched?
• How many new 3^rd party integration activities are needed?
• How many processes need to be modified?
• How many new processes need to be created?
• What infrastructure changes are needed – servers, server types, routers, switches, security devices?
• What new infrastructure pieces need to be installed – servers, routers, switches, security devices?

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

This by no means covers it all, but points you in the right direction.  Now I’ve heard some people say that in an Agile process you don’t need to worry about this.  Yeah, right.  Trust me, someone in the organization is telling the CFO what this thing your building is going to cost – how many 2 week iterations it’s going to take to get full functionality.  If you’re not responsible for making those conversations happen today – you will be at some point.  Better to start figuring this out know, before you’re asked to provide that first estimate.

Realize that you’re first efforts are going to be wildly off base.  Don’t be afraid to tell your team that you’re giving them time to get better at creating estimates.  This means when they’re wrong – it’s a conversation not a point against them in their annual review.  Use each estimate as a coaching opportunity when the final numbers come in – what they did right and what didn’t look so good and how do we make it better.

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