Apr

24

SDSIC Integrated Product Management and Development - A Case Study

Filed Under business, entrepreneurship, marketing, people i like, product management, project management, san diego, startup, strategy | Leave a Comment

Recently, I’ve been really fortunate to have met so many amazing people, that I can just learn from through osmosis, merely by just hanging around them (the converse is also true, which is why I am careful to stay way from people I don’t want to model myself after). Two days ago, I attended a San Diego Software Industry Council (SDSIC) event on Product Management where a real world case study was presented by Alan Kiraly, CEO of Enterprise Informatics.

When I last took Rod Whitson’s class on product management at UCSD, I particularly liked the real world case studies that we went over. It was definitely a plus that Rod actually had real world experience to draw from. Likewise with Alan, who is also an industry veteran. The other thing I like about an actual face-to-face event is the people interaction, the stuff that you learn that nobody will actually write in a book.

Here’s a couple of things I picked up from Alan’s presentation.

A solidified and well defined business processes can be quite the competitive advantage. Alan talked about how Enterprise Informatics use their own product for their SOWs “lifecycle” management (eating your own dogfood == awesome!). What I particularly liked about this really manages decision making. Once an SOW is defined, if the time is not right, it can be thrown out in the “parking lot”. At a later time, if the opportunity arrises, the SOW can be picked up, dusted off a little, tweaked and be reused by putting it on the development cycle train.

The obvious value here is in saving time and resource in planning. Planning and strategizing stuff takes time and .. well, brain power! Too many times have I figured a whole plan for something, shelved it, and then later when I want to revisit it, I have to redefine the entire plan from scratch again.

Transparency is good. Ok, so nothing really ground shattering here, but it’s nice to hear about real world problems when transparency is not advocated. In a global and diverse organization, with people working across various continents and different timezones, synchronizing work and expectations can be a challenge. I can surely relate to that–my team at work, consist of folks in California, Australia, Israel, China, France, and the UK.
Read more

Aug

26

Holding a program in your head

Filed Under engineering, hacks, ideas, innovation, project management, self improvement, stanford, startup, things to ponder about | Leave a Comment

Here’s some good advice from Paul Graham writes about good practices that any good programmer can relate to.

  1. Avoid distractions. Distractions are bad for many types of work, but especially bad for programming, because programmers tend to operate at the limit of the detail they can handle.

    The danger of a distraction depends not on how long it is, but on how much it scrambles your brain. A programmer can leave the office and go and get a sandwich without losing the code in his head. But the wrong kind of interruption can wipe your brain in 30 seconds.

    Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard.
  2. Work in long stretches. Since there’s a fixed cost each time you start working on a program, it’s more efficient to work in a few long sessions than many short ones. There will of course come a point where you get stupid because you’re tired. This varies from person to person. I’ve heard of people hacking for 36 hours straight, but the most I’ve ever been able to manage is about 18, and I work best in chunks of no more than 12.

    The optimum is not the limit you can physically endure. There’s an advantage as well as a cost of breaking up a project. Sometimes when you return to a problem after a rest, you find your unconscious mind has left an answer waiting for you.
  3. Use succinct languages. More powerful programming languages make programs shorter. And programmers seem to think of programs at least partially in the language they’re using to write them. The more succinct the language, the shorter the program, and the easier it is to load and keep in your head.

    You can magnify the effect of a powerful language by using a style called bottom-up programming, where you write programs in multiple layers, the lower ones acting as programming languages for those above. If you do this right, you only have to keep the topmost layer in your head.
  4. Keep rewriting your program. Rewriting a program often yields a cleaner design. But it would have advantages even if it didn’t: you have to understand a program completely to rewrite it, so there is no better way to get one loaded into your head.
  5. Write rereadable code. All programmers know it’s good to write readable code. But you yourself are the most important reader. Especially in the beginning; a prototype is a conversation with yourself. And when writing for yourself you have different priorities. If you’re writing for other people, you may not want to make code too dense. Some parts of a program may be easiest to to read if you spread things out, like an introductory textbook. Whereas if you’re writing code to make it easy to reload into your head, it may be best to go for brevity.
  6. Work in small groups. When you manipulate a program in your head, your vision tends to stop at the edge of the code you own. Other parts you don’t understand as well, and more importantly, can’t take liberties with. So the smaller the number of programmers, the more completely a project can mutate. If there’s just one programmer, as there often is at first, you can do all-encompassing redesigns.
  7. Don’t have multiple people editing the same piece of code. You never understand other people’s code as well as your own. No matter how thoroughly you’ve read it, you’ve only read it, not written it. So if a piece of code is written by multiple authors, none of them understand it as well as a single author would.

    And of course you can’t safely redesign something other people are working on. It’s not just that you’d have to ask permission. You don’t even let yourself think of such things. Redesigning code with several authors is like changing laws; redesigning code you alone control is like seeing the other interpretation of an ambiguous image.

    If you want to put several people to work on a project, divide it into components and give each to one person.
  8. Start small. A program gets easier to hold in your head as you become familiar with it. You can start to treat parts as black boxes once you feel confident you’ve fully explored them. But when you first start working on a project, you’re forced to see everything. If you start with too big a problem, you may never quite be able to encompass it. So if you need to write a big, complex program, the best way to begin may not be to write a spec for it, but to write a prototype that solves a subset of the problem. Whatever the advantages of planning, they’re often outweighed by the advantages of being able to keep a program in your head.

