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