Skip to content

Video of the Week: Sales Safari

Amy Hoy discusses finding users’ pain points in this 50 minute presentation from 2013.

I think developers, myself included, are much more interested in the how (redis, nodejs, bright shiny things!) than in the why. Amy’s presentation is a good reminder that it is important to start with the why–what is your customer trying to achieve and why are they trying to achieve that. She calls this process a “sales safari”. Lots more information about this and other bootstrapping topics at her site.

On the benefits of a private, internal API

polygon photo
Photos by Double–M

A few years ago, the company for which I worked went through the monumental task of defining neighborhoods for a number of cities in the area where they had real estate agents.  Neighborhood data is hard to get, and this task required a lot of back and forth between the person responsible for the mapping and the people who knew the neighborhoods.  The maps were captured in Google’s My Maps feature, and exported as KML to a vendor who would then build neighborhood pages and maps with the data.  Much of the neighborhood page would be driven off data entered in an admin back end system (it was a custom CMS, essentially).

Almost as an afterthought, I asked the vendor to provide an API for the neighborhoods, including the polygon data.  I wrote up an API spec, had it reviewed by my team, and obtained approval for the vendor to build it. If I recall, it was in the neighborhood of a couple thousand dollars, and the vendor had never been asked to build something like this before.

This one API allowed the company to apply dearly won neighborhood information in so many ways:

  • generate statistics by neighborhood against any lat/lng coded data
  • tag any geocoded content with neighborhood meta data
  • find new and sold listings by neighborhood
  • understand who were top listing agents in each neighborhood
  • create internal BI tools
  • write internal recruiting tools
  • pull other geocoded data by neighborhood
  • tag transactions with neighborhood meta data

Many of these were accomplished with a plugin to the data processing tool (Pentaho Kettle) that used the Java Topology Suite. Creating JTS geometries is expensive, so the plugin caches them with a simple hashmap cache. The plugin java code is garbage collected fully on each data load run, so this simple solution is appropriate, rather than a more complex LRU cache.

However, this solution isn’t perfect. Often, if a property was on the boundary, the JTS code would often put it in the wrong neighborhood. Boundaries of neighborhoods are incorrect or overlap. Points are incorrect because geocoding isn’t perfect. Human review is still required.

But, the very fact that the neighborhood data was so accessible meant that the company could ask questions (how many homes are in each neighborhood, what are the three newest listings in this neighborhood) that simply couldn’t have been asked if there was no API. Having an internal API that exposed hard won business knowledge within the company was beneficial, even if it will never be exposed or monetized outside the company.

WP-Inject Rocks

inject photo
Photo by MattysFlicks

Inspired by Drew Meyers over at the Geek Estate Blog, I’ve made an effort to start putting images into my blog posts. I manually searched Flickr for commercially licenseable images, upload them to my server and put them into my post. After I did this a couple of times, I thought–surely there’s a plugin for this. And if not, I should write one!

A quick search turned up WP-Inject. I installed it and never looked back. It takes care of searching Flickr (and another site that I’ve never heard of called Pixabay). It takes care of the attribution link. It uploads the file to my server. It puts the image into my blog post. Well worth the install if you want to add any images to your posts at all.

My only wish is that it handled captions a bit better, but this could be a config option I’m overlooking. And that’s a small flaw for such an awesome plugin!

Giving books as gifts

book photo
Photo by shutterhacks

A few years ago one of my contracting clients gave me a book for a Christmas gift. It was a thoughtful gesture. It mattered all the more that I received it from a client who I’d spent a lot of time working for and who I know had spent a lot of time thinking about some of the issues the book raised. I read the book, and applied its lessons to my life, both business and personal.

Since then, I’ve given and received books to business colleagues and clients. Books are a unique gift because they convey a message in a way that few other gifts do. A book is a more committing gift than a visa gift card or a piece of electronic equipment (both gifts I’ve also received and was thankful for). You are asking for the receiver’s time and focus, and making a statement that the gift is worthy of both of those. You’re also making the statement that the recipient will benefit from the book. It’s a gift that actually has some demands (a bit like giving a gym membership, without as much judgement).

When you are giving a book, you’re giving a new idea. You are saying you were touched or changed by this book, and you hope that the recipient will find the same idea. You also need to understand the receiver–will they find the same benefit? Have they already tuned into the ideas so it will deepen their understanding? Is this a new perspective for them?

Bonus! If you set giving worthy books as a goal, it will make you read more books. It also has the beneficial side effect of forcing you to evaluate books you read from the perspective of ‘would I want to give this as a gift?’. Not every book has to meet that criteria, just as not every meal should be broccoli and yogurt, but it is a useful filter if you have limited reading time.

