How are we Leading our Teams?

Today I want to address the human aspect of management.  Let’s face it, as leaders, we rise and fall based on the success of the team members that we manage.  

The best lesson I’ve ever learned in my years as a manager: ensure that the individuals within your team are recognized for the successes that they have and take responsibility when things go wrong.

Now that doesn’t mean that team members are not held accountable - but that they need breathing room to occasionally make mistakes and to learn from those mistakes.  The trick is knowing when to give them room to fail - it can’t be a project or task that is critical.  You need to find instances where a mistake won’t cause irreparable harm to the company or to your customers.

I’m not saying that I’m anywhere close to being an expert at this, but I do try and keep several things in mind as I “manage” team members within the organization.

1. Working together, have I been able to determine the strengths of the individual?  Am I giving them assignments that play to their strengths?
2. Have I set clear expectations of what the end result is for the task/project that they have been assigned?
3. When they hit a roadblock, do I listen to the individual and allow them an opportunity to define a path forward?
4. Am I spending enough time with the individual?  Do they have time with me to explore questions that they may have?
5. When they do fail - do I back them up?  Do I help them clean up the mess and move forward?

I’ll tackle the last point first - as a team, we all need to know that failure is ok.  Seriously, technology is changing every day.  We are expecting our team members to stay on top of the new features, products, languages, hardware and to have the answers.  Many of us are learning as we go.  Yes, we occasionally are heading out to seminars, or Googling for answers, but, the reality is that in many instances we are learning technology as we are building solutions to integrate into the enterprise.  Failure is going to happen.  You can somewhat mitigate the opportunity for failure by giving people stretch experience on non-critical projects/tasks, but you ultimately will end up having a failure.

So, it’s not if your team member will have a failure somewhere along the path, but when he/she will have a failure.  Your job as a leader is to mitigate the risk of failure by identifying the right times and places for individuals to be put in positions where they can fail.  And the team needs to understand that everyone is going to fail at some point.  But, failing on the same type of issue twice is not acceptable.  As an individual, we need to accept the risk of failure, acknowledge that it is ok, but take responsibility to ensure that it doesn’t happen again.  In fact, I recently read an article about an organization where the team members all took responsibility to help clean up the mess any time someone failed - the first time!  After that, if an individual team member failed again doing the same/similar task, they were held accountable to clean up the mess on their own - no help from the team.  This is not something that I personally have implemented, but I like the concept and may take a look at working it in to the overall way that my teams operate.

Let’s hop back to the first point from the list.  Knowing the strengths of the individual team members.  I’m not a fan of managing people to their weaknesses.  It is stressful for the individual and usually means that they are operating in a manner which promotes errors.  I’m much more focused on finding talent and focusing the hiring process around the needs that I have and how to find people with the characteristics, knowledge, experience and ability to successfully perform the role - hire for the individuals strengths and then amplify those strengths within the projects/activities/tasks that they are assigned.  It also means balancing these strengths across a team.  Sometimes for specific roles you can look for the same strengths, but more often than not, you actually want to find people with different strengths to form a team.

I’m not making the claim that individual can’t learn - they can, otherwise we, as a species, would never have learned how to leave the forest and build the culture of humanity.  That said, it is more reasonable to assume that an individual learn to hone their natural skills, knowledge and talents.  It is also reasonable to assume that attempting to stretch a person to become comfortable with areas where they show no predisposition to success will be a challenge.  Yes, they may learn the fundamentals, but they will most likely never really be comfortable within skills, knowledge and talents that they were forced to learn.  They may figure out how to compensate for the weakness, but along the way, they will most likely encounter serious resistance from within.

My second point - setting clear goals.  Too often, as leaders, we forget to clearly communicate the end goal.  This leads to a big gray area that promotes miscommunication within the team, lack of focus by individual team members and exponentially increases the risk to the organization by promoting a project that will go over budget and not deliver to the real needs of the user community.  It is important to define the end results - people need an understanding of what it is you are looking for, how you will claim success.  

