Culture and international companies

International companies are said to have a very strong culture. In fact, this is mandatory not only to motivate employees but also for offsetting cultural differences coming from different countries.



Even in Europe where cultural differences are supposed to be smaller, bridging cultural differences is important. As an illustration although it may appear as a cliché, different cultures such as Italian and German do not have the same approach regarding work. For example, efficiency is favored in Germany, spending less time at work whereas commitment is measured in Italy through long hours. Another example is the way work is organized: in Germany structured plans are preferred whereas they are viewed as a lack of creativity in Italy. Management is also perceived differently: considered more like a coordination role in Germany opposed to a leading role in Italy. If no one tries to bridge these differences, a mixed team will soon be impacted by these divergent views.


Cultural differences are influencing the way a company is organized and run. These differences are impacting companies on all levels: on the entire company, on managers, on teams as well as on projects.

Company wise, the company’s culture must be very strong to be able to offset cultural differences coming from various countries. If not there is no common ground for basic things like work hours, signs of commitment, …

Even if a strong corporate culture is in place, on a managerial level, managers have to understand and respect those cultural differences otherwise, they will be less efficient or fail. There is a limit to what you can force people to do. Respect is not straightforward in heterogeneous environments: a common behavior is to reject what is different.

From a team management perspective, diversity is a constraint but can also be a clear advantage if managed smartly. The art of management is using resources in the best possible way; in an heterogeneous environment this is made even more difficult as differences among people are wider. Therefore, identifying the best fit between people and tasks is more difficult but can be truly rewarding if a manager pays sufficient attention to differences.

Cultural differences also influence politics and consequently projects and project governance: depending on the culture, visibility is not always given to the same projects. In some organizations, business cases will be the main driver trying to maximize the value/cost ratio. For others strategy and long term plan may play a stronger role, for others a country can also be in the driving seat, …

Managing diversity does not mean that there is no common ground: vision and strategy are key to motivate teams: even from different backgrounds, understanding together what we are aiming at has been a powerful lever for success. Of course diversity is making this exercise more difficult as the vision and its implementation have to be translated and adapted to each culture.

Why CIOs should not report to COOs

It is very common to see CIOs reporting to COOs or CFOs. Of course there are advantages in doing so : less people directly reporting to the CEO, better alignment between support functions and IT, CEO able to focus more on business topics.

IT is core

The main drawback of this is that de facto, IT is not considered as core business. A previous post was trying to paint how IT is becoming embedded in the business. There is, since now many years, an increasing involvement of IT in building end user products. This cannot be achieved efficiently if IT is perceived only as a support and not as a strategic function.

CIOs reporting to COOs or CFOs do not get the same information and experience on PnL. They are less likely to be able to understand which are the popular products, the customer needs, and how IT innovation could make the difference. A CIO should understand and know company's strategy. He should even contribute to it bridging together business and technology.
Understanding the business strategy, the CIO is then able to align his organization to this goal.

Alignment is key

This means that the entire team and not only the CIO should work on the same target. This is helping to be more efficient as experience shows that an IT team with a defined goal is by far more efficient. This is also avoiding projects that are not fitting with the strategy making the portfolio of projects more efficient and also the improving the perception from other groups.
Having a portfolio with a lot of pure IT driven projects not linked to the comapny's strategy generates a poor impression...

KYB

CIOs, as well as the IT team, need to know and understand the business : who are the competitors, what are those competitors doing, what are the revenues per product, what are the trends from a customer perspective, ...in short Know Your Business ! They also need to sell internally IT strength. Experience shows that when product guys are convinced that they can ask IT for innovation they tend to be more creative, not self restricting the scope of a new product

Indeed all of this is more difficult when CIOs are interacting with the company through the filter they get from their COO or CFO.

Traduction à venir prochainement ...

Capital Markets IT attractiveness

In a recent post, I tried to picture the changes transforming deeply the IT within Capital Markets especially in terms of sizing (or better in terms of downsizing).

Crisis is not only impacting budget

The crisis impact is not limited to budget and team size : it is also impacting the nature of the projects we do. Race for complexity is over and in most banks, proprietary trading is not really favored and high frequency trading is not anymore in focus.