I hope I’ve convinced you to try giving books to your clients, colleagues, bosses and employees. The easiest way to start is to find a solid business book that you’ve enjoyed reading (‘Getting to Yes’ and ‘The Personal MBA’ are two candidates) and sending it to someone you have worked with for a while. Then, start a list and add any other books that resonate with you. When the holidays come around, you’ll have a list to choose from. Start small because of this higher bar this sets–you’re not just asking for a ‘Thank You’ and a place on a shelf, you’re asking for time and focus.  And those are precious.

Content generation for employee acquisition

interview photo
Photo by MattHurst

I was brainstorming the other day and thought of an add on service for recruiters. My explication of this service is focused on tech companies hiring engineers, but could easily be modified for any organization that is trying to find high value employees that are difficult to hire (high performing real estate agents, sales people, financial advisers, etc).

If your company is doing interesting things–solving tough problems or using interesting technologies–potential employees are very likely interested in your activities. How, though, will they find out about the cool problems your company is solving? Well, there’s your company website, back channel communications through professional networks, or presentations at conferences or meetups. But the traditional website serves many masters (including converting ‘customers who will pay you’), and content may be hard to generate or place. Professional networks often scale poorly, depending on where you are and what sector you are in. And presentations or meetups are rather scattershot and time consuming.

Enter the company tech blog. Write about solving interesting problems. Because the blog is tech focused, you avoid the issues with the traditional company website. (Of course, don’t write about any trade secrets or unprotected intellectual property, but in my experience a large chunk of the engineering problems solved at any company are scaffolding, not core knowledge.) It also scales, because the content is write once, recruit for years (not forever, because eventually the problems you discuss won’t be interesting). Basically, any argument in favor of content generation for customer acquisition can be applied to content generation for employee acquisition. So, set up that company blog and have your engineers start writing blog posts about interesting work they are doing. Soon, you’ll rank in Google and/or have Hacker News fame (see 42 floors).

Wait, what? You say that most engineers who are competent to write these articles either have no time, no interest, no ability or some combination of all three? I’ve seen many many company tech blogs that start off strong and interesting and then slowly fade away. This is more prevalent since other information dissemination platforms (your twitters, your facebooks, what have you) have proliferated, but for whatever reason, the key to a content generation strategy is to keep at it.

And that is where my idea shines. As a value add service for a recruiter, hire reporters to interview engineers. Have the reporters write the article, with engineer review to make sure it is correct, and have both on the byline (or use ‘as told to’). An interview about an interesting tech problem will probably take about an hour, and you can expect an hour for review, so you still have to carve out two hours from your engineer. If you have a team of ten engineers, and half are willing to be interviewed, that is less than two hours a month for a weekly blog post. Of course, you have to pay the reporter for more than two hours, but reporters are less expensive than engineers. Sure, this is an extra cost, but the article will be published. And the next one will get done. And eventually, the company will have a recruiting site working for you. Hard problems aren’t everything for engineers, but they count for a lot.

I mentioned this business plan to a friend and his feedback was–“seems like a great idea, but couldn’t an intern and a junior marketing person do this”? I think so, so I’d love to see more companies doing this! Hire that intern and that marketing person and start blogging about the hard problems you have faced and solved! However, maybe you outsource your recruiting efforts. If so, ask your recruiter about their content generation strategy.

If you are a recruiter, consider offering this as a value add service. (Eventually you may work yourself out of a job if your only value add is finding people, but good recruiters I’ve talked to offer more than just finding people–they screen them, make sure they are a culture fit, help the candidate through the process, and more.)

Do you know any companies or recruiters that are doing this? Do I have a fatal flaw in my idea? Let me know.

Saying Goodbye to 8z

Today is my last day as an FTE. After four years as an employee, and five years as an on and off contractor, I’m moving on from 8z. Partially–it looks like I’ll be doing some contracting.  8z is a great company that I think will be fixing what is broken in real estate for the foreseeable future.