I once had a manager that showed me a pyramid with 4 layers and had me measure the goals against these layers.  The layers were as follows:

1. Base layer - the bottom of the pyramid.  The customer.
2. 2nd layer up from the bottom of the pyramid.  The owners.
3. 3rd layer up from the bottom of the pyramid: The company.
4. 4th layer up from the bottom - the tip of the pyramid: The individual team member.

With every project, I was asked to identify the goals/outcomes for the project and prove that each individual goal/outcome satisfied each of the above groups.  Note - the last group satisfied is the individual team member.

My third point - opening my ears instead of my mouth.  Look, everyone is going to hit a roadblock.  It is human nature.  Not everything goes right, all of the time.  Someone has a bad day and forgets to do ‘x’, then ‘y’ fails and you end up having a bad day.  Sometimes, through no fault of their own, something shifts - an external vendor can’t deliver on time, a piece of hardware that was working yesterday has just failed, one of the key resources on the project was just admitted to the hospital and won’t be back for over a month - and they are left holding the bag.  When this happens, they are going to want to come in, sit down and tell you about it.  Your first instinct is going to be to jump to the answer, when in fact it should be to let the person wind their way through to a solution.  

Amazingly enough, most people will find the solution as they walk you through the problem that they are having.  If not, this is a mentoring opportunity.  Don’t tell them the answer, let them talk, ask them questions, give them hints, but make them find a solution.  It may not be your solution, it may not be the best solution, but if it gets the job done, it doesn’t damage the customer or put the company at risk, it isn’t illegal or immoral, let it happen.  It can be cleaned up later.  What you are really doing is showing the individual that you have confidence in their ability to find a solution.

And finally, the fourth bullet point - am I spending quality time with my individual team members?  Part of the contract, when you assume the mantle of leadership is to act as a mentor.  Everyone of the folks that you lead has their own personal goals.  What are you doing to help those individuals achieve the things that are important in their lives?  You need to find time on your calendar for everyone of your team members to be able to talk with you about their personal growth.  This means understanding what drives them, what they feel their natural skills/talents are, how to motivate them, and how to challenge them to hone their skills and talents.  It means finding a way to expose their professional passion and letting it grow.  Yes, their needs to be a common thread that ties the individual growth to the needs of the customer, the organization and the team.  Your job is to find the thread!

What are you doing to show your team members that you understand what drives them and that you are helping them to achieve their goals?

Tags: #SDLC #softwaredevelopment #lifecycle  #applicationdevelopment #leader

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

Until it's in Production, it doesn't matter ...

It doesn’t really matter until it’s in production!

Yep, we can all work hard, play and enjoy what we are doing, but it doesn’t count until we’ve packaged it all up, wrapped it in a bow and moved it into production.  But, that being said, how many of you are planning your implementations vs just moving them into production.  And, yes, just moving them into production is a plan - not, a very good plan, but it is a plan.  Similar to my comments on no process being a process.

So, let me ask this question - if you’re “just moving it into production”, how much time do you spend afterwards cleaning up the mess:

1. Oh, forgot to update my stored queries to account for the new data elements that I implemented in my users table.
2. Oops, what’s that, the billing app doesn’t recognize the new billing codes that were implemented along with our new service?
3. Argh, Bob didn’t tell me that I needed to move that property file into the models directory.
4. Why didn’t someone tell me that the XML configuration file needed to be updated?
5. Great, we forgot to begin replicating the new data elements into the warehouse, management’s reports are all busted.
6. Are you kidding me, we’re getting calls saying that the install is bombing out - they’re getting some message about a missing property file.

When I speak with students, I try and get them to understand that coding is actually a small part of what they need to be concerned about as a professional software engineer.  They need to think through all of the phases of the lifecycle.  Side note: a frustration point - our higher educational institutions for the most part skip a great deal of the software development lifecycle.

