Project Management Is Such A Lonely Phrase

Project Management, is like the word honesty from Billy Joel’s hit song titled “Honesty”.  Project Management is such a lonely phrase!

Let’s get down to the brass tacks – Project Management at its most basic function is responsible for managing the three sides of the triangle: time, budget, and scope.  Project Management requires the Project Manager to utilize their knowledge, skills, tools and technique to oversee a team of individuals and deliver against the Project Requirements, within the allocate time and budget with the approved resources.

If a Project Manager is to be successful, they must view themselves as the only source of truth.  At times, they must set aside the need or want to be liked by the team so that they can provide a true assessment of ongoing activity to the Project Sponsor.

Let’s face it, at times, the teams like to sweep issues and risks under the table so that they can present a warm and fuzzy view of the project to the Project Sponsor and the Project Management Office.  The Project Manager sometimes enables this behavior because they want to see their status in a ‘happy state’.  This also reduces tension within the team, because the Project Manager is not confronting the issue.

Well, that’s just plain wrong!  I’m sorry, but as a Project Manager, you role is to highlight to the Project Management Office and the Project Sponsor when tasks are not being completed on time and the risk to the overall project.

Now, I get it!  Not every task will be completed on time, but there are milestones that activity should be tracking to that allows the Project Manager and others to get a sense of whether a project is on track or not.  A given task may be late, but not risk the overall milestone.  However, if the milestone is at risk, either from a time or budget perspective, than the issue/risk needs to be highlighted, mitigation plans need to be identified, and communication needs to occur.  It is possible that thru the mitigation plans identified by the team that the Project Sponsor will allow the team to address the issue or risk.  However, if it is a key milestone and the Project Sponsor is not comfortable with the mitigation plans, they then have the opportunity to engage and assist the team in getting the issue corrected.

As a Project Manager, you are the source of ‘Truth’ for the project.

Resources like to always look at their own package of work and paint a rosy picture.  They will find reasons – not their own – as to why something is late, or why it’s costing more than was budgeted.  As a team, they will work together to gloss over the truth and allow the Project Manager to report a rosy picture from week to week.  I’ve heard things like:

•      Yes, we are running over the timeline to get requirements complete, but we’ll make up for it somewhere down the line.

•      Yes, the designs aren’t ready to go, but everyone knows the estimates put together for the actual construction are way high, so we’re good.

•      I know development is taking longer, but we don’t actually need all the testing time that is shown in the plan.

•      The contract firm that is doing that piece is late, but that’s ok, we can still get all of our pieces in on time.

None of the above statements (or any other excuse) is acceptable.  As the Project Manager, your job is not to go along with the team. Your job is to identify the issue, create a mitigation plan and communicate it up the chain to the Project Management Office and the Project Sponsor. Once the issue has been highlighted, maybe additional resources can be applied to bring the timeline back in and meet the next milestone. Maybe the Project Sponsor accepts the recommendation from the team that the milestone can be missed, but the overall plan can still be delivered within the identified timeframe. But at least, the Project Sponsor and Project Management Office are aware of the issue and can work with the team, vs being surprised at the very end that a project is being delivered late or over budget.

As ‘truth brokers’ you are keeping the team members honest with each other and are keeping the lines of communication open up to the Project Management Office and the Project Sponsor.  This truth is critical as it allows the Project Sponsor to accept the truth without questioning the motivations and ultimately forces clearer communication between team members. 

Telling the truth should not be viewed as a negative, but should be viewed as the core responsibility of the Project Manager.

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

Rock Star Programmers - 5 Traits I See As Winners

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

So what makes a great developer?

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

Patience

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

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

Lifelong Learner

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

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

Commitment to Excellence

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

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

Passion

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

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

Self Sufficient

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

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

Wrap Up

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Don’t Be Afraid … Change!

Over the last several years, my teams have made significant changes to our project management, development, testing and implementation processes and paradigms. We’ve had some bumps along the way and in no way do I consider this evolution over. I will continue to challenge my team members to find a better way to build the mouse trap that drives our software development lifecycle.

Let’s look at some of the successes the teams have had introducing change into the organization:

