Negative User Stories and Email Subscriptions

Share
Reading time ~ 3 minutes

When I first joined Red Gate nearly 4 years ago my first major project was working on a replacement system for managing marketing and transactional email for our customers.

Yes – email marketing – and boy did we suck!

Back in summer 2011 I kicked-off some team research, analysis and story activities on one major enhancement we wanted to develop – “Subscription Management”.

This sounds pretty straightforward right?

Hell no!

This is a sensitive area involving a series of tensions between international compliance & standards, good end-user experience, the working lives of a marketing team and ultimately the reputation of the company.

Let’s put this into context of a few major groups of users (this is just a subset)

1: The “Customer”

I bought your software once, I pay my annual support & maintenance, I’m reasonably happy with what I have. Let me know when there’s a free upgrade or my renewal is due but don’t sent me any more damn marketing or I’ll report you as a spammer.

2: The “Tourist”

I attended an event sponsored by you at some point in my life and since this I seem to sporadically receive mails from you or one of your affiliate companies. I’m interested in the community stuff and freebies so I might read some of the mails you send but if they’re not directly relevant to my interests I want to get off of whatever list/sub-list I’m on fast.

3: The “Fan”

I bitched about your company when you acquired a free product and turned it into a paying one but I’ll concede you guys have done an awesome job and I already used a few of your other tools anyway.

I’m always on the lookout for things that make my life easier and I’m not averse to finding out about the new developments you have in the area I work in.

If you send out something interesting I’ll even share it.

These people are worth looking after & listening to but they’re a fickle bunch – use with caution.

4: The “WTF”

How the hell did I get on this list? I’ve never heard of you, stop sending me spam!

It turns out they attended an event or downloaded some freebie from an affiliate site an their details found their way into the system or into the hands of a marketer who moved project, role or teams but kept their contact “because it was closely related”.

5: The “Prospect”

Yup, that’s right – you might actually be sending mails to real prospects!

What are they trying to achieve right now and what’s the most useful thing you could offer them?

If that’s not in the mails you’re sending, expect an unsubscribe. Staying in there inbox “to keep them aware” is probably not going to improve their opinion of your products.

6: The Marketer

I’ve been sending mails to this specific subset of the company-wide install base for years. I have my campaigns carefully planned with content, timings, massive target audience etc. I’d love to see the campaign convert into direct revenue but I’m more interested in getting it out of the door as one small part of my overall marketing strategy for the quarter.

This should be the easy bit, right?

What do you mean everyone unsubscribed because half a dozen other marketers hit them with irrelevant stuff over the last month as well?

 

Yup. That really used to happen here.

So the great thing is that with a little research, designing a great user experience around email subscriptions is surprisingly easy. There’s a basic set of users with competing and/or overlapping needs but more importantly. When someone doesn’t want your marketing mails, that doesn’t mean they hate you. It’s not a break-up, it’s not the end of a beautiful relationship, it’s simply someone asserting their needs.

So many companies manage to screw this up because they focus only on the needs of the marketer.

Make opting out a positive experience and chances are if a contact has a reason to talk to you (or someone like you) again they’ll be in touch. If they don’t – well, there’s no point in them being a contact still, right?

Spend a bit of time thinking about the more negative interfaces your customers, users and prospects have with your company.

What small steps can you take to raise the bar on these?

Take It Off-Site (Part 1) – The Bad and The Ugly

Share
Reading time ~ 3 minutes

Offsite meetings have a checkered past. Back in 2006 a colleague shared this painful article with me.  To quote from the main article:

“…only about 10 percent of executives consider offsites truly valuable. Half said they aren’t worth the time or money.”

Over the last 7 years I’ve seen the exceptionally high value offsite meetings can bring but also the stress and pain that often leads up to them.

At my last employer, the entire global executive and senior management team would have a 6-monthly operations review offsite that ran for 3 days. We booked out significant portions of a large hotel in the US and fly the entire team together from over a dozen sites around the world. Over 3 days, the leaders from each site would present their statuses, finances, roadmaps, portfolios, visions, strategies and plans to a group of about 50 of us. We’d put them under the grill and review their work in depth both as bosses and peers.

