Creating a win

In my job, I do a mix of project work (larger bits, building sites, etc), tickets (service requests from clients) & management (running a company). Historically, I would spend my mornings doing the latter two tasks – they’re all piecemeal items that take anywhere from 5 minutes to 2 hours to complete, then I’d switch over to project work in the afternoon before wrapping up with a little management action – mostly status updates from staff/contractors.

This was ok, except that it really left only 3-4 hours a day to do project work, and in the afternoons which have *always* been less productive than mornings & evenings for me. I felt like I always had a huge pile of tickets and wasn’t keeping up with project work. Partially because we’re so busy, but partially just a sense because with such a short timeframe, I often wasn’t reaching a milestone within a day. And I like checking things off my to-do list.

So earlier this year, I started to push things around, and watch how things fell out. I don’t work fridays, and I don’t launch projects on thursdays (because I don’t work fridays), so I tried to do tickets & non-daily management tasks on Thursdays. This worked out ok for me, but less so for clients – they wanted tickets done before thursdays so that they could review them too. So now I’ve moved my “tickets” day to Mondays. And this has been an epic win.

I discovered that no one minded if I told them that their request would be completed the following Monday – even though they minded when I used to say Thursdays. I think that’s because mentally, Mondays are the start of something, even if it’s the next something, whereas Thursdays are near the end, so people are feeling rushed to finish before the end of the week. And because I’m not in the office on Fridays, there was always an extra dose of staff management, partner meetings & ticket requests to deal with anyways.

So now on Mondays I do tickets, I buy supplies, I check on staff, I check in on clients. I spend all day doing little 5 minute-1 hour tasks. By the end of the day, generally, my to-dos for the week have dropped to only the projects I’m working on and 1 or 2 others. And, rather than feeling stressed because I’m already behind after 1 day, I instead feel accomplished because I’ve cleared my slate and now have 3 solid days of “real” development ahead of me. Days with few interruptions where I can knock off milestones and get that satisfying tick on my to do list.

So I’m not doing any less work, or any different work. But just by examining how I worked, and looking at what clients were expecting, I’ve been able to shift my week around to be, on the whole, markedly more productive than it was prior to my making this shift. I’ve created a win for myself where previously there was generally only failure and “close”. This month we’re experimenting by putting everyone on this schedule. We now have enough staff that every day but Friday has 1 staff member knocking out service requests, freeing the rest of us to just to project work the rest of the week. I’m hoping that we’ll not only maintain our current turn-around-times for service requests, but potentially actually get a little faster with this system, even though each staff is spending only 1 day a week, rather than little bits of everyday.


Blast from the Past: Pencilneck Creations Site Mockup

At the turn of the century, I was finishing my degree & running my company as a sideline. Today, digging through my digital archives to find a file from that era, I found this: My photoshop mockup for the original Pencilneck Creations site (Pencilneck Software was born when I joined forces with Jeff. Given the nature of the company, we changed the company name slightly from ‘Creations’ to ‘Software’):

Pencilneck Creations
The remaining mockup from my original "corporate" site

Simple, very plain – this is definitely the style I liked at the time. Not that there was any fear of anyone confusing me with a designer. But looking at our current site (woefully out of date as it is), we’ve come a long way, baby.

Have Lunch with Me

I often waffle back-and-forth about the value of “soft” networking – where I’m not necessarily wanting something from the other person, or vice versa – but more just a “hey, how are you, what’s new?” A friendly interaction so that I know the cool stuff that they’re doing and vice versa. Defining a value for this is hard, and it does take time – which is one thing I often don’t have a lot of. On the other hand, there are lots of very cool people, locally, doing very cool, very diverse work. There may never be a direct professional reason for us to interact, but does that matter? Lauren & I get together for drinks semi-frequently (or semi-infrequently. Whatever the description, it’s probably not often enough). We talk some shop, but because we’ve been friends for ages, we’re just as likely to not talk shop. I don’t expect to get business out of it, but I do find I often come back from our sessions feeling re-energized about some particular topic or problem.

