Data-Driven vs the Dashboard 

It is common for technical product companies to call themselves “data-driven” these days. The idea is that metrics are used to drive decisions. Sounds easy enough, and compatible with a technology landscape that is enamored with data science, etc. 

But something didn’t always feel right to me. Strange, right? If you follow this blog or know me, you probably know that I have been steering my career in a data-centric direction. I coordinate the Cleveland R User Group, and have spent most of my personal technical time with a variety of tools to do analysis and modeling. 

Maybe it’s a deeper understanding of statistics and related skills that lies at the center of my problem. Many people view these fields as black and white. “Show me the numbers”, people say. As if they are stone tablets chisled with the truth. Creating summaries, graphs, models, etc. requires understanding the domain, and subtle interactions. The tools are getting better, but we still need people to drive the tools and frame the questions right. To correct mistakes of causality. 

In explaining this, the example that hits home for me is a dashboard for a product. Have you ever tried building a B2B software product without one? Good luck when sitting in front of an executive board and you can’t show them a dashboard they can monitor. Never mind that for all of your existing customers that dashboard is the least used page in your analytics. It’s key to the sale. But if you ignore that, and just look at user data to drive all of your decisions you’ll miss that. 

So maybe there’s nothing wrong with being data-driven, it’s just that you have to be willing to mix in some decisions based on strategy and experience. And you have to ask your customers the right questions in the first place.

To be a great firm, a company should find a sophisticated middle ground. You can’t rely on a visionary employee to drive all decisions. Many founders think they are Steve Jobs and can divine all customer needs. Steve Jobs is an outlier among outliers. The answer, however, is not to turn in your brain because you started gathering data. The metrics are a tool, and you can still choose how to use your tools. A feature (or page) may still be legally required. Or it may be used rarely, but of tremendous value when it is. Data provides clarity for the many mundance decisions. It should still be up to a person to set the strategy. Otherwise, you’ll be selling a product without a dashboard. Heaven forbid…

Ownership: Artist or Engineer?

There are varying ways that a client / service relationship can work, and this view can be the cause of harmony or discord in projects. It’s something I’ve understood for a while, but had trouble explaining at times. What follows is an attempt to explain my view of something that knowledge workers need to understand to have a successful and fulfilling career.

The Artist

When an artist does work, we typically think of them as having complete control of the work. This is certainly true in the case where the eventual owner is not yet determined. Meaning an artist creates, and then sells directly or via a gallery to the public. Even commissioned artwork has only varying levels of control. A commissioned portrait certainly falls into the realm of work that would come with constraints. After everyone involved is dead and gone, people tend to remember the artist, not the owner.

The Engineer

When work is not sponsored, but contracted, it begins to fall into a completely different classification. Though you may refer to it as “artwork”, a visual painting done for advertising is really more “creative” work for hire. Certainly work that is more functional (like a bridge) comes with rigid requirements. This is the attitude of the engineer. That work is asked to meet certain goals, and ultimately subject to the approval of the buyer. While the engineer is an expert who expects to provide guidance, but does so at the behest of the client. In terms of credit, this world is muddled. Sometimes it is the architect, other times it is the owner or visionary that is remembered.

What does any of this have to do with consulting, software development, functional work, or any other type of service industry? Don’t get caught up in the work medium (paint, steel, code), or left brain / right brain aspect of the work, but just consider the metaphor in terms of relationship to the client and ownership of responsibility. In my world (consulting in the areas of software development, creative, marketing, etc) this distinction makes a big difference. All of these types of work have a right-brained aspect to them. People think of software development as a very regimented thing, but there is a lot of freedom to work in your own styles and patterns. Languages are fairly abstract these days, and they are high level enough to provide nearly infinite ways to solve complex problems. Certainly I don’t need to discuss how easy it is for a graphic designer to relate to an abstract artist.

Here’s where the risk is of confusing yourself with having the control an artist does, when you do not. The consultant works in a world where the client owns the final product. And the project would never even exist but for the idea and financial commitment of the client. Deadlines, requirements and other constraints are all part of the context. “Ownership” of the direction is a privilege that goes to the person that takes the risk. While an artist that is producing works for sale is bearing the risk that the piece will not sell, the bridge builder is not. It was sold before the project started. Sure, many contracts include shared risk clauses, but for all intents and purposes, the risk is on the client.

It is arrogant and unproductive for a paid consultant to believe they have the final say in work. They have the right to turn down work. And some clients may choose to give control over to the consultant, but that is their choice, not a right of the consultant.

When a consultant is doing work for hire and thinks they have the privilege that come with the artist mentality, it easy to develop a disdain for the client. Whereas in the engineering mindset, it is understood that one can recommend to the client, but ultimately the idea must sell itself. There is no expectation that the consultant wins because they are the subject matter expert. They are expected to be able to convey their idea and it’s merits in plain English and at a level understood by someone outside the field. In short, they must sell the idea.

Am I saying that workers should not have principals? Not at all. Take the story of Howard Roark, the principal’ed architect of Ayn Rand’s The Fountainhead. Roark suffered while turning down business as he would only work on buildings where his style of architecture was called for and he had the free hand to build modern and innovative buildings. He turned down others with work that would not satisfy him, but he did so respectfully. In this fictional work Roark has many enemies, but not the clients he turns down. A read sympathizing with Roark may agree with those clients, but it’s hard to see them as malicious.

