Killing a project early. Another game design story.

I spend my evenings designing and making games and so far I’ve finished two of them. One board game, and one video game. It’s fun showing people the finished products, but as each of these games took more than a year of my evenings to complete, I thought it would be nice to document and share some of the things I’m doing and learning as I go. Otherwise it’ll be a year before you hear from me again. And in this particular case, it’s a project that will probably never see the light of day – as I’ve decided to kill it.

After shipping CAAARGH, doing a little bit of zero-budget marketing, and taking a couple of weeks rest from working every evening I was itching to start on my next game. I have a backlog of designs ranging from CAAARGH scale projects (equivalent of about three months full time work) through to projects that would need many people and much time and far too much money. And I wasn’t ready to commit to one in particular yet.

Then I saw an email from the Game Crafter, mentioning a couple of new design competitions running on their site. I decided to look at the Minion Games competition to design a dice game for the Manhattan Project series of games. The scope was reasonable. The deadline was close enough to focus me, but far enough out that I could get something together and do a few play-tests and design iterations.

Also, I’d been dipping into Reiner Knizia’s Dice Games Properly Explained, so had been toying with some dice mechanics in my mind and thought this would be a good place to try them out.

The existing Manhattan Project games pride themselves on having low-luck mechanics which I thought could pose a challenge for a primarily dice driven design.  The angle I thought could make this work would be to focus the gameplay on the people of the story (as people are individually unpredictable, but mostly predictable as a group).

The loose design in my mind was that you would use the dice to hire people, and other dice to apply their skills towards building weapons, and then use agents / spies to compromise the hired people to learn the location of weapons, which in turn could reduce their final threat level / score. Or something like that.

I’d been trying to keep short notes about what I worked on each night, with the intent to write more blog posts like this. Some nights I do 30 mins work, some nights it’s a couple of hours. But it’s mostly progress by lots of small steps.

15 June

  • The blank dice I’ve ordered arrive in the post and I start playing with components and sketching cards.
  • How can constructed weapons be linked to an individual scientist / engineer?
    • All constructed weapon cards have to be placed on an engineer or scientist to identify their knowledge of the weapons location
  • If the knowledge of the weapons location is linked to individual, it encourages players to hire more people to distribute their risk
  • If some scientist has more skills and a player risks them having much knowledge, how can a player protect them? How can this come with a risk / reward mechanic?
    • What if you can sacrifice an agent to try and prevent a compromise? But roll of a dice determines if you are successful?
  • Can the back of the agent card double as an icon to show someone has been compromised
  • Can a compromised person still contribute to new weapon construction? Maybe yes, but it affects where you can place the cards
  • How to make different scientist / engineering cards interesting and worth considering?
    • Idea: Each comes with a number of skills and dice powers – or a dice roll needed to unlock
  • How to get risk reward into the play?
    • Maybe need to declare which weapon they are trying to build before rolling

17 June

Looking at some basic calculations to work back from competition brief to think about possible number of cards and dice

Max play time
60
Turn time
0.5
Total turns
120
% of time spent building weapons
50%
% win rate for building weapons
50%
Max weapons everyone can build in a game
30
Weapons built per player (in 4 person game)
7.5
  • In a typical game you should expect each player to build up to ~7 weapons cards
  • This gives us an idea of how many staff each player would hire, if weapons are assigned to staff in some way. Approx 5.

18 June

  • Looked at possible distribution of Victory Point values across weapon cards
  • Assuming a threat value and a defensive value gets to an idea of relative cost
  • This can later be used to work out probability for dice combos per card
  • Also realized that the Manhattan Project era is earlier in the nuclear arms race than I was picturing in my head
  • Weapons probably need to be variations of atomic bombs rather than subs / facilities etc
    • Need to research categories and ratings – e.g. Mega-tonnes
  • I also found the rules for the main Manhattan Project game which gives a better understanding of the universe and the tone: http://www.miniongames.com/rules/Manhattan_Project.pdf

19 June

  • Picked some starting points for number of cards and number of dice to use in the game
  • Working back from the target playtime, this ends up being smaller than it maybe was in my head
  • Currently at
    • 30 VP cards
    • 26 people cards
    • 17 dice
  • Might also end up with the people forming a single deck for hiring from, rather than one per class as the total number of cards available is small
  • Pretty happy with the hiring costs and hiring die calculations, but need to work out how those relative strength scores map to fair abilities to gain victory points

