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/

It's NOT all about you, it's about the Team!

I'm not a success without the people on my team!  Flat and simple - if they aren't succeeding, then I'm failing.  As a leader inside the organization, it's one of my responsibilities to look out for the needs of my team and find ways to make them successful.  I can't guarantee them success every time, but I need to find ways for them to succeed more than they fail and within their failure, I need to recognize that I own some of that failure.

I've seen people that have been great contributors on the team suddenly put themselves in a position where they look like they are going to hit the wall.  I've had to step in-front of them and prevent the smash up that is about to occur.  Sometimes these discussions can be difficult, because they don't want to admit that they are about to fail.  Sometimes there is a look of pure relief on their face when someone steps in and says - hey, I'm here to help.

One of the first projects I worked on after becoming a manager was a fairly mundane project needed within the organization - there were several pieces of the software being developed and one of the pieces was being held up because there was nobody else to work the issue.  I made the decision that I would jump in and work the issue myself.  At this point, my boss asked me why I was working on the code.  I explained to him my logic and he began to ask questions:

• If  you're working on the code - who's going to keep track of all the pieces that are moving within this effort and make sure overall we're on target?
• If you're working on the code - who are your engineers going to escalate the issue to when there's a problem and how will you manage those issues?
• If you're working on the code - who's going to keep myself and the rest of that management team aware of the status, issues, risks and plans?

There were several other questions - but you get the general sense of the conversation,  I was young and eager and for every question he had, I had an answer, me!  My manager made it clear to me that this was not the right answer and that I was going to end up hitting the wall.  I assured him, that I would be able to handle all of it and went on my merry way.

Soon, I began to trip up on myself - at first it was missing a status report here and there, not escalating an issue that needed to be escalated.  Then the impacts grew - I wasn't paying attention to all of the different moving parts and coordinating the delivery.  I hit the wall.  My boss looked me in the eye and asked me what I was going to do to clean it up.  I had failed!  Luckily, he reached out and helped clean up the mess and get the project back on track.  But what he taught me happened after all the pieces had been put back together and the project was again running forward.  He sat me down, told me that this time he had allowed me to fail and had helped me out so that I could learn what not to do going forward!  The next time this happened, if I let it happen, I would need to clean up the mess by myself.

Where to start?  First I learned as a manager, it's tough to be the one in the details and still be the one coordinating everything else that needs to be done.  Two, I learned that sometimes it's alright to let people fail.  Three, I learned that when somebody does fail, you have to be there to pick them up and help them get back on track - give them the ability to learn.

Now in some instances - the failures begin to outweigh the successes and you come to the moment of truth.  Is there a way that I can make this person successful, or have they proven that they are incapable of performing within the role that they've been hired for - a difficult decision.

As leaders - either formal supervisors/managers or informal project managers - it's not enough just to do the tactical parts of the job.  It's essential that we work work with the people we touch in the organization and help lift them up.  Only if we truly give them the tools and skills they need to perform their role and prepare them for more difficult responsibilities in their future, will we reap the rewards and succeed within our own role.

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

Dysfunction within the Team - Breaking down the barriers!

Sometimes I'm left surprised when an issue hits my desk and I begin to work backwards to find out what happened.  In too many instances, I can trace it back to follow-through.  Someone in the organization knew something, or was assigned to do something and for some reason forgot.  What's even more irritating is when I'm the guilty party!

Recently, I was rightfully called out by one of my peers for not communicating a decision impacting a critical project out through the organization.  She had every right to call me out on the lack of communication.  It was my error and I could do nothing but agree with her and acknowledge the failure.  I like to pride myself on the fact that have strong communication skills and working relationships with my peers, and so I take this one personally.  There are many excuses that I could use - I'm too busy as we move several key projects into production ahead of our year end production freeze; the Project Manager should have communicated that out to the team.  Ultimately, I made the decision and I had the responsibility to communicate the decision across the organization - especially when that decision was going to put pressure on other teams across the organization.

This is not unique to myself.  As I began to explore at the beginning of this post, too often I look at the root cause of an issue and it all goes back to someone knew and didn't think to share that knowledge.

I recognize that some of this is human nature.  In the heat of the moment, decisions will be made that we believe will move the process forward and get the entire organization closer to the end goal.  While that may be the case - follow-up is critical.  Let's face it, we've all sat on the receiving end of some decision that made our lives miserable.  We've had to deal with the fallout when that information comes at the last minute.  I will be the first one to step up and call someone out when they do that to myself or one of my teams - it's only fair that I take the feedback when I'm the one causing the problem.

