eBusinessBlog.org Leveraging marketing & technology to solve business problems.

9Apr/080

How to determine if you delegate enough

Posted by Eric Long

rescuetime-logo.jpg

I recently came across an article that really hit home for me. It's titled "How to determine if you delegate enough." To quote the article:

How do I know when I am delegating enough? I think that the answer is very simple: You are not delegating enough if the questions that you are getting are easy for you to answer.

If your subordinate comes to you with an easy question ... the possibility is that the answer was indeed simple but you didn't share the necessary information, requiring the subordinate to ask the question. This may mean you retain some information in order to feel that you have not lost control, but it causes your people to be frustrated and to feel that you don't trust them. It's important for you to disclose to your subordinates all of the information that they need to do their jobs.

Shifting from "doer" to manager & avoiding "doing nothing" as a manager

In my recent role change, I'm now managing a larger range of projects and a larger group of people. I've always admired managers and executives who could get their hands dirty. I think this garners respect and establishes credibility with any manager. In this new role, my biggest challenge is identifying the tasks to take on myself and to delegate to my staff. While there are many simple projects and tasks I am perfectly capable of handling without the help of my staff, I need to be able to identify which tasks make the most sense for me to be focusing my time on.

Enter RescueTime - How I measure where I'm spending my time

I recently came across a new free service called RescueTime. It's a web-based service with Mac and PC "listeners" that install quickly and effortlessly so I can monitor my application usage and website visits. The benefit here is that my "doer" tasks vs. my "management" tasks are clearly divided between the websites and applications I use:

  • For example: firing up the Mac OS Terminal app and hopping on a server to move some files around is clearly a "doer" role. I file the "Terminal" app as a "development" task/app.
  • On the other hand, reviewing Omniture web analytics data is most definitely a web marketing role, so I flag all Omniture sites as "web marketing" tasks.
  • Email, Excel, Visio, Microsoft Projects are all tagged as "eBusiness" applications.

 

The RescueTime Dashboard

Since I have a dedicated laptop specifically for work, the only time I really use it is for work-based functions. Since the RescueTime "listeners" time out after 2 minutes of inactivity, the service provides a very accurate portrayal of the true time spent working (for me, at least). Of course, when I'm in meetings and the laptop is idle, this "work time" is not captured. Since the majority of my job involves a computer, it's pretty safe to say that it captures most of my work-related activities on any given day:

 

Below we see (for the week of March 30th) I spent 55 hrs and 50 minutes working.

 

Below we see how my 55 hrs and 50 minutes that week broke down into the "tagged" sites and applications I used:

 

RescueTime then tells me how efficient I've been based on the above data collection and my account settings (I rate "ebusiness" as more efficient than "development"):

 

I'm still spending too much time "doing" and not delegating

When logged into the RescueTime dashboard, you can hover over the above red bars to see the total time spent on the tags. "development" was comprised of more than 11 hours of work. That's 20% of time dedicated to "doing" which is much too high. RescueTime has also calculated my efficiency. Efficiency is described as:

A score based on the ratio of productive activity to distracting activity. To improve this, spend a higher percentage of time on productive tasks.

Without the RescueTime software and web service, I'd have no way of quantifying this information other than going by gut feel.  Now that I know I'm spending too much time, I am not worrying as much about being perceived as a manager who doesn't like getting their hands dirty. RescueTime is enabling me to focus on more accurately managing and delegating the tasks and projects for my staff.

Tags: , , ,

9Dec/070

Building vs. Buying Software

Posted by Eric Long

My first week has come and gone (officially) in my new role as eBusiness Manager. Not only is this a new role to me but we are also replacing two people on the team who had previously been in development roles for several years at the company. One is advancing to corporate and the other is leaving the organization. One replacement has been hired and his first week was very challenging, to say the least!

The Open Source Dilemma
I'm an enthusiastic supporter of open source applications and development. However, without proper documentation of home-grown applications, the cost savings up front of an open source deployment will eventually come back to haunt you down the road when those original developers leave. This is the exact position we are in. While it won't be damaging to the organization, it will create a rather steep hill for the new developers to climb as they dive into the custom code (and lack of documentation).