20 June

  • Worked out a system for turning dice rolls into building / purchasing power in an interesting way
  • Now need to work out how to balance this systematically WRT to purchase / value

21 June

  • Debated trying to balance the cards using brute force software iteration, or building up the values from a spreadsheet
  • Built a spreadsheet that lets me evaluate the value of individual staff cards in relation to the VP cards, but not sure if I’ll need to do more to get this to work with combinations of cards. This might be enough with some eyeballing of combinations.
  • Need to plug in more values now and work out how to turn these scores into hiring costs

22 June

  • Allocated skills to scientists cards
  • Decided we need 16 (10 jnr, 6 snr)
  • Used these to calculate probability of each card scoring against each symbol combination
  • Used the average likelihood of scoring a given combination to assign values to each combination
  • Decided to use 2 of each possible combination to create 30 science halves to the bomb cards
  • Multiplied the value of a combo by the likelihood of each card getting it to create a per combo value for a card
    • Summed these, and normalized them against a scale of 1-4 to create a hiring cost
    • Tweaked some card values to get a better distribution of hiring costs across the pack
  • The combined score of this with the engineering equivalent will give the total card score
    • These will need to be even combinations to
  • Added some non-scoring variants / impacts to the dice

23 June

  • Worked on the card variations for the engineers following the balance model used for the scientists
  • Did some spreadsheet jigery pokery to get the balancing view of the data into a simpler format for CSV export and use with nanDECK
  • Installed nanDECK

25 June

  • Read the nanDECK manual
  • Got the data from my spreadsheet hooked up and started learning how to layout the content
  • It’s pretty great how quickly it turns data into a printable set of cards for prototyping. Would have saved me a few nights of work spent on Moving Out card testing.
  • Also, it’s so quick to make changes that I think it will support quicker (and therefore more) playtesting and design loops

26 June

  • Fought with nanDECK syntax
  • I’m sure it can work, but it felt like too much effort
  • Trying to use Squib instead but fighting with installing Ruby versions on Windows

29 June

  • Squib is up and running
  • Setup git repo and project directory etc
  • Worked through some examples to get a better feel for how Squib works
  • Being Ruby based there’s no new syntax for me to learn, and the documentation is really good.

1 July

  • More Squib learning
  • Setup data, basic layout and some card background colours

2 July

  • Get some icons rendering dynamically on the science / engineering cards
  • Choose 8 icons for initial playtest (using game-icons.net)

3 July

  • Finished reading the excellent book The Art of Game Design and was playing with the Deck of Lenses app as a way to review the design so far.
  • Got to The Lens of Love
    • Do I love my project? If not, how can I change that?
    • Decided to think about this

4 July

  • I like a lot of things about the mechanics, and I think this could be turned into a viable commercial game fitting the design brief. But I was still pondering the question. Do I love my project?

5 July

  • North Korea tests a new missile, and it dawns on me I don’t want to spend my evenings designing a game playfully themed around building Nuclear Weapons
  • So I stop.
  • That’s not to say there shouldn’t be any games about this.
  • There are already many, and some are especially good. And games can be a great way to teach people about nuclear proliferation and dynamics of power and so on, but that’s not what I’m motivated to do in my free time.

6 July

  • Write this blog post.
  • Start on the next game.

Caaargh Game Development Blog #3 – Complexity from Simplicity

In my last post a few weeks back I was pondering whether to add more complex track segments to the game (Caaargh!) as a way to make more interesting tracks. It must have been a good question, as it’s kept me occupied for the best part of a month.

In the end, I found I was able to generate many more, more-interesting tracks by making the component pieces even smaller and simpler than they were before.

Example of old style track pieces
Example of old style track pieces above
new_style_pieces
New style track pieces are much smaller

As part of this process I updated the scripts that generate these tracks to work with arbitrary directions and angles which also freed me up to use vertical space as well as horizontal in the game. This means tracks can now cross over themselves in interesting ways.

Track's can now vary in height
Track’s can now vary in height

There was a bunch of new modelling work to-do, and I can’t overstate how much I’ve been enjoying using Sketch-up to make these. It’s such a human friendly piece of software given what it can do, and it exports nicely enough to .fbx files to work with in Unity.

sketch_up_deadend
Modelling a deadend segment in SketchUp

