Today we have a guest editorial from Bill Nicolich as Steve is on vacation.

Many people have worked hard to help explain why software/tech projects go right and wrong. Some of the available material touches on the impact of people's perspectives - i.e. how people look at things. Here, I look closer at one particular perspective: what counts as work. I'm looking at what counts at work in the minds of various people who affect the outcome of projects. I argue that this particular perspective deserves special attention and that those who pay attention to what others think about it can gain insights and advantages.

Another way to say it is we should be thinking about what counts more and what counts less as legitimate work on projects. Of the many perspectives and attitudes, I should explain why I think this one is important. In short, this perspective affects the "incentive ecosystem", which in turn greatly determines the fate of projects. I'll explain more below.

There are already lots of factors that threaten the success of team-based design projects. There's the lack of resources. There are turf wars. There are hidden agendas. Now imagine that key people don't see the value in doing things that are crucial to the success of projects. Add that to the mix, and one can imagine how vital it is that important activities are valued.

The perspective matters because people take the answer of what counts less and what counts more as legitimate work as a guide for what they should shift their focus to and away from. Sometimes that shift of focus can have grave hidden consequences.

Imagine that I create a software job with a set of responsibilities - all of which are needed and important. I tie general incentives to the whole set and hope that each element will be handled well. This is the basic mechanics of most jobs. But somewhere along the way, I start sending signals about the extra importance of one or two responsibilities, and I rarely, if ever, talk about the other responsibilities. Imagine that I frequently send reinforcing signals about the act of writing code but never about planning, documenting, collaborating, deciding, reflecting or learning.

If we apply the general truism that people tend to respond to incentives, then what could we predict will happen over time? Plenty of code will get written and the other activities like planning, documenting, collaborating and so forth will tend to get neglected - potentially to the point of disaster. This can lead to unsustainable levels of technical debt, unmanaged risk to important technical assets and disorganization at several levels - the level of code, project, solution portfolio, technical environment and so on.

How often has it happened that someone walks into a technical environment only to find astonishing disarray everywhere,  and then this person wonders, for the love of humanity, how things could have gotten this way under the care of rational human beings given adequate resources? Well, in a way, it's simple. Perspectives aren't complete. Incentives are off kilter. Hit the fast-forward button for a while and there you have it.

It's great when that perspective is complete, but it's easy to get wrong. I hope to further explain how to notice if that perspective is amiss by considering some common scenarios. I'll start with a caveat about noticing things. There's always a context to consider, and it's best to have frank conversations with people. In addition to that, one can notice people's behavioral patterns and listen to clues in what people say. In the scenarios below, I'm looking for clues, which can then be considered in context, and then hopefully would be followed up with frank conversations that give people a chance to explain their views.

Here are two scenarios. In the first scenario, a software developer says "It's crazy that I have all this stuff to do that gets in the way of my real work. Isn't there a business analyst or somebody else that should be doing all this stuff, so I can spend more of my time writing code?"

In the second scenario, a business manager says "People have been talking about this for two months with no end results. Nothing is getting done!"

There's an element of reasonableness to these comments - and it's easy to miss other signals. Both comments deserve some reflection. Both offer clues about the underlying perspective owned by the speaker about what counts as work and what does not.

I'll consider the first scenario: the software developer's comment. I'll focus in on the part about "real work."

To sketch up the mental model at play here, I see two categories of work. There's "real" work and then there's fake/pointless/useless/inappropriate work. In this model, the act of writing code belongs to the first category. All the other stuff belongs to the other category.. These are presumably things like talking to people, collaborating about requirements, documenting stuff, attending meetings, and the like.

To help put it into perspective as to how incomplete this model is, I'll refer to a model laid out by Agile Manifesto signer Alistair Cockburn in his book Agile Software Development. Cockburn views software development as a "cooperative game of invention and communication" with three possible moves: invent, decide and communicate. From perspective, writing code is just one segment of the "invent" move. Emphasizing one move while neglecting the others puts the game in jeopardy.

It's common on software projects for the focus to shift heavily toward code-centric activities like demonstrating that code has been written and deployed. That might seem like a good thing for a while with no detectable drawbacks. However later, big problems can surface and might seem unconnected to anything in particular. For instance, solution quality can suffer. Defect rates can go up. Solutions can miss their intended mark. The environment can decay. People were too busy writing code. They didn't have time to write tests or do things safely. They neglected to communicate key theories to others. They were too busy to clean up messes.

Another unintended but common side effect of this off-kilter emphasis on the act of writing code is that it might become difficult, if not impossible, to change course once the business segments have become accustomed (addicted) to a certain level of code output.

A similar refrain is an attitude like "this refactoring code business is for the birds. I want to be doing real software development, like building new systems." There's a signal here about what counts as legitimate work for this person and what doesn't. From there will follow a predictable pattern of focus and neglect. Code won't get improved. Lots of new code will get written (probably in need of refactoring).

I suppose my message to those working with developers is "ignore these signals at your peril." A way to address these issues is to go have frank discussions. Monitor the perspectives and reinforce a good perspective amongst developers. Don't assume that everyone appreciates the value behind the neglected activities today as much as they once may have. Don't assume that verbalizing it once is sufficient.

Try linking typically neglected activities to their value proposition in the same statement. For instance:

• "Our effort to collaborate about architecture helps make sure important options are considered."
• "Our time spent attending meetings helps ensure that priorities get decided."
• "Talking to stakeholders and expert users will help the team understand the actual requirements."
• "Commenting code helps create sign posts for others to follow."

Now to the second scenario: the business manager's comment about "nothing is getting done." It's easy to grasp the overall message, which is that "not enough" is getting done. It may seem like splitting hairs on the outset, but it's worth pushing back on the notion that "nothing" is getting done, because it reveals the underlying perspective about what counts and what doesn't. Again, if code output is all that counts, then the "incentive ecosystem" gets altered.

Strictly speaking, the comment acknowledges that something is getting done, but somehow those activities don't seem to count. There are meetings that have been held. Decisions were likely made. Ideas likely became socialized. Shared understandings were likely achieved. Designs were likely considered and started. If message goes out that these things don't count , how could that be good?

One can relay the message that not enough is getting done, but it should be done carefully. Thinking of its effect on an "incentive ecosystem" will help people realize that care should be taken when crafting and relaying messages.

I don't think it's uncommon for influential people like bosses and key stakeholders to be unaware of very key responsibilities and activities of technical jobs. They can operate with a perspective on what counts as work that is incomplete or flat wrong if success is the goal. If the perspective is off kilter, an influencer can easily neglect to incentivize key success factors to the detriment of people's careers, the technical environment and the project at hand. They can do this without even knowing it.

That said, I also don't think it's uncommon for technical workers to hold a less-than-complete model of what well-functioning technical jobs entail for a variety of reasons. Sometimes it's inexperience. Other times, it's a tendency to focus only on strengths like solving puzzles and to discount weakness in areas like communication. Still other times, this view comes over time from listening and becoming entrained by the wrong set of signals, mixed with not learning the whole picture. A software developer or other technical job holder can remain blind to a broader and healthier picture of what the job is consists of.

There's room to learn and grow on all sides. No parties involved can afford to take this key perspective for granted. It won't fix itself on its own.

With all that in mind, I hope I can encourage people to go have frank conversations, listen and pay attention to what counts as work in the minds of people affecting software/tech projects - so that this perspective can become an asset rather than a liability. A good perspective of what counts as work can go a long way toward fixing what's wrong and achieving success.