Wednesday, February 29, 2012

Startups and Vendors

I work with a lot of startups. I work for a lot of startups. Yup - two way street! Vendor management is frequently a large part of my job. Sometimes I'm the vendor, and sometimes I'm the client.

Usually, negotiating between a vendor and a client follows certain steps:

  1. Find each other. Sometimes the vendor finds the client, sometimes it's the other way around. Either way, there's a need and a provider, and you both kind of like the idea of working together.
  2. Identify a way to work together. You settle on a basic project with some goals and a simple structure. It can be anything from the vendor providing a service (e.g., hosting) to custom development work, to training, to co-working on something with the vendor on behalf of a customer.
  3. Pricing, Timing and Scope. This is where things get interesting. After all, the client wants things as cheaply as possible, and the vendor wants to make as much money as possible. In theory, the landing place should satisfy everyone.
So you've got the basic idea of what ya'll want to do, and you're starting to talk about money and timing. You've already established that both parties WANT to work together. This is just the stuff about making it happen. Here are some things to remember:
  • "Well, we're self funded." That's nice. And that's important to the party doing the paying, but it's not relevant to the conversation at hand. Leave it outside this conversation; it's just opening the way to emotional involvement and driving you farther from a deal. Where the money comes from doesn't matter. You the client need to talk what this project is worth to you in dollar terms.
  • Payment isn't always dollars. Maybe the dollars are simply not there. Consider payment in other services or other means. Don't have cash? Maybe the vendor will take equity. Are you a marketing firm looking for dev services? Consider paying in branding help. It won't always work, but it can broaden the creativity.
  • Adjust all parameters. There is a slider for money - how much this will cost. There are other sliders, too: time and deliverables are at least two of them. If you can't do the whole thing now, can you do part of it? Can you do it more slowly and stretch out the payments?

In the end, we're all looking to get the best deal possible while accomplishing some great thing. Start with that common ground, and be creative about the rest. There's usually a way to work together. All you have to do is find it.

Monday, February 27, 2012

Making a Good Pitch

I spent this weekend mentoring at StartupWeekend Boston. As usual, I had a lot of fun getting out of the day job and spending time with people working on new ideas and solving problems.

One of the more enlightening things was working with teams on pitch practice and comparing them to final pitches. If nothing else, pitchfests like this are a great opportunity to look at what makes a good pitch presentation.... and what doesn't. Here's what I noticed this weekend:

  • Live demos make your idea look a whole lot more real.
  • Slide titles are overrated - try ditching them. If you have to use a title, your content is probably unclear.
  • No notes! Please no notes! Do you really want to look like you don't know your own idea?
  • If you look completely panicked while answering a question, we'll know you're making it up.
  • Your slides should match your feel. If you're pitching a trendy consumer app, don't use a corporate-looking template.
  • "We didn't get a chance to show".... because you didn't budget your time correctly. When you know how long you'll have, it's up to you to make sure you fit the important parts in.
  • Don't start with a question unless you're darn sure you'll get the answer you want. Bad questions: anything that can be answered with "No".
  • Words words words. If you have a lot of words on a slide, there's probably an issue. A 5 minute pitch isn't the place to throw up a lot of words. An hour long pitch and we'll talk, but in 5 minutes, slide reading is not really effective.
  • Watch your time. In 5 minutes, you're not going to go through everything. Your goal should be to get people excited and show them you know what you're talking about. Translation: demo, problem statement, solution, and basic market validation. Skip: projections, bogus market sizing.
  • Beautiful helps. Great design - product and slides - goes a long way toward making your idea seem better.

Wednesday, February 22, 2012

In Praise of Self-Funding

Lately it seems my life is consumed with pitching to investors. I'm not pitching personally, but I've been talking to a lot of people who are, and I've worked on a few pitch decks for clients in the last month or so. It's been interesting.

It's also made me think. Why pitch? Why take investment at all?