The new track modelling work has let me fix up the aesthetic and practical (in game physics) issues that were bugging me with the original track pieces, and at the same time make the track a bit narrower which better suits the single-player game-play.

Here's the car relative to the track
Here’s the size of the car relative to the track

Here’s a quick sample of generating a bunch of random tracks of a specific length.

track_generation

There’s still plenty to tweak in here, but the next design decisions about tracks can’t properly be evaluated until some of the other game mechanics are in place, and what’s here goes through some more play-testing.

Also, banked corners looked fun, but didn’t play well. Sorry banked corners.

banked_corners

Caaargh Game Development Blog #2

This week has only seen a little time spent on Caaargh, but I’m trying to keep this blog updated, so here goes.

This week I’ve mostly been thinking about the segments of road that make up the race track in the game. To prototype the game and get the development started, I’ve been working with a collection of models bought from the Unity Asset store.

capturea

These got me off to a quick start, but are actually causing some of my biggest gameplay bugs right now and visually I wasn’t totally happy with them.

Visually, I don’t like the fact that the track edges don’t have any depth to them. They end up looking like sheets of paper stuck on the edge of the road. Also, something about the way these were modeled means the road surface and the edge don’t join perfectly so you see a slither of light through the road, and it shows up annoyingly in the shadows these cast onto the ground below. See below.

capture

The road/track shadows might seem like a minor detail given the other major work this game needs, but in Caaargh these shadows are one of the few visual clues that help the player ‘see’ upcoming corners given the deliberately restricted camera view. They also help the player orient themselves in the world after turning many corners. So I decided I needed to fix or replace these track segments because the shadows are important.

From a gameplay point of view, the edges and angles of these tracks were also causing occasional physics based chaos with the car getting stuck, or flipping in ways that weren’t very satisfying for the player. By building new segments myself, I can tweak these until they work just right. Or at least take the blame if they don’t!

Now though, I have a new game design challenge to think about.

The size of these original segments were pretty uniform. E.g. the lengths and widths of each segment were always 16, 32 or 64 units and if they rotate it would be 90 degrees exactly. These could be combined in interesting ways, but essentially created a certain style of track.

E.g. here’s an example when I click the generate random track button…

track

Now that I’m building new segments myself, these can be any size or shape I might want. This could be a good thing, and more interesting segments might lead to more interesting tracks, but it might also be too much. In this game you rarely see the track ahead, and you learn it by failing over and over again. If most of the tracks existence is in the players mind rather than on the screen, simple segments might be the best after all. I don’t know if 29 degree turns are a good idea or not.

capture3

So I’m going to have to test this. I also have to be careful not to the let this opportunity to add more complexity to the game slow down the development overall.

My gut feeling is that the track can be interesting even if the segments are simple, and that that’s more important overall.

capture2

For now though, I’m enjoying this 3D modelling work. 10 years ago, I used to know my way around 3ds Max, but these days Sketchup is doing the job just fine.

Sign-up for my newsletter here.

Caaargh Game Development Blog #1

I’m making a game called Caaargh, and I thought it would be a good idea to write a bit about the development as I go along. This is the first blog post to get that ball rolling.

Caaargh is inspired by one of my favourite games from my childhood, Micro Machines Turbo Tournament. In particular the experience of playing a four-player race, where the winner drives right up against the leading edge of the screen and gets very limited visibility of the track ahead.

In Micro Machines, the difficulty this limited camera view caused the leader created a beautiful balance mechanic that made multiplayer games so tense and exciting, especially when combined with the crazy tracks with plenty of places to crash if you forgot about an upcoming corner.

If you’re not familiar with Micro Machines, it’s worth watching a recording of a four player race see how this works.

After playing a lot of Micro Machines, you eventually race the tracks by memory. You remember what turn is coming up after the spilled cereal or the red cue ball, and you begin to steer before you even see it so that you can take the corner at full speed.

It is this second implication of the limited camera view that I wanted to play with as the core mechanic for Caaargh.

In Caaargh, the tracks become a series of memory puzzles. A bit like that kids toy game Simon, with the primary colours. But instead of remembering a series of colours, you have to remember a series of corners. And instead of pressing you buttons you have to steer the car.

Playing this way is also a bit like racing a rally car without a co-driver.

I’ve been working on this game on and off for a few months now and I think I’ve tested enough of the concepts to want to push this through to be a real game. So as I do I’ll try and write something on this blog at least every couple of weeks.

