Startup Stereotypes

The last couple of days I've been giving a friend some advice as he tries to flesh out a startup. Having spent a decade or so playing in that arena with some good successes (and even more valuable failures) to my credit, I'm doing what I can to make his transition into the ranks of the entrepreneur less volatile than mine. From time to time, I use this place to spew thoughts that seemed to be helpful to him and might be useful for others.

In the technology workspace there are a couple stereotypes that have evolved. The first is the Developer. The technical guy who solves engineering problems, makes the impossible a reality, and knows way more details about how things work than most of us will ever care to acknowledge. The best ones are often very temperamental, strong-willed, and emotionally volatile. Their opinions and decisiveness, an un-erring determination of their own correctness or failings, and unflagging curiosity are their hallmarks. These traits are what spur them to the feats of creative genius and startling leaps of intuition which are why they are tolerated. As a sweeping generalization, the more valuable and miraculous they become the harder they are to manage.

The other major stereotype is the Manager. The general purpose resource who can direct activities, plans details and contributions, and makes the decisions. The best ones align themselves with contributors and seamless funnel opportunities and remove roadblocks in their relentless pursuit of specific outcomes. They are cheerleaders and priests, mothers and big brothers. They protect their people when necessary but make the hard choices on who to throw under the bus when necessary. Being social and flexible, easy to speak and quick to learn are key traits. As a sweeping generalization, great Managers sell themselves and their people, and act as information insulators.

In the startup world today you need both types of people. If you are somehow able to find both in the same person, hire them immediately. If for some reason you can't hire them, send them my way and I will.

Stomping Grapes

Someone who works for me recently was charged with doing some work on a system that many people use for the project on which we were working. He came to me with concerns on how to proceed. He wasn't sure how to set expectations to the team about the work he was doing. He was struggling with how to layout his work because he was concerned with impacting others. Keep in mind, his work is absolutely crucial to the forward progress of the entire team and as such has far reaching impact. Specifically, he was proposing to create multiple versions of the system and play a shell game of moving people from system to system in an attempt to minimize their impact. The following is a much edited version of the email I responded with:

----

The proper way to follow an Adaptive Approach is to keep one and only one reference or definition for a thing. In this case that is your application. If that impacts other work we are doing on the system, so be it. Work fast.

One of our basic principles is that the overhead used in trying not to impact other people slows us down. This slow down costs a lot and the amount of impact avoidance gained is rarely enough to warrant the expenditure. As such, if you need to make changes, then by all means make changes. If that impacts people, so be it. Work faster.

I will give you my best advice that you have heard before and will doubtless hear again from me. Think in terms of a single build. A single process. A single copy of code. A single version. A single Application. And so on. When you think about "old" versus "new" it skews your ability to focus on the work. Instead you spend mindshare on preservation of work, or juggling conflicting requirements. Whenever I hear someone in a conversation about setting expectations start to say "What we were doing..." or "Before we did it like..." or anything that doesn't speak in the present or future tense I mentally shudder. They have just lost points with me and I make a mental note that their stock price is sinking. That is because they are effectively wasting the time of everyone in the conversation.

Like ripping a bandage off, or breaking up with someone, you need to just do it quickly and for heavens sake do it all it once!

One of the quickest ways to get into an Adaptive Approach is to forgo chronological labels like old and new. As the Highlander would say, "There can be only one." It means you impact people more often, but working in isolation is a myth of software, not reality.

You will find that software development (real software development) is a social activity. It's sort of like stomping grapes. You can try not to get any on you, but you'd be really missing the point as well as the fun. Wash your feet, wear white clothes, and embrace that the mess is going to get everywhere for a little while and your clothes will never be the same.

Enjoy the stomp, it makes better wine.