Out of the Darkness comes Light …

I really liked one of the first professional programming jobs that I ever had.  The people were great, I learned a lot on a daily basis, we had fun at work and after we left work.  I made great friends.  We had good clients – sometimes they were demanding, but nothing too unreasonable.  The company was stable and seemed to have a bright future.  While I did put in extra hours, it wasn’t required and I got recognized for the effort.  They let me play with new technology and I got to interact with development teams at some of the significant players in the industry, at least they were at that point in time.  So, the question is, why did I leave?

Although I really liked the people, the technology, the product we built and the customers – there was one thing that overshadowed everything else … the person who ran the company.  We’ll call her Edna.

Edna was great at sales – she could walk in to a room and convince anyone and everyone that she had the cure for cancer, if they’d just sign on the dotted line.  The issue – Edna had no clue how to interact with her team in the office, she did not understand what it meant to develop software and didn’t want to take any time to at least understand what it was that her team did.  This company lived off of the software that was built by an incredibly talented group of individuals.  And I’m not just talking the developers – top to bottom, the company had some incredibly talented people: business analysts, customer support, finance, marketing and development.

Edna consistently put a strain on this team because she had no idea how long it took to actually develop new functionality.  She would get in front of the customer, who would request some unique feature, and then put promised delivery dates in the contract.  Edna didn’t take the time upfront to discuss the “concept” with the team, so we were always under the gun to create the latest “whiz bang” that had been promised our latest customer.

Now, before you fire back, yes, I realize that when the product that is being marketed is a software package – that during the sales process, there are most likely going to be customizations that are requested.  And, I actually do understand that it is the development teams’ responsibility to deliver those customizations.

My problem was that we had no time to plan.  We were constantly shifting from one emergency to the next, as we scrambled to accommodate the latest promise.
To top this off, Edna’s style of management consisted of pulling people in to a room to have a meeting, and then berating them because they weren’t moving fast enough.  Really?  So I got the specs last week.  Oh, and by the way, the specs are woefully incomplete and now you’re not satisfied that I’m not making enough progress.

One day I went in to work and was immediately pulled in to a “meeting”.  There were six to eight of us in the room with Edna, and the meeting lasted the entire day.  Not one person was left unscathed during the 8 hour marathon session.  Edna had made promises, and by God we were going to work to make sure that the necessary functionality was complete by the date she had put in the contract.  While I was just a developer at that point, I clearly remember the senior manager in charge of all the development teams attempting to shield the rest of us.  It didn’t work – she blasted him with everything she had, in front of all of us, and then methodically worked her way through the room.  She had no respect for the people in that room – not her managers and clearly not the team members.

I left the building feeling miserable.  I didn’t know what else I could do – we had all been working hard on this latest project and were making excellent progress.  Yet nothing we were doing seemed to make Edna happy.

I got home, and it couldn’t have been more than 30 minutes when the phone rang.  I remember looking at my wife, telling her it was probably Edna, and to let Edna know that I hadn’t gotten home yet.  My wife answered the call and then told me that I needed to take the call.  The call ended up being the human resources contact for a company that I had interviewed with 6 months prior – the position had been on hold, but was open again and she wanted to know if I’d take the job.  I didn’t have to think for more than 2 seconds before I answered with a big “YES”!

As I left that job and moved on, I made a promise to myself.  That if I ever became a manager, I would never treat people the way that I’d seen Edna treat her team.  I really did like the team that I worked with – I think about those days every once in a while, at least the ones where Edna wasn’t in the office.

I’m not sure that I understand the mentality of management by fear.  I do recognize it when I see it, it’s not pretty and it’s very destructive to those that have to work within its grip.

I’m not saying that people can’t have passionate discussions.  That’s only fair – I think some of the most incredible leaders I’ve met know how to encourage these types of discussions.  It really does allow teams to break through tough problems.  The difference is leaders that know how to do this properly, know how to manage the flow of the “discussion” so that it doesn’t become personal.  They also know how to get people to listen what is being said, so that teams can understand what is possible.

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #leadership, #management

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

As Leaders we need to Support our Teams...

So, here it is very early on a Sunday morning – I mean really early, 2:00AM to be exact.  And, I’m in the office.  I don’t really need to be here.  If you want to get down to the nuts and bolts, I’m not actually here to do anything!  The team is implementing some changes to one of our key applications tonight.  The best time to do this is in the middle of the night when transaction volume drops significantly.  So if I’m not here to do anything, why am I here?

