Feeds:
Posts
Comments

Planning ahead

As life gets more complicated, planning gets more important.

I’ve never been a good planner. I don’t like planning, so I naturally resist it. But as work gets more challenging and my 9-year-old son Gus gets more active, planning is simply unavoidable.

There’s the school of thought that if you want to learn to swim, you jump in the water. That applies to me here. Since my life isn’t going to get simpler, all I can do is make my best effort to plan ahead a bit, because if I don’t, everything falls apart. I’m confronted with the effects of any failures to plan daily. I’m under water, and my arms are flailing.

And wouldn’t you know it – it’s starting to have an effect. I’m beginning to think a couple of moves ahead. I’m beginning to fix process failures as I notice them. I’m recognizing better what’s important to me and what isn’t.

I still make plenty of mistakes, but it’s cool to see myself starting to suck less at something important.

What about you – is there anything you’ve struggled with a long time that you’re starting to get better at? Did you get there by diving in or some other way? Did you get there by … planning ahead?

Oops!

When you break a streak, the best thing to do is start another one …

Deadlines

The nice thing about deadlines is that they force you to ship. Your article, your app, your art will never be perfect, so of course you can always make it better tomorrow. Deadlines force you to give that last burst of effort to make something at least “good enough.”

I’m OK at externally imposed deadlines, but I’m not so good at creating deadlines for myself. That’s what a regular project sprint cycle is – it’s an internally imposed deadline to ship every week or two.

Internal deadlines are all about creating a regular rhythm. It’s less about getting something done at a specific time and more about inducing that burst of creative effort in a predictable, reliable way.

Gotta go – I have an article due …

What money can buy

A while back, I mentioned Jacob Needleman’s Money and the Meaning of Life. One of the points Needleman makes is that for almost any problem in life there is a very specific amount of money that will solve it.

If you are building a software company and have figured out how to scale, there is usually a specific amount of money that will help you execute your plan. This is what VC’s provide.

If you have an incredible idea but no time to build it, a specific amount of money will allow you to quit your job to focus on your startup. An angel investor might provide this.

If you are sick of hosting your own blog, there is a specific amount of money that will help you remove that problem from your life.

If you want your son to be a racecar driver when he grows up, there is a specific amount of money you can expect to invest in that goal.

If you want to impress your sweetie on Valentine’s Day, you can think of a specific budget to lavish her with gifts, flowers, and a dinner at a fancy restaurant.

BUT … there are some problems that can’t be solved entirely with money – it’s important to know the difference.

Happy Valentine’s Day – spend some time today appreciating the things that money can’t buy.

Learning git

I’m working on some startup-oriented content with teammates around the country. It’s mostly text, not code, but there are a healthy amount of code snippets mixed in.

For any other project like this I’ve worked on at Microsoft, we have collaborated using SharePoint or (gasp!) email. But the guys leading this project are very comfortable with git, and since this content is aimed at developers who would likely use git, it makes sense to collaborate on github.

Instead of working directly in PowerPoint, we’re building the content primarily in readme.md files, which are text files with simple markup that make them look good on github.

Even though I was familiar with git, I had never actually used it on a real project (I had never gone past hello world). It took a couple of hours, but I’m starting to get it – I’m beginning to understand why so many developers (especially startup developers) are so fond of it. Once you get going, it’s pretty darn easy and efficient to collaborate with people around the world.

It’s going to be interesting to see if we meet the tone of our intended audience with this content, and I’m curious to see how much the tools we use affect that. Regardless, it’s always fun to learn and actually use a new tool.

Envision then do

You have to know exactly how you want the music to sound in your head, hear exactly how it actually sounds in the room, then bring the two as close together as possible.

That’s paraphrasing a knighted British conductor – I read the quote at school more than twenty years ago and since then haven’t been able to find who actually said it. If you know, please tell me.

When you get pretty good at something, you can start doing it without thinking. Perhaps you can get up in front of people without having to prepare or write without having anything to say. Maybe you can start hacking away on a software project before you really know what you want it to do.

In some ways that’s good. If you want to improve your craft, you have to do it. Sometimes it’s best just to dive in and see what happens.