If students are going to successfully transition into the workplace, they are going to need to understand and hold themselves accountable for the entire lifecycle - that means everything from the initial vision all the way through to ensuring that the final product can be installed in a production environment or shipped out the door/over the internet to be installed by the final end user:

1. Scoping/Discovery: In many organizations, the software engineers work alongside partners across the business organization to define what will/will not be included within the specific release.  Today, it is difficult for non-technical resources to solely make these decisions as technology is pervasive within the business and the technical resources understand the various capabilities and constraints of the systems being developed/modified.
2. Requirements: Some organizations make it the responsibility of the software engineers to drive discussions and document the requirements for a particular application.  Even if the software engineers are not responsible, they need to understand how to read the requirements, clarify any outstanding/open issues and use the requirements to drive the rest of the process.
3. Technical Design: Yep, before you start coding you better have a plan in place.  Most developers want to hit the keyboard and start chunking out code.  As much as I like to code, I’ve learned over the years that planning is the better part of coding.  It will more than pay for itself on the back-end.
4. Coding: Finally!  Yep, this is where the rubber meets the road and you get to do what you love to do.
5. Testing: In previous posts, I’ve talked long and hard about testing - in short, don’t forget or you will pay for the transgression.
6. Implementation: I’m done coding, time to move on to the next project.  Hold up there, partner.  Until someone is using your code you’re not going anywhere.  Yes, now that you’re done, you need to put the finishing touches on that present, wrap the bow and hand it over to the users.

See, it’s not just about creation of something wonderful.  It’s also about ensuring that the people that originally wanted this beautiful thing created, actually get to use your masterpiece.

How many of us actually sit down ahead of time and plan how we are going to move our code into production or how we will create the install packages that we deliver to our customers?  How many of us actually execute the implementation plan to ensure that we have identified every step, every property file, every change to the database, the removal of files that are no longer needed, the removal of data no longer needed, the removal of property files or registry entries no longer needed?

And, by the way, you also need to plan a graceful fallback!  If you’re in the middle of the implementation and something starts to go bad - can you back out?  How do you back out the changes?  Can you put Humpty Dumpty back together again so that your users can go about their business?  More importantly, have you just shut down the companies ability to make money?  Don’t place yourself in a career limiting situation just because you didn’t plan.

None of this is rocket science, but if you don’t go through the exercise you will get caught.  You may be able to move minor projects into production without too much concern, but I guarantee the bigger the project, the more interconnections with other systems, you will need to have a plan.

Hey, but I’m on a 2 week sprint and the system automatically performs the build and moves things into production.  It does it in the middle of the night, nobody even has to be there.  Has it ever failed?  If it does, what will you do?  Can you promise your manager that you’re not going to take the site down for a day because the auto-build/deploy process broke?  Have you ever walked in the morning after one of your automated installs to have calls coming in from your user community because something isn’t working right?

I work for an organization whose systems must be accessible 24x7x365.  We don’t get downtime to perform installs on our OLTP engine - we need to replace pieces in flight without interrupting our ability to handle transactions.  Luckily on our other applications, we can take small outages in the middle of the night to install our code.  That said, those windows are extremely tight and we must have things planned extremely well so that we don’t waste time and that we can recover quickly if something does go sideways.

The teams that I have the pleasure of being associated with, plan extensively to ensure that our OLTP engine is always available - even when we are installing new pieces of code.  They also ensure that on our offline systems the outages are as small as possible.  This takes time and energy to do right.  Yes, we have automated some of the pieces, but there are still steps we take manually to ensure that we have proper gating through the implementation process.  We test our implementation plan, and if it is a critical system, we’ll actually test the fallback plan to ensure that we can back changes out quickly.  The teams are on-site for the implementations and we are monitoring our systems to ensure that transactions continue to flow and that entries propagate through the various systems accurately.  Monitoring is a key driver for the success of our installs - there are typically checkpoints along the way where we validate certain events across the system.