The latest news (for those people who’ve seen a bit of this story on Twitter already) is that I’ve decided to target mobile for the initial game release.

In the long-run I’m really interested in making this a co-operative local multiplayer game for PC and console as I think there are some interesting dynamics that will come from the mechanics that I have planned in a co-op setting. But I can also see a much quicker route to completing a nice single player version of the game that would be well suited to mobile. So that’s what I’m working on now.

This week I’ve been getting placeholder screens in places to manage the player flow from title screen, to level select, to level results screen etc. These are not visually interesting to share at this stage, but I feel good seeing the prototype turning into something that feels more like a real product.

That’s it for today.

Also, you should sign-up for my newsletter about my game design projects here.

My Last Week at Mozilla / Moving Out (At Last)

To those I haven’t yet had a chance to speak to one-to-one (there have been a lot of you!), this is my last week as a paid contributor to the Mozilla project. It’s also the week I finished and published a board game I’ve been working on for a year or so, called Moving Out (At Last).

It’s a misleading naming combo for this blog post title, but it made me chuckle, so I’m sticking with it 🙂

Whistler

To say my time at Mozilla has been ‘an experience’ would be an understatement. I will miss climbing mountains with friends and breakfast meetings where all participants are battling with remnants of glitter painted faces and recovering from wonderful conversations that had run on into the early hours of the same morning. Saying goodbye has been hard as this place is full of friends, but I also like change, and am excited about what’s ahead.

homeTo keep doing my job well at Mozilla, I would need to keep travelling, and probably travel even more. And while I miss my colleagues when I’m working remotely, I miss my family and my little kids even more when I’m travelling for work. For me, right now, I want to be in my own locale. In a part of the world I call home, and where I feel totally privileged to be raising my family.

There’s never a ‘good’ time to leave an organization you care about, but this is probably as good as any. The Foundation are gearing up to implement a new strategy that I think will make their work even more impactful and which makes the role of the Foundation within the overall Mozilla project clearer than it’s ever been. It’s been an honour to contribute to that strategy, and I’m excited for the work ahead. The nice thing about stepping out of an open-source org is no-one shuts the door behind you (I hope not anyway!?).

“Have your heart be where your feet are” (h/t to CLAW who shared this article with MoFo colleagues last week). This quote perfectly captures what I’m excited about for the next phase of life.

As of next week, I’m joining the wonderful agency Kyan in my home town of Guildford. I’ve known Kyan for a long time through their work, and their efforts to bring together the local developer community. I’m excited to be working with new colleagues in the same physical location and the same timezone. And excited to be learning some new programming skills while getting to grips with new development projects. I’m endlessly grateful for the things I’ve learnt travelling around the world with Mozilla, but I’m happy to be swapping planes for trains.

Rather than taking time off between roles, I’ve overfilled my upcoming weekend by signing up for Awesome Sports Jam. By this time next week, I may have shipped a bad sports game to compliment that board game. Mostly though, I’m enjoying being a part of this community.

Just as I finished writing this post, this song came on Spotify. I wasn’t looking for a song to include, but it fits. To my friends and Mozilla “thank you for the records”:

What’s so special about Networks?

This is a long overdue blog post, so it’s also bit long.

In the latter half of last year, as part of the work on the Mozilla Foundation 2020 Strategy and 2016 Business Plan, I was thinking about KPIs (Key Performance Indicators).

I think a lot about KPIs, and how the numbers you choose to care about either do or don’t influence the people who make day-to-day decisions about where to invest time, energy and money.

Many people have written much about KPIs, and the intersection of people and numbers is a fascinating place to work.

And in many cases it’s pretty easy to find a good KPI. Most of the significant ‘business’ decisions made around the world today will be mapping as directly as possible to some concept of Shareholder Value, or Gross Domestic Product.

But when your goal isn’t making money, or moving money around, it gets more complex (and usually more interesting).

Which brings us to Networks. In particular, the trickiest kind of network to measure – the ones made up of people.

16181710782_67731fa7bd_z

A significant part of the work we do in the Foundation is investing in communities of practice that are linked in various ways to our mission. These are amazing programmes, and the volunteers around the world who get involved are a huge part of our capacity to influence the shape of the world.