In the building tonight is everyone from the project manager, developers, architects, database architects, to infrastructure team members.  They have the implementation plan documented forwards and backwards – in fact, most of the implementation plan has been executed in the last week as we’ve moved chunks of code in to the production environment.  Not only have they documented the implementation, but they’ve practiced the implementation and rollback steps in our parallel environment.  Making sure that each step has been identified and that we know how long each step should theoretically take.

These are good people – that take their roles in the organization seriously and who are passionate about making sure that we provide the best service possible across our network.  Not just good people, great people!

So, again, why am I here?  The people running the implementation tonight are competent and can handle any situation that comes up.  They don’t need me looking over their shoulder asking questions – in fact if I did, all that would do would be to slow things down.

There are really two reasons that I’m on site:

• My being here shows the team that I care and that I’m not putting myself above them.  If I’m asking them to come in during the middle of the night – then I should be willing to walk in that door with them.
• I’m here to act as a communication point if something does go wrong.  The last thing that I want the team to worry about if the stuff hits the fan is to call me to tell me there is a problem.  It’s actually my job to be here and if there is a problem clear any roadblocks, take responsibility to inform my boss, our CIO, and potentially the rest of the Senior Management Team.

Yes, I live just minutes from the office and can easily be on-site within 15 minutes.  It would be easy for me to stay at home and head to bed instead of staying up all night.  But does that show the team that I’m willing to be a part of the team?  No!

My small effort to support the team has been noticed and is appreciated.  I’ve had development team members, as well as people that don’t report up through the parts of the organization that I manage stop me as I roam the building and thank me for coming in.  They feel better knowing that I’m there, that I’m willing to help and that I’m willing to try and take some of the burden off their shoulders if push comes to shove and something goes wrong.

The good thing is that I rarely have to engage during these implementations.  Because I trust the team to do their jobs and because I know that they care.  I’m here in a support role and that’s ok!

How do you show your team members that you are part of the team and that your willing to step in and support them?

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #leaders, #leadership

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

Testing is NOT an Afterthought …

Many years ago, I had been hired as a programmer for a small firm.  My first assignment was to take the accounting package that the firm was already selling and modify the package to work for manufactures.  I literally was given this assignment my first day on the job.  There was a deadline on getting this done and I was actually given a PC to take to my apartment and do the work – and no, there was no such thing as an internet to connect back in to the office.

I worked round the clock – not being married at the time, and new in town, it really didn’t bother me.  I would go in to the office a couple of afternoons each week to work with the test team and to show my manager the progress that was being made.  At the time, I remember thinking – “why are these guys picking on me?”  They would take issue with small things that I was sure wouldn’t make a difference – yes, they also found other items that were bigger and I knew I needed to address, but I couldn’t figure out why they were so bothered by little issues on the screens or reports.  This went on for a couple of months until I finished the new package and was then asked to go out and install it for the customer.  All the while I pushed back on all the small changes that the QA team was asking me to make.  In my mind – they were just slowing me down.  It was only when I was on-site with the customer that I finally realized that the QA team wasn’t picking on me.  The customer was elated with the end product – in fact the owner of the company pulled me in at the end of the week to tell me how pleased he was with what had been delivered.  His comments about how much this was going to simplify his people’s lives and how impressed he was with the accuracy of the information being displayed and reported on – what a change it was going to make for his business.  That’s when I realized that the QA Team wasn’t picking on me, they were advocating for the client.

I work in an organization where thousands of transactions can be hitting our switch in any given second.  These are all financial transactions – payments, transfers, deposits, etc.  When you’re out on the road in the middle of the night and hit a gas station to fill up – you want your card to be recognized and the transaction approved.  When you’re out with a group of friends and paying for dinner – you want your card to be recognized and the transaction approved.  When you’re on vacation and paying to get your family in to a hotel – you want your card to be recognized and the transaction approved.  You don’t want to hear the words – hey the network is down and we couldn’t process your payment.

Our systems must work 24 hours a day, 7 days a week, 365 days a year (24x7x365).  Not only must we make sure that each and every transaction coming through our switch gets routed properly for the authorization decision, we must track every transaction on the network and then settle with thousands of financial institutions, merchants and the Fed every night.  That means we must balance down to the penny across all of the cardholders, merchants, financial institutions and ultimately with the Fed every day to actually make the money move between the various accounts.

We can do this because we have great people that are passionate about what it is they do and because we have built processes that allow us to validate our systems before they move in to production.  Quality is not an afterthought!

While we have done a good job with quality – I’m now looking at how we can do this more efficiently within our organization.  To date, we’ve been successful because we are able to take advantage of the wealth of knowledge that we have within our teams.  People who are very passionate about getting it right!

