Bookmark and Share
RSS

Recent Posts

Ways IT Teams Work: Hierarchy Aligns With Operations

December 12, 2016

This week, I’m starting a multi-part series on how teams are organized and how they work together within a set of conventions and constraints. I am writing this series from my own experience as a team member at different parts of my career.

This post describes a hierarchical IT organization with members having roles that align directly with the job of adding and fixing applications for a company with thousands of employees who move millions of dollars worth of goods around the country daily.  

About the Team
This was my first experience in IT. I joined the team right out of three months of training in COBOL and JCL. After punching 80-column cards for my first program and its JCL, TSO/ISPF/PDF was the tool we used to get our programs into MVS for compiling and testing. We had no exposure to CICS, so naturally our first assignments were writing COBOL CICS macro-level programs.
 
The team structure that I found myself part of worked well and the people had few overlapping responsibilities. I was strictly a programmer assigned to a senior analyst who designed my programs. We had a manager who managed other designer/programmer teams and our manager reported to an assistant director who, with other assistant directors, reported to a director. This was a traditional hierarchy with people who worked closely together but had different but related responsibilities.

What Worked Well
Our director interacted with other company department heads that were focused on moving freight. He was a businessperson who gathered work and made commitments. He was experienced and a good communicator and he was effective at his job.

The assistant directors signed up for components of work based on their staffing level and the kind of work that they did in the past. The assistant directors had come from programming and they were knowledgeable about the operational challenges. They had an operational role during the deployment of code, for example on Wednesday night when maintenance was released they made go/no go decisions if there were problems with the deployment. It was useful to have them assume this role and they took the lead in fixing what went wrong so it could be avoided in the future.
 
Managers received applications or subsystems to work and they met with their designers and the work filtered down to the programmers. The biggest strength of the organization was the skill and experience of the people involved. All this was positioned in a way that helped to make the new programmers joining the unit useful in the overall ecosystem. 
 
What Didn’t Work So Well
The people in the organization worked well together but the technical environment was very challenging, creating problems for new programmers. There were design decisions made when CICS was an early product that weren’t well communicated to the new programmers. The absence of in-house documentation resulted in a lot of trial and error and many questions asked trying to figure out the architecture of the environment in which we operated.    

An even bigger problem was the lack of computer power and other resources. Test systems took a long time to come up, ran slowly and would abend often because a large number of inexperienced programmers were imbedding BAL macros in their COBOL programs and they didn’t really know what they were doing. In this era, running COBOL programs had access to systemwide control blocks so one wrong move and you could cause a crash.
 
Looking Back 
It was an organization failure not to realize that new programmers (and designers) needed documentation about the series of architectural enhancements that were made to supplement the functionality of CICS. Another shortcoming was training about CICS. The managers should have realized that product-specific training was needed before programmers could be expected to “service reload” BLL cells and reliably address task and system control blocks in a COBOL program using BAL macros. This kind of challenge often arises when experienced teams bring on new members. Unfortunately, many new programmers left after just a year due to the pile up of day-to-day frustrations.

I learned that having an effective organizational structure is not enough. A balanced package of experienced people with sufficient hardware, well-documented software, useful data and procedures makes good work possible.

Coming Up

Next week, I plan to move to another example involving teams working together in a federation, that is a collection of teams from business units being formed into a single centralized unit. In this arrangement, each organization keeps some internal autonomy. In my example, you will see that a common process unified the unit.



Posted December 12, 2016 | Permalink

comments powered by Disqus