Being an entrepreneur can be fairly isolating – actually, that was one of the draws for me. I focus on my work, my business part focuses on sales, and magically money appears (where I by magically I mean we work really f’ing hard, but there’s definitely some magic to how it all comes together). But beyond our internal interactions, there’s very few outlets to talk, at large, about business ideas. I can read books, attend conferences, participate in online forums/discussions, but none of those replace good face to face interactions. What’s more, I firmly believe that local markets strongly influence companies – that is, 2 small companies from Vancouver, in different segments, are more likely to have similar issues than 2 companies in the same segment from different cities. Things like health benefits, paying staff enough to afford Vancouver’s exorbitant real estate, life balance, transit, parking, etc. When I meet with other small business owners or consultants elsewhere, we chat superficially, but there’s always this element of competition about our interactions. Lauren wrote very eloquently about defining your own success for BC Business, which I think is a key component when chatting with other professionals. I’m certainly guilty of being envious of colleagues’ successes. But lately, I find myself more able to celebrate their success, without feeling that inner lurch of envy. Possibly because I’m really proud of what I’ve accomplished, but mostly I think because I’ve learned that there’s no one whom I need to compete with more than myself. If I can always make my next project better, in some way, than my last, I’m doing things right.

So, loooong digression from the original point of this post aside, I’ve been thinking about trying to “network”. Wherein by “network” I mean “have lunch/drinks with people whom I think are doing cool stuff”. I follow on Twitter a whole slew of locals whom I’ve met here & there at some function but otherwise don’t know. This is often the case – I don’t do terribly well at functions – a room full of strangers – even a room full of friends is a panic inducing thought. But I may well have heard enough to want to know more, somewhen. Many I don’t even know what you do. I often end up with clutches of business cards or new twitter handles, without being able to remember why I even have them. But you seem interesting & I’d like to know more. So I’m going to try something out: I’m going to try & have lunch with someone local whom I think is doing something cool at least once a month. That might not seem like a lot, but it’s a start. I don’t want to sell you on Pencilneck Software, I don’t want to be sold on your company. I just want to meet you and listen to your story, tell you something about mine. Low-key, and spaced far enough part that I don’t stress out about it.


So what I’m saying, dear Vancouver, is that I’d like to have lunch with you. I’m booked already this week, but how’s your next week looking?

Calendar Synch

At work, we use a ticketing/timetracking app that I wrote a while back. It’s served us well, and, hopefully in the near future, we’ll roll it out to be a full-fledged stand-alone product (we’re doing some closed beta-testing right now – if you’re a consultancy/digital studio looking for something like this, let me know!).

Today I finally added a feature I’ve been wanting for ages: Synching the ticket-list with my calendars. It’s a fairly simple process. Based on the query string, I can spit out a webcal:// feed of all tickets, all tickets for a particular client, tickets of a particular type, assigned to a particular person, in a particular state, or any combination of any of those. These then just show up in my calendar under my Calendar subscriptions, and allow me to see at a glance what’s coming up. I’ve set my subscription to refresh hourly so I can see what everyone’s doing.

Currently, I’m only writing iCal events, but I’m playing with being able to send to-do lists this way. For “tasks” that are meetings, I can send these as invites to the attendees, which is pretty cool too – all through our centralized ticketing & time-tracking system. Mostly, as a manager, I can quickly look at the calendars for my staff to see who’s working on what when so I have a quick idea of availability. And even my own, which I sometimes lose track of.

Writing an ICS file turns out to be even more trivial that I had thought it would be – I honestly don’t know why I don’t have this as a standard part of every calendar module on every site as a subscription option. Now that I’ve written a simple function to pass in an array of date info and spit out an ICS file, I likely will.

But what’s most rewarding about this work is the immediate use this has received by our beta-test group – who were used to using calendars to manage their work before, but wanted something more central – so now they have the best of both worlds: centralized, web-based ticketing/time-tracking, but each user can still continue to use their desktop & phone calendars as they used to.

