1 of 31

Everyone’s a player (in a mid-90s MUD)

(They/Them)

Kenzie Woodbridge

DevOpsDays Portland 2019

2 of 31

Let me tell you what I’ll tell you

Context
These are the people in your docs neighbourhood
MUDs and Player Type Theory
Connections and implications for documentation
Challenges, solutions, and strategies

Me thinking I’m just sooooo funny - throughout.

@rainbowkenz

So here’s my plan. *First, context is always important. I’m going to give you a little of my real-life work context for my work situation so you can understand where I’m coming from. *Then, I’ll offer up a few… caricatures of some of the folks you might find in any technical organization, whether it be a tech startup, a long-standing software company, a government or education IT department, etc. *I’ll introduce you to Player Type Theory and talk just a little bit about the history of online games. *Then, I’ll try to connect it to back to those folks I introduced you to and to documentation and *I’ll finish up by identifying some of the challenges and offering some possible solutions and strategies that this application of the theory suggests.

*Also, I hope to make you laugh if I can, because that’s part of how I measure my value as a human being (no pressure).

3 of 31

1.

Context

@rainbowkenz

4 of 31

BCIT:

5 campuses
~2700 faculty and staff
~50,000 students (FT+PT)
>500 credential programs

@rainbowkenz

5 of 31

Me: Kenzie (they/them)

@rainbowkenz

Docs are

awesome!

My job title is Intermediate Systems Analyst, which must mean that I analyze intermediate systems? That’s not a funny joke, but I’m compelled to tell it every time. Sorry about that.

Over the last 15 years at BCIT I have worn and continue to wear many hats. This is DevOpsDays, so I’ll say that I started out more on the Ops side of DevOps. I’ve done a lot of *software user support and I continue to do plenty of *technical training with our users. Spending so much time with our users has led more recently to my *contributing substantially to the development of new tools and software for them to use, bringing the user perspective into the Dev room and designing systems to meet their needs. I also do a surprising amount of *meeting facilitation and conflict management.

But if there is one through-line in my extremely weird DevOps-y career, it is the part of my job where I *write, edit, and just generally wrangle documentation.

As you can probably guess, I’m not neutral on documentation. *I think documentation is great! It can solve and prevent so many problems for so many people. In my opinion, it’s one of the most important things to consider in a tech project and one of the hardest things to do well over the long term.

Why have I maundered on about myself and my job so much? It comes back to what I said a minute ago about complexity. I work in a complex environment and so I know first-hand how important it is to have documentation to help us all to navigate that complexity. I’m not going to pretend to you even for a moment that our technical documentation at BCIT is perfect. It is inevitably, incomplete and somewhat variable in quality. But it’s better than it could be and I have managed to convince my colleagues to fill a few gaps using some of the strategies I’ll be suggesting later in this talk.

6 of 31

Documentation:

Developer Docs
User Docs
User Manuals
Knowledge Bases
Code Samples
Release Notes

Requirements
Code Comments
Embedded Help
UI text
Decision Logs
Meeting Minutes

@rainbowkenz

Docs are

many!

7 of 31

2.

These are the people in your docs neighbourhood

@rainbowkenz

8 of 31

“Sprout”

Support desk
User focused
Broad technical experience and knowledge

@rainbowkenz

9 of 31

“Turnip”

Specialist developer/�Server administrator/DBA/etc.
Knowledge focused
Deep technical experience and knowledge

@rainbowkenz

Turnip! Turnip could be any number of different technical specialists*, but for our purposes let’s say that Turnip is a server administrator, probably Linux. *Turnip loves knowledge. But… Turnip does not. Like. Interacting with. Users? To Turnip, users exist to justify the existence and maintenance of servers, and my friends, those servers are beautiful, even if we are maybe not all equipped to appreciate that beauty. Turnips can sometimes find themselves being a bit openly dismissive of people who can’t understand what a server configuration means just by looking at it. If you’re not going to spend the hours that Turnip has spent learning everything there is to know about this*, you don’t really deserve to have the information handed to you on a plate. Sound familiar? Maybe even a little too familiar? I’m guessing a bunch of you Turnips are here in this room? Anyone care to self-identify?

10 of 31

“Kale”

Developer/project manager
Sufficient technical experience and knowledge to accomplish the thing
Likes to win
+4 CHA

@rainbowkenz

