Project Management – Words of Wisdom to the Uninitiated

So, you’ve got your first job as a Project Manager (PM) – congratulations.  Now, you’ve been assigned your first project and you’re looking at the elephant thinking to yourself, what do I do next?  Well, jump in with both feet seems like a good idea – but which end of the pool and how do I tread the water to keep my nose above the waterline?  I’ll attempt to give some advice in this posting – take it for what it’s worth, it may not work for you or your organization, but you may be able to find a nugget in here that gives you a ray of hope!  I know that it has helped me and those individuals that I’ve mentored over the years.

So, most development projects are broken down into phases along the following lines:

1. Discovery – this phase allows you to identify the stakeholders of the project and then working with the stakeholders identify the boundaries of the project, what will and won’t be included in the overall scope of the work.
2. Requirements – this phase allows the team to clearly identify the requirements associated with the project – this should include functional and non-functional requirements.  By the way, this is a personal pet peeve of mine – if requirements don’t include at least a high level explanation of how the user will test/validate that the requirement, then the requirement is not complete.
3. Technical Design – this phase of the project allows the technical side of the organization to take the requirements and translate them into an overall roadmap that identifies the application silos that will be touched and how everything ultimately fits together – this is the roadmap that technical teams will use to build the applications and underlying infrastructure.
4. Development/Construction – this phase of the project allows the teams to construct the functionality that will be delivered as a result of the project.  This should include not only the technical pieces, but the business pieces as well – marketing plans, supporting documentation, etc.
5. Testing – this phase of the project is used to confirm that we have not broken current functionality and that we have validated that the new feature/functions work as documented in the requirements and the technical design.
6. Implementation – this phase of the project allows the teams to move the application and underlying infrastructure changes into the production environment.

Clearly, looking at all of this when you’re first assigned to a project can be overwhelming.  As a PM, how do I know what tasks to put in the project plan and how long do I have those tasks last?

Really, this becomes much simpler than it looks – let’s take the first phase, Discovery.  We understand what needs to be delivered within this phase of the project – in most organizations, it will look something like the following:

• Project Request Document – gives the background justification for the project, a very high level scope of the project used to inform others what is being delivered, extremely high level expenses/costs, extremely high level sales goals, and competitive information.
• Project Concept Document – once the project request is signed off by the stakeholder, this document dives down to give more details – if the project request document was the 100,000 foot view, this takes down to the 50,000 foot view and includes things like the formal project scope/boundaries, project needs analysis, market assessment, proposed timeframes.
• Vendor Due Diligence – this activity confirms that viability of outside parties to deliver critical components of the project.
• Business Case – this takes the Project Concept and builds the other components around the base to provide management with the complete picture allowing them to make the go/no-go decision - sales commitments, revenue projections, product demand and strategic fit information.

Other organizations may drive more or less artifacts through the Discovery phase of the lifecycle.  All that being considered, there are a base set of deliverables that are expected at the end of the Discovery phase.  Additionally, it’s not just a matter of the deliverables/artifacts being generated, it is disseminating that information to the decision makers and getting direction on the go/no-go decision.

So, let’s work backwards – let’s say you’ve been given 3 weeks to perform this activity.  You know that you have to have a meeting with the decision makers at the end to review the information and get the go/no-go decision.  You know that the expectation is to deliver the necessary artifacts 3 days before the meeting.  So if you have a 3 week timetable – that’s a total of 15 business days.  Assume the meeting with the decision makers is held on the last day, that means the documentation must be delivered on the 12th business day.

As the PM, you need to have the following discussions in your phase kick off meeting:

• Who needs to be included in meetings to create each of the deliverables/artifacts – Project Request, Project Concept, Vendor Due Diligence and Business Case?
• We have 12 days to complete each of the artifacts/deliverables for the Discovery Phase – how often do we need to meet on each artifact and how long should each of those meetings last?
• What are the check points in each of these meetings to ensure that we are on track to complete the documents in the required amount of time?

