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/

Plan for Success ... Be Aware of Reality!

I run hard! My teams run hard!  We’ve got a lot on our plates and the pipeline is overflowing.  As soon as something is done, there are 5 more things waiting in the wings that need attention.  That’s a good thing – it tells me that the business values the services that my teams deliver on and that we can continue to be a difference maker within the organization.

As we go about our business – we plan for success.  Delivering product and services that our Financial Institutions can use to succeed in the market and make a difference with their customers.  Over the last several years, we have built a process around activity that ensures that we know why we are building something, we know the success factors around what it is we are building and that we then can design, build and QA the stuff we are moving into our production environments.

The teams have done a great job of reducing the number of iterations built before code can move into production.  Translation, they’ve reduce the number of critical errors found during testing that requires additional iterations prior to implementation!  They’ve also significantly reduced the number of issues that require after hours support.  Our teams have worked together to reduce the overall amount of time needed to regression test our products.  We are doing automated nightly builds on our code and are well on our way to having a full suite of regression tests run along with the automated builds.

So why am I talking about all of this?  Well, to put it all in perspective, it doesn’t seem to matter how well we refine the processes and manage the activity, we still have things go wrong!

1. Requirements identified after development is under way. 
2. Designs between teams that sometimes conflict. 
3. Estimates of project activity that end up being woefully incorrect. 
4. Resource constraints across teams just based on the sheer volume of activity. 
5. Data issues within our test environments. 
6. Validation exercises that end up taking longer than planned.

You know the drill.  You’ve all seen similar stuff happen to your projects.  So what’s a team to do?  Well as much as we want to keep our rose colored glasses in place and see sunshine and rainbows, it’s our job as leaders and technical experts to measure and apply a dose of reality within our projects.  The organization is looking to us to deliver new features/functions into the production environment.  They don’t really care to hear about how we make the sausage or why it might be taking longer.  What they do want is a semi-reasonable date as to when the features/functions will be available and what it means to our Financial Institutions and our Acquirers.

So, translating back to our internal teams, that means we need to make reasonable estimates along the way and refine as we move through the process.  As technicians, looking at and identifying the tasks needed to complete the activity – you can’t assume everything will go the way you want and your estimates need to include the breathing room you’ll need when something unexpected pops its head up.  As project managers, you can’t believe everything you’re being told – you need to validate what is being said and ensure people are on track.  Depending on the complexity of the project, you may need to put in some buffer time between the various activities to ensure that the teams have time to stay on track and recover from unknown issues.  This may not be needed on smaller less complex projects, but as the complexity gets bigger, you’d better start thinking seriously about buffer space.

I am not advocating that you needlessly pad time into your projects to make a 6 week effort end up taking 10 weeks.  What I am advocating for is that project resources accurately evaluate their tasks in a realistic fashion and feed those numbers back up to the project manager – that includes identifying the riskiest tasks and ensuring that you’re not being overly optimistic on the estimates.  Additionally, the project manager needs to review those estimates coming in and ensure that the numbers are ‘good’ and make judgements on where additional time may be needed to address parts of the process that look to be difficult.

I’ll give you a perfect example within my own organization.  With our large enterprise wide projects, we perform an integration test within development prior to moving the code into our formal QA and Parallel environments.  We began this formal ‘integration’ test effort probably a year and a half ago.  This testing required us to ensure mock data was setup across various platforms and application silos that would allow us to take transactions across the entire ecosystem.  This was initiated to ensure that by the time the code hit QA that we had successfully tested input/outputs and application handoffs between the various silos.

When we initiated this new step in our overall lifecycle – we were extremely aggressive in how long we thought it would take us to build the environment, populate the environment with the correct data and then execute the integration test plan.  I kept pushing the team to get all this activity done within a short time window so that we could then get into the ‘real’ testing and move the project forward.  Whether planned or not – the time associated with this integration testing took longer than planned and we eventually had to account for that within our planning.  Now that we’ve been through several iterations, we are beginning to automate various pieces of the environment and data setup/configuration – this should help us draw the time back down

Our goals were right, this helped us implement code into production that had a higher level of quality, however, I created a set of false expectations within the teams on the durations associated with this activity and they needed to give me feedback to reset my expectations and identify the correct timeline within the overall project activity. 

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