When an organization is designed around self-motivated teams of highly engaged, high-energy, entrepreneurial individuals, it will be able to adapt rapidly to market changes in a productive and cost-effective way, resulting in business agility.

As pointed out in the article designing organizations that are built to change:

“Many executives talk about the need for greater flexibility and adaptability from their companies. But the truth is that most businesses have organized themselves in ways that inherently discourage change.” … ”The truth is that the effectiveness of change efforts is largely determined by organizational design, or how a company’s structure, processes, reward systems and other features are orchestrated over time to support one another as well as the company’s strategic intent, identity and capabilities. In a world that is perpetually changing, an organization’s design must support the idea that the implementation and re-implementation of a strategy is a continuous process. However, a number of traditional organizational design features tend to discourage — and not encourage — change. Thus, to transform themselves into organizations that are “built to change,” companies need to rethink a number of these basic design assumptions.”

The departure from the traditional hierarchical organizational structure and line of authority is described by Brian Lucas as a fundamental change in philosophy. Quoting from his article the imperative of having an agile organization structure:

• no fixed or assigned authority
• sponsors (mentors) not bosses
• natural leadership defined by followership
• person-to-person communication
• objectives set by those who must make things happen
• tasks and functions organized through commitments

In the five traits of an agile enterprise, Michael Hugos pictures this change as follows,  transforming The Boss into an Enterprise Coordinator:

Quoting from his blog at CIO.com:

• Agile organizations replace command and control with training and trust. They are structured to provide their business units with the flexibility they need to decide and act on their own within broadly defined parameters set by senior management. People are empowered to do whatever is legal and not expressly prohibited instead of only doing what is specifically permitted. A network organization structure enables freedom of action.
• Participatory senior executives actively create the environment for middle managers and employees to succeed. They guide their companies with clearly defined goals and performance targets that are not stated just in financial terms.
• Senior executives in agile companies focus on the essentials; they take care of their people; and they do not micromanage. They seek out and exploit opportunities to diversify into new markets. They figure out what needs to be done and give people clear objectives and performance targets, and then they get out of the way. They tell their people WHAT to do, and let them figure out HOW to do it.
• Entrepreneurial employees are the energy that makes an agile enterprise come alive.

Concluding with some advice on how to find the right people: seek to hire employees who are real travelers, not tourists. Quoting from Artie Debidien during her presentation at CIO day:

“Travelers know where they want to go and what to put in their backpacks. Tourists just wander around, watch, learn and then leave.”

Suggestions for further reading:

• Characteristics of Agile Organizations: As Agile Methods have become one of the predominant ways for successful software development, we are increasingly confronted with the question: “How can the mindset and associated benefits of Agile pervade the entire organization?”.
• Scaled Agility: The Project Forum is an application of agile philosophy to large project structures. Rather than impose a hierarchy of decision making from the Project Manager downwards the Project Forum is a virtual team in the middle of all stakeholders.
• The Big Picture of Enterprise Agility: describes an organizational, process and requirements model for implementing agile methods at enterprise scale.
• Scaling Agile at Spotify: Dealing with multiple teams in a product development organization is always a challenge. One of the most impressive examples we’ve seen so far is Spotify, which has kept an agile mindset despite having scaled to over 30 teams across 3 cities.

The relationship between an IT service provider and a customer can be highly complicated. Oftentimes this complexity is reflected in detailed contracts containing SLA’s and KPI’s, based on ITIL service delivery processes. Unfortunately these contracts contain no practical approach to having a healthy and sustainable relationship. Having been on both sides of the table, I’ll share some of my experiences.

Organizational size: if both the supplier and customer are companies of roughly the same size, there will be an incentive to keep each other alive and none of the parties will be ‘crushed’ by the other. I.e. as customer, make sure you will be important enough for the supplier, without having the risk that they are fully dependent on your revenue.

Benefits: make sure the contract is mutually beneficial. Not only should the customer get the required service, the supplier should also gain enough profit from the contract. A commonly used tactic by suppliers is to enter a bid too low and try to add bonuses later. This will be a heavy burden on the relationship since there will be a lot of discussions on out-of-scope costs. Both customers and suppliers should be aware of these side effects and try to avoid them if possible.

Contracts: it will be necessary to have a contract in place that reflects the agreed service levels and price. However I believe these contracts should be as simple and short as legally possible. During operation the contract should be irrelevant and stored in the drawer. Both parties should be able to act outside of the contract’s boundaries when necessary to help each other out during tough times.

KPI’s: if KPI’s are part of the contract, they should reflect real business value for the customer. I.e. there is no use in measuring helpdesk response times if the answers provided are useless. Having the wrong KPI’s in place will get the worst out of your employees.

