I Wish I Knew Then, What I Know Now!

When I got my first professional job - it was selling IBM PC's and compatibles, along with the assignment of teaching a couple of courses for the company I worked for - these courses included dBase III and I believe Lotus 1-2-3 (that should give you a pretty good indication of how old I am). Yes, I had done contracting work prior to this job - some coding on the IBM 5110 - which was state of the art at the time. But that wasn't full time and I fit in the coding between school activities and my real job.

After a couple of years, I sought to find a job doing software development - I learned that although I could sell, I didn't like it. I also knew that I really enjoyed programming. So the switch was logical. Looking back on those first two jobs, I realize that although I thought I knew everything, in all honesty, I barely knew the basics. Following are some of the things that have been ingrained into my psych over the years – things maybe I knew, but didn't realize were important when I started my professional life:

1) Patience is a virtue. I've indicated in previous postings that I'm a Driver - with a capital D - learn more by reading about Social Styles. That's not a bad thing, it's not a good thing, it just is. My particular issue - one that I've learned to manage over the years - is that I want to dive in head first when I see a problem. What I've learned over the years, is that in many instances, you want to listen and ask before starting to solve a problem. In fact, I frequently tell my direct reports that when presenting me with a problem, they need to let me know: 1) they just need some room to vent; 2) they want my input on ideas on how to resolve the problem; or 3) they are escalating the issue and want my involvement. I had/have a nasty habit of jumping in on their conversation and telling them how to solve the problem. In many instances, they don't want me to solve it, they want me to guide them through the process and help them solve the issue (some might call this mentoring).

2) Be Passionate about your Role. I can honestly state that I've loved most every job that I've ever had. I've never left an organization because of the work - I've left organizations because of the culture and because of specific individuals. If you want to get ahead in your current role, you need to show passion, you need to let your boss know that you want to help him/her. Volunteer for the tough assignments! How many times have you walked up to your boss and asked if there was anything on their plate that you could help with? When an opening has occurred, have you ever told your boss that you’re willing to take on the responsibilities associated with the open position? Let your boss save money in the budget! I have and it's been awesome - I've taken on teams that were outside my prime area of expertise and it has forced me to learn. What's better than that? You win, your boss wins!

3) Learning is a never ending process. Especially in the technology industry. And, change is only accelerating. It wasn't long ago that you could use a language for years and not feel the pressure to learn a different language, now there are new scripting tools appearing daily. Businesses are shifting development paradigms!  You need to think about the user experience across mobile (phones and tablets) as well as traditional laptops and desktops. You don't need to run hardware anymore, you can develop, test and have your production environment in the cloud.  Companies are now introducing wearable technology - how do you think that will impact your business?

4) Communication, communication, communication! For those of us in the technology field, there is a certain personality that people associate us with - they believe we lack social skills and don't understand how to interact with others. I am lucky that my parents taught me how to communicate in groups at a young age. The fact that I can move between non-technical and technical users and communicate and share information has been a key driver in my career. The time has passed where you could hide at your desk and not have to interact with anyone. In the business environment that exists today, you need strong written and verbal communication skills. You also need to be adept and moving between technical and non-technical discussions and being able to translate information between teams.

5) If you're not happy, find something else to do! When you're dreading going into work every day, maybe you need to change things up. Once job from my past, made me extremely miserable. I didn't realize it in the moment, but after leaving the company and taking on another role, I was able to look back at the experience and understand how it had impacted me - and not for the better. It was a miserable experience for myself and others. I wasn't the only one who ended up leaving either. Over a period of time, a lot of good people ended up taking on different roles in other organizations. What a loss for that organization.

As I've grown into different roles and moved between organizations, these realities have allowed me to tackle new challenges.  Each of us have our own core strengths.  Figure out how to maximize the impact your strengths have within the role you currently play.

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

How to FAIL an Interview!

When interviewing candidates for a position, I like to get the candidate to tell me about experiences that speak to the goals that I have for the open position. This is the easiest way to weed out people that can't speak to their own personal contributions within the roles that they've played.

It amazes me on regular basis when I tell someone about an objective/goal that I have for the open position and a timeframe that I want it completed, and they can't come up with concrete examples of how they've achieved something similar. They will speak in generalities and will become silent when I ask them specifically what contribution they individually made in the effort that they are discussing. Suddenly, they look like a dear in headlights and stare back at me - then begin to tell me what the team did. STOP!

