Living vSocial

Zone Coverage

This is somewhat more of a management-centric post, but it has some applicable theses for building apps and being an engineer in general.

Start-ups aren't about very, very specific tasks for specific people. They're really about having an 80% core competency, and a 20% zone skill that can cover for someone else. Unless you're the CTO/CIO/VPoE, then you're doing whatever you have to do to get things to fly. ;) Anyways, back to Zone. If you're an employee in a start-up, and you expect to code specific functionality 100% of the time, you're delusional. Maybe. It could be that the folk that hired you didn't make you aware of how these things go. I know, I know, it's hard to believe that there's an engineer worth his salt out there that hasn't been involved in a startup (/sarcasm off) but it's important to recognize this important fact. If you hire someone, and you tell them "Suzy, you're going to be a PHP engineer. I expect the best PHP out of you that you're capable of" and a week after starting, Suzy starts having to write copy because it's the necessary task of the day... Well, Suzy may not like you very much, and may slack on delivering on that -- albeit an extraordinarily important deliverable -- unbeknownst, to her, job. Now, if Suzy had been told up front, that part of her time was going to be spent "chipping in," or "helping out" with the rest of the team, there's a much higher chance that she's going to do her best to deliver what she can to help the team/company meet it's overall goals. It will also let her feel like she's a part of the overall business, not just the X lines of code she's expected to create on a daily basis.

This also comes down to who's got what skills. Guess what, I'm a pretty good writer. I'm not as good as our CEO -- not even close -- but I'm damn good. If he's swamped, I'll grab the ball and make sure it gets over the finish line if we have some document(s) that need to get out in a timely manner. Why? I'm the friggin' CTO, why should I write? Because my primary job -- just as any employee at a startup (or an established company, but that's a harder sell) -- is to make the company succeed. Not help, not hope, not pray -- make. Same deal with Mark, same deal with Brent, all the way to Steve. We're all here to win. Granted, I'm terrible on the phone, so if there's a phone-centric task that may or may not involve me, that can be better accomplished by Brent -- who's amazing on the phone -- I have no problem handing that off to him. I know he's going to do a better job at it than I am.

So... how's this apply to you, Engineer Guy? Well... duh! Dependencies. Working in a team environment, as much as we'd all love things to move at the same pace, it's simply not going to happen. Throw a hand to that guy who's module really should have been spec'd an extra week. Or help the designer who might have Photoshop-block. Get yourself more involved in the blood and guts of the project you're working on. That kind of interest rubs off, and you may find your counterparts extending the same hand if you find your module overloading your days, too.

posted by webba @ 6:32 PM