Managing People in 15 minutes, or is it Micro-Management ?

I enjoy reading HarvardBusiness.org. There are some really insightful articles there, and I think about some of the better ones days after reading them.

When I first read How to Manage People in 15 Minutes a Day by Daisy Wademan Dowling, I thought that it was a fairly good article. It was short and to the point. 10 minutes went by and that’s when its struck me: it’s rubbish.

Now, the article gives out 4 pointers on how to manage people in 15 minutes a day. My feeling is that its geared towards the busy manager/executive who will need to squeeze out every second of the working day to ensure that the team is working at 100%.

These are the 4 tips that were listed:

  • Turn dead time into development time. Walking back to your office after a meeting? Use those two minutes to give your direct report feedback on the presentation, and on how he could do better next time. He didn’t have a speaking role? Ask him how he thought the meeting went and how he might have made certain points differently — and then offer feedback on that. Direct, in-the-moment feedback is your single best tool for developing people.
  • Constantly spot dead time. Look for every two-minute stretch in your day during which you could be talking to someone else — most often, that’s travel time — and convert each into a coaching opportunity. Walking down to Starbucks to get a coffee? Driving to the airport? Headed out to your car at the end of the day? Ask one of your people to come along with — and talk to them about their goals and priorities.
  • Show up in their workspace. Employees expect you to stay in your seat. Don’t. Once per day, get up and walk over to the desk of someone you haven’t spoken to recently. Take two minutes to ask her what she’s working on. Once she’s done answering, respond “What do you need from me to make that project/transaction successful?” Message to employee: I know who you are, I’ve got high expectations — and I’ve got your back.
  • Make two calls per day. On your way home from work, call (or email) two people you met with that day, and offer “feedforward.” “I like what you’ve done with the Smithers account. Next time, let’s try to keep marketing costs down. Thanks for your hard work.” Always make “thank you” a part of the message. Employees who feel appreciated, and know that you’re trying to develop their skills, stay engaged over the long run.

I won’t go into the details and analyse each and every point. However, here’s my feedback to these 4 tips:

Points 1. and 2. is essentially time management. Its not rocket science and the subject been there since the dawn of modern management. So, lets not kid ourselves that we’re actually gaining new knowledge by coining it in new, fashionable ways. Nothing new here. Telling managers that they need to make sure every second of their time is used effectively is just pointless. Everyone knows about the importance of time management, but most get stuck on how to implement/execute it. For execution, there’s a plethora of seminars, books, papers, conferences around the subject.

When I was managing teams and projects, there were days that felt endless. I usually started work at 7am, and at 8am sharp 5 people decide to whack in 5 different meetings throughout the day at different times. Managing those days were challenging, but its was not rocket science. On days like those, every 5 minutes free time was spent with someone, which is a trait I picked up from my director at that time. I’ve sat in countless of meetings that I had lunch in. You just have to make every moment count.

However, the rubbish part comes on points 3. and 4. If you read them carefully and picture yourself as the manager, it makes sense. But lets remember – management is not about you, it’s about them. Now, put yourself in the place of the your direct report and all of a sudden points 3. and 4. suddenly feel like you’re being micro-managed. This is not the way to lead a team. To be honest, if I had done that to my teams in the past, the consequences would have been dire. Admittedly, managing developers is different from managing a team of say, sales people. However, micro-management is always a bad thing to do. It undermines, demoralises and makes the person feel utterly useless.

Now, it’s not normal to find such low quality content on HarvardBusiness.org, and this one has to be one of the worst I’ve read. Infact, head over to the article right now and just read the comments that were submitted. Not entirely good feedback at all.

5 Tips for Building a Web SaaS

I have encountered tons of problems, some small, some large while building XP-Dev.com as a web software as a service (SaaS). To be honest, I was a little too naive and didn’t foresee some of these issues, and I really do hope it will help someone out there who’s thinking of building a SaaS for the masses.

1. Case Sensitivity

Case sensitivity of your unique keys is really important. For example, when you’re building a user database, you need to consider whether User1 is the same as uSeR1 and vice versa. Do note that email addresses are case in-sensitive and you’ll need to be able to cope with that in your application code. If you’re hosting your application on a Linux box, do remember that in general, Unix filesystems are case sensitive, and if you had a directory for User1 on your server, you could have another directory for uSeR1 as well.