It’s nice when an afternoon’s project works out so well!

Getting the Yaris Serviced

I own a Toyota Yaris that I bought from Downtown Toyota four years ago. It used to almost never be driven, but we’ve driven it more since moving to south van – it’s now up to about 40,000 kms. For the first 18 months, everything was great. We had our first service, a recall-fix and something else. And then about 2 years ago, the Pattison Group took it over and it went downhill. I’m not sure if the staff changed, but the next few times we went in there, it just wasn’t as friendly as before. Also, they started telling us that we a) needed to rotate our tires and b) needed new tires because they were wearing out. And a couple of other suggested fixes. Which would be fine on an older car. But a 2-year old car that didn’t get driven that much, it seemed odd. Now I don’t know anything about cars or maintenance, so I was willing to believe them, but fortunately Leah knows a fair bit, and didn’t believe them.

Purely by coincidence, another Yaris-owning friend of mine had recently had a good experience at a different dealer – Granville Toyota, so, for our 40,000 km checkup, I thought we’d give them a try. And it was good service. The people at the shop were noticeably friendlier. When I mentioned that there might be an issue with our headlight, he not only noted that it should be looked at, but checked both if I would approve costs for work and if necessary, replacement, explaining what would it would likely entail, and a price range for approval, saying he’d call if the issue was different and would cost more. A nice change.

I explained also that the car had to be ready by four, so we could pick up Liam, and, just as I was about to call to ask if the car was ready, they called to say it was. Leah picked up the car. And guess what? Our tires, brakes and everything were in great shape according to this dealer. Which just makes me think that Downtown Toyota was just trying to make a fast buck at our expense.

So we’ll keep taking our car to Granville Toyota for now when we need our scheduled Maintenance. Customer service is sort of like running along a tightrope above lava: You can waver a little bit, but one wrong step and you’ll lose a customer for life. It’s something I try to keep in mind in what I do, and good advice for anyone who depends on repeat business.

A Day Apart Seattle – my thoughts on the workshop

Last week, I posted my thoughts on Day 1 of An Even Apart  (Seattle). I had fully planned on writing on both day 2 & the 3rd-day workshop, but after somehow losing a longish post to the ether, am skipping day 2. Suffice to say, the quality of the talks continued, as well as the laser-like focus on what can be accomplished with HTML5 and CSS3.

The A Day Apart Workshop was my primary reason for attending the conference. I wanted some hands-on learning & experimentation with these new tools that I had been unable to play with much. I have seen both Jeremy Keith & Dan Cederholm speak previously, so knew they would be good. And they were good. In fact, I would argue that the only thing that made this workshop worthwhile in the end was the quality of the presenters, who overcame everything to actually deliver quality.

