Great Engineering Teams
Building great teams is hard. We all know this. Nobody has the perfect recipe for creating a great engineering team, but I’m fairly certain that some things are obvious and should be heeded. What follows is a list of observations I’ve made throughout my career about what seems to work and what doesn’t. Perfect excuse for a good old “Do” and “Don’t” list:
Do: Encourage Side Projects
All good developers run into things that piss them off from time to time. Great developers build tools that help them fix the shit that pisses them off. Give developers space and time to work on things not on the roadmap and they’ll probably end up building tools that solve unseen business problems. Intentionally under-load developers (or go one step further and do away with deadlines) and you’ll start to see deploys run more smoothly, metrics start being captured, open source libraries and tools start being published and everyone is happier for it. Allowing developers time for side projects is an intangible, but I’m convinced it’s an investment that pays for itself and then some.
Don’t: Hire Asymmetric Managers
One of my pet peeves is seeing a shop employ a “manager” who’s job is to pester developers and make sure they meet deadlines. The best managers I’ve worked with always ask two questions during check-ins:
- How are you doing?
- What can I do to help you?
Good managers know that their job is to enable people to do great things by clearing roadblocks and getting the hell out of their way. If you have a manager who is constantly “whipping” their team into shape, things are going to go very wrong. Hire managers who help programmers as much as possible. We’re all on the same team.
Do: Support Async Workflows
Being a software developer involves blocking out large chunks of time to get into periods of deep concentration. Requiring developers to break for meetings or respond to emails / im messages / impromptu conversations immediately breaks concentration and can ruin a big part of the day. It also screws your remote employees if you have any. Zach Holman and Paul Graham have written about this much more elequently than I could hope to.
Don’t: Hire “B"s
Comprimising on hiring is the quickest way to build a shitty team. It can be tempting to hire some “juniors” that will need supervision, and there’s definitely room for people with a variety of experience, but you need to shoot for the best and hire nothing but. Hiring second rate developers will hurt your productivity and effect the morale of your best folks. Good people like to work with good people. Don’t fuck with that.
Do: Encourage a devops culture
As I mentioned, great programmers scratch their own itches. Hire people who know the whole stack. Great programmers should write great code, but also care about how it’s deployed and write or use tools that help you do that effectively and safely. Having a divide between developers and people who make sure their code can be shipped creates two problems:
- Your developers stop thinking about ops.
- You create an “us” vs “them” attitude. Developers complain about “conservative” ops people and ops people complain about “sloppy” developers.
Bottom line: making sure your production environment is healthy is everybodys job.
Conclusion
Most of this boils down to respect. If you’re shipping software, you’re an engineering company. Engineering companies need to be managed as such. Don’t treat your developers as second tier. Give them what they need, support them and your chances of building a great culture where people want to come and do great work will be greatly increased.