On the database side, MySQL has a small bug nifty feature that will actually help you solve this headache a little. If you declare a column as a VARCHAR, searches on it are case insensitive, i.e. if you search for uSeR1, you will get back User1.

If you’re finding some weirdness around Hibernate, MySQL and case sensitivity, do have a look at by past blog about it.

2. Internationalization and Unicode

Just build everything on UTF-8, from the beginning, on each-and-every-file, on each-and-every-request. It will save you a whole load of headache later on when you’re considering releasing your SaaS to the non-english speaking world (and that’s a HUGE motha-** of a world that you don’t want to miss out on).

Use UTF-8 database tables. Depending on your installation, you’ll find that MySQL uses latin1, and that doesn’t bode too well with them accented and asian characters. The trick is to use the ‘CHARACTER SET‘ option when creating your database, and setting ‘charset=utf8‘ when creating tables.

Do use the awesome W3C HTML Validator to ensure that web browsers are reading your SaaS using the correct encoding:

3. Login/Register Lifecycle

Ahh yes, authentication! There’s a ton of research put into answering the question ‘How do I authenticate users on a website ?’. But my gripe is not about the authentication itself – it’s about doing the right thing after authentication.

Here’s a common scenario – User1 visits http://example.com/some/private/service/ which is an authenticated service – i.e. User1 needs to login to example.com to be able to access it. The problem is that some SaaS out there immediately redirect User1 to their ‘dashboard‘ or ‘homepage‘ on example.com – http://example.com/userhomepage.

This will frustrate users as they have to:

Remember the initial URL http://example.com/some/private/service/
Login
Retype http://example.com/some/private/service/ in the browser’s address bar
Press Enter.

The same applied if the user has not even registered for your SaaS.

The solution here seems pretty obvious – keep track of the last URL that a user hit before reaching your authentication pages, and upon successful registration or authentication, just redirect the user back to the original URL.

Most web frameworks will have support for this functionality in one form or another. Do look it up and get it in before the site goes live.

4. URLs and Permalinks

Keep everything in nice encapsulated URLs. This is a subjective area (that has been debated to an extent that it’s no longer funny), but I think having URLs that do not contain query paramaters are:

Easier to remember
Search engine/SEO friendly
Cleaner to regenerate in code

For example, instead of having:

http://example.com/some/private?service=login

You could instead have:

http://example.com/some/private/login

If you’re using a modern web server like Apache, Nginx or Lighttpd, they all provide some mechanism of rewriting URLs so you don’t have to modify your code too much.

5. Application Level Permissions Layers

Most SaaS are essentially database driven applications, and they all access the database under a single user. In some complicated setups, this can actually go to 2 users – one for reading and one for writing. An even more complicated setup, each user of the SaaS will have a database login.

All of these are essentially not enough.

And here’s why – in a world where a normalised database structure is all the hype, there’s a high degree of certainty that data for User1 sits on the same table as data for User2. As far as I know most databases don’t really have row level permissioning and hence, having to rely on your database as your permission layer just does not work.

There is one setup where I thought that it might work – give each user a new table or database. But clearly this is a solution that simply won’t scale.

So, what’s the alternative ? Embed it into your application code. The decorator or facade patterns are extremely powerful for implementing this. Moreover, you can do complex permissioning, for e.g. User1 can read the business object during weekends, but not when User2 is logged in at the same time. OK, fine – ts a bad example, but you get the point.

Why bother going through all this trouble ? Well, here’s a generic use case:

MyCalendar app is a web SaaS online calendar offering. Each user can have multiple calendars, and they are all private to the user. To retrieve a calendar, all a user has to do is visit http://example.com/calendar/<calendar id>/ where calendar id is an identifier on a database table.

Say User1 has calendars with calendar ids 240, 252 and 362. If MyCalendar app didn’t have application level permissioning, User2 would happily be able to view all 3 of User1’s calendar.

So, the natural question to ask is “Do users actually try to do that ?”. YES! They will. I’m not sure whether they are curious, or looking for a security hole, but you will find some users exploring the URLs. What I mean by that is, say User2 has a calendar id of 5442. He/She will try to visit the URLs for calendar id 5440-5449, even though there are no direct links to those calendars that they can see (except 5442).

Using a database driven web framework like Rails and Django is all well and good, but remember to implement some application level permissioning if you have any private data.
There You Have It

5 simple tips that will save you a ton of hassle if you’re building an SaaS. As always, feedback is appreciated.