How to convince your employer to let you telecommute (LIKE A BOSS)

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

You have decided to work from home. Telecommute.  Listen to the kind of music you want to – dance the way your body tells you. Shower less, love more.

La-di-freaking-da – you still need to convince your traditional in-office boss to let you do it.

What your boss fears

Your boss thinks that working from home is all Saturday-morning: pajamas, fruit loops, SpongeBob SquarePants, drinking, gambling, loose women, not working, cursing off the Boss (“BWAAAHH this bar gets Wi-fi look at me on IM right now guys!”). (ed note: Saturday mornings are pretty exciting for me)

He has heard horror stories of people working from home just doing enough to get by, not returning phone calls, working on other things, quitting, etc. He fears that:

  • Your performance will decrease
  • You will lose touch and work on the wrong things
  • You won’t be there to help others

Therefore he is afraid he will:

  • Look really stupid to everyone else for letting your try it
  • Have to let you go and find someone else

We just need to fix these concerns one-by-one in a detailed manner. You need to think through and deliver a proposal  – and then you need to be a badass and execute it.  He is most concerned with Performance and Communication.

Performance: prove that it will increase

You need to show that for you working offsite is more productive. Tell him why and then show him its true.

Send him studies and a summary of their conclusions to show that it can work

Studies say that:

  • People who work from home don’t change jobs as often
  • People who work from home have better morale (which leads to nice things like staying alive, being less stressed, and having more ideas)
  • People who work from home end up doing more actual work / work longer hours (emphasize whichever one your boss seems to care about more)

Finding evidence is easy:

Show him how much it works for you

  • Ask if you can hole up in a conference room for the afternoon, and then show him scary results.
  • Ask if you can work from the coffee shop/hotel across the street, and then show him scary monster results.
  • Ask if you can work from home one day and then show him scary monster-who-is-taller-than-average results.

Communication

There are two fears about communication – one specific fear is that you won’t be productive simply because you will be out of the loop and the other is that you will be a roadblock that holds up others.

Over-Communicating Status

For status the simplest method is to email what you are planning to do at the beginning of the day, and email at the end of the day with what you did. This also acts as a clock-in/clock-out mechanism for the more paranoid set.  Over-communicating is a good place to start – you probably aren’t offering twice-daily status updates in person now.

Offer to share your to-do list. When you work from home you will need more structure than you had before so you will most likely be documenting more anyway. Use one of the many tools (RTM, Workflowy, Toodledo) that offer sharing so that your boss can (but most likely won’t often) see that you are in fact adding and deleting items that he recognizes.

Be available

For team communication it is harder to stay in the loop.  You need some infrastructure in place: broadband internet, slower internet or a close Wi-fi backup, Skype, clear phone, etc. You will need to have your cellphone with you all the time when starting out and will need to act like you are in the office: if you need to run a 30 minute errand or have a doctor’s appointment tell someone.

Smell the tasty politics

For on-the-fly information and politics it gets much harder.  Since clearing communication roadblocks across the team might (absolutely should) be part of your boss’s job you are indirectly asking him to do more work by communicating differently with you so avoid any special cases that require him to do anything just for you.

Take the initiative on your own to identify how real information travels around the office and make sure you can show him what proactive steps you will take. e.g. “I’ll still be on the morning call and I’ll message Cathy around lunch to see if anything comes out of the Thursday interdepartmental fist fight that seems to always determine our priorities”.

Being in-office also helps – offer to do 3 work from home days and 2 non work from home days. If the days are typically the same (i.e. there is no big planning meeting) offer to still come in on Mondays and Fridays. This calms his SpongeBob nerves as an irrational fear of ninja three day weekends is common.  On the days you do come into the office you should turn into a total water-cooler guy and try to catch up with people to see if there is anything you need to know.

The most badass move out there

So you give him your plan – I’ll work Tuesday – Thursday from home from 7AM to 4PM, be available over IM, on Skype as needed, dial into the stand-up meeting, share my todo list, keep in touch with Cathy about politics, call you once a week if I haven’t seen you, etc.

Setup a timeframe of one month in which you will execute this plan. Tell him that at the end of it if he feels that you got less done you’ll give him the vacation days you would have earned over the period back.  If you are a contractor offer to not be paid for 2 of the 20 business day in play, or 10% of your billed time over the period.  Also – you should fully intend and be ready to make good on this.

The reason this works is that you are putting a stake in the ground and providing a mutually beneficial outcome for both parties.  The boss knows that he is still in charge but has an employee that is taking initiative and will get things done.  The added benefit to you is that it puts you in the right frame of mind – the absolute most important thing to understand about working from home is that it is all about execution.

(The second most important thing about working from home is never missing an episode of SpongeBob.)

I’m writing a book about successfully working from home; click here if you want to know when it is complete.

Glorious Hack #97: Wrapping regular ViewResults as JSON for rich client-side processing

