Innovation Chamber: What is it like to work in a startup?
About the Author: Tom Chapman is a regular guest contributor to Silicon Prairie News. In his series Innovation Chamber, Chapman draws on his professional experiences to lend advice, share observations and provide milestones to the entrepreneurial community in the Silicon Prairie.
Currently with Nebraska Global, a Lincoln, Neb.-based software investment company, Chapman previously held the role of director of entrepreneurship and innovation for the Greater Omaha Chamber of Commerce. Throughout his career, Chapman has worked with hundreds of local (and some non-local) new ventures, many large companies seeking innovation advice and a host of funders looking for deals.
Hudl, another Lincoln company that sports the authentic characteristics of a startup culture, is located next door to Chapman's Nebraska Global office. Photo by Kyle Murphy via Flickr.
On August 29, I began working for Nebraska Global. Nebraska Global is an odd place because it partners a software investment fund with the creation of software enterprises. Currently, our portfolio includes a number of startup companies – including two that I am working with more intimately. Moreover, our company itself is relatively young – around one year old. Thus, Nebraska Global as an entity and as an operating environment (because of the multiple startups under our roof) and because of my responsibilities – acts very much like a startup company.
For those who have never worked in a startup, which included myself before Nebraska Global, let me give you my thoughts after one week at a startup.
- There are a lot fewer suits. So far in one week, I have only seen one suit and two ties. Surprisingly, it was not me who was wearing either. However, when you are "the" suit in the office, you do have to earn a certain amount of respect from the development teams – so I did wear a t-shirt saying "n00b." And yes, I did know what this meant before I wore the shirt.
- Meetings are much faster. In general, team or group meetings do not last one hour – they last however long they need to – usually about 20-30 minutes. Essentially they are built to execute for a day or a week – not to chit chat about whatever the meeting organizer wants. It was interesting to see the deployment of Agile Development Methodology in the field.
- You are expected to do your job immediately. There is not a getting to know you period. I have already started making calls on people to get information, opportunities and sales. Moreover, you don’t necessarily know everything about a topic before you are put into the field.
- The stuff that needs to work – does. The stuff that doesn't really matter – doesn't really matter. For example, one of the pipes in the lobby was leaking and caused us to have to put buckets down and fans running. While this was not pleasant and there was some grumbling, people basically said – "Oh, well. We can work around this." However, when I said that I needed a whiteboard. It was taken out of another part of the office and walked into my room immediately. It's not hanging, but it is here and operational – so to speak.
- Generally, people come to our office seeking help – but don’t know how to ask for it. For example, individuals with company ideas have asked for our help with software development or funding. Unfortunately, they ask without enough information to make it possible for us to provide useful immediate feedback – who are you, why do you have domain expertise, how much money can you make, do you see us as a consultant or partner, etc.? We really do want to help – but it can be challenging to provide good, timely communication when you have such limited information.
- Solving hard problems is fun. We are working on two or three really hard problems, including ones that are "game changers." The experts in the space who are running the projects are really smart people with domain expertise and clear technical capabilities – it is really impressive. I feel like an idiot when I talk to some of them – but in a good way.
- User experience really matters. We are increasingly thinking about who the person is that is using our software – and this seems to me to be really important. For example, tools built by experts for experts usually have small markets – not always but often. Whereas tools built to help non-experts need to be simple on the user side and solve the problem in the black box. Make it easy and understand the use of the user.
So, in short, it's been an interesting first week and really fun.