Skip

Working in a software agency versus a large tech company
January 18, 2013 4:34 PM   Subscribe

What are some differences to expect for someone working at a software agency for the first time, coming from the enterprise world?

I work as a programmer. For a while now I've been working for large-ish enterprise-y ecommerce companies, the kind with wacky furniture and hundreds, if not thousands, of engineers. It's basically all I've known aside from a few months working in a small PHP shop.

How will my experience compare to working at a small-to-medium sized software agency (that is, a place that develops applications for clients)? What are the various roles? How does the relationship between the agency and a client typically work? How stressful are such jobs, compared to the big enterprise type companies?

Perhaps someone who has made this transition could expound on their experience.
Thanks!
posted by deathpanels to Work & Money (1 answer total) 7 users marked this as a favorite
 
I've run a web development company for nine years now, and wasn't really anything before that so I can't comment too much on the transition, but I can tell you a bit about what life is like in our small shop.

Up until this week, we've been a team of four developers, three testers, and two founders. My partner and I split our roles; he's the primary project coordinator/manager/product consultant/de facto CTO for our clients, I'm business development, payroll, taxes, proposals, procurement, contracts, invoicing, accounting, purchasing, etc., with a side of project management/product design.

We typically try our best to hew towards agile, which is tricky when you're dealing with paying clients. We convince them of the wonderful merits of agile by being very transparent about what each of their features cost, in story points, and how many points we can accomplish per sprint. They use that information to build out their sprints with our guidance and have a good expectation of what they'll receive each sprint.

We split our guys up into teams of two, and we just added a third team this weekend. We rotate team members to try to ensure as much exposure across the company on as many projects as possible and to prevent siloing or knowledge hoarding or keyman issues. So far, so decent, I suppose.

Our workflow is based around Github, with different projects on different repositories and all stories and bugs tracked through their issue tracker. That allows our guys to figure out what stories they're working on over a given week and sprint, and have at it.

There's a lot of communication, there's a roping in of others for key architectural decisions, and there's a lot of fun. We try to get stuff done fast, because we charge a lot and clients expect a lot for that. My impression of larger software companies with internal projects is that it's much easier to slip timelines and flow into a true agile mindset where, if something's not done in a given sprint, it's pushed to the next sprint backlog and away you go.

There are budgets and timelines to hit, but their shortcomings can more easily be blamed on changing requirements, blocks from external sources, or any other number of issues. When we're doing client work, we really need to get darn close to our sprint goals, darn close to on time, and we need to push pretty hard to keep our clients on track in the middle of each iteration.

We have our roles split into basically two (perhaps three) general roles: senior developers and junior or just plain developers. Our seniors are set apart from a firmer grasp of CS concepts, exposure to a lot of the newest technology, and a keen architectural mind. There's something to be said about a developer who can build a web app: that's every one of our guys. But the guy who can really nail the database schema for scale, API implementation, and decide which technology stack to use on a given project tends to be the "architect" and that guy tends to be our senior developer.

I also find that our more passionate developers tend to surface into the senior role more quickly. Our seniors are hobbyists. They love this stuff and they enjoy it at work and then again at home. Our juniors get good work done and they solve problems well, but they tend not to push the envelope as much or tend to clock-punch a bit more. Post hoc ergo propter hoc, perhaps, or a bit of a self-fulfilling prophecy essentially, but either way, that's been my observation as I've worked with many, many devs of both types.

We tend to be very transparent with our clients because transparency is the easiest route. Everyone in the office knows what we bill and our clients know what their sprints cost and roughly what they're getting per sprint. It's our job to make sure we're driving value for each two week iteration and so that's on us. If we slip a bit or miss a deadline, we typically tend to eat it, because frankly, you can't ask a client to write another five figure check a third time for the same sprint because you underestimated how difficult the Intuit API would be to work with. So you pad and you make conservative estimates and you break things into smaller components and you work like that to mitigate as much as possible.