What's good about taking investments:

  • Yay money!
  • When we have money we can spend money strategically, whether that's on marketing, development, infrastructure, or whatever.
  • Yay advisors! These are now invested advisors, so they extra want you to succeed. After all, it's their money and they'd like it back eventually (and some more, too, please).
  • If you have competitors (hint: you do), and they can outspend you, then taking investments gives you a better chance of keeping up.

What's bad about taking investments:

  • It's a huge distraction from that thing you're actually supposed to be building. Yeah, your company. That thing.
  • You have to give up a chunk of your company. Sometimes it's a lot of the company, which limits your ability to direct and control your company going forward. Oh, and you only have 100% of the company total, so you can't get too many investments (or investors) without getting to 0%.
  • You get advisors, yes, but you get biased advisors. Someone with a stake isn't going to be as objective as a true third-party.
  • Boo money! Laugh away, but it's true. If you don't have much money, you really think about every bit you spend, and you're more likely to spend money - and time, and focus - on things that are strategically the wrong thing to do. Sometimes being tight with money makes you really consider the strategic implications of what you're doing with what little you have.

Don't get me wrong: sometimes taking an investment is the right thing to do. Sometimes you need it to grow before your competitor does. Sometimes you need it because what you're creating is capital intensive. Sometimes you need the advisors and this is the only way to get them.

But most of the time, at last consider self-funding first. Taking in an investment is a choice, not a stop along the way.

Monday, February 20, 2012

Contributing

When you're an engineer starting out or looking to build your reputation, one of the first pieces of advice you'll here is, "go open source!". Creating or contributing to an open source project is seen as a great way to get your name out there. A few hiring managers are even going so far as to ask for your Github name so they can look at the work you've done there.

And this is great. Granted, it's perfectly good to contribute to open source projects that aren't hosted on Github, but the underlying sentiment is the same. Many of us use open source projects, so coding (or testing or documenting or evangelizing) on one is a good way to "pay" for that software.

Let me make a plea for contributing to open source projects rather than starting your own.

There are thousands and thousands of open source projects out there solving all kinds of problems. If the problem you're solving is truly not addressed by any of them, then please go ahead and start your own. If, however, the problem is mostly addressed or addressed but could be nicer by something else, then please go contribute to that one.

For example, there are 476 captcha repos on Github right now. I can almost guarantee you that your new captcha repo would get lost in the shuffle. Instead, go extend the functionality of one of the 476 repos that are already there. You'll get a bigger audience for your code, and you'll have made the overall captcha world better, not just larger.

Please, go do something fun with open source. It'll be fun for your and great for the project. Just try contributing, and don't make your own unless you really need to.

Friday, February 17, 2012

Design (a Little) Ahead

One of the fun topics developers and architects like to throw around is "emergent design". It's shown as a counterpoint to "big up front design". The fundamental idea is sound: don't design for the next two years since it's likely to change. Instead, design for your current needs. For many of us, that translates to designing for the current sprint or iteration.

But then the next sprint starts. And someone groans, "Oh, shoot! We're going to have to rework that!" Reworking and refactoring is fine. When you're doing it every sprint, though, it starts to be a little ridiculous.

Let's take an example. Suppose we're building a recipe sharing application. During this sprint we're putting the basics in place, and at the end of it we have the ability for users to sign up and to create a recipe. We haven't yet specified what goes into a recipe, so for now it's just a free text box that is an attribute of the user. Hooray!

Now sprint 2 starts, and our stories include such surprises as "Users may have more than one recipe", and "Recipes have two components: ingredients and instructions".

"Oh, shoot! We're going to have to rework that!"

If we had looked ahead just one sprint, we would have seen that recipe is a separate concept from user, and we would have designed it accordingly. We would have saved ourself some time.

I'm not advocating for huge designs. But look ahead just a little bit, and design for that. After all, it's highly unlikely that absolutely everything will get changed between sprint N and sprint N+1. Some things will, but for the most part, it's safe to design a little ahead.

Build for this sprint. Design for this sprint and one or two after. Looking just a little bit ahead can save you a lot of time.

