5 Thoughts After 5 Years — Building a Successful Engineering Team at a SaaS Startup

Johnny Dobbins
Jan 17 · 6 min read

In deciding to join a SaaS startup 5 years ago, I understood that every fiber in my being would be challenged to change and grow. As the second hire, I recognized that my past accomplishments across a very storied career would mean little. As part of this growth exercise, I welcomed the idea of ‘starting over’ as I was certain it would offer me an education unlike any other.

I was not willing to walk away from everything I had learned, however. Some of my core beliefs would not change and I made it my mission to make them a part of our startup culture. Here are the 5 things that helped me grow our startup through four seed funding rounds and finally our series A:

  1. It sounds silly to have to say it, but every hire matters.
  2. It is difficult for some, but learn to challenge ideas.
  3. Understanding what code to write is much harder than the actual writing of code.
  4. A healthy culture means you have a healthy company and product.
  5. Security and process do not slow you down, they drive long term success.

I would like to go deeper into each of these points; while appearing as obvious and perhaps even generic, there is a story behind each.

Every Hire Matters

In a startup, your people are everything. Literally. They will likely represent eighty percent or more of your cash burn. In the engineering world, we often do not consider this and may be excited about bringing in that eccentric and likely wizard-like engineer. Do not do it.

Make your early engineering hires from a different pool of people; hire a person with a diverse background and maybe even just an “okay” coder. This person should have failed at something that they care passionately about.

In my experience, the best product developers are those who come from a liberal arts background, curiously enough. They are self taught coders and understand that they may lack what CS grads have; this self awareness will drive them to question everything they write. That is the key to it all. The arrogance and assumptions that sometimes comes from those “who know” will lead your culture, the codebase, your product and indeed your organization to an untested and often toxic place. A working function does not mean success, it only means that you are able to write something that can pass a unit test. It does not mean something valuable has been contributed.

These “Superstar” “hero” “magicians” are more likely to write code that only they can maintain and understand — or at least that is my experience. This can also create a toxic culture where your company cannot do without this person.

Learn to challenge ideas

You are not all knowing — and neither is your coworker or founder. Be okay being challenged and be okay challenging people. Seriously.

The founder or your peer may have the best idea in the world, and you know it and recognize it. But challenge it anway. In doing that you help them, and, indeed, your product and organization backup and solidify product direction and strategy. Make people defend their ideas and be okay defending your own. If people can not do this, then it likely is not a great idea and we can all move on.

Some of my best product moves and engineering choices came from heated whiteboard conversations where I defended and evolved my ideas. Allow yourself to be influenced and surround yourself with engineers who will do the same. I have seen mediocre ideas become multi-million dollar product offerings through intensive and intentional collaboration and constructive contention.

What to write is much harder to know than the act of writing the actual code

See point number one and two. Hire critical thinkers who are okay being challenged and then get to work on defining the value of what you want to build.

Once you think you have identified that value, validate it. Doubt yourself. Doubt the idea. Seek validation of the value in your idea — externally. Use a mentor or peer group external to your organization and get their feedback. Allow yourself and your idea to be challenged. Be certain of the value of your idea before you allow one line of code to be written.

Invest in a Minimum Viable Product (MVP) and write throw away code to build it out. The point, once you have your validated idea, is to confirm if it works not only technically but also has value in practice. Quickly get this MVP in front of the same group; iterate as many times as necessary before investing in the actual development of the idea.

You will identify alternate use cases, different value and even technical needs during this process; this ultimately becomes your epics and user stories that you and your product developers will code out.

Avoid, like the plague, product developers who say “yes” to everything you ask for. Of course they CAN built it, but SHOULD they?

You will end up with a more simple and better defined product with explicit value as well as an imminently more maintainable codebase.

A healthy culture drives a healthy product drives a healthy company

Hire smartly, challenge ideas, create an understanding of what value is and turn your team loose. Empower your product developers in every aspect.

Nothing is more pleasing than writing code that people will actually use. This is the root of quality and a healthy culture within an engineering team.

No one likes to be sent on a fools errand or to spend time on projects where value is poorly defined. We all want whatever we are working on to be a success.

Create a culture of quality. QUALITY OF LIFE. Not code quality, though the two are highly correlated.

Ensure your team gets downtime; I am not talking about the hilariously bad concept of “unlimited vacation time”, either. I mean real downtime, on the clock, so to say. People who work in pressure cookers over extended periods of time will break down. Make sure your team gets what I call “window time” where they can peacefully stare out of the window and contemplate life. If there is magic in an organizational happiness, it comes from that “window time”.

Finally, if you are in an “unlimited vacation time” environment, make damn sure you and your team get an appropriate amount. Do not sacrifice holidays and personal down time for the “success” of your company; trust me in that it will do little more than turn everything toxic — and often more quickly than a poorly defined user story.

Security and process do not slow you down

Process is the glue that supports the eventual scale of whatever you are building. Adopt a healthy methodology that is clearly defined and stick to it. Being able to measure growth means being able to measure success.

Fives years in, I can look back at every major decision made in our product and tie it to a jira ticket. When you are being acquired or seeking more funding and going through the due diligence phase, nothing is more satisfying than being able to lean on the artifacts from your process in explaining the who, what, when, where and why of today’s reality.

Security. You either get it or you do not. From day 1 of your product through your last breath, security is everything. In the SaaS space, SOC2 is the rule. Learn it and use it as your guide as you build out your team, product and infrastructure. You do not have to be compliant on day 1, but you absolutely should be before you scale your company.

In the end, these five guiding principals have kept me sane and ultimately drove success in our engineering group. In the future, I will write about the five key learnings from my first five years at a startup — things I absolutely never considered in any of my past work. I am not joking when I say they were life altering growth points for me, professionally.

If you have not read it yet, check out 5 Learnings After 5 Years — Becoming a Successful Engineering Leader at a SaaS Startup.

>>> import this

The Startup