I've been fortunate in my career to have had a couple of great managers. The rare combination of vision and execution found in my managers at Microsoft Research and DuClaw Brewing Company have established a kind of gold standard in my mind. I've been thinking about management a lot lately. I'll probably be head down doing technical work for the next few months, but after that I hope to build and run a new technical team. Even though I aspire to be like the outstanding managers I've worked for, I don't think you have to be great to be successful. As a matter of fact, I think that being a good manager can be distilled into 2 simple steps.
Step 1: Make It Terrible to be Bad
There are plenty of good people who are bad employees, especially in the technical world. Since I've worked mostly in software, I'll focus there for a moment but the same principle is applicable to any industry. My definition of a good developer is one who develops good software. It's no surprise then that I think a bad developer is someone who doesn't develop good software. As a manager, it's your job to make the environment unpleasant for bad employees. Yes, you get extra points for offering up solutions to their crapitude like training and whatnot but even if you don't you can still be good manager simply by making bad employees not want to be there. Why am I harping on this so much? Because bad employees are a cancer to a team and they kill the team from the inside. First we have displacement – a bad employee is sitting in the seat that could be occupied by a good one. Next we have infection – bad employees have a very strong potential to turn others bad either by active instruction ("Here, junior dev, let me show you the wrong way") or through passive observance ("Why should I be any better if that guy sucks and he's still here?"). And finally we have repulsion – good employees don't enjoy working with bad ones so they leave.
Step 2: Make it Easy to be Good
The step is all about clearing the path for your direct reports. Most technical people really enjoy what they do, it's all the other stupid stuff that turns what they enjoy into "work". This is one of the reasons so many good and great developers work for start-ups, small software companies, or the few "big name" companies that you read about all the time like Google. It's about the purity of the work as much as it is about the work itself. This is where most companies inflict Death By 1000 Cuts – poorly managed web filtering that blocks technical blogs? Cut. Stupid HR rules that require filling out a paper form once a month? Cut. 17" screen instead of a 24"? Cut. Slow network, unstable email server, not enough hard drive space? Cut, cut, cut. Sure, any given one of these isn't enough for someone to leave but put enough of them together and you've got one seriously unpleasant and ineffective environment to work in.
The steps are listed in order of importance. Sure, you can start knocking off some of the low hanging fruit to make it easy to be good while you're putting the heat on the bad folks but you can't ignore step 1 and make it up by doing lots of step 2. When a patient is diagnosed with cancer, the immediate focus is on eradicating the cancer not on adding lean muscle or lowering cholesterol. Yes, the latter two can contribute to improved overall health by they simply don't matter if you don't take care of the most pressing need first.
*-as-a-Service is all the rage these days. Everywhere you turn you see Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service. It reminds me of the late 90s when everything was Internet, Intranet, and Extranet – you know, back when it was so new and important that we capitalized the words.
Even though we're seeing some serious overuse, my problem isn't with the terms it's that the root words are incorrectly swapped around so much that folks have a hard time thinking about them correctly. Sometimes everything is lumped into SaaS since it was first. Other times Platform and Infrastructure are used synonymously. My goal here isn't to introduce you to SaaS, PaaS, and IaaS . . . chances are you have an idea of what these are if you read this blog. Instead, my goal is to show you a way to think about them to know what fits where including a 2-part value proposition of each. This is especially important if you're building software that falls into one of these 3 groups.
Infrastructure-as-a-Service
Unless you work for Amazon, Rackspace, GoGrid, or one of the other big providers chances are good that you're not building IaaS. Infrastructure is just that: the foundation where you run your system. This service is all about providing you infrastructure components like servers and networking goodies such as load balancers, firewalls, and VPNs. The "service" part of it is the management software that lets you click (or programmatically call) to provision new resources. Click: new server. Click: new network segment. You get the idea. The important takeaway here is that you are renting infrastructure that lets you do what you want, but it's pretty much up to you to make it do something valuable. The 2-part value proposition of IaaS is that you can rent infrastructure instead of buying it and that someone who is better than you will be running it, provided you go with a quality provider.
Software-as-a-Service
At the other end of the spectrum, we have Software-as-a-Service. SaaS should do something of value immediately after you sign up for it. Sure, there may be some customization involved but the bulk of a valuable problem should be solved by the software that you're renting. If you work for a software startup, then there's a good chance that you're working on a SaaS product or that there will be a SaaS version of your product offered in the near future (either by your company or a new competitor). The SaaS 2-part value proposition is that you only have to pay for software you use and you have a solution to the problem that's better than what you can build in the time you have. That last part is especially important since if you can't find something worthwhile to rent, then you've just stumbled upon a great market opportunity (or you're awful at using Google, but I'll give you the benefit of the doubt).
Platform-as-a-Service
This is actually the term that's been stuck in my head and led to this post. PaaS should let you build something of value after signing up. It's a step away from infrastructure in that you don't have to worry about the underlying servers and networking, but it's also a step from being SaaS because it doesn't do anything of general value until you get to work. I think that a lot of the confusion around the term can be credited to the success of Salesforce.com. They started as a SaaS offering and then created the first really successful PaaS offering (while continuing to offer plenty of SaaS goodness). Their hosted Customer Relationship Management system is often cited as the first successful SaaS product. Later they created Force.com which lets developers build new applications on top of their infrastructure. Another factor that contributes to confusion about what constitutes PaaS is the use of the word "platform", one of the most nebulous terms in the tech industry. I think that Architecture-as-a-Service may be a more accurate (though not necessarily better) description because what you're paying for is someone else's solutions to common development tasks. Instead of worrying about collecting data, storing it, retrieving it, searching for it, etc., you use the provided platform – its architecture. The 2-part value proposition is that you can use the platform to build software without having to solve all of the problems common to software development.
To give a little perspective, I'm currently working on a PaaS system that will be used to create several SaaS products. I'm using IaaS (Amazon EC2) for testing and production deployment. So I rent from Amazon and others rent from me. The spread between what I pay and what I charge is dependent upon my solutions to both development problems (the PaaS layer) and business problems (the SaaS apps).