ed weissman

I never say “No”. 

I just say, “Yes. And this is what it will cost you to do it right:” 

- Projects X, Y, Z will all be pushed back 2 weeks. 

- Prerequisite Project will have to come first. 

- weeks overtime for people = $z. 

- Joe and Mary will have to be pulled away for 3 weeks. 

- Interim solution will only take 1 week, but won't work. 

- We will need your top supervisor full-time next week. 

or, best of all: 

- We don't know. We need a project to find out. 

Note that “doing it wrong” or “doing it quick & dirty” are not options. 

People understand “this is what it will take” a lot better than “no”. They also understand the trade-offs and sacrifices needed. Then they will work with you to make the best decision for everybody. 

“Despite all this every time I sit down to code my brain turns to mush, somehow, and nothing gets done. I can always give my managers an intelligent explanation of why progress is so slow…”

Oh, so this happens at work…This exact same thing has happened to me many times and here is what I figured out…

The problem is NOT with you, it’s with the work.

Like you I have scored excellently on interviews and tests and have written code so cool I even surprised myself. So we have to believe that we are as good as we think we are. That belief is what enables us to take on the hard projects. That belief is also what turns our brains to mush when our work is too many levels below our capabilities.

Sure, we all do work below our level every once in a while; we have to, that’s the nature of the beast. But when you’re doing low level work for too long (like at many jobs), you lose energy from the lack of stimulation. We then mistake that lack of energy for many other things: our skill, our commitment, even our health.

Here’s what I’ve done in situations like yours: build something cool on your own time. It will get your juices flowing and you’ll be your old self in no time. Of course, you’ll want to work on your own project instead of your employer’s, but that’s another problem.

“You will NOT become an engineer, programmer, or web developer, but you will be able to put a prototype of your idea together and maybe get one or two beta users for feedback…”

You will also be able to have an intelligent conversation with a developer.

I get sad whenever I encounter a business person with no technical BS filter. Not because I’m judging them, but because if I can BS them, any other developer can. Which probably means there’s a problem somewhere that will hurt all of us.

I’ll make a point to have a cursory understanding of financial statements, market segmentation, and project management if you do the same for the basic building blocks of software applications. Then the two of us will be able to talk about almost anything. OK?

I hate to break the news to you, but “systems analyst” is a job title that’s pretty much exclusive to the enterprise world. For the most part, start-ups don’t really have a place for “business/system analysts”. Let me explain…

School of Thought A: Call it SDLC (Systems Development Life Cycle), the project approach, or the waterfall approach goes something like this: Define a need, conduct analysis to answer the question “What”, conduct design to answer the question “How”, program, test, program, test, compare to the Functional Specs from the Analysis Phase, conduct User Acceptance Testing, promote, deploy, repeat anything as required. The more rigorous the documentation and project management, the better.

School of Thought B: Build something ASAP. Get it out there ASAP. Get feedback ASAP. Iterate
indefinitely.

For the most part (I’m sure there are many counter-examples), enterprises employ School of Thought A and Start-Ups employ School of Thought B. There simply isn’t a need for systems analysis in School of Thought B. By the time you’re done analyzing, someone else is servicing the customers you sought.

My advice: Combine a love for building stuff with your love of systems analysis. They go perfectly together. In fact, we now have a name for that: “programmer/analyst”.
 
The systems analyst who can code is a better systems analyst because he can test/evaluate his ideas. The programmer who can conduct analysis is a better programmer because he knows what to work on. This may not be what you wanted to hear, but you’re in a perfect position to do both, so do it.

Trivial example of what people need to know in enterprises: 

“Tell me whether pet rocks are selling better than Barbie dolls in the south?” 

What people really need to know: 

I already know from existing reporting that 984 orders (18% of our backlog) are already past due. For those 984 orders:

- How many are for one item and how many are for multiples? 

- Do we own what we owe those customers? 

- If we do own it, is it in the proper warehouse? 

- If it is in the proper warehouse, can we find it? 

- If we can find it, is it undamaged and certified? 

- If it's shippable, do we have enough labor to ship it? 

- If it isn't certified, how soon can QA certify it? 

- If it isn't in the right warehouse, can we move it? 

- If we don't own any, where can we get some? 

- Which vendors have it on the shelf? 

- Which vendors do we have blanket purchase orders with? 

- Which vendors do we have contracts with? 

- Which orders can be split to satisfy a partial? 

- Which orders are for customers already on credit hold? 

- Which customers are threatening not to renew with us? 

and (ironically) the most asked question of all: 

- Which orders must be shipped to hit our quarterly numbers? 