Kale! Kale’s very popular these days. Somehow, if there are 15 projects on the go, Kale is always going to be right at the head* of the most exciting and buzz-wordy project. Kale led that responsive website redesign project back in 2008. Cloud storage project? Look no further than Kale. *Kale is knowledgable enough to get ‘er done, but that’s not what motivates them. *Kale likes to win at IT. In service of that, *they know how and when to schmooze and they show up at meetings when important people are there. At the end of the project, their name is at the top of the incomplete list of deserving team members when the kudos get handed out in public. If Kale is on a project, that project must come in on time and on budget. I would guess that Kales would be pretty well represented in this room. Kales in the room? Own it, Kales!

11 of 31

“Broccoli”

More of a lifestyle than a technical role
Hierarchy/power focused
Unknowable technical experience and knowledge
Undermine everything

@rainbowkenz

Broccoli. It’s time to talk about Broccoli, no matter how awkward it is to do so. *Being a Broccoli, I suggest, is more of a lifestyle than a technical role. *Broccoli can actually have any number of roles in your organization, though usually they have at least a little power. They could be a developer, project manager, server or database administrator, support desk coordinator, etc. *It’s often hard to pin down exactly how technically skilled Broccoli is or what their availability is, or what they’re actually responsible for. *They are often eager to get involved in projects but then at some point, when it can cause the most stress and anxiety to others, they become a weird unaccountable bottleneck. Broccoli is great at engineering a situation so that they’re causing the problem, but you’re the one who will be blamed. I certainly hope that you don’t have a Broccoli in your workplace, but I’m guessing that most of us have encountered such a person in our careers at least once. Any self-identified Broccolis in the room? Heh!

12 of 31

3.

MUDs and Player Type Theory

@rainbowkenz

13 of 31

Richard Bartle & Roy Trubshaw

MUD:

Multi-User Dungeon

Place your screenshot here

@rainbowkenz

Put up your hand up if you know what a MUD is and have ever played one? For those of you who haven’t, MUD stands for Multi User Dungeon. MUDs are text-only online multiplayer games.

* Richard Bartle and Roy Trubshaw created one of the very first MUDs in 1978, which happens to be the year I was born. Their popularity likely peaked in the mid- to late- 90s, which is when I spent my time playing and creating in them, but there are still hundreds online and playable today. I heard of one just the other day that’s been going for over 20 years and is primarily used by blind players. Room descriptions aren’t visual, but instead are tailored to the kind of sensory input that blind people would relate to, for example. The MUD you see me inexpertly navigating above is actually a version of Bartle and Trubshaw’s original MUD (called MUD2). It is still online and playable and I recorded this myself not so long ago.

14 of 31

Interact

Act

Players

World

“Socializer”

“Explorer”

“Killer”

“Achiever”

@rainbowkenz

Player Type Theory? What’s that?

So, what’s player type theory? In 1996, Richard Bartle published an article which he described four types of players, differentiated by their motivations. *The easiest way to explain the types is to sketch out a simple combinatory table. *We only need two axes. One axis I’ll mark as *Interact at one end and *Act at the other. I find it helps to think of it as Interact with and Act on. The other axis has *Players at one end and *World at the other.

Then each of the four quadrants is a combination of two traits. So up at the top left we have the combination of interact and players, *these are the folks whom Bartle called Socializers. They have fun by interacting, usually pleasantly, with other players in the game. They might play, but they’re not playing to win or even to explore. It is the social interaction with other players that interests them. Then over here *we have Interact and World. These are Explorers, they have fun by gaining in depth knowledge of the game, its mechanics, and the environment. Though they might have the hard-won skill to beat the game, that’s not really interesting to them. Finding hidden things or understanding game mechanics well enough to exploit them for your own uses is. *Down here we have Act and World. Bartle named these players Achievers and they have fun by acting on the game world and beating the game. They want to get to the highest level, beat all the quests, get the best armour, and so on. And then in the final quadrant we have *Act and People and Bartle, not one for mincing words, *called these players Killers. They have fun by acting on other players, often by disrupting their play, perhaps by killing their characters or destroying what they have built or collected.

Those four are Bartle’s player types. And in his player type theory, Bartle posited both a number of interactions and dynamics that occur between players of various types and suggests ways to design a a virtual world to encourage or discourage various types in hopes of finding a stable equilibrium of players in the game.

15 of 31

Caveat Time!