We’d take time to focus on specific strategic issues that benefitted from face-to-face focused collaboraton. (When your management team are distributed around the world. A few intense days of co-location often delivers far more decisions and clarifications than 6 months of project work and conference calls.)

The general approach for these was: Prepare, Pitch, Review, Collaborate, Revise, Re-pitch.

Sounds pretty sensible? – It is…        … if you know what you’re in for. 

The offsite workouts were usually brutal but exceptionally valuable. By the end of the week everyone’s plans were in far better shape, we all understood what each other were doing, found areas for shared benefit and made a lot of difficult decsions.

Better still, we spent a few days working, eating and drinking together. 3 days of deliberate convergence in order to stem the behaviour issues associated with extreme divergence kepts us functioning as a successful management team.

Whilst the outcomes were great, they took their toll. The pain behind the scenes generally involved a bunch of us working 2 weeks of long evenings and weekends to pull all the data, presentations and spreadsheets together. ($100m of software projects contain a lot of moving parts & data) Often we’d still be revising our work during the start of sessions and whoever went first bore the brunt of painful lessons and questions whilst everyone else frantically updated their slide decks to accomodate the new knowledge.

And here’s the thing – the lines of questioning…

Our Senior Exec at that employer was an exceptionally sharp, experienced, bright guy. After working through multiple iterations and having joined the operations team on the organizing side of the offsites I saw what made him tick. He had a brain full of powerful questions that he’d learned from experience and was constantly adding to them. He knew what to ask and when that would lift the lid on just the right barrel to find a body (if there were bodies to be found).

As a spectator, sometimes it’s satisfying seeing the blood on the floor when someone you think is an ass-kisser takes a roasting. It’s not so fun when it’s your own team.

I even helped develop a set of “difficult questions” for our Head of Operations in the weekend prior to one of these offsites. They were great questions to ask. The thought and effort put into developing them was a lot like spending an hour writing test cases up-front. We learned quickly what we really needed and wanted to know (and why). We were confident we could get under the covers of even the most prettied-up project report.

But we could have made the whole thing so much less brutal.

Much like writing test plans, if we’d just put the questions out for participants to review in advance they’d have adjusted their research and reporting to accommodate them rather than playing project question battleship on the day.

So here’s an action for you.

Next time you’re reviewing a project or a piece of work, capture the questions you regularly ask.

Now…

Share them

Share them with the people you’ll be asking beforehand.

Now they can answer those questions sensibly first and you’ll all have time to dig into more valuable insights.

I have a few more posts planned around “critical questioning”, plenty around running offsites and I’ll be sharing where I’ve been for most of the last year so keep your eyes open for more soon.

 

Still Alive!

Share
Reading time ~ 3 minutes

First of all, I’m flat-out at work right now on recruitment and running a challenging project so here’s a plug for some jobs…

We’re looking for 3 amazing Agile PMs here at Red Gate. If you think you’ve got what we need and fancy working with me, please dive in and apply.

[edit] – actually we’re hiring for more than a dozen different roles you might expect in a software company! – Take a look at the rest too.

Second. I’m currently supporting part of the SQL Source Control development team here on a rather challenging technology refresh project. We’re planning to ship an Alpha soon to validate our technology decisions and then press ahead with completion and new features. I can’t say much more about this at the moment but despite being relatively small by most company standards, it’s one of the trickiest projects I’ve ever inherited. Once we’re successful, I hope to write more.

Finally – back to the title…

Forgive the Portal reference but for the last few months I’ve been using my spare time coding a game.

If you’re of a certain age (like me), you may fondly remember hours of bashing away trying to solve puzzles and guess verbs in black and white (or green screen) dungeon/text adventure games.Minimum viable text adventure game screen

I grew up coding on a BBC micro and developed an early love for interactive fiction. It’s now a pretty niche area with some amazing games.

Whenever I want to learn something new, I need a goal – something concrete. So I decided to write my own but using slightly more modern technology. If you’re interested in why, see my last post.

Progress has gone really well and I think the results so far have some promise. There’s a few unique aspects of the game in comparison to the more old-fashioned equivalents. Essentially, the games characters and scoring are somewhat more dynamic and based much more on the actions of you as a player. I won’t spoil it but if you have the patience, give it a shot at: http://mvta.herokuapp.com/