So, the question is, how are you your teams implementing code into the production environment?

Tags: #SDLC #softwaredevelopment #qa #lifecycle #implementation

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

Our Problems are Small

Over this last week, I had the opportunity to listen to several speakers.  A couple of the speakers discussed the topic of success - what it means and how they have gone about building success within their lives.  I was then able to listen to a speaker challenge a group of 200 people on what steps they needed to take to improve the return on investment for the products that they provide to their customers.  And finally, I listened to a war hero tell his story - growing up in the mid-west, graduating from West Point, becoming a pilot, being shot down and captured by the enemy and held for 6 years in an 8’x8’ cell before returning home to America.

There was a constant thread through the stories and presentations, and a final lesson that placed a bow on the lessons of the week.

1. Adversity is a gift that forces us to reach into ourselves and through hope, faith, persistence, resilience, intelligence and ingenuity we can overcome anything.
2. We are not victims.
3. Challenge yourself and those around you to bring a positive attitude to work.
4. Treat the people you meet as friends - not as simple business acquaintances.

And the final lesson of the week - you can probably guess.  The problems that we face within our daily lives are pretty insignificant when compared to the reality of a war hero’s story!

Adversity is a gift - oh, really!  In a nutshell, yes.  Think about it, if you got everything that you wanted in life, when you wanted it, would you be the person you are today?  I would venture to place a wager that you are just like me and that many of the lessons that you have learned, that make you better at what you do today, came out of situations that went wrong.  Those times that you crashed into the wall and had to pick up the pieces to make it right.  Those are the lessons where you learn what not to do - and aren’t they some of the most important lessons you have learned?

We are not victims!  I’m not saying that things don’t go wrong - they do.  I’m not saying that sometimes someone else may have caused the pain your feeling - they will.  I am saying that each of us has within us the power to change the rules of the game that is being played.  We are not some pawn in a whack-a-mole game that has no choice but to raise our head above the playing surface, just to be smacked down with a hammer.  Each of us the ability to learn and to make choices that allow us to change the trajectory of the path we are on.  We do not have to accept the status quo.

Bring a positive attitude to work!  This is actually tougher than it sounds.  Work is not easy.  We don’t always get along with the people that we spend time with,   Our customers can be demanding.  The piles of work in our queue get larger and larger.  Where does it stop?  Let’s be clear - it won’t stop, but if we manage it right, we can reduce the chaos.  Most of this is prioritizing and realizing what it is we need to work on and what stuff can wait.  In fact - maybe we need to spend some time to stop doing things that don’t matter anymore.  If we truly focus on putting our effort into those things that matter, maybe we’ll be able to smile a little more at work.  To help, we also need to get those around us to smile and be happy.  That means we must talk within our teams and change from the inside out.  One of the speakers showed that it was not necessarily knowledge or effort that allowed a company to accelerate growth - but culture and attitude.  Believing you can win and creating a positive team culture that reinforces the good.

Treat the people you meet as friends!  Many of us - myself included - have grown up in a formal business environment.  This is actually hurting us.  Think about it, how does it make you feel when you greet a friend that you haven’t seen in years!  I’m betting that there is more there than a stiff handshake and a formal greeting - ‘Barb, nice to see you again after all these years.”  So, how do you think your customers feel when they walk into your place of business and receive a simple hello?  Does that make them want to stay?  Do they want to sign a new contract with you?  Do they go out and actively promote your products or services to others in the community?  

At the end of the week, I had the fortune of listening to a decorated war hero - who, with five days left in his tour of duty, was shot down over enemy territory, captured, tortured and held captive for six years.  He spoke softly of his experiences and more importantly the traits that allowed him to live through that experience and come back home.  What allowed him to survive in an 8’x8’ cell with no toilet, no creature comforts and no communication with the outside world.  He was able to weave the lessons of life into his story - how conversations with his high school teachers and coaches were brought in to a new light based on his captivity.  How his personal faith allowed him to persevere and survive captivity.

