How I Learned to Manage My Small Team of Devs and So Can You
5 proven tips that can really boost your team’s productivity
Working with a small team may sound easier as opposed to working with a very large one, but the truth is you're going to face many challenges there as well. Especially if you are inexperienced as I was.
I know that in the beginning of a startup, everyone can take the role of the developer. So this goes out to you, the lead developers, the project managers, the CTOs and CEOs… to those who are starting or joining a startup of just a handful of devs.
No one likes changes
One of the worst things you can do to your team as the lead developer, is to organize and implement the code of an update, share it with them so they can start, only to realize there are changes you need to make. Everyone’s work will be affected, and that’s going to put the whole update behind schedule!
Obviously you can’t anticipate every little thing that can go wrong, but the more you’ve tested, the smaller the possibility of you needing to change something.
Create concise documentations
Do you remember back in college where there were programming courses that you had to create documentations for? That suuucked!!! “Why would anyone need a 10-pages documentation for a program assignment?” I used to think. “Just run the damn thing and see if it works or not!”. Well, it seems our professors knew better! Who would have known, right? 😛 Writing documentations, isn’t necessary just in big cooperations… even if you have a team of 2 devs only, write them!
I myself have seen a great deal of quality improvement in my projects when I took the time to explain to everyone in a doc what needs to be done, and how. Do you develop the backend of a new feature? Great! Include all new database structures, new endpoints, their parameters and responses, and anything else worth noting.
Here’s an example:
NEW STRUCTURESStory {
text: String, // optional
imageURL: String
likes: Int,
comments: Int,
views: Int,
reports: Int, // if > 2 we’ll put a blur with a message
user: JSON, // { id, gender }
createdAt: Date
existsUntil: Date // createdAt + 24 hours
}----------------------------------------------NEW ENDPOINTSgetStoriesOfUsers {
params: {
userIds: Array<String>,
shouldFetchCurrentUserStories: Bool
},
response: {
stories: Array<Story>, // empty array if none
currentUserStories: Array<Story>, // empty array if none
likes: Array<Like> // empty array if none
}
}It's called from the home page, as soon as the current user is fetched
See how straightforward it can be for the frontend developer — or anyone correlated— this way? Especially in these Covid times, where everyone works remotely, it can be a great way to communicate any changes/features.
Make sure to include any mockups in the same doc… It will make it easier for the developers not to have to look in separate files.
Visualization is Organization
Having a detailed doc to guide your team through the things they need to do is neat. What’s even neater, is the use of a management app that helps you have a more visual sense of your tasks. Such an app is Trello*, which offers a suit of tools like assigning tasks to certain people, set due dates for each task, categorize them under titles and more.
Here’s how it looks:
As you can probably guess, these apps are designed in a way that every time a developer drags a task to the next category, he/she gains a sense of accomplishment! It becomes easier to keep working when you can see your progress.
The best thing you can do, is to use both a project management app AND write documentations
* I’m not affiliated with Trello… I just genuinely like it!
Shorter updates, faster implementations
Another thing I’ve come to realize, is that it’s much more efficient to have multiple but small updates than having a single, huge one. How is that possible, you ask? Shouldn’t it take the exact same time? Well, no. You see, people that work on one update for a long period of time, tend to find it monotonous. And it does make sense if you think about it. When an update is short and you finish it quickly, you feel like you made it quick. Otherwise when you finish a part of a big update and you still have lots to do, that feel of a burden is still there.
Of course there are times when an update is big by its nature and cannot be divided into smaller ones. There’s really not much you can do in that case; Just try not to have major updates one after the other. Put some little ones in between.
Does everyone agree?
Always, I can’t stress that enough, ALWAYS, communicate the work that you think it needs to be done with your devs! In a small team, everyone should have a vote! Especially if you don’t have the money, you can’t just demand things from them.
And I don’t just mean to discuss if you should develop a feature or not, but also how that feature could be. You would be surprised of how much better an idea can become when everyone pitches in!
Summarizing
Here’s the recap of this story:
- Before assigning each feature to a dev, first make sure there won’t be a need to change anything
- Document thoroughly each update’s requirements and specifications
- Start using project management apps
- It’s better to have many small updates, than one that’s very big
- Don’t just present fully-crafted ideas and just wait for their implementation… discuss them with your team!
I hope that after you read my without a doubt perfect guide, not bragging 😜, you will have gained a sense of how to gracefully manage that small dev team of yours.
Thank you for reading!
See ya in the next one (hopefully 😁)