The full compexity of the human experience cannot possibly be summed up with a simplistic “There are four types of people” declaration (or a “There are four lights” declaration for that matter) and I want to assure you that I am not attempting to do so. You are a complicated and wonderful human being with many many facets and so am I and all of us together are only a small part of the amazing complexity available on this beautiful planet we live on, which itself is only a tiny part of the amazing complexity and beauty and depth and interestingness of the universe and all of this is available for deep and interesting conversation, as am I after this talk, so don’t worry. Together we can combat the slow trundle towards oversimplification, but this is just a 30-minute tech writing talk so I had to follow the KISS principle, though I don’t like that because “stupid” is an ableist slur which I prefer not to use. Also, climate change is real and caused by human activity!

16 of 31

4.

Connections and implications for documentation

@rainbowkenz

17 of 31

Interact

Act

Players

World

“Socializer”

“Explorer”

“Killer”

“Achiever”

@rainbowkenz

Now, I was reading Bartle’s article about player types and I noticed something. Although Bartle was writing about playing a game and the kinds of things that motivate individuals to play it, he sure mentioned documentation an awful lot.

And that’s especially true when he talks about the differences between the top and bottom half of our combinatory on the world side, *Interact with Explorers vs. *Act on Achievers. Bartle talks a lot about the difference between a game that you’re designing specifically to engage * Explorers, vs. one that you’re designing to engage Achievers. And for the most part, the difference between them relates to documentation of one kind or another.

Here’s a couple of examples: *Emphasising Interacting over Acting means designing for Explorers, and Bartle says to “Make the help facilities produce vague information” and “produce cryptic hints when players appear stuck”

*Emphasizing Acting over Interacting means designing for Achievers, and Bartle suggests “providing a game manual”, and “including auto-map and auto-log facilities”.

When I read this, it immediately struck me that this might offer a useful insight into a phenomenon that I frequently saw in my workplace. Perhaps you’ve seen this too: not all of the time, but at least some of the time, some of the most specialized and expert people are also the people who write the least documentation. This has always puzzled me. But if those deep-dive specialists are motivated in their work by discovery, by figuring things out, then having proper documentation would actually take all the fun and enjoyment out of that for them. Doing a difficult thing is only an engaging task worthy of their skills and their attention if there isn’t a walkthrough telling them each and every step along the way. They can work and even thrive in an environment with poor or no documentation because it’s engaging and interesting. This made me start thinking about applying the model to my work environment.

18 of 31

Users

Technology

Interact

Act

Players

World

@rainbowkenz

Docs are for everyone!

Let’s go back to our combinatory again. I’m going to modify it just slightly for the workplace application. I’m going to leave Interact and Act just as they are, but I’m �

* going to swap out Players for Users. Then, I’m going to ��* swap out World for Technology. Now let’s bring back those personas I talked about a few minutes ago. You’ve probably already guessed, from what I just said, that I’m proposing that ��* Turnip is an Explorer, because they like to interact with the technology. ��* Sprout, who enjoys interacting with users, is a Socializer. ��* Kale then, with their love of of winning, is an Achiever. ��* And yep, that makes Broccoli, the gate keeper and weird subtle power-player of the group, a Killer.

So what does this schema mean for technical documentation? Here’s where I’m going to tell you another of my biases: *I don’t think documentation is something that only a technical writer should do. In fact, in a complex organization like the one I work for, and in organizations too small to hire a technical writer, it simply can’t be limited to a specialist writer. We all can and should document at least some of the things we know because it makes our own work and the work of our colleagues and clients easier and more efficient. But how can we make that happen? Let’s get to the meat of this talk.

19 of 31

5.

Challenges, solutions, and strategies

@rainbowkenz

20 of 31

“Sprout”

Socializer

User focused
Broad technical experience and knowledge�
Natural documentor�(may need support)

@rainbowkenz

Sprout first. I’m going to suggest to you that since Sprout’s focus is on *users and meeting users’ needs, the Sprouts of the world actually often love documentation because it helps them solve a user’s problems quickly and without missteps. They can send a user to a resource that let’s them do self help or they can step through it with them in person or on the phone.

Documentation also helps Sprout to maintain their *broad technical experience and knowledge, and they tend to give back to it. As a support desk worker in a team, Sprout also often wants to support their colleagues in solving user problems. If, for example, Sprout figures out a workaround that isn’t documented, they will document it.

*In fact, in my experience, Sprout is a natural documentor and if Sprout is working in a place without a central documentation repository or if they are prevented from easily contributing to it, they will be the person with 40 Word documents on their desktop that they can quickly email to a user in need.