The problem is that so many give away the right to have those principles for the sake of expediency without realizing they gave up that control. So they still expect the control. As an example, coming to work for a consulting company, you give up that right. Why? I’ve already made the point that the client has control, so you can only control work by selecting projects that meet your criteria, or working with clients who are ceding control. But as an employee of the company, you are giving up the client selection privilege in order to minimize your risk and investment. The consulting company provides you with a salary, book of work, etc, in return for your work. You do not get to control what work the company takes or not. It is your choice to leave if their client base does not suit you.

Too easily do I see people in the business blame owners and clients for work they do not like. But owners and clients anted up. They paid for the right to call the shots. If you want them to call the shots differently, it is your obligation to sell them on those ideas. Not your right to complain if the idea is not sold.

So what should someone who believes in the artist mentality do? There are people that believe so strongly in the control of their output. Folks like this tend to idolize people they view as uncompromising, like a Steve Jobs. (It’s worth noting that there are a lot of signs that he compromised more than the public perceived).

There are some simple solutions. Being an independent consultant means that you can turn down work that does not fit preferred principles. Owning / building your own consulting firm allows you the control of selecting your projects and clients. The third option is to return to the artists root of non-commissioned work. In other words, start a product company. While your clients have say in the form of sales, you are free to put whatever product you see fit on the market that can be held to only your standards. For all the knowledge workers that idolize Steve Jobs and he uncompromising reputation, it is worth remembering that he started and returned to a product company.

Media is a great analogy. Being an independent musician, filmmaker, or game developer is hard. You have to market for yourself, sell each product, secure distribution, etc. But for that price, you have control of the product. Signing with a publisher makes those tasks easier, but you have to be aware of the conditions you agreed to with the publisher. Like any contract or relationship, you should consider what those terms will mean in good times and in bad.

This is not to say that the rest of us don’t have some control and determination of our own destiny. It’s just that you have to remember you only have one lever to pull, leaving the company. You can negotiate terms based on a company or client’s desire to have you be a part of the team. But to get emotional about it, or think you have a right to control without taking the primary risk is folly.

Lessons of a Failed Startup(s)

A couple of months ago, I finished reading Eric Ries’ The Lean Startup. It got me to thinking about startups and small projects I’ve been a part of in the past.

In particular, I think of a social site for readers that I was apart of that failed. I think of the the end, where I was trying to make the case to launch something and let users drive the feature list. What I find really frustrating is that I did such a poor job of communicating that at the time. Reading the book, I hear a much better way of emphasizing the point of customer feedback loops. The minimum viable product with hypothesis and user testing driving the next steps; it has so much value. Additionally, that movement has a number of successful followers to their name, so they have credibility with their message. Timing and other market factors may have doomed us anyway, but I can’t help but thinking of what could have been different armed with some of that information at the time.

The other part of the book that really resonates with me is how hard successful startups are. People are so afraid of there idea being stolen. In the book, Eric Ries suggests that you try to have someone steal your idea (it’s hard to do). He’s right. If someone actually wants to steal your idea, at least it validates that other people think it’s a good idea.

I get approached by people with startup ideas a lot, looking for programmers who want to work for equity. For young developers with the time, I think they should get involved, it’s a great way to learn the realities of business and to get some extra experience. But beware of how much of a longshot it is to get the product successfully to market. It has to be a good idea, successfully built, successfully marketed, and fill a timely need. Miss any of those categories, and you probably won’t do much.

I’m not suggesting people avoid startups. They are a great learning experience and some of them work out. But go in with your eyes open to the amount of work you have in front of you. And be discriminatory about where you choose to invest your time. Are the others involved willing to put in the same effort you are? Will this new organization be capable of all of the things needed to be done to launch a product?

My advice for evaluating an idea: run a set of books for the project (meaning keep accounting). If you’re working for equity, keep track of time anyway and what you could have been paid at your regular rate to do that work. How long will it take for the project to pay that back? That question opens a lot of eyes. Say what you will about money as a measuring tool, but it’s the standard for all projects and companies. It’s relatively objective, and very compatible with math. The same can’t be said of a subjective goal like “let’s take over the XYZ market.” Presumably, you have your day job because you make someone more money than you cost them. If you can’t say the same of your startup project within the first year, then your project doesn’t even have the ROI of your “boring old day job” (you may love your job, my point here is that people thing of startups as high risk / high ROI and that may not be the case). Every time you sit down to put more into the project, you’re saying that you will get that back in cash on the other end. Is that true, or are you kidding yourself?

There can be other reasons to do a startup. I’ll use a personal recent example. I built VicinityBuzz, and iOS application around Social geo-search (also coming soon to Android and WP7). It’s been slow out of the gate so far, but I’m hopeful that some of the new features coming in the next update and some marketing ideas I have will help. Regardless, I’m certainly a long way from paying myself back for the time I put in. But I have been working in cutting edge technologies more and mobile is a real focus. I knew even if the project never paid for itself that it was valuable time learning and to put the project into my portfolio of work. I went in with those realistic expectations, but try really hard to exceed them.

If there is intended to be a single message of this post, it is to apply measurable goals to your projects, and evaluate and pivot your direction as often as reasonbale. If I had to boil down the message of the book to one sentence, that would be it.