Throughout those two specific examples, one can see that the nature of what we do in Capital Markets IT is also changing dramatically : much less exciting topics and IT also becoming less core than before. On the other hand, some other things are not changing : pressure coming from the markets, heavy procedures coming from former size, … the excitement is less but the pain remains the same which means that Capital Market IT is less desirable than before. This is true for people already working in this sector and one can see some people moving to other industries. This is also true for new comers who find this area much less attractive.

Competition with other industries is tougher

This trend is even stronger if we consider changes in other industries : in former times, Capital Market IT was one of the areas where IT was considered as core business. Since e-business is blooming, there are a lot of other areas relying on IT for their core business. Therefore IT guys interested in contributing to core projects, without belonging to a pure IT company, have now a wider range of possible target companies than before.

This is going to have a very strong impact on Tier2 and Tier3 banks which have to transform deeply to maintain their attractivness otherwise the gap between top players and the others will get larger.

Dans un post récent, j'ai essayé de dépeindre les changements qui transforment profondément l'informatique des marchés de capitaux en particulier en terme de taille (ou plutôt de diminution de taille)

La crise ne touche pas seulement le budget

L'impact de la crise ne touche pas seulement le budget et la taille des équipes, la nature des projets est également impactée. La course à la complexité est maintenant terminée, dans la plupart des banques le prop trading n'est pas en odeur de sainteté et le trading haute fréquence plus véritablement d'actualité.

A travers ces deux exemples, on peut voir que la nature même des activités des marchés de capitaux change fondamentalement : beaucoup moins de projets motivants, et une informatique s’éloignant du cœur de métier. D’un autre côté certaines choses ne changent pas : la pression venant des marchés, les procédures lourdes venant de la taille passée…la motivation baisse mais pas les difficultés. Cela signifie que l’informatique des marchés de capitaux est moins attractive qu’auparavant.

C’est vrai pour ceux qui travaillent actuellement dans ce domaine et on peut d’ailleurs voir des mouvements vers d’autres industries.

Ceci est également vrai pour les nouveaux entrants qui trouvent ce domaine moins attractif

La compétition avec d’autres domaines est plus rude

Cette tendance est même plus marquée si l’on prend en compte les changements intervenus dans d’autres industries : il y a quelques années, l’informatique des marchés de capitaux était l’un des domaines où l’informatique faisait partie du cœur demétier. Depuis l’explosion de l’e-business, il y a maintenant de nombreuses industries qui s’appuient sur l’informatique dans leur cœur de métier.

De ce fait pour les informaticiens intéressés à travailler sur des projets stratégiques, sans pour autant faire partie d’une société informatique, ont maintenant un choix plus large que par le passé.

Ceci va avoir un impact majeur sur les banques Tier2 et 3 qui devront se transformer rapidement pour maintenir leur pouvoir de séduction. Si cela n’est pas fait, l’écart entre les joueurs de tête et les autres va considérablement s’élargir.

Why separate support and development?

Pourquoi séparer support et développement ?

L'infrastructure et le développement ont été séparés depuis des années dans la plupart des entreprises. Une autre séparation est également souvent faite entre le support applicatif et le développement. Les principales raison étant la séparation des rôles, nature différentes des tâches et un meilleur contrôle.

Separation des rôles (Sox 404)

Bien que ce chapitre de Sox ne dit pas clairement que les activités de projet et de maintenance devraient être séparées, les auditeurs demandent d'avoir des "release managers" indépendants pour avoir un meilleur contrôle sur ce qui est livré. Des environnements distincts assurent que la livraison est faite à travers un processus après que les tests concluant aient été effectués.

Mettre en place un "release manager" pousse ce concept un peu plus loin pour assurer également la tracabilité des besoins à la livraison. Ce qui est livré doit être cohérent avec les besoins et le "release manager" est responsable d'assurer cette tracabilité qui ne peut être garantie par les services d'infrastructure.