1. Our project management process used to be split into separate and distinct teams: 1) project management for business and operational teams; 2) project management for technology teams. This has been consolidated into one project management team managing all project related activity across the organization. This has streamlined activity and improved communication across all teams involved in the process.
2. Our lifecycle was revamped as we consolidated the project management organization. During the revamp – we created RACI documentation that clearly outlined 1 owner for each key task/milestone within the overall project activity, along with those that would act in the roles of responsible, consultative and informed parties. This has provided clarity to who owns each activity and what the key tasks are that are included within every project.
3. Recently we made additional changes to the lifecycle – completely eliminating 1 phase and adjusting the tasks and milestones associated with both our scoping and design phases. This has allowed us to streamline the process and give clarity to when project activity actually starts within the organization.
4. We have challenged all of our team members to review the overall standard tasks/milestones within any given project, and challenge the project manager and sponsor to eliminate tasks and standard artifacts when it is justified and where there is minimal risk associated with utilizing an altered process.  This decision then is documented as part of the project and communicated to the team to ensure that down the road, people can review the effort and understand why certain documents or tasks might not have been done. This should allow us to be more nimble and find the best path for each project to take thru the organization.
5. A couple of years ago, it took up to 3 weeks to complete regression testing associated with key functionality within our application silos. This was a manual effort that typically was handled by multiple individuals. The teams have worked hard to automate the regression tests associated with these applications. Today, the execution of these tests can be done in less than 17 hrs. The labor savings moving forward will more than pay for this effort. This also allows us to provide quicker feedback to the development teams and ensures that our regression testing is more consistent across all projects.
6. Recently, the teams also completed the resurrection of standardized test data to be used across our test and development environments. This will be further enhanced as our automated tests are enhanced to create/modify/cleanse and reset data needed for a given test. This will reduce the time spent creating test data for each project and will ensure downstream processes/applications have the data that is needed to execute their regression tests.
7. Over the last several years, our implementation plans have seen significant improvement. Our business demands that our systems be available 24x7x365. When you want to buy a tank of gas at 3AM or 3PM, you want the transaction to go through so that you can continue on your way. You would not find it acceptable for us to deny the transaction because we are updating our systems.  Our implementation processes have been templated and include all implementation activity, across all application and infrastructure silos, commands, scripts, validation and fallback steps in the order they will be executed.  Recently, our external auditors informed me that our implementation plans are among the best that they have ever reviewed. This has hardened our implementation activity – reducing the overall time needed to implement changes into our production environment, standardizing the validation activity during and after implementation activity has occurred and most importantly having fallback steps at the ready when any validation activity shows that there may be an issue.
8. Our development teams have changed their processes to include code reviews of all changes prior to those changes being introduced into our production environment. This is hardening our code base and reducing the risk of making changes within our production environment.
9. Our development teams have changed their processes to ensure that unit tests are created for all code being touched within a project.  These unit tests are then kept in a repository and used in future projects. This, again, has hardened our applications and reduced the overall number of bugs slipping through the process into our quality assurance testing or into our production environment.
10. Our development teams are now doing nightly builds – with reports going back to each team on build failures, unit test execution failures, code coverage and other statistics. This is giving immediate feedback to our development team and ensures that issues are addressed within 24 hours.

These are just some of the changes that have been implemented by the teams over the last several years. And we’re not done! Moving forward, we will move the regression testing into our nightly build process. We will be evaluating further changes to our development lifecycle to reduce the amount of time between idea generation and product introduction into our production environment. We will continue to improve upon our implantation planning. We will introduce key metrics across the development lifecycle. And where it makes sense, we will introduce Agile techniques into the development process.

I talk to college and high school students on a regular basis to discuss what it means to be in the technology field (specifically software development). The one constant that I tell students is that being in this field means you will constantly have to learn. They will learn new languages, they will drive change into the organization, they will experience multiple different development paradigms. All of this is good – it means the organization is alive, is learning and is adapting to its competition. 

Don’t settle for how it works today or with someone telling you, “well, that’s the way we’ve done it for decades!” Your job, no matter what role you play in the organization, is to find a better way, review your suggestion with those that can help implement, trial those changes and then roll them out across the team and the organization. Change is good – don’t settle for the status quo! 

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

A Little Help From My Friends!

I have been blessed in my life! I'm not a man of physical riches. Yes, I live comfortably and am able to provide for the needs and wants of my family. I grew up in a family that had a lot of love! Even though we live hours apart, we make time to get together at least twice a year - this has grown to include my nieces and nephews, their respective spouses and my great-nieces and nephews. Of course their are disagreements - but at the end of the day, we are family and I'm a better person because of my family.

My mom, dad and brothers and sisters were my first mentors. Being the youngest of six children, I did not lack direction from my elders growing up! While I may have fought against some of this, they taught me right from wrong, they taught me about responsibility, they provided my moral foundation, and, yes, they let me know when I was wrong!

Between high school and college, I had the good fortune to actually work in my dad's business. This was my first office job - having delivered papers and worked in fast food restaurants prior to taking on this role.  My dad showed a lot of patience with me as my attention to detail was not quite where it needed to be in those days. All that said, I learned a lot from working with my dad. His work ethic is impeccable, his fairness to others can not be challenged. My dad has always been my role model - in some ways I'm his clone (ask anyone who knows us), in other ways we are different.  I have never had the patience my father has, but he was the first one to call me out and I've continued to work at this my entire adult life.

Throughout my professional career, I've been fortunate to have people that cared enough to help lift me up and help me to learn things that I did not know. These mentors have made it possible for me to succeed!  They have made me learn lessons that I didn't necessarily know that I needed to learn or was to stubborn to recognize where I may have been making a mistake.