Doing this right means planning it right.  Very early in our processes we must begin to identify how it is we are going to validate what it is we are building.  This isn’t a matter of testing a web page – or as one of our Enterprise Architects would put it, “the fluff”.  This is digging in and validating real-time interfaces between point of sale devices, automated teller machines, our switch, other networks and processors and ultimately our backend billing and reporting systems.  Some of the systems we don’t control.  The systems all pass data among each other through documented interfaces without human interaction.  It all transpires in milliseconds, and must work every time – all the time!

When we are building a system – it can cross multiple silo’d application environments, yet the card holder views it as a transaction.  Our tests must take in to account every part of the transaction – at the terminal are we displaying the correct screens to the cardholder, are we displaying and reacting to all of the buttons properly.  Once the transaction is initiated, we must make sure that the various data elements are represented properly within the messages that move between the terminal and our switch.  Once the transaction hits our switch we must ensure that the data elements are reformatted properly to send to the authorization agent – sometimes that’s us, sometimes that’s other processors off our network.  Then we need to make sure that the data flows to our backend billing systems, reporting and maintenance systems.

This gets very complex, very fast!  So how do we do it?  Have I mentioned our people – they are very good at what they do!  The first thing we do is we plan.  Our QA Analysts, Tech Leads, Subject Matter Experts and Engineers all work together to develop not only the individual unit testing that will be needed on any given application being touched, but more importantly, they plan on how to test all of the integration points between the systems.  This means this group of people breaks down the transaction flow across all of the systems – starting with when the card is swiped to the point where the cardholder sees that the transaction has been approved.  We need to plan to ensure that the test card data is setup properly across all the systems – that means the underlying test data associated with the dummy financial institution that issued the dummy card.  We have to setup test environments representing all of the pieces of the network and touching all of the sub-systems or silo’d applications that the transaction touches.  The integration testing is key to ensuring that we can take those transactions from the point of initiation all the way back to the user seeing the transaction approved, the financial institution getting the proper transaction reporting and settlement, the Fed getting the proper settlement information and the user ultimately being able to see the transaction in their on-line/mobile banking applications and on their monthly statements.

But you can’t just stop at the planning – you have to monitor the execution of the integration test plan.  Are all of the identified tests being executed?  Are you getting the expected results?  What happens if you insert an invalid value in to one of the data elements being passed around the various systems?   Can you prove that the settlement reports are accurate – to the penny?

As a developer, I’ve made my fair share of mistakes.  It always irritates me when I, or someone else, finds an error.  But what irritates me even more is when one of those errors makes its way in to the production environment.

Computers are excellent tools – however, if we don’t take the time to validate the information that we are presenting to our end users, we can lead them to make huge mistakes.  Just think if I made a small mistake on every transaction moving through our switch – that’s millions of transactions every day.  Do you think the cardholders would be happy if I randomly, and without reason, declined their transactions?  Do you think the financial institutions would be happy if I couldn’t tell them which cardholders to debit or credit and how much money needed to move between accounts?  Do you think the Fed would let us stay in business if we couldn’t balance our transactions and give them invalid information on what money needed to move between financial institutions and merchants?

What are you doing to improve the QA processes on the programs you’re creating, the team you’re working on and the organization you represent?

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment, #qa, #qualityassurance

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

Let’s Talk About the Next Generation …

STEM!  It’s where it’s at!  Science, Technology, Engineering and Math!  I’m most interested in promoting the “T” in STEM and getting the next generation to think about careers in Technology.

Here’s some facts …

• Growth of STEM related employment opportunities over the next 10 years is expected to be almost double that of non-STEM opportunities: 17% vs 9.8%.
• Those choosing careers in STEM related fields will see a wage difference of almost 26% in their favor.
• Over the last 10 years, STEM related employment opportunities grew 3x faster than non-STEM related employment.
• Projections for the next 10 years show that STEM related employment opportunities will grow substantially faster than for non-STEM related employment – 29% for professional, scientific and technical careers; 47% for computer systems design; and 58% in management, scientific and technical consulting services.
• Four out of the six highest paying professions are STEM related: Life Physical and Social Science; Business and Financial Operations; Computer and Mathematical; and Management.

Translation: If you want a job after you get out of school, and you want stability and the ability to earn a decent living – you need a background in one of the STEM disciplines.

This means that students going through high school need to be taking courses heavy in math and science to prepare them for college level courses.  I’m by no means saying that this is the only way to break in to these disciplines – but, your chances go down significantly if you are not preparing yourself properly.

Folks, it is our job to be talking about this with our kids and their friends.  Promoting what it is we do, why it is exciting, why we love doing it!  Kids don’t necessarily want to take the math courses or the science courses – it’s our job to encourage and in some cases push them.  They need to understand the long term impact of not being prepared means when they enter the workforce after their education.