If you embed yourself in one of these communities, you see magical things happen. But as these networks get bigger and are distributed far and wide geographically, it’s hard to keep an accurate intuition of where things are going well, and where things need help.

To care for the network at scale, we need ways to track it’s ‘Vital Signs’.

Coming from a web analytics and fundraising optimisation background, this started out feeling somewhere between ‘very messy’ and ‘outright impossible’ to me. But the more I dug into existing work in the field, the more I realised we could do something useful here.

The question I’ve been asking myself is ‘how can we build a nervous system for our network?’ Something light weight, but capable of firing feedback signals and generating reflex actions. This frame has been helpful as I’ve talked to people about this work. We’re not at that point yet, but that where I’d like to see this work go.

So, onto what we’re doing right now.

Evaluating the impact of network building programmes isn’t new, but compared to other evaluation processes used by non-profits, it’s a younger field of work. We’re going to start by running network mapping surveys, and apply some Social Network Analysis (SNA) methods to analyse the results.

Where we might be doing something new, is trying to turn the ongoing process of network evaluation into an organisational KPI – by boiling down the constituent parts of the analysis to generate a single number we can track over time – allowing us to compare networks of different shapes and styles on a standard scale. I say ‘might be’, because it’s possible we’ve just not found the other people who’ve done this yet. Searching for content on Network KPIs usually ends up finding the ‘ICT type of network’ rather than the ‘people type of network’.

So, I have more to write here but for now I’ll share a couple of working documents:

 

Featured Photo Credit: Matt Gibson

Blog posts I haven’t written lately

Last year I joked…

Now, it has come to this.

9 blog posts I’ve not been writing

  • Working on working on the impact of impact
  • Designing Games in my free time
  • Moving Out (the board game)
  • Mozilla Foundation 2016 KPIs
  • Studying Network Science
  • Learning Analytics plans for 2016
  • Daily practice / you are what you do every day
  • Several more A/B tests to write up from the fundraising campaign
  • CRM Progress in 2015

But my most requested blog by far, is an update on the status of my shed / office that I was tagging on to the end my blog posts at this time last year. Many people at Mozfest wanted to know about the shed… so here it is.

This time last year:

Some pictures from this morning:

office1

office2

It’s a pretty nice place to work now and it doubles as useful workshop on the weekends. It needs a few finishing touches, but the law of diminishing returns means those finishing touches are lower priority than work that needs to be done elsewhere in the house and garden. So it’ll stay like this a while longer.

Software as means of changing the world

This is a thought piece as part of the Mozilla Learning strategy project. In particular it’s a contribution to the Advocacy Working Group who are looking at how we design a programme to have impact at a significant global scale as one part of an organisational mission to create Universal Web Literacy.

To be clear, this is an input into the strategy project, not an output. This may or may not be something Mozilla Learning chooses for it’s strategy, but I put my name down to write this piece as it’s something I’ve been thinking about.

I agreed to write ‘a paragraph or two’. It turns out I have more thoughts on this.

So I’ll start with the summary:

Point 1. We could choose to build software as a deliberate means of creating change
Mozilla is known for changing the world by building software. We have precedent for taking this approach and exceptionally talented engineers around the world want to play a part in this story (both as staff and volunteers). Building new software products is hard, but if successful can scale to have a disproportionate impact in relation to investment.

Point 2. We can create change via software without writing any code
Through partnership with existing consumer software products, we could deliver web literacy content/training/engagement independently of any software we build. This approach can also have a disproportionate impact to investment return. Can we be there to greet the next billion as they come online and create their first accounts / profiles / digital identities? What would that look like? Is that something we want to work on?

Both approaches are valid options for a strategy, but require very different execution. They are not mutually exclusive.

Longer Brain Dump

This rest of this isn’t entirely coherent, but I can’t spend longer on it right now…

Software as a means of changing the world

What is the role of software in an Advocacy strategy?

I’m going to argue that choosing software as a method for creating deliberate change in the world is potentially the most cost effective route to large scale impact.

Assumption: Software already changes the world

I’ve been thinking about this topic for a while, and want to start by directing you to a short post I wrote three years ago – Interwoven with bits – it distills a topic I could write about for days on end. We shape software, and software shapes us.

