A Business Technology Place

Dunking IT Developers in the river

My disclaimer this week is that I’m writing about an idea in my head. This is not something I’ve tried and have first-hand experience to report. But I’ve got feeling this idea will hold water if we can determine the logistics to make it happen. This I believe.

Setting context.

When I was a cooperative education student at Georgia Tech I was employed by a company in the northern Atlanta suburbs. The company setup a program that rotated two co-op students through different areas of IT so we could gain exposure and experience with different areas. My counterpart and I rotated different school/work quarters. While he worked one quarter I was in school. Then the next academic quarter we flipped. We had assignments in different groups including telephony, service desk, mainframe services, and networks. The program complemented our education at school and provided us with valuable experience to use when we graduated.

A larger version of this same principle is in corporations that have formal leadership development programs. High potential young employees are selected to go through a job rotation in different departments to prepare them for leading the business in the future. This is often coupled with exposure to international divisions in the business and includes rotations in departments like finance, sales, marketing, and operations.

Today, I was reading through some articles about job trends in Information Technology and I side-tracked onto an article from Fortune Magazine about skills employers want that are not found in a job description. Three of the five employee traits mentioned in the article can be strengthened by a job rotation program like leadership development or co-op rotation. They are 360-degree thinking, cultural competence, and empathy. I believe that these three employee traits are part of the challenge when people talk about the IT group not having alignment with other business departments.

The idea.

Put IT developers through a six week job rotation in the following departments: operations, sales, customer service, marketing, and finance.

 

The program would be setup put the IT developer on the front line of each department in entry level jobs so they can feel and touch the flow of business in the organization.

Black and White Concept Cartoon Illustration of Head Above Water Business Saying or Metaphor

Black and White Concept Cartoon Illustration of Head Above Water Business Saying or Metaphor

The objectives are different from a traditional leadership development program because this isn’t a program to develop managers or executives. But the objectives for developing more desired employee traits are the same:

  1. We want IT developers to be able to see business challenges holistically. This includes the viewpoint of the customer and the company.
  2. We want IT developers to create solutions that engage the customer and yet fit into the workflow of the business units behind their code. They’ll do this through cultural competence in their organization. Imagine how they might design a solution differently knowing how work is sold, configured, and produced.
  3. We want IT developers to be able to see business challenges through the eyes of other departments. A good way to break down barriers between departments is to walk a mile in their shoes.

Will the idea hold water?

Just like you, I can think of a hundred reasons why the idea would fail. Executing this idea would be difficult. The logistics of implementing the idea are complicated. Outside of the planning and job content, this idea requires cooperation from multiple groups of employees. For some it would mean slowing down to ‘train’ others. For the developers it would require they learn some skills outside of computer programming. Combine this with the trend that IT developers are becoming highly specialized in a specific area of the business or that IT developers tend to serve on one specific programming team because of technology-use and it would appear the idea has too many holes to work.

But I’m looking to build a more invested employee. I want to create a developer that can write code for solutions across a broader variety of disciplines.  This is about employee longevity, long term investment in talent, job rotation, and building patriots to the company’s mission.  

I see this like a baptism for IT developers by immersing them in the waters of the business river. When they come up from the dunking, they’ll have a new life with the ability to think more holistically, the ability to see business challenges through different lenses, and the ability to create solutions that are more connected to the business and customers they serve.

Onward and upward!

Photo Credit: Igor_Zakowski

Level the workload for development team leads

Incoming work.

If you work in IT you know that some days it feels like work requests appear from every direction possible and then some. The IT group is a service organization at its core and there is a strong drive to satisfy all customer requests in a timely manner.

For the development group within IT, incoming work results in new projects to create code, fix defects, or mitigate security vulnerabilities. It’s very easy to over allocate the development team leads because the natural tendency and customer desire is to solve all the requests quickly. Inevitably, unchecked incoming work will overburden a development team lead. That creates a large bottleneck in the flow of work and then the rate of production code pushes becomes erratic as the amount of work-in-progress increases!

Load level.8560840624_c67c5c1fef_z

Many modern workflow systems, including Lean, Six Sigma, and Theory of Constraints show the benefit of leveling the load within a production system. Effectively, the idea is to eliminate overburden on people and machines to make production more even and eliminate wastes. In my IT shop we have evolved to a regular prioritization meeting to review current projects in progress, prioritize work not started, and look at the allocation of team leads responsible for executing the work. The intent of the meeting is to level the load of current work that the team is processing.

But the team lead assignment review is a newer component of our process. We realized that even though we were meeting to assign priorities to projects that we had not considered the capacity of the team lead when assigning work. Initially, we looked at the capacity of the entire team and quickly overburdened our team leads. This clog of work stressed our team leads and disrupted the flow of work output for the team.

Now we look at our active work and continuously ask the question, “Have we over allocated our team lead in this area?” When the lead has capacity for new work then it’s pulled from the backlog of prioritized project requests.

This is a simplified look at a much larger concept, but an easy practical step to implement. Maybe it will spring an idea for you to use if you face the issue of over allocation.

Onward and Upward!

 

The truth about IT developers.

CSStoHTMLPart 1 of 3 – The Truth is …. I’ll share some truths about developers, managers, and processes in IT.

I almost became an IT developer.

I graduated with a Bachelor of Science in Computer Science from Georgia Tech. The curriculum was heavily weighted towards programming to teach computer science concepts and initially I thought I would become a developer. While I made As and Bs throughout college I realized my senior year that I wasn’t a gifted developer and couldn’t see myself doing that 40 hours each week.  I could write code. But for many assignments, the code didn’t flow naturally for me.  I saw myself an average-joe developer.

Fast forward to today.

My development skills have served me well in my 20+ years in a technology profession. I’ve been able to do light coding for some work tasks and productivity routines. I know enough to speak intelligently with developers and ask probing questions. Today, I work with development teams to provide solutions for our internal business partners and customers. The importance of IT developers in an organization is immense. Some of them excel at not only knowing how to write code, but they become a repository of knowledge for business rules that govern the day-to-day operations of their business. You probably know a few people like this. They are intertwined with the system, the rules, and the output of work in your organization. I think of them as an organizational czar. They are experts in their area and hold a large amount of influence in how work is produced.

Some truths about IT developers.

Working with developers for so many years I’ve come to realize a few things about them. These are characterizations and not criticisms in any way. I love my development teams. For better or worse this much I know to be true:

  • IT developers want to please you so they will tell you what you want to hear. They don’t like to commit to dates but sometimes they’ll give you a date that you want to hear. I often say developers are some of the most optimistic people I know.
  • IT developers really prefer to be single threaded and not be assigned multiple things at once. The trick is to figure out how to keep the development backlog full without letting the developer get stressed about having too much to do.  Don’t interrupt a developer during the middle of a sprint and ask them to do something different!
  • IT developers don’t like to fill out status reports, track time, or write documentation. I’ve not been able to convince most developers that if they use the proper tools to update their status then they’ll see the project manager less.

If you haven’t told your development team how much you appreciate them lately then use this as a reminder to do so.  When they give you an optimistic estimate, just smile and thank them. Add a little buffer and make sure to not interrupt them once they get started. 😉

Onward and upward!