This was the first A Day Apart put on by the AEA folks, so I expected it to not be perfect. But I did expect more. I’m certain that the next iteration will improve slightly on this one, and so on and so forth. But let me list my complaints, with some hopefully helpful critique:

  • Size of workshop: There were simply too many attendees in one room. It meant, for the most part, that it was hard to carry on a Q&A thread, because you don’t want to take up everyone else’s time & B, radically changed the possibilities of how run the workshop. To fix, I’d recommend a)lessening the number of spaces available and b)split the audience into 2 groups. Group A would get presenter #1 in the AM, presenter #2 in the PM. Group B would get it in reverse. Yes, this would double the work-load for the speakers – but I think would vastly enhance the experience for the attendees.
  • Format of workshop: The workshops were really just extended seminars – not so much a workshop.  While Jeremy’s seminar & workshop topics were different, Dan was talking about CSS3 in both, so his workshop felt like an extension of his earlier seminar. Jeremy had us guess the definitions of elements from the HTML 5 spec, and actually work that out. The result? I remember those definitions more than virtually anything else. Because I got to actually interact with the material. So here’s my suggestion to fix this: Each workshop was divided into 3 parts (if I recall correctly). If, let’s say, 10 minutes was cut out each (maybe even 20 minutes) and replace with a related exercise for the audience to do, suddenly the interaction with the material would increase greatly, and, I suspect, both people’s comprehension & retention of the material. If, in addition to 10 minutes of homework, there was schedule in 10 minutes for post-homework Q&A, that provides a nice way to summarize each content block.
  • Density of Material: The material-to-time ratio was way off, which meant we raced through the material. Either cover less or make the workshop longer. Both spent a long time on the history of the material – this was useful, but could likely have been done quicker, given the quality of the rest of the meat they were delivering.
  • Related Assets/sample code: We were all given a book with all the slides printed and bound into it. This is a great reference. But an online wiki, perhaps specific to the course, that was setup by the creators, but, going forward, be looked at, edited, updated by the attendees would be awesome. If a laptop was required (given the audience, I don’t think that’s an unreasonable request) and we were provided links to download some source code, we could then, in the workshop, very quickly build a site each, to see the material in action ourselves – this would work great with the ’10 minutes of homework per section’ model – you just keep building on. This has been, more or less, the standard for programming workshops I’ve attended. For me, this is likely the biggest miss.

Despite everything I’ve written above, I do feel that I came out that workshop with a better understanding of the two tools I went into the workshop wanting to learn. As I said above, this is almost entirely due to the quality of the speakers, not the format of the workshop itself. If there was to be another A Day Apart at a future conference, on a topic of interest to me, I would certainly consider attending it again. But while it was OK, it could have been great.

Update (2010-4-12): I had initially remarked that both workshops felt like extensions of the seminar. Jeremy, thankfully, corrected me that his seminar and workshops were quite different. My apologies.

An Event Apart Seattle (2010) – Day 1

I spent the first 3 days this week at An Event Apart (Seattle). This is a conference that I’d been wanting to attend since its inception, but somehow never actually made it down to one. I was really looking forward to a few days of self-affirming web-geekery. And that respect, I wasn’t disappointed.

I don’t know the process by which An Event Apart selects their speakers, but whatever it is, it is good. From start to finish, the quality of the presentations were excellent – even those whose content I wasn’t particularly interested in. Jeffrey Zeldman got us started in fine form, with a talk, essentially, about mistakes that would be good to avoid in running a studio. Having been running a shop (or studio) for the past 7 years, this was of very little interest to me – I’ve made those same mistakes previously, I’ve come to many of the same conclusions, I’d offer the same advice to anyone wanting to strike out on their own. But! I still thoroughly enjoyed it. A light hors d’oeuvre before the meaty sessions that followed. He’s a great speaker, which made this otherwise too-low-level talk appreciable by all.

Of all the talks, Nicole Sullivan‘s, who followed next, was the least inspiring. It fell between two worlds for me. She was talking about object-oriented CSS. Given her background, I was hoping for a super-nerdy, intense look at site-speed optimization & whatnot. We got a little bit of that – but not with the detail I’d like, and then the second-half of her talk was spent looking at her wish-list for things to be included in future CSS spec. So, not even actual proposed spec. Things that she proposes should be in proposed spec that I might get to use in bleeding-edge browsers 3-4 years from now and actual projects a decade or so in the future. Which felt like a waste of my time, to be honest. So, while I’m down on her talk, her answers in the brief Q&A were great and I’d love to hear her do a “developer” talk, rather than a “designer” talk, which this seemed to be.

Dan Cederholm talked CSS3, and gave some nice tips & tricks. His presentations are fantastic – but I’ll talk more about him later. Luke Wroblweski gave the talk that I wish every designer in the world could hear. Titled “Mobile First!”, I think Jeffrey Zelman summed it up best: “Luke Wroblewski’s extraordinary “Mobile First” presentation changed the way I think about web design”. It was compelling, well-backed-up with samples, and, perhaps best of all, seemed very easy to implement.