Governance: have a clear governance model. Make sure people on both sides know who must be contacted when and who has a mandate to make decisions in which situations. This should not only be focused on the supplier, the governance model should equally include people from the customer’s side. Having a good escalation process is very healthy: getting the final decision makers at the table at the right time is key.

Level of integration: the supplier should have a thorough understanding of how its product affects the customers’ business. This is essential knowledge not only to make sound decisions when service disruptions occur but also to allow continious service development to fit the customer’s needs. Additionally, the customer should understand what’s going on at the supplier’s end. Both parties should look ‘over the fence’ from time to time to keep a healthy customer-supplier relationship. Depending on the nature of the service, the integration level can be higher or lower (see diagram, courtesy of Gartner, 2003)

So, how does this relate to agile service delivery? The following points from the agile manifesto apply:

• Individuals and interactions over processes and tools
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And last but not least: Be reasonable. Be open and transparent. Trust each other. Behave.

In a world where change is the only constant, there is a need to keep innovating using new technologies and new business models. By looking at the hacker culture, we can learn valuable lessons on how to achieve this and allow CIOs to become Chief Innovation Officers.

(photo taken by Olaf Hartong at Electromagnetic Field 2012)

This article is not about malicious computer criminals, the commonly used definition for a ‘hacker’. Instead, it’s about the traditional definition, that originated from the 1960s:

“A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.” … “In a very universal sense, hacker also means someone who makes things work beyond perceived limits in a clever way in general, without necessarily referring to computers.”

Open source advocate Richard Stallman describes it as follows:

“Hacking means exploring the limits of what is possible, in a spirit of playful cleverness.” … “Playfully doing something difficult, whether useful or not, that is hacking.”

The founders of Apple (Wozniak), Microsoft (Gates), Linux (Torvalds) and Facebook (Zuckerberg) are commonly considered to be hackers. However, hacking also happens outside of technology, as described in the essay Hackers and Painters.

Being a CIO and a regular visitor of hacker conferences (Hxx, CCC and HOPE), I believe that there are some valuable aspects from the hacker culture that can be useful for running a company or leading a team of (IT) individuals:

• When trying to achieve a goal, hackers put limitations and boundaries to the test. Hackers will continue to try, even when someone tells them it cannot be done. When pushing against a constraint, the best ideas arise and innovation happens. These limitations can evoke greater creative output. A famous example is when the engineers of Apollo 13 had to fit a square peg in a round hole using a limited amount of parts in less than 24 hours, in order to save the astronauts from suffocation. The lesson is that adding constraints to a project can be a very effective way to stimulate innovation (as pointed out by Rebecca Bortman in her presentation at TEDxUtrecht last week):

• In order to satisfy his/her curiosity, a hacker will think out of the box, ignore conventions and oftentimes use tools and technology in a different way than intended by their designers. This creativity will sometime lead to unexpected discoveries and innovations. This is demonstrated at Maker Faires around the globe. A good example is the VCR cat feeder by MAKE Magazine:

• Hackers are motivated self-starters and self-learners. When recruiting IT personnel, I will often prefer hiring self-educated programmers or system administrators who learned their skills from tinkering in their spare time. In my experience they are more capable of learning new technologies and solving problems than others.

• Hackers are oftentimes very passionate about their projects and love to share their knowledge with others. I recommend my colleagues to visit hacker conferences, as they are very inspiring. (I’m especially looking forward to OHM2013, next summer). Encourage having a regular internal conference for sharing interesting subjects and recent ‘lessons learned’ amongst colleagues. Order some pizza and organize a ‘hackaton‘ (hacking marathon). Or, if possible, allow for 1 day a week personal experimentation time as is the case at Google and many other modern tech companies.

The following quote from an interview with Steven Levy, the author of Hackers: Heroes of the Computer Evolution sums it all up:

“The real lesson is that you should try to do the impossible. We’re at the best time ever in history to do the impossible, and we have amazing tools to do it. We’ve created a technological platform where imagination is your only boundary. The best laid business models are overturned by a kid in a dorm room, more now than ever.”

Improving information security is not just a technical issue, it’s all about organisational change. This article contains some tips and tricks that might help when establishing a information security management system.

Determine the maturity level

The Capability Maturity Model (CMM) is a commonly used management instrument for determining business process maturity. When applied to information security, it provides a useful roadmap that allows you to derive security requirements:

• Level 1 – initial (chaotic): there are no security processes or measures, security is not a priority nor a concern, security awareness is zero to none
• Level 2 – repeatable: security is considered to be useful, some ad-hoc security measures will be implemented, sometimes by an external specialist, however nobody is responsible for security and there is no formally defined process
• Level 3 – defined: security has a clearly defined position within the organisation, there may be a staff security officer, processes and responsibilities and policies are described
• Level 4 – managed: security is a integral part of every process and change project, the responsibility has been shifted from staff to line management, KPI’s are defined and monitored
• Level 5 – optimizing: security is considered a strategic topic, it is continuously monitored on the C-level and it’s considered an integral part of executing business, security is continuously improved based on the production processes needs