Le "release manager" ne peut faire partie des équipes de développement (conflit d'intérêt évident) et devrait donc faire partie de l'équipe de support. Réaliser tests et livraison dans l'équipe de support application apporte d'autre avantages : l'équipe de support est impliquée plus tôt, connait la nouvelle version à l'avance et sera en mesure d'apporter un meilleur support.

Parce que le travail est différent

Les capacités nécessaires pour développer ou pour gérer des systèmes diffèrent : le développement mobilise des personnes innovantes et créatrices tandis que le support requiert des personnes fiables et solides.

Le rythme de travail est également différent : le support doit traiter tout incident immédiatement mettant de côté les tâches en cours. Les équipes de développement ne peuvent pas se permettre le risque de différer une livraison du fait de nombreux incidents.

De plus, résoudre un incident demande beaucoup d´énergie, d´attention et de résistance au stress. Quant un incident est clos, la pression retombe, réduisant la capacité de travail sur une période bien plus longue que celle de l´incident.

Parce qu´avoir une vue indépendante apporte de la valeur

Mettre en place un support indépendant apporte une vue complémentaire, utile en particulier lors des mises en production. Une équipe de support indépendante permet d´assurer que les procédures de test ont été suivies et que les vues optimistes de certains ne gouvernent pas les mises en production. Disposer d´une vue indépendante sur la manière dont le développement suit les procédures est un plus important. On pourrait penser que ce type d´organisation génère des conflits, l´expérience montre que ce n´est pas le cas, les deux parties connaissant les règles du jeu.

Bien sûr séparer développement et support applicatif comporte des inconvénients comme : une communication plus difficile, un fonctionnement avec deux équipes au lieu d´une seule et enfin ce type d´organisation ne peut s´appliquer que pour des équipes de taille suffisante.

Communication

Au lieu d´avoir une seule équipe en face d´eux, les utilisateurs dialoguent avec deux équipes (support et développement) et ont besoin de comprendre les rôles de chaque équipe. N´étant plus impliqué sur les incidents, le développement échange moins avec les utilisateurs. Cela pourrait appauvrir les retours utilisateur impactant la qualité du code produit.

Travailler ensemble

Avoir deux équipes au lieu d´une seule est plus difficile et exige un étroit travail en commun en particulier pour les phases critiques comme les livraisons.

Les deux équipes doivent également travailler ensemble sur le support de niveau 3 : l´équipe de support applicatif n´a pas la connaissance intime du code, il doit se reposer sur l´équipe de développement pour le support de niveau 3.

Dans l´autre sens, l´équipe de support peut aider l´équipe de développement sur les tâches techniques proches de l´infrastructure sur lesquelles le support a plus de connaissance.

Enfin, une attention particulière doit être portée sur la responsabilité : deux équipes livrant un service joint peut générer une perte de responsabilité dans la résolution des incidents.

Même si une telle organisation n´est pas facile à mettre en œuvre et qu´elle présente des inconvénients, d´un point de vue général, les avantages sont solides. L´expérience montre que pour des équipes taille moyenne ou grande ce type d´organisation a du sens. Pour des plus petites équipes (moins de 10 personnes) cette organisation a moins d´intérêt.

Application and infrastructure activities have been segregated for years in most organizations.

Another split is also often made between support and development. Main drivers for doing so are usually: segregation of duties, different nature of activities and control

Segregation of duties (Sox 404)

Although this section of Sox does not state clearly that run and change should be separate, auditors are asking for separate release managers in order to have more control on what is been released. Separate environments ensure that rollout is done through a managed process after a proper testing has been performed.

Having in place a release manager is pushing this concept a step further to also ensure traceability from requirements to delivery. What is delivered must be consistent with the requirements and the release manager is accounting for this traceability which cannot be guaranteed by infrastructure.

The release manager cannot be part of the development team (obvious conflict of interest) and should belong to the support team. Performing testing in the support team brings additional benefits: the support team is involved and knows about the new version in advance and is likely to give a better support

Because work is different

Skill set is different: for development the need is to have creative/innovative people bringing new solutions whereas for support the need is reliable and sound people managing safely systems. Managing a system is different from creating a system

Timeframe is also different: support needs to pickup immediately any incident postponing other activities they may have. Development cannot afford to put at risk project commitments due to multiple incidents. Furthermore, solving incidents is very intense, demanding a lot of concentration and resistance to pressure. When the incident is solved, pressure releases impacting work capacity for a much longer period than the incident itself.

Because having an independent view is bringing value

Having a separate support brings an independent view especially useful for rollouts. This ensures that the proper testing procedure has been followed and that wishful thinking is not driving system upgrades! Having an independent opinion on how development is following procedures is also valuable. On could think that this kind of organization is generating conflicts, experience shows that it is not the case as both parties know the rules of the game.

Of course, such organization has drawbacks like: communication, working together in two teams instead of one and also such an organization cannot be applied for small teams where the critical mass is not sufficient to split one team in two.

Communication 

Instead of having only one team in front of them, users need to talk to two teams (support and development) and need to understand the difference between the two. Development team is also losing some interactions with users and they may not get all the feedback they get when they provide also support. This potential farther distance between development and users could impact the relevance of the software produced.

Working together

Obviously, having two teams working on the same topic is more difficult than having one and the two teams need to work closely together especially in critical phases like rollouts.

Another area where the two teams need to interact is third level support: as the support team is losing intimate knowledge with the software, they need to rely on development to perform third level support activities.

On the other way round, support may help development on technical matters linked to infrastructure where they usually have a greater knowledge.

Last but not least, special attention should be put in not losing accountability: having two team delivering a combined service to users may lead to less accountability from support as they handle the incidents.

Even if such an organization is not so straightforward to implement and is showing drawbacks, overall benefits are strong. For mid size or large development teams, experience shows that it is making a lot of sense. For smaller setups, (less than 10 people), it is definitely less relevant.

VO ou VF ?

Blogger ne supporte malheureusement pas nativement les posts dans plusieurs langues. Heureusement la communauté très active a trouvé une parade !

Tout n'est pas parfait, mais les deux petits drapeaux permettent de passer le corps du post d'une langue à l'autre. Reste maintenant à traduire les posts ...

Unfortunately, Blogger does not support natively multi language posts. Fortunately the very active community has found a workaround !

It is not perfect, but the two little flags enable to switch from English to French. Now, the posts have to be translated ...

IT Department should not compete with external providers

Very often internal IT departments are competing with external providers, they mimic their processes, pretend to be independent, … but there is a key difference that cannot be forgotten, an internal IT department is part of the same company, contributing (or impacting) the same balance sheet. This difference has many impacts on different aspects such as : Intellectual property, risk taking, communication, ..

Intellectual property

As IT is more and more becoming core (see previous post), IT is involved in topics connected with the core know how of the company. The IT department has access to information which is hidden to external providers. Therefore IT departments should not position themselves like external providers as they have a different role to play being part of the products their company is offering

Risk taking

An external provider is trying to minimize as much as possible the risk he takes. All known methodologies like CMMI have been built towards that goal: ensure repeatable delivery, project after project.

Of course, every organization share this goal of successful deliveries, no one wants to fail ! Nevertheless, the risk level a company may be comfortable with is different from the risk its provider is likely to take. Furthermore, internally knowledge is deeper and therefore risk perception is different from outside

Communication

Clearly, no man is a prophet in his country ! Nevertheless, an IT department should not try to mimic external providers in communication plans, ads, … IT has a direct access to colleagues in other departments, this is a big advantage to facilitate communication : no need to break call filtering, to build outstanding brochures to catch attention, … Internally communication can be spread much more and be much more frequent. This means that, instead of having a centralized communication effort, an IT department should make sure the different teams interact on a regular basis with other departments and not only formally but also informally to ensure good understanding

All this does not mean IT departments should not care about their image and their strategy nor that they should do everything by themselves : a deep analysis of the differentiators IT is able to provide is mandatory to define core and non-core domains and functions. Focus should be given to core activities and external providers should be used to minimize cost on non-core activities

2013 Season Greetings

All the best to you all for 2013 !

Crisis, especially in the capital markets, is here to stay which means that we´ll have to deeply transform to survive. Instead of fearing these changes, one should consider this as exciting time ahead of us !

Hope this blog will bring ideas to contribute a little to this process....