Joe Stump is the co-founder of attachments.me, Sprint.lyand SimpleGeo — and ex-Lead architect at Digg. In this First Round CTO Summit talk, Joe shares how to build a great engineering culture. He explains how to recruit rockstars (no, really), why managing engineers is like herding cats, whom to fire, why to avoid technical zealots and why peer code reviews matter. Below is an interpretation, not a transcript, of Joe’s talk. The credit goes to him for all the good stuff, and you can watch the complete talk in the video below.
Technology-Driven Startups Are a Misnomer
Over the past 14 years working in engineering organizations, one of the things Joe never really understood was the misuse of the phrase “technology-driven companies” — particularly in the startup world. Startups are supposed to be technology-driven and yet within a good majority of the companies that you work at, the engineers are treated as cost centers. Most of the time sales, BD and PMs actually drive the roadmap, not the engineers — who are the closest to the product and the technology.
How to Recruit Rock Stars
In order to build an engineering-driven organization you need to start with recruiting the right engineers to your company.
Everyone says to go out and recruit rock stars. But the reality is that recruiting rock stars is hard. The best engineers aren’t looking for jobs. So, when you try to bring on the best people (the ones who are likely already employed), make sure you check your ego at the door and actually recruit. Go hire people smarter than you, always. Sometimes these candidates might be so talented that they merit an even higher salary than their manager. If skill is valued above seniority, it should be a non-issue.
Do not send a recruiter to do an engineer's job. It’s the job of founders and CTOs to be personally involved in the recruiting of the first 30 to 40 team members. Once you identify a great engineer, send your very best engineering employee who's personable to go after the person (this could be you). Make sure this individual can speak the candidate’s language and pitch them on the things that actually matter. Engineers care less about equity, salary and benefits and more about the problems they’re going to be working on. Make sure you’re targeting candidates who will find your problems compelling — and sell them hard.
If you get to a point where you’re ready to make an offer, and they’re ready to accept, don’t be stingy. If the right person wants a $110,000 salary, the right move may be to pay up. At the end of the day, $20,000 amortized over two years is not going to negatively impact your burn in the way that you might think — and someone else will surely step up and pay the engineer the salary they deserve if you don’t.
Managing Engineers is Harder Than Herding Cats
Now that you’ve recruited rock stars, you actually need to build stuff. One of the most difficult steps in managing engineers is to stop coding yourself. Managing engineers will probably be the hardest job you’ve ever done and will most likely be the hardest job you’ll ever do — it needs all of your focus. Stop coding and start managing. If you’re spending 50% of your time recruiting, how do you think your code quality is going to look? If you code as a technology leader, you will slow down the organization and be a roadblock — don’t do it.
Engineers Are Lazy (By Design!)
There are times when you absolutely need to call bullshit on engineers. The best engineers are lazy — that's why they get into automating and coding things — so you need to know when they're bluffing. Engineers are also difficult because they protest everything. They’re stubborn, vocal, motivationally challenged — and that’s actually a good thing. You need to recognize this and be willing to call them on it.
Cultivating Culture Through Communication
Some founders think that you hire a bunch of great engineers, put them in a room and awesome stuff is just going to come out. Unfortunately, that’s just not the case. You need to manage and cultivate your culture if you’re going to build great products — and you can do this through communication.
Holding 1:1s is a great way to do this — and they need to be more than status. Turn your weekly 1:1 into a tool to learn more about what’s going on in your company and what’s bothering your employees. This is the one place where you really need to build trust with your colleagues and where they feel they can have an open line of communication. Ask things like, “What’s really bothering you?” This isn’t your time, it’s theirs.
As a CTO or engineering manager, another challenge in communication occurs around long-term company vision. Implementing the vision of the founding team takes a long time — often years. It’s your job as an engineering leader to constantly communicate this vision. You need to beat the drum over and over and over again.
Even if you’re constantly reinforcing the vision of the company, gossip and rumors will inevitably start. Gossip is usually a misinterpretation of your vision and plan. So many times an engineer heard something from someone about an upcoming feature and they don’t agree with it. When you trace the chain back, you quickly realize the feature isn’t even on the roadmap and it was just a misinterpretation.
To stop this misinformation, you should be as transparent as possible. At SimpleGeo, the entire board deck was presented once a month to the whole team so everyone knew where they were and where they were going. You can also generate a weekly email that discusses what was accomplished that week and what’s going to be completed in the upcoming week. Keep the information flowing at all times.
Firing Assholes
A lot of people say don’t fire great engineers — but they’re wrong. It only takes one asshole to destroy an entire team.
After you’ve fired any assholes, you should then turn to those engineers with the hero syndrome. You know, that guy that leaves on a Friday and comes back on Monday exclaiming, “Hey! I re-wrote the whole site.”
There are two fundamental flaws with these sorts of people:
High burnout rate: They’ll have 12 or 24 months before they do a nose-dive and then bounce to some place in Southeast Asia and don't come back.
Discontent and discord within the team: The hero is going off on his own and will crush team dynamics.
For these people, do everything from sending them home to mandating a vacation.
So you’ve handled the assholes and heroes; now onto the technical zealots. They’re the ones who think every nail is a PHP hammer, or every screw needs to be tightened with Rails. If you allow your engineers to become zealots, it will force you down a path of only hiring specialists.
If your engineers are basically, "Come hell or high water, all we're going to code is Rails or CodeIgniter or Django," it will inevitably lead you to hiring only those types of people. You also don’t want to get into arguments around technical religion. You want to use the best tool for any given problem. If you let this go on too long, what’s left is a syndrome called technical atrophy.
Knowing What to Promote
Promote ownership within your organization. Empower people to make those technical implementation decisions on their own.
Promoting ownership is often difficult for architects and senior engineers. Newcomers will come in and say, “We want to write this new thing, and we want to do it on top of Mongo, or we want to do it in Node, or we want to do it in whatever the new hotness is.” Let them choose these things. If you do decide to override, choose very wisely. As long as their choice is generally in line with your standards, conventions and general philosophy, you should go ahead and let them pursue their intuitions.
Promote proper design, too. Engineers really respond well to getting enough time to properly design and implement something.There's a difference between properly designing something and properly implementing something. You can design something properly and just not implement all of it. And that's OK, as long as you give people time to come back and fill in all the holes. Always remember to either allow engineers the time to properly implement the code to begin with, or make sure they have time to revisit and refactor in the future.
Finally, get behind peer reviews. Joe has never encountered a code review where at least one major bug wasn't found, and chances are you will squash some issues too. It’s also a time where your engineers get together, sit at a table and talk about what they did line by line. That builds a sense of camaraderie and teamwork. Junior engineers are built up by senior engineers — and senior engineers by junior ones. It brings the organization closer together.