Skip to content

Helping a friend gather data and reach prospects with gentle intros

coffee photo
Photo by My Aching Head

I had coffee with a friend the other day, and he shared a business idea. I thought it was an awesome idea–I certainly saw the need in the marketplace and believed he had the skillset and resources to execute on the idea.

He’s still in the exploratory phase, so I offered to send gentle intros to people in my network who I thought would benefit from his idea. (The target market is anyone with a custom web application that makes money, or anyone who builds custom web applications and is looking for a way to provide ongoing support–if that is you, contact me if you would like to learn more.)  I asked him to write a small spiel that he’d feel comfortable with me sharing.  If you are thinking of doing this, make your friend write a spiel for you.  If they can’t write a spiel, chances are they won’t be good at follow up and your intros will be wasted.

Then, I went through my LinkedIn network and put contacts into categories:

  1. this person (or the company for which they work) might want to partner with my friend
  2. this person (or the company for which they work) is a possible client for my friend’s offering
  3. this person might know people who are in categories 1 or 2.
  4. this person (or the company for which they work) is not a good fit for what my friend is working on
  5. who is this person?

And then I sent soft pitch emails to almost everyone in categories 1, 2 and 3.  The content varied based on which category someone was in, but for category 1, the email was something like:

I have a friend who owns a hosting company who is looking to talk to consulting companies about a possible new product he is thinking about offering.  Here is his spiel:

 

[…spiel from friend …]

 

I wasn’t sure if this kind of software maintenance was something that your company wanted to keep inhouse, or if you would be interested in discussing this with him.  I wanted to check before I did intros.    Is this something you think is worth learning more about?

This way, my friends and contacts on LinkedIn don’t get spammed from someone they don’t know.  Instead, they get an informative email from me, asking if they want to learn more.  If they do (and about 10% did), I do mutual introductions, and then the ball is in their court.  (Side note: here’s a great intro email etiquette guide.)

Why did I do this?  Well, there were a couple of reasons.

First and foremost, because I thought it would be a win win for both sides.  My friend gets more data about his offering and how the market will react to it.  My contacts/friends on LinkedIn learn about a new product from a trusted source.

Second, I was able to do some social network housecleaning.  I was able to ‘unlink’ with all people in category #5–it’s always nice to clean up your social graph.

Third, I reached out to people and had some interesting conversations.  Some folks I hadn’t talked to in years.  It’s good to reach out to people, and always better to do so with something of use to them, rather than a plea for work.

This was a fair bit of effort (a couple of hours).  I can’t imagine doing this monthly, but once a quarter seems reasonable, especially if I’m reaching out to a different segment of my network each time.  And I don’t have to do the whole process every time–spiel, linkedin, soft pitch, intro.  I actually like scanning news sites and simply sending interesting articles to old contacts: “Thought you might be interested in this <link> because of XXX and YYY”.  Those are super simple to send, and again, provide value and raise your profile.

Next time you talk to a friend who has a great idea, who can execute on it, and who will follow up with anybody you introduce them to, consider reviewing your social graph for prospects.  Gentle intros can benefit all three of you.

#TBT: Precision and Accuracy in Software

precision accuracy photo
Photo by {Guerrilla Futures | Jason Tester}

I originally wrote this in Dec of 2004. I still think that having someone who can answer engineers’ questions authoritatively increases productivity (of the engineer). However, now I’d emphasize that developers need to spend some time learning their domain to gain some intuition, and truly great business software engineers will learn when to bump a question up to a business person and when their intuition can be trusted.

————————————————————-

Back in college, when I took first year physics lab, there was a section of the course that focused on teaching the difference between precision and accuracy in measurement. This distinction was crucial in experimental physics, since measurement is the bedrock of such experimentation. Basically, precision is how many digits of a measurement actually mean something. If I’m measuring the length of a room with my stride (and found it to be 30 feet long), the precision is less than if I were to measure the length of the room with a tape measure (and found it to be 33 feet, 6 and ¾ inches long). However, it’s possible that the stride measurement is more accurate than the length found with the tape measure, that is, it reflects how long the room actually is. (Perhaps there’s clothing on the floor which adds tape measurement, but which I stride over.)

