Organization is Only Easy on Paper
When you look at the entire company-wide IT program, you see an ocean filled with waves of projects. Each is constantly changing and presents its own issues and struggles.
IT management requires willingness to take a deep dive into the details of many different areas, while allowing yourself time to work on higher-level strategies and tactics. I am often amazed at how much you as a CIO need to do right to succeed, and how little you have to do wrong to fail.
That is why I believe that the CIO of a company 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 constant need to attract, select and retain top talent.
In addition, IT departments have unique challenges that keep them from being managed in the way other businesses are. One of these challenges is the constant change occurring 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. Teams are working on goals with different life cycles, different areas of technology, different areas of business focus and different levels of business understanding.
Due to these ever-present conditions, and to the technical nature of the work, 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, as it provides a way to measure and quantify the most important aspects of IT’s challenges. The Nucleon formula allows CIOs and CEOs alike to work together on the most important issues facing the company.
7Jeppe Hedaa and his team has looked at the relevant data and identified four universal areas that greatly impact performance in the area of organization. They are:
Team Size, Bureaucracy, Decision-maker Proximity
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 delivers a much lower performance per individual 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 (less than five people) or large teams (more than twenty people). Though the larger teams finished the job six days earlier than the smaller teams, 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 organizations need administrative staff and compliance, but as soon as these support teams take on a life and agenda of their own, things start to deteriorate.
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 so than 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 solution 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 must be 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 counter-productive and should be avoided whenever possible.
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 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’ or group dynamics 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 being a positive or negative contributor.
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 the middle 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. But 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 – and scalable. This model is obviously financially great for consulting companies, but as Nucleon shows us, it is NOT optimal for an IT organization.
We have shown some different scenarios in the book Nucleon where organizing two 10´s have a higher delivery capacity than 20 mediocre developers, and our experience and research reveal 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.
Download a chapter for free
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 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.
The Black Box of IT with Archbishop of Canterbury, Justin Welby and Jeppe Hedaa – Culture in Organisations
Other than conducting Harry and Meghan’s wedding… What does the Archbishop of Canterbury, Justin Welby, have to say about culture in a multinational organisation? For organisational culture experts: This is an interesting alternative perspective, looking at the...
The Black Box of IT with Jørgen Høll and Jeppe Hedaa – Team Size
Team Size in Army Special Forces - The Black Box of IT: What can IT learn from elite soldiers? Watch this interesting conversation with Jørgen Høll, retired Major General and former Commander of the Danish Special Operations. Jørgen Høll and Jeppe Hedaa talk about...
The Black Box of IT with Krzystof Dabrowski and Jeppe Hedaa – Agile Implementations
Agile Implementations - The Black Box og IT: A Corona-distance interview with author of Nucleon, Jeppe Hedaa and mBank COO, Krzysztof Dabrowski covering expected productivity gains, investments needed, cultural readiness, implementation time, learning curves,...