Creating a technology-centered culture

This is the last in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In the finale of the series, I'll talk about how to change your culture so IT actively contributes to the success of the organization, in order to unleash your company's potential by getting the most out of your technology innovation. To describe the change process, I'll leverage John Kotter's 8-step change method.

Step 1: Create Urgency

Let's face it, most people don't want to change. Staying with the tried-and-true is generally more productive in the short-term than trying a new approach. This can especially be true when you're talking about something such as allowing IT to contribute to the overall company strategy. Luckily, the breakneck rate of change for technologies that your competitors are probably using to improve their products and profitability is probably enough to create that sense of urgency needed to push forth change. Here are some things you can leverage to make your case:

• Technology is changing how businesses work. If you're not leveraging mobile, data analytics, or smarter internet-connected devices, your competitors probably are.
• Business leaders can't go it alone. Marketers can't know what problems might occur when connecting various platforms. Operations can't know what security problems they might be creating by purchasing automation software. They need help from the technology experts.

Step 2: Form a Powerful Coalition

Unless you work in an extremely small company, you can't push all of the needed changes yourself. You need to get the buy-in, if not active support, of other influential leaders within the organization. These leaders are not necessarily executives, though you need their support, so you should identify the most influential individuals and make sure they understand what you are trying to accomplish and why it is urgent that you do so.

