Beyond Senior – Just Enough Experimentation

After a number of conversations over the past few years with several other engineers who have moved beyond senior levels into staff and principal positions I've come away with a lot of insights, many of which have seen their way to Twitter or other conversations first, but now it's time to start collecting some of those stories into this new series: Beyond Senior.

What does it mean to go beyond the senior level in an engineering organization?

That's the question we're going to be looking at throughout this series.

Just Enough Experimentation

In my last post we got into progressive influence and how to approach major projects. This was very much meant as an overview post, and as such was very generic in nature.

This post will look more into code and process changes, and how experimentation can really kick off a great conversation, but you know: just enough experimentation.

Informed Code is Worth a Thousand Words

You've probably heard the old phrase that a picture is worth a thousand words, and perhaps even the extrapolation that code is worth a thousand words as well. In some cases I would agree this is true, code can indeed make a very compelling point very quickly, but it can also be a distraction at times.

Returning to the previous post I would very highly encourage you, before diving into too many experiments, to seek understanding and a mutual one between enough teams to form a reasonable opinion that you can base that experiment on.

If instead you start to experiment from solely your own opinions without vetting them by others, doing some discovery work, or really any foundational research you're very likely going to have an experiment which does not reach people as effectively as it could have.

I would instead amend that phrase in these contexts to be "Informed code is worth a thousand words," and that means informed by more than just yourself no matter how well you may know a given domain.

Enough to Explore

The beauty of an experiment is it allows us to investigate a novel idea, and test that idea with teams. Generating those conversations and pairing sessions is immensely valuable in turning an experiment into a full project, or perhaps in even disproving an experiment and finding out what other problems may exist.

Your goal here should be to find teams which your experiment is designed to help, and run a bit of ping-pong with them to see:

1. If this could potentially solve their problem
2. What features would make this more useful to them
3. If this is even possible to code (it might not be)
4. How expensive it might be to pursue

For me I like to find at least three teams, sometimes up to five. Enough to vet ideas, but not so much as to require interviewing the entire company every time I need to test something.

But No More than Needed

Now be careful with that though, as there's also a tendency when experimenting to add all the features, bells, and whistles. After all you're a smart fellow, why not? You could make something truly amazing in just a week and really polish off that interface.

I believe this misses the point of an experiment. Think of experiments as more of a conversational piece, in that they provoke conversation about a potential direction of work that could be investigated. Every answer in code you give is met with a reply, and a retort.

We let these retorts drive a bit of back-and-forth to suss out the edges of a problem certainly, but at some point we've gone from an experiment to a full project without considering how we'll break the work up and really push it into prime time.

Before starting an experiment be sure that you're not taking it too far, because the point of an experiment is to make a point and generate buy-in. Once you have that it's time to start project planning and gathering more formal requirements.

If your experiment immediately becomes a solution you've skipped a few steps, especially if this experiment is designed to address projects of significant scope.

Qualifying Success

Your job with experiments is to prove whether or not something is worth pursuing. Hold fast to that line, and make sure to measure progress towards it. Crossing it can often times become a distraction and have you diving deep into code when it may well be time to promote it to a full project.

Make sure to have a definition of success in mind before starting, otherwise you'll find it very tempting to move the goal posts as you get closer.

Qualifying Failure

Likewise you should be willing to admit that an experiment was not successful. There's no shame in that, and in fact writing down solutions which did not work narrows the field for future pursuits and is valuable in and of itself.

Many of the experiments I've done in my career have qualified as failures, but because of that I was able to stop from pursuing a full project based on an idea. That experiment let me quickly assess that moving further was not a good idea, and for that it was still very much worth the time.

The trap here is often trying to make something a success, and not being willing to let go.

Wrapping Up

Experiments are useful at levels beyond senior to prove a point, or to originate work. The danger is when experiments absorb all of your time and distract you from other work. They should be quick, light, measured, and to the point.

When done as such they can be powerful tools to inform decisions and generate work for others. Especially at these levels your job is to create clarity and direction, not to play hero and do it all yourself. Being able to let go of an experiment and turn it into a full project is a critical step in growth for engineers once they go beyond senior.