• Home

  • Custom Ecommerce
  • Application Development
  • Database Consulting
  • Cloud Hosting
  • Systems Integration
  • Legacy Business Systems
  • Security & Compliance
  • GIS

  • Expertise

  • About Us
  • Our Team
  • Clients
  • Blog
  • Careers

  • CasePointer

  • VisionPort

  • Contact
  • Our Blog

    Ongoing observations by End Point Dev people

    In-House to Consulting, Rinse and Repeat

    Steph Skardal

    By Steph Skardal
    March 28, 2018

    In House vs. Consulting
    Photo by Matthew Henry of Burst

    Hi! I’m Steph. I’ve been working 10+ years now as a software engineer, and I’ve spent ~4 years of that as an in-house developer at 2 different companies and 7+ years as a consultant here at End Point and as an independent contractor. Whenever I’ve started a new position, I get asked “What’s it like on the other side?” or something along the lines of “Is the grass greener?” I thought my answer to this was good blog fodder, so here we are.

    If you google “in-house vs. consultant”, much of the results are written from the perspective of a company looking to hire either in-house engineers or looking to outsource to consulting companies. Here’s my approach to answer the question as it relates to employee happiness, skill development, and job satisfaction.

    Working as an in-house engineer

    • Working as an in-house engineer can mean that you may focus on one technology (or one web stack) and even one main codebase, although this isn’t necessarily true. When I worked for Backcountry.com a while back, the main application was an ecommerce application running on Interchange, and that’s where I spent most of my dev time. But as my experience grew, I began working on other internal B2B tools as well.
    • With a small team, it’s possible you might adopt consistent style rules in the code.
    • In an engineering role as an in-house dev, you might not be directly involved in sales efforts of the company.
    • With a small, single team, there is only one set of team dynamics that you have to navigate between, which might allow you to build stronger relationships with those team members and understand how to work with those team members efficiently. Of course the disadvantage of this is if you don’t get along with a team member, you should learn how to work with them.
    • Working as an engineer for a product company might mean a steady stream of income and less micromanaging of expenses. This might translate to benefits like maternity leave, simply because the revenue stream can support paid leave, but this isn’t necessarily true and highly dependent on the circumstances. On the flip side, if the company isn’t doing well financially, there isn’t a resource for additional income, which could translate to loss of jobs for employees.
    • From my experience, working with a small team, there have been better processes in place for code review and code feedback, ultimately resulting in better growth of individual engineers. I have found that while I was an in-house engineer, I did a deep dive into one technology stack, and my skills greatly improved with that depth of experience.

    Working as a consultant

    • Working as a consultant often offers the ability to be exposed to many technologies, many technology stacks, and more variety.
    • From my experience, adaptability is highly valued in the consulting space because you are exposed to different technology stacks and development processes. It is valuable to move seamlessly between teams and technologies.
    • Depending on how your company is set up, there can be a wide range of types of client interaction. Some clients want to learn how to make website changes and your role is to support them in that desire. Other clients may be hands-off all dev work, expecting you to have the expertise to drive technology choices. Clients may have very limited budgets and want a consultant to provide the most value to them. Client management is very important here.
    • In consulting, from my experience, it is not unusual to participate in sales efforts to provide estimates or technical solutions for proposals.
    • While I find many successful software engineering consultants have a breadth of knowledge, companies can often grow talent in specific areas or with specific hires to gain a depth of knowledge in specific technologies. The benefit to other employees is the access to expertise that may translate to better efficiency for clients (for example when I ping other expert co-workers when a question is not in my skillset).
    • By nature, consulting is diverse, so job stability may be decent if clients are overall successful and you are successful in working with them.

    Working for a company that does both consulting and product development

    • I’ve seen a few companies that have been successful in both consulting and product development, where their employees develop a product but supplement company income with expert consulting.
    • From an employee perspective, this may offer a nice balance between breadth and depth in working on specific technology stacks.
    • A company that does both product development and consulting successfully may be more stable financially due to diversified income streams.

    In-house & consulting

    • In both scenarios, I’ve found there is always a feedback loop going on in during active software development. You complete some task, pass it on for review, wait for feedback from a decision maker to iterate to the next step or adjustments. I like to fill in time when I’m waiting by working on another feature (in-house) or other client work (consulting).
    • My personal experience has taught me that communication is one of the most valuable assets to have as a software engineer, because you are responsible for translating business needs to software. The better you can communicate with intent, the more efficient you will be as an in-house engineer and as a consultant.
    • The ability to calculate work effort and manage priorities is also a highly valued skill in both employment circumstances.
    • From my own experience, I’ve been lucky to receive flexibility in both scenarios working half/​part-time since my first daughter was born. In the consulting space, working limited time may be suitable for limited client budgets, but as an in-house engineer working half-time translated to less output while still providing knowledge from previous experience.
    • I’ve also found that in both scenarios, some job satisfaction comes from the happiness of the client (or decision maker), which can put you in a difficult position if your client isn’t happy. Every time the decision maker walks away dissatisfied, I think you have an opportunity to improve how to communicate and work with them to build a successful relationship.

    Conclusion: Is the grass greener on the other side?

    If you ask me “What’s the best option for me?”, I can’t answer that for you in your particular circumstances. I think an in-house position establishes a good foundation in a single set of technologies that could be beneficial as you progress in your career should you choose to climb the ladder in your current position or move to a consulting position. But if you are adaptable, and want to grow your breadth of experience and exposure to technologies, I think consulting is a good fit.

    In true consulting form, I can only suggest to anyone considering a job change from one to another that you evaluate factors such as job satisfaction, compensation, flexibility, and stability when you are evaluating your options.

    tips software


    Comments