Two Things I Learned When I Crash Landed at a Startup
Two Things I Learned When I Crash Landed at a Startup
Takeaways for When Your New Company is 5600X smaller Than Your Old One
Digital Equipment Corporation was my first company, and I always thought of it as this great mothership, a giant technology behemoth sailing through the vast business universe, crewed by 140,000 hands. But the mothership, while formidable, became an increasingly attractive target for smaller, nimbler craft. Caught in the crossfire of the powerful new hardware its enemies brought to bear, Digital eventually lost structural integrity, and broke apart.
Somewhere in the middle of this circa 1997 space opera, I decided to jump ship. The glowing, burning chunks of the company were being boarded by outsiders, and my immediate manager whom I really enjoyed working for had already evacuated. His replacement was a generic middle-manager named Dennis — An Alien who came from somewhere in the WinTel galaxy and who was keen on converting all of our Unix CAD tools over to Windows NT.
When I pointed out how much work would have to be thrown out and then redone to accomplish this, he said something like: “I’m not trying to pull up your carrots, Ned.”
That’s when I knew it was time to leave. I’d had enough of the chaos and destruction going on, and I certainly was not going to let Dennis the Alien anywhere near my carrots. I called up my old manager and arranged for an interview at the place he went to, a small startup with 24 employees. I had not interviewed anywhere in 11 years, but in spite of some rustiness, did OK enough to get the job.
If there were any doubts about whether it was time to go, they vanished during my exit process. Dennis was not around the day I gave my notice, and so I went instead to our division director Fred, whom I had worked with for a long time. When I told him I was leaving, there was no shocked “Oh no!”, or attempts to lure me back. Not because they didn’t want me. Because I was probably the 5th person that week who had given his notice. Fred just nodded, and sighed. I was pretty sure he was eyeing the escape pods as well.
When I went to my exit interview, Susan the HR person asked me where I was going, and when I told her it was a small startup run by ex-DEC people, she asked me if they had any jobs there. I was kind of amused that the person conducting my exit interview wanted to come along with me, but I had to tell Susan that sadly, the escape pod only had room for one.
Stranger In A Strange Land
I set down on a small remote planet. If we were going for a Star Wars analogy, it would be more of a Dagobah situation than Tatooine, my admired and often-mysterious old manager standing in for Yoda, and the site as mentioned in another post looking a lot more like a swamp than a desert. The key characteristic though here was: small. There were probably DEC cafeterias with more employees than this company.
Small was not something I was really prepared for, after working for a giant company for so long. I of course knew what I was getting into at some level, being employee number 25 and all. But it’s different than you imagine though when you actually start interacting with the colonists of a tiny new world. I found myself shifting from fighting alien invaders, to becoming the alien myself. And here I had to relearn some basic customs, a couple of which I had taken for granted as being unchangeable.
Lesson 1: You Have To Do Everything Yourself
One of the first denizens of this new land I met was a guy named Marv, who was the IT department, along with being in charge of other infrastructural things like programming the dated telephone system that our CEO had picked up at a surplus sale. I sat under a skylight that leaked during rainstorms, and one day I looked up to see Marv above me with a green tarp, on the roof doing emergency building maintenance. (Thereafter the office area had a green, undersea vibe to it.)
Marv was a busy but efficient guy, and by the time I arrived had already set up my user login, which followed a first-initial, last-name convention. In my case, it made my login ‘nutzig’, which I had some reservations about using as my company-wide ID. Marv was reluctant to have to go change it, and he tried to sell it to me. It’s great, it’s fun, we can call you “The Nut”! he offered. Luckily my boss intervened to have him change it before he wore me down.
After that, we went on to setting up my Unix workstation, sadly a Sun machine which would have been heresy to use in my previous DEC workstation days. It was different than I was used to, and I went to Marv constantly to ask him to help configure it to my liking. This was normally a function of a much bigger IT department back at Digital, and the fact that Marv had given me root privileges to set it up would have been unheard of in my old job.
Marv seemed a bit irked that I kept asking him for help rather than figuring things out on my own, and I had to shift my thinking from “If it doesn’t work, have IT fix it” to “If it doesn’t work, try to fix it yourself first.” It was part of the first lesson of Small: self-sufficiency.
Marv stopped by the next day and asked if everything was working OK. I told him it was, to which he replied: “Good. Now start fuckin’ producing.”
This is when I knew I really liked Marv a lot.
The self-sufficiency lesson for me soon extended beyond IT matters. I found myself being sent on customer visits, sometimes solo, to see about issues they had. Such a thing would have been unheard of at DEC. In my 11 years there I directly interacted with customers perhaps twice, and each time, with a squadron of support people.
I remember going over to (soon to be experiencing hull-decompression also) Data General to look at a problem they were having with our software. It was then that it struck me that I was literally the face of the company, and whatever I did during this visit would reflect either positively or negatively on our product, company, and future sales to this customer.
That’s a lot of responsibility to take on as an individual, but also a lot of opportunity to affect change. I have worked at only larger companies since, and still sometimes meet one-on-one with a customer, but more often now, with a team. But I’ve carried forward the idea of “you are the face of the company” a lot more earnestly as being part of my job, even when meeting with customers in a group situation, and even when I only indirectly represent the company to the customer, through the things I create.
In the case of Data General, it was another doomed voyage situation. The chip they were working on was a totally asynchronous design, with (for the HW geeks), gated clocks, flow-through latches, and clock domains with non-overlapping frequencies.
In a way I think it was a futuristic design, we see more of these things now than 25 years ago. And who knows what will come with AI-designed hardware, and systems that mimic (also very asynchronous) neural networks. The trouble for DG though was their chip did not in any way work, and the verification tools of the time, including ours, were unable to debug it efficiently.
The problems with this project were not the sole cause of Data General’s end, but a bit of a harbinger if you ask me. I solved their immediate issue and flew away from there that day feeling I had done my best for them, but also feeling that it would not be long before the designers I met would be searching for escape craft of their own.
Lesson 2: You Can Do Everything Yourself
I also learned another lesson of Small, kind of the inverse of Lesson 1. This was the idea that once the bureaucracy of your job environment is removed, you are now free to do things that previously would never have been allowed. And in a small company situation, people are basically counting on you to not wait for formal permission to do something, but to take the initiative yourself. Knowing when and how to exercise this freedom is kind of the key skill set for mastering Lesson 2.
Our CTO Kevin was a guy I felt was just destined to live a charmed life, that included such feats as becoming independently wealthy three years after starting and selling his first company, along with smaller things, like hitting a hole-in-one on his first swing at our company pitch-and-putt golf outing.
One time Kevin got bored and went up onto the roof of our three-story Mill building with a fishing pole, and cast a line into the pond that abutted the building. Within seconds, a fairly large bass got hooked, and he reeled it up, much to the astonishment of some ladies who worked in another company located on the second floor. As they sat at the window assembling medical devices, a large fish just began levitating upward past them.
I don’t know why this is important to this story, but maybe just because it speaks to the level of informality that was in play on this strange planet I was on. Office NERF gun wars became a Silicon Valley cliché at some point, but in the 1990s I like to think our giant impromptu wars we had were on the cutting edge. Every employee was issued a sidearm when they were hired, and nightly capture-the-flag games were quite common.
Small here provided opportunity, and the CEO and CTO and other decision-makers of the company were not in some far-off corporate headquarters, they were the people you shot at with your NERF gun, and bumped into coming down from the roof with large fish. Everyone knew each other, and even an intern would have a chance to pitch ideas to the CEO.
I had been doing decent work in the company creating new interfaces for the product, and would get visibility, recognition, and guidance directly from Kevin and others in charge of the products we developed. Eventually they offered me a chance to work on building a whole new product, which in retrospect was probably a task beyond my level of experience then.
Perhaps there is another lesson in here about when to say no to an opportunity, but for better or worse, I took this offer. It was not something that would have been remotely possible at my previous job. Here is where I also learned a hard lesson about the right and wrong ways to do things all by yourself.
The product I had been put in charge of turned out for various reasons to be a dud. I can certainly take some of the blame for that, but there were many things working against it that were also out of my control. The one thing that was under my control though was the software architecture for the new product, which similarly turned out kind of bad.
What we were creating was really just a new mode of our old product, so it shared a lot of existing functionality, and in theory, code. The dilemma I faced was that the new product would do things differently, necessitating some fundamental changes to the code it was based on to make it extendable. The right solution here was a pretty deep refactoring of some of our software layers, including ones authored by different teams in our company. I think doing that would have been within my capability, perhaps with some help.
But years of working for a large, stratified organization had trained me to rule out that possibility. Proposing a big change to another group’s software at DEC (or worse, just changing it yourself) would in most cases have caused drawn-out conflicts, and the bureaucracy involved would bring inevitable delays and unneeded compromises.
The usual DEC way to deal with this was to just re-invent the wheel yourself, creating duplication, but thereby putting your project’s destiny in your own hands. (This siloed thinking of course caused a lot of issues at Digital, which I explored a bit previously in my article The Enemy Within.)
Following the DEC playbook, I built a product prototype that just duplicated some of the infrastructure code, rather than refactor something I was not in charge of to make it common to both products. In my head, this was a temporary measure, and I had the intention to work with the original authors to redo this “the right way” at some vague, unspecified point in the future. I got the prototype up and running pretty quickly this way, and Kevin who was excited about this project was soon showing it to customers, way before it was ready.
When inevitable problems cropped up, there was a review of the product and code, and the nature of my hacky implementation was revealed. This earned me a (luckily not permanent) reputation as a reckless, cut-and-paste hacker, and I was relieved of my architectural design duties on the product. It was probably a low point in my technical career, and I spent a few years after that in technical exile, managing people and projects but not writing much code.
Looking back it is obvious to me that I could have just gone in and reorganized the needed code myself, and it was not a task I had to wait for formal permission to do. There would have been a lot of scrutiny and review of my changes of course, but in general no red tape, and the creators of the code I would change were not the territorial types who would have minded me changing it. Another one to chalk up in favor of small.
My travels through space and time since have taken me to larger, more populated planets once again. But the lessons I learned on Planet Startup still hold in many ways. Grace Hopper, US Navy Rear Admiral, Computing Pioneer, and (for a brief period) Digital Employee is famous for saying:
“It is easier to ask forgiveness than it is to get permission.”
I have found this to be at least partly true. I think the modified, very software-developer-centric version of this for me became: “Don’t ask permission to write the code, ask permission to check it in.” My version skips the forgiveness part, because although there are indeed times when you should “just do it” and possibly upset people in the process, it’s not really a collaborative or reliable long-term strategy. You still need eventual buy-in with my modified version of avoiding asking permission. But it does allow for taking the initiative to do something nobody asked you to do, which is really a killer skill if you can master it.
So no matter what size spacecraft or planet or whatever you may find yourself on, my learned advice here is to not wait around too much. If you are waiting for someone to do something you can do, do it. It doesn’t matter if it is something you typically don’t do, just make it happen. And if you can help out in some way, don’t wait for someone to give you a perfectly green light beforehand, just go.
If you follow this advice, perhaps some Hopperish forgiveness will be needed in there, from time to time. But if you do it right, maybe your company will be the one blowing up the Death Star, rather than the other way around.
Explore Further
Next Time: Interactive Fiction games can trace their roots back to the late 1970s, and in the decades since have provided countless hours of entertainment for generations of players. We’ll catch up with the man who brought Adventure off of the mainframe and into our homes, spawning an entire genre. See what he’s up to now when we head back to the maze of twisty passages in: The Further Text Adventures of Scott Adams
Whether you hail from a big planet or a small one, consider subscribing to the Mad Ned Memo! You’ll receive weekly posts from the nerdy world of computer engineering and technology -- past, present, and future. (check the link for a sample of past articles). The Mad Ned Memo is cost-free and ad-free, and you can unsubscribe at any time!
The Mad Ned Memo takes subscriber privacy seriously and does not share email or other personal information with third parties. For more information, click here.