Folks, the problems that I deal with on a day to day basis, don’t hold a candle to the problems that this man faced in a cell in North Vietnam.  Suddenly, the pressures of decisions that need to be made to move projects through the enterprise and manage my teams don’t feel as significant.

Tags: #management  #leader #workgroup

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

An Hour of your Time!

What’s in an hour?

For as long as I can remember, I’ve always arrived at work early - usually right around an hour early. It’s “my time” and I encourage each one of you to find a slice of the day that is your time.

So, what’s the hour for?  That first hour in the office - alone - allows me to plan the day and clear the desk.  Literally, during that first hour, I ensure that there are no appointments on my calendar and I limit which calls I answer.

I use this time to review my calendar for the day, set daily objectives and to give myself prep time for any last minute items I need to complete so that I’m ready for the day.  More importantly, this simple hour allows me to step outside the normal tactical day to day decisions and gives me a slice of time to think more strategically.

One of the things that my team has always heard from me, is that we must constantly be looking at what it is we are doing, we must ask ourselves what it is we need to change, so that we are ready for where the company will be tomorrow.  Our organization has made significant changes over the last five years - our processes have matured and we have worked hard to open the lines of communication between the various departments.  With all of that, there are still further improvements to be made if we are going to continue to support the strategic goals of the company.  I’ve discussed in recent blogs the changes that my teams are making related to testing.  That didn’t come because of some epiphany I had in the shower one morning - the seeds of those changes began out of research that I was doing during “my time” and that blossomed during conversations with my teams.

Occasionally, my boss will stop by during “my time” and we actually have a chance for a more casual conversation.  Yes, we talk regularly, but what do you talk about with your boss in your scheduled meetings.  More often than not, you’re talking about the tactical - how to move the ball forward on a given effort, what roadblocks need to be removed, departmental issues that he or she needs to be aware of.  When there is that moment of unscheduled time where the two of us can sit down together - I learn a lot.  One, he has been with the company for many years and he is able to provide me the history and background on why some things operate the way that they do.  Two, he is able to give me insight into some of the strategic decisions that are being made, which gives me a firmer foundation when I go out and discuss with my team.  Three, he has very deep knowledge of how the industry operates and the key players within the industry - it is a great learning experience as I continue to evolve as leader within the organization.

Another important reason for this time - is my team.  They all know I’m in the office early.  If there is something on their mind that they want to talk about, they all know that they can catch me during that first hour.  It doesn’t happen often, but occasionally, someone will stick their head in my office and ask me if I have a minute.  There isn’t a lot of open slots on my calendar during the day and it can be hard to catch me moving between meetings.  People know that if there is something pressing they can catch me during this time and I’ll be there to listen to whatever it is that is on their mind. Sometimes they just need a sounding board, sometimes they need my assistance.  Either way, they know that is a guaranteed time that they can catch me.  Don’t get me wrong - I’ve always told people, I will clear time on my calendar if they have an issue, but for some people, it’s just easier to catch me without having to formally schedule something.

This has been a familiar pattern in my career.  Arriving early, and using that time to prepare - both at the tactical level and the strategic.  I’m always trying to answer that question of what needs to change.

How are you making sure that you have time in your day to take care of yourself?

Tags: #SDLC #softwaredevelopment #metrics #lifecycle #timemanagement

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

Stepping out of the Comfort Zone

In my last posting, I said I would talk about the most difficult lesson I had to learn as I transitioned from a single contributor to an influencer - in other words “management”.

We’ll look past my jobs as a child - newspaper delivery and working in fast food restaurants.  While these were important in building the values and work ethic that I have today - I want to focus on the technical jobs that I’ve had that allow me to trace the tree branches that have allowed me to obtain the role that I play today.