In my experience, a lot of smaller to mid-sized companies are somewhere between level 2 and 3 and are planning to move up to at least level 4. When moving up the maturity ladder, the concept of security evolves from ‘not important’ (level 1) to ‘something special’ (level 3) to eventually become ‘business as usual’ (level 4 and 5). This evolvement model is also applicable for other ‘non-functional’ business requirements, for example ‘quality’.

Top management commitment

It is obvious that not all organisations require the absolute highest level of security. A good way of determining the applicable level is by interviewing the top management about their security concerns and expectations. Some interview questions that might help:

• which security threats can be identified?
• is security improvement necessary and what level should we try to achieve?
• to what extent should we be prepared for a security breach and its consequences: reputation damages, decreased customer confidence, press exposure and even legal penalties?
• is compliance a factor that implicates a certain level of security?
• what strategic developments relevant for security?
• inside the organisational structure, who should be responsible for security?

As pointed out in the article Security Is Not Just a Technical Issue:

 An organization’s ability to achieve and sustain adequate security starts with executive sponsorship and commitment.

Conducting a management interview is a good way of getting this top-down commitment. As with every organisational change, the success factor of a this commitment should not be underestimated.

Security advisory committee

In order to get from CMM-level 2 to level 3, security needs to have a visible position in the organisation. This can be achieved by appointing a security officer who will lead a security advisory committee, consisting of some key employees. The committee can function as a central organ that evaluates security incidents and advises on security measures and policy. In order to start the security management process and feed information to the committee, it is advisable to have a ‘security hotline’ that employees can use to report a incident or to suggest ideas for improvements. As a next step, the committee might install a emergency response team consisting of staff members with specific technical knowledge that receive additional training on how to handle security breaches.

What weaknesses to be addressed first?

When compiling a list of possible measures to improve information security, consider the following methods:

• listen carefully to the IT engineers: even though they might not all be security experts they will probably already have a good idea of where the weak spots are. A brainstorm session might deliver some valuable results.
• get your systems tested by professional hackers: a report from a company specialized in security penetration testing will contain valuable information on what weaknesses to be addressed first.
• label your information systems and processes: some systems are more mission critical than others. For each of them, determine the required level of confidentiality, integrity and availability. This allows you to quickly identify which areas should be improved first.

Never ending process

Security is not a event, but a continuous interlocked process. New weaknesses and threats are always emerging and improvement should be continuous. After a cycle, execute a security self-assesment and re-evaluate the previously gathered weaknesses.

(image source: Wikipedia)

Deploying a fresh and shiny new technology in your IT infrastructure is obviously very tempting. However it can also be highly disruptive if managed poorly.

Last year I researched the impact of introducing server virtualization technology in organisations that use ITIL based processes for their IT service management. Organizations have considered server virtualization initially from a tactical viewpoint: an effective technology for consolidation, offering increased utilization levels, reduced server sprawl, and lower capital and energy expenses. Over time, server virtualization is being considered more from a strategic viewpoint: a catalyst for IT modernization that changes how IT is acquired, deployed, consumed, managed and paid for. Gartner states that server virtualization is currently the highest-impact issue changing IT infrastructure and operations, and offers the main path to cloud computing.

The research showed that introducing this new technology had considerable impact on the business processes. In my experience, this conclusion can be considered a pattern for most new technologies deployed in an organization. Some critical success/common pitfalls that were derived from the study:

• the new technology is most likely no silver bullet, it will have hidden costs, disadvantages and risks that need to be addressed
• the vendor will overstate the benefits of the new technology for obvious reasons
• new technology will innovate rapidly after it’s first inception, it is a challenge to determine if being an early adopter will give you significant advantages over the competition that still uses proven technology
• don’t try to reinvent the wheel: hire an expert who has executed several deployments in different IT environments
• if the technology is only pushed by the top management, resistance from the engineers can be expected; a bottom-up approach has a much higher chance of success
• any new technology or tooling without the proper process or policy adjustments is useless

The ‘peak of inflated expectations’ and ‘trough of disillusionment’ of the latest Hype Cycle for Emerging Technologies shows you what to be beware of in the coming years:

Suggestions for further reading:

• Failure to Communicate: The Challenges of Implementing New Technology on the Business Process (research paper by Chris Decker)
• Top Down or Bottom Up Approaches to Change (blogpost by Nick Anderson)
• The Impact of Server Virtualization on ITIL processes (my research paper, published at the 2011 international conference on cloud computing and services science, CLOSER)