Here’s the challenge. Despite their expertise and knowledge, Sprouts are often undervalued and sit low in the IT workplace hierarchy. I have a bunch of personal theories about this, specifically to do with the way they are perceived to be tainted by their interaction with and concern for the inconvenient non-technical user. So I want to note that in player type theory, Bartle sees Socializers as critical elements in a stable game community. He notes that without sufficient Socializers in the community, a game’s player base will inevitably dwindle. That’s because within a game environment, Socializers provide an appreciative and companionable audience for Explorers and Achievers and reactive prey for Killers, which is an uncomfortable thought. In a tech environment, Sprouts can have even more impact. In addition to producing their own documentation focused on the actual needs of the users they have contact with, they are appreciative users, testers, and communicators of any documentation that their more tech-specialized colleagues produce. Sprouts are important and even pivotal contributors, so we should take seriously the problem of their marginalization in our organizations and possible targetting by the Killers/Broccolis of the world. It’s worth pointing out that a work environment isn’t the same as a game environment. Workers have less freedom to just physically leave if they’re bored or harassed. But they can certainly disengage, stop going the extra mile, and doing things like writing and maintaining documentation.

21 of 31

Socializer/Sprout documentation support

Public Support Strategies

Expect to:

Advocate for them to others
Give public kudos
Include them where they are excluded

Structural Support Strategies

Expect to:

Provide templates
Provide a repository
Assist with writing/editing and publishing

Specialist Writer Mentor
Buddy System/Peer Review
Docs Sprints

@rainbowkenz

How can you help? I suggest a two-front approach: personal support, and public support.

**Under personal support, all of my suggestions actually apply to every type to a greater or lesser degree. *First, I suggest that you can never go wrong with a structured template. Nothing aggressively and intimidatingly stares down a potential documentor like a completely blank document. Likewise, *providing a repository for their docs that is integrated with the rest of the documentation is very useful. Adopt my broad definition of documentation and keep it all together in an organized way. *Finally, I suggest that some non-judgmental assistance with editing and publishing could be useful. If you are lucky enough to have a *specialist writer/KB administrator like me on the team, then that kind of support is just a natural part of the role. If not, a *buddy system could be a good strategy, or *social group documentation sprints with a culture of folks being a second reader for each other.

**You also need to support Sprouts in public, and include them where they are being needlessly excluded. *Become the local Sprout ambassador. Don’t let anyone speak ill or be dismissive of a Sprout in your presence. Talk about the good work they do, the documentation they write, their expertise and knowledge of users, their user empathy, etc. *Thank them for the work they do publically, in front of others. *Include Sprouts. If you’re in project meetings and there’s never anyone there who supports users in using the thing you’re building, ask why not. Ask it often. Get those people in the room, because they know things that developers and administrators and project managers don’t know.

Basically, what I’m saying is that if you care about documentation, Sprouts are your natural allies, and if they’re being dismissed, forgotten, excluded, or discounted, your documentation is going to be worse, your workplace culture will be less engaging and enjoyable, and supporting your user community is going to be a lot harder.

22 of 31

“Turnip”

Explorer

Knowledge/exploration focused
Deep technical experience and knowledge�
Natural anti-documentor

@rainbowkenz

Oh Turnip. As an Explorer: Turnip is *motivated by knowledge and likes to have the freedom to explore and figure things out for themself. Learning and exploring are so central to a Turnip’s motivations that they have difficulty imagining that this isn’t true of everyone else. Something that I have heard a lot from the Turnips I work with, whom I love, is that they don’t want to tell users best practices or guidelines for how to use a tool, because the tool is flexible and/or intuitive and users should just spend a bit of time exploring it and figuring out how they want to use it. They appear baffled by users who just want to briefly use technology to accomplish a specific task and move on to the next thing on their list.

*Then too, Turnip’s deep technical experience and knowledge and their respect and reverence for same can also introduces tension into the workplace where differences in skill level are likely to be common.

In my experience, Turnips tend to be quick to judge others against their own expectations. This means that for Turnips, folks who lack experience and knowledge of technology or who aren’t interested in exploring the technology for themselves aren’t busy people who may be experts in their own domain and who just have a lot of work to get through in a day. They are just wildly inferior Turnips, and surely no amount of documentation will help with that.