When to buy or build?
This had me thinking during the first week in this new position -- where is the line drawn between buying software and building software? I have to bring up a saying I use quite often: "Just because you can, doesn't mean you should." I think this is a perfect application for this phrase. I've discovered a lot of the home-grown applications were built as a cost-savings measure and "because we could." That mentality has backed us into a corner today as we scramble to educate the new hires as quickly as possible before the original developers leave the organization.

Don't view IS as a cost center
In talking with the original developers, it seems as if the mentality of the organization was such that IS was viewed as a cost center, not an innovation center. Therefore, an expenses incurred in IS were viewed as negatively impacting the bottom line. As a result, we ended up with a lot of home-grown applications utilizing different languages and database backends. This strategy works if you never plan to migrate to new technology and never plan to advance your developers.

Future-proof your IS strategy: standardize and document
Moving forward, we will begin to standardize on select platforms. We have a series of consumer websites, internal applications, intranet sites, and reporting spread across a myriad of technologies. Our downfall was this strategy (or lack thereof) which resulted in dedicated employees for managing each of the technologies/platforms. Since each platform was different, development was being handled in silos with very little strategy being shared between the silos. It also made us extremely dependent upon the individuals in charge of the silos.

Standardizing on a few select platforms and technologies will enable the proper cross-training among existing staff to be able to support applications in the event of individual vacation schedules, sick days, or departures from the organization. It makes sense from a technology strategy, business strategy, and also in keeping the sanity of your staff. It's no fun for the weight of the world to be on the shoulders of a single individual.

Documentation seems to always take a back seat to projects in any business. In an enterprise like ours where we rely on reports and data feeds from external vendors, corporate IS, and other departments, documentation can save a lot of time and also prevent downtime. We have the fortune of being forced to start with a clean slate with new developers, so our first several weeks will simply involve documenting existing applications and systems.

Tags: , , ,

5Jan/070

Ajax User Experience vs. Adobe Flex User Experience

Posted by Eric Long

I came across an interesting post which I commented on over at Read/Write Web, discussing the recent Forrester Research
results of RIA (Rich Internet Applications) vs. HTML. While I think the result of the research is nothing shocking (RIA provides a better user experience than HTML), the bigger issue I would like more insight on is ajax vs. Adobe Flex.

