Play test your tools

2024-01-26

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.