Wednesday, February 15, 2012

More Than The Product

This one's for all you consultants out there... (okay, yes, I did watch Back To The Future again last weekend).

Frequently, we're hired to produce a product. We write code and set up a production environment and deploy to it. We build the features the client wants, in the order the client wants it. We show the client progress along the way. Life is good!

But.

This approach puts a lot of work on the client. The client has to:

  • Plan releases or marketing pushes that include groups of features we're building... and time those releases.
  • Make sure the backlog is full enough that the team can work efficiently, which gets even harder when the team has specialists (and a CSS guy/designer versus a server-side coder is a specialist!).
  • Set expectations with his bosses or clients based on the team's work, even across vacations or sick days.
For some clients, particularly clients who are themselves experienced engineering managers, this is not a problem. They're used to looking at past velocity, evaluating a backlog, considering relatively complexity and risk, and setting a reasonable release date.  They're also used to actively managing a backlog considering not just priority but the team's skills and availability.

For other clients, this is a bit much. They're simply not technical clients. Or they've never managed a team before. Or they don't have enough exposure to the team to see when vacations happen or when the team makeup changes. For these clients, if you want to be successful as a consultant, you have to help them with all these things.

No matter how good the product is you build, if you're a consultant, you're offering more than the product. You're offering the product and the way it gets to the client over time. Consider your client, and make sure you're covering the delivery as well as the product itself.

Monday, February 13, 2012

Explanations Are a Usability Smell

Over the weekend, I spent some time helping out a friend with a new application they're building. They had just finished a big workflow story, and he wanted to get someone else to take a look and see if there was anything weird about the way the workflow ended up.

I found five bugs. Just plain "whoops it shouldn't do that" bugs. I also found seven places in which I had to ask for help figuring out the right thing to do. In each of those seven cases, the system was doing what the devs had intended it to do; there was no bug there. BUT there was training required.

Asking for an explanation is a smell.

We talk about code smells, and call things like long methods or excessive imports or even comments "smells". This is a usability smell. And just like a code smell, it's an indication that something isn't as apparent as it could be.

Sometimes we don't fix code smells. We know they're present, but we choose not to fix them, either because we don't have time, or because there are more important things to do. Sometimes we don't fix code smells because we're getting a lot of value out of the code as is and  that is more important than the smell. The default behavior, though, is that we should fix code smells, and it takes a really good argument to change that.

The same should hold true for usability smells. If an explanation is required for the user to get through something, that's a usability smell. By default, we should fix usability smells. We should live with the smell only if there's a really good argument for NOT fixing the usability smell.

It's easy to get into fixing code smells; we all acknowledge that's just good coding habit. It's time to get into fixing usability smells.

Wednesday, February 8, 2012

PyCrypto on OS X Lion

Why yes, I HAVE been having fun* installing python packages again. I need to SSH from Python, so I installed paramiko. Importing that told me I needed to install PyCrypto. Installing PyCrypto, I got this error:


arete:scratch catherine$ easy_install PyCrypto
Searching for PyCrypto
Reading http://pypi.python.org/simple/PyCrypto/
Reading http://pycrypto.sourceforge.net
Reading http://www.amk.ca/python/code/crypto
Reading http://www.pycrypto.org/
Best match: pycrypto 2.5
Downloading http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.5.tar.gz
Processing pycrypto-2.5.tar.gz
Running pycrypto-2.5/setup.py -q bdist_egg --dist-dir /var/folders/vn/y9kznfvx0zv06kxlvn111pp40000gn/T/easy_install-8aXjiK/pycrypto-2.5/egg-dist-tmp-L9drMW
warning: GMP or MPIR library not found; Not building Crypto.PublicKey._fastmath.
unable to execute gcc-4.2: No such file or directory
error: Setup script exited with error: command 'gcc-4.2' failed with exit status 1

Whoops.

Here's the magic incantation to fix this:


arete:scratch catherine$ sudo ln -s /usr/bin/gcc /usr/bin/gcc-4.2