What it comes down to is that *Turnips are natural anti-documentors. It doesn’t naturally occur to them to write it and if they document something, it is likely to be reminiscent of the quote I showed you previously: *cryptic hints that only another similarly skilled Turnip could parse. And when that doesn’t appear to stop people asking them inconvenient and annoying questions, they may just throw up their hands and give up on documentation entirely.

23 of 31

Explorer/Turnip documentation extraction

Reframing Strategies

Demonstrate that documentation:

Shows off expertise
Is another thing to have knowledge of
Keeps icky users away

By sending to docs first
By giving others the ability/access to fix problems

Writing Support Strategies

Expect to:

Reduce barriers (provide templates, repository, etc.)
Rewrite docs for audience
Not sweat the small stuff

@rainbowkenz

If your goal is documentation that is correct and detailed, then the folklore contained in a Turnip’s brain is your holy grail. Because they’re not naturally inclined to document things, and because they’re busy doing important work, your documentation process may need to be altered to accomodate them, but this is generally worth doing in my experience. To get those docs out of them, **first, you need to reframe documentation for them. Get them to think about documentation as *showing off their expertise to others, proving that they are in fact knowledgable. You could also *reframe documentation as yet another thing for Turnip to be knowledgeable and expert in. But perhaps most effectively, *remind them that good documentation can be used to, um, reduce interruptions in their life from lesser beings. This has a broader cultural piece, because it will only be convincing if it’s actually true. That means that there either needs to be an organizational expectation that it’s appropriate to *send users to the docs first, before escalating users to Turnip, and/or you need to *increase the scope of what your support workers are permitted to do for users with the support of Turnip-written docs. I’ve seen push-back to both of these strategies, but there’s usually room for at least incremental improvement on these.

**You’ll also want to support Turnip’s writing efforts. *Reduce the barriers that stand in their way. Provide templates. Help with publishing. Do whatever you need to do to get their knowledge out of their head and in the docs, because it is worth it. This means that at least some of the time you may also need to *edit and rewrite some of their documentation for the users. We all get to choose the hills we are willing to die on, but I’d suggest that *winning the fight on consistent use of the oxford comma with a Turnip is not a good use of your time, especially if it prevents them from getting what they know out in an accessible form.

24 of 31

“Kale”

Achiever

Achievement focused
Documentation opportunist
Love “events”, hate slow-grind operational work�
Inconsistent documentor

@rainbowkenz

25 of 31

Achiever documentation gamification

Gamifying Strategies

To motivate achievers:

Post doc writing/review stats
Make doc authors visible
Advocate for docs as critical success criteria in projects

Achievement Support Strategies

Expect to:

Be available on short notice
Provide and enforce templates, structure, etc.
Outsource maintenance
Publically thank them

@rainbowkenz

How to support Kale? Well,

**First, you want to literally gamify documentation for them. *One way to do that is post the stats on who’s doing the doc writing, at least internally. Who wrote the most or most-visited this week, this month, this year? Who has the greatest proportion of current reviewed docs? And so on. Kale likes to have their name in lights, *so maybe consider making the author or docs visible in some fashion, although I admit that this might not be desirable in all circumstances. *Of course, the biggest gamification strategy I’d suggest is to not let writing documentation be an optional side quest. Having all needed docs in place before launch needs to be a critical success criteria in your projects. It needs to be a standard element in your release plan or project plan. There’s probably a whole other half-hour talk contained in that one bullet, I acknowledge, but a big part of achieving this is having a good understanding of what your actual documentation needs and expectations are and ensuring they’re in proportion to the need and the resources available and maintainable over time. If folks are failing to meet documentation expectations they may just need more of the supports I’m talking about here. But if they’re not even trying to meet documentation expectations then it’s also possible that those expectations are either non-existent or, alternatively, inappropriately complex and unmanageable.

**Once you have them concerned with documentation, you need to support Kale’s achievement. *One piece of advice I’d offer is to be available on short notice. Where I work, I know that about a week before the launch date of their major project, Kale is going to come with me and ask me to edit and publish their 15 docs. I could quite reasonably tell them to organize their work better and that their poor planning is not my crisis but the reality is, they likely won’t change. Accomodating them now gets me their gratitude and further commitment to documentation in the future.*Once again, templates and structure are great. Achievers will use them, and it’ll make your short-notice rush job easier to get through. Also, if you can *outsource the maintenance of their docs to others, perhaps Sprouts, you may save yourself many a headache in the future. *Finally, public kudos are important. Thank them in front of others, especially in front of the folks whose judgments matter to their careers or other projects.