Now you have a timeline to work with – 12 days – and it becomes a matter of accountability.  Setup the meetings, ensure people are attending and contributing.   Your markers for each meeting – make sure you have an agenda, then take and distribute notes:

• Validate that the work that was supposed to be done between meetings was completed.   Get proof – sorry, I tend to be skeptical.
• Review agenda items – check off those items completed, note those not completed and create action/agenda items for next meeting.
• From the review of agenda items – when looking at items that were not completed, are there new risks/issues that need to be highlighted and mitigation plans created or does someone just need to catch up on work assigned?
• Review status updates across the team – ensure people are highlighting what is needed from each other to complete activity needed in this phase of the project.

Sounds simple, right?  Now, as a PM, it’s your responsibility to not to be surprised in your meetings.  While you may be meeting with parts of the team several times a week and the whole team on a weekly basis.  It’s your job to stay on top of things between meetings.  You should never walk into one of the meetings you are holding and have it be the first time you hear that someone is behind schedule.  You need to be performing walkabouts – moving around on the floor, instant messaging, or calling people to discuss how they are doing, what’s working, what’s causing them problems and staying on top of activity.

If between meetings, you become aware of a roadblock – it’s up to you to find ways around, under or over the roadblock and allow people to continue to move the process forward.  Who can you bring into the discussion or work activity to help the person forward?   What work activity can be reassigned?

Now, rinse and repeat for each of the following phases.  The difference being that at the end of the design phase, you should be able to obtain feedback from the team identifying all of the remaining tasks/milestones and timelines for the project.  This then becomes the baseline that you measure everything against.

Tags: Project Management; Software Development Lifecycle; SDLC; Change Management;

For more information on David L. Collison: LinkedIn Profile

Microsoft and IBM - two giants falling!

I credit the fact that I'm in this industry to Microsoft and IBM.  I was enthralled with the introduction of a small business class computer that you could place on any desk and with the OS and applications that made computers accessible.  Applications like Lotus 1-2-3, VisiCalc, Wordstar and dBase III.  Yes, this was long before the introduction of graphical OS - they all ran on MS-DOS, don't cringe, a text based OS.  And, yes, that means I was playing with these systems shortly after IBM introduced the first IBM PC - the year was 1983 and the IBM PC was only 2 years old.

While attending college, I got a job installing PC's, setting them up and introducing the client to their new system.  I also picked up computers that weren't working properly and brought them back to the service desk to be repaired.  At the time, PASCAL was the language of choice.  I was learning how to program in this language in school and the company I was working for allowed me to take a Compaq Portable PC back to my dorm room.  I convinced my instructors to let me use the Compaq for my programming assignments (I think I was using a copy of Borland Pascal - but my memory is a little hazy) versus having to logon to the DEC PDP 11/70 - a mini computer.  I also was able to get my hands on copies of Microsoft Assembler and Microsoft Basic.  Much as I hate to admit it - that was geek heaven at the time.

I loved the PC and MS-DOS.  Config.sys and AutoExec.Bat were my friends - I knew how to get into these files and make changes to the way that the system operated and the utilities that would be loaded into memory.  Microsoft and IBM made it fun and easy to use these new computers and made programming accessible.  Ask my folks how many hours I spent in front of those early computers teaching myself without realizing how important this would be for the career path that later followed.

I ended up working for a couple of computer resellers early in my career - doing everything from installs, service calls, sales and teaching.  Yes, I actually ended up teaching computer classes on dBase III and Lotus 1-2-3.  Teaching dBase III actually ended up being the precursor that allowed me to get into programming.  I started playing with Clipper - a compiler for the dBase III language.  Then I applied for and got a professional programming job using Clipper.  From there, as they say, the rest is history - moving through my career as a developer, consultant and manager.

None of this would have been possible without IBM and Microsoft partnering together and creating the business class personal computer.  Ask anyone I knew back in those days and you'll hear about how I looked up to these two companies - in my mind, they were at the top of the top, no other company came close to the respect that I held for these two companies.  And my early career was built on this market - migrating to Visual Basic and Visual C++ when Windows took hold.


