Drive Data Work with Business Savvy

Most technologists start thinking about a problem from the perspective of the tools we use, at least I do. "I can make recommendations from collaborative filtering, we should build one." "I can build probabilistic graphical models, we need those." Sound familiar?

Recommending better content might be a great idea, but we really do need to put our solutions in the larger business context and get collaboration from other people. Even if our job title gives us complete freedom to act, we're still wise to involve other people in our work.

When things go wrong they can go really wrong.

Consider one time when I didn't take my own advice. I had been working with Bayesian networks and wanted to understand the onboarding process for a SaaS product. So I modeled the system from the data I had, got the useful insight, and showed a few people. No harm, no foul, right? From some of my coworker's perspective, it was like the math club submitting a batting order to the baseball coach. They were doing fine without me and didn't understand what I was doing.

This mini project was a wasted opportunity.

If I had talked to people before thrusting my work at them, they would have been a lot more interested in what I had to say. I could have also used their perspective to think about the problem differently. I could have asked them about the problems they were thinking about. Even though I found the insight I was after, I didn't really change anything, not like I could have.

That's the good kind of failure, where you're missing a few opportunities, it's a very fixable problem.

The other kind of failure is when it all goes wrong, people start taking sides, pretty soon you're thinking of agendas and politics, who controls which budgets and whether this project is worth losing my job over. I hope you never have those kinds of challenges, but even those can be handled better if you start with the people around a project.

So what does it look like when things go right?

I once worked with an executive who couldn't stop pitching. He was obsessed with his pitch, pitching the next step, trying out a few versions sometimes. Talking with him it felt like he was a human vacuum, sucking up everything I said, my body language, seeing if he could get me nodding and contributing back with excitement. Leaders get everything moving in the same direction and sometimes the best way to do that is to get in front of someone and start pitching.

Yeah, but I work with technology, not people.

I know where you're coming from. I can be the most introverted person on the team. The steps from my desk to the restroom can be painful, dreading that I might be pulled into a conversation, muttering to myself so nobody will interrupt me. Yeah, I can be that awful sometimes. (I can also be the guy pulling everyone else out of their introversion, go figure.) . Maybe you've got more social skills than I do, or fewer, it doesn't matter, you've got to learn to make a business case for the people around you.

Making the case, pitching it, is serving people, it's getting them involved, getting their ideas, getting their commitment. It's not quite a free for all where all ideas are good ideas. There are definitely bad ideas. Your job is to get the conversation going, decide what's valuable, prioritize the work, then pitch the top idea until your project is moving forward.

So how do I learn to pitch my ideas?

Learning to pitch can be rough for people that have focused on learning technology, but you start with the technology as your prize, something that excites you, challenges you to learn and stretch your skills. Say you want to build an A/B test with a Bayesian model, how do you pitch that?

A pitch is three things: the state of things before you go to work, the fix you're applying, and the results you're expecting to deliver, it's the Before, the Fix, and the After. It's the past, present, and future. I'm repeating myself here because it's those three things, always those three, sometimes in a different order for effect, but it is those three things. Got it? Before you read this paragraph you thought a pitch was something salespeople did, but then you got this pattern drilled into your head, and now you realize that this is not only something you have to do every time you want to work on something cool, but also it persuades people to let you do the coolest things, making you more effective in your job and providing incredible job satisfaction. You're welcome.

Pitching doesn't come naturally, not for me, but with practice I get pretty comfortable working on my pitches. Remember, I'm learning to use some business savvy in my work, learning to put things in context, getting people to come along.

If you haven't noticed before, that's the whole premise for every Pirates of the Caribbean movie, where Captain Jack Sparrow does seriously crazy but cool things, and all these people eventually follow him to the ends of the earth. The pirates life is definitely all about persuasion, sometimes with the aid of a cutlas or musket, but also with wagers, deceit, accords, promise of treasure, and the call of the wide open sea--all forms of a pirate's pitch.

And the good news for people learning to write a pitch is you can start with the least-persuasive dreck, the abstract snippets of thought that are enticing to you but have no real connection to others' lives, not yet. Start with an idea, a technology, or something you think will be exciting to deliver and include some of the features that would make the project whole. This is the "what" of the pitch, with a little of the "how" mixed at the end. Now work on the why. What is the current mess people are finding painful? How is the fix delivered? What do people get when you're done? Organize this as, "Before..., When..., Then....." Then think about why someone cares about the outcome and get deeper with more and more why questions answered, "Before..., When..., Then..., That..., That..., That...."

At the end of this mental organization, you should be pretty clear why someone should care. Now turn this information into something you might say to someone. Write it down as if you were talking with them. Later you'll pitch this out loud to yourself, your mirror, your dog, something. Or start sharing this with people and see how you're doing. Get into conversations by pitching them ways you can improve their lives.

Some Practice

Here's an example:

Idea: A/B testing and incremental improvement
Features: Bayesian models and data visualization
Before/Fix/Result:
  Before we built new content or features, responding to problems
  When we proactively change and measure improvements
  Then we gain confidence that we are refining our offer
  That we respond explicitly to customer behavior
  That we can provably add value
  That we can hold on to and enroll the right customers
  That our revenues are more steady and grow more effectively
Pitches:
  Owning a software product can demand all we have and never be enough,
  like a hamster in their exercise wheel, worn out but not really
  getting anywhere. When we start to measure our work, actually
  prove that our efforts are working, we start to get out of this
  cycle, gain confidence that we're making progress in the important
  things, not just responding to crises, and stabilize our
  relationships with our customers.

  We're drowning in customer churn. Let me get some measures around
  our product performance and turn our customer relationships around.

Notice how that worked out. I start with what I care about, figure out why someone else should care, and start to write down some pitches down. If this is going to be a pitch to a stranger where my words and my customer's thoughts have got to bridge a gap between us, then I'm going to write 5-10 pitches down, refining what I understand about the problem, the fix, and the result. I'm going to use a lot of empathy in my words, explaining full thoughts in ways that someone can follow where I'm leading them, understanding that I want to bring them forward as quickly as possible, but no quicker.

It takes practice. Your first Hello World program wasn't anything that incredibly remarkable, but you celebrated the effort and kept learning until you figured out how to deliver whole systems. Learning to pitch and use business context in your conversations isn't very different.

Learning to pitch is a sane response to frustration.

Until I started to learn how to pitch, I was often quite frustrated. The initial idea usually felt self-evident to me. "Why can't they see it already? I want to get started." Notice how my opening thought, "A/B testing and incremental improvement", isn't even a fix yet, rather it's an abstract idea. If my opening idea were code, it wouldn't even be a typespec or function signature, let alone a full function or a larger block of code. Just as code has to be organized, well executed, and complete, so too a pitch has to take shape, drawing people through a process that see themselves wanting to participate. If they're going to care, I had better figure out why that could possibly be and write it down.

A pitch is learning to think in reverse, talking about the other person's perspective first.

When we get involved in something, we first care about why we should get involved, then maybe how we would get involved. Only some pitches start to explain what getting involved will look like, but that's OK. But we start our thinking THE OTHER WAY AROUND. Without training, we start with the what, work through the how then finally start to talk about the why. I wanted to do some A/B testing, then I thought about the tools, then it occurred to me that most people don't wake up thinking hat A/B testing is the thing they're missing in their lives.

So start with things the way you see them, work until you grasp why your collaborators will want to get involved, then reverse it and start practicing a pitch that way around. As long as someone knows why they want to get involved, and they're persuaded, you can work with through the details of how you will get things done and what it is they'll actually end up owning.

Why do I write this down?

I did write these pitches down, but notice that they're not really complete. They could get a whole lot better. Pitching is a practice. You're not writing a novel, you're training yourself to use language in a way that reveals your thinking, reveals the thinking you need to be persuasive, reveals whether you grasp why someone would want to get involved.

Pulling this kind of insight into a conversation takes a lot of practice. By spending a little time with it before you pitch, you're not going to confuse what you want to build with what others need to hear. Once words exist on a page somewhere you can start to notice what's missing, where you are leaving people behind. You often can't see it until it's actually there somewhere. (Writing isn't only good for pitching, writing is good for thinking. Write more and think more clearly.)

This is the approach to pitching: writing down what I want to do, how I would do it, the before/fix/result pattern, and finally a pitch that actually talks to someone. This is the approach I use to setup Get Data Chops. Those scribbles to the left? That's where I wrote down the pattern, These tools work for engaging with people however we find them. So far, this has worked out pretty well for everyone involved.

This pitch is the beginning, what comes next?

After you get someone's attention, you want to get their input. You'll make a lot of the decisions, but you're looking for feedback. You want collaborators, after all, not indulgent patrons. That means their best ideas mix with yours and you actually approach a data project differently than you thought you would.

The traditional idea of a pitch is really outdated, reminding us of the fast-talking salesperson that steamrolls over all our objections and strong arms us into deals we never really feel good about. Don't do that. Use your pitches to start conversations, to initiate collaboration. Let me show you.

"Our customers' experience is all over the place and we're spending a lot of time trying to slow the customer churn down. Let me put some A/B tests together so that we can start to stabilize our customers' experience and hold on to our better customers."

"Hmm, that's interesting, what does A/B testing mean?"

"Oh, that's a fancy way of saying we'll adjust things quickly, measure our progress, and keep what works."

"Is this going to take a lot of time?"

"Setting up the tooling takes about an afternoon and maintaining things take about an hour a week, give or take. I'd want to sit down with you and walk you through the results the first time we do this, but then keep this information in front of you during our regular checkups after that."

"Sounds interesting, is it worth all the work?"

"I've been able to eek out steady improvements with this kind of work before and a lot of the most successful startups are really good at it. Given some weeks or months, this could start to feel like a whole new company both for us and for our customers."

Notice what's going on here. Through someone's hesitancy, I'm hearing that they're feeling overstretched, over committed. They're not actually too worried about things like statistical significance, which technologies I might use, whether I'll have a hard time getting these things setup, whether I'm focusing more on content or product features, or many other things.

If they've done this before, they're going to ask much more pointed questions, comparing my proposal against their past experiences. In that case the conversation is going to revolve around tradeoffs and constraints. You're going to get into a collaboration conversation much earlier than you'd hoped. This is good news, gently demonstrate that you're competent and able to take on the project without too many difficulties.

Also notice that I'm being imprecise but accurate in my answers. I'm not overpromising. I know that if I can get 5-6 rounds of A/B testing over 4-6 weeks (by spreading it around different parts of the product), I can start to steady some of the problems I imagine we're having with the customer (this was after all an imagined pitch). I'm going to have to be proactive to ensure I've made measurable improvement in a shorter timeline than ideally I'd like to have.

This conversation is fairly accurate. I've had it in several previous positions and it's worked out fairly well. Still, I don't go into a new data project without getting this kind of feedback from my pitching first.

What about me?

Another common concern I hear when I'm pitching people is that they're worried about their reputation, they don't want other people taking over their jobs. This is where I reassure them, "I'll deliver this to you, I've got your back." This isn't playing favorites, this is creating clarity who my customers are. Sometimes they're colleagues or someone that would appear lower than me in a traditional organization chart, while sometimes it's the executives or board members that are my customers. Whoever I'm serving, if I make sure the service is for them directly.

This reminds me of Tom Peters' Professional Service Firm 50 from 1999. It's a short book about delivering work really well by building these kinds of agreements around our deliveries. If promoting your commitment to your organization is causing trouble, pick that book up.

What if I don't have copious amounts of free time that I can fit this on top of everything else I do for the company?

You're pitching people because you want something from them. Sometimes you want permission to pull colleagues off their current projects, hire new people, spin up more cloud services, or otherwise spend the company's resources. In my experience, your ask should grow with your reputation and the benefits you're creating for the company. If you don't have the word "data" in your job title, you're going to start smaller. In that case, pitch something you can do with a few extra hours, later you'll take on bigger projects, replacing some of your regular responsibilities, and involving more of the company's resources.

You should work on creating balance in your life, but you should also work to participate in projects that get you excited and fulfill a growing curiosity. This isn't as contradictory as it sounds, push forward with a measured gait, letting your ask grow with your ability to deliver. I've found that the more data work I do, at least the kind of data work that challenges me, the more curious I grow. It's a nice path.

What if my company has formalities around starting projects?

Most larger companies do. That's OK, use those and respect the policies, but don't skip on the interpersonal support you're going to want to deliver a good data project.

What if the stakes are high, this is an important data project that will take more than workaday commitment?

If this is more than a trivial project, read and practice Getting to Yes. Fisher and Ury will show you how to get from your best ideas to a much better outcome through negotiation. This is the only book on negotiation you need.

You'll enhance your pitch with a collection of interests: yours, theirs, the tradable ones, and the ones that are still difficult points. You'll frame things differently, prepare differently, and work towards mutually beneficial outcomes differently. You'll learn how to create a completely different kind of conversation around these projects.

You'll get into more and more of these as your reputation and abilities grow.

And once the work is done?

This is when you prove your value. Reduce all the complexity, features, trouble, and turmoil down to 4 slides: a single metric that represents the greatest win you achieved, a visualization showing your work in action, a brief summary of what took place, and a visualization projecting the ongoing impact of your work. Deliver this only to your direct internal customer. You can afford to be generous here, letting others take some credit too. You've got hundreds more of these types of wins that you'll deliver all over your organization so practice benevolence.

The bigger picture is you're building a data-driven organization, usually from a role somewhere in the middle of the organization. Remember that the better you are at collaboration, the more prepared you are for Lead Data Scientist, CTO, or similar roles.

And by the way, you can deliver this as an email, a presentation, a PDF, however you choose. Be sure to make all your wins tangible and clear, and make sure you follow up each one with another pitch for more projects.

Where do I go from here?

If this is exciting you, there are probably things you're discovering to improve collaboration around your projects. Effective collaboration is my definition of business savvy, creating advantages around your business practices. My recommendation is to practice these until you feel a bit sheepish thinking of past projects, that's how you know you're developing more effective leadership skills.

P.S. I love you Divvy

I wrote this article because harmony at work is harnessed power, a power that fuels the drive to pitch, negotiate, collaborate, and apply business savvy to all my projects. As I've admitted here, I can get incredibly introverted when my head is full of thoughts, reducing my effectiveness working with others. When I write I clear that out, prepare the better part of me for service.

I have a chance to affect many lives with my best work at Divvy, creating insight and an impetus for action. Like all great opportunities, this one asks the best of me, challenging me to create intricate things from their basic elements. This can't happen unless I'm fully engaged with the people around me, the customers and coworkers.

I mention projects I've done, challenges I've faced, and very little about Divvy. It's not a disloyalty that causes that, but its opposite.

And Get Data Chops? If I know it I can teach it, and teach it simply. I'm also passionate about Get Data Chops. Getting out of my shell, sharing what I know, experiencing a more-whole version of me. Get Data Chops is the spring training to the Divvy regular season.