In this case, you will want to get the most innovative individuals within the company understanding (if they don't already) why their ideas will reach their maximum potential if they work closely with the experts in technology. The executives within the company will likely be reluctant to let IT into their decision-making, so you may need to point out how previous failures could have been lessened with earlier support of IT.

Step 3: Create a Vision for Change

If you did a good job creating a sense of urgency around the change, people will want to implement their own solutions to the problem. Creating a common vision will help ensure that, as people work to implement the change, they work together towards a common goal rather than in parallel towards similar goals. Your specific vision will vary depending on your company and its needs, but starting with creating an environment where all employees are empowered to make decisions is central to a true Stage 4 environment.

Step 4: Communicate the Vision

Once you have a guiding coalition and a vision, it's time to communicate that vision to the company and get them on board. Having one meeting to communicate the ideal future and expecting results isn't feasible. Instead, communicate the need for change as much as possible in as many methods as possible. It's also vital that you do what you say - "actions speak louder than words" certainly applies here. To become a partner to the business, you may want to consider the following:

• Don't hide your developers behind business analysts and project managers. Your development team needs to hear first-hand the problems the business is trying to solve, and business users need to hear first-hand the challenges to make issues go away.
• Encourage your employees to actively participate in strategy discussions - these are more than just "business decisions" and the team needs to give them the appropriate attention.
• Encourage new ideas and implement the good ones. Give individuals the freedom to implement their own ideas, even if the solution isn't the one you'd choose.
• When you can, tie compensation and bonuses to the new objectives.

Step 5: Remove Obstacles

I've met a few people who were frightened of change merely because it is change, but most people have specific concerns that they want to have answers for before buying into the change. Rather than force the change through anyway, address as many of these concerns as possible. To do this, you can:

• Encourage constructive feedback and visibly adapt your plan when valid concerns arise.
• Give your change leaders the freedom and authority they need.
• Alter organizational structure if necessary to reflect the new goals.
• Minimize the influence of resistors as much as you can.

Step 6: Create Short-Term Wins

Creating short-term wins does two things for you:

1. Small changes, especially at first, are more achievable than large ones. Aiming for small wins means you can start making progress without needing a perfect solution.
2. Both success and failure tend to feed on themselves. You want to establish a few successes to prove to people that this is the right course of action.

In trying to create a partnership between business and IT, you can look for short-term wins by:

• Celebrating a successful product delivered successfully because of collaboration between business and IT.
• Implementing a new product idea from an IT person that improved a business function.
• Creating a new award for employees that live the new ideal.

Step 7: Build on the Change

Kotter states that many change initiatives fail because victory is declared too soon. In one example, he states that he tracked the number of changes as the result of a change initiative, and the peak number of changes happened in year 5, a full 36 months after the first quick wins. (https://hbr.org/2007/01/leading-change-why-transformation-efforts-fail/ar/1) It is vitally important that you keep pushing the change. It is easy to get discouraged with the sometimes glacial pace of change, but stay vigilant!

Step 8: Anchor the Changes in Corporate Culture

This last change seems fairly obvious. If you're making a corporate culture change, it goes without saying that the change should be a part of the corporate culture. But if you read Kotter's article that I linked to in Step 7, you'll see that Kotter suggests you do the following to cement the change as a part of the culture:

• Explicitly make connections between success and the new approach.
• Ensure that top management continues to make a good example for the new way of doing things.

And though he doesn't explicitly say so, you should also emphasize your new values when hiring new candidates, setting their expectations that the ideal way is, indeed, "the way we do things here".

Summary

It's easy to say that in order to achieve its fullest potential a business must integrate its technology team with the rest of the business. It is much harder to make that happen in companies where the established normal mode of operation is to treat IT purely as a service provider. Merely telling people that collaboration is better isn't good enough to push forth change. Instead, you'll have the best success if you carefully plan for a cultural transformation.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

Cultural Roadblocks to Implementing Agile

If you had asked me a couple of years ago what type of people didn't like Agile software methodologies, I would have said "people who never tried it and managers with too much focus on the wrong success metrics". If you had told me that there were people who didn't like Agile because they didn't truly understand it, but tried (and failed) to deliver software using Waterfall methodologies altered just enough to look like Agile, I wouldn't have been surprised. But it pains me to admit that I rather naïvely believed that people simply needed to be shown the benefits of using Agile to design, develop, and deliver software in order to become believers. Now I know better. While I still believe that Agile is a superior methodology to delivering software if you care about the right things, here are some (interrelated) cultural problems that can be significant roadblocks to finishing a successful Agile software project.

Unwillingness to change staffing

Central to Agile's core principles is responding to change well. This is important because software needs change quickly and often. In some cases, this can occur because business needs can change on a dime, e.g. a new competitor enters the market. In many cases, change occurs because people working with new software improve their understanding of the underlying need. Whatever the reason, though, software makers need to be able to change quickly.

Because such change is expected, it is impossible to set firm budgets, timelines, or scope for an Agile software project. But it's largely a project manager's job to track and maintain timelines, budget, and scope for projects. Sticking a traditional project manager on an Agile software project is at best a waste of the project manager's time. At worst, though, his/her presence and influence can undermine the newfound agility of the software team.

Unwillingness to embrace uncertainty

As I said earlier, change is expected within the course of completing an Agile software project. Agile teams are built to adapt to these changes by handling the most important issues as they arise and dealing with the rest later. However, some business leaders want to have a plan for every possibility. Spending time to plan for a situation that will never happen is a waste of time and resources under the best of circumstances. But when taken too far, this can lead to "analysis paralysis" and kill the progress of a software team.

Lack of leadership

When ever-shifting priorities are built into your process and mindset, it is easy to get distracted with items of relatively little importance to the organization. Leaders with a strong sense of true business priorities who can persuade others what the right path is will keep the software product moving in the right direction. Weak leadership will allow individuals with a personal agenda to hijack the effort of a software team. Or just as bad, multiple people can try to take the product in multiple disparate directions, creating confusion and frustration in the team while leading to an unfocused product.

Lack of personal responsibility

If you had shown all the items on this list to me five years ago, this one would have surprised me the most. After all, who doesn't want to do a little extra work in order to do much less work in the long run? Agile requires constant communication between the software team and the business leadership, but it also requires business leadership to make decisions and make their teams ready for the coming changes. But not all leaders are willing to do so, unfortunately. There are two attitudes that I've seen from these people:

• People who believe that software is the job of the "techies", so they don't wish to make any decisions regarding the software
• People who avoid getting deeply involved so they don't have to take blame if the project fails, but try to stay superficially involved so they can claim a portion of any successes

Regardless of the reason, to depend on these people who won't take responsibility for the success of their area will almost certainly derail your Agile effort.

Inability to see the big picture

When you are constantly reprioritizing your queue, you need to have a grasp of the big picture, both in terms of current state and ideal future state, to know what features/fixes should be worked on first. When you don't see the big picture, everything seems like a high priority. And to quote a former co-worker of mine, "when everything is a high priority, nothing is a high priority". In such environments, it becomes nearly impossible to know when anything will get done. This will cause people to first lose faith that their items will get done, then to lose faith in both the project and process as a whole.

Extreme change aversion

Few people like change. But there are some people for which change is something that causes extreme anxiety. You can tell who these people are fairly easily in meetings - at the mere suggestion that they might have to rethink what they do their eyes get wide, they literally brace themselves in their chair, etc. When the mere suggestion of a single change can cause this level of anxiety, the thought of constant change can lead to mental shutdown.

Conclusion

Change is hard under the best of circumstances. Changing to Agile is no exception. When you're not dealing with the best of circumstances, it's vitally important to identify that as early as possible to make appropriate adjustments. If you have a team that's smart, is willing to take charge, and is willing to change, then you'll likely have a relatively smooth transition to Agile. If not, then you'll need to take additional steps to prepare your leadership team and the rest of the company for the change.

Peter Principle and Software Architects

It's time to address an uncomfortable truth within IT: technology professionals have a tough time finding, retaining, and promoting people with leadership ability. Instead, technology professionals, especially in consulting, tend to promote people based on their ability to do their current jobs and their knowledge of technology. This type of promotion leads to the Peter Principle, which is the idea that people get promoted until they cannot do their job anymore, which leads to them failing and getting fired. It also leads to business leaders losing their faith that IT can manage themselves, causing IT to lose their place at the executive table.

The problem is that typically people aren't promoted to a job that requires the same skills. Managing people well requires the ability to understand people so they can be motivated to do their best work, which only rarely requires a manager to be able to do a job better than the employees can. A leader (CIO, CTO, etc.) must understand their industry and know how to react to industry trends, and must be able to create plans for the managers to execute. But instead of promoting people based on their ability to do their new job, they're too often promoted based on their ability to do the job that they have. This makes sense to a certain extent - if you have a team member who clearly excels at their job more than any of their peers, would you promote one of the lesser skilled team members?

Within technology departments and companies there is another issue that is contributing to the problem. As I mentioned earlier, promotions within technology areas tend to occur based on a candidate's knowledge of technology. I would argue that knowledge of technology has surprisingly little bearing on how well a software product is built (though a detailed explanation of why that is the case will need to wait for another day), and it certainly has no bearing on turning around an underperforming employee's performance.

Let's examine a fairly common example of the Peter Principle at work: promoting a good software developer to a software architect. Many companies treat a software architect as a senior software developer, but if done correctly, the positions are quite different.

	Developer	Architect
New Technologies	Must understand the details of new and emerging technologies and how they can solve a particular problem	Must understand at a high level how new and emerging technologies can solve a particular business problem
Business Requirements	Must take a micro-level business requirement and anticipate end-user needs (such as form field validation)	Must take a business need and envision how that could be solved (with or without software)
Return On Investment (ROI)	Does not need to understand ROI	Needs to find the right balance between the best software solution and keeping costs appropriately low
People Management	Needs to be able to communicate with peers about the specifics of technology decisions	Needs to be able to communicate with and persuade people with a wide range of experience, from developers to project managers to business stakeholders
Code	Must write clean, clear, understandable, and maintainable code	Must understand why developers focus on code quality and must be able to communicate these reasons to business stakeholders
Debugging	Must be able to find and fix problems on a micro-level	Must be able to look for macro-level logical fallacies in business and technical requirements

Looking at this list, it's not hard to see why people promote their best developers to be architects. On the surface, it appears as though the architect must do everything that the developer does, except have a higher-level understanding and have better communication skills. And I will be the first to admit that having developer skills would help an architect do their job well. But here are some problems that occur when you assume that the best developer can be an architect:

• A good developer needs to be extremely detailed. They must understand where a user might make a mistake on a single form field, and understand how one line of code might cause problems several hundred lines later. If an architect tried to think at this level of detail, he/she would be extremely slow to make decisions as he/she gathered all the information needed to understand the problem.
• Similarly, a developer must be able to communicate very small issues to other developers and to the architect. To contrast, an architect must understand his/her audience and provide the level of detail necessary for that person to understand the issue at hand. Just because a developer can communicate well does not mean that he/she can communicate as an architect should.
• A good developer should spend time on their own learning about new and emerging technologies so they can work with them on a moment's notice. An architect must instead have at least some knowledge over a much wider array of subjects, both technology- and business-related.

In other words, the detail orientation that is needed to be a truly fantastic developer can at times be a hindrance for an architect. Instead of promoting the best developer on your team to be an architect, focus on finding the big-picture developers on your team and training them to be architects. To make this work, you'll also need to build a company structure where there are multiple means for advancement and build a culture where being excellent at a career without being promoted is okay.

You should also take the same approach when promoting people to leadership and management positions within your organization. Promote people based on their ability to do their new position rather than their old. Your company will be better for it.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success

Programming beyond writing code (Part 1)

I recently came across an article by Laura Klein titled "Your Job Is Not to Write Code". I read the article because I happen to agree - it's a software developer's job to solve problems, and too many developers focus too much on the code and not on the problem at hand. I was hoping for another point of view, or at least something I could share on Twitter. Instead, I read a condescending and destructive post from a myopic product manager. I'm going to write a blog post soon about why software developers should be problem solvers before coders, but today I want to respond to Ms. Klein's post.

Quote #1

Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don't always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!

One of the reasons I got into programming in the first place was that I was excited about building solutions to make people's lives easier. Then after a while I realized that it's generally not the programmers who set the strategy, set the scope, determine the metrics for success, or even come up with the general design. But it's these things that really make the most difference in the overall quality of the product. It's this lack of control that led me to getting an MBA and searching for several years for the right position where I did have the control to make a real difference. So I disagree quite heartily about a developer/programmer/engineer having an "enormous" amount of control over anything other than code quality.

Quote #2

For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users' machines. [Emphasis in original.]

Don't get me wrong - I've definitely seen the attitude that "it works on my machine so it's not my problem". But I've also seen the attitude of "I don't want to hear 'it works on my machine'! That's just an excuse, and a pathetic one at that!" The truth is I simply can't always predict how my code will react in other environments and you don't have the budget for me to try. So I will make my best attempt to prevent these types of issues from happening, but realize that problems that only crop up on other people's machines will happen from time to time. And don't be surprised if it takes a long time to fix - any programmer will tell you how incredibly difficult it is to find and fix a problem that he/she can't recreate.

Quote #3

Did you know that our users probably don't have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked. A lot of them have Internet Explorer on 4 year old laptops, so sometimes things you build don't work right on their machines. They're still our users, and it's still your job to improve the product for them, so please make sure that the code you wrote works in a reasonable number of environments.

On its own, this statement is pretty fair. No programmer likes to dumb down their code because of IE's stupidity. Given the tone of the rest of the blog post, though, I feel like I have to defend the programmer's point of view here, too. "Works in a reasonable number of environments" is an extremely vague term. What is "reasonable" to a product manager who is fielding complaints from users is almost always different than to a developer whose primary focus is putting in the latest whiz-bang features. It's important to take a realistic look at the actual number of people with problems. Are we truly talking about "a lot" of people? Or are there just three people who complain a lot? (And yes, I've been in situations where people have said that "a lot of people have problems" when in reality it was a very small but very vocal portion of the total users.)

Also realize that by putting in work-arounds for other browsers, you are increasing the costs of development, increasing the costs of testing, and increasing the costs of support. These costs increase exponentially the older the browser you want to support. You are also increasing the chance that the user experience for people on the latest and greatest technologies will be degraded. In other words, you can't make a website easily accessible to everyone, give everyone the best experience possible, and do so at a reasonably low cost. Therefore it is absolutely critical that everyone stays on the same page as to when these additional costs are worth it and when they are not.

Quote #4

So, to avoid [having problems crop up in production], you need to check your changes in production. Every time.

Here's another quote that if found in an otherwise normal blog post, I wouldn't think twice about it. Given the attitude in the post, though, it gave me pause. To explain why, here's a situation that happened to me earlier this week:

In the process of customizing Microsoft's Team Foundation Server (TFS) to be a time tracking system as well as a work tracking system, I needed to make a couple of unrelated changes. One of them was a configuration change to TFS, the other a code change to a customization I built. I made the changes in our development environment and everything worked fine. I pushed the changes to production, tested each change, and everything still worked fine. But when users got their hands on it, they uncovered a problem when taking a particular action that touched both of my changes.

Most people would understand that problems like this happen. This is true especially when you consider that, in this situation, I had the choice of either spending 4-8 hours really testing the app hard or spending 30 minutes diagnosing the problem, fixing the bug, and installing that fix. Some people assume that just because a bug pops up that wasn't found in testing, that the problem must have been an oversight of the developer pushing up code. And yes, I'm making assumptions here, but the tone of Ms. Klein's post makes me think that she's in the latter camp.

Quote #5

Of course, in order to check your changes in production, you're going to need to make sure that your code actually gets merged and pushed into production. I mean, you can't really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.

In principle, I agree. But if you actually use these words, you're more likely to do harm than good. If you are condescending towards your developers, their mindset will tend towards pain avoidance rather than problem-solving. And which do you think would avoid more pain, delaying pushing up code or pushing up code for someone who apparently thinks she knows your job better than you do?

(On a side note, I actually got scolded twice in the last couple months by a coworker who didn't like that I pushed up code outside of my determined release schedule, despite the fact that I did so to help her team out. Really? The usual response towards someone who goes out of their way is "thank you", not "why is it acceptable for you to not follow an arbitrary process".)

Quote #6

Another thing to remember is that sometimes users do surprising things, which means that it's not enough just to test that your code works under perfect conditions. You need to make sure that it does something reasonable even in error cases and zero data states and when the user does something you might not expect, like use the back button or make two accounts by mistake.

The vast majority of programmers know to test for certain conditions, both for usability and for security. But we can't anticipate everything. I wish I could attribute the source, but the quote "if you make something idiot-proof, someone will make a better idiot" comes to mind. Ms. Klein, as a product manager, should know that better than anyone. And like my response to quote #4, the law of diminishing returns applies here too. I could spend 8 hours trying to break an application or I could spend 30 minutes to find the cause of that same problem and fix it. There are times when spending the extra time is appropriate. There are others when it is not. It is unwise to always assume the correct course of action is one or the other.

Quote #7

There's one more important part to your job. You need to make sure that we can measure whether we're all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes. If you expect the code you are writing to improve user engagement (by improving the user experience in some key way), then you need to have a way to learn whether or not you succeeded. How else will you know if your job is done? Because, as I've mentioned, your job isn't done until you've improved the product for our users.

There are two problems with this statement. The first is that a programmer may certainly suggest that this would be a good feature to put in, but if you read my response to quote #1, you'll realize that whether the feature actually goes in is generally not the call of the programmer/engineer. It is a business/design decision.

The second problem is I've never worked on a project that was big enough, or had a budget large enough, to warrant such an investment. I've certainly been in situations when such tracking would be useful, but at the end of the day, most people are going to throw Google Analytics at the website and call it a day. If you have the budget to write your own tracking, great! Have at it! But don't take it for granted that this is a feature that MUST go into a system! For most products the benefit is just not worth the expense.

Quote #8 (Article Subtitle)

I am lucky enough to work with a small team of fantastic engineers who truly care about their customers. If you are not that lucky, this letter is for you to share with your engineering team.

My advice for you is that even if you feel the need to share this with your engineering team, don't. There's very little chance you will do any good, but a very great chance you will do some harm. Here's what will happen:

If your team is clearly apathetic, then showing them this article will make you feel better for a short time, but then you'll get even more frustrated after it does no good. Your team will tear this blog post apart (sometimes making excuses in the process) and lose respect for you.

If you have a young development team, reading this article will cause them to get paranoid that they aren't doing a good job and they'll get overly-analytical about their own work. They will then start making mistakes by trying too hard and pushing too quickly, blowing your budget out of the water and killing your timelines.

If you have a good team, then they will be annoyed with the fact that you wasted their time to read an article that was full of condescension and devoid of any real solutions. Good leadership requires you to understand problems and find solutions. This article does neither beyond just "work better".

But as I said, I actually agree with more points in the article than not. I just think the tone is horrifyingly destructive. In the next few weeks I'll come out with a post with a different take on this problem.

Hiring in service-oriented vs. innovative environments

This is the seventh in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In this month's continuation of this series, I'll talk about how hiring practices differ among the environments that are worth talking about. (Followers of this series will recall that Stage 3 is unsustainable.) 

Hiring in a dysfunctional environment

If you're unfortunate enough to work in a dysfunctional Stage 1 environment where the goal is to minimize the risk of an IT failure, you should be prepared to do one of two things:

1. Hire someone who only meets the minimum requirements for the job
2. Hire someone who is well-qualified for the job, but be prepared to pay well over market rate

Obviously you wouldn't want to hire someone who is not qualified for the job. But why wouldn't you want to hire someone who is well-qualified for market rate? Stage 1 environments are miserable places to work and well-qualified job applicants in technology generally have plenty of other places to work. Looking for and training a new employee is difficult and expensive. If you're going to hire someone who can get a job elsewhere, you're going to need to pay them well enough to ignore the bad work environment.

When would you choose one over the other? Unless you are actively trying to change the culture of the organization, it is unlikely that you'll have the budget to overpay someone, so you may have no choice but to look for the barely-competent candidates.

Hiring in a service-oriented environment

If your goal as a technology department is to provide a service to the rest of the business, you're probably tempted to go after the superstar technology expert when you have an open position. Try to avoid this temptation. Superstar experts tend to want to work on cutting-edge projects that only result when someone with knowledge of what's possible with technology either drives a project or closely collaborates with the business person driving the project. When the cutting-edge innovation isn't baked into the design, these experts tend either to lose interest in the project or go rogue and add their own innovations.

Instead, you have two choices:

1. Hire a solid contributor at market rates
2. Hire an above-average contributor, either at an above-market salary or find other outlets for creativity

Choice #1 is the lower risk, lower reward scenario of these two. If you choose to hire an above-average contributor and try to find other ways to make the work rewarding for them, be sure that this is communicated well during the interview process and don't oversell the position.

Hiring in an innovative environment

If you have a truly innovative environment where collaboration occurs with the rest of the business, your best bet will be to hire superstar technology people with a passion for problem-solving. These types of people will fit in with the culture of the business best.

However, you may want to consider adding one or two average contributors to the team. You typically want your innovators innovating, but most programmers need to do quite a bit of non-innovative work as a part of their day-to-day jobs. (Don't we all?) Hiring someone who can get this work done will free your best people to do their best work and raise the productivity of the team as a whole.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

Wanting to move to Agile? Certifications are useless.

A couple of days ago, I read an interesting article about how Agile certificates are actively destructive to the Agile community. One of the most important points he made was this: because Agile certifications aren't sufficient to prove whether you are an expert or not, companies that hire certified "experts" to launch their Agile efforts will fail, and therefore believe that Agile is not a valid approach. While I agree with most of what the author said, he missed an important point. There is a significant difference between being able to lead an Agile project and helping a company with an Agile transformation. To see why, we need first to look at what a certification does and doesn't cover.

What certifications show

Good certifications generally show an individual's skill with a particular subject, i.e. whether they understand the terminology and theory about that particular approach or technology. Even the best technology certifications, though, typically do a poor job showing an individual's knowledge of a particular subject, i.e. whether they can make the necessary adaptions to the approach or technology to solve the problem at hand. (A further discussion about skills vs. knowledge can be found in an earlier blog post about age discrimination in IT.)

Why skills aren't enough

If you are in an organization that already is using Agile to great success, plugging in someone with the skills to get started but without the knowledge to lead may not do that much damage. Existing processes and co-workers will often be enough to overcome knowledge deficiencies. But Agile, at its best, is a cultural change, not a procedural one. The minute you start trying to make Agile a procedural change within your organization you've failed. Instead, Agile is more about increasing collaboration and maximizing flexibility than following a process. (For an explanation why, please read my post about the subject from earlier this year.)

Why this can be a difficult cultural change

A manager's job is to ensure that his or her people have what they need in order to succeed. Most managers I know achieve this by doing two things: making sure that their people have the processes and procedures in place to do their job predictably well, and creating and monitoring metrics that demonstrate their team's effectiveness. Adopting an Agile culture makes these two goals extremely difficult. How can you create processes when you're trying to increase collaboration with outside teams? How can you measure success when maximizing flexibility makes monitoring time and scope, the two most common IT project metrics, obsolete?

The other significant challenge that teams face when moving from Waterfall to Agile is that Agile projects have immeasurably more uncertainty. With Agile, scope is always changing, responsibility is shared, and there is no "definition of done". Selling this to a group of people who have a (false) sense of security with a fixed-scope, fixed-budget project can be overwhelming to say the least.

All these sound like Agile skills. What's missing?

If you try to implement Agile in these environments, you're going to run into significant challenges from other people who, either intentionally or unintentionally, sabotage the change effort due to their own discomfort. To get through this, you need a change management expert who can create the sense of urgency necessary to get people behind the change effort. You will have much better luck achieving a transformation with a change management expert who is not up on the latest Agile frameworks than an Agile expert who is not familiar with managing people through a change.

Conclusion

If you are starting, or planning to start, a transformation within your company to a more Agile mindset, don't worry too much about Agile certifications. You want someone leading the project who has done it successfully before. If, in the case of the original article, you're in HR and don't have the skills to evaluate candidates, then get references and hire the people who have already achieved what you're looking to do. Then let the certification be a tie-breaker in case you really need one.

Getting programmers to see the value in management

In my latest post in my Leadership vs. Management series, I'm going to discuss how to get programmers to see the value of management. Most programmers I know don't manage people very well and don't hold high regard for the managers they work with. It can be a fixable problem, though, if you understand the causes.

What is management, really?

Many people confuse leadership with management. To summarize my first post in this series, leadership is about setting a vision for your company and/or employees that will help the company achieve its goals. Management, on the other hand, is about ensuring that employees are doing their jobs in order to achieve the vision. To further clarify, it is a manager's job to look for opportunities to improve, and it is a leader's job to determine the path to make that improvement. If you have perfect employees and trust them completely, you have no real need for managers. That is a big reason why it seems like more and more small technology consulting companies are advertising their manager-free organizational structure.

Okay, what do programmers do?

To non-technical people, a programmer's job seems simple: programmers write code. In large companies or on large projects this might be the case. In these environments, a programmer's job is to make code that implements a software architect's vision. But on smaller projects and in smaller companies, programmers must be flexible problem solvers as well. Many of these problems are related to maximizing efficiency - inefficient code is hard to debug, hard to maintain, and is slow to execute. Programmers may spend days at a time looking to maximize the efficiency of their software in some way, shape, or form.

Putting it together

If you have a group of people who have become extremely good at maximizing efficiency looking at a role (i.e. a manager) that doesn't directly add value to a company, you're going to get some friction. But most programmers understand the value of managing code. Having bad code introduced to a system can cause all sorts of problems, so most programmers have no issue spending resources managing how and where code is written. It's clear to me that programmers (good ones, anyway) dislike inefficiency, not management. Assuming that you have a qualified manager, often the best thing you can do is show programmers who are disdainful of managers exactly what that manager is accomplishing and why. Be logical and thorough. Expect tough questions, but with understanding comes the respect you're looking for.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success

Why Agile Can't Work Without a Focus on User Experience

If you make software for a living, or work with people who do, you've probably heard of Agile programming techniques. Unfortunately what is not as common knowledge is user experience design. But it is extremely tough to do Agile programming well without also being able to incorporate user experience research into your designs.

What is user experience design?

User experience design, or UX design, is the practice that determines how software should behave so that it is as intuitive for the user as possible. The example most often given about how this works is the button on a web page. In many cases, this button says "Submit", in large part because this is how the programmer who created the form sees what the button does. But the user is not thinking of it as submitting the form. Instead, they are purchasing items, signing up for a newsletter, etc. In those cases, a user experience designer would suggest that the buttons would be labeled "Purchase Items" or "Sign Up".

A good user experience designer does a lot more than just naming buttons, though. Here are a few more examples of the types of changes a good UX designer would make:

• Since Westerners typically read from left to right and top to bottom, a page should generally read from more general items on the left to more specific items on the right
• In order to make signing up for newsletters as easy as possible, forms should generally require as little information as possible to get people to follow through with the sign-up process
• Navigation within a website should be as easy as possible, allowing users multiple means to find the same information
• Users should be able to find help for problems when they first start using new software, but this help should not be a distraction once familiarity is gained

The general idea is that software should be easy to learn and intuitive to use, reducing the need for user manuals and increasing overall user satisfaction.

What is Agile, really?

First, it's important to note that I'm not talking about the pseudo-Agile that's practiced at many companies that's really just Waterfall with multiple releases. Agile, when at its best, embodies these principles, as found on http://agilemanifesto.org:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

It's important to emphasize that merely doing your code in sprints does not mean you're doing Agile. Instead, Agile, when done well, is focused on maximizing collaboration by quickly and frequently adapting to users' needs. Sprints, timeboxes, multiple releases, scrum meetings, etc., are all a byproduct of these goals, not the endgame.

A perfect match

Well-executed Agile projects contain changes early and often. In such an environment, creating documentation is difficult and keeping the documentation up-to-date is nearly impossible. Training would also be difficult to do, because changes to the system will come early and often. In order to avoid confusion and dissatisfaction, software teams have no reasonable choice other than to create a system that's as easy to use as possible. Most developers I know (me included), tend to focus on adding as much functionality as possible and lose sight of the fact that less-experienced computer users might not find the system intuitive. This is where the user experience designer comes in. The UX designer should be able to create front-ends to the system which allow users to understand the system and its changes quickly and easily. This increases user satisfaction and user adoption, and frees up developers to continue doing what they do best - adding still more needed functionality to the system. 

Managing for consistency vs. managing for innovation

This is the sixth in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In this month's continuation of this series, I'll talk about how management practices differ among the environments that are worth talking about. (Followers of this series will recall that Stage 1 is not worth pursuing and that Stage 3 is unsustainable.) 

IT as a Service Provider

The primary goal of IT in a Stage 2 environment is to be the technical resource that can successfully bring to life the ideas of the business leaders. As such, the goals of any Stage 2 IT manager should be centered around maximizing consistency and reliability. To achieve this, such a manager would:

• Create processes that maximize predictability and reliability
• Vet new ideas thoroughly before trying them out in live-fire situations
• Focus investment time on incremental improvements that reduce costs
• Be intolerant of "wasted" costs inherent in innovation-related activities
• Focus training time on learning tried-and-true technologies that solve a specific business need

IT as a Business Partner

The primary goal of IT in a Stage 4 environment is to be a full partner to help the business achieve its large-scale, strategic goals. In the 21st century, this means creating a competitive advantage by using technology, though this means that both business and technology personnel need to have a solid understanding of both worlds. To achieve this, a manager would:

• Automate as many menial tasks as possible in order to maximize time spent on innovation
• Encourage employees to implement new ideas that may improve a process, efficiency, etc.
• Focus investment time on game-changing ideas that could provide a competitive advantage for the company
• Manage "wasted" costs due to innovation by replacing dying projects early with others that have more potential
• Encourage a wide range of training from cross-functional assignments to new technologies to industry-related degrees/certifications

If you don't match performance to expectations...

Most IT folks I've worked with naturally gravitate to either a Stage 2 or a Stage 4 mindset. It is extremely important, though, that the manager focuses on meeting the expectations of the company. If a Stage 4 IT manager tries to impose his/her will upon a Stage 2 company, the manager would likely feel frustrated at the lack of cooperation and vision among his/her colleagues, and that manager would be seen as a non-conformist maverick to be avoided rather than encouraged. Likewise, if a Stage 2 IT manager tries to exist in a Stage 4 company, he/she would likely be seen as an incompetent roadblock to progress, and would be in danger of being micromanaged to a Stage 1 environment. Unless you're actively trying to achieve a culture change, you are more likely to succeed working within your peers' expectations than working around them.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

How to Add People to a Late Project Without Making it Later

Many of my readers should be familiar with Brooks' Law, as quoted in Fred Brooks' Mythical Man Month:

Adding manpower to a late software project makes it later

The thinking for this statement is primarily that, when faced with tight deadlines, a software development team would spend more time getting new team members up to speed than they would just doing the work themselves. And so, people have taken this statement for granted ever since the book was published. But is it true?

I've had three times in my career where I was the one brought onto a project that was running late (in one case, already past the deadline and over-budget too). In each case, I did something different to bring the project back on track. In all fairness to Mr. Brooks, my experiences were generally for much smaller projects than what he was talking about, but I believe that my experiences could easily be applied to larger projects.

Start small and simple

One project I helped turn around was an internal work tracking application for one of my clients. The project had fallen behind primarily because of extremely aggressive timelines and expectations at the outset. The team really had no chance of finishing the project on time from day one, and unexpected changes pushed the project even further behind. When I arrived, I saw that the team had slightly less experience than I did with this particular technology, but they were quite competent and very familiar with the business need that we were solving.

To turn this project around, I didn't want to waste the time of the developers on the project any more than I had to, so despite the fact that I had skills to do anything on the project, I focused on doing simple, straightforward work normally done by a junior developer. I started with finishing the user interface for a list page, then I finished all of the similar pages. After I gained some familiarity with the project, I moved into some more simple but time-consuming tasks on the project. This allowed the developers already on the project to focus on the more difficult aspects of development. We finished the project a day before our drop-dead date given to us by the business leader.

Select your targets carefully

Another project I helped turn around was an eCommerce site for another of my clients. The project had fallen behind because of a combination of scope creep and trying to bend the selected eCommerce framework beyond its capabilities. To make matters more difficult, some of the features were beyond the abilities of the developers involved. When I arrived, the team's project manager was working to stop the scope creep, but the development team was focusing all of their time on a small number of the most important (and difficult to solve) problems.

In this case, focusing my time on making as much progress as possible wasn't the right solution. The team was clearly getting stuck on a few specific issues. Since I was the senior programmer on the team, I took over responsibility for fixing the most difficult to solve problems which freed up the junior developers on the team to finish the numerous but easier-to-solve issues. We were able to eliminate the backlog list fairly quickly after that and deliver a satisfactory website to our customer.

Sometimes process is the answer

Another project which I helped turn around was a highly-customized eCommerce application for another client. Both companies agreed that an Agile approach would be better for this project, and so each sprint had a fresh set of deliverables. The client was not happy, though, due to the fact that we couldn't deliver features fast enough. We also were not happy, due to the unusually high stress this project caused. When I arrived, there were seven client contacts giving us suggestions for features or enhancements, and all of them felt like their suggestions should be the highest priority.

The first thing I did, and truthfully the only thing I did, was persuade everyone that choosing a contact on the client side to serve as the Scrum master was in everyone's best interest. After that person was chosen, we told him our capacity for each sprint, and he was responsible for setting our priorities accordingly. After everyone settled into their new roles, we were able to spend less time managing the project and spent more time delivering features. We were happy because we were under less stress. The client was happy because the got more features each sprint.

Conclusion

Adding people to a late project can indeed help turn it around. But it's important to add the right people to a project. Diagnose the cause of the problems associate with the project, then assign new people to address those specific problems. Only then will you be able to turn around badly running projects.

How to leverage a Project Administrator effectively

In my second post in my series about Leadership vs. Management relating to IT, I talked about how project managers need to anticipate problems, decide which issues are worth fixing, and remove obstacles for their teams. Most IT people have worked for a "project manager" who merely ran reports, scheduled meetings, and constantly asked people for their status. In that article, I talked about how this second type of project manager really should be called a project administrator. What I didn't talk about, though, was what do you do if you suspect that you have a project administrator instead of a project manager?

Determine if you have a good project administrator or a bad project manager

Merely noticing that the project manager does a bad job doesn't necessarily make them a good project administrator. Here are some differences between a good project administrator and a bad project manager:

	Good Project Manager	Good Project Administrator	Bad Project Manager
Attention to Detail	Very detail oriented, but pays special attention to the most important details	Very detail oriented, but is unable to tell the difference between important and unimportant details	Not detail oriented
Interviewing	Great at eliciting the details that are important for the successful completion of the project	Good at eliciting all of the details associated with a particular area or feature	Has own agenda during interviews
Scheduling Meetings	Schedules meetings when they are needed, invites the right people	Schedules meetings when asked, invites everyone	Schedules meetings when asked, invites the wrong people
Project Planning	Understands when extra time is needed and plans accordingly	Schedules project plan according to timelines given	Plugs schedules into project management software and hopes for the best
Mitigating Issues	Works with team to solve important issues, lets unimportant issues slide	Works with team to solve all issues	Lets rest of team handle all issues
Communicating Issues	Raises potential problems to the people most able to fix them	Raises potential problems to everyone on the team	Raises issues to the people most likely to give pleasant answers

Identify your project leader

The most crippling problem that I see of projects led by project administrators is that the team lacks focus. When objectives are clear and the project is running smoothly, it is easy to feel like the leadership is adequate. But when the objectives become unclear or the project stops running smoothly, the team loses focus and several individuals attempt to step into the leadership void. To prevent this from happening, choose your leader before the project starts.

Decide if you need a manager

Do you need an explicit manager? Managers typically are tasked with ensuring that each person on the team is doing their job efficiently and to mitigate issues when they arise. If your team lead can serve this role, or if you are running an Agile project and the business stakeholder for your project can serve this role, then you may not need an explicit manager. When in doubt, don't include a manager in the project, and bring one in if it proves necessary.

Play to your administrator's strengths

Good project administrators are very detailed oriented, so give them responsibilities that play to their strengths. Most project administrators are great at scheduling meetings, providing regular status reports, etc. But most project administrators are also good at testing software, reviewing contracts, watching for missing details, etc. In general, look for detailed, repetitive, and straightforward tasks and your project administrator will shine.

Limit the information that the administrator receives

Because most project administrators don't have the hands-on experience necessary to know the difference between important details/problems and unimportant ones, try to limit the information that they receive. Generally I'm a fan of making all information available for everyone, but project administrators really should be on a "need-to-know" basis. Otherwise you risk having them overreact to an unimportant detail, which can distract the team from what is important.

Ensure that the roles are properly communicated

Finally, if you try to do all of this without the project administrator knowing, you will fail. Either the administrator will sense that their role is being diminished and they will force themselves in, or they will become confused and stop functioning altogether. Tell them what you are doing and why. Best case is that you have identified a training opportunity for a motivated employee. Worst case is that you can take some of the administrative tasks away from your business leaders and software architects and allow them to focus on the tasks that only they can do.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success

I'm not impressed by your Klout score. Here's why.

As I've been getting more active on social media, I've started digging into Klout to see if I should care. (If you are new to Klout, I suggest you go to the Klout site to get an overview of what their score is.) Recently, I ran across this article that described one person's inability to get hired because of his Klout score, and his subsequent efforts to raise it which led to job offers and speaking engagements. Clearly Klout matters. But should it? I went through my own Twitter network to see if there was a correlation between qualities that I admired and high Klout scores, and after I was finished I was not impressed with Klout. Here are a few examples why.

Klout doesn't break down score by topic

"Bill" is fairly well known in technology circles for one particular type of technology. He attends many conferences and speaks at many more. He also tweets about new features and techniques for this technology. He also tweets about sports. And movies. And food. And his sleeping habits. I'm sure you get the idea. While Bill has an impressive Klout score of 66, Klout doesn't separate buzz that Bill generates because of sports vs. his professional life. And Bill seems to generate more conversations about sports than he does anything else. While Bill seems to be a great guy and an asset to the technology community, his Klout score simply cannot be compared to other technology guys to see who is more knowledgeable or influential in their areas.

Apparently high volume, even if low quality, is good for your Klout score

"Mike", on the other hand, pretty much only talks about social media-related topics on his Twitter account. He also has a healthy Klout score of 68. So does that mean that Mike would be someone to hire for a position or a speaking engagement? I've read several of Mike's articles, and they consistently start by stating a couple of vague, obvious points. Then right when you'd think that a truly informative, insightful conclusion is about to appear, his articles stop. But Mike tweets frequently and has a HUGE following, which leads to his high score.

High quality is rewarded, just not to the same degree

"Thomas" consistently posts high quality content on Twitter. His posts, though, are generally targeted towards people new to one particular concept when its most vocal supporters are fairly advanced. As a result, his engagement with others is somewhat lower. His Klout score of 57 is still respectable, but it's clear that Klout values his contributions significantly less than others in the technology field.

You're an expert in what?!?!

Finally, when I looked at my own Klout score, I was surprised to see that apparently my most influential topic was RabbitMQ. I was even more surprised after I looked at Wikipedia to find out what RabbitMQ is. Apparently it's an open source messaging system, but I never tweet about messaging systems and most of my posts about open source software are about how over-hyped it is. Somehow, Mac OS X Snow Leopard and Cisco made the list too, despite my ignorance of those two topics. It's tough to take the scoring system of a company seriously when it is so ridiculously far off on my own areas of focus.

Conclusion

Given these problems, it is tough to justify using a Klout score as a major criterion in a job search or in looking for presenters for a conference. However, Klout appears to do a good job in measuring an individual's influence using social media. Here are two areas in which I would use Klout heavily:

• I would never hire a social media marketing expert without a high Klout score
• If I needed a sales person in an industry whose target audience is on social media, a high Klout score would be an important criterion in choosing a candidate

In both of those situations, you want someone who knows how to generate attention using social media, and Klout is probably as good a way as any of assessing them. 

That doesn't mean that if you're not a sales person or a social media marketer that you should ignore your Klout score, or that it doesn't matter. While I don't put much faith in the score, other people clearly do. So it's reasonable to go through some efforts to raise your score, just don't lose perspective.

Why IT pros may be their own worst enemy in getting a chair on the executive table

This is the fifth in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I have talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In this month's continuation of this series, I'll use the issue of whether the CIO gets a seat at the executive table as a proxy to discuss whether the CIO is respected within the organization, and how IT professionals can unwittingly sabotage their own chances of getting this respect.

You'd think that the CIO already has a seat at the executive table. In many companies, this is not the case. According to the Financial Times, only half of CIOs sit on the operational board of their company, and less than a third report to the CEO. So just because the CIO has an executive-level title, they clearly are often viewed as less important than, say, the CFO or COO. In the age of such pervasive technology that is vital to both smooth day-to-day operations and game-changing innovation, companies that don't have a CIO at the executive table are putting themselves at risk of their competitors passing them by. Technology professionals blame business people for this, but how much of this is the fault of technology pros themselves?

In order to answer this, we must first look in more detail at different attitudes prevalent within IT and how they would mesh with the stages I mentioned above. Here are the attitudes of IT professionals I've encountered in my career:

Combative - These IT professionals generally believe that the business people they work with are incompetent and should therefore be worked around rather than worked with. A combative CIO is sometimes a master at technology, but cannot understand (and doesn't wish to understand) why others aren't as knowledgeable. Such a CIO would want a seat at the executive table merely because he/she doesn't trust the people on the executive committee to make the correct decisions.

Compliant - These IT professionals generally believe that the business people own IT, and they view themselves merely as service providers to the business leaders. A compliant CIO is usually up-to-speed with technology, but often lets business drive innovation and only takes leadership around cutting costs. Despite being a follower rather than a leader, such a CIO would see himself/herself as a peer to the other C-level executives, and therefore believe that he/she deserves a seat at the executive table.

Collaborative - These IT professionals realize that technology is used most effectively when business leaders and IT professionals work together to create solutions. A truly collaborative CIO would be up-to-speed on both technology and business issues, and would constantly bounce around ideas with his/her business peers. A collaborative CIO would want at seat at the executive table in order to help shape and direct business strategy to make the most of available and emerging technologies.

It should be pretty clear to anyone who isn't himself/herself a combative CIO that a combative CIO doesn't belong at the executive table. He/she simply does not have the ability to build the personal relationships necessary to build trust. In fact, a combative CIO is likely to alienate his/her peers to the point where he/she would create a Stage 1 environment within the company and be viewed as a cost of doing business.

Most compliant CIOs probably believe that they belong on the executive committee due to the fact that other C-level employees within the company are. But it's tough to take someone seriously as a leader when his/her goals are limited to cutting costs and implementing the visions of the other leaders. Such a CIO would push his/her organization to adopt a Stage 2 environment - respected as a vital part of the business but still viewed as a cost center rather than as a source for innovation.

Most collaborative CIOs believe that they belong on the executive committee because they do. These are the leaders that have the vision to utilize technology to best achieve business objectives. Their vision would be such that they would push their organization into a Stage 4 environment. He/she would be well-positioned to ensure that the technology that the company is using is well-suited to achieve the company strategy and vice versa.

Finally, it is important to note that even the best CIO can only do so much to change the culture of an organization. A collaborative CIO in a Stage 1 organization probably won't get anywhere quickly - the business is already predisposed to seeing any mistakes, real or perceived, as proof that the CIO can't be trusted. It is unlikely that a qualified, collaborative CIO would stay long in such an environment. Likewise, a combative CIO could very likely ruin the trust present in a Stage 4 environment. So even though technology is so pervasive in today's business world, it takes the right CIO and the right environment to get a CIO on the executive committee.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

How to Manage Agile Software Projects

In my third post in my series about Leadership vs. Management relating to IT, I will talk about how to manage Agile software projects. Before I do that, though, I feel that I need to clarify the difference between true Agile and the pseudo-Agile used by most service organizations that I'll call "Iterative Waterfall".

As I discussed in my post about Agile a few months ago, the goals of any project leader who is truly taking an Agile mindset to their projects are to reduce wasted effort and to see value from the project as soon as possible. However, most service organizations' customers are focused primarily on two questions before the project gets started:

1. How much will this cost me?
2. How long will this take?

As we'll see in a moment, the methods that people have created to eliminate wasted effort and minimize the time before realizing value make it extremely difficult to answer these two questions. The result is that companies make a compromise by setting the scope of the project first, then creating a timeline for the effort, and then releasing the software in small batches on a regular basis. Iterative? Yes. Agile? No. Again, the point of a true Agile project is to reduce wasted effort, which means being able to easily adapt to changing priorities anytime during a project. People still call that type of effort "Agile", though, so I feel like I need to address it here.

Managing a Pseudo-Agile Project

Managing the actual effort during the progress of an Iterative Waterfall project isn't much different than managing the progress during a pure Waterfall project. Here's a rough overview:

1. Define your scope.
2. Organize your desired features into logical (and roughly equally-sized) groups, preferably groups that when completed represent usable software. This is like pure Waterfall in that you have milestones built in, but unlike pure Waterfall the milestones are equally spaced in the project plan.
3. Decide in which order your groups of features must be developed, and organize your project plan.
4. As the project continues, track effort and make adjustments to your timelines/scope/daily effort as necessary.
5. When a change in scope is needed, have contentious discussions about whose fault it was that the needed feature was missed during the requirements gathering process.

Managing a True Agile Project

Since Agile is meant to be, well, agile, managing these types of projects is significantly easier. Essentially, you need someone to manage scope for each sprint, but otherwise Agile teams are usually managed by a technical lead. How does this work?

1. The business leader determines what features are needed in the near term.
2. The software team estimates the amount of effort needed to implement each feature.
3. The business leader and software technical lead negotiate what features will go into the next release.
4. The delivery team meets each day to inform the group of their progress. Slower members of the team are helped and trained, and perpetually slow members of the team are removed.
5. Repeat steps 1-4 as needed until the features requested are not worth the effort of putting in.

Yes, removing most of the management for a project makes most middle managers uncomfortable. But the purpose of management is to ensure that teams and individuals have what they need to succeed, and this process does that wonderfully. The need for managers is greatly reduced, freeing up the business leader to focus on the value that the project brings without the overhead of the now unnecessary managers. This should free up managers to focus on adding more value to the organization or finding other portions of the organization to simplify and improve.

Other posts in this series

June: An introduction to Leadership vs. Management

July: Is a project manager the right person to put in charge of your software project?

August: How do you manage an Agile software project?

September: How to leverage a project administrator effectively

October: Getting programmers to see the value in management

November: The Peter Principle and software architects

December: Creating a leadership team to make your software project a success

Who is to blame when a security breach occurs?

Last month, I wrote about how it is impossible to make software systems 100% secure. Essentially, companies trying to secure their systems should constantly be asking themselves whether spending extra money on security is worth mitigating the risk of a breach. When a breach does occur, though, people inevitably look for someone to blame. It's usually the CIO who gets blamed (and often fired). But is this reasonable? After all, the decision to spend more money on innovation and less on security is a business decision, not a technology one. So the answer is: it depends largely on the culture of the company.

To help describe company culture, I will again leverage a framework developed by two Harvard Business School scholars that defines the levels (or stages) in which manufacturing interacts with the business, which I have adapted for IT. Here is a summary:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors, or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

I'll ignore Stage 3 here because it is not sustainable, but we can safely examine the cultures of the other three environments and how they pertain to blame when a security breach occurs.

Stage 1

If a company is in Stage 1, it is inclined to think that anything that goes wrong with anything technology-related is clearly IT's fault. In this case, though, nothing could be further from the truth. A true Stage 1 leadership team wouldn't have given the IT security staff enough resources to adequately secure the systems, since security is more of a risk mitigation activity than one that directly improves profitability. By placing the IT staff in a position to fail, the leadership team should take the blame for any failure. 

Stage 2

Based on my experiences in Stage 2 environments, business leadership and IT leaders probably haven't had a conversation about the risk/reward balance inherent in any discussion about how much money to spend on security. In such an environment, IT is focused on providing the services that the business requires, and the business leadership is content letting IT handle all of the "technology problems". Any discussions about the business drivers behind IT priorities are indirect at best.

Even though the communications about security issues are indirect, one can usually tell where the business priorities lie based on the tone of the communication between business and IT. If the business is excessively focused on cost-cutting or innovation, security is going to be neglected. If the signals the business leadership team is sending to the IT team are balanced and rational, then it is primarily the technology team's responsibility to ensure that infrastructure needs, such as security, are being adequately addressed.

Stage 4

In a Stage 4 environment, since IT is an integral part of the business leadership team, all parties should have agreed to resource allocations between innovation and security. Therefore, the entire business shoulders some of the blame for a security breach. This can be especially true if the leadership team (including IT) decides that cost-cutting or innovation is more important than security at the moment.

It is worth noting that there can be valid business reasons for focusing at any given moment on innovation or cost-cutting at the expense of security. It is not a wise business decision to neglect security in the long run, however.

Final Thoughts

You probably noticed that I didn't go into detail about whether the rank-and-file IT workers should be blamed. Yes, individual workers make mistakes. But companies with healthy cultures, i.e. Stage 4 companies, tend to hire better individuals and put them in situations in which they can succeed. In these situations, it is more likely that a security breach is caused by reasonable differing priorities or an honest mistake than by a fire-worthy incompetent decision. Conversely, companies with unhealthy cultures, i.e. Stage 1 companies, generally can't hire good employees, so replacing bad employees with other bad employees won't help the situation. Only fixing the culture will fix the issues.

When Technology Acts as a True Partner to the Rest of the Business

This is the fourth in a series of eight posts that examines the relationship between business and IT. Based on an article examining manufacturing by Steven Wheelright and Robert Hayes, I talked about four different levels (or stages) at which IT can interact with the rest of the business:

• Stage 1: Internally Neutral (Minimize IT’s Negative Potential)
• Stage 2: Externally Neutral (Parity with Competitors or IT as a Service Provider)
• Stage 3: Internally Supportive (Provides Credible Support to the Business Strategy)
• Stage 4: Externally Supportive (Provides an Important Contribution to the Competitive Success of the Organization)

In previous posts, I talked about how Stage 1 was not a stage that a functional company would find itself in, how Stage 3 was inherently unstable, and how Stage 2 is a comfortable place for both business leaders and IT, but limits the potential of your business. Today I'll go over Stage 4. Wheelright and Hayes called this "Externally Supportive", but I'll change this to "Technology as a Partner" in my discussions.

In the Technology as a Partner model, the IT leaders would truly be partners with the rest of the business in their shared goal of maximizing the business value. In other words, the IT leaders would be equally responsible as the business leaders to create and cultivate visions for new technologies that would enable the business to succeed. In fact, a true Stage 4 organization wouldn't separate IT vs. business leaders - they'd both just be "leaders". Both groups would be responsible for keeping up with the latest business and technology trends, although everyone would have their own perspectives.

To make this work, you need to have a large amount of communication and trust between different groups within your organization. This requires an entirely different management approach than is expected out of a business in the other three stages. To further clarify this difference, here is a chart of skills needed as defined by the authors of the original article:

Alternative Views of Work Force Management (Exhibit 3)
Stages 1, 2, and 3: Traditional, Static	Stage 4: Broad Potential, Dynamic
Command and control	Learning
Management of effort	Management of attention
Coordinating information	Problem-solving information
Direct (supervisory) control	Indirect (systems and values) control
Process stability/worker independence	Process evolution/worker dependence

One more that I would add is that Stage 1, 2, and 3 employees focus on finishing tasks, where Stage 4 employees focus on accomplishing goals.

Companies whose technology team is a true partner to the business have several significant advantages over its competitors:

• Business-savvy IT professionals and IT-savvy business professionals can understand how to extract value out of new technologies much more quickly
• High trust in employees makes it easier to implement Agile (as opposed to the pseudo-Agile that's popular today), leading to a higher project success rate
• Greater responsibility for individuals means younger employees have a greater chance to develop their leadership and management skills
• Lower requirements for micro-managing employees leads to more productive managers
• Stage 4 companies attract better employees

I could go on, but you get the idea. If you want to be a truly successful company, you need to strive to make the technology team true partners of the business (Stage 4). How do you get there? Unfortunately it's not a quick or easy path, but my next four blog posts in this series will attempt to answer that question.

Other posts in this series:

May: Levels of function (and dysfunction) IT can have with business

June: Why Stages 1 and 3 are not viable long-term stages

July: IT as a Service Provider May Be Bad for Business

August: When technology acts as a true partner to the rest of the business

September: How IT professionals can be their own worst enemy in achieving Stage 4

October: How your Stage would affect your management practices

November: How your Stage would affect your hiring practices

December: How can an organization reach Stage 4?

5 reasons for IT project failures aren't IT's fault

I've been involved in a number of IT projects in my career, ranging from overwhelming successes in every sense of the word, to projects that came in a full 100% over budget, to projects that came in on time and on budget but didn't meet the business needs. Most of the articles that I read about IT project failure focus on IT. This is understandable, since by definition, IT is involved in every IT project failure. But when an IT project fails, there's usually plenty of blame to go around. What are some reasons that these projects fail that aren't directly related to IT?

Lack of shared understanding of the project goals

It is tough enough getting business leadership and IT on the same page as to what should go into a software product, where compromises should be made (in quality vs. cost vs. time-to-market), etc. This becomes infinitely more difficult when the individuals on the business team cannot agree to what the product should be. Minor disagreements are normal, and every good IT manager plans for them. But major disagreements can doom a project before it starts. In my experience, the two major sources of these types of conflicts arise when:

• The business stakeholder leading the project only has a vague idea what the project's goals are
• Multiple business stakeholders leading the project have conflicting ideas as to what the project's goals are

The second scenario is less challenging to fix - in this case the stakeholders would need to choose a leader to represent the group and find ways to appease everyone. While this won't solve all issues, it will simplify communication and clarify the vision. It's tough to rescue a project in the first situation, though. In this case, it's often best to stop the project, or start over with clearer goals.

Slow feedback

By far the most common reason that I've encountered that IT projects run long is that the business leaders directing the project are slow in giving feedback. When feedback is slow in one particular area (i.e. what to do with one particular feature), or when feedback is slow about minor details (i.e. what exact wording should go on a button), the software delivery team can usually work around it. But when feedback is consistently slow, or feedback is slow in a particularly critical area, the IT team either has to start pushing deadlines or has to start making guesses as to what the functionality should be. If the IT team is making guesses, you'd better hope that they thoroughly understand the business need behind the system being created, otherwise expect moderate to severe budget overruns as their decisions are removed from the system.

Inability to differentiate "need" from "want"

The average business user would be shocked at the complexity that is present in even the most simple-seeming software product. On top of that, the more complex the business need is, the disproportionately more complex the software needs to be to support it. The best way to combat this problem is to keep the software as simple and small as possible, then build on it as time and budget allows. When business leaders cannot differentiate the things that they must have in order for the project to be a success and the things that they would like in order to make the project better, uncontrollable scope creep occurs and the project never gets finished.

Inability to talk conceptually

Until businesses get smart and start hiring IT personnel who have a deep knowledge of the business they're supporting and business leaders who have a reasonable understanding of the technology they're using, we're going to have a gulf between the vocabulary and understanding of the business leaders and the IT staff that support them. The level of difficulty will vary depending on the skills of both the business leaders and the IT staff. To simplify the discussion, I'm going to define some terms that describe the levels of understanding that business leaders can have about their processes and IT:

• A leader has deep project-level understanding if they are a subject matter expert and have experience/skills in envisioning how their processes could be simplified by software.
• A leader has subject matter expertise if they understand both how their business works and why the processes are the way they are, and can communicate their understanding to others. They don't, however, have the experience or skills to know how specifically how software can fix their problems.
• A leader is a figurehead when they neither have the understanding of their own business processes nor have an understanding of the benefits and limitations of software. (Note, a person who has an understanding of their processes, but cannot communicate them to a non-expert such as IT, might as well be a figurehead for the purposes of an IT project and will be treated as such here.)

I will also draw on a previous post to describe IT's understanding of the business:

• A Stage 2 IT leader will be a technological expert who focuses on delivering what the business team asks for.
• A Stage 4 IT leader will be a technological expert who has an understanding of the business and focuses on delivering a solution that meets the stated business needs.

To show what kind of effect this can have on your project's chances of succeeding, here is a chart that shows my experiences with skill levels and project success. (Note: all cells assume that the IT staff is competent with the technology they're using.)

	Stage 2 IT	Stage 4 IT
Deep Understanding	The business leader will lead the project, and the project will generally run smoothly	Expect success
Subject Matter Expert	Expect a product that is delivered late and/or over budget, as there will be a lot of trial and error during the development process, but the product should eventually meet the business needs	Expect the IT team to lead most aspects of the project and that the business leader will focus on ensuring the details are right
Figurehead	Expect failure	Expect the project to go sideways as poor communication derails the effort

Note that the best chances for success lie when someone, either the business leader or IT, has an understanding of both the business process and the underlying technology. Without that, the ability to communicate both the how and the why of the business processes at hand become vital to the project succeeding by any definition.

Lack of focus

If you try to make a little bit of progress on everything, you won't make significant progress on anything. Yes, there are a lot of areas that need to be improved, but you will be significantly better off by getting one problem fixed then moving onto the next rather than trying to solve everything at once. There is a balancing act that must be done here. If you try to proceed with too many ideas at once, the project will stall and die. If the business leadership tries to be too hyper-focused on only one or two needs, they risk losing the enthusiasm and support of the people who will use the software.