Leadership cannot exist without authority. The two go hand in hand. Leaders set the goals and vision and establish an environment that make it possible to achieve them. They often do this by giving people the authority to make decisions in order to continually move toward the set vision and goals.

It is necessary for some leaders to delegate decisionmaking. If the authority to make decisions is not delegated and leaders are forced to make every decision, then unnecessary roadblocks are formed that slow progress. In many cases, leaders don’t always possess the knowledge, information, expertise, or experience to make the needed decisions.

How Leadership Relates to Technology

Technology plays a critical role in attaining goals and realizing vision. This is true today, and will only grow more true as time progresses.

Within your technology domain, there are many decisions that must be made on a fairly frequent basis. These decisions include:

• What software to buy
• What upgrades to perform
• What vendors to use
• Whether to in-source or outsource development
• Whether to build or buy
• The priority for pending work/demand
• The architecture to use
• Using in-house services or cloud services
• The development methodology to use
• Who to hire
• How to structure the team
• The role of business

The list goes on and on. In fact, it can be daunting. Many of these decisions require fairly detailed technical knowledge and expertise that leaders often do not possess, making smart decisions difficult. Yet these important decisions still need to be made; they are decisions that will be impactful to the health of the organization.

With a set of clearly communicated objectives and parameters (such as cost), authorized technology team members can evaluate each decision that needs to be made against the stated goals and objectives that leaders have set. This ensures ongoing strategic alignment between technology and business objectives.

Below are three ways you can create authority to ensure that technology decisions are being made with the strategy in mind.

Enterprise Architecture Checkpoints/Gates

Technology authority can be enacted within an enterprise via a series of checkpoints and/or gates. These are key points in the development/procurement that look for formal approval for pending technology decisions.

Each new technology element that you introduce into your technology domain must align with your existing or planned technology stack but also be within the capabilities of your technology staff to control, maintain, and work on.

By mandating an enterprise architecture checkpoint or gate for any pending/planned introduction of technology into your environment, you will help ensure that alignment stays in place. The enterprise architecture group should be given the authority to approve or reject (with cause) proposed technology introductions if they do not align effectively with your existing or planned technology stack and capabilities.

It is important to note that it isn’t always the best technology that you add into your environment. It is instead often the best technology that you can afford, that also integrates well within your existing environment, and that you can readily support.

Peer Review Board (PRB)

Another instance of such a checkpoint or gate which should be granted authority is a Peer Review Board (PRB) for technology design and coding. Assuming that you have established standards for design and code (and if you do not then you should) this PRB will serve to validate that new applications being designed and developed are adhering to established standards.

It is has said that 80% of the defects and issues introduced into an environment are introduced by the same 20% of staff. These are often people who can develop a lot and fast, yet not necessarily of the highest quality. This is because they go too fast. They lack appropriate checkpoints to ensure they are following standards and not introducing “buggy” or difficult to maintain code. Those who are more meticioulous, follow the standards, and take the time to adequately test their work will naturally produce less, but more superior, code. Meanwhile, those who go fast, do not bother to follow standards, and often do not do adequate testing will produce more, but more inferior, code. This is the opposite of what you want. A PRB helps to check and align the fast, and somewhat careless, people. This way they are not introducing more and more problematic code into the environment.

Well Commented Code

You should have a development standard that requires developed or altered code be well commented. This must be thorough and easy to understand by someone other than the coder. This standard will help with the long-term maintainability of the code. It will also allow you to be less dependent on the person who wrote the code.

To be frank, those who write the code, over time, will likely not fully remember why they wrote the code they wrote without proper commenting. This standard saves you time and money, while protecting your asset.

Many people do not like to comment code, and there are reasons why: it takes time away from developing new code, and they believe their time would be more valuably spent writing code.

This can often lead to a cyclical problem: by not commented on code they are freed up to develop more code, but their code continues to be problematic because it is not commented.

By not enforcing a code commenting standard via a PRB, or some other method, you allow a person to create code not to your standard. This in turn leads to code that is more difficult and more costly to maintain and can threaten your asset.

Performing proper and thorough Unit Testing is also a very good example of all of this. Thorough testing takes time. Code not well tested will have problems. These problems will likely be uncovered only further on down the lifecycle and at a much greater expense. Proper testing will also slow those who would create and introduce “buggy” code.

These type of checkpoints, gates, and reviews, while they take time and cost money to do, could save you much more time and money in the long run. They will also likely give you a far more superior end product.

Consider a house painter. A painter who does not tape off edges, put down drop cloths, and properly clean or prep the walls or their equipment will be able to paint more because they are not spending time doing prep, protection, or taping. Because they are not taking steps of proper preparation, they will not do as good a job and likely will create a mess that will need to be cleaned up. Meanwhile, the painter who does take care of their equipment and who does properly prep by cleaning, taping, and using drop cloths will do a neater and cleaner job. They may not paint as fast, because they have spent time doing other essential tasks.

Peer Review Boards, enterprise architecture review, and other checkpoints and gates are ways to bring sloppy, costly, and inferior practices to light and to thwart these practices before they do damage to your technology stack.