Next Friday, I’ll be presenting at SandCamp on best practices for teams. Naturally, I’ve been thinking about what makes a good team in general, and a good software development team specifically. For most of my career, I’ve been part of development teams at development shops or technical companies. Those places already had forward-thinking technical people making infrastructure decisions and crafting the technical culture (for better or worse). By the time I came along, most of the kinks had been worked out.
But I don’t work at a technical company right now - I work at an advertising agency.
The more time I spend here, the more I realize: advertising agencies are the exact opposite of technical companies. They’re filled with forward-thinking non-technical people. Most agencies used to be print/media focused. But, times change and agencies change along with them. Now most advertising agencies have in-house development teams. A lot of these agencies brand themselves as bleeding-edge and interactive-focused. But those same people who have brilliant creative visions for agencies are rarely able to nurture a technical department. Developers at ad agencies often become after-thoughts. After the brief is done, a producer will get a developer involved to “execute the vision.” By that time, it’s often too late to correct flaws in the design, or point out potential architectural pitfalls.
And sometimes, developers and designers intuitively know that the way they’re working isn’t right, but can’t identify exactly what the problem is or how to fix it. If you find yourself in a similar situation, take the quiz!
Answer True or False to each of the following statements:
- My entire department uses the same version control system, wiki, and ticketing system.
- I’m a developer starting a new project. I know where to go to create my repository, tickets and anything else I need.
- I’m a developer looking for comps. I know where the design team keeps their comps for my projects. I also know each time a comp is updated or changed without having to go look.
- Each time a project is scoped, I, or another developer, am consulted to validate the feasibility of the overall plan.
- I have regular meetings with my larger, non-tech project leads about the status of the project’s different parts.
- I have regular meetings within my technical department to do code reviews / educational seminars / showing off neat stuff.
- I’m excited to learn from other members on my team. I think I work with amazing programmers.
- I’m a developer looking to improve my skills. I know my managers are going to be excited to help me do so.
- I have a suggestion about a breakdown in our process. I know my managers are going to be receptive to my ideas.
- I can approach the design team about a problem and be sure we’ll find a solution that meets both of our needs.
If you answered true to most of the statements above, congratulations! There is nothing more to do - rejoice in your awesome team and go build cool stuff!
If you answered false to most of the statements above, it’s time for an intervention. Personally, I’m working to create an infrastructure and cultural shift that ensures that everyone on my team will be able to answer true to every statement. I’ll be writing more about it, but if you’re doing the same, let’s talk.
Did I miss anything? Tell me! @drnikki