Compound Thinking

What is data?

Ocean asks on his blog is data an asset?

Data is certainly not like many other assets, it doesn’t depreciate, you can copy it endlessly, and it’s next to impossible to imagine a commodities market for data. Heck copying the data can either increase it’s value (think “The DaVinchi Code”) or decrease it (think passwords). People don’t pay for data as much as they pay for human attention. You can use data to get attention or you can use attention to collate, assimilate, and otherwise transform raw data into useful information, but either way data needs people to understand and interpret it to become valuable.

So at best:

data + human_understanding == value

Bruce Schenier takes it one step further, calling data the pollution of the the information age.

Data Pollution

Data sucks up space, time and human attention. But more than that, data can be parsed, manipulated, and transformed to fit various agendas. And in a world where data about all of us is “owned” by various large corporations, from Amazon, to Google, to Enron, it’s not always clear how that data will be used. Besides which millions of credit card numbers are stolen from various companies who store our data “in good faith.” Data costs money in terms of maintenance, in terms of storage, and in terms of liability. Heck, I know people who work for companies who have an e-mail retention policy — which is really more of a mandatory e-mail deletion policy.

Polluted Data

And that assumes that all that data is verifiable true, and that’s definitely not the case. I sold a car once and the new owner didn’t take it to the DMV to get it registered before his friend drove it without a license and got it impounded. And that showed up on my credit report for years. I have a friend who somehow ended up “deceased” even though she’s still very much alive and well.

All of this is to say that as software developers, IT Mangers, and companies in general need to think a lot more about data, and to invest in some better terms for the various different things we call data.

We need to differentiate between raw data, information, and knowledge. We need to help our customers think about the life cycle of the data they want us to capture. We need to educate people about the costs and benefits associated with keeping data, and ultimately we need to follow the mantra:

Think before you store

And if you’re concerned about privacy, and individual liberty, please take a few min and read Bruce’s article.

The motivational meeting…

Last week, I ranted a little bit about motivational meetings. Today I’ll make the opposite case.

Why have motivational meetings?

The right way to use motivational meetings is to reaffirm the purposes of the group, and help people to connect the dots between their individual efforts and the collective goals of the group, and to connect those goals with their own individual aspirations.

Basically, motivating people is easy:

• Give them work that is meaningful to them and to the organization
• Treat them with respect

Treating people with respect includes paying them a fair wage, and not doing any of these things.

Among other things it also means not letting people who aren’t contributing to the common goals of the organization hold back the group by not doing their job.

Research has shown that one of the survey questions most highly correlated with motivation and performance is:

Does my supervisor, or someone at work, seem to care about me as a person?

Which is another way of saying does your boss respect you. At the same time the single highest correlation for any question was:

I get to do what I do best everyday at work.

So, it’s really important to line people’s intrisic skills and internal long-term motivational drivers with the work you ask them to do.

If you’re not doing those two things, motivational meetings are a loss. If you are doing them you can use a meeting to remind people of how their deeper motivations are connected to what they are doing now.

P.S. My info on the top questions and their correlation to performance comes from Gallop research via the very interesting book First Break All the Rules, which is one of the best, and most evidence based, books on managing for exceptional performance I’ve read.

So many revolutions, so little time.

Tim Bray is blogging about “inflection points” in the uptake of various technologies.

Python get’s a very positive review:

Today you’d be nuts not to look seriously at PHP, Python, and Ruby.

So, the rise of the so-called scripting languages is one of the inflection points, but it’s not the only one.

He singles out web-framework development as one place where there’s a lot of stuff happening, and a lot of new “rails-like” frameworks are cropping up all the time. TurboGears will live or die in the context of a much larger web-development revolution, and we need to be prepared to make our way forward in the midst of that.

What comes after rails will not be a rails clone. It will learn the right lessons from rails, avoid the pitfalls of rails, but it will also need to carve out something new and better than rails. For RDBMS users, I think the key difference between TG and Rails is the power and flexibility of SQLAlchemy. We need to “sell” this better.

There are a lot of other revolutions coming according to Tim. And I do think we’re looking at big changes in terms of everything from programming language choice, to web-development tools, to end-user desktops, and data persistence mechanisms. We’re also just beginning to see what the world of high-end javascript and other “rich” internet applications is going to do to our view of end-user software.

He doesn’t even mention the rise of EC2 and the Google App Engine as sea-changes in the way we buy computational resources, and I think that’s going to have a huge impact.

In the end my prediction is that the way we develop applications will change more in the next 5 years than it did in the last 5, and it’s time to start getting our heads wrapped around these issues, or we’ll be left behind.

An Agile Paradox: People over Process (part 1)

The agile manifesto says we focus on “people over processes”.

And I think that’s the right thing to do, people are ultimately more important than processes. But, at the same time, there’s a paradox to be thought through here, because focusing your management efforts on people can be counterproductive. If you focus on people it’s easy to blame them for failures, to try to change them, and to loose sight of the processes which got you the wrong people, or which made it difficult or impossible for the right people to do the right thing.

In fact much of the benefit of the Lean/Six Sigma camps comes from the notion that you pretty much always get better results if you always assume it’s a process problem, and try to improve the processes.

The solution to the People over Process paradox is easy enough:

Good managers lead by creating an environment where people are empowered, in other words they lead by focusing on a different kind of processes. Processes which put people in charge, and which encourage learning and self-correction. That might sound hard, but really it’s not as complicated as you think. For, example Toyota has thrived by creating a “metaprocess” which gives every employee power over the day to day processes of their job. These meta-processes which make standards of work clear, and make it the team’s responsibility to relentlessly and ceaselessly continue to improve those standards. Employees are expected to think, and to act on a regular basis to improve the way things are done. And they are ultimately “in control” of the processes which govern their work.

If you focus on the right metaprocess, you won’t get into the kind of “process problems” that the agile manifesto was written to combat. Processes will be owned by the people doing the work, not imposed from above, and they will be adjusted continuously to meet the daily needs of the project.

Processes must serve people. But at the same time people following good processes — and even more importantly good process improvement processes — are more productive than people with no process. So, removing process isn’t the answer to “People over process” it’s providing people with control over the processes, and with a well defined way to improve those processes.

Bar Camp Ann Arbor?

I’ve been toying with the idea of putting together a Bar Camp later this summer. I’ve got a potential venue, and some interested people. But I’m looking for some feedback, and some people who might be willing to help with some of the organizational details.

If you’re interested, or want to help out, drop me a comment or e-mail me at mark at compound thinking.com