Building a dev team

Recently I came cross this interesting blog from Ben Halpern, talking about things to watch out when working on a side project. Although all of his points are reasonable and should be followed, one of them jumped out to me: “Start it yourself, eventually find help”. Over the side projects I have worked on with various teams, this bit is due for more elaboration, which is my goal for this blog post. Today I want to write about a few tips I learned over the years that make a successful development team.

Talk, talk, talk

From a discussion thread I followed earlier this week, developers value communication skills a lot in their peers. From a technical point of view, you want you co-workers to have clear and concise comments in code, and moreover, be able to explain things orally with a few sentences. Also when you get stuck on a tech issue, a weird bug for example, it would be wonderful if there’s someone in the team to talk to, and they may be able to shed some light to the question. As a little side note, I wrote another post earlier about “getting unstuck”, so have a read if you are interested.

From a more business point of view, communication skills are just as important too. It is crucial for everyone in the team to have some idea about what others are working on, and their progress. This is not just for management, but for developers to coordinate themselves. For example, if I am building a standard web app, I wouldn’t worry about Models and Databases if I knew backend isn’t ready yet, and more important, if I have a rough idea of where the progress is, I can preemptively integrate part of the database in, and catch bugs at an early stage, which is easier to fix.

Last but not least, and I understand this bit is kind of hard to achieve, team members should ideally build up personal relationships too. Talk about your weekend plans, and other things in life too. Personally I favour a more organic team, which feels less like a job and more like coding with friends. Let me know how you think about this in the comments, is it maybe too good to be true, or if you have seen or worked in a team like that?

You don’t need two warriors

If you have played a multiplayer game, you would know everyone in your team is here for a specific reason: warrior to be at the front slaying monsters, and healer at the back for support, for an over-simplification. In my opinion a dev team to have the same principle.

Prof. Diane Pozefsky, one of my professors at uni, has this team layout for a team of four, which I think is quite nice and effective:

  • Architect. Overall design of the system.

  • Designer. Design for UI/UX.

  • Product Manager. Contact point to client, vendor, users.

  • Writer. Keeping documentation updated.

Of course everyone still has to code; these are more like extra responsibilities for each of them. I like this structure for two main reasons: a) it separates UI design and system design, considering the fact that most developers who focus on the efficiency and layout of the codebase probably know less about what users want to see and feel. (No offense to sys design people who do) And b) you NEED someone to handle the docs. I have seen so many good projects with bad documentation, which just confuse me and make me not use their services at all.

My team build

Since most of my work is web dev, I have a slightly different team structure to the one described above. If you want to know about some web dev basics, check out Dave’s video. My team build looks at this:

  • Front end guy

  • Back end guy

  • DevOps

Which basically just follows the structure of a standard web app. Although this has worked pretty well for a few web apps I worked on, so I would personally recommend it to people starting a simple web project.

Fluid Team

I have to admit I stole this term from this blog post, which talked about having a team in which everyone can do what their want to do, and thus improve passion and the product ultimately. Personally I have a different take on the term. In an ideally fluid team, everyone should be able to help with others, or you have a “jack of all trades” in your team who works as a fluid utility member from places to places.

Now I understand that’s very hard to do, and personally I have not had the fortune to be in such a team. Let me know how you feel about this in the comment. Would you rather have work turf clearly established, or would rather have a loose border that others can come in and help, and vice versa?

Closing thoughts

When you are first starting out in the world of real projects, simply working in a team can present challenges, at along building one for yourself. My tip would be just go for some “blind match” opportunities, where a team is built randomly. This can be uni projects, hackathons, etc. When you enough experience working as a team, and you have seen each team work out or fail, you would have absorbed some idea about team building. Then try to go and have your own team. Maybe the first few would suck, but just keep going and trust you will get the hang of it. :)

See you all next week.

© 2018. All rights reserved.

Powered by Hydejack v7.5.1