These concepts aren’t just valid in physics; I think they’re also useful in software. When building a piece of software, I am precise if I build what I say I am going to build, and I am accurate if what I build actually meets the client’s business needs, that is, it solves the business problem. Almost every development tool either makes development more precise or more accurate.

The concept of precision lends itself easily to automation. For example, unit testing is rapidly gaining credence as a useful software technique. With unit testing, a developer writes test cases for each part of their code (often at the method level). The running of these tests ensures that code is actually doing what the developer thinks it is doing. I like writing unit tests; it gives me comfort to know that corner cases are taken care of and that changes to code can be fairly easily regression tested. Other techniques besides unit testing that help ensure precision include:

Round tripping: using a tool like TogetherJ, I can ensure that the model (often described in UML) and the code are in sync. This makes it easier for me to verify my mental model against the code.

Specification writing: The more precise a spec is, the easier it is to translate into code.

Compilers: the checking that occurs at compilation time can be very helpful in ensuring that the code is doing what I think it is doing–at a very low level. Obviously, this technique depends on the language used.

Now, precision is needed, because if I am not confident that I understand what the code is doing, then I’m in real trouble. However, accuracy is much more important. Having a customer onsite is a great example of a technique to ensure accuracy: you have a business domain expert available all the time for developers’ questions. In this situation, when a developer stumbles across a part of the business problem that they don’t quite understand, the don’t do what developers normally do (in order of decreasing accuracy):

  1. Ask another developer, which works great if the target audience is developers, but not so well otherwise.
  2. 2Best approximation (read: guess at the correct answer).
  3. Ignore the issue. (‘I’ve got a lot more code to write before I can go home today, and we’re shipping in two weeks. We’ll just let the customer discover it and deal with it as a bug.’)

Instead, they have a real live business person, to whom this software really matters (hopefully), who they can ask. Doing this makes it much more likely that the final solution will actually solve the business problem. Other techniques to help improve accuracy include:

Issue tracking software (I use Bugzilla): Having a place where questions and conversations are recorded is truly helpful in making sure the mental model of the business user and the programmer are in sync. Using a web based tool means that non-technical users can participate and contribute.

Specification writing: A well written spec allows both the business user and developer to have a sense of what is being built, which means that the business user can correct invalid notions at an early stage. However, if a spec is too detailed, it can be used to justify precision at the cost of accuracy (‘hey, the code does exactly what’s specified’ is the excuse you’ll hear).

Spring and other dependency injection tools, as well as IDEs: These tools help accuracy by decreasing the costs of changing code.

Precision and accuracy are both important in software engineering. Perhaps the best way to characterize the two concepts is that precision is the mapping of the programmer’s model of the problem to the computer’s model, whereas accuracy is the mapping of the business’ needs to the programmer’s model. However, though both are needed, accuracy is much harder to obtain. Knowing that I’m building precisely what I think I’m building is beneficial only insofar as what I think I’m building is actually what the customer needs.

Be an Informal Recruiter

link photo
Photo by elcovs

As I kick start my consulting business, I’m talking to many people–everyone in my network, anyone that I am referred to, and random people from Hacker News.  Employment is far less fungible than other purchases (even housing), so it behooves anyone selling labor to cast a wide net.

These introductions and conversations have not just given me the chance to talk about my skills and knowledge, but also to learn about other needs of the company.  Even if they don’t have need for a senior developer who can talk business and learn new languages, they may have a need for someone else in my network.

I’ve been about to do a few such intros since early August.  It actually is quite fun to do this, and it is good for karma.  It’s also a great way to stand out from the pack–if I an helpful to the organization before I take a job/contract with it, imagine how helpful I will be when I am engaged day to day.