Whilst not “finished”, it is live and that’s an achievement in itself.

I reconnected my developer empathy circuit, thoroughly enjoyed going back to coding and managed to learn some new skills on the way.

A few nerdy highlights…

  • I’m really impressed with Heroku as a hosting platform. I managed to go from zero knowledge to live and running in under 2 hours – including restructuring the codebase and packaging in order to support heroku deployment.
  • I had to get to grips with NoSQL  much sooner than expected. The original saved game data was filesystem-based but Heroku offers no filesystem support so games are now saved in a hosted Redis data store. This also gave me the benefit of painfully relearning use of binary data streams and debugging third-party libraries (developing on Windows vs production on Linux). It turned out that by default, the nodeJS Redis library is somewhat buggy on Windows as it drops back to a javascript parser. On Linux it uses a C library.
  • I’ve come to love Github for source control and got to grips with a modern IDE (Visual Studio) having last used Eclipse back in around 2007!
  • I’ve learned to value real user testing and usage reporting. A large part of the game usability came from observing the attempted and failed actions of users playing the game.
  • I’ve really boosted my nodeJS and javascript skills although the JS itself is still largely poor OO rather than dynamic.
  • I still prefer writing business logic over coding the “plumbing” but did occasionally have to drop back to some old-school computer-sciency work to achieve what I wanted.

Most importantly, whilst it’s a well-tested and working game and engine, I built a nasty legacy codebase that forces me to resort to writing tests and reworking/refactoring whenever I want to add something new and facing the pain of missing tests and regressions as I go.

I’ll continue updating the content over time but please dive in, have a play and waste a few hours.

Oh… and post comments here if you need “guess the verb” type hints or clues!

Cheers for reading!

Simon

 

Back to the Technical Stuff (or “Why so Quiet Cap’n?”)

Share
Reading time ~ 5 minutes

5 months since my last post. What’s been happening?

Lots!

A recent entertaining high point was this photo of Alberto Brandolini‘s (@ziobrando on twitter) lightning talk at XP2014 going viral. Alberto Brandolini at XP2014 (Rome) It’s still doing the rounds on twitter 2 weeks later so if you’re here because of “that photo”, thanks for stopping by and don’t forget to congratulate Alberto! Sadly most of the content on here – whilst hopefully interesting and insightful – probably won’t have the same mass-appeal. Back in the day-job, I have 3 irons in the fire at the moment.

  • Build & cycle time
  • Agile staff development
  • Rebuilding my “developer empathy”

Build & Cycle Time

I’m working with two of the function heads at Red Gate on a project to improve our build and test cycle times. Chris and Jeff are doing all the hard work directly with the teams, I’m just offering support, guidance and occasional prods.

In the last 6 weeks they’ve managed to reduce the amount of processing on our build servers for one of our major products from 56 total hours (requiring a total test run duration of nearly 15 hours) to 10 hours processing, ~30 minutes total run time and a build time reduction from 40 minutes down to 6.

At the same time they managed to get all the tests back to green and fix the hidden bugs they were masking (just 3 luckily). Somewhat embarrassingly, this was a first in over 5 years). This has had an amazing positive effect on team morale and Chris’ visualization of status has really upped the game for all teams in the division. Chris' LED buld lights The team’s best run so far without a broken build or failing tests was a week but this time when things failed, they were fixed and re-tested in under an hour, not left for the next “overnight”.

That’s a major shift in behavior for us and means we can now be much more responsive in turning around customer issues too. The knock-on impact of this on all other projects is probably even greater.

Other teams are benefitting from a build queue that actually has free slots during the day (previously unheard of) and overnight runs that are significantly quicker due to the reduced load on infrastructure.

This is all part of a major push by our team to crank up the effort on our technical issues here. We’ve got agile project processes running to a level where we’re happy and continuous improvement is culturally part of every PMs daily life but we’d not focused on the technical side, XP practices and development culture so much. Until recently our teams had done “pretty well” with brute force and intellect but many hadn’t seen what “really good” looks like for a while. We’re fixing that :)

Agile Staff Development

