 |
|
|
|
| |
 |
I
had been working for two years as the technical Product manager for a
large software company, when their partner company gave me call. They
needed Good software engineers to customize a new version. Of software,
and they thought I was their guy.
They told me what they wanted to do to the software, and they even
showed me some prototypes. Their idea was to take the basic software
tool that the large company was producing and make it more accessible
to the customer. They would do this by building in flexibility based on
user skill level and organizational maturity. I thought that was a
fascinating approach, and I bought into it in a big way. I decided to
leave my job and join up with the smaller company as their director of
software engineering.
You'd Better Know the Shot
My former employer was a massive organization with tons of money. They
can afford to try, try, and try again -- but even they hate to do that.
At a startup, you typically have one shot. Screw up, and you're dead.
| Managing software has a lot more to do with
people than it does with processes. |
We were taking a product designed for everyone and trying to make it
work for a smaller set of users. Here is something I learned quickly:
When you're modifying a commercial-off-the-shelf (COTS) product, it
makes a huge difference if you have inside information. Why? Because
there are undocumented features, a.k.a. bugs, which only people with an
intimate knowledge of the product will know how to work around. It's
something to think about when you're going to tailor a COTS product:
How extensible is it from the get-go.
We were okay because the person I had recommended to the company, a
hotshot at my former company, had gone to work with them. He knew
things about the old software that the current team didn't even know.
But even with him on our side, we were bootstrapped with limited
resources. We needed money, so we had to find a client.
What the idea looks like.
At that point we had our working prototype. (I'm a firm believer that
prototypes are the best way to communicate a vision.) We showed it to
people and heard things like, "Oh yes, this is interesting." We had a
few customers in mind, and we visited all of them. It helps to get
feedback from your customers as early as possible (again, the prototype
was invaluable). Plus, there's the other side of the equation, which is
making certain that your customer has a sense (not a lot of detail
necessarily, but a good sense) of the engineering constraints of your
development effort.
We found a few small clients willing to pay for some of the research
and development we needed to keep going. After a while, we got enough
traction to go after the real capital -- we needed VC money. That was a
scary proposition. We couldn't just go in and say, "Give me some money
because I have a great idea." These people were very technical and very
sharp. But we apparently said the right things, because in the end we
got the money we needed. That took some of the pressure off. We now had
enough money to survive on, but a very short period of time (about a
year and a half) to develop a product.
Closing in on the Deadline
This was early 1999. At that point, I was trying to hire the
development team that would take our product to the next level. Because
we had to get things done quickly, we couldn't afford to sit around
thinking about the design for eight months before we wrote any code. We
decided to take a milestone approach, where you basically pick a number
of features or a quality bar - something -- put a date on it, and run
towards that date.
We chose a rapid development programming language as the first
technology to implement this software. We did this because the software
was more readily modified as customer feedback came in. When we would
show the software to the customers, they would say, "I think you should
have this," or "Based on my experience it should do this…"
Then we could turn around, go to engineering for a couple of weeks and
send a version of the software back to the customer that did what they
were describing.
No Time to Play
That was helpful early on because we could get the customer's viewpoint
almost immediately. It's also a wonderful way to force your developers
to buddy up with the Quality Assurance guys and get things done. That's
important because the natural instinct for software developers is to
treat the project like a box of Legos. They want to take it home to see
what they can create. You have to ask, "Okay now, is the customer
really going to have a better experience if you put one more layer of
lacquer on that sucker?"
Their answer is usually, "What's a customer?"
As a project manager, you have to be able to take these people who
think they are just playing with Legos and get them to do things on
schedule and on budget. You have to make certain they understand the
business purpose for what they're developing. The role of the project
manager has to be to articulate business requirements to the developers
in a way that gets them jazzed -- like reminding them that they're
doing something good for the company, or whoever the target is in the
end. When it comes to managing software, I've found that it has a lot
more to do with the people than it does with the processes.
Getting too close.
Our ultimate constraint was a window of opportunity, which was rapidly
closing. Our one competitor was getting ready to release. We had some
money, but we still had to do what's referred to in the industry as a
"death march" towards our deadline.
I was the development manager, or what is effectively the project
manager -- and I made the absolute worst mistake a manager can make. As
development manager, your job is to delegate, but I couldn't keep my
hands out of the coding.
Originally, I didn't think that we had the manpower to separate the
functions of management and development. In hindsight, we should have.
I was working on a number of low-level subsystems, and other developers
couldn't get started on their work until mine was flushed out. I was
supposed to be managing these people, and here I had put myself on the
critical path.
It was just a crazy time. I lost 20 pounds. My team kept asking, "What
happened to our development manager?" I would go into my office before
it was light, and I would leave after it was dark. Instead of meeting
with them to talk, I was "instant messaging" my leads to get status
reports, because I was busy cranking out all of this code.
A high price for success.
We launched in October 2001, and it was a big success. But I had to
take a hard look at myself and ask, "At what personal cost?"
I had previously thought of the developers as the guys who got wrapped
up in creating rather than efficiently tailoring a product to the needs
of the customer. Now I was faced with the truth: I had become one of
the Lego people, obliviously adding layer after layer of blocks. Don't
get me wrong -- we software people do it because we love it, we have a
passion for it. But I had let myself become overtaken by just one
aspect of the project rather than the whole. I was losing weight, never
seeing daylight, having virtually no person-to-person contact with my
team...
It was a great experience, but I wouldn't do it again. I had to figure
out the hard way that software itself is not the answer; project
management is the answer. It's all the people, processes, and
technologies working together. Rather than being one of the Lego
people, I knew I needed to figure out exactly how to motivate them so
that together we could create products that make good business sense.
Lessons
- When tailoring a COTS software
product, you should recruit developers who have an in-depth
understanding of the intricacies of the product.
- Establishing open communication
with your customer is not only intended to understand customer
requirements but also to convey challenges you face on the project.
Question
How does an active project manager effectively delegate and manage
without "sticking his hands in" the actual project?
|
Search by lesson to find more on:
 "I wrote my first piece of software when I was
11," says Colby Africa. "When I was 15, I wrote my
first production software, which was promptly rewritten by a
13-year-old, who went on to work at the media lab at MIT. The lesson
there is that someone is always smarter and younger than you are."
In spite of his prodigious gifts, Africa never intended to become a
software developer. At Microsoft from 1994 through 1999, he rose
through the ranks to become a product manager -- making time to write a
little software on the side. Today, he works for Robbins-Gioia, a
project management consulting firm in Washington, D.C., and is too busy
assisting project teams around the country to write any software code
even if he wanted to.
"I have a bunch of developers who work for me now," he says. "Whenever
I want to get my fix of software, I have them show me something cool
they're working on." |
|
|
|
|