The software that changes the world takes many forms. A list of examples could technically include all software that continues to be used by any human being (directly and indirectly). But I’ll call out a few categories:

  1. Software as a direct and targeted solution to a specific problem
  2. Software as a delivery mechanism for ‘traditional’ advocacy and communications
    • Like this game from WWF whose pirate distribution through file-sharing networks actually generated much greater reach in target markets than a paid communications channel could have hoped for – while paid downloads in other markets generated funds
  3. Software designed as a ‘neutral’ utility but which has unplanned side-effects (good and bad)
    • This is pretty much all commercial software. Those that reach the biggest percentage of the global population likely have the most impact on the world. These are the systems we are addicted to, which change our behaviour through the creation of new habits and interactions with technology, society, and even with ourselves.
  4. Software as an ethical, political, or other deliberate consumer choice
    • Like choosing a freely editable wiki to power a website
    • Or choosing Linux over Windows
    • Or using software to hide your identity online
  5. Building software as an act of advocacy
    • By building it’s products in the way that it did, Mozilla changed the world directly and indirectly as an advocate for the open web. While the success of Firefox as a consumer product gave Mozilla a louder voice in many important forums, even the ‘smaller’ stories like the organising principles of community participation had an impact by changing public understanding of how an organisation could be run in a networked world.

Mass adoption

In general, when I’m thinking about how software changes the world, I’m thinking about how the mass adoption of a piece of software creates a shift in behavioural norms. The more successful and/or popular a piece of software is, the more likely it is to have more impact on the world.

For people who want to fix the world with software, it’s easy to look at ‘Silicon Valley’ success stories and get excited about building the next big thing. But in a sensible planning process these inspiring stories need the context of survivor bias.

Most software will go to market and die. The same is true of most inventions and artistic creations. The majority who try to build something and ‘fail’ are known as the “optimistic martyrs“. Most software dies in the market because the formula for winning is elusive, and even a well defined target market is actually a collection of complex busy human beings.

People who build software with purely good intentions about making the world a better place face an even bigger challenge – they don’t have the forcing function of the market to keep them focused. That’s not to say it can’t be done (see Firefox), but as someone who uses numbers to influence decision making, numbers with currency symbols next to them always get a more direct response.

Is software too big of a bet?

As an advocacy strategy, choosing software as a means of changing the world would be a gamble. Even with the best people working on it.

But software is interesting because of its relatively low cost of development and distribution. These costs don’t need to scale with success – they become negligible if a product reaches a mass consumer market. I.e. the cost to impact an extra person beyond a critical mass approaches zero.

Therefore, the potential ROI on software is enormous (thanks Internet!). But potential is a word that optimistically wraps up unknown odds.

There’s a good reason that successful start-ups that scale are called ‘unicorns’.

A Mozilla bias

At this point I want to reflect on a Mozilla bias.

I was drawn into the org through experiencing this bias at my first Mozfest – hacking on software in my free time as a way to try and change the world.

Many people work at Mozilla because they believe building great software makes the world a better place; myself included. This is Mozilla’s heritage and origin story. But it might not always be the best or only solution to a given problem.

Changing the world through software, without building software

This next piece is not to exclude the option of building software. But I’d like to approach this section as though Mozilla didn’t have its history of building products and as though it was a new org setting out to advocate for Universal Web Literacy using software as a means of creating change.

If you pick a particular goal, like helping the next billion new users of the internet who come online in a mobile-first capacity to understand the full scope of the web, what is the most effective route to success?

We’ve already been exploring how to build learning opportunities into Firefox, but what about partnering with the organisations who own many other front doors to ‘the web’. For example, if you create a Twitter/WhatsApp/Telegram/Other account in Bangladesh, can we work with owners of those products to offer a locally relevant and meaningful crash course to the web – covering everything from privacy to economic opportunity? Something that delivers on our mission, but also adds real value to the end-user and the product owner. How much effort would be required to make that happen? How many people could we reach?

Though I noted the example of the WWF Rhino Raid game in the list above, many well intentioned orgs have tried to create software like apps and games as a way to change the world without understanding the real nuances of product (games are possibly the hardest to get right). As an example of using the partnership approach, WWF have also run campaigns in existing successful consumer products via partnerships, like these in game experiences.

When I talked about this concept briefly on our last working group call, Laura flagged up that Tumblr directs users who explore their theme editor to online training courses run by General Assembly. This is the kind of partnership that adds value in both directions. Tumblr want users to build higher quality sites, and General Assembly want to educate people who have an active interest in learning about these topics.