I recently had the need on a ASP.NET MVC/js project to wrap the results of a controller action in JSON so the middle-class UI could consume and then do one of:

  • Redisplay the current active popup because validation failed (and I wanted to use the built-in MVC validation)
  • Close the current popup and refresh a grid on the parent page with the new item
  • Display a generic error message page (in the case of something unexpected like an EndOfWorldException being thrown (by who?))
  • Display an even nicer error message page with contextual information returned from the controller about the data entity

Logic like this seems to want to occur on the server side – a combination of ActionResult and some logical branching would normally work but in the context of a rich javascript UI and the current context being an active jQuery dialog box that won’t work – the user won’t like a full page refresh, and you can’t tell the javascript which ViewResult you’ve returned of the above cases.

So I came up with the following which is either a glorious hack or just a hack:

  • Have the controller return JsonResult in all cases with a instance of a simple wrapper type ValidationResultViewModel
  • Have the javascript then decide what to do with the payload based on this information
  • Generate payload by running the ViewResult via your controller and making the payload a regular string

So the ValidationResultViewModel class looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class ValidationResultViewModel
{
        public bool IsValid { get; private set; }
        public bool IsError { get; private set; }
        public string Payload { get; private set; }
        public long EntityId { get; private set; }
 
        public static ValidationResultViewModel Make(bool isValid, bool isError, string payload, long entityId)
        {
            return new ValidationResultViewModel
            {
                IsValid = isValid,
                IsError = isError,
                Payload = payload,
                EntityId = entityId
            };
        }
}

This class is populated by the controller’s action like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
protected JsonResult PartialViewToValidationJson(string viewName, object model, bool isValid, bool isError, long entityId = 0)
{
	string payload = RenderPartialViewToString(viewName, model);
 
	var viewModel = ValidationResultViewModel.Make(isValid, isError, payload, entityId);
	return this.Json(viewModel, JsonRequestBehavior.AllowGet);
}
 
protected string RenderPartialViewToString(string viewName, object model)
{
	if (string.IsNullOrEmpty(viewName))
		viewName = ControllerContext.RouteData.GetRequiredString("action");
 
	ViewData.Model = model;
 
	using (StringWriter sw = new StringWriter())
	{
		ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
		ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
		viewResult.View.Render(viewContext, sw);
 
		return sw.GetStringBuilder().ToString();
	}
}

There is a bit of magic here – we are rendering the view as the engine would run it and then transforming its payload back into a string to return to the client.  These methods live on a BaseController class and reuse ViewData et al. from the existing context.

This is not a normal approach – ViewResult and the way it works are abstracted to allow unit testing and separation of concerns, etc.  We are reusing this to say that we want to force it to render as we want to tradeoff some performance on the server for some magic on the UI.

So now your controller is free to populate it as it sees fit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[HttpPost]
public virtual ActionResult Edit(SomethingViewModel viewModel)
{
	if (!ModelState.IsValid)
		return this.PartialViewToValidationJson(MVC.Something.Views.Basics, viewModel, false, false);
 
	try
	{
		Something.Save(viewModel.ToSomething(), this.User.Username);
		var something = Something.GetById(viewModel.SomethingId);
		viewModel.Populate(something);
		return this.PartialViewToValidationJson(MVC.Something.Views.Basics, viewModel, true, false);
	}
	catch (Exception e)
	{
		return this.PartialViewToValidationJson(MVC.Shared.Views.Error, ErrorViewModel.Make(e), false, true);
	}
}

Think russian dolls – in your controller action you are essentially calling another controller action, rendering it, then making it a string and returning it as part of your returned result:

-> popup -> js does a $.post to Something/Edit -> using existing Model renders Something/Basic as a string -> makes ValidationViewModel -> returns as JsonResult

The client can then do things like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$.ajax({
	async: false,
	cache: false,
	context: form,
	type: form.attr('method'),
	url: form.attr('action'),
	data: form.serialize(),
	success: function(data) {
		if (data.IsValid) {
			successTarget.replaceWith(data.Payload);
			ret = true;
		}
		else if (data.IsError) {
			if (data.Payload) {
				errorTarget.find("form").replaceWith($(data.Payload));
			}
			ret = false;
		}
		else {
			// replace only form contents to prevent overriding
			// any .dialog or other post load changes to target
			if (data.Payload) {
				errorTarget.find("form").replaceWith($(data.Payload).find("form"));
			}
			ret = false;
		}
	}
});

I actually ended up replacing this with generic callbacks so that you could pass in what the UI should do in the event or an error condition, success, validation failure:

1
2
3
4
5
6
7
8
9
10
11
success: function(data) {
	if (data.IsValid) {
		validationSuccessCallback(data);
	}
	else if (data.IsError) {
		errorCallback(data);
	}
	else {
		validationFailureCallback(data);
	}
}

And we have extended it a bit to include other client-side view model type data.

A hack, but one that fits the tradeoffs on the table – sacrifice some performance on the server side and add some complexity for the payoff of a nice wicked fast client UI experience.