As mentioned in previous postings - my first job in the computer field was actually doing contract work in my late teens.  What an opportunity.  It was a team of 3 - me, myself and I!  I had to understand the requirements of my client (my dad’s company), turn that into a workable design, make the changes, test the effects of my changes and then implement those changes into production.  I did it after school and worked around the hours I was scheduled to work at the fast food joint where I was employed.  I learned quite a bit and had an immediate impact - when I made a change and moved it to production, I could see the results immediately.  For a teenager - this was a pretty cool.

As I moved on to college, I took a job with a local IBM PC sales organization - responsible for delivery, setup and pickup.  The interesting thing with this job was the direct customer interaction - it wasn’t just the setup, but setup and training.  Getting them to understand how to turn on the PC and load the software that they had purchased.

My next job out of college was selling and installing IBM PC’s.  I also ended up volunteering to teach Lotus 1-2-3 and dBase III courses for the company.  Again, a lot of customer interaction and the opportunity to see an immediate impact with my role.

Let’s look at the role I played as I obtained my first formal development job - working as a programmer for a small IBM VAR/VAD that created customized accounting solutions.  Within this role - very similar to development team members today - I sat in front of a keyboard and banged out code.  Lot’s and lot’s of code.  I could see the results immediately - working with the formal QA Department, we would work together to walk thru what they were seeing, I would make changes, we would wash, rinse and repeat until they were satisfied that the code could be released.  At first I didn’t understand their role - but I eventually learned that they held two interests in mind - protecting the reputation of the company to ensure that when we released something, it worked; and just as importantly representing the the customer and ensuring that they had a voice in the process.

Next up, I worked for a much larger organization that was 24x7.  When software was moved in to the production environment, it had to work.  I moved from shipping discs out the door to having to implement code into a production environment.   Most of the software that I wrote back then was actually used by internal teams.  But, they directly impacted the ability of the company to roll out services to its clients, in other words, they were used beyond the normal business day and had to function for the company to continue to provide services.  It was with this company that I was given the opportunity to move into management role.

Let’s take a look at the experiences and what I had learned up to this point within my career:

1. Communication: Quite a few of the early jobs that I had required me to build relationships and understand how to communicate in non-technical terms.  This may sound easy - but can be quite intimidating for people that are used to working with technology.  You need to rid yourself of the techno-babble, understand the communication style of those you’re working with and speak with terminology that they understand.  My early jobs forced me to learn this skill.
2. Requirements Gathering: These first companies that I worked for didn’t have dedicated teams that wrote requirements.  It was the job of the developer to extract requirements and understand the needs of the end user.
3. Translation - Requirements to Design: Several of these early jobs forced me to understand how to take requirements and turn them into technical designs that I could use to build solutions.  Whether that was when I was selling PC’s or the first contracting or development jobs that I held, there were no architects to do the design work.  I was responsible for coming up with the design and reviewing with my manager before I actually started coding.
4. Coding: Ok, let’s just say it upfront, yes I learned to code in high school and picked up additional training in college.  It wasn’t real world - companies have things you don’t learn on your own and you don’t learn in school.  Not only are you writing things from scratch - you have to maintain code that was written by someone else at some previous point in time.  Back then - in my early jobs, there was no such thing as a network, when you wanted to share code, you had to physically make copies on diskettes and walk them between computers.
5. Testing: In hindsight, my idea of testing when I first started coding for my dad’s company was lacking to say the least.  Heck, I’m still learning new ways and paradigms of testing today - so I’m not going to knock myself too hard, but let’s just say that as I moved between companies I came to appreciate testing.
6. Implementation: Yep, building and bundling code for shipment or production.  Sometimes I learned the hard way, but I eventually figured out that you had to have repeatable processes when you moved anything to production.  Anything else was just plain risky.