Sometimes it’s not so good. You can spend an afternoon or a week or a year building something that nobody wants.

So it makes sense to balance doing with envisioning. Before you sit down to practice your craft, ask yourself the simple question, “What am I trying to accomplish?” Picture the outcome in your head. What does it look like? How do I get there?

Got it in your mind? Good. Now sit down and make it happen …

BUT – as that conductor pointed out, the “music” you envision in your head never sounds exactly the same as the music in the room.

On the way to building the software you envisioned, you found shortcuts or obstacles or serendipitous detours. Sometimes you have to plow past these to realize your vision – but sometimes you have to alter your vision to take advantage of what your software and your customers tell you. Building software is an ongoing negotiation between what’s desirable and what’s possible.

Whether you’re creating software, making music, writing a blog, or sculpting, the goal is to maintain a lofty vision while bringing your vision and your reality as close together as possible.

There are some things in life where it’s important to do a great job. For example, the difference between being an OK musician and a great musician is an enormous amount of work … but it’s worth it, both to the musician and the audience.

Surprisingly, there are things where it’s NOT important to do a great job – it’s only important to do it. And trying to do a great job where you shouldn’t can actually prevent you from doing a great job where you should.

I thought about this yesterday while shoveling snow. The difference between shoveling and not shoveling is huge – you can’t get your car out of the driveway if you don’t clear a path. But the difference between shoveling and shoveling perfectly is insignificant. Does it really matter if there are little strips of snow between shovel strokes? Does it really matter if the sidewalk has perfectly square edges? No. It’s snow – it’s going to melt eventually anyway. Just push the snow around to clear a path for your car and clear a path for pedestrians as quickly as possible – time saved doing a mediocre job shoveling is time that can be spent doing something more worthwhile.

So what about building a startup – is there anything like shoveling snow in a startup, something that’s more important to DO than to DO WELL?

One thing that comes to mind is managing email. Fred Wilson spoke about email the other day – he gives it an hour in the morning, an hour at night, and maybe an hour in the middle. He does what he can during that time, but he’s not willing to invest more in the overall process. For him, “doing email” seems to be like my shoveling the driveway – just get as much of it done as possible, but it can never be perfect.

I’ve never emailed Fred Wilson, but I have corresponded with Brad Feld and Seth Godin, two other famous startup people who receive a shocking amount of email yet respond personally to any reasonable request, usually within 24 hours (in fact usually within 5 minutes). How do they do it?

For starters, their emails (at least to me) are very short. They trust that I will be thrilled to get a reply from them, so they don’t bother setting me up with useless niceties like “It’s very nice to meet you, Patrick …” It’s more likely to be a reply like “thanks” or “yes” or “not at this time.” Seth once gave me very quick feedback that I wrote something “generous,” which meant a lot to me, coming from him. I once asked Brad for an interview, and he simply replied back, including his assistant, saying “+1 [assistant’s name] please schedule.”

I want to be the kind of person who replies back to every email I receive and doesn’t leave loose ends. I am not that person yet – not even close. To get there, I’m pretty sure I need to learn what Brad and Seth (and probably Fred) were forced to learn a long time ago – it’s better to get email done than to get it done perfectly. If I don’t have an answer for a request, I’ve got to learn to reply back with something like “I have forwarded your message to a colleague, and I will let you know when I hear back” or even “I don’t know, but I will let you know if I find out.” That’s better than what I do now, which is stroke my chin, put it in a “tickler” folder that gets buried worse than my inbox, and never get back to it.

I want to answer every email with a wonderful nugget of helpfulness, but I simply can’t. Too often, that reality ends up burying me, which gets me down. And that feeling of defeat impacts my ability to do the rest of my job well.

The fancy word for this is satisficing: “a decision-making strategy that attempts to meet criteria for adequacy, rather than to identify an optimal solution.” Every email requires a decision. If you attempt to maximize every one of those decisions, you will never “finish” your email. That leaves you with a stack of unmade decisions which is worse than a stack of adequate – but completed – decisions.

Email is never going away. I just need to learn how to do each one a little bit more poorly – it’s better than not doing it at all. It’s counterintuitive, but the end result is actually “doing email” better.