---
type: blog-post
title: Play test your tools
description: You just had this brilliant idea, you had this one problem that you just found the solution to while showering, you couldn't wait to go back to your pc and put it in ink, or rather bytes. By 1 in the morning you succeed, filled with excitement you write in slack to your coworkers or peers that you've just burnt the candle again and have something exciting to show in the morning.
draft: false
date: 2024-01-26
updates:
  - time: 2024-01-26
    description: first iteration
tags:
  - "#blog"
---

You had this one problem that you just found the solution for while showering,
you couldn't wait to go back to your pc and put it in ink, or rather bytes. By 1
in the morning you succeed, filled with excitement you write in slack to your
coworkers or peers that you've just burnt the candle again and have something
exciting to show in the morning.

In the morning you filled with excitement and without preparing a demo jump
straight in and show your groggy coworkers your new tool, which by the way
barely limps along, but in your mind is enough to show the idea, and the
glorious promise of the behemoth you just constructed.

Jumping straight into the technical bits, you can slowly feel the tired looks
from your coworkers, once again it happened. As you explain the idea and
solution to the degree you're capable so early in the morning, questions come
in - Is this needed, what does it do for us, do we really need the complexity?
Questions in your mind that suggests negativity, and maybe a slight hint of you
being a bother.

You leave the demo meeting slightly dejected, and disappointed - was what you
built a waste? should you just throw it in the bin?

> No

No is often the answer. But it is clear that the tool will need a host of
iterations to be useful. And that is exactly what you need to keep in mind. What
your coworkers gave the tired look, was not necessarily your idea, it was the
ratio of complexity vs benefit. Did your barely limping along behemoth provide
enough benefit for your team and your company to be worth the complexity. Maybe,
maybe not. But that is a discussion you should have.

Don't be dejected, it is okay to grieve for an idea, and solution (we're
engineers after all). But get back on the horse, try again and this time include
your peers.

## Focus on the right thing

When doing these demos you need to do one thing and one thing only. Communicate
an idea of your solution to a problem. Showing technical details often don't
matter, if they're not part of the problem themselves. This means that as you
demo these tools the focus should be on the solution not on anything else.

It should be presented in a manner you would expect from a keynote, the demo
should be practiced, and work without showing the bits that are held together
with duct tape. And more often than not, short and straight forward. And usually
it isn't a good idea to plan for the demos in the morning where people are just
getting into work, do it just before lunch, that way you can also talk about it
during lunch if there is enough interest.

But take feedback like you would during a pull request, as software engineers
we're used to giving and taking feedback all the time. But often for trivial
features. This is different, you often can't help to be married to your
solution, as such you can't take these questions for what they are; feedback.

To build products, which is usually what these tools and ideas are, in some form
at least. You need to take objective feedback, take a step back, pull the wool
from your eyes and look at what you've built with clear eyes. Take a day or two
from it, and come back to it, so that you can evaluate it as well.

## Someone stole my idea

This happened to me a bunch of time when I was a Junior engineer, and
occasionally happens now and then as well. You may feel like you successfully
presented your solution to your peers. It wasn't met with much interest, but
either during the discussions afterwards or a few weeks after someone builds or
presents a solution that you feel is eerily similar to your idea, but is met
with all the praise and excitement that yours didn't.

This can of course be nefarious, but more often than not, it was your fault. You
felt like you built a solution to a problem, but you didn't actually communicate
the solution sufficiently. As such none was able to see it for what it was,
someone else may even have been inspired by the idea, of what your tool could be
and took their own spin at it. As they'd churned on the idea a bit more, and
may've been a better communicator they could properly present the idea and
solution.

> Your idea is only as good as your ability to convey it

As tools builders we need to get it out of our heads that building a tool is the
same as conveying it. It isn't, at least not by itself. One of the reasons
Kelsey Hightower is as successful as he is, is that he is a master communicator,
and tool builder. He knows exactly what he needs to communicate and how much of
a solution to show to get buy in.

But don't accept someone stealing your idea, if you feel like they got all the
credits for what your work have an honest talk about it. Don't become bitter
because of what may've simply been a misunderstanding.

## As a playtest

A playtest is usually the practice of testing a piece of a game to check it for
a variety of factors. It may be a general playtest to test if the game is fun to
play, is cohesive, or in general if it works at all. Collect feedback and
iterate.

Your tools are not so special that they don't need refinement, and as you're
absolutely married to your solution, as you've just built it. You need external
feedback. You may want this feedback from your team, but they might not be as
unbiased as it may seem, for some of the factors given above.

Instead reach out to a few colleagues in another team or ask in a forum if
someone would like to try your tool out. It will help you practice your
presentation, and get some feedback from someone a little less biased towards
your idea. That way you can have room to answer the difficult questions when you
end up presenting this idea to your team during a demo.

I really recommend this practice, but remember to ask for feedback, and choose
your testers with intention. Such that it doesn't just become a show and tell,
but an intentional section that improves your ability to convey the idea you'd
like to. You may also get enough feedback, simply from seeing them interact with
your tool, and the questions they ask. If they ask the same questions as your
colleagues did in the earlier section then it may not have been conveyed
properly, or been too confusing.

## Your idea isn't yours anymore

Once the idea or rather solution is accepted you need to realize that it isn't
yours anymore, you may still be the initial author, but you probably aren't
gonna be able to recognize it a few iterations from then.

As your tool is let out in the wild, people will struggle with certain parts,
find bugs, some of your smart ideas, will turn into sharp corners and will need
to be remolded entirely. The tool may even need a pivot because your initial
solution didn't actually cover the right problem space. As you didn't have the
full knowledge of said problem space when you began developing the solution.

## Ask for meta feedback

If you feel like your presentation didn't go the way you wanted it to. Either
ask the most senior person on the team, or give the same presentation to another
senior person and get feedback on the presentation itself. It is much easier
seeing what went wrong from outside your perspective. Getting this feedback on
how you convey a message is crucial for becoming a natural at it.

Communication is hard, really, really hard. You may have it down one day, and
the next you whip up a message in 10 minutes and get no engagement, or simply
confusion. You always need to be intentional with your communication. If you're
not you're simply producing white noise.

# Maturity

At long last your idea is mature, it is widely adopted, your team uses it as
part of their daily work, it has its quirks, but it works just fine. The tool
has become the team or organisation and you don't feel the same ownership of it
as you did in the beginning, but you're still somewhat proud of having presented
it, and it being accepted.

At this point you're ready to think about the next edition of idea and how it
will solve problems in a whole new way. It will be janky, it will be
frustrating, you will be dejected, but you will continue with the learning that,
yes, you need to be a great tool builder to implement these solutions to your
ideas, but being a great communicator and being intentional with your
presentations is just as important as being able to put your idea into bytes.