So, at this point in my career, I’ve learned how to be an individual contributor where I can see immediate impacts with the activity where I am responsible.  I get an assignment, I work the assignment, the assignment goes into production and something wonderful happens for the customer - well, at least most of the time.  I’ve also learned to create important artifacts/documentation along the way..  Things like requirements, design plans, test plans and implementation plans.  I’ve learned how to work with others to see the chunks of code that I have written being merged into something  larger.

Now the tricky part - moving into management, how tough can it be?  Boy, was I going to learn.

So, I’m promoted to a position for which I’m not prepared - or at least in my mind I’m not prepared.  Obviously, my managers has seen something in me that leads him to believe I can do this role.  At the time, I questioned his sanity!  I liked sitting down and banging away at the keyboard to produce something - in fact, I still do when I get the chance.  However, my professional life turned upside down overnight.  Suddenly, I was no longer sitting with my team working on code, I was now sitting in meetings everyday, being asked to give my opinion on how long things were going to take, and to tell people how long it was going to take to work around problems that were being found.  I was the one being asked to put the “plan” together and provide timelines to others.  I was the one being hunted down to provide answers when the team wasn’t moving as fast as other teams would have wanted.

All I wanted to do was code!  My first reaction to the added pressure was to do what was the comfortable - continue to code.  Yes, I attended meetings and I gave answers - they weren’t necessarily well thought out answers, but they were answers.  Yes, I came up with “project plans”, again, not necessarily the most revealing plans.  But my satisfaction came from slinging code around and building stuff.  My manager was patient - he really did try to show me what I should be doing, but I wasn’t listening.  A sure sign I was in over my head.

What I didn’t realize at the time, is that I was letting the team down.  They were relying on me to keep the pressure off them and by acting the way that I was acting, I was in reality increasing the pressure.  Not understanding the deadlines, over-promising on deliverables and agreeing to things that the team wasn’t able to accomplish within the time-frames promised.

It was a good thing that the manager who promoted me was patient and understood I was going to make mistakes.  But, finally he pulled me into his office for a “chat”.  He asked me what I was doing.  I didn’t have a good answer.

He very slowly peeled back the layers of the onion to show me exactly what I was doing and how it was hurting the team.  He showed me that by focusing on the wrong thing - how much damage was being caused within the team and with my reputation with others.  The most important thing he told me was that it was time to stop coding.  Yes, I had to give up the thing that had allowed me to succeed up to this point in my career.  It didn’t mean I had to stop coding all together - just when there was something else that needed to be done.  He clearly drew out that during normal working hours - it was my job to build relationships within the team, build relationships between my team and the other teams I worked with, be the master of planning, under-promise and over-deliver, figure out the process, master the process, and understand how to provide estimates.

Trust me, this did not happen overnight.  Over a period of months, he etched this message in to my mind.  He reviewed my work plans and gave me hints on how to improve them.  He poked holes in my estimates and made me continue to revise those skills.  He pushed me out of my comfort zone and got me to regularly meet with non-technical teams across the company.  He asked me to develop plans on how to improve the department based on what I was hearing from my peers across the company.  He got me to understand my role was learning how to anticipate and remove roadblocks so that my team could succeed.

Over the years, I’ve accepted the fact that my first job is not to code.  I code now outside of normal business hours - I contribute to things that allow me to stretch my skills as a developer, but that can be done on my own time without deadlines.  My real job has changed me - hopefully for the better.  I’m now comfortable sitting in meetings and contributing in a different way - discussing the whole portfolio of projects underway, how the timelines for each project interact and what it means to the overall pool of team members chunking out the code.  My impact is not on anyone project effort - but on the entire effort of the teams that report up through me and understanding how to align these efforts to the strategic needs of the organization.

So, for the students who’ve asked me how I got to where I am today - you have your answer.  Skill, hard work, and someone who trusted that I could make the change from an individual contributor to an influencer - yes, I’m a manager and I love what I do!

Tags: #SDLC #softwaredevelopment #metrics #lifecycle #work #growth

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