Friday, October 25, 2013

I was recently asked by a recruiter (who “cold called” me for a job I didn't deem I was qualified to fulfill)
to describe the attributes of a successful project manager. I think my no holds barred replies shocked
him a bit. I said uncensored (make sure
there are no children present):

To know what the fuck you’re talking about (I don’t know why I dropped the
F-Bomb to a stranger, but I did …): Basically, don’t say “I know” if you don’t. I have no problem saying I don’t know
something and asking for help from someone with more wisdom in the matter than
me.

To ignore process when it’s in the way*** : For example, if you
have the bandwidth (time), and somebody needs your help – help them. Don’t make
them raise tickets and bother 3 other people in the organization and waste
their time to solve a problem.
Especially if it’s a customer.***This can even work in more serious changes like production rollouts, but you
really have to know what you’re doing. You're either a hero or fired. Not for the squeamish.

To garner social capital with your teammates and customers
on a regular basis … ie, get shitted (drunk) with them once in a while and have some fun. If you don’t drink, that’s fine, just don’t be a bore. Nobody wants to help
people who aren't fun, and they will do so only by “force” or necessity.

That’s it. All the
certificates in the world mean nothing (Yes, I’m Prince2 certified, but I was
forced to do it!). I knew many PMs with
certificates covering their walls, but they were notoriously unsuccessful because
nobody wanted to help them (see point #3 above), they moved way too slow (see point #2
above), and they tended to escalate way too much (instead of trying to find the
solution themselves in a diplomatic manner …. point #1 kinda applies).

Monday, October 07, 2013

As I get into the final phases of development before the
first release of my smart shelf solution, I am focusing a lot on usability and
productivity features. Outside of elite
software development circles, these intangibles are still little understood and
highly undervalued in the IT world. Such features are always
hard to elucidate to potential customers because they’re immaterial (not easily
written into a feature list) and can usually only be perceived after the fact
(ie… after using them).

Many years ago I got the opportunity to work for a new start-up
ran by some real math geniuses at JetBrains.
When I was asked to come on, it was a small team just releasing the 2nd
version of their now industry famous and unbelievably awesome Java IDE IntelliJIDEA. These guys were the first to put
refactoring features into a Java IDE and not only that, made it quick and easy
to use. Developers (their niche market)
saw the value immediately and sales quickly took off. A simple refactor like “rename” immediately
saved 10s of minutes if not hours of manual (and error prone) work renaming
items in your code. You could now fire up the “rename”
refactor with a push of a button, and all (for example, class names) within the entire project
would be renamed to whatever you chose (error free). Seems simple in retrospect, but it was a huge
time saver at the time, and companies were willing to pay for such features. Here’s why:

Let’s say you pay a developer
80,000 USD per year to program for you. He works 8 hours a day, 5 days a week,
4 weeks a month – an average of 20 days per month. That yearly salary roughly translates
into 6,666 USD per month, 333 USD per day, 42 USD per hour, .70 cents per minute. This new feature saves 15 minutes per day. Time = Money, so around 10 USD per day of
developer time (ie… more work completed in the same amount of time). Now, basic math: 10 USD per day = 50 USD per
week = 208 USD per month = 2500 USD per year.
The software license cost was 500 USD.
That’s 2000 USD in increased productivity or programming value for that 1 developer.

And of course, that wasn’t the only feature (the tool had
way more, with much larger productivity savings, but general time savings per
day with the new tool was probably around 1 hour a day total). Other elite programmers understood it
immediately and had their bosses buy it; in companies where there was no budget,
or worse, somebody who did not understand productivity was in charge of
finances (which is usually the case), many programmers bought the software with
their own money!

Then came the competition. As our
software added these productivity features, other vendors started to add them
as well. In this market, our competitors
were open source software Eclipse (funded by IBM) and NetBeans (funded by Sun
Microsystems). Backed by billion dollar
corporations, the foundations running these open source variants offered their
software FREE, with features rivaling IntelliJ IDEA – maybe always 1 or 2 steps
behind, but basically great value for the money (free!). But you know what, although on a 2
dimensional feature list, they could compete with similar features, they still
could not compete on the productivity side.
Their “rename” feature might work just as well, but to use it, you had
to take your hand off of the keyboard, click around on the mouse, and basically
go thru 4-5 steps to invoke this feature.
With IntelliJ IDEA, you needed just one press of a button (superior usability). To this day, JetBrains is around, making a
ton of software variants for different platforms and languages (all of them
born out of IntelliJ IDEA) and always keeping 1-step ahead on productive
features against their rivals.

That’s what tools you buy for your company should do. If they complicate things, then they really
do not have much productivity value.
Having played with many of the leading ERP system variants and their
modules (SAP, Ariba, ex-People Soft now Oracle, Salesforce, and even smaller
system), some of them are just horrible to use.
Slow, complex menus, nothing intuitive about them when using them …
they’re not productivity inducing at all and even add some initial complexity
to the organization (usually requiring expensive trainings, consulting for
refinement, etc….). Such systems
shouldn’t be that way, but they are. And they rule the logistics world.

However, knowing the above ... how can one sell “productivity” to a potential
customer if the customer is unwilling to try something new, or due to the size
of the company at hand, it’s simply impossible to rollout and demo a new product in their
environment? This is a problem I’m
looking to answer. And it’s a question supply-chain related companies need to figure out as well. Being dominated by slow-moving, expensive 800-pound gorillas isn’t doing their organization (or the industry!) any justice, they need to
internally think of ways they can “test” disruptor like chasm crossing solutions at the same
time, to keep their current vendors honest and innovating. Stay tuned! :-)