You know what - I really don't care what the team did (ok, I do, to give context). But I really want to know what you did. What obstacles did you personally experience? How did you overcome those obstacles? What disagreements did you have? How did you solve the disagreements? What did you learn? If you could go back in time, what would you do different?

Some candidates who are entry level look at me and tell me they haven’t done anything yet.  Yes, you have.  What team assignments did you have in school?  How did you solve problems between team members?  Don’t tell me there weren’t any problems, there always are.  Were you able to deliver something unexpected in the piece of the project you were responsible for? 

If you didn’t have any team assignments, than think about whatever jobs you’ve had.  Be it a cook at a restaurant, a server, a lifeguard – think about how you provided service.  Where did you go above and beyond in the expected job to be noticed by your supervisor?  If it was a volunteer activity – tell me about it.  Were there experiences you had during the volunteer experience that show your passion for doing something?  Where you needed to get something done and someone or something was in the way – how did you get around it?

Let's be honest, I'm taking a few hours to make a critical decision that will allow the team to succeed, or that could potentially cause the team to fail. This is not an inexpensive decision - when I bring a person on board, I'm going to lose some productivity within the team as others bring the new team member up to speed. I need to have the highest degree of assurance through a short interview process to make the decision that this person will fit in with the team and be a contributor.

If you're not willing to understand what the goals and objectives of the job are and can't speak to specific experiences that you've had that can contribute to achieving those goals, you will not get picked. In fact, if I see the pattern, I'm going to find a way to end the conversation and move on to the next candidate.
 
Prior to an interview, take time to reflect on the contributions you make to the team you’re part of and be willing and able to talk about that during the interview. In other words ... take time to prepare!

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

Communication: You might be the Problem!

How many times have you entered into a conversation where you knew you had the answer to an issue, you just needed to sell the others. Much to your surprise, when you presented your idea you struggled to get the expected buy-in. In your mind, it was obvious what needed to be done, but you couldn't get others on board.

Well, it just might be because you didn't know how to communicate your ideas in a way that others could understand, or in a way that they felt safe buying into your recommendation.
Let's take a look at the 4 different Social Styles as documented by Larry Wilson:

• The Driver - these are the folks that just want to get it done! Given the opportunity, they will take charge.
• The Analytical - these are the folks that want to know the facts! Before diving into an assignment, they want to know all the details.
• The Amiable - they want to be your friend. Relationships drive their world. They are very loyal and want to know who they can work with and why it needs to be done.
• The Expressive - these folks have a lot of energy and have a "let's do it" attitude. They are spontaneous and will struggle with commitment and follow-through.

If you want to be successful in the interactions you are having with others, it is imperative that you understand what makes that person tick. Then guess what - it's you that needs to change your approach! Yep, you need to take the time to figure out who your interacting with and be able to modify your communication style to win them over.

• The Driver wants you to cut to the bottom line. Expect them to be business like and outspoken. They can sometimes be poor listeners and want to control the conversation. They will freely interrupt the conversation to get answers to questions and will summarize to move the conversation forward. To be successful: focus on the problem at hand, be brief, speak in terms of results, give them options to choose from and allow them to feel in control.
• The Analytical wants you to talk facts. Expect them to set high standards for themselves and others. They will have limited expressions and eye contact during the conversation. They will focus on the detail and will want to ensure the accuracy of any assertions. They expect you to be logical and well organized and will expect you to do what you say you will do when you say you are going to do it. You need to allow them time to think through things and don't force a decision.
• The Amiable wants you to avoid conflict. They will want to focus on the traditions and will want to be flexible in how the approach the issue. They will want to keep things easy and informal. They will want to allow time for the team to feel good.
• The Expressive want you to seek their input. They will focus on the future and want to illustrate points with stories. They will want to focus on the big picture and leave details to others. They will want you to compliment and recognize their contributions.

The trick is learning how to quickly recognize the social styles of the individuals you are working with and then being able to change the presentation of your idea to make it more compatible to how the person will hear the proposal. This isn't easy, and it take quite a bit of practice to master. What can really be tricky is when you are interacting with a group of many social styles and then understanding how you have to shift the presentation between the different social styles to win over the others in the room.

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

Find a Mentor ... Be a Mentor!

Maybe you're in your first job, maybe you're at the pinnacle of your career, it doesn't matter, all of us need a mentor and those of us that are moving up the ladder need to lend a helping hand to those on their way up!