Disclosure: Paul Graham runs the Y Combinator Startup School held annually at Stanford, so he does have a vested interest in helping startups succeed.

Now that I’ve got that upfront disclosure out of the way, I want to include Paul’s two observations which I agree with, simply because I feel what he says is true.

On why single solo great programmers are productive and get great products out the door,

It’s striking how often programmers manage to hit all eight points by accident. Someone has an idea for a new project, but because it’s not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions. Driven by his enthusiasm for the new project he works on it for many hours at a stretch. Because it’s initially just an experiment, instead of a “production” language he uses a mere “scripting” language—which is in fact far more powerful.

He completely rewrites the program several times; that wouldn’t be justifiable for an official project, but this is a labor of love and he wants it to be perfect. And since no one is going to see it except him, he omits any comments except the note-to-self variety. He works in a small group perforce, because he either hasn’t told anyone else about the idea yet, or it seems so unpromising that no one else is allowed to work on it. Even if there is a group, they couldn’t have multiple people editing the same code, because it changes too fast for that to be possible. And the project starts small because the idea is small at first; he just has some cool hack he wants to try out.

On why large software companies sometimes don’t realize that they work against these good practices for programmers,

Even more striking are the number of officially sanctioned projects that manage to do all eight things wrong. In fact, if you look at the way software gets written in most organizations, it’s almost as if they were deliberately trying to do things wrong. In a sense, they are. One of the defining qualities of organizations since there have been such a thing is to treat individuals as interchangeable parts. This works well for more parallelizable tasks, like fighting wars. For most of history a well-drilled army of professional soldiers could be counted on to beat an army of individual warriors, no matter how valorous. But having ideas is not very parallelizable. And that’s what programs are: ideas.

It’s not merely true that organizations dislike the idea of depending on individual genius, it’s a tautology. It’s part of the definition of an organization not to. Of our current concept of an organization, at least.

He then concludes,

Perhaps the optimal solution is for big companies not even to try to develop ideas in house, but simply to buy them. But regardless of what the solution turns out to be, the first step is to realize there’s a problem. There is a contradiction in the very phrase “software company.” The two words are pulling in opposite directions. Any good programmer in a large organization is going to be at odds with it, because organizations are designed to prevent what programmers strive for.

There is some truth to that. Established software companies have their own marketing departments. However, they sometimes tap outside marketing firms for help in their programs. Some things are just better when produced outside of the company. Are ideas and rapid-prototype software development one of them?

Apr

19

“Next Action”: Identifying the next step

