Bootstrapping a New Software Development Team
Have you just been hired at a company as a tech lead for a brand new software development team? Have you been promoted to tech lead on your current team and have no idea how to get things rolling? I was in a similar position nearly two years ago, with some ideas on how I wanted to run things but mostly filled with uncertainty and plain lacking knowledge. Here’s how I handled things. Hopefully this will help put you in the right direction if you’re in a similar situation.
All the written guides I mention can be found in this repository. Use these as a starting point; modify, tweak, and update to fit your team’s needs.
New team lead here, help!!!
My current job has taught me nearly everything I know about software development. After my initial onboarding period, I was given assignments that ramped up in difficulty, starting with small scripting tasks and bug fixes that eventually lead to my first web application. Over the past few years, I’ve learned how to take a web application from an idea to deployment. Though software development isn’t just writing code; there are lots more things involved, both technical and non-technical. While I was busy developing applications, my team lead was both developing applications and handling many invisible other things. The discovery, and subsequent codification, of these things, would become crucial for me very soon.
Nearly two years ago, I was promoted to team lead. But one crucial piece of learning that I was lacking when this happened was… how to lead a team. We were in the process of rebuilding; two of our developers had left and our designer had gone to grad school. Not only did I need to rebuild our team, I needed to figure out how to run things, establish processes, get us all on common ground so we could work effectively. How were the new developers going to collaborate with our new designer? How would we manage and track our work? How often would we deploy? These and other questions were at the forefront of my mind in that first month.
After I spent some time documenting the invisible processes and unspoken rules established from my previous team, I conducted as much research as I could on the subject of forming and leading a software development team. What I came up with was, to use a phrase often quoted at my company and in improvement science, “possibly wrong and definitely incomplete”. In a situation like this, where you’re learning as you go, this is most definitely the case. I wrote document after document on what I thought we needed but not necessarily what we actually needed. I have since revised and updated some of the documents. Some of my ideas did not survive the initial months of the new team. Some were tweaked. But all of them served as terrific starting points that pushed our team to where we needed to be.
The process
I like to write. Writing processes and ideas down on paper (physical and digital) “codifies” them, makes them concrete. They are physical (or digital) things you can point to and say “this is how we version our applications” or “this is how we plan our sprints”. The tricky part is getting your team to actually read your documentation. Everyone has their own learning style, and not everyone like to learn by reading. That’s why it’s a good idea to combine your documentation with a presentation and a demonstration.
Once you’ve given your team enough time to read (or not read) your documentation, you should present it. Try to create an engaging presentation with visual aids and diagrams. Clarify any dense bits of the documentation and answer questions. Then you can show your team the processes and ideas in action, letting your team participate in the demonstration if you can. In this way, you can cover multiple styles of learning: linguistic (reading the documentation), visual (seeing visual aids and diagrams of concepts in the presentation), aural (hearing you explain the concepts in the presentation), and kinesthetic (participating in the demonstration). Indirectly, you also cover social learners (the whole team learning together during your presentation) and solitary learners (make your presentation available in a team-shared location, like a Google Team Drive, for people to consume after the fact).
The more learning styles we can cover, the more efficient our onboarding becomes, and the faster we can get our new team members writing quality code, sketching killer designs, and dominating our Jira backlog.
The list, at-a-glance
Here is the list of documents I ultimately compiled, with a brief description of each. You can find all of the documents mentioned here, with a few exceptions, in this repository. The documents not included in the repository will be noted below with a “not included” tag. You are also free to write these documents the way you want. In any case, here is the list:
- Priorities and objectives — These are priorities and objectives for your projects and your team. I like to break these down by fiscal year or quarter, then by project. I also include a “general” project that includes any team-level priorities for that quarter or fiscal year. Regarding objectives, these can be either high-level or specific, or both. Some examples are “revolutionize the social media space”, “be a learning organization”, or “phase out our legacy application”. If you have some specific learning objectives, they can be something like “deploy at least one Node.js application” or maybe “obtain Google Cloud Architect certification for every developer”.
- Project deep-dives (not included) — For each project your team is responsible for, whether it’s a legacy application or something currently in development, write up a technical deep-dive. You should provide a conceptual overview of the project, the key components of the application, and the current (or proposed) technical implementation. These will be vital when you onboard new developers as they will help them get up to speed. They can also be guiding documents that you can refer to when thinking about new features or philosophical concerns for a project.
- Onboarding (not included)— You will likely hire new team members as a team lead. Outline all the accounts you’ll need to create, what applications you’ll need to grant access to, how you’ll introduce them to all this beautiful documentation you wrote, and the projects you’ll need to onboard them onto as well. This document will be very specific for your team. Once you’ve written it up, any future onboarding of new team members will hopefully be trivial.
- Setting up your computer for development — Any new developer should have a local development environment identical to yours. Write out a list of applications, utilities, and libraries you want your developers to use. That way, they can just go right down the list and install what they need, Or, you can use this handy repository that will guide them through the process. Feel free to fork the repository and modify for your team’s needs.
- Agile overview — Let’s face it, everyone says they “use Agile” but what that ends up looking like varies wildly between companies and teams. Ideally, this should be written by your Agile-trained project manager after they have determined, with your team, what “flavor” of Agile you will use. If, like me, you start without a project manager, you’ll need to rely on previous Agile experience or research this yourself. Plan out and describe your team’s various Agile ceremonies, outline how your sprints will work, and include any detail on how you want tickets to be written up.
- Coding style guide — I know there are many style guides on the internet that developers can use. They are often language-specific, so it can become tricky to enforce a common style guide when you code in multiple languages. Your style guide can most definitely just be a compilation of common guides from multiple languages. But some developers have a specific way of doing things (see tabs vs spaces). This is your chance to write your own or compile/pick-and-choose elements for your team’s style guide. It’s the best feeling in the world when everyone’s code looks the same; the code is pretty, and it makes code reviews faster.
- Git usage guide — The way git is used to development seems to differ between companies, and teams, and even between developers themselves. Establish how you want your team to use git. What branch gets deployed to production? What branch is branched off of for development? What do we write in our pull request descriptions? Answer all these questions here.
- Development pipeline — This will outline the process of development from Jira ticket to deployed feature. This document may overlap a bit with your Git Usage Guide and your Versioning Guide.
- Versioning — This is probably self-explanatory for some developers. As with coding style guides, there are already terrific guides on how to version your applications. What’s important here is that we establish a system for our team.
I’ve also included a few documents that I wrote specifically for my team. These might be useful to you. You can see an example of each one by visiting the same repository linked at the beginning of this post.
- Sprint Planning checklist — We were having trouble producing consistent results from our Sprint Planning meetings so I wrote up a checklist to function as an “agenda” for the meeting.
- Release plan — At the end of your sprint, once code has been reviewed and tested and ultimately approved, you are ready to “release” the changes from the sprint. Whether this is done through Jenkins jobs or custom deploy scripts, this is the place to outline that process.
- Testing protocol — Employing unit tests and functional tests in your applications should be a requirement. But it’s often a good idea as well to have humans test your code, especially non-developers (and maybe a small set of your users if you can). They can uncover new bugs and reveal design flaws that you didn’t think of. In order for the “human testing” to be a fruitful as possible, I wrote up a protocol for the various ways someone could test our applications and how to provide actionable feedback.
- Crisis plan — This was another one of those invisible things, something I picked up from observing other senior developers and from researching best practices. As with all the other invisibles, I decided to codify this by writing it into a full plan. When a catastrophic bug is encountered in your application, something that prevents users from accessing some or all of your application, you should have a plan in place to rectify the matter. I have included my plan here verbatim as I feel it is general enough for all teams to use.