You ask yourself, why do I need mentor? Well, let's be frank - you don't know it all. If you're new in your role, or have been in your role 15 years, there is someone you can learn from. Maybe you've noticed someone within your organization that you respect. Maybe you've been introduced to someone outside the company that you feel you could learn from.

Before you make any moves, sit down and figure out what it is you are expecting from a mentor. What is it that you want to learn from them?

Next, find an issue that you're dealing with that addresses the above question. When you have a situation at hand, open up the conversation by letting the person know that you've been watching the way that they handle themselves and really respect their abilities. Then ask if they wouldn't mind giving you some advice on a specific situation. Once you've broken the ice and started developing a relationship with the person, ask them if they would be open to providing you career advice on a regular basis. Let them know up front that you don't want to eat up a lot of their time, that you understand that they are successful and you are willing to minimize the time spent together to get this advice.

When you're having this discussion make sure that the person your approaching is relaxed. Don't approach this conversation when you know they've just gotten through a tough meeting or had a rotten week at the office.

Now let's flip this around! Those of you that have started moving up the ladder, when's the last time that you intentionally found someone to help take their next step? If you don't take the time to help the next person up, how does the organization find the next talented person when it's needed? Part of the human experience is sharing knowledge! I'm sure each of us have seen someone struggling as they try to figure out which path moves them forward. Remember when you felt that way and someone put a guiding hand on your shoulder and opened the door for you. Now is your time to return the favor.

Look at the people that you meet with on a regular basis. Is there someone that you recognize has the potential to be something bigger? Introduce yourself, if you haven't already. Let them know that you see something bigger in their future, that they have the potential to grow and that your willing to help them. If you see a project that they are struggling with - give them some free advice on what they might do next. If you see them struggling with certain conversations - tell them how you might approach the situation.

Now, I'll let you in on a little secret - I found my mentor by accident and found myself being mentored without realizing it at first! I had actually been in management for a while and thought I was all that, I was comfortable and having fun. What I didn't realize is that my personality was causing some of the pain that I felt in my role. I'm a Driver by nature - I see a problem and I begin attacking it to solve the issue. I can be very vocal and sometimes in my communication I can be blunt. I immediately head for the goal posts and will drag everyone across the line to get the problem solved.

My mentor also happened to be my boss. Without realizing it at the time, she was coaching me on understanding how to recognize what made other people tick and how to change my approach to working with people. She would take me to meetings I didn't necessarily need to be in, just so I could see how she was handling certain situations. She never formally told me what she was doing, it was only after some time that I figured out she was 'teaching me'.

During this time, the organization began training all of the supervisors and managers, taking them through a Working Styles course. It was during this class that I realized what she had been doing with me since I had started reporting to her. My mentor worked with me a lot outside of that class to help me break some bad habits, how to improve my chance of having a successful exchange of ideas with others. I won't say I'm an expert at it, but I'm a lot better at it today than in the past. 

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

Adding Value – That’s Why They Hired Us …

Are you adding value?  I don’t care what your role is within the organization – are you adding value?

If you’re simply holding the fort, doing only the minimum required for your role.  Then you have a job, not a career and I would also argue you are not adding value.  Look, we are all here for a purpose and that’s to advance the cause.  Now for some, that may mean exceeding the expectations of the department down the hall, your peers halfway across the world or the customer actually using a product sold, distributed or given away by the company.  Heck, you may look across the deliverables of the team you work with and identify multiple customers.  At the end of the day, look back at what you’ve accomplished.  Did you move the ball forward and did you exceed the expectations of your customer.

If the answer is no – then you need to look at the way your performing your role, the way that your team performs it’s role and potentially the way that the company responds to its customers.  You can definitely change the way you respond to work assignments that you have responsibility for and you have influence on the way that the department and the company provides the product or service that your customers use.  Some of the best advice I ever received in my years of work: “under promise and over deliver”.  And, that’s not an excuse for padding the work estimates just to make yourself look good!

Early in my career, I not only took responsibility for work that was assigned to me, but I would volunteer to help others, or to take on additional work.  Now, all in all, that is not a bad thing, except for the fact that it was preventing me from meeting the deadlines associated with work my boss was expecting me to deliver on assigned projects.  Lucky for me, I had a boss that realized I was young; he knew what was happening and took the time to educate me on what I was doing to myself.  For a while, I kept up the pretense that I could handle the work – both my own and any additional work where I had volunteered.

