IT management requires willingness to take a deep dive into the details of many different areas, all while allowing yourself time to work on higher-level strategies and tactics. I am often amazed at how much you need to do right to succeed, and how little you have to do wrong to fail.
It’s why I believe that the CIO has one of the toughest jobs in the corporate world.
It is the CIO who is tasked with making all of the organizational decisions for the IT department. On top of the rapidly-changing technology stack, there are new partners and vendors to be selected and dealt with; new methodologies and architectural choices to be made; and changes in legislation that have implications for projects. There is also the continuing need to attract, select and retain top talent.
IT departments also have unique challenges that keep them from being managed in the way that other businesses are. One of these challenges is the constant change occuring in the technological toolbox. According to PwC’s 2017 CEO Survey, 71% of global CEOs report that they are concerned about the speed of technological change and see it as a threat to their growth.
The other major challenge is the project-oriented nature of the work that’s being done. Teams are working on goals with different life cycles, different areas of technology, different areas of business focus and different levels of business understanding.
It’s because of these ever-present conditions, as well as the technical nature of the work, that top management often has the sense that IT is too difficult and too specific an area of expertise for them to understand or improve upon. This leads them to close their eyes or give up, leaving the CIO alone to deal with the various assignments and responsibilities.
This is where the Nucleon formula enters the picture, because it provides a way to measure and quantify the most important aspects of IT’s challenges. The Nucleon formula allows CIOs and CEOs to work together on the most important issues facing the company.
7N has looked at the data and identified four universal areas that greatly impact performance in the area of organization. They are:
and Optimal People Allocation.
Team size can heavily influence the performance of the team. Through studies of thousands of comparable projects, the conclusion is that larger teams have a lower performance than smaller ones.
The optimal IT team size is between three and five developers, though you can grow a team to seven developers with only a minor impact on performance. When you compare the progress of one of these small teams to that of a larger group, you see that adding more people results in a huge decrease in productivity and a significant increase in mistakes.
Studies of more than 4,000 IT projects confirm the greater efficiency and effectiveness of small teams. One study analyzed 564 comparable projects in which 100,000 lines of equivalent code were written. The projects were divided into two groups of either small teams with under five people or large teams with more than twenty people. Though the larger teams finished the job six days earlier than the smaller teams did, they carried an overhead that was 7.3 times greater.
In the Nucleon formula, you get the minimum drag if you organize small teams of seven people or less, containing, for example, three side-by-side functions with one lead-developer/project manager. When larger teams are calculated in the formula you will get a reduced effect of the total team effort per extra individual.
Managers of all kinds should always try to align mental models and avoid introducing agendas other than delivery and performance. Without a strict focus on this, teams can lose as much as 20% of their potential performance.
There’s no question that all organizations need administrative staff, but as soon as these support teams take on a life and agenda of their own, things start to go bad.
Large IT development organizations have specific needs. At the very least these include a Human Resources department, an architecture function, a methodology function, a procurement department and a financial department. Sometimes these groups take on a life of their own and what follows is unnecessary bureaucracy, power struggles and a jungle of paperwork that produces drag and eats away at the core organization’s motivation and productivity.
The IT development organization is particularly sensitive to interference and disturbance, much more than is true of the i.e. Finance or Legal departments. IT professionals cannot live with illogical systems that work against development productivity and implementation. Bureaucratic frills such as department meetings called for no apparent reason, silly rules, administrative burdens and onerous paperwork that make their lives more difficult will frustrate them to such a degree that they’ll eventually leave for a better environment. The answer is not to eliminate support staff but to refocus them.
IT bureaucracy should be optimized specifically to the creative environment with only a few, simple rules as guidelines:
- Autonomous: Each team should decide how the group will work,and responsibilities are clearly defined.
- End-to-end knowledge: The team should possess all knowledge required to deliver a working product.
- Communicating: Development is all about close collaboration. Ideally, the entire team would be sitting in the same room so that there are no barriers in communication.
- Dedicated: Every member of the team should be assigned to the project full-time because any distraction will only delay work.
In it for the long run: Try to keep teams together and don’t make frequent changes. Teams take time to learn to work together.
The guidelines are adapted from Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland.
Looking at these five principles, it is evident that adding resources not directly involved in the development of the product is counterproductive, and should be kept to a minimum.
Not having the decision maker (the person who calls the shots regarding the final products features, layout, etc.) close to the team significantly hurts performance. This is because both idle time, confusion and communication lag arises.
In the data we have analyzed we see that performance can be affected by up to 32% if the decision maker is not close to the team.
One of the worst side-effects of an absent idea-owner is that the IT development team experiences too many waiting cycles. I call these cycles “black holes” because they suck all the energy out of the team. Even though the team can normally make non-problematic decisions on their own, there are many issues in a development project that require the business owner’s attention. For instance, the initial design phase of a project is extremely demanding and requires lots of dialogue; it is of the utmost importance that the team is working towards the content and meaning that the business owner had in mind.
The Nucleon formula punishes the performance numbers if the business owners aren’t working directly with the development team. The business owner doesn’t have to, perhaps even shouldn’t be engaged full time, but they do need to be readily available. If they’re not, Nucleon reduces productivity for the individual team by as much as 32% decrease in performance.
Optimal People Allocation
The ‘spillover effect’ is the measure of the fact that great people lift those around them, and vice versa. Everyone in a given team is affected by their team members and can produce at up to three times their individual potential – or at a third, depending on their environment.
I was trained to think in talent pyramids: put a 10 at the top of a team and then staff it with a lot of less-talented performers. This is the way it has always been done in big IT development organizations, as well as most other industries. The belief is that you can lift an entire team of mediocre people to a higher level by placing a 10 in their midst to lead them.
I believe this stems from how the big consulting companies organize themselves. They do exactly this: place a partner or senior in the top and then staff up with juniors directly from university, and we have all followed suit: when the big, professional consulting companies do it, it must be right. This pyramid model was chosen because it is financially attractive to the consulting company, who can then charge $350 an hour for the partner and “just” $150 for the junior. This is a wonderful cash cow. This model is obviously financially great for consulting companies, but as Nucleon shows us, it is NOT optimal for an IT organization.
Our experience and research reveals that great performers deliver at a completely different and far superior level when they are put together with other great performers — that you should place 10s with 10s, 9s with 9s, 8s with 8s, and so forth.
This is one of the most important things I’ve uncovered about improving performance, and I realize it’s a big step away from conventional thinking.
Some experts support a strategy of placing 10s with other 10s, while others advocate getting more out of your 10s through their support of lower-level groups. I believe that it might be a good idea to mix 10s with juniors out of a strategic long term ambition for the department, even though it is not a good idea from a short-term performance perspective.
I think it is very important to gather your most talented IT people on the same teams, and you should calculate the potential consequences of not doing so.
When placed on a team, a person who is a 10 will lift another 10 to far beyond what could have been achieved individually or when placed among those of lesser abilities. Though it’s true that the same 10 can be placed amongst 5s and make them more efficient, the 10 will be also be positively affected when asked to work with another 10, and negatively affected by working with a group that has a lower overall rating.
If you want to try something exciting, create a small team of 10s, then sit back and watch them make miracles.