Filed Under goal setting, project management, time management | Leave a Comment

If you work on multiple projects at work, you will realize that it’s pretty similar to juggling balls in the air with your two hands. You might be thrown a new ball in addition to what you already have in the air (new project), you might be trying to place a ball on the ground without dropping the other balls currently in the air (tying up any open ends left on a mostly finished project), and perhaps you might also have your eyes peeled for the next ball you want to juggle (perhaps you have a semi-vivid vision of a project that will positively impact your team/dept/company’s bottom line).

If the above sounds familiar to you, then perhaps the phrase “analysis paralysis” would also ring a bell. Analysis paralysis is described in Wikipedia as an informal phrase applied to when the opportunity cost of decision analysis exceeds the benefits. In other words, too much planning or a discussion that goes nowhere, and no execution. Also known as “all talk and no bite”. I really hate that.

I’m a fan of David Allen’s GTD book and it has helped me manage my work flow better. In it, he talks about the “next action”, and I have come to realize how much important it is just being able to identify what to do next, without actually doing it yet. I’m trying to emphasize the value of planning without executing immediately which I have discovered by experience, speaking as a guy who likes to execute immediately after planning, and doesn’t really care about planning right away, after executing.

When multi-tasking and switching between tasks so often, it is easy to lose track of the end goal of each individual project. This is especially true when operating in an R&D environment where you are pushing the limits — so by definition, your end-goal cannot be rigidly specific. I found that planning the current project’s next step before temporarily halting it to work on another project to be a huge load off my shoulders. Allow me to illustrate.

My work queue would look similar to an old-skool single core processor (with no hyper-threading) such that at any given time, I am focused on a single project. Each project (because they are large), are broken up into smaller bite-size chunks.

Time t1=0 t2=t1+n t3=t2+m t4=t3+x t5=t4+y
Project A
(step 1) 		Project B
(step 1) 		Project C
(step 1) 		Project A
(step 2) 		Project B
(step 2)

After step 1 in project A and before step 1 in project B, I first identify the next step (as step 2) for project A, with the understanding that I’m just merely identifying the next step towards project A’s goal, but I will not actually do it yet. Then, I move on to execute step 1 of project B. Likewise with the end of project A, after step 1 of project B, I quickly determine project B’s step 2 before moving on to step 1 of project C.

What’s nice about this is that after I am done with step 1 of project C, when going into step 2 of project A, I no longer have to dig up my recollection of where I last left project A. I don’t have to ask myself, “alright, where did I last leave this project?”, and “Okay, now what was that next incremental step that I had meant to take again?”. I had already thought out the “next actions”, as Dave Allen would call it, and I can jump right into execution mode!

On the flip side, what I did before was that I would jump into execution right after planning a next action, resulting in me spending too much time on a single project, and neglecting other projects. In operating systems theory, that would be the equivalent of thread starvation because another thread is hogging all of the CPU. Also, from a psychological perspective, the longer you have neglected a project, the harder it is for you to jump back in it. Why? Because so much has happened since then, and now it’s way more difficult to remember where you last left it.

In addition, while working on my current project, my mind will often worry and think about that other neglected project — which is really unnecessary and just eats up memory and brain power, causing severe inability to focus on the current issues at hand.

I’m an advocate of action and don’t like worrying, so I prefer to act on a worry, than to worry. Acting on a worry gives me a peace of mind.

The secret of getting ahead is getting started. The secret of getting started is breaking your complex overwhelming tasks into small manageable tasks, and then starting on the first one.
– Mark Twain


Getting Things Done: The Art of Stress-Free Productivity

Getting Things Done: The Art of Stress-Free Productivity

Oct

15

Discourage politics, use data

Filed Under google, product management, project management | Leave a Comment

BusinessWeek has this excellent article about how Google (more specifically Marissa Mayer) runs meetings. What stood out to me the most is #5: Discourage politics, use data

This idea can and should apply to meetings in organizations in which people feel as though the boss will give the green light to a design created by the person he or she likes the best, showing favoritism for the individual instead of the idea.