We also try to keep our guys working on whatever project they're working on without distractions. This is frequently easier said than done when you're a small shop and you have production code that sometimes breaks or another client who has an emergency request that has to go out because they have a huge feature on CNBC or TechCrunch coming up and you're their guy. So we find ways to work them in, without sacrificing quality of the main sprint. In our case, we're planning on having a 7th dev who acts as a "floater". (The position itself would float, too, and not just be one guy.) He'd be able to do hourly billable work throughout the week without pulling our guys from their gigs.

How stressful? That depends on your organization, your boss, your clients, your technology stack, and a LOT of other factors. I know of shops that burn their devs to the ground because they constantly over-commit and lack the resources, practices, and platform to back those promises up. We've spent a lot of time and effort getting our well-oiled development process machine rolling and that makes it much easier to crank out good code quickly.

We also try to work with clients we anticipate are a good fit for us. It's really easy when you're an agency used to churn-and-burn and pipeline concerns to just jump at the next easy almighty dollar, but that's a huge mistake that takes a long time to train yourself away from. We have taken on stupid projects based on simple math: this is a basic ecommerce site, we can have our floater slam it out in Magento, bill $18,000 and probably not use more than 40 hours of his time. Wrong. Wrong wrong wrong. The client was a nightmare, they were impossible to work with, they demanded tons of meetings, the floater slacked off, Magento is a shitstorm, and everything goes to hell. $18,000 was already only about $16,500 in profit, and now it's $14,000 and now it's $8,000 and now it's... how is this project three months old I know it's not all he does, but seriously what the fuck? And now we're barely breaking even on a one-time client in an old industry we have no business in pursuing for a client that will drive exactly zero additional dollars to us for a lot of headache and nothing else in return.

Textbook bad client. We've gotten better at saying no, and we've been blessed to have a more steady pipeline that affords us that privilege. (Of course, now we're having to tell clients we're four weeks out from our next open slot and getting yelled at for that as if they expect us to just have two guys in jump seats waiting to go as soon as the light turns green, on payroll, and just because we've been speaking about your project for six months, you expect that since NOW is when you're ready, so too NOW is when they're available.

The stress is definitely different. The clients put pressure on you because they want value and they want quality. They also have a lot of ideas, and we have to corral them, make sure it's understood what they cost and what the implications are and work with them to prioritize things and make sure that we're directing them towards the path that delivers value. Clients can waste money asking for tons of revisions on the stupidest thing and it's not our job to just put our head down and take their money. It's our job to gently nudge them towards the requests that will yield the largest bang-for-buck, so that they're thrilled to write us the next check and not blaming us for barely any new features in this release.

But again, a great deal of this will matter on the people around and above you. Like I said, we've worked REALLY hard building a process that we believe facilitates our developers kicking ass and taking names. We've automated tons of stuff, we've standardized our development environments and deployment processes, and we've landed on a narrow range of languages, libraries, and tools for the projects we work on, so that we don't spend the first two weeks deciding which new shiny toy we want to learn to use this project.

We also provide a fun work environment, no cubes, nice lighting, fun colored walls, cool office space, and whatever equipment our devs ask for to get the most out of them. It's not worth it to me to save $100 if you don't have a second monitor because now it takes you twice as long (or even more) to debug and test your code. So you need a support structure and even though we have our clients speak and interact directly with our devs, we also support them and step in and manage expectations and manage quality and stand behind our work.

It's a lot of fun, minus the persistent ulcer I've had for the last nine years counting the number of days until bankruptcy and hoping-slash-assuming that the next jobs will come in right when we need them. Nine years so far, so good, but it's a lot of work, and it helps to have a great staff.

Enjoy the transition and let us know how you like working a bit of a different pace with (probably) a fair amount more impact and a bit smaller margin for error!
posted by disillusioned at 12:00 AM on January 19, 2013 [1 favorite]


« Older I carefully change my photos' ...   |  I am looking for a rental agen... Newer »
This thread is closed to new comments.


Post