I can go on and on; this is just off the top of my head. We like to pick on enterprises, but this is the stuff that happens all the time. So whenever you get gas in your car, bread on your table, new shoes at the mall, steamed milk in your latte, etc., rest assured that “someone”, “somewhere” has asked these questions. Questions that were probably answered using some form of RDBMS, SQL, ACID technology (with really good application software on top of it). 

Wanna know the biggest difference between you and me? I’m pulled. You’re pushed. Let me explain…

I love building stuff. Nothing gives me a bigger rush than getting something working the first time . But I couldn’t care less about the technology. If an abacus, two tin cans on a string, or some BASIC code on a Kaypro II did the job, then that’s what I’d use.

What I really care about is how my software is used. And who uses it. There’s an endless stream of people who need stuff and an endless stream of problems to solve. For individuals, groups, and businesses. When I encounter a new problem to work on, I use whatever I can apply in my tool box. Sure, I have to upgrade that tool box every so often because I need more to solve my problems, not because I love the toys so much.

You sound like the opposite. You love the toys and look for places to use them.

My suggestion: Take a break from the technology and put yourself in more situations where people can share their problems. This will give real human meaning to the technology. I bet you’ll be chomping at the bit to build something for someone in no time. For me, being pulled by a demand motivates much better than being pushed by a supply. Maybe it can be for you too.

You have to get your prospects to think that what you’re offering was their idea all along. 

How do you do this? 

Get to know them. Spend time with them. Find out what their lives are like, what they have to go through to compete, and what makes them suffer. Jump into their pool at the deep end and learn how to swim. Walk through their warehouses, customer service departments, and general offices. Sit down at their computers and try to do their jobs. Get them talking. 

Once they see that you are sincere and have something to offer, they will not be bashful. They will tell you everything you need to know to help them. This will do 2 critical things: 

1. It will provide specific feedback about what you’re building or have built, whether or not it makes sense for them, and what to change/fine tune/refocus. It they need it like that, chances are that many others do too. Your first prospects have unwittingly been the best focus group you could have assembled. 

2. You will be offering exactly what they asked for so they will have few excuses not to buy. Do not underestimate the solid gold of this approach; it works incredibly well. 

Call this good sales and marketing if you want but I never have. I just call it doing whatever it takes to help your customers. Becoming successful is a byproduct. 

My customers. 

My customers do great things. They often need my software, built and functioning properly for years to do these things. I love building stuff, but they are the real heroes. Just some of the things that they do:

- get the right drugs get to the right people 

- get the ambulance to the right address 

- get the right materials purchased and delivered 

- get the right product built, on time and budget 

- get the right product shipped accurately and on time 

- make sure the parts going into that airplane are certified 

- make sure your insurance claim gets processed properly 

- make sure they make enough $, so they can keep doing it 

I can go on and on, but you kinda get the idea. I love to learn, to optimize and refactor, and to build beautiful things. But what I do pales in comparison to what they need to do. I never forget that. 

1. Help each laid off employee land on their feet, whatever that means for them. This must NOT be lip service, but a legitimate effort. Hire an outsourcing firm, provide resume/career counseling, provide reference letters, or find job opportunities with vendors, customers, or industry contacts. 

2. Make a clean transition. Give laid off people an opportunity to share what they were working on and debrief others. Even though they are leaving, many people value the work they have done and want to know that it’s in good hands. If you don’t do this, you might as well be saying, “We can figure out what you were working on without you.” Nothing else you say or do will offset the damage this will do. 

3. Find a way whenever possible for people to keep contributing as contractors or part-time employees. 

4. Find a way for people to keep their health insurance. 

5. Offer severance whenever possible.

As uncomfortable as a layoff can be, it’s also an opportunity to show how well you can do the tough stuff. 

People will be watching and remembering; count on it. 

“…it is 100% necessary to send an email…” 

I take it a step further. I always send a hand written Thank You Note by snail mail. Always. I have never failed to do this. 

Why? Because if someone has spent an hour of their time (I don’t care if it’s on company time) to potentially change my life, the least I could do is take 5 minutes to share a sincere Thank You. I always take the time to hand write it, I always make it personal, and I am always sincere. (If you’re going to be even 1% phony, don’t bother, people will see right through it). 

There are some nice byproducts. It demonstrates professional courtesy. It demonstrates good communication skills. It demonstrates good customer service. It gets you remembered. Every time. 

But I don’t do it for these reasons. I do it because it’s the right thing to do. It is never “annoying” or a “detriment”. Almost everyone I have ever sent a hand written note has told me that they really appreciated opening it and reading it. 

Sometimes I even take it a step further. Several times, I have asked public speakers what their favorite restaurant is, and then sent a gift card in the Thank You note. I really want them to understand what a difference their contribution has made in at least one attendee’s life. The gift card is a nice idea because I know they will use it and enjoy it, and maybe even think of me that night. I would never send a gift to an interviewer - that’s not the same thing.