As a child, I was glued to the television whenever there was an opportunity to watch Star Trek! I loved the show - campy by the standards of today, I couldn't help myself as I wanted to be on the Starship Enterprise as she traveled to the stars. And, yes, my favorite character was Spock - followed closely by Scotty. Spock in may ways spoke to many of us - using logic instead of emotion to solve problems. And when he did let his emotional side out of the box - showed that emotion could and would frequently lead to painful mistakes.
So, why am I using space within a blog focused on project management and applications development to discuss Spock? Logic - use it to succeed within your role. Strip aside the emotion that you feel when confronted with issues and follow the facts! Stay calm, track down the details and use those details to identify the move forward solution.
No project of any realistic size moves from idea to implementation without some sort of issue rising up, ready to take the whole thing off the rails and into the ditch. Some problems are small and others tend decloak themselves like a Klingon battle cruiser to surprise and fire upon your Starship Enterprise! These incoming salvos threaten to overwhelm you, the team and the project. At this point, you can either act emotionally, running around without a plan and make the problem worse. Or, you can act like Spock - use logic to create a plan, execute the plan and overcome the issue.
Planning:
Sometimes with a small issue, you can 'wing it' and successfully manage the issue. That said, the larger the issue, the more likely you will need some type of plan and process to deal with the issue. Leadership in the organization is going to expect you to communicate the issue, progress in finding a solution and then progress against whatever plans are ultimately put in motion to resolve the issue.
There will be wide variety of additional items you will need to manage within the overall effort:
- You may need to setup a research team to investigate how the issue
was missed or what the cause of the issue was so that this information
can be communicated to the management team.
- Additional personnel resources beyond the original scope of effort associated with the project to identify the overall solution as well as assisting in any work needed to implement the solution.
- Additional budget resources beyond the original scope of the effort to cover any additional internal or external resources needed to provide the overall solution.
- Communication plans may need to be put in place to update internal resources, communicate with and manage customer expectations and manage any risk to the overall reputation of the organization.
Each of the above items will require management effort from the Project Manager to ensure that future milestones within the overall effort are adjusted and manged properly; and to coordinate activity between various team members, departments, and outside consultants. All of this will take careful planning, using organizational skills to minimize the impact to the project.
Methodical:
Many times as a Project Manager you are dealing with choices - making decisions about where short-cuts can be taken; making decisions on whether to go with Plan A or Plan B when there is no consensus from the team on which direction to take; sometimes sifting thru agonizing amounts of detail to understand an issue so that it con be communicated to the management team.
As the complexity of a problem increases, the number of details being tracked or managed associated with the issue will grow beyond your minds ability to track them all. You are going to need processes in place that allow you to align the issue resolution within the overall tracking mechanisms in place to manage the project.
- You will need to track new data points within and aligned to the overall project - new milestone dates, budget information, new internal and/or external resources, new equipment that may need to be purchased.
- You will need to realign your current schedule to accommodate any new milestones associated with the new effort. Especially those new milestones that will require current or future activity within your plan to be delayed or altered.
- You will need to ensure that communication plans are executed properly not only to manage internal expectations, but just as important to ensure that customers, vendors, the media and other 3rd parties are kept in the loop.
Your role as Project Manager requires that you have a plan, that you execute the plan and that you manage the expectations of your team members. You need to be the calm within the storm.
Detail Oriented:
Team members are going to be hitting you with lots of information - your job as Project Manager is to sort through the minutiae and ensure that the relevant data is recorded, tracked and used to make decisions throughout the overall project lifecycle. As Project Manager, you will be expected to identify the important pieces of data, communicate that to the team and ensure that the information is available within meetings as decisions are made on the forward progress of the project effort.
Additionally, management will expect that you understand the relevant pieces of information within the flood of details and know when to present that information up the ladder. Many a Project Manager or Manager have failed when they have forgotten to keep the leadership team informed on decision points and the underlying information used to make those decisions. I'm not saying that you should have the expectation that your being micro managed - but when there is an unforeseen issue that crops up, over communication is necessary to ensure that everyone understands the nature of the issue, the solution being implemented and the overall impacts to the organization.
Logical:
You can be angry and frustrated - that however is not going to help you move the ball forward and find a solution. At this point, you need to step away from your emotions and use logic to understand where your at, what data points you have available to make a decision and then make short and long term decisions based on that information. Knowing that you can adjust future activity and decisions based upon additional data points that surface.
Spock would 'follow the facts' to get to the answer - wherever those facts happened to lead him. That's your role! You will be tempted as angry and frustrated team members, management, customers or 3rd parties call you or come over to talk with you. At times, you will want to 'fire back' at the individuals - however, it is better to step back, take a breath and then approach the conversation. Focus on the fact, just the facts! Use logic - it is the best tool you have at your disposal to deescalate the situation.
Mr. Nimoy, you are and were an inspiration to many of us ... may you live long and prosper among the stars!
If you'd like more information on my background: LinkedIn Profile
I've been talking to several different groups lately on how we attract more people into technology fields - specifically Applications Development. If your an employer and you're out looking for development talent - it ain't easy!
Maybe for the larger companies that have offices all over the country and that can pull from multiple pipelines, they might have it easier. But for many small to mid-sized companies that are attempting to build or maintain their development shop - it's tough to source good talent.
Don't get me wrong - if you take your time, don't panic and hire the 1st candidates that show up (even though they don't match the qualifications or clearly will unsettle the team) and force yourself to hire individuals that truly meet the needs of the position and have the personality to fit in with the team, you can do it. The flip side is you loose months of productivity within the team because the position sits open. Now let me state right here - I will take the pain of an open position vs hiring the wrong person into the position. And, yes, I have the scars to prove hiring the wrong person is a bad idea. Trust me, it just doesn't work.
I will not speak for every company, or every geographical area across the United States. We all have our own issues when attempting to find employees. Overall, I think I have a great story to tell prospective employees - from the organization that I work for to the community that we work in, there are a lot of positive things happening. Look no further than the following link if you want to know why folks should look to metro Des Moines area as a place to work and live. This is a beautiful community with easy access to other metro areas and a lot of reasons to live and play right here at home. We have plenty of colleges and universities in the metro area and our K-12 educational system is as good if not better as any other school district in the country.
However, I compete against a lot of companies in the local area for talent - large financial and insurance companies, to small and mid-tier companies - including tech start-ups. The baby boomers are beginning to retire - which is leaving holes in all of our teams. And our companines are demanding that IT shops expand to meet the needs of internal and external users. In essence, we are competing for the same talent and we all need to be honest about where we are going to find these workers and also be honest about the false criteria we have within our hiring process that rules out good people.
Back in the day, many school districts actually had software development classes taught in the high schools. I was lucky, when I was 12 I had a friend show me a teletype terminal (just dated myself) hidden in a small room at the middle school I attended. I was curious and wanted to play around with the thing - not knowing what it could do. Luckily, I had a math teacher that got me an account on the computer that the terminal was connected to and I began to teach myself BASIC. By the time I hit high school, I was able to take formal software development classes using Fortran (and, yep, I've dated myself again). If my memory serves me right, the high school instructor that taught me Fortran also ended up teaching me Assembler outside of class - that was some real fun.
Today, very few K12 school districts have formal technology classes provided to students. Some of the larger schools in the metro area are able to provide them, but many don't have the money and the smaller school districts from what I can tell don't have the expertise or the money.
Well, in my opinion something is going to have to give:
- As parents - we need to stop hitting the easy button! School is to prep our kids for the real world after they graduate. While I encourage my own kids to be involved in sports - it's not at the expense of their education. If there is a tough test coming up - I'll pull them out of practice to ensure that they are ready for the test. We also need to speak honestly with our kids about what careers will allow them to live independently when they leave the house and move out into the real world. We also need to support the instructors that are teaching our kids - that means when they aren't getting the grades we expect we hold the child accountable as well as the teacher.
- At the middle school level - kids need to be given formal opportunities to play with technology both from the hardware and development perspective. We also need to change the way that we communicate these opportunities and ensure that we market these career opportunities equally to young women and young men. Our field is woefully underrepresented by women - this didn't use to be the case and we need to turn this around. If that means we have young women only technology competitions, than we have to think along those lines.
- We need to begin ensuring that every school district has the means to provide technology trade classes to their students. Much like we have trade classes for auto (used to also have for metal and wood - some high schools still do), we need to have trade classes at the high school level for Technology fields. If done right, these students should then be eligible for entry level jobs into the work force.
- Infrastructure courses that allow students to learn how to build and troubleshoot networks.
- Application courses that introduce students to the concepts of software development using scripting languages and progress to more structured languages used by business.
- We need to encourage our State Department of Education to ensure that Computer Science courses taught at the high school count towards the overall Math and Science credit. Some states have even moved to count these courses as foreign language courses replacing Spanish, French or German.
- We need to look at the possibility of software educational boot camps.
I've been looking at these as tools to find developer talent over the
last couple of years. I have yet to pull the trigger, but based on what
I'm reading and hearing, this is going to become a valid tool for many
of us. This is a very compressed educational and hands on environment
that gives someone the basic skills they will need to join a firm as an
entry level developer. Usually requiring 10-12 weeks of 40+ hours a
week to get the student ready and certified.
- We need to encourage and work with our Community Colleges to ensure that their course curriculum matches the needs of the business community - unfortunately, technology changes happen frequently and it's tough for the Community Colleges to keep retooling for the latest greatest fad. We need to encourage the Community Colleges to stick with the bread and butter of what is needed within the local business community - augmented with some of the newer technology. Slow down the pace at which they retool.
- While some of the scripting languages are hot, most business have standardized on Java, C++ and C#. Let's make sure that they are learning the languages that will get them jobs.
- We need to continue to work with our 4 year colleges and universities. Ensuring that their course work aligns with the needs of the business community. These are fine institutions and they provide a much deeper experience for candidates before they come into the workforce providing both deeper theory and the practical how to of applications development.
- As business leaders and technology leaders - we need to make sure we are seeding our technology teams with entry level candidates when at all practical. While it is easy to go out and hire only 'experienced' candidates - we are doing a disservice to the organization by not mentoring our next generation of leaders and subject matter experts.
We have become somewhat complacent because we have traditionally held a very strong lead on the rest of the world. That lead is evaporating and we need to ensure that we are preparing the next generation to continue along the journey.
Collectively, we need to get off our back end and demand the best from our kids and their schools. We need to look at multiple ways to source entry level candidates into our organization and we need to be flexible when we look at how these entry level candidates got their education. The days of sitting back and demanding that every candidate have a four year degree are over.
If you'd like more information on my background: LinkedIn Profile
Off-shore development continues to be a discussion point within many organizations. I've managed teams across the US and had the occasion where I've used off-shore resources. Let me share some of the experiences in the hopes that it helps others that struggle with the model or are questioning whether to proceed with the use of off-shore resources. I won't claim this represents the model to run off-shore development, ultimately, you need to make the decisions that will work within your organization. Hopefully, this will shine a different light on the topic and allow you to gain insight that may help you make the decision to use off-shore development resources or to keep the development on-shore.
First, it is not easy. If you think this will solve issues within your current development lifecycle - don't bet on it. If you're going to seriously begin to use off-shore resources, you better plan appropriately, or you'll pay the price with development timelines that get extended and budgets that creep beyond your expectations. In the worst case scenario, you'll end up rolling product into production that has not been properly tested and vetted.
Some of the breakdowns that my teams encountered in using off-shore resources are as follows:
- Communication - eliminating the natural lag in communications as teams work shifts that do not align.
- Design Aberrations - ensuring the product developed fully conforms to the original design/requirements.
- Coding Standards - putting processes in place to ensure that the off-shore development team followed the development coding standards of our internal teams.
- Quality of Code - ensuring that the code had been properly tested all the way through integration testing with other application silos/subsystems.
- Quality of the Team - ensuring the consistency of development resources applied to projects.
- Product Knowledge - ensuring that knowledge of team was retained from project to project.
The above list covers the major challenges that we encountered. Let me go in to some level of detail so that you can get the flavor of what was experienced and how we handled the longer term needs of the organizations use of off-shore resources.
Communication: Each and every day, without your knowledge dozens and dozens of project decisions are made as developers lean across the walls and talk to each other or see each other walking around the office. My teams have been no different, requirements and designs could change based on a hurdle that needed to be solved and a quick conversation in the hall. Suddenly you have a team separated by multiple time zones - in my case, they had left the office for the day by the time we arrived in the office. If the remote team had a question, or hit a roadblock and needed direction, there was an automatic lag of at least 1 work day. If it was a serious issue, the team might loose several days as communication threads worked their way through email. In extreme instances, we might have some of the remote team stay late or some of the local team come in early to establish conference calls and work out the issues.
Design Aberrations: The standard methodology we used to develop project requirements within the organization wasn't sufficient to support the use of outside resources. Didn't matter if those resources were on-shore or off-shore, our teams were comfortable dealing with each other and could abbreviate how the requirements were documented. There were a lot of things assumed within the requirements that didn't need further explanation because the teams had years of experience working together. This continued to feed through the process as design documents were generated by the team. Suddenly we introduced a team of developers that did not have that tribal knowledge. The results were obvious in hindsight, the off-shore resources built the product to match the documented requirements and designs. The only problem - those requirements and design documents didn't contain the unspoken elements known by the internal teams.
Coding Standards: Some of the products that we chose to develop off-shore ended up needing to be supported by local teams. We quickly found out that the coding standards we had in place were not documented thoroughly and left many items up for consideration. Translation, the remote team was producing code that looked like none of the other code that was used internally.
Quality of Code: The internal teams had many years of experience working together, touching each others code and making the necessary revisions to the code base. Suddenly we had bugs that had been solved being reintroduced into the code base later in the development cycle. Worse yet, we would find chunks of code that were never being executed, yet were loading up the code base.
Quality of the Team: Just as we were getting used to working with one set of developers, suddenly they would be reassigned to a different project and we would end up having to reacquaint ourselves with a new team. To say that this slowed down development and introduced inconsistencies into the code base would be an understatement.
Product Knowledge: As we completed development with one project and started up the next project, we were not assured that the team we had gotten used to would continue on and do development on the next project.
None of this is serious and can be resolved, but you need to think through the engagement up front and take the necessary measures to protect your organization. Here are some of the tactics we began to utilize to minimize the risk in the use of off-shore development resources:
Communication: We required the off-shore company to place one of their resources on-site with our local teams. They became the primary communication point between our teams and the off-shore resources. They sat in on the meetings locally and could catch the small things that needed to be communicated to the off-shore team. They could do the impromptu meetings in the hallway and get that information promptly to the remote teams. Our project timelines included buffers to accommodate the communication lag between the teams.
Design Aberrations: We ended up beefing up our Business Analyst and Architecture teams to create more thorough documentation. Our documentation became much more thorough and attempted to accommodate the things that people took for granted. The architectural diagrams became much more sophisticated outlining all servers touched, all databases touched and were color coded to identify new, changed or removed elements. Design documentation began to reference not only the objects that would be touched, but could go down to the individual methods and parameters when needed.
Coding Standards: We ended up going through our coding standards and documenting much more thoroughly how code was to be structured, how variables names were to be created, what security precautions were to be taken when creating the code, etc.
Quality of the Code: Code created by off-shore resources was required to go through the same
code review process that we used for internal teams. This ensured that
our senior developers were reviewing the code - exactly as would be done
for internally written code and that they could catch issues and feed
them back to the remote team.
Quality of the Team: After some experience with team members shifting, we ended up negotiating with the off-shore company to ensure that we had a core set of developers that would not be reassigned off of the project. This allowed us to maintain some level of consistency within the off-shore team and addressed quality of code, coding standards and communication issues.
Product Knowledge: Similar to the Quality of the Team issue - by keeping a core team of developers assigned to our projects, the off-shore teams knowledge base of our products began to increase and they could begin to anticipate some of the issues ahead of time.
I want to state again, these were experiences that my team had in working with off-shore resources. Other organizations may have different experiences. Hopefully, some of these issues and the ways in which we resolved them will assist you with determining whether you can support the use of off-shore development resources.
I typically do not use off-shore resources unless there is a need to temporarily augment our internal resources to accomplish specific development/project goals. That's a choice that I feel comfortable with based on the particular business needs within the organization. In previous roles, I've had the opportunity to work extensively with off-shore resources. If you're going to use off-shore resources, I highly recommend you pick a couple of small projects and trial a couple of different vendors to establish which one will work better with your current development paradigm. Don't be afraid to switch vendors if you don't feel you're being taken care of - ultimately, it's you that will be held accountable for the delivered product.
If you'd like more information on my background: LinkedIn Profile
Over the last few years I've been moving my teams towards Test Driven Development. If you're not there, you need to be looking at this paradigm. In essence, the following is what you are shooting for:
- Write your test.
- Run your test - the test should fail because the code hasn't been written yet.
- Create the bare minimum of code that will allow the test to pass.
- Continue to refactor the code until you are satisfied - is it simple, have you removed any duplication?
- Repeat - accumulating additional tests until full functionality matches the agreed upon requirements and design criteria.
I've been on this push for a couple of different reasons: 1) The QA Team is spending an inordinate amount of time performing regression tests that should be in the build process; 2) The QA Teams and Development Teams should spend most of their time on new feature/new function testing - not regression testing; 3) Within the old paradigm that we were following, by the time the development team member became aware of a defect in the code, they had long since moved on to other parts of the code and it was not fresh on the mind.
I've recently spoken with several groups of students - some high school and some at the collegiate level - and the one common theme that I have been impressing on all of these groups is that they need to think about testing first. That means while doing the design work and prior to any code being written, they should understand how they will test the code and then execute against the plan.
In a separate session. when meeting with some of the instructors - another individual recommended that the instructors should have a base set of tests created that the students will need to execute against their assignments. The students could do this at any time to get immediate feedback. If an instructor were to pursue this paradigm within their classrooms, I would encourage them to create a portion of the tests, but force the students to create their own set of tests.
Unless our teams are working on a completely new system - there should exist somewhere in the organization a base set of tests that cover the current functionality. It may not be extensive, but it's there somewhere. That's the baseline! No build of the system should happen without improvements to that baseline with your development team increasing the code coverage with additional unit tests that are then included in the set of regression tests the next time that code is touched.
Let's face it, immediately after the code has been written and the developers focus shifts on to the next task, their ability to maintain the code begins to drift. I'm not saying they can't maintain it, but that they will need to spend time re familiarizing themselves with the code and then planning how to make the change. Additionally, you can't guarantee that the next time the code needs to be touched it will be touched by the same developer. By having these tests complete and in the pool of regression tests, you set an expectation with the developer that they can't claim they are complete with the code until all regression tests are complete and they can prove that they have tested against the new feature/functionality of the application.
Really, when it comes down to it, it's about accountability within the development team. They are just as responsible for the quality of the code as are the people working the front end of the project - discovery and requirements, design - and those working the back end of the project quality assurance and the user representatives.
If you'd like more information on my background: LinkedIn Profile
There is a lot of talk across the nation in promoting STEM careers with our younger students. This continues to be an issue that we need to address. More jobs continue to open up within these fields and that trend will only accelerate as the Baby Boomers retire.
Take a quick look at the number of job openings that are expected thru 2022: BLS: Occupational Outlook Quarterly. Let's review the top jobs identified in this report (as of Spring 2014):
- Software Developers - 218,500 openings thru 2022, average wage $92,660
- Computer Systems Analysts - 209,600 openings thru 2022, average wage $81,190
Computer User Support Specialist - 196,900 openings thru 2022, average wage $46,620- Software Developers, System Software - 134,700 openings thru 2022, average wage $101,410
- Civil Engineers - 120,100 openings thru 2022, average wage $80,770
You know what, those are pretty good wages! I recognize that these are not the starting wages, that said, you can see that overall, these are jobs that will be in demand. Students entering into these jobs should see wage increases that will allow them to earn a decent living.
My focus in this post will be careers in Computer Science. While other STEM careers are critical - I'll focus on those that I'm most familiar with, those that have powered my careeer.
Unfortunately, here in the States, we are doing a very poor job of educating our students about what opportunities are available and are not focusing our curriculum to encourage young students to explore the career choices.
Only 1 in 10 of our high schools offer computer science programs for their students (as identified by TEALS). That is a scary statistic - if 9 out of 10 schools can not provide early experiences to students that might be interested in Computer Science, how are we expecting these students to make the choice to pursue degrees in Computer Science. More importantly, if it is this bad at the high school level - what do you think it looks like at the middle school level.
I firmly believe that if we don't find a way that allows middle school students a way to explore these careers early and then do not reinforce that through high school experiences, that we are failing the next generation. More importantly, we are putting the future of our companies at risk.
So, here are my ideas of what needs to be done:
- Our local school boards need to find a way to introduce computer science curriculum into all middle schools. These courses need to count as math or science credits.
- We need to specifically find ways to encourage both young men and women to take these courses.
- Our local school boards need to find a way to introduce computer science curriculum into all high schools. These courses need to count as math or science credits.
- Alternately, some states are declaring that computer language courses would count as foreign language credits.
- Our states need to fund the expansion of STEM exploratory courses at both the middle and high school levels.
- Businesses need to step up and provide volunteers to go into the schools and assist students as they explore STEM careers. Some of this is being done through initiatives like Lego League, but we need to find these types of programs and make them available to every school, every year.
- Businesses need to open up and hire more entry level technology students. I have seen the tide shift to where many companies now only want to hire people with several years of experience. They no longer want to hire newly graduated students and mentor them into the next generation of experts within their company. Or they only want to contract and rotate people in and out every 18 months. That may work for their bottom line today, but it destroys the expertise that they will need when current subject matter experts retire.
And, yes, before you ask, I'm holding myself accountable. For years, I have taken time to regularly talk to high school and college students about career opportunities and what life is like working within the Computer Science field - specifically software engineering. I have volunteered to assist as schools present various tech initiatives for their students.
If those of us in this field don't take the time to encourage the next generation to step up and become the future technology experts, who will? If we don't take the time to encourage our schools to address the educational needs that will drive job opportunities, who will? If we don't take the time to personally lobby/communicate with our state leaders on the need to drive change in this area, who will?
If you'd like more information on my background: LinkedIn Profile
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
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:
- Your direct reports
- Your peers within your supervisors team
- 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