During initial contact with the interesting organization, I talk about my skills and how that might fill the organization’s needs–after all, they are interested in meeting and learning about me.  But I also note any other needs, either via postings on their websites, needs they imply or mention in the conversation, or by simply asking them: “do you have any other needs at this time?  I like to help and would be happy to ping my network”.  I take notes.

Once I know some needs, I consider who in my network might help fulfill them.  Then I reach out to the members of my network and see if they can help. Typically, I send an email with the details of the need, and ask if they know anyone who might be a fit for the company.  Network members don’t have to be looking to make a move.  They will probably know of folks who can be a good fit.  For example, a marketing will typically know far more marketers than I will.  Therefore, if an organization I am interested in helping needs a marketing assistant, reaching out to marketers in my network and asking if they know anyone looking will be helpful. This interaction is useful to my network contacts–it lets them reach out to their network, opens a conversation with me, informs them of labor market conditions with minimal work on their part, and could end up in a new job if the fit is right.

This technique also lets me have a soft touch point with the prospect in a week or so.  I say something like “I reached out to my network about the position X you posted, and haven’t heard back from anyone, just wanted to let you know.”

If I don’t have a specific person who could help fill this role (either themselves or via their contacts), there are other ways to add value.  I’ve passed on recruiting tips (or interested tech articles), helpful employment sites, or general labor market advice such as “based on what I’ve seen, you might to have a hard time finding someone expert in tech X for pay Y”, or “in my experience, rates for tech X are $Y/hour”.  All of these add value to the interaction at very little cost to me.

Connecting people with openings is great for hiring managers on the other side of the hiring/contracting process.  If I am casting a wide net looking for contracts, I have recent data as well as a network and perspective worth sharing.  Since this is low cost to me and has benefits for me, the organization I am interacting with and members of my network, it is worth the extra effort to be mindful of needs and to send that intro email.

“Where there’s muck, there’s brass”

hydra photo
Photo by Andrew Jian

I was reading this Ask HN post about a consulting arrangement that seemed a Sisyphean task. Here’s an excerpt:

I have been asked to consult a company in how they should speed up their development process.

 

Today the application which in the end of it all is a web application, consists of a lot of old ASP classic code, a COM+ bridge for being able to function within a mix of a lot of different .NET libraries written in .NET 3.5 (CLR 2). COM+ acts as a bridge between the two technologies.

 

The teams cannot compile code inside the development tools, it can’t debug unless they do it with some obscure hacks and workarounds and it seems that no one is really in control of what is going on in the core code base and no one really want to touch the original code base to clean it up and refactor/re-write it.

Seems pretty hopeless, right?  “Teams can’t compile code”?!  Unfortunately, this type of task is more typical of consulting engagements than not. After all, if there was a simple solution, why would the company have engaged a high priced consultant?  (If you are consulting and not ‘high priced’, well, that’s a problem, but a different one better left for another post.)

The comments on the post are interesting and worth reading. I left one, but wanted to expand on it. Now, I’m not familiar with the tech stack at all, but I am familiar with a large codebase (where large is relative to the size of the team supporting it–100K LOC can be large to two person team) with a lot of technical debt that was crucial to the business.  I have also consulted for years.

Whenever you are consulting, the first task is always to ascertain the real problem.  Hint–it’s often not what you were explicitly hired to do.  In this case, I’m guessing the real issue is that the web application needs to change to meet business needs, and that it can’t do so fast enough because of the accretion of complexity.  But a guess isn’t good enough, you need to find out what you are being hired to do–it could be you are being hired to provide cover to spend money to rewrite the app or to be blamed when a development team misses dates or to actually speed up compilation.

Then, you need to learn who wants the task done, and who is writing the checks.  They are sometimes the same person, but not always.  You also need to learn how these folks want to be communicated with, including method, verbosity and frequency.