Apparently, this has already been discussed on several sites/blogs (google search "ajax vs. flex"). There are inherent pros and cons to each platform, and I think the debate could go on forever on which is "better." Sort of like J2EE vs. PHP for web application development...or better yet, Mac vs. Windows, or Ford vs. Chevy. Two types of technology that can really get to the same end result (more or less). Obviously, depending on the end result you need, one technology may be better than another. In the case of cars, if you need to do any real work, then you need a Ford ( :D sorry, I'm a "Ford" guy).

I digress. The issue I would like to initially evaluate is not really the technical implementation discussion but rather the usability and user experience discussion.

Ajax User Experience vs. Adobe Flex User Experience
Do consumers really care that an application is done using Flex vs. Ajax? Does one technology fair well for certain demographics, industries/markets, or services better than another?

Take Glidden Paint for example. Here is their RIA utilizing Adobe Flex:

Glidden Paint using Flex

Painting is a very interactive experience, and the color-picking process should arguably be, too. In the Glidden application, you navigate down to color families which they've so kindly organized for you, and you drag and drop color swatches onto the areas of the photo so you can see how it looks. Very effective. Does it help sell more paint? Probably. Could the same application be done utilizing ajax? Probably, minus drag-and-drop features.

Let's say it was done in ajax, to the best of the most-talented developer's capabilities, designed to look nearly identical where it could:

  • Would a consumer know the difference?
  • Would consumers using the Flex-based app convert to buyers at a higher percentage?
  • Maybe it does become a technical consideration after all?
  • What was the cost to get to this solution utilizing flex vs. ajax?

Knowing what I know now, flex is definitely the way to go for the Glidden environment. Why? The subtle touches that flex offers:

  • smooth animations
  • nice transitions from one color family to the next
  • the function of dragging the paint color to the floor or wall

These all contribute to making it a very usable, inspirational, and, well, fun application to use! This is an important consideration that needs to also be made when choosing the technology -- how will your customers benefit from one technology vs. another?

OK, so when is Ajax better than Flex?
In many places. Google maps is one. The ability to grab the map and move it with your mouse is a significant usability benefit of Google Maps over competitor mapping systems. Not to mention that there really are no page loads. Google benefits from a very "plain Jane" UI throughout all of its applications it offers for free. Ajax is a clear winner for them because it provides extreme flexibility, runs entirely on open source software, and well, their target audience wants their product to just work. Light-weight portability is also critical for Google as they branch out into mobile phones, syndicating services, licensing search engine appliances -- dealing with the inherent licensing fees of Flex and the portability to all of the different mediums they play in would be rather difficult. When your target market is the entire world, it's best to K.I.S.S.

I already have an ajax-based web application. Should I port it over to flex?
This is a really interesting question that I do not have the answer to. We will face this same dilemma for our ajax-based project. We've already spent 12 months on the project, it's nearly finished -- does it make technical sense to port the client-facing side of the application over to flex? Does it make business sense? Will it create a happier customer? Will it generate more revenue? Will it be more or less of an ongoing burden as it pertains to maintenance? What about portability to other mediums besides the web (mobile phones, kiosks, etc.)?

I will continue to comment on our progress on our ajax application (I will talk more about it when we actually launch it -- so for now, I have to be vague). We will most certainly do a technical and business analysis of converting from ajax to flex to see if we will see a return on investment. The last thing we want to do is to do something just for the sake of doing it. Converting to flex essentially means halting new development of the existing ajax application -- which also will have an affect on current revenue streams and customer satisfaction. Instead of pumping time and resources into improving what we have already, we're essentially starting the client-side from scratch. Anyway, we'll weigh the pros and cons and I'll post more details as we cross that bridge.

Moral of the story: 3 components to choosing the right RIA technology

  1. Which is the best solution for your customer?
  2. Which is the best solution from a technical resource standpoint?
  3. Which is the best solution from a business/financial standpoint?

In the meantime, we'll chew on research like Forrester's RIA vs. HTML -- but this is fairly common sense. RIA's inherently provide an improved user experience, so they are a home run with consumers. I'll eagerly await more data on which RIA technology drives higher satisfaction and ROI.

Tags: , , , ,

2Dec/061

apache mod_deflate reduces bandwidth usage by 27% on SuperMotors.net

Posted by Eric Long

In the ongoing battle of optimizing, tweaking, and testing, in November we enabled apache's mod_deflate module on SuperMotors.net. Literally adding about 10 lines of code to httpd.conf (the apache config file), all text-based content on our pages now use gzip compression when delivered to web browsers that support gzip compression. By using this tool, you can see if your site currently utilizes gzip compression. When testing SuperMotors.net with this tool, our homepage size was originally 49K, but with gzip compression thanks to mod_deflate, it is reduced to 9K. This is an 81% savings in bandwidth usage.

So, when implemented over the course of the entire month, we saw an overall 27% reduction in bandwidth. Surprisingly, our absolute unique visitor count was down 14% for November (holidays do this to our site), but page views actually increased by 1%. Page views are ultimately the driver in bandwidth utilization. I interpret this to mean that fewer users were able to do more on our site because they were downloading content in less amount of time.

So, why does the test tool from above show an 81% reduction in bandwidth yet we only saw an overall reduction of 27%? This is because images (and other files) are not compressed when delivered to web clients. Since we primarily serve images and videos, the rest of our bandwidth still remains largely untouched by mod_deflate -- which is by design.

This bandwidth reduction is very good news for us. As previously posted, we are leaving the world of colocation and moving to managed hosting -- with a new billing model. The "total bandwidth used" billing model favors us even more now that we've reduced bandwidth usage by 27%. This translates into squeezing more data out of the pipe than previously anticipated. We'll be able to maintain our fixed costs and increase revenue, thanks to this little module. The more data we push out, the more page views we serve, and the more revenue we make from our CPM-based advertising model with Tribal Fusion and our in-house ad inventory (read the challenges we face when we introduce Ajax functionality and how it'll affect our CPM-based ad model).

The mod_deflate module does increase CPU usage due to the need to compress each page sent out. However, this had very little impact on us as we had plenty of processing power to spare. Your results may vary, so keep an eye on CPU usage when you implement this module. The slight increase in CPU usage was worth the risk, because the 27% reduction in bandwidth was a much bigger gain for us.

12/4/06 Edit: Ajaxian has an article on gzip compression with some user responses. Interesting insights (in the comments section) on the law of diminishing returns with gzip compression used on ajax-enabled pages. 

Tags: , , , ,