• Ryan Nicoletti

C - E - Oh brother...

Updated: Sep 5, 2019

If you've read the in>D:\dev "About" page, you'll see a quip there that my title in my one-man show here is "Chief Everything Officer". The tautology doesn't really seem that clever; I'm sure this joke has been made a few hundred times... or even a few thousand... by other entrepreneurs that came before me.

It's the worst-of-the-worst-kinds of title inflation. I'm in charge of everything, but "everything" is pretty small potatoes right now. I went through no vetting or interview process; I just appointed myself with no competition to the post. I have no claim on success yet; my first game is playable and I think it's fun, but I can't keep doing this forever unless other players think the game is fun enough to buy it and support my continued work.

At the same time, saying my company is "small potatoes" doesn't mean that this isn't challenging, because it is. The particular way in which it's challenging is actually the topic of this post. While the "Chief Everything Officer" title is a little tongue-in-cheek, it also happens to be true, for better and for worse.

While the "Chief Everything Officer" title is a little tongue-in-cheek, it also happens to be true, for better and for worse.

The idea of being your own boss sounds glamorous to most people, and there are definitely perks. There's no one around to second-guess your decisions, to take credit for work that you did, or to take the work away that you would like to do and leave you with a bunch of dull or thankless tasks that you would rather weren't part of your job. Those are all things that many people experience in their day-to-day jobs at some point in their lives.

On the other hand, a lot of people that are their own boss got there the same way I am trying to do - by setting out all on their own to accomplish their goals. Proving you can do this is often a critical step towards getting buy-in from clients, your customers, or investors so you have the financial bandwidth to start compensating other people to be part of your team.

When you work alone, it is much harder to find quality mentors and expert advice to help guide your decisions. Nothing will get done if you don't do it; there's no backup to help you out on days when you are unmotivated, sick, or scared. When there is something that needs to be accomplished, it doesn't matter if you don't like to do it - or even if you are unqualified to do it - there's no one to trade tasks with to get a more appropriate match-up of work for your interests and skills.

You probably already saw what I did there, but if not, go re-read the third paragraph back, then read that last one again.


This sounds like trouble, doesn't it? One would think that it would cause a host of business challenges if I have to make decisions regarding circumstances and scenarios in which I am unqualified or otherwise unfit to render good judgement. Surprisingly to me, this doesn't seem to be the case. That's not because it wouldn't be better if I were some kind of superhero that was competent to perform not only the software development at my company, but also do graphics and user interface design, handle marketing and social media, and refine the designs and balance of my games. Clearly, that would be ideal. The reason I'm surprised that my unfitness for many (or possibly even most) of my duties isn't more of a business problem is because very few other business leaders I've met seem to know what they're doing, either, and my anecdotal* experience suggests this is often true even in successful businesses!

* Disclaimer: Anecdotal experience does not automatically represent definitive or generalized truths. I may use my judgement to weigh my anecdotal experience as I see fit, but I encourage you to exercise your judgement as well when assessing unsubstantiated opinion. Fortunately, whether or not you agree with that previous point isn't critical to the final thesis of this post; I contend that being mismatched to certain aspects of your goal execution is still a problem for other reasons.

When this is the case, the kind of person who has the faith to strike out on their own will often compare pretty favorably to the norm, on the basis of trusting their skills in research and learning to help them through cases where they find themselves in unfamiliar waters. That doesn't mean they're going to succeed, either; every statistic I've seen says the odds are overwhelmingly against success for anyone trying to start a new business. But if, say, 90% of new businesses are doomed to eventual failure, then one or both of the following is true. Either the overwhelming majority of people spearheading these efforts are just as unqualified as I am, or having the right qualifications doesn't contribute as much to success as one would like to believe.

In some ways, this is liberating. If I accept that sometimes, I just won't know what I'm doing when I have to wade out in the weeds, that doesn't automatically mean I'll get eaten by an alligator as long as I'm paying attention and using my best judgement. If the generally-accepted norm is to fumble around while one figures out their strategy, direction, and execution, then surely my own fumbling puts me in no worse position than the next guy trying to do the same thing. There's even a fancy bingo-sheet word for this in business: "pivoting".