Finally, you can start to dig into the (software) problem.  (This process assumes you are doing time and materials billing.)  Do a preliminary investigation and look at some of the following:

  • given the end goal, what are intermediate steps that can get you there?  How long would it take to get one or two of these steps?
  • are there third party solutions that can get you 90% of the way to solving the business problem–this can include framework upgrades?
  • are there subsystems of the current hand coded solution that are isolated and can be reworked with minimal impact on the system?
  • are there one or two huge issues that would be a relatively easy win (version control, big bugs, moving configuration from code to a database, etc)?

Prepare ballpark estimates on the level of effort to accomplish some of these.  After that, you need to sit down with whoever wants the task done and whoever is paying for it.  Present your options, making it clear that any time estimates are truly SWAGs.

Let them decide.

If they ask for a recommendation, be prepared to make one, but the decision must be theirs.  They have the business context to know how much to invest in this system.

After that, either withdraw or start executing against the plan you and the decision makers have decided on.

Simple, right?

Build your capital

I was working on a post about how important it is to have a side project, but then read this post by patio11: “Don’t End the Week with Nothing”, which could be more accurately titled “Don’t End the Week with Nothing except your Paycheck”. Not that there is anything wrong with just having a paycheck, but Patrick’s point is that when you work on something you own, rather than something you are paid for, you can (in the right circumstances, with hard work and luck) get accumulating returns.

He did such a good job explaining how to move your career forward as a software developer (a superset of the topic I was covering with my “have a side project” post), that I wanted to call your attention to it. The whole article is worth reading, but here’s my favorite part:

Telling people you can do great work is easy: any idiot can do it, and many idiots do. Having people tell people you do great work is an improvement. It suffers because measuring individual productivity on a team effort is famously difficult, and people often have no particular reason to trust the representations of the people doing the endorsements.

This is one of the reasons I blog, it’s why I have spoken at several user’s groups, it is why I wrote a book, and it is why I have a side project.

Q and A: Unexpected technical issues when contracting

I got a question from a friend who is doing some freelancing.

Perhaps an odd question, but when you do web work and run into issues that are only showing up in IE browsers, do you bill the client for the extra time it takes to try to figure out how to make the site work on that crappy browser? I know the web developer(s) we used for the farm calculator [a project for which he was the client] bill for everything, even if they are redoing something they screwed up… but I’m curious as to your way of handling things like this. I want to be fair to my client, and myself!

This is a great question, and goes beyond just “IE browser” issues.  Here was my answer:

When I run into an IE problem, I will usually stop and ask the client if making it work perfectly on IE is really important to them.  It would be useful to have stats for IE on their website (or the broader internet: http://en.wikipedia.org/wiki/Usage_share_of_web_browsers ), so they can know if 10% of their users are on IE6 or 0.01%.  It also would be useful to have an estimate for how long it will take (as long as you’re clear that it is an estimate).

If I’m billing time and materials, and I’ve had this conversation, I absolutely bill the client, but try to keep them informed as to how long this is taking me.

If it is a fixed bid, then I might go to the client and say ‘I’ve run into this issue, for this browser, which is x% of your website traffic.  There’s solution A and solution B, but both of them are things I didn’t expect.  Can we talk about this additional work’.  If they say no, I grit my teeth and deal.

So, to make it more broadly applicable, if you run into issues that you didn’t expect, here’s my advice:

  • Stop work and identify the issue.  Don’t keep spinning your wheels.
  • Gather useful facts to help the client make an informed decision (IE browser % in the example above).  Include a rough estimate if you can, but make sure the client knows it is an estimate.
  • Talk to the client about the issue and find some kind of resolution.
  • If the resolution is you doing the work, then, if you are on a fixed bid, explain how you didn’t consider this particular issue and see if the client is flexible about paying for it.
  • If the resolution is you doing the work, and you are on a time and materials contract, then bill for the extra work.
  • In either case make sure you keep the client in the loop about time spent and schedule changes due to the issue.

Surprises come up all the time.  What is important is that you come to a fair accommodation with your client.

My experience implementing GWO for a non profit, part 2

I was finally able to get access to the wild.org server via FTP (previous cliffhanger resolved).  After cautioning me to be very careful (“please proceed with caution and help keep wild.org from blowing up…warnings from my IT guy”) Emily handed over FTP access.

I proceeded very carefully.

We had already had discussions about what we were going to vary to test the donation button.  Pictures, location of button, text of button, and text around button were the major variables.  One of the hard things about GWO is deciding what to test–the possibilities are infinite.  Even with our handful of variables, we ended up dropping some options and still have 100 variations to test!

Actually installing GWO was pretty easy.  The only wrinkle was the fact that the goal was a click of a button and not another page.  This post was helpful.  One item that that post didn’t cover was validation–GWO doesn’t let you start an experiment if the program can’t verify that the script tags are installed correctly.  Since we were doing a non standard install, I gimmicked up a goal page for validation, then added the goal tracking to the onclick event as described in the post.

So, the experiment is currently running on The WILD Foundation homepage.  It’s been running for about a week, and has only 1 non test conversion.  I worry that we are not testing big enough changes (a donate lightbox, rework the entire front page), but I think it makes sense to let the test run for a few weeks and see what kind of data we get.

My experience implementing GWO for a non profit, part 1

A few weeks ago, I went to the most recent BDNT and saw a number of non profits present.  It was very interesting to see the vast range of needs and technical experience across the twelve non profits who actually presented.  Everything from a small webapp project to any web presence at all to updating a custom php webapp.

Most did a good job of containing their request to something manageable, though one group did get asked “Do you need a super volunteer or an employee” by Andrew Hyde, I assume because their needs seemed so vast.  The answer: no employee would be hired :).