Then the backlog started to creep in and I began to miss deadlines.  First I would miss them by a day or two and then it began to stretch out further.  Finally, my boss called me on it and forced me to admit that the additional work was preventing me from meeting my own goals and was impacting not only myself, but the entire team.  Not an easy conversation to have with your boss.  This is the person that I wanted to impress, to show him that I was the go to person on the team.  Well, I impressed him, just not the way that I had intended.

It took me a while to dig out of the whole that I had made, but my boss was patient and helped me make decisions on where volunteering to take on additional tasks made sense and where I needed to pass.  Sometimes that meant telling my co-workers that I was on a deadline, but that I’d be happy to help them once I got past the next milestone.  My boss made me realize that sometimes the person asking for help didn’t necessarily need it that minute.  Sometimes they could wait, and I needed to be able to determine when someone truly needed immediate help and when it was something that could wait. 

He also made me realize that it wasn’t necessary to volunteer for every extra assignment that popped up on the radar.  When picking these extra assignments, he showed me how to identify those projects that would have a net positive impact on the team or the company.  He also got me to realize that not every call that came in to my desk was an emergency. 

Now, I’m not advocating that you ignore requests.  What I’m talking about is being able to prioritize the work requests – both requests originating from others and additional work that you identify as important.  The feeder that fills your pipeline has many inputs – assigned project activity, departmental meetings, service requests, code defects, project meetings, code reviews, implementation planning, environment builds, etc.  However, there is only one output from your pipeline – you must be able to identify the priority of all of the inputs.  Now, depending on where you are in the chain of command, you may need to validate the priority with your boss, or you may be able to set the priority within some discretionary limits.  Whatever method you need to use – use it!  Figure out the priority and then work accordingly to produce results.  Meet the deadlines, exceed the expectations by delivering something extra that wasn’t planned and ensure that you wow your customer!

When it is something that you have direct control over – hold yourself accountable.  When it is a team or company decision, make your best case for change and don’t give up.  Just because someone up the chain doesn’t like the idea right now, doesn’t mean they won’t like it a month from now.  If you know it is the right thing to do, find a different way to present your idea.  You may need to find out why it was rejected and then provide alternatives that work around the objection.

Take a minute and think about a time you received exceptional service from someone.  Maybe it was the last time you went out to dinner with your family.  Maybe it was the last vacation you went on.  Maybe it was work that a vendor had performed for you.  Maybe it was a contractor that had worked on your home.  Whatever that moment was – what made it special?  Was it the personal contact?  Did the person responsible, go above and beyond and exceed your expectations?  Now, what can you do to provide that same experience for people you work with on a day to day basis.

So, how are you adding value today?

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

Using Metrics Across the Development Lifecycle

We’ve discussed metrics before, but I think it’s time to revisit the topic.  Different members of the team are going to want access to see different sets of metrics at different points in the cycle.  I think it’s critical for organizations to understand what metrics are easily available – or what can become available with a small amount of work.  Then you need to understand how to use the metrics to drive the behavior you want within the organization.  Metrics used the wrong way can create bad behavior.

I’ve known organizations in the past that rate their development team members based on the overall number of lines of code that they create.  I’ve attempted to explain to individuals that this encourages developers to focus on the wrong thing – how fast they can key in chunks of code without any care as to the number of bugs they are introducing into the application.  This may also encourage the development team to create chunks of code that are not optimized.

You may not think this is a big deal.  But I’ve seen real instances where a company has a transaction loop that is measured in milliseconds, just to have their transaction time crater because some joker hasn’t optimized their code.  Instead of being able to handle a 1000 transactions a second, they find out they can handle less than 10 transactions a second.  Yeah the guy got the code done ahead of schedule, but at the cost of preventing the system from processing transactions.  Don’t worry.  The change never saw the light of day.

I’ve also seen organizations that award bonuses to team members by how early they can deliver the functionality – a sliding bonus based on how early the product is delivered to production, the earlier you deliver, the bigger the bonus.  This shifts the focus to how fast the system can be assembled vs how well the system matches up to the original requirements or how many bugs found their way through to production.  Just a tad short sighted if you ask me.

Tracking metrics is a fine line.  You want to create a set of metrics that allows you to understand what is happening within your lifecycle, but you need to identify and balance the metrics to get the real behavior you want from the team.  Ultimately, you need to produce a product or an enhancement to an existing product from the project that is as free of bugs as possible and that delights the customer.  If you do your job right, you’ll deliver more than the customer was expecting (under promise and over deliver).  Oh, and you'll also produce a product that drives additional revenue to the organization.