The "Chief Everything Officer" role flies in the face of advantages that come from the division of labor.

On the other hand, this is still causing me very specific, identifiable, and predictable problems, and its in the spirit of that predictability that I close with my own cautionary anecdote as a heads-up warning to anyone else that might want to try their hand at starting their own business. My problem with the "Chief Everything Officer" role is that it flies in the face of advantages that come from the division of labor, from which spawns several related frustrations.

I was very, very good at the database development and information science that were at the core of my work when I was traditionally employed. If you'll forgive the immodesty for the sake of my point, I've never met someone I would consider a peer in relational database programming. In fact, the other best people I know are previous coworkers who were disciples of mine. I have some competitive successes that vouch for my ability to take on challenges in that realm that were beyond the ken of someone who was not also a veteran specialist, and I have very clear foresight and judgement when examining problems in that area of expertise. Critically, this effects the speed of the work in ways that feed back on each other: familiarity allows a lot of on-boarding learning to be avoided for a related problem, insight helps prevent bugs and architectural mistakes before they are implemented, and recognition helps identify problems that do still make it through the quality control pipeline before they cause an explosion in the final product.

I haven't done any database programming in my game development thus far. In fact, I have a hard time believing I will ever encounter any database development I would consider challenging in a game whose scope is small enough that I can tackle it as a one-man show. In spite of this, the programming skills I've nurtured over the years have been quite helpful to me in learning the new development platform I've been working with (#Unity).

I've been programming long enough that I know every new project comes with its own learning curves, and every new domain discipline comes with its own best practices to assimilate. The delays this brings to my projects are relatively easy to accept; this is just the "cost of doing business" when working with an unfamiliar system. A good example of this kind of hiccup was Unity's abandonment of their UNET multiplayer platform, which I was using as the network substrate in Stitchcraft, and have since replaced with Mirror, an open-source implementation of the same high-level application programming interface.

Successfully flexing my expertise is very motivating to me.

Occasionally, I still find an opportunity to flex my generic programming capability in a place where it doesn't touch on any system integration in which my ignorance and inexperience interferes. Adding the AI player to Stitchcraft was a great (and unexpected) success in this vein. The codebase I had created was accommodating enough that it took only about a week to work in an event-driven framework for allowing the bot to interact with the game and fill the shell with random behavior. In another week, I had created a weighted stochastic model for how the AI makes gameplay decisions which ended up in a fairly competent player that's capable of beating even talented players every now and then (including me). This was a stunning success for something I was scared might be a far more significant undertaking, and that success was very motivating.

Unfortunately, the flip side of this is just as demotivating to me as that one was motivating. Putting together this website has taken me some five weeks, twice as long as getting the AI player set up in code. Part of this is because there is a surprising amount of work all wrapped up in that task: determining who to use as a host, setting up the official business (and its mail, banking, etc.) so that several new bills for hosting and DNS registration can be associated with the LLC, choosing a design for the site, trying to concisely describe my mission, concisely describing how to play Stitchcraft, finding or creating representative graphics for the page and the game, and the list goes on.

Working as a novice again is slow and demotivating; THAT is the real struggle in the Chief Everything Officer role.

In database development work, I could have quickly put together a plan that included 90% of the alligator nests I would likely encounter. In this project, I found most of the alligators by stumbling into their nests, face-first. In database development work, my first implementation is usually close enough to successful that small refactoring gets me the rest of the way to home plate. In this project, my how-to-play Stitchcraft text rulebook started out 15-20 pages long, and I had to pare it down five or six times to get to the page I have now that might manage to hold our modern attention deficit long enough to reach the end. I made several mistakes with the design tool's templating capability that required me to go back and fix earlier work. In general, I'm just not very damned good at all this.

That has been the real struggle with being the "Chief Everything Officer". It's not as glamorous as it sounds. Working as a novice again is slow and demotivating.

62 views0 comments