Aaron Walter‘s talk ‘Learning To Love Humans—Emotional Interface Design’ was funny, humble  and very very smart – all about how to create an emotional response to design, and moving beyond the idea that functional is the goal (paraphrasing Aaron to sum it up: You never hear a chef say ‘taste this, it’s edible!’ so why should a designer).

If you’ve never heard Jared Spool talk about usability, design & process, chances are you’re doing it wrong. His insights are incredible. His talk here was about the anatomy of a design decision – what ‘kind’ of design to teams do, how they arrive at that process, and what effect it has both on productivity and on end-user experience. The 101-take: Experience is what happens in the space between actions. His talk, to me, nicely summed the internal conflict that makes Pencilneck Software work so well. I am, by default, an intuitive developer. I rely on tips, tricks, experience and instinct to guide me through what I do. Jeff, by contrast, is a firm believer in process & methodology to get things done right. Where we meet in the middle is why we are successful where lots of other firms have failed, I feel – and Jared Spool really captured both the differences in approach and how they each affect teams & workflow.

What I look for in a potential hire

I’ve been thinking a fair bit the last little while about how I run a business. This started after a conversation on Linked In with Dave MacDonald sometime last fall, but has percolated to the top of my brain of late. I recently passed the 7th anniversary of my company, and I’ve worked in small companies for nearly all my professional life at every level, so I suspect that I have some insights. So, consider this the first in an irregular series on running a business.

Here’s the dirty secret about getting hired by me: by the time you’ve shaken my hand and sat down, I already know if I want to hire you or not. All that’s left to figure out is whether or not you can lose the position by not being what I expect, how exactly I want to slot you into my company, and, most importantly, how you want to slot my company into your life. This means 2 major things:

  1. My first impression of you when you walk in the door is key – this is the “gut” decision that Malcolm Gladwell talks about so much in “Blink“. In over a decade of hiring people, I’ve only been wrong once when I thought someone would be a good fit (I’ve no idea, of course, how many times I’ve been wrong when I thought you wouldn’t fit in). I might talk about what I look for in an interview another time.
  2. Everything you do that leads up to me calling you to interview you is vitally important. And that’s what I’m going to look at today.

There was an article last week on SquawkFox called “6 works that make your resumé suck“. All that is true. I will likely throw your cv out if I see a lot of that. Other tips for resumés and cover letters:

  • Short! If your resumé is more than 1 sheet of paper, double-sided, it’s too long. Your cover letter should be even shorter. You either have information that is no longer relevant, or you’re purposefully padding it. Either way, you’re lying to me, and we’re off to a bad start.
  • Looks nice! Your resumé should be easy to scan for highlights, with lots of appropriately sized & spaced type. my 2 page rule does not mean I want 2 pages of single-spaced, 8-pt type all across it. Layout proves to me you understand the basics of presentation & user experience. At this point, I’m the most important “user” of your resume, so help me out .
    update: Mark Busse points out, quite correctly, I suspect:  ‘In the communication design profession, resumes are basically dead. NO designer gets hired using a cv—even a gorgeous one’.
  • Error-free! I may be extreme on this one, but I will discard your resumé out of hand if I see a single typo or grammatical error. Same goes for a cover letter. I don’t care if English isn’t your first language or not. Errors on these tell me a few things:
    1. You’re not detail-oriented. Programming & Design are both all about sweating the details. A typo tells me that you’re not attentive to detail.
    2. You’re satisfied with “close enough”, which, to be frank, is not good enough. If you don’t care enough to impress me, how could I ever trust that you’ll care enough for our clients?
    3. You’re not willing to ask for help. This is a group environment where you won’t always be the expert in everything. If you won’t ask someone to help make sure your resumé & cover letter are perfect, you probably won’t ask for help when figuring out that algorithm either.
  • Professional! If your resumé is on blue paper with spaceships in the background, or is scented, or anything “gimmicky”, I’m not interested. This just says to me that you don’t feel your qualifications will speak for you, so you want to trick me into checking into you. Not true. That being said, I’d love a colophon explaining your typeface, paper, etc – the rationale for your design decisions. Using your personal letterhead is also fine, if it looks professional (so if your personal brand contains rocket ships, that’s fine).
  • URLs! This is pretty industry specific, but I expect you to have an online presence. I expect to see your twitter, facebook, blog, linked in, youtube, whatever profiles listed (or at least a path to see all relevant profiles). We work on the web. If you don’t use the web in a contemporary way, why should I believe you understand it at all? Along those same lines, you better be sure that your online profile is suitable for a potential employer to see. Your online profile consists also as a way for me to rapidly assess you for how you’ll fit into our corporate culture.
    update: to clarify – I’m not looking for a specific service, or that it is “clean”.  I’m looking to see is evidence of use/understanding of social media & online interactions. Also, this is the perfect way to show me examples of your work along with rational and process decisions made along the way. Wrote some awesome code? where’s the post on it? Particularly proud of a logo you designed? Write about it!
  • Not a form letter! I understand you might be sending off hundreds of these. But if your cover letter doesn’t include some specific references to my own company, our work, our clients, etc, I don’t believe you really want to work here. And I only want to hire someone who actually wants to work here as opposed to just get a job, anywhere. And this is the prime role of your cover letter. To convince me of your interest in working here, specifically. Your cv does the “get a job, any job” part.
  • LinkedIn! Also pointed out by Mark Busse (follow him, he’s smart: @markbusse) is this: ‘Good advice, except why have a resume at all when LinkedIn exists?’ I’m totally down with just being sent a link to your LinkedIn profile instead of a resume. This goes very well with the URLs! idea above.

