One of the things about starting a company is that you’ll have to wear a lot of hats. I always had this image of an entrepreneur wearing a bunch of different hats all at once. Kind of like this. They’d be wearing a “Marketing” hat, an “Engineering” hat, a “Finance” hat, a “Sales” hat, etc. I’m sure there are people that can do this — with panache, even — but I’ve personally found that I’m only comfortable wearing one hat at a time. Take consulting and engineering. When I’m a consultant, I talk (and think) about process and organizational change. When I’m an Engineer, I talk and think about zero conf jeos virtual appliances and version control systems. I can switch hats, but it takes a day or two for me to really get into the role.
…make light work
At this point in my startup’s life, we have a v1.0 of our product ready to release and a beta customer that’s been using it for the past 4 months. In order to keep the lights on (i.e., make light work :-)), we’ll have to find at least 3 more customers. That means that I’ll need to take off my “Engineering” hat and put on a “Marketing” or a “Sales” hat — I’ve been struggling with which should be first. Drucker noted that Marketing and Sales are opposites in some sense:
…the aim of marketing is to make selling superfluous. The aim of marketing is to know and understand the customer so well that the product or service fits him and sells itself.
If the product fits the market well, then getting the customer to buy is easy. If the product doesn’t fit the market, then getting the customer to buy is hard — you’ll have to do more selling. This makes sense to me. Since I want our product to sell itself, I’m thinking that I should try the Marketing hat first :-).
When I’ve gone out to demo my product to people, I’d catch their interest but would inevitably lose it again, seemingly at random. I wasn’t sure what was happening. I described the product features in a logical progression that made sense to me, but I wasn’t able to fully engage my audience. I didn’t get it. We have this amazing product that solves some of the toughest and most important problems organizations face, and for some reason I couldn’t get people to see it!
Fortunately, a friend of mine, who works at an innovative marketing firm in downtown Portland, was nice enough to drop by and set me straight. He outlined some useful Marketing concepts:
- Positioning statements: These are brief statements that describe what your company does. For instance, if you go to a networking event and someone asks what you do, this is what you say.
- Value statements: This is the benefit of your product to a customer. When they ask “So what?”, this is what you tell them.
- Differentiators: This is what makes you different (and better) than competitors or competing options.
The key to all of this is that you don’t just have a list of value statements; you have a list of value statements for each type of audience. This became very clear when my friend asked “What is the value an engineer gets from your product?”. I responded, “Oh, they want something that doesn’t get in their way, something that doesn’t have much overhead to use”. Oddly enough, this was the first time I’d ever said that explicitly. I instantly realized that this was why my demos weren’t effective. In describing the product logically, I’d inadvertently emphasized the wrong features at the wrong time to the wrong people. I wasn’t recognizing the perspective and concerns of my audience. Engineers didn’t care about the same features that executives cared about. Why should they? No wonder my demos were hit-or-miss.
Right now, I have my Marketing hat on. I’m going to keep it on until I have positioning matrices filled out for each of our market segments. Once these are done, I’m going to slap on a Sales hat and find customers to talk to. Unfortunately, I don’t really know what a Sales hat looks like. For some reason, I have this image that’s a cross between Willy Loman and Darrin Stevens. I picked up some books to help me figure this out, but I think I’ll just need to sit down with a salesperson on this one. I’ll have to do this soon because my company doesn’t have much ramp left before we hit the road.
As I’ve been writing this, the final scene from Spinal Tap (scrub to minute 4) keeps looping in my head:
Nigel: Well, I suppose I could, uh, work in a shop of some kind or…or do uh…freelance…selling of some sort of…uh…product, you know…
Marty: A salesman, you think you —
Nigel: A salesman, like, maybe in a haberdasher, or maybe like um…a chapeau shop, or something…you know, like: “Would you…what size do you wear, sir”, and you answer me.
Marty: Uh…seven and a quarter.
Nigel: “I think we have that…”, you see, something like that I could do.
Marty: Yeah… you think you’d be happy doing something like —
Nigel: “No! We’re all out, do you wear black?”, see, that sort of thing I think I could probably muster up.
Marty: Do you think you’d be happy doing that?
Nigel: Well, I don’t know – wh-wh… what’re the hours?
In 1993 (wow, has it been 16 years?), I was working at a startup called Synthetica Technologies just outside Berkeley. It was a fun job, but it wasn’t going to be my career — I wanted to get a Ph.D (I wasn’t entirely sure why, it just seemed like the next step). Looking back, I have no regrets, but what I got out of grad school was certainly different than what I expected.
Getting in to Grad School
Before you can experience grad school, you have to get in. Whether you get in or not is result of several factors: your GPA, the school you went to, your GRE scores, your essay, and your letters of recommendation. If all of these are stellar, you’ll most likely get an offer. If any of these things is a bit off, you’re on shakier ground and might not. But there’s something you can do to help tip the scales…
The one thing that, in my experience, can outweigh any of the factors above (and maybe all of them combined) is convincing a professor with funding to express an interest in you. When my wife and I were applying to grad school we sketched out a plan to visit a number of schools across the country. We started in Boston (since I was there for a business trip for Synthetica) and went down the East Coast and then across the country. On Amtrak. In winter. During the Blizzard of ’93. In our California wardrobe. I’ve never been so cold in my life. It turns out, the timing of our trip was opportune. When someone from California has taken Amtrak across country and is hoofing it across town in a windbreaker in a blizzard just to see you, you tend to remember them. The professors were welcoming and I had some good conversations. In the end, we got offers from every school we applied to.
Making the Cut
As soon as you accept the offer to become a doctoral student, you begin a competition for spots on a roster. I wasn’t aware of this. I thought that once you were accepted, it was kind of like college: you don’t screw up too badly, you graduate. Not so.
The first two years of a doctoral program involve the same coursework you’d do for a Masters degree. The department professors will teach a range of courses in your field. You will demonstrate your mastery of the subject matter, but you will also be observed in other ways. How well do you interact with others? What is your style? How insightful are you? What do you bring to the conversation? Would you make a good peer?
At the end of the two years, you take a Qualifying Exam, an all-day test spanning the breadth of your field. It’s the Mother of all Finals. This, combined with your coursework and what professors have observed about you, determines whether you stay or hit the job market with a Master’s.
The Next 3 Years
If you make it through the Qualifying Exam, you’ll typically need another 2 to 3 years to get your doctorate (although there’s no specified time). This is when you’ll do your research, when you’ll go deeper into a subject than anyone has gone before. After you figure out what topic you intend to research, you propose this to your dissertation committee. Because you’ll eventually become the expert in this area, your committee won’t really know what will come of your work. Their goal is to make sure you’ve done due diligence in selecting your topic, that you’ve done enough preliminary research to justify more extensive work. After you successfully defend your proposal, you’ll do more research. Write more papers. Present at conferences. Publish in journals. And, in the meantime, write your dissertation.
An interesting thing happens during this time. Doctoral candidates self-select into two groups. One group figures out (or is told) the rules of the game. The other group never figures out the rules (or is told but ignores them).
I’d always been idealistic, and so the biggest revelation to me about grad school (and academia in general) was that there were politics involved. I’d imagined academia as a pure pursuit — people working together to better understand the world. It’s not like that, or at least not entirely. The ivory tower is guarded. Every discipline has a political terrain.. The game is figuring out how to navigate it. This isn’t about understanding ideas; it’s about understanding people and their motivations. You need to do more than study articles, you have to study the authors as well. You have to meet the right people and figure out how to collaborate with them to carry out research, write articles, and present at conferences. This requires an entirely different skillset than what you’ve developed to this point. You probably don’t have time to learn this and write your dissertation at the same time. That’s where your advisor comes in.
Your advisor knows how to play the game. Your advisor may give you general advice like “try to get two papers published this year” or more specific advice like “go to the conference in Utah this summer and meet Professor X” (not the Professor X, of course, though how cool would that be? 🙂 ). Your advisor may even flat out tell you what to do: “Look, if you want a teaching job, you need to co-write a paper with these three guys because a position is opening up at University X and the chair of the search committee will ask at least one of them for their opinions on candidates”. Your advisor is the person who’ll have the biggest impact on your academic career (other than yourself, of course). Heed their advice and if they don’t offer it, ask..or ask elsewhere.
If you do find yourself in grad school, take advantage of it. This is a special time. Although you’re working hard, you get to set your schedule and how you work (it’s like bootstrapping a company). If you want to read articles at Longwood Gardens, go right ahead. If you want to tour the East Coast in between conferences, no problem. I’ve often observed that it’s kind of like living some of your retirement years when you’re still young — you get discounts everywhere, the only catch is your fixed income (stipend).
The one thing you should absolutely do in grad school is this: network. Attend events for grad students. There’s great food (at Penn, some of the best food in the country). There are well-connected people. And your peers will eventually go on to do great things. I should have done this more. It would have been more valuable than studying fluid mechanics or reactor design (especially given that I’m writing web apps now). If you have the choice between coursework or attending a networking event, please network — it’s a great way to learn the game, get a good meal, and meet people you’ll one day read about. The doctoral students that want to play the game and learn to play it well move on to teaching positions. The ones that choose not to play the game or who don’t play it well enough will have to find jobs. Or start companies :-).
Note that everything in this post is based on my particular perspective and experience. If any of this sounds wrong to you, please feel free to comment…
Oh, and thanks, Lyle — you were a great advisor!
Last week, I gave a 2-day workshop on project management. I focused on what I call the Five Principles for Project Success. It’s been my experience that when any of these principles are violated, a project is headed for trouble. Conversely, if a project is in trouble, reviewing these principles is critical for recovery.
Everyone involved in a project at every level should always know the project purpose: who cares about a project and why is it important. People should know the project drivers (e.g., cost, quality, target date, feature set, stability, usability, performance, flexibility, accessibility, …) and how the drivers are ranked. This is the only way to rationally make tradeoffs within and across projects.
The project purpose is frequently overlooked because we tend to focus on the work that needs to be done and often get started on it without asking why. When this happens, we tend to work on tasks we want to work on, not necessarily what’s most important for the client/customer and stakeholders. We don’t move the project in the right direction, if in any direction at all. There’ll be plenty of motion, but not much progress. At some point (when the budget or schedule gets tight), we’ll have an emergency meeting to figure out what should be done and finally the project purpose will be recollected or even spelled out for the first time. Great, but too late. There won’t be room to recover.
The project purpose should be defined up front, and, again, everyone should know it. The purpose should be captured in something like a “Project Charter”. Johanna Rothman describes these charters in her book Manage It!.
The most famous quote on planning is probably from Eisenhower: “Plans are worthless, but planning is everything”. Ike said it in the midst of the Cold War, but it’s a timeless observation. When engaged in planning, we’re considering options. We think through risks and how we might address them. We lay things out, we make assumptions, we make choices. At the end of this we have a plan. However, no matter how thorough our plan or how much thought we’ve put into it, the plan can only reflect what we know at a given point in time. Things change. We may run into a set of unanticipated problems or perhaps the risks we did consider didn’t really have the impact we feared. When this happens, we should adjust the plan. We should re-plan.
Without planning, projects will be left to chance. Risks will come as a surprise and quickly derail a project. People will be constantly shooting from the hip, making decisions based on urgency instead of value, reacting to events instead of anticipating them.
Planning is something we should do throughout a project. When a plan is no longer useful, we should draft a new one. The plan itself is only a snapshot of what we knew at a point in time.
To make rational decisions about projects, you need to track project data. Period. This isn’t something you get from chatting with someone. When you ask “How are things going?”, you’ll get a response like “Pretty good. I think we’re going to be done with this next phase soon”. What does that mean? What does that tell you? When someone says something like that, I hear “We’re not done yet”. You need a finer level of status than that. You should be able to answer questions like this at any point during a project:
- Is the project running late? By how much?
- Is the project over budget? By how much?
- Which tasks can be started now? Are any of them late off the bat?
- Is the project resource-bound? Where are the bottlenecks
- What are people working on?
If you don’t have tracking, you won’t know if your projects are in trouble until the end. Key decisions will be delayed. Teams will miss important dates. The sense of urgency that should have come earlier in the project will come too late.
Tracking project data can be straightforward and easy if you have the right tools. If you set up your projects efficiently, tracking them basically boils down to logging effort left and effort spent. It can be that simple (with the right tools :-)).
Demos are the real measure of progress. If you can show something working, then you’ve actually done something. If you can’t demo anything, then you really don’t have anything of value. Demos are great because they expose assumptions. They ensure that details are looked after. They get everyone on the same page, something especially important when there are several teams involved.
If you don’t do demos, teams that can work separately will — and they’ll work in isolation. Work won’t be integrated until the very end of the project. Everyone will feel their part is on track when, in reality, much of the work is yet to come. When integration finally does arrive, it will take much longer than everyone expects. There will be unanticipated rework, cost, and stress.
Demos are something we should always plan for in our projects. They can be fun. They give people a sneak peek at something that no one else has ever seen. It’s a time for teams to get together and show off, when executives get to drop by and see progress, a time to re-sync before moving forward again.
Consistency is about predictable execution. It’s about dispatching work efficiently and having clean handoffs across teams. When you have consistency, your organization runs like a well-oiled machine. This can only happen when roles and responsibilities are clear, when processes are well-defined, and when people have the skillsets to play their roles.
If you don’t have consistency, you’ll waste a lot of time reinventing process on the fly. Tasks will be dropped, especially across team boundaries. There will be gaps in process, gaps in task assignments, and gaps in skillsets. Execution will stall and be unpredictable.
To become consistent you need to think through your processes and capture them in some form. Swimlane charts are a good tool to use here because they force you to think not only about what needs to be done, but also who should be responsible for it and what sequence the work should follow. It can be an interesting exercise to get people together to sketch out a process because it will quickly become obvious that everyone had a slightly different view of the roles and responsibilities. Getting clarity around this early-on improves consistency of execution.
These are the principles that I’ve found to be crucial for project success. Time and time again, these are what I point to when projects go wrong. Of course, there are other principles “embedded” in these five (e.g., communication runs through everything above). If you can think of a principle not covered above, please feel free to comment!