26 of 31

“Broccoli”

Killer

Hierarchy/power focused
Motivated by the frustration of others
Will never, ever review or update�
Inconsistent documentor
Element of destructive chaos

@rainbowkenz

Back to Broccoli. I’m gonna suggest that in addition to their other difficult traits, Broccolis are often predictably terrible at documentation. Not because of lack of ability but because *information is power, so controlling information is also power. If something is well-documented it makes it possible for others to avoid Broccoli’s influence. For example, if Broccoli is in charge of the weird legacy software that your organization inexplicably still depends on, it will likely be pretty badly documented, because then everybody has to go through Broccoli. *Paradoxically, however, if Broccolis haven’t managed to consolidate sole ownership of the technology, or if documentation is considered laudatory in your workplace, Broccoli may be motivated to occasionally add to the existing documention when doing so let’s them show a coworker up in front of others. *I promise you, however, that they will never ever review or update it. Ever. **Broccolis are inconsistent documentors and elements of destructive chaos. They are also, not to put too fine a point on it, bullies.

27 of 31

Killer/Broccoli documentation… something

Self-protection Strategies

Protect yourself:

Keep discussions public
Document everything (ironically)
Engage Turnips in the struggle

Go Forward Strategies

You should:

Ally with others
Treat agreements like contracts
Follow up/escalate
Expect but not tolerate delays and power plays
Make them the defenders of the project

@rainbowkenz

I sincerely hope you’re not having to deal with Broccolis, frankly. But, if you are, and there’s no way to get those people off your project, then player type theory does suggest a few strategies you can use.

**First, you want to protect yourself and other vulnerable members of the team. Not just because these strategies can help with actually getting documentation done (they potentially can) but because, and I’m not joking now, work matters, your experience of it matters, and you are worth protecting. *Only talk to them in public. Don’t let them collar you in a quiet hallway and make commitements for which there are no witnesses.

*Document everything. If you do have a verbal conversation about a project, follow up with an email in which you reiterate what everyone committed to. *And Bartle suggests that Explorers are the natural enemy of Killers, so get a Turnip involved. They know enough to keep Broccolis in line and to pierce through their lies.

**Then, you need to go forward with documentation projects as though it were completely reasonable to do so. Too often, workplace bullies are permitted to act with impunity because people would rather accept their bad behaviour and avoid conflict than acknowledge how damaging it is. But if you are able to confront it, you need to do it safely. *It’s dangerous out there, because of Broccolis, so don’t go alone. Have allies who also know what’s going on with this person.

Then, even though everything isn’t normal, you should still act, in public, as though it was. What I mean by that is, *treat the commitments they make as though they were real and be surprised, in public, if they don’t fulfill them.

*Follow up, in writing and in public, on commitments they have made and expect accountability. Escalate the problem to someone with more power than you, if you need to, and since you’ve been documenting everything, you can do it convincingly. Also, if you are someone with more power, it is incredibly toxic for you to ignore someone’s bad behaviour. If there is a pattern of concern being expressed by the people in your team, this needs to be addressed one way or another. Don’t ignore it just because the Broccoli you know seems different than the one that is being reported to you.

*Privately expect delays and power plays, but don’t tolerate them or engage with them.

I don’t want to be completely negative here. All Broccolis aren’t created equally, so *for extra credit, turn their destructive tendencies in a more useful direction. Sometimes a Broccoli acts the way they act because of frustration and cynicism. If you can empower them to use their killer instincts on behalf of the project against delays and barriers rather than against their coworkers, you might just do everyone a huge favour.

28 of 31

Docs are awesome.
Theory is great and also fun.
Crucifers are tasty.

@rainbowkenz

29 of 31

Users

Technology

Interact

Act

@rainbowkenz

How can I help?

How could you not know?

On time, on budget!

I ruin everything.

30 of 31

Thanks!

Let’s chat?

You can find me at:

@rainbowkenz

kwoodbridge@gmail.com

linkedin.com/in/kenziewoodbridge/

@rainbowkenz

31 of 31

Credits

Special thanks to all the folks in the world helping others (sometimes for free):

Presentation template by SlidesCarnival
Pictures of Hats from www.villagehatshop.com
Player Type Theory proposed by Richard Bartle
Workplace bullying advice by Captain Awkward and Ask a Manager

@rainbowkenz