In fact, at one point, I was lucky enough to have 3 mentors at the same time: Beth Gritton, Jim Haddad and Art Christofferson - CIO, COO and CEO of McLeadUSA Publishing during the late 90's and early 00's.  To state that I learned from these individuals would be an understatement.  They never let me doubt that they trusted me, they were never afraid to let me make changes, they actively threw new challenges my way and gave me the support needed to succeed, even when I did make mistakes.

Beth took the time to show me the difference between being a manager and being a leader - lessons I still strive to understand today as I work with my teams. I have a strong tendency to react to what my team members are telling me about situations that need to be resolved and then inserting my view of the solution on them. Beth taught me to slow down and allow individuals to walk me through their issues as they see them, ask them questions and allow them to discover solutions, and support the direction that they want to take. That doesn't mean I sit back and let it all just happen. She also taught me how to understand when those decisions are material and when they are not. Letting people learn on projects and decisions that are not material and ensuring that the right support is in place when a decision is material and can impact the organization.

Beth was never afraid when I disagreed with her and would allow me to challenge her (note: if you're going to challenge your boss, do it behind closed doors and do it respectfully). When I felt I had a different way to tackle an issue, she would let me get my thoughts on the table, she would help poke holes in the solution I was presenting and more times than not, she would let me move forward with the recommendation.

Jim and Art were incredibly valuable as I learned from Beth. They both had open door policies and let me come in and 'chat' at any time. Both always expressed confidence in my abilities and let me know that they respected the skill-set that I brought to the organization. They never once cut a conversation off because they were 'too busy'. They would let me ask any question and they would always answer it - they never hid from the issue. In fact, in one instance I know I went to Jim with an issue that I did not feel I was capable of solving. Jim never hesitated, when I was done explaining the problem, he asked me how much it was going to cost to solve the problem and told me that he had faith that I would resolve it in a way that was a net positive for the organization.

Beth, Jim and Art allowed me to change the way that my teams worked within the organization and in how they supported the rest of the team. They held me accountable, but did so in a way where I was able to flourish, grow and become something greater than I imagined. I will forever be thankful for the experience to work and learn from these individuals - the ultimate mentors! 

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

Don’t Hide Behind the Process

Well, it’s been a while since I’ve discussed process issues.  Time to dig in and have some fun!

Most of you that have followed my previous posts know that I’m a process kind of guy!  I’ve introduced formal lifecycle management into several organizations.  The teams that I’ve led have successfully utilized process enhancements to drive improvements in productivity, overall capacity and quality within various organizations large and small.  Utilization of a known process allows you to begin to measure various pieces of the lifecycle – looking for inefficiencies and issues that impact your overall ability to deliver for the organization.

Now all that said, each organization needs to find the lifecycle process and development paradigm that will work with their culture.  I’m not going to try and tell you what development paradigm you need to follow because I don’t know your organization.  Within the organization I currently work for we largely follow a waterfall process with some agile techniques utilized within various teams.  This works for us and the style of applications that we create/support – mostly technical interfaces within the payments industry.  Our overall lifecycle has various checkpoints/gating that we use to validate we are ready to move to the next stage.  This works for us!  We’ve significantly increased our productivity and capacity over the last decade and have improved the overall quality of applications that we are delivering to our production environment.

While all this has been good, I occasionally notice when people are hiding behind the process versus just getting the work done!  Not every project needs every step of the lifecycle.  Some are small enough and straight forward enough that we can skip various parts of the process or make the decision not to create some of the standard artifacts/documentation.

Decisions need to be made up front when the project is defined.  Those in the know, need to direct the teams when a project needs the full pomp and circumstance of the lifecycle and when the teams have the option to skinny up the process and skip parts of the lifecycle.  That means at the very earliest stages of Discovery, the Project Sponsor should be giving direction to the team on what the risks are associated with the project which can then drive decisions on how much of the process can or should be used on the project.

Additionally, once a project has been initiated, I think individual team members need to be cognizant of what is happening and make recommendations to the Project Manager if they feel certain pieces of the lifecycle could be skipped or maybe some documentation might not need to be created.  I’m not saying that we’ll always make the choice to skip over pieces of the lifecycle or to not create various pieces of documentation, but as leaders, we need to listen to the recommendations of the people closest to the work and if it makes sense, say yes!  When we decide that we can skinny up the process used within an individual project or that we can eliminate some of the standard documentation, those decisions should be documented.  That way, there is a record of the decision and the reason is documented and shared with the Project Sponsor.

Overall, we still need to deliver for the organization!  Delivering the requested solutions with the necessary features/functionality; delivering a solution at or below the expected budget; delivering a solution with the highest levels of quality.  Our teams should be held accountable to ensure we are delivering successful solutions at the end of the project.

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

Picking your own Path!

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

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

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

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

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

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

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

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

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

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

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