Read "Peopleware". Seriously, every page was written with you in mind.
Next, if you (as developers naturally do) struggle with the idea of management, structure and order, read "The E-Myth Revisited".
Peopleware TL;DR: Good teams are united by a strongly defined purpose (eg. get X defined and tests written by date X), and that is almost NEVER the same as the goals of the business (which is to make money). Don't create internal competition; overtime kills productivity; physical/mental space allows creativity; interruptions are deadly.
The E-Myth TL;DR: Aimed at small business owners, but as a team lead you're effectively running a business, and the rest of the company is your customer. It's a mere 5 hour read... JFDI :)
And if you're feeling really bookish, "The Mythical Man Month" - if you're under 50 this will shock you, because you'll realise that software in 1970 had the exact same problems that we do in 2015.
The biggest takeaway from The E-Myth for me as a software engineer was the idea of making a job easy enough for the least qualified individual to do it. The example they use is how to train completely untalented 15-year-olds to make burgers at McDonalds. McDonalds doesn't need to hire chefs.
In software engineering, I've seen teams look for years for a candidate with X years of experience in technology Y. In many cases, you don't need an expert, you just need a smart person.
Build up a library of books/articles as well as sample code and exercises. Then hire smart people rather than experienced people. We had a git repo with exercises in functional programming and scala along with unit tests and day one involved checking it out and getting started.
Also, simple code is more accessible to the "least qualified individual". You may sacrifice performance, but you will be able to scale more effectively as an organization.
Someone once told me that the key to scaling is tolerating inefficiency.
Example: Instead of a front end team and a backend team, have two full stack teams. If they are working on similar parts of the codebase, don't stop them. It's better for both teams to build the same piece of functionality and throw one away than to have one team dependent on the other. Many teams grind to a halt when they say "We could build this in a week, but let's let the other team do it because it will only take them a day or two."
I second the recommendation for MM-M, after recently reading it. You may find the chapters around how to structure a team to be interesting. Here's my review (posted elsewhere):
----
I decided to give MM-M a read, after seeing it repeatedly listed as one of the classics of the fledgling - as the book maintains - field of software “engineering”. Despite a few dry chapters extensively detailing the development of OS/360, the book holds up remarkably well for being forty years old. Indeed, many of its central, oft-repeated development aphorisms still hold value. Unfortunately, its advocacy for extensive and exhaustive planning and documentation cycles screams “waterfall”, and muddies what is otherwise - I think - a number of worthwhile recommendations:
1. Avoid the second-system effect by being ruthlessly practical
2. Build a prototype and throw it away
3. The essence of programming has an irreducible complexity
Aside from these, I noted with great interest Brooks’ suggested team structure which he refers to as a surgical team: 6-7 people in highly stratified, and complimentary roles, led principally by a “surgeon”-type chief architect. I’ve only worked within relatively flat team structures up to this point, typically set up in junior/senior relationships. Since this is a less frequently cited recommendation in the book, I’m curious to know if it has been implemented with any success.
Finally, this suggestion is tantilizing:
As a discipline, we need an extended information theory that quantifies the information content of static structures, just as Shannon’s theory does for communicated streams.
The lesson is basically, when you're designing a new system or product - make one with the knowledge that you're going to scrap and it start over. The value in doing so is that you expose flaws and design challenges that you can't anticipate through the speculation that occurs before you've actually started.
Another really good book about management is called _First, Break All The Rules: What The Worlds Greatest Managers Do Differently_ by Marcus Buckingham of Gallup Polls.
TL;DR: Different things work for different people, figure out what works for your employees and do that.
My big recommendation is that for kids, you reward effort, for adults, you reward for results.
Next, if you (as developers naturally do) struggle with the idea of management, structure and order, read "The E-Myth Revisited".
Peopleware TL;DR: Good teams are united by a strongly defined purpose (eg. get X defined and tests written by date X), and that is almost NEVER the same as the goals of the business (which is to make money). Don't create internal competition; overtime kills productivity; physical/mental space allows creativity; interruptions are deadly.
The E-Myth TL;DR: Aimed at small business owners, but as a team lead you're effectively running a business, and the rest of the company is your customer. It's a mere 5 hour read... JFDI :)
And if you're feeling really bookish, "The Mythical Man Month" - if you're under 50 this will shock you, because you'll realise that software in 1970 had the exact same problems that we do in 2015.