Mayer believes this mindset can demoralize employees, so she goes out of her way to make the approval process a science. Google chooses designs on a clearly defined set of metrics and how well they perform against those metrics. Designs are chosen based on merit and evidence, not personal relationships.

Mayer discourages using the phrase “I like” in design meetings, such as “I like the way the screen looks.” Instead, she encourages such comments as “The experimentation on the site shows that his design performed 10% better.” This works for Google, because it builds a culture driven by customer feedback data, not the internal politics that pervade so many of today’s corporations.

Well said. Too many times have I seen favouritism/politics trump true merit, inconvenient hard-facts that are just “shrugged” off (and left at that). Or just be given some lame excuse (so shoddy and shady that it wouldn’t stand fact-based scrutiny) of why the idea “wouldn’t fly”.

By definition, sheer hard work and determination won’t help since merit isn’t appreciated. The solution? Cut your losses and get the hell out.

Jul

24

Software engineer today? More than just l33t hacking skillz!!

Filed Under career, engineering, geeky, project management, self improvement | Leave a Comment

Today, it is not enough just to be technically competent to survive. Yeah, yeah, everyone says that, but I found some numbers today. According to the annual Design News salary survey, these are the skills participants found most important (from most important):

  1. Project management and communication/presentation skills (86%)
  2. Computer skills (85%)
  3. Team-building skills (64%)
  4. Language skills (43%)
  5. Marketing/sales skills (35%)
  6. Finance/accounting (31%)

Who would have guessed that the #1 most important skill is communication? (Shocker, it’s not some l33t rare proprietary system hacking skillz. Us geeks have been trained in college to work in a dark windowless basement without talking to each other that communicating our ideas effectively is just naturally un-natural, to say the least.

Delivering results on time and within budget is also an obvious, although no where in a regular computer science curriculum is this strongly emphasized. However, this shouldn’t be a problem for students that have completed their operating systems class. Remember the fundamental concepts in threading, process and memory management? It’s all about juggling multiple tasks with finite memory space and a single processor. Same thing usually applies in the real world — you will have a finite resource/budget.

I’m sure someone can write up an algorithm for their project management needs. Here’s a pseudo-code algorithm:

  1. Identify the “projects”, tasks that need to be worked on (deliverables)
  2. Prioritize each task — use appropriate metrics (e.g. urgency, due date, cost, risk, etc.)
  3. Execute, and don’t drop the ball! Feel free to apply threading and pipelining concepts e.g. make sure no threads get “starved”.

Other advanced concepts that you can also apply from the OS class are such as solving deadlocks (process contention), reducing overhead cost when task-switching too much, and pipeline “hiccups”.

Also, I would highly recommend applying the infamous GTD concepts. I have learned to apply the GTD toolkit and I have managed to tie up many of the loose ends in my life that were just bogging me down (too much overhead). I like to think of it as reducing the number of background processes, giving me more memory and processing power for other things!

Perhaps CS grads are also lacking in the leadership department, because students are too busy competing to out do each other in grades that they didn’t get the memo telling them that in the real world, people are supposed to work together — performance reviews/appraisals replace “grades” and the need for leadership skills become more relevant and important.

That shouldn’t be a problem either. Any competent CS grad cannot call himself a “computer scientist” if he doesn’t carry his problem-solving algorithm toolkit with him at all times. Many hackers have used these general problem solving principles to solve non-technical problems. The Hacker’s Diet is a very good example a person determined to lose weight by approaching it as an engineering problem. The key resource in this weight problem? Determination.

Rick Johnson, president of Cherry Electrical Products says:

“My experience is that all companies prefer technical people in these [management] positions. The opportunity here for an engineer to continue in engineering is to add to his/her leadership skills. All engineers are taught to solve problems. If an engineer pursues acquiring leadership skills … they will have huge opportunities in store for them in the future. Alas, most engineers just ignore this aspect of their personal development preferring instead to learning more and more about the latest technologies.

Full article at Design News.