After pizza (thanks BDNT sponsors! ) I wandered up to the group that had piqued my interest the most.  The WILD Foundation had an employee (Emily) whose job responsiblities included social media, a blog, and actively engaging the online community.  This strategy had worked wonders for the foundation’s web traffic, but for online donations?  Not so much.  This was the challenge she asked us to attack.

The session was moderated by Derek Scruggs and there were lots of great ideas.  To paraphrase, you could see where someone sat by what actions they suggested.  I mentioned Google Website Optimizer (a tool I’ve been a fan of for a long time); marketing folks wanted to focus on the message; some people wanted to change button color.  There were about 10 suggestions at the end.  Derek and Emily and the group then ranked them by effort (mostly group input) and priority (mostly Emily input).  Then we assigned tasks to volunteers.

I volunteered to set up a GWO test for the donate button on the WILD.org homepage.  We’re going to vary images and text to see if we can drive greater click through to the donate page.  Eventually, it’d be nice to optimize the whole process, but the actual donation page and donation thank you page are hosted on a vendor’s server, so I’m not sure whether we’ll be able to.

It’s been a week or so, and I still haven’t gotten write access to the template so I can add the code.  There are a number of reasons, and I think they might be common to all technical volunteer efforts, so I thought I’d outline them.

  • Exploration of technology takes some time.  I looked at the GWO for wordpress plugins, and found that they didn’t quite do what we wanted.  I also nosed around the existing site and found which file to change in the theme.  And I suggested what elements we might want to vary and ran those by Emily.
  • Time was a big issue; both mine and Emily’s was generally lacking.  Since it was a volunteer effort, I squeezed it in around work that paid.  Emily had to do her job first too.
  • Trust had to be established.  These folks didn’t know me from Adam, and yet were letting me edit one of their primary faces to the world?  Emily’s IT guy was rightly concerned about this, and insisted on a website backup.
  • IT issues–I had trouble editing the theme files, and working through Emily (with this being neither of our highest priority) to resolve the IT issue (basically, getting me an FTP account) took some additional time.  As mentioned above, there’s still an issue of not being able to track the entire donation process (so as to optimize it) because the WILD foundation uses a third party donation acceptance service.  I think we can make it work but wanted to get a win and build trust without having to involve a third party like the donation acceptance vendor.

However, it’s all coming together.  Once I get GWO up and running, I’ll let you know.