I learned a lot in my time.  Here’s a top N list:

  1. Hiring is hard–I had the luxury of hiring a few employees and ICs, and it was a grind to find the right person.  I don’t know if that was because my budget was tight (so I was really only looking at entry or junior level candidates) or the team was small (so I needed someone willing to wear at least three hats–ops, developer, QA) or my location (Boulder) or the fact that developers are in high demand, but it was a grind. However, when I did find the right person (and I think I had a pretty good batting average) it was great to see the team gel and people advance in their skills and careers.
  2. Budgets are fiction, but a necessary one.  The planning required for a budget enforces rigor, but the actual spend almost always changed. Like Eisenhower said.
  3. Blogging is harder to do when you’re an employee. It’s just harder to find the time.
  4. Zapier is awesome.
  5. Managing while being an individual contributor is hard.  In a small team (we were never more than four), I (and everyone else) wore many hats, including PM, tech lead, developer, QA, DBA and business analyst.  From my reading–looking at you, Rands–some of the difficulty was intrinsic to management, not just management of a small team while wearing many hats.
  6. Having monthly one on ones with your direct reports is a bare minimum.  If you aren’t having these meetings with your reports or your superior, start doing so. The open lines of communication will pay dividends long term by making sure you aren’t surprised.
  7. Using the database as a bus lets you have a number of smaller isolated more easily understandable software processes.
  8. Being a software developer in a small team at a real estate company made it hard to find peers around Boulder. I didn’t fit into the startup culture nor did I fit into the bigCo culture.
  9. Default to using innodb.
  10. Core values can actually matter. If the CEO makes a regular effort to help them live.
  11. You can ship a lot of software with a small team.  But code rot will eventually bit you–here Jenkins and automated tests (junit, dbunit, qunit, phpunit, py.test, pentaho kettle testing, etc) are your friends. Jeff, thanks for pushing hudson!
  12. Gmail is an eminently usable web client.
  13. Having two equal co-founders is a tough row to hoe.
  14. Some people can tell the difference between Budweiser and Coors with their eyes closed.
  15. Google Apps is going to severely wound MS Office, and LibreOffice might do the rest.
  16. There is no substitute (none!) for asking the person who knows.  Many times I’d be discussing requirements or a bug, and come up with a question.  After batting it around a few times, the best course was always “well, let’s just ask XXX”, where XXX was the person who knew.  The nice thing about a small company is that the right person to ask is usually obvious, and if the first person you ask isn’t the right person, they know who is. Don’t speculate–find out!
  17. MLSes … if you are in real estate software and you want listing data, and you do, be prepared to spend a significant amount of time understanding your local MLS compliance rules.
  18. Some of my biggest wins in the last four years were finding the right tech partner, not building the software from scratch.
  19. APIs make sense, even in the smallest company.  Even if you are never going to expose them to the outside world for gain (and more so if you will).  They enforce a rigor and provide interfaces for polyglot development.  And you can be surprised where they’ll be useful.
  20. Java has a tremendous ecosystem.  This includes third party jars (like this one for querying polygons), frameworks like spring, and tools like maven.  I know lots of folks aren’t impressed with maven, but I found once you get your head around it, it can make your life easier. If there’s a build feature you want, maven already has it.  Plus, dependency management kicks ass–I hope that npm learns more from maven than just avoiding XML.
  21. A small team working primarily in Java seems to be an anomaly in this day and age.
  22. Having a consistent tech stack vision is good–it leads to reuse and fewer operational issues.
  23. It is far more satisfying to ship a 90% solution than not to ship at all.
  24. Hackfests and brown bags aren’t just for software companies.  With the support of the CEO, I introduced both of these to the wider company (see my post about monthly brown bags and semi annual hackfests) and they resulted in cross pollination, public speaking skills for employees, and some great ideas, including one that became a core 8z initiative.
  25. Having software in maintenance mode is tough on a team.  One of the biggest tasks for my team for about half of my time at 8z was to maintain an old complex website (10+ years old) just enough to keep it running. It was and is crucial to the business, but the business was trying to migrate away from it for a number of reasons (gobs of technical debt, among others).  This required painful choices, because often the right technical choice (fix the root cause) was the wrong business choice, and technical band-aids were the right business choice. That wears on me.
  26. Maps in Apache Cordova are hard to get right–the single threaded javascript execution environment really stinks when it comes to complex maps. (ht @intalex)
  27. A five character domain name gets a lot of purchase offers. You can also tell, to a first approximation, how technical someone is by how they react to your short domain name.
  28. Beer Friday (aka Friday afternoon club) is a great way to get people to interact cross department, but doesn’t work for everyone–not every coworker wants to hang out and have a beer.  Having other ways to cross pollinate makes sure everyone can participate.
  29. It is addictive to hear from consumers or other users that your software made their lives better.
  30. I learned as much or more from my failures as I did from my successes.  To name some particular personal failures, I made a hire that didn’t work out, a mobile app of which I was owner of that didn’t get to production (or even to QA) and a vendor who I evaluated, recommended and implemented that ended up not being a fit.  In each case it felt really crappy when it happened.  After I had some time and perspective, I was able to identify some lessons that hopefully will keep me from making the mistake again. You might hear more about these mistakes in the future.
  31. Finally, I enjoyed the the opportunity to be the primary technical voice at the executive table (while I never had the title, I was the effective CTO for a time). Bringing software engineering practices into a real estate company was fun and I think made 8z a better place to work. Of course, I could not have done any of that without the support of the owner/CEO, but it was fun to see what stuck and what didn’t.

The primary reason I joined 8z was that I felt after seven years of contracting and consulting that I wanted to be part of a team again. I also thought being an employee would let me grow in ways that you can’t as a contractor. Both of these turned out to be true.

Thanks for four great years!