Investment to Impact Ratio

After thinking through the points above, I’d advocate for ‘advocating’ with software; some of which we build, some of which we don’t.

The potential investment to impact ratio for a software product that scales is immense. But it requires a long-term product strategy.

I’d argue that good products typically last longer than good campaigns, and my view is that the most meaningful change comes from what we help people do repeatedly.

Software also offers a degree of measurability and accountability hard to match in any other line of work. If I were an impact investor, that’s where I’d put my money, for that reason. Though I definitely have a bias here.

This isn’t to say what software we should build.

Image source.

Thoughts about CRM, from Whistler

…and in the context of the Mozilla Learning Strategy.

Obligatory photo of Whistler mountains
Another obligatory photo of the mountains

Mozilla recently held a coincidental work week in Whistler Village.

I knew this would be a busy week when the primary task for MoFo across teams was to ‘Dig into our relationships goal‘.

  1. ‘Relationships‘ meant a lot of talk about relationship management (aka CRM).
  2. ‘Goal‘ meant a lot of talk about metrics.

Between these two topics, my calendar was fully booked long before I landed in Canada.

My original plan was to avoid booking any meetings, and be more flexible about navigating the week. But that wasn’t possible. This is a noticeable change for me in how people want to talk about metrics and data. A year ago, I’d be moving around the teams at a work-week nudging others to ask ‘do you want to talk about metrics?’. This week in contrast was back-to-back sessions requested by many others.

We also spent a lot of time together talking about the Mozilla Learning Strategy. And this evolving conversation is feeding back into my own thinking about delivering CRM to the org.

Where I had been thinking about how to design a central service that copes with the differences between all the teams, what I actually need to focus on is the things that are the same across teams.

I’m not designing many CRMs for many teams, but instead a MoFo CRM that brings together many teams.

I’m not actually giving this post enough writing time to add the context for some readers, but that small change in framing is important. And I think very positive.

Lastly, one other important lesson learned: Pay attention to time-zones and connecting flights when booking your travel, or you’ll end up sleeping in the airport.

18637945384_5c9b5b844b_z

Working on CRM

I’m writing a couple of blog posts today. This first is a belated note about my work on CRM for MoFo, and how I ended up doing this.

Slides from my presentation to MoFo on our All Staff call in June.

In the second quarter of the year, my Metrics work was pretty quiet while we were prototyping the new Webmaker Android App, and the Learning Networks team was in planning mode for Mozilla Clubs. There was some strategic work to do, but at this stage in the product life-cycle, data-driven decision making isn’t a useful tool. I never actually ran out of things to do, but was keen to spend my time on things that had the most impact.

So I was looking around for projects to help with. Talking to David Ascher, I explained that the projects that engaged me most were the complex ones that combined the needs and views of many different teams. This was also a moment of realisation for me that this was true of every job I’ve held. I like connecting things, including differing points of view.

The MoFo CRM project has been on the table(s) for a while now, but it never gained momentum for legitimate organisational reasons. All our teams needed some form of CRM, but even those with the biggest requirements didn’t have spare capacity to supply CRM tools to the rest of the teams. The more a team tried to coordinate with others, the more complex it was to solve for their own use case. It was everyone’s problem, and no-one’s problem.

So my proposal was to have a ‘product manager’ to look after CRM as an internal service to the org; Centralise ownership of the complexity rather than making it everyone’s problem. That way teams can think about the benefits of using the CRM rather than the complexity of building it. And after reviewing the plan with our Ops leadership, I picked up this task.

It’s been a couple of month’s since then, and I’ve had hundreds of hours of conversations with people across Mozilla about CRM. The project is living up to my request of ‘complex’, but I’m also pleased we’ve started doing the work. Although CRM includes more than it’s fair share of ‘Enterprise IT’, we’re keeping our workflow inline with the agile methods we apply to our own products and projects.

But it’s a difficult project to track, with many plates that need to keep spinning. I noticed this most after being offline with my family for two weeks then coming back to work. It took me a few days to get up to speed on each of the CRM pieces. So this week I’ve been working on documentation that’s easier to follow.

The project is now split into seven projects, and the current status of each, and the next steps with links to github issues for tracking and discussion can now all be found in one place. Building on Matt Thomson’s hard work organizing many Mozilla things, I’m using this wiki/etherpad combo as my working doc: CRM Plan of Record.