This is where most of my time’s been going. I’ve been working closely with Brian, our head of Tech Comms to roll out training on our new “personal development planning” workshop and tools to all our line managers in development. This is the culmination of the work I wrote about back in September last year following a successful pilot.

We’ve overhauled the skills part of this area as a team with some great design assistance from our head of UX (Marine) resulting in a skills map for each of our main development roles.

Project Manager Skills Map

We’ve developed a half-day training course where participants explore the materials and gain a deep understanding of the concepts, goals and challenges and then actually do the personal development workshop itself as deliberate practice – with one participant leading and one participating – before unleashing their new skills back with their teams. We’re documenting much of our work at http://dev.red-gate.com/skills/  and have made our internal skills maps available under an open source license for others to adapt the concepts for their own use.

We’re now at the point where all development line managers have been trained, about half of our development staff have development plans (and are actively tracking and maintaining them) and we’re now looking at how to both make this scalable, sustainable and expand the next phase of the project to cover non-development roles.

There’s been a real buzz about the skills maps in particular outside Red Gate so we’re hoping to take these concepts out to a couple of conferences toward the end of the year.

 Rebuilding my “Developer Empathy”

Related to our technical push around the build and cycle times, I found that after too many years away from the technical coalface I was becoming somewhat jaded towards what I perceived as a lack of technical discipline from some of our developers. I needed a mental reset. Starting out with the premise that we hire great, motivated people who care, I needed to understand what it was that would make someone with the best of intentions fail to write and maintain unit tests, develop poor quality architecture and allow a codebase to fall into disrepair.

You see when you look at it like that, something else must be amiss.

Rather than simply looking, I’ve decided to do it myself. So in the last few months, in early mornings, lunchtimes and evenings I’ve taken up (simple) coding again. I’ve taken a domain I know well (text adventures) a project I knew I’d enjoy (writing a new game) and started deliberately building up a legacy codebase. Whilst trying to use at least some basic object concepts (in JavaScript), I’ve not used SOLID principles or composition (In my former Java life I generally avoided inheritance in favor of interfaces/composition), I haven’t written tests first and I’ve written some quite complex methods without tests.

3 months later I have a rather neat game and engine, a nasty codebase. 150 tests (all passing) where I should realistically have more than 1500 and amongst the full set of classes, a small number of 1500+ line “god classes”. I found myself repeatedly “play testing” new features rather then writing tests, blurring the boundaries of responsibility across objects and occasionally rushing work so that I could “get home” or switch back to my day-job.

I’ll write about this in much more detail in future (and will try to find somewhere to host the game) but in summary, I’ve reconnected my empathy circuit. There are many reasons why we don’t work at our best on legacy codebases. I don’t always know how we get there in the first place but I can see why we fail to dig ourselves out.

In short, there’s just “too much to do”. And so… Back to the big rocks and the oubliette.

What Are My Needs as a Hiring Manager?

Share
Reading time ~ 5 minutes

Inspired by a twitter conversation with Bob Marshall, Marc Johnson and Nicole Rauch.

What really are my needs when I’m looking to hire someone onto my team or organization?

This article is a great start on interviewing and the goals of doing so. (whether or not you agree or disagree with the content)

In particular, understanding :

  • Can they do the job?
  • Will they be motivated?
  • Would they get along with the team?

I have to admit that’s a good summary of my needs – I’d add “Will they fit with the way we do things as a company?” as well.

What about the needs of the person applying?

Well there’s the whole safety, security Maslow’s hierarchy of needs type stuff for starters. There’s also Dan Pink’s work on Drive
“. Mastery, Autonomy,  Purpose. Jurgen Appelo is doing some amazing stuff around this at the moment too but…

At the end of the day, this is a 2 way relationship. If neither of us will find our needs fulfilled, it’s just not going to work.

Incidentally we’ve found from talking to all of our teams recently that trust, respect, peer recognition, support and self-fulfillment are pretty key.

Chapter 1 of “Love ‘Em or Lose ‘Em” has some great research on what makes people want to stay in a company that’s worth a read.

Before we even get to this point there’s a bunch of work to do though.