NOTE: The metrics identified below are things that I’ve seen work across the various organizations I’ve been involved with over the years.  These may or may not work for your organization.  It is important to look at the culture of your individual organization and identify what you value, what needs to be measured and how that information will ultimately be used.  Do I use all of these in the role that I currently play – no.  Some of them just don’t make sense for the way that we manage our projects and others won’t work because some of our processes haven’t fully matured.

I've seen organizations use multiple specialized roles to get through the first couple of phases of the life cycle - variously titled: Product Managers, Product Owners, Business Analysts, Process Engineers, Product Engineers ... the list could go on and on.  That said, all of the roles have the responsibility to reflect the needs of the project sponsor.

Through the scoping/discovery phase of a project, the team should be fully focused on eliciting the needs and expectations of the Sponsor.  This allows you to draw the box around what needs to be delivered and to begin to identify what will be called success.  All that said, how do you measure the success of these individuals - what metrics make sense?

The Project Office may consider the project a success if it is delivered on-time and on-budget.  However, the Sponsors perspective is more concerned about the impact that the project has post implementation.  They would not have authorized the project to move forward unless they were expecting efficiency improvements, cost reductions or revenue increases.  Ultimately, the project was approved for some underlying reason.  It was not approved to provide busy work to a bunch of people across the organization.

From the Project Office perspective, the key metrics that they will watch - again remember they are concerned about time, costs and resources - occurs during the overall life cycle of the project.

1. What is the % of Project Change Requests against the identified scope that do not alter the overall boundaries of the project – minor misses?
2. What is the % of Project Change Requests that increase the original scope of the project enlarging the overall boundaries of the project – major functional or non-functional pieces that were missed – major misses?
3. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

From the Project Sponsor perspective, the key metrics that they will watch will happen after the project is considered complete and has been moved in to production.

1. Did the company achieve the expected efficiency improvements, costs savings or revenue increases?  Does the project meet the objectives identified and agreed to within the business case?
2. Did the company hit the objectives for the total number of clients adopting the solution?

NOTE: Take a moment to reflect on the different viewpoints – the Project Office may consider the project a success due to the fact that it was delivered on-time and on-budget.  However, six months to a year later, the Project Sponsor may declare that the project was a failure because the expected increase in revenue didn’t appear.  What processes do you have in place to support the different needs of the Project Sponsor vs. the Project Office?  What feedback do you give to your Product Owner? 

As the project moves through the formal requirements definition phase, responsibilities shift and additional resources are brought into the team.  Additional artifacts are generated – the business case, requirements, business impacts, security assessments, risks and mitigation plans.  Quite a bit is going on in this phase and this really begins to put the underlying structure in place that will give shape to the product that is being built or enhanced.

The Project Office will have primary interest in the success of this phase and may want to look at measuring success of the team when the phase is complete based on the following metrics:

1. What is the % of Project Change Requests against identified requirements – minor misses?
2. What is the % of Project Change Requests that introduce new requirements – major misses?
3. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

There are multiple team members defining requirements – one individual should be accountable for the overall set of requirements, but accountability should occur across those responsible for contributing to the set of requirements impacting their slice of the organization.  You may want to track down to the contributors so that you can assess weakness across projects and across the organization.  For example, you may see a pattern emerge across several projects that would indicate that requirements associated with the sales team are consistently seeing change requests – you then have something to act on.

As the project moves downstream we begin to do the formal design work – this is where vision hits reality.  The team gets larger and begins to focus on breaking down requirements or combining requirements to understand what is being requested and translating that into technical terms that define what will actually be delivered.  If the Project Sponsor wants a hard dose of reality – this is usually the place and time for that cold water to be thrown in their face.  Sometimes what is wanted can’t be delivered – or at least can’t be delivered without significant pain.

All that said, the design is laid down and the Project Office needs to measure the success of the design using the following metrics when activity within the phase is completed:

1. What is the % of Requirements that can’t be traced through to the Design – major misses?
2. How many defects are identified in production that can be traced back to Architectural Design?
3. How many defects are identified in testing that can be traced back to Architectural Design?
4. How many changes are identified within the architecture artifacts during the following phases of the lifecycle?
5. How many additions to the architecture artifacts are identified that account for functionality missed during the design phase?
6. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

Then we are move into the construction phase of the life cycle.  Once again, the team bulks up and this is where we lay down the pieces that come together and satisfy the original vision.  Traceability becomes an important factor across multiple disciplines in this phase.  I like to include regression testing in this phase as my teams are moving to an automated nightly build/test model.  The Project Office may want to look at the following metrics after the phase has finished:

1. What is the % of Requirements that can’t be traced through to the unit tests?
2. How many defects are found during integration testing?  Are they design or build related?  
3. How many defects are found during quality assurance testing?  Are they design or build related?
4. How many defects are found during user acceptance testing?  Are they design or build related?
5. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

We're almost there folks!  We now move into the formal testing phase - formal quality assurance, user acceptance tests, load testing, parallel testing.  This is all the stuff we need to do to make sure the product is ready for prime time.  The Project Office will look at this activity and want to track a few more metrics once this phase has been completed:

1. How many defects are found in the production environment?  Are they design or build related - or are they related to the implementation?
2. Did they miss the target milestone to complete all activity associated with this phase of the lifecycle?

If you review the metrics identified at each stage of the lifecycle, you'll see that most of these metrics assess issues that can impact the final product delivered to the customer.  The one consistent measurement across all phases that the Project Office will want to know about - but is not necessarily tied to the user experience is: "Did they miss the target milestone ...".  This is more about keeping accountability within the overall team to ensure that things stay moving.  And the most important metric won't be known until after the project is in production - are the customers accepting the product, is the company experiencing the revenue increase expected or the efficiencies that were planned.

Tags: Project Management; Software Development Lifecycle; Teams; SDLC; Change Management; Portfolio Management; Project Portfolio; Project Metrics; Metrics;

For more information on David L. Collison: LinkedIn Profile

Are we asking team members to be too perfect …

This happened early in my management career.  And, it’s a story that I share with others on occasion.

So, to set the background up, this happened a long time ago in a career far, far away.  I was a partner in a consulting firm and we were beginning to grow.  We had recently moved in to our own space and had begun to hire our first few employees. We had a set of clients that used us regularly and we continued to add new clients at a regular pace.  The company was profitable and my partners and I were working hard to keep everything running smooth, our customers happy and our bills paid.

One of my hires, we’ll call him Tim, happened to be fairly fresh in to the game of programming, but he’d had a couple of years’ experience so I felt comfortable that he’d be able to handle moderately complex development assignments.  I ended up assigning Tim to a smaller project associated with a system that we had already developed for one of our primary clients. The add-on was to be done in MS-Access. And, yes, at that point in time, MS-Access was a go to tool for small database work.  The core system had already been developed and was being used by the Human Resources department.  The add-on piece would allow them to track additional data associated with training that they provided their employees.  This was critical to the HR department as the company was responsible for providing proof of training to several of their clients to keep contracts in place and active.

So, I assigned the new hire this add-on to the core system.  I attended meetings with the client, along with Tim, and acted as the Project Manager for the development effort.  We met with the client weekly to provide status reports and to get feedback from them on our development plans and activities.  After a few weeks, it became apparent that Tim was struggling with the development and was not making the progress that was needed on the project.

After meeting with the client one afternoon, Tim and I headed back to the office.  I knew it was time to address the situation and so when we arrived at the office, I asked Tim to meet me in the conference room.  Tim knew I was agitated and he immediately became defensive.  My mistake as a young manager was letting my emotion show through during the conversation. Instead of talking to Tim about the roadblocks he was facing and how we might overcome them, I made the mistake of attacking him.

Luckily, during the conversation we both realized we were not approaching the conversation the right way. It actually happened when he caught me between breaths and asked me, “What do you want me to do, quit?”  He stopped me dead in my tracks.  No, I didn’t want him to quit, I wanted him to do the job and I told him so.  At that point, we began to backtrack and talk about the issues he was facing and what we needed to do to dig out of the hole.

Long story short, all he needed was some technical mentoring.  I was so busy selling our services to new clients, attempting to PM projects and doing my own development tasks, that I forgot that I needed to reach down and help the next person up the ladder.  I compounded my mistake by approaching Tim the wrong way and not giving him the opportunity to find a way forward.

Tim actually ended up being a fantastic team member.  He was a hard worker and knew how to interact with clients.  I’m glad that he stopped me during our conversation with his question before my emotions got the better of me.

Sometimes we need to realize that the people we’re dealing with don’t know how to succeed and it’s our job to show them.  We can’t ask them to be perfect every minute of every day.  Think back on the mistakes you’ve made in your career.  If someone hadn’t extended a hand to you, would you be where you’re at today?  The real nut is, are they learning from their mistakes.  If they are – then mark it up as a win!

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