IBM lost their way and fell down against the IBM compatibles - eventually selling their PC business to Lenovo.  They couldn't figure out a way to compete on cost with the competition.  Go figure, literally, the pinnacle of multinational companies could not figure out how to leverage resources across the world to compete against much smaller companies.  (If you're looking for the full story on IBM's fall - and not just related to PC's - I'll send you to I, Cringely for further reading - The Decline and Fall of IBM.)  IBM is gone from the PC industry and is seeing a decline across their other product lines.  As much as I hate to see this company in the condition it is in, I tend to agree with the assessment that IBM is on it's way down.

Microsoft on the other hand successfully out maneuvered the industry - yes, Apple was there, but they were a niche player.  Along the way, Microsoft made blunders - but was always able to recover.  And why not - they really didn't have any competition, to the point where they were charged and found to be a monopoly. Using their weight to drive competitors out of the market.  Ever hear of the phrase embrace, extend and extinguish?  If you haven't - look it up, it will give you an excellent run down of the way Microsoft controlled the industry.

The first chink in the wall of Microsoft was the open source movement.  Linux in particular and the open source programming languages and tools.  More and more developers became disillusioned with the walled garden of Microsoft and began looking for alternatives - myself included.  Linux, check!  Apache, check!  MySQL, check, Python, check!  All open source, no cost barrier to development or deployment!  What started out as an irritation became a full panic at Microsoft as they ranted about open source being a cancer in the industry.  Today, Linux runs the web.

Then along came the iPhone.  Microsoft initially made jokes about the iPhone - well, that humor came back to bite them in the back end.  The iPhone and iPad have ended the PCs dominance.  I know more and more people that are foregoing the purchase of laptops and desktops at home to purchase 1 or more iPads.  And I'll also wager that Chrome is becoming a bigger and bigger headache for Microsoft.

Apple ruled the smartphone market for several years until Android came along.  The one thing you won't hear is Windows Phone.  Ok, I'll give Microsoft credit Windows Phone isn't bad, but I still prefer iOS.  I'll use Android if I must, but I can never see myself going for Windows phone.

This is where I think Microsoft has really gone nuts - they created Windows 8 to run across phones, tablets and traditional PCs (laptops and desktops).  For those of you that like Win8 - that is your choice.  All I can do is speak for myself and I can not stand this Frankenstein of an OS.  Mindlessly switching me between Metro and traditional windows mode when I want to do various tasks.  I won't go into all of the details, there are plenty of articles out there that get into the details.

Microsoft used to be there for the developer - building the tools and making it easy to get stuff done.  I can't say that anymore.  Developers have moved on to iOS and Android - if it's convenient they'll build a Windows version, but it's usually well after they've developed for the other mobile platforms.  Don't get me wrong, both iOS and the Android environments have their issues, but developers want to be there, not with Microsoft.  And the consumers have spoken as well - at the end of 2013, Windows Phone had a whopping 3% of the world-wide market share of smart phones.

Today's kids want an Android phone or the iPhone - and, yes, that includes my kids.  Do you think when they're ready to move up, that they're going to go with Win8 or with an iPad or a Mac?  Some of them will move to Android tablets.  Fewer and fewer of them are going to choose Win8 machines.

I don't know what Microsoft can do to change the equation.  Is it too late?  Well, the good news is Microsoft has a lot of money in the bank, they've realized that Balmer was leading them off a cliff and have replaced him, and they still have a following.  Will something change in the equation - who knows, but if I was a betting man, I'd say Microsoft will never have the power or control that they had in the 90's and early 2000's.

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Implementations - When Things Go Bump In The Night!

Sometimes bad things happen.  The question - how fast are you able to respond and put things back on track?

Technical teams need to plan and test their ability to rollback changes that are negatively impacting users.  This needs to be a formal part of your process - sometimes that means falling forward, fixing the broken functionality in production; sometimes that means falling back and reverting to a known state where the application was functioning properly.

Let's be honest - none of us are perfect all of the time.  Occasionally, we are going to miss something and move code into the production environment that ends up breaking things and making life miserable for the folks actually using the application.  

What have you done to prepare for this moment?

1. Does your implementation plan include steps to proactively monitor the system as changes are moved into production?
2. Does your implementation plan allow time for you to look at patterns of application activity to validate that you are not seeing patterns that would indicate that something is broken within the application?
3. Does your implementation plan include validation steps to ensure that the application is acting accordingly and that the new/changed functionality is working?
4. Does your implementation plan identify risk points and fallback strategies?
5. Have you tested your implementation plan?
6. Have you tested your fallback plan?

Every environment is different - but we mostly face the same types of challenges.  Breaking things that users expect to work is not what we want to do, but occasionally, it happens!

Yes, planning your implementations takes time.  Yes, planning validation steps and inserting them into the overall implementation plan takes additional time.  Yes, testing your implementation plan chews up more time.   And, yes, testing your fallback plan takes even more time.  That all being true, failing to do any of this means that your operating by the seat of your pants and your recovery time when things go bad will hurt you worse.

1. When your application fails - the reputation with your customers takes a hit.
2. The longer the outage increases the risk that your customers will walk away from you and begin to use a competing application?
3. Will an outage impact your revenue stream?

Now, all that said, sometimes even with all of the best planning, you're going to get caught.  It's bad enough when it's a web based application/service where you can make immediate changes or perform and immediate rollback.  However, what if it's software that you're sending out to customers - that they install on their systems?  How do you think Microsoft feels when they send out one of their regular patches only to find out that it causes the blue screen of death.  This can affect millions of computers around the globe.

Not to hit Microsoft too hard - but, in April they released a patch to Windows 8.1 that was required before any other updates could be applied.  This impacted retail customers as well as corporate customers and was not fixed until early May.  I'm sure that they ran their standard quality processes against the code prior to the initial release in April - but something obviously got by the testers, and it wasn't a minor issue.  It took time for Microsoft to hit the reset button, but in the meantime their customers were in an uproar.  

I'm going to walk softly here because as a developer it could happen to me or the teams that I lead.  I'm not trying to single out Microsoft - anyone that writes software has had to recover from a misstep when loading code into production or sending out a new release.  What I'm advocating for is that you implement solid processes that minimize the risk to your customers, your team and your organization.

What are you doing to mitigate the risk of an implementation/software release going bad?

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Back In The Saddle Again ...

I have been distracted with several items over the last few months and apologize for my absence.  That said, let's dig into our discussion and see if we can do some sharing.

Sharing my thoughts on Microsoft ...

My early career was built on Microsoft.  I graduated high school in the early 80's just as the IBM PC started to be sold.  Yep, aging myself.  Anyhow, after learning BASIC and Fortran on a DEC 1170 - I migrated to programming on an IBM PC using BASIC and then learning PASCAL and Assembler.  Then I learned dBase III and Clipper - learning to program against databases.  All on a PC with floppy drives - yep, no hard drives at that time, just dual floppies where you needed to swap disks to manage all of the data.  None of this would have been possible without the OS that Microsoft built and licensed to IBM.

Then in marched the IBM compatibles - Compaq the most successful in the early days.

Not only was I programming, but I also ended up selling IBM and IBM compatible equipment.  The company I worked for let me lug around a Compaq portable while I worked for them.  I had access to Microsoft compilers for Basic and Assembler, and used Borlands Pascal.  The company I worked for also had me teaching programming courses.

Along the way we transitioned to Windows and I learned how to program using MS Visual Basic.  This became my bread and butter for quite some time - allowing 2 buddies and I to eventually open our own consulting firm.  We built a healthy practice, hiring additional developers and working for several local and national companies.

I was able to enter the field of software development right as Microsoft was transitioning the industry.  Moving us all from monolithic computers operating in the back room to a vision of a computer on everyone's desk.  I knew the first time that I saw the IBM PC - that it was my future.  I didn't look back - I wanted nothing to do with the mainframe class machines, I wanted to figure out how these small (by the standards at that time) boxes could be used in business.  And oh how the world turns as I know manage development activity on mainframe class machines and Unix/Linux clusters.

For a long time - Microsoft owned the development community.  They created tools that allowed us to transform the industry, thereby further fueling their growth.

Then Microsoft lost it's way - it became more focused on protecting it's cash cow and locking developers into their environment.  Companies attempted to displace Microsoft and turn us onto their platform, but most failed.  Then along came the browser and smartphones - to say Microsoft was not ready would be an understatement.  They nearly lost the browser wars and only woke up at the last minute to use their monopoly power of the OS to win the browser war.  The smartphone is a different story.  Windows Phone is an also ran and I'm not sure Microsoft will ever have the chance to be a driving platform within the phone space.  Oh, they'll stay in, but in my opinion, they won't truly compete with Google or Apple.  They missed the boat.

On the desktop Win8 was a colossal fail - yes, they can brag about the numbers sold, but most companies are using the license terms to downgrade to Win7.  I personally hate Win8 - it's a mindless combination of OS modes that make no sense on the desktop.  Win8 may be pretty on a tablet and phone, but on the desktop it only irritates.  Where I used to regularly recommend Windows equipped laptops and desktops to friends and family, I've now moved to pushing Apple's ecosystem.  Many people only need an iPad, and for those that need more, the MacBook Air,  MacBook Pro, iMacs and Mac mini's are the choice.

And this is a stunning development - ask my family and friends, for a long, long time I viewed Apple skeptically and always thought they were too expensive.  Well, you may pay more for a Mac, but if that allows me to walk away from the problems that I experience in the Windows environment and mess that they call Win8, it's worth the money.

Where the Apple ecosystem just works, the Microsoft ecosystem confuses - mindlessly flipping between metro mode and desktop mode, sometimes for no apparent reason.

Of all the expert articles written about this farce of an OS and what Microsoft needs to do to fix it, I vote for Windows Red as documented by InfoWorld.

Can they come back, who knows?  They'll never go away, they're too big and have too much money in the bank.  They would really need to screw up to disappear, not saying it can't happen, but the chances are remote.  They have become the new IBM - too big to fail.  

All that taken into context, the best move they could have made was to ditch Balmer and replace him with Satya Nadella.  I don't think Balmer would ever allow Office on the iPad, and while the package introduced by Nadella is handicapped, it's at least a start.  Microsoft appears to be making some steps to stop the ship from sinking - I wish them well, but really wish they'd kill the FrankenOS on the desktop.

I know this has nothing to do with Project Management or specifically with software development, but I thought I needed to do a mind dump on this topic.

Tags: IBM; Microsoft; Windows 7; Windows 8; Win7; Win8; Change;

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

Languages, Languages, Languages ...

I speak regularly with High School and College level students promoting careers in technology - specifically careers with Applications Development, Quality Assurance and Project Management.  I enjoy interacting with the students and telling them what they may experience as they transition from the role of a student into the professional workforce.  Along the way, I also ask students to think about interning - either with my organization or some other organization in the area.  This is a fantastic opportunity for students to get real-world experience, become visible to an employer, and begin to understand some of the concepts taught in the classroom as they apply them to tasks in the workplace.

Many times, students ask me why we use the languages that we use and why we don't take advantage of the latest scripting or language fad.

My answer - why should I?  They seem to be stumped by my response.

Well, really, why should I?  Why should my team be disrupted on a regular basis just to use the latest language fad?  Why should I continually experience a productivity loss as team members shift between languages?  Why should I take the risk of bugs being introduced into production systems because the developers are not experienced with the language/tools that they are using?  Why should I risk customers being subjected to performance issues because the developers haven't figured out how to optimize the programs they're creating?  Why should I make the on-boarding experience for new developers more difficult?

Look, there are a handful of languages that we've committed to within our organization.  Four languages are used to generate all of our production level systems.  A couple of additional scripting languages have been used to create internal tools that assist us in production setup, as well as assisting us in ripping through logs to find specific information when we are researching issues in our environment.

Programming languages are programming languages - if you're a good programmer, you can pickup any language.  If you're a good developer, you understand that once you understand the various constructs of a language - learning a new language simply means translating the specific syntax of the language you want to learn to the languages you already understand.  It's translating how to use an if statement, a loop, a case statement, etc.  

Let's say it take you a month to become familiar with the new language - assume that your productivity drops by 50% and for 6 months after your initial learning period, you're running at only 75% productivity.  That means that over a 7 month period - you're productivity has cost the organization 8 weeks of development time.  Now multiply that across the entire team.  Assume their are 10 members on the team - that's a total of 80 weeks of lost development effort.  Assuming this same 10 member team and an average of 2 weeks vacation time for each team member - you have a total of 500 weeks that you can allocate to development efforts.  The end result is that you've stripped the team of 16% of the overall capacity of the team for the year.

Now, the numbers discussed above don't even take into account the impacts down the line as we move through test, implementation and post-implementation support.  How much more time will the Development Team need to create and execute unit tests?  How much time will the Development Team need to perform integration and regression testing?  How much time will the Development Team need to perform load testing?  How much extra time will the Quality Assurance Team need to test the application?  What additional issues will be experienced during the implementation of the code into production?  Can you quantify the number of additional issues that will be identified post-implementation that will need to be fixed and how much additional time it will take to address those issues?
 
The impact on productivity across the organization is significant and material - that is real time that prevents projects from being initiated or completed.  That's time that allows your competitors to either close the gap or get further ahead.

I don't mind taking on a new language when there is a need, or when there is a specific purpose.  Over the last couple of years, we've actually brought in specific tools that have allowed us to move in to the mobile market.  At this point, a select number of developers within the overall team have been exposed to these new tools.  Over time additional developers will be brought in to the loop.  Here, there is a specific need - our tools at the time did not lend themselves to creating cutting edge mobile apps.

Take a step back and look at the decisions being made within your organization.  There's usually a reason that organizations aren't moving as quickly from one language to another as developers would like.  To the developers that would like to get an organization to change - don't just go in and say that you need to be able to use a new language.  Document what you feel the benefits are, and just as importantly recognize the impact to the organization and craft your discussion points to address the costs that the organization will incur.


Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making;

For more information on David L. Collison: LinkedIn Profile

Where do you want to work and live?

I spend quite a bit of time visiting with college age students in the Des Moines Metro area and I get quite a few questions from them asking why they should stay in the area after they graduate.  My reply - there has never been a better time to be young and working in the Des Moines Metro area.  Let's look at some of the recognition received by the metro area in just the last couple of years.

Some of the awards received in 2013:

• #2 Best City to Start a Business (March 19, 2013 The Street)
• Des Moines Ranks in Top Ten of Most Unexpected Cities for High-Tech Innovation (April 8, 2013 Techie.com)
• Des Moines Tops List Of The Best Places For Business And Careers (August 7, 2013 Forbes)
• Des Moines is #3 for Top Emerging Downtowns in US (March 25, 2013 Forbes)
• Des Moines Farmers’ Market ranked #2 on this list of 101 (August 29, 2013 thedailymeal.com)
• Waukee and Ankeny both land on CNN Money's "Best Places To Live" list (August 12, 2013 CNN Money)

Some of the awards received in 2012:

• Des Moines ranks top 6 for Cities where startups are thriving (November 28, 2012 CNN Money)
• Clive ranked in Top 10 Small Towns (September 20, 2012 Livability.com)
• Iowa is the #3 best state to be young in America (August 28, 2012 Business Insider) 
• Des Moines #1 best city for families (July 25, 2012 Kiplinger)
• Des Moines is the fourth best city for business and careers (June 27, 2012 Forbes)
• Des Moines is #2 for strongest local economy (May 31, 2012 POLICOM) 

That's a lot of awards, and there are more that I didn't include in the list.  This speaks to a strong, vibrant economy that provides great opportunities to young individuals looking to enter the professional work force.  You can find start-ups, thriving small business as well as some of the larger financial services and insurance companies in the United States.  There are successful small business incubators helping to build businesses around ideas.