At the moment I see hiring as a funnel type of workflow with iterative filtering:

  • Attract Candidates (Advertising, headhunting etc.)
  • Perform an initial filter (CV sifting) to develop a shortlist to invest in further
  • Filter again (Telephone Screen) to get beyond the introduction and get a “feel” for capability, personality and salary/role expectations (both ways)
  • Filter again (1st interview) to check capability
  • Filter a final time (2nd interview) to check motivation & team fit (both ways)
  • Make a decision – offer or reject
  • Nurture to start date
  • On-board with team & company
  • Review progress/probation – is the relationship working out (both ways)

Note, this is just one example – I generally see the hiring process continuing through to being a successful, happy team member with a happy team.

I’m writing this post quite hastily but if we look at that flow, there’s a value stream in terms of effort and cycle time per candidate and also a funnel at which points candidates “drop out”. There’s a lot of effort, a lot of waiting and a lot of waste. I truly think there could be something better but I’ve not tackled the problem yet (and perhaps that’s part of my problem!)

Here’s the first challenge I face…

As a hiring manager, my time is at a premium. I’m usually trying to do at least one other job at the same time as hiring (usually running  a project and team) and often working on other “hidden projects” such as improving the way parts of the organization work (including adjusting and learning from feedback on the hiring process itself and the types of candidates we’re getting through).

On top of that, it’s really hard to attract the “right” people – back to skills, motivation, team & company fit.

Our first port of call in most cases is a covering letter and CV. Sometimes we start with an introduction or conversation but eventually we usually go back to a CV.

We’ve hired most of the people we already know are good that want to work here (location and company-wise), that we can honestly afford and are available. (Being based within an hour’s easy commute of London means competition for good people is tough). So most remaining applications come from strangers.

If someone’s a stranger, how are they able to catch our attention (in a positive way) to make it clear to us they’re worth engaging with, spending our limited time getting to know and developing a positive relationship with? Particularly when there may be dozens (or in my last company, hundreds) of others competing for that same attention. This works both ways – how do I get your attention too?

For my current job, I developed an early relationship through reputation first but at the point we decided to formalize things, I was still happy to present my CV. I’m proud of what I’ve achieved and earlier conversations could have missed things that were relevant and valuable. In my case this was particularly true. I worked on CRM and order management systems early in my career and the conversations I’d been having so far weren’t around this area but it turned out this experience was really valuable to them. We wouldn’t have made that connection without my CV.

If someone approached us without a CV as a total stranger we’d have no idea what to expect it’s a gamble as to whether we’re dealing with someone we really want to know or not and realistically the little time I have for hiring isn’t an area I choose to gamble blind. That initial “Yes/Maybe/No” that I can get from reading a CV is a lot quicker that talking to every single person that applies to figure out what they can offer that’s relevant or valuable.

Similarly, job specs are like CVs – would you apply for a job with no spec? How do you know what’s expected of you and whether you’re a good match?

So, my needs – assuming you’re a stranger…

  • (Without being a stalker) Seek me out, get in touch, say hi, invite me to stuff, find a way to get to know me and start building an interesting professional relationship.

OR

  • Make it easy for me to get you through that first sift of candidates with useful, relevant stuff.
  • Make it clear what your motivations and skills are, how you work and what sort of person you are.  I don’t hire assholes and I’m pretty wary of “Alphas“.
  • Link up what’s on your CV to what I’ve said I’m looking for but please do share the other cool stuff you’ve done – you might have useful experience I’ve not even considered.
  • If you’ve done cool things that are publicly visible and don’t need me to do a mountain of digging, point me at them. If the rest of the CV is interesting, I’ll go and look.
  • I won’t have time to read your twitter stream, blog, Stack Overflow activity, Github check-ins and Linkedin profile unless I’m already interested in you. (I don’t do Facebook) But if you’re interesting, I assure you I’ll look for you on all of these.
  • Don’t over-inflate or lie. It might get you through the CV screen but when I find out you can’t back it up later you’ll just piss me off.
  • Show me real evidence of what you’ve achieved and how. I can’t stand all theory and no results. But if you have a love of the theory, show me how you’ve applied it and made a difference by putting it into action!

I’m sure there’s more but this is plenty for now.

What are your needs when you look for a new job and how do I get your attention?