And now our install goes juuuust fine.
arete:scratch catherine$ easy_install PyCrypto
Searching for PyCrypto
Reading http://pypi.python.org/simple/PyCrypto/
Reading http://pycrypto.sourceforge.net
Reading http://www.amk.ca/python/code/crypto
Reading http://www.pycrypto.org/
Best match: pycrypto 2.5
Downloading http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.5.tar.gz
Processing pycrypto-2.5.tar.gz
Running pycrypto-2.5/setup.py -q bdist_egg --dist-dir /var/folders/vn/y9kznfvx0zv06kxlvn111pp40000gn/T/easy_install-JYVoZl/pycrypto-2.5/egg-dist-tmp-Kq95pu
warning: GMP or MPIR library not found; Not building Crypto.PublicKey._fastmath.
zip_safe flag not set; analyzing archive contents...
Adding pycrypto 2.5 to easy-install.pth file


Installed /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/pycrypto-2.5-py2.7-macosx-10.6-intel.egg
Processing dependencies for PyCrypto
Finished processing dependencies for PyCrypto



Now, back to the work I meant to be doing!

*It's not actually fun. It's really sort of obnoxious.

Monday, February 6, 2012

Run Through the Finish Line

No matter how good we are, there are always going to be crunch periods. These are often structured around date-specific things where we want to look our best: demos, release dates, big new client starting, etc. We work really hard, pull some late nights, work a few weekends, and often something really great comes out of it.

It's really tempting to take the next day off. After all, when you've worked the last few weekends there's a big pile of laundry needing to be done (and a serious sock shortage!). As a manager, you want to give your team a reward for all the hard work, and a day off is usually appreciated.

Don't do it.

You've got to run all the way through the finish line. (I think this is a track and field term, obviously.)

After all, your big day - demo day or whatever - is just the start of your users' big days. They're going to need support. Maybe it's questions, maybe it's bugs, maybe it's congratulations. Either way, you need the team around for that. You need to make sure that all your efforts are still showing themselves as people start to use your system.

So don't take the day after the demo off. Take a day off a week later, or two weeks later. Once you've made sure you ran all the way through the finish line, then - and only then - you can stop running and take the time off.

Friday, February 3, 2012

Slice AND Dice Your Data

It's been a data-riffic week. It all started with a product comparison, then segued to a series of staffing questions, and is gearing up to conclude with a big bang load test. Suffice to say I've had a whole lot of paper shuffling around. These projects have two things in common: they're all dependent on the collection of large amounts of data; and their success depends on the clear presentation of that data to support my (brilliant, of course) conclusions.

So, how do we get our hands around all that data? And once we have a conclusion, how do we present it effectively?

Slice up the data. Then start over from the raw data and dice it an entirely different way. Repeat.

The point is to look at the data from several angles to gain comprehension. Let's take the product comparison as an angle. It was a pretty straightforward project: We need a CMS. Which one should we use? There are literally hundreds of CMSs in this world, and a whole lot of information available about most of them. Let's commence data analysis:

  • Slice. Make a feature comparison table, showing which ones have the features we're interested in.
  • Dice. Map out the release frequency of modules, showing how quickly these introduce new features (as a proxy for future feature development pace).
  • Slice. Figure out the annual cost of each CMS.
  • Dice. Describe the community around each CMS, including number of job postings/candidates, presence and activity in forums or other documentation, and breakdown of current users in our industry.
Etc. etc. etc. You get the point. The idea is to take the data available and look at it from several different angles. Each angle will point up some CMS that is more appropriate than others. By starting over each time, you avoid bias based on your earlier analysis. Collectively, the slicing and dicing produces a small list of really good candidates, and provides comprehensive grounds for argument.

So often we deal with large amounts of data, and it's easy to get overwhelmed and make a choice based on just a few data points and a rough guess. Take the time to cut through the data in a few ways, though, and your choice will not only be more obvious, it'll also be a better decision.