On top of the professional opportunities, the communities provide abundant recreational opportunities for people of all ages.  Sports and concerts at the Wells Fargo Center;  Hockey; trail systems that connect all of the communities in the metro area;  mountain bike trails; the Iowa Speedway located less than an hour from the metro-area; the Des Moines Theatre; the Des Moines Performing Arts. 

I challenge each of these students to find something that they love and turn it in to a career!

Tags:Community; Location; Des Moines; Students;
 
For more information on David L. Collison: LinkedIn Profile

Management - Leading, Coaching, Mentoring!

Well, I think it's time to switch up topics again.  With this posting, I'd like to change lanes and look at the human aspect of management.  As Leaders and Managers within the technology field, we need to be able to shift from the technical aspects of our jobs and deal with the individual team members at the drop of a hat.

Whether we realize it or not, we swing between different roles during the day as we move between issues and projects.  Depending on what is happening, we need to get in to the technical details of a specific sub-system or project; an hour later we may need to display our ability to drive to a decision; in another moment we may need to handle a disagreement or communication issue between two members of our team; or, we may need to mentor or coach an employee to continue their growth as they prepare for new opportunities.  Day to day, our bearings shift as we navigate between the various events that surface, that want to take us off task.

As I look back on my career - and, yes, it has been an interesting ride with paths yet to be explored - I think the toughest shift I've made was when I went from being the programmer pounding out code to a manager no longer responsible for creating the code.  I've touched on this subject before, so I won't belabor the issue.  That said, hitting that particular brick wall made me assess what my role was, what was important for me to focus on and what I needed to "give up".  My boss at the time let it happen and I give him a lot of credit for giving me the space to fail and then sitting me down and forcing me to understand my role.

As my boss pointed out to me at the time - I was there not to be the technical expert, but to mentor and guide the people on my team; to remove the roadblocks and ensure that my people knew what it was they were supposed to do and ensure that they were provided the proper resources to get it done.  I was there to keep them focused and to deliver results.  Along the way, I learned that there were limits to what I could do and that I would never be able to provide all of the resources that my teams wanted.  Nor could I feasibly address every project that was requested - it was up to me to find the balance between what was requested and what the company and the available resources could provide.

Now, all that said, I earned some bruises along the way.  There were times as a young manager, I didn't necessarily treat people the way that they should have been treated - sometimes my driver personality got the better of me and I ended up doing or saying something that wasn't as well thought out as it should have been.  In those moments, I was lucky enough to have a boss that continued to coach me, to teach me how to smooth the edges.  These learning experiences through several mentors have shaped me in to the role that I play today.  Do I still sometimes let the driver in me get the better part of me - yep, but it happens a lot less than it used to these days.

People that I respected took the time to invest in me.  They knew when I was at a point that I needed a stretch goal; they knew when it was time to take me out of my comfort zone; they gave me room to make mistakes and fail; they let me come and ask questions; they let me make a difference.  And when needed, they pulled me back from the abyss.  Even today, I am mentored by someone that I respect and that I feel is pushing me and preparing me for that next step in my career.

Not every boss I've ever had was a mentor - I've had my share of clunkers along the way.  Case in point, the boss that flew in to town right after my department had been moved under his to inform me, and I quote, "I don't know what it is you do, I don't want to know what it is you do, if you need something, tell me who I need to talk to and what I need to say".  Yikes!  Or, there was the owner of a company that I worked for that felt it was appropriate to verbally abuse everyone on her staff - the rush for the door was quick once it started and to this day I'm sure she never understood the message.

Somewhere along the way, I learned that I could also be a mentor.  Not everyone wants a mentor, but to those that do, I attempt to be available.  Sometimes, I identify someone who I think has the potential to act in a different role and I initiate the conversation.  Sometimes individuals ask if I would be interested in giving them guidance.  Sometimes these people report to me or within my organization.  Sometimes these people don't even work for the same company I work for.  However, it's my turn to give something back.

What are you giving back to your teams?  Who is it that your mentoring so that they can take that next step?

Tags: Leadership, Mentoring, Management, Lifecycle, Software Development

For more information on David L. Collison: LinkedIn Profile