To allow this type of honest feedback - you need to be willing to trust the teams you work with on a daily basis:

1. Your direct reports
2. Your peers within your supervisors team
3. Your peers across the organization with whom you deal with on a daily basis

One of the best books that I've read on this topic was written by Patrick Lencioni, "The Five Dysfunctions of a Team".

This book leads you through a scenario of how a group of individuals that didn't work or trust each other was transformed into a highly functional team.

I was first introduced to this book, by my current boss - our CIO.  It was the first thing that he wanted me to read after I was hired.  In fact, he sent it to me before I even officially started.  It is now one of my favorite books.  I in turn have required all of my direct reports to read the book.  I encourage my team to be honest with each other and to hold each other accountable in their daily interactions.

We have been hired for a purpose.  We are here to make a difference, to move the ball forward.  That means holding ourselves and others accountable for the deliverables that people throughout the organization rely on so that they can do their job.  We must open ourselves up to others, understand the story that is driving their actions and be prepared to receive open and honest feedback when we fail to live up to our commitments.

Don't get me wrong - this isn't a directive for you to walk around the building pointing fingers at people and telling them they're not doing the job - chances are if you did you'd have a line of people at your desk telling you that you didn't do your job.  What you should do is be willing to engage in a positive open communication.  Explain what you are seeing - you may not have a full understanding of the situation and be prepared to change the direction of the conversation based on what you hear.  If the person truly is responsible for failing to deliver, than it's up to you to find a positive way to work with the person and manage the situation.  Help them help you!

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

I Wish I Knew Then, What I Know Now!

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

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

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

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

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

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

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

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

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

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

What about Your Growth …

Too many times, I’ve met with team members who’ve told me that they are frustrated because the company isn’t sending them to off-site training on a regular basis.  Yeah, so?

Look, I have no problem sending people to training to improve their skills or to introduce them to new skills when it makes sense – to accelerate our ability to develop specific tools or to introduce a new technology in to the organization.  However, isn’t it just as important for the individual to take responsibility for staying abreast of what is happening within their field and to identify learning opportunities that keep them in play within their individual profession?  More importantly, people need to realize that there are plenty of learning opportunities within the organization.

Every year, I have my team managers sit down with each team member to discuss and create an individualized learning plan.  I continue to be amazed at the number of people who view this as an exercise of “what is the company going to do for me”.  Folks, it’s not about what the company is going to do for you, but to look ahead and identify what you need to do to take the next step.

1. Do you want to be promoted from an Engineer II to an Engineer III?
2. Do you want to be a team lead?
3. Do you want to be a team manager?
4. Do you want to cross boundaries and maybe develop in a new language?

The conversation between the manager and the team member needs to be open and honest.  What are the goals of the individual and what are the needs of the organization?  Maybe the organization doesn’t need you to cross over and learn a new development language.  That doesn’t mean you can’t learn that on your own.  I learned a handful of languages formally in school – everything else I’ve learned on my own by picking up books or by learning via the internet.

However, in most instances, the team manager is going to be supportive of the goals that individual team members have identified.  They will look to provide internal opportunities to mentor and give the team member the experiences they are looking for to further their professional goals.  At the same time, the team member needs to be willing to listen to the manager and step outside of their comfort zone.  Maybe we are going to ask you to begin mentoring others on the team with specific skill sets that you have.  Maybe we are going to ask you to take the lead role on a project moving through the organization.  Maybe we are going to ask you to get involved in project level design sessions or implementation planning.  And, yes, maybe we will ask you to go off-site to a specific training opportunity.

What everyone needs to understand is that there is some give and take in the process and learning doesn’t necessarily equate to being sent off site for a week in Las Vegas to attend the latest and greatest symposium.  Yes, there are times when I’m going to need to send someone off-site to be exposed to a new technology – but there is a lot of learning that happens within the organization.

I would also add that it is your individual responsibility to stay on top of your field by reading.  Yes, that old fashioned skill we all learned in grade school.  Today, there is a vast amount of information at our fingertips – either on the internet or by actually ordering a book and reading it.  You can browse on the web and learn just about anything you want to today.  I've learned more on my own or being mentored by others in the company vs any formal training I've ever had.

How many of you are taking the time to improve yourself vs waiting for the organization to do it for you?

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