For me – it’s all about Technology.  If you’ve read my introduction, you’re aware of the fact that I was introduced to computers by the time I was 12.  Yes, that was a long time ago when they were rare!  Once I touched one, I knew that was what I wanted to do professionally and I’ve been blessed to have done it the last 37 years!  By the way, what I learned in school way back then about computers doesn’t even begin to touch the capabilities that we have today.  Translation, if you want a job that keeps giving you opportunities to grow professionally and personally, I can’t think of a better career!

Find someone – change their life by talking to them about opportunities that exist.  More importantly, the jobs that will be available to them and the money they can earn, by pursuing careers within the STEM fields.  Offer to take your daughter and her friends in to the office and give them a tour.  See if you can talk about what it is you do at your local middle or high school – most teachers that I know love to have guests come in and talk to the students if it can align with the subjects that they are teaching.  Find your Engineering instructor or the instructor that teaches computer classes and offer to be a resource.  If you’re in the medical field – maybe you could spend some time in the biology classes.

Folks, it’s up to us to open the eyes of the next generation!  Can you spare an hour or two every few months to walk in to your local middle school or high school and make a difference?

Sources:
-    http://www.esa.doc.gov/sites/default/files/reports/documents/stemfinalyjuly14_1.pdf
-    http://curiosityintheclassroom.com/media/pdf/Career_Informational_FINAL.pdf
-    http://dpeaflcio.org/wp-content/uploads/The-STEM-workforce-2012.pdf

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

Yes, it is all about the Process …

I’m constantly amazed by the number of people that I talk to within the industry that still run things by the “seat of the pants” methodology.  Let’s acknowledge right up front that operating with no plans is a methodology.  And there are too many organizations that still allow the technology teams to operate under this methodology.

Look at your teams and ask this fundamental question, do you know where your team members are spending their time?  If not, how do you know where to make improvements?  Are they spending their time on activity that is beneficial to the overall goals of the company?  Are they spending their time in meetings that have no purpose?  Are they spending time with busy work that at the end of the day adds no value?

As a consultant, and as a new manager within the companies that I’ve been associated with over the years, one of the first things I do when I walk in the door is to get everyone to start recording where they are spending their time.  I’ve seen companies move from less than 20% productivity on actual approved project activity to over 65% productivity in a matter of months.  Now, I don’t ask for a minute by minute blow – but ask each individual to record when they start and stop working on a particular task.  More importantly, I ask them to record the interruptions.  You know – the simple phone calls or when someone does a drive-by to ask that "simple" question.

If you’ve never done this with your teams, you’ll most likely be shocked at the results.  Some of your best people are getting interrupted so much that they can’t get any work done.  People within the team don’t get enough work assigned and are working on non-productive activity.  By non-productive, I mean work that does not align with the overall goals of the organization and is approved project activity.  Yes, it may be fancy little tool that handles a task done internally, or it may be a change to the routers that someone feels is needed.  However, if it isn’t approved activity, why are they doing it?

The other time waster is the need to do the same task 2, 3, 4 or 5 times because nobody sat down at the front end of the assignment to explain what was really needed.  So the developer, or the infrastructure engineer, tackles the problem, just to find out at the end that they’ve done the wrong thing and the customer is not happy with the results.

Why do we put up with the fact that we are paying someone to do the same thing over and over?  Isn’t it counterproductive to rush something in to production – just to see it fail?  I don’t care if it is a new software patch or a new switch moving in to the infrastructure environment.  If you haven’t put a plan in place on how to assess what it is you’re doing, build, configure and implement in to production – you’re risking on outage for your customers or the fact that you might allow invalid/incorrect transactions in to your system.

Granted, everything comes with a risk and it is valid to make decisions to skip parts of your process if it is a low risk change.  However, the higher the risk, the more important it is that you follow some level of process that includes planning the change, building, testing, planning the implementation and just as importantly, planning the fallback.

Every organization is different and there isn’t a one size fits all model to how you need to manage the processes within your organization.  Your goal as a leader is to evaluate what process is right within the organization you manage and then manage to that process.  Work with your teams to communicate the importance of the process and how it will improve their lives.  Work across the organization with your peers to sell the process and show what the savings will be to the company and how the company should see increase productivity.  You’re not going to make the change overnight, but if you don’t start, you’ll never get the changes put in place.

I’ll leave this with one last question – if you’re not measuring it, how do you plan to fix it?

Tags: #sdlc, #softwaredevelopment, #lifecycle, #process, #applicationdevelopment

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