That’s my advice for resumés & cover letters. Pretty straight forward, I think. While I’m on the topic, here are some criteria that over the years Jeff and I have evolved to see as must-haves in a potential hire:

  • Degree or equivalent: Having a degree tells us that you can stick with something long & difficult all the way to the end. You don’t quit at the 90% mark. What your degree is in is somewhat irrelevant, but having successfully completed something as demanding, time-consuming and protracted as a degree is a must. This tells us you likely know how to handle the stress when push comes to shove and you have to fight through problems to finish a project.
  • Team experience: This one might be controversial: We’ve recently decided that we only want to hire people who have played team sports or other otherwise played a part on a team with a shared goal (and distinct from working elsewhere with others). The reason for this is simple: This is a small, close-knit company. People who have played team sports understand the importance of team-building. Also, understand what “take one for the team” actually means. I’ve worked with people who fundamentally do not understand the meaning of teamwork, regardless of what their experience is – and this has been detrimental to everyone else on staff.
    update: to be clear, I want evidence of experience in working as a team – not just in sports: Band, theatre, debate clubs, whatever. I’m not looking to hire jocks – I just want to know that you truly know what “teamwork” is, outside of the required team project you likely had to do at school.
  • Obvious Social Skills: given what else I’ve written on this site, and that we’re a software development house, this might seem odd. Aren’t software developers known for having the eccentric genius on staff that no one understands but can throw out perfect code all day every day? Yes – but not where I work (except for me? ;). If I hire you, I will likely spend more time with you than virtually anyone else in my life except for my wife. So I have to believe that I will enjoy that time. And that my other staff will enjoy that time. And that my clients will think positively of us after interacting with you. Otherwise, what’s the point?

So there’s my initial thoughts on things to think about when writing resumés, cover letters and presenting yourself. I think a take away is that all of these add up to be your personal brand, whether you are conscious of it or not. So start being conscious of it. These are all the intangibles that crystallize into form the moment I finally interact with you in person and we start the interview.

(final aside: You might note, quite correctly, that this blog is rife with both typos and grammatical errors. But you know what? This site isn’t my cv, it’s my thought playground – it’s not meant to be perfect, just a place for me to think out load and interact with the world at large in a casual setting – and that’s ok.)

%d bloggers like this: