Getting the most from Information Technology

Sunday, October 26, 2014

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.

Sunday, October 19, 2014

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.

Sunday, October 12, 2014

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.