Original URL: http://www.theregister.co.uk/2014/03/25/from_corporate_to_startup_lessons_learned/

From corporate bod to startup star: The 10-month gig that changed everything

What I learned as a techie in my time away from globo firms

By Dave Mandl

Posted in Jobs, 25th March 2014 09:01 GMT

For pretty much my entire career as a techie (variously a developer, manager, and consultant) I’ve worked for very large, usually global, companies, most of them in the financial industry. A couple of years ago I decided I needed a break from that world.

After taking some time off to de-stress and pursue a few personal projects, I found a new gig that was different from anything I’d done previously: working as a consultant (and one of only two technology people) at a five-person startup, heading the effort to build a new web product from scratch. I’d like to talk about some of the things I learned in my 10 months there.

First and foremost, I thoroughly enjoyed the work I was doing, for several reasons. After years working for companies where security (not unreasonably) trumped all other concerns, this was a position where that black cloud was lifted.

In many ways, being a publicly accessible website, the web project required tighter security than I’d ever had to contend with before. But day to day, I was able to work on my own laptop, more or less anywhere, using my own tools, utilities, and browser plug-ins for things like editing (Emacs for OS X, if you’re curious), database work (Sequel Pro), password management (1Password) and source control (git).

At financial firms, in contrast, I’d always felt like we had to stick our arms through a set of thick iron bars to do our work, barely able to touch any actual source code. All development, deployments — everything — had to be done either on locked-down company computers (Windows, invariably) in the office or through several layers of somewhat shaky VPN software on our home machines. The latter entailed juggling multiple passwords and dealing with constant session timeouts just to keep a window into your office desktop open, not to mention having your SecurID with you at all times in case you needed access while travelling.

Coding Sans Frontières

Laptop on a picnic table outside, green grass in background

Something's so appealing about your own dev environment

I realise I’m not the first person who’s ever had the luxury of doing design and development on their own laptop, but this situation was drastically new to me, and I was surprised at how much it affected my attitude toward my work. Among other things, I suddenly had the freedom to simply grab any open-source libraries or tools I wanted to tinker with.

I’ve worked at companies where getting a public Python library installed (if they’d used Python) might have taken literally weeks and required the approval of multiple high-ranking managers. But no: For proof-of-concept work in your own development environment, “sudo pip install [package]” does it. Amazing.

One result of all of this was the discovery that I still enjoy writing code – and the significance of that can’t be overstated. I’ve got a CS degree, I’ve been working in tech for decades, and…a few years ago I was shocked to find that I’d lost all interest in doing development. But the freedom to bang out scripts on my own computer late at night whenever I felt like it, or to build a custom interface to Google Analytics, or to use the Pushover API to plug mobile messaging into an app on a Saturday afternoon was genuinely exciting.

For better or worse I found myself doing things like voluntarily staying up till 3am, working at home, or jeopardising my marriage by pulling out the laptop to make assorted code tweaks while on our summer holiday (not recommended).

The joys of DIY tech

Did the simple fact that I was designing and working on something that I was able to build from scratch help stir my interest? Possibly, but those kinds of opportunities were few and far between in the world of international finance, and at the startup I found myself feeling like a bona fide techie in ways I hadn’t in quite a while.

Wall Street Tech teams tend to be insular, sharing as little as possible, and often consider themselves to be finance people as much as tech people. There’s also the fact that, to be honest, most Wall St tools are far from cutting-edge, even though the applications themselves may be. Outside of relatively small “new technology” areas, things seem to be limited to C++, Java, maybe Perl. Being restricted to those languages eventually made me feel like I was mired in ’90s technology and sheltered from a lot of what was newer and better.

Born-again geekery aside, there was something I got from working at the startup that was probably much more beneficial to my career and mental health, and for any clients I may do work for in the future. I was able to play the kind of role that I hadn’t had a chance to in ages, and to confirm my feelings that this was where my main strengths as a technologist lay.

Specifically, I helped transform a largely “analog” set of business requirements into a concrete database schema, sets of UI components, well-defined application use-cases, etc, with almost no hindrance, before any development started. I ended up in this spot largely due to luck, but also because when speaking to the company’s principals about their ideas I made it clear that this was a crucial first step that regularly gets short shrift, with disastrous results, and fortunately they trusted me.

Yes, I’d had this kind of role many times over the years, but I was able to do it properly this time, without the extra baggage of dubious legacy code, ultra-fine divisions of labour among many teams, and mountains of bureaucracy. The pressure of all this responsibility was balanced out by my confidence that this was something I was really good at and, incidentally, enjoyed doing. Were the startup’s founders taking a chance by placing all this authority in my hands (along with the project’s one full-time developer)? Sure, but in this case their gut feelings based on our up-front discussions and their conversations with my references turned out to be right. (Good thing, for all involved.)

Hang on – if I do this thing really well... you'll reward me by making sure I NEVER DO IT AGAIN?

An equally important side-effect of my experience was honestly confronting what I’m *not* so great at. One dilemma that always accompanies long careers at large organisations is the pressure to become a manager — or, to be blunt, a bureaucrat.

This is a common phenomenon: Once you achieve a certain level of expertise at something, you’re given the questionable reward of not having to do that thing any more. So while I’ve got solid skills as a system designer/architect/developer, at various times I’ve found myself in senior positions dealing exclusively with things like budgets. Why? Even if they’re technology budgets, is putting a died-in-the-wool geek in charge of them the best use of that person’s talents? At large global firms, climbing the tech ladder means eventually *not doing tech*.

To complicate matters, saying no to any promotion can be career suicide. (One former colleague of mine, a strong developer, rose to a position where, he joked, all the “coding” he was doing was in Visio — drawing system diagrams and flow charts.)

In the end, having identified what I’m confident was a perfect role for me, it’s also become clear why I was less than happy with my performance in a couple of managerial positions I’ve held, and it feels less awkward admitting it: They were obviously unsuitable jobs for me and, career suicide or not, I’d think very carefully before accepting them again. It’s just as helpful to get confirmation on what you aren’t cut out to do as what you are. ®