Yesterday you were a senior developer, happily spending your day working on the scenario or user story that had been assigned to you. When you sit down with your manager, they ask you to take on this new role of a Tech Lead and you accept, because, why not…

Original Post on TeachingTechLeads.com

What new responsibilities have just been added to your day to day life?

Gathering Requirements

Every project starts with someone realizing that they have a problem. That person complains to someone else, and sooner or later, they realize that IT needs to come and fix everything.

You’ll be meeting with the business, or the client, to hear about what their problem is. You listen, you ask questions, you take in as much information as you can before even thinking about proposing a solution. And then you propose it.

“Here’s how we can solve your problem.” Once they agree, it’s time to get to work.

It’s not enough for them to agree with the overall solution, you need for them to agree to the smaller nuances as well. The last thing you want is for them to see everything completed and not be happy with it.

Small feedback loops are key.

Designing the Solution

Once you have a sign off, it’s time to start putting together how this solution will work. At this point, depending on the size of your organization/team, you may be working alone or with an Architect of some sort. You’ll move from the abstract to the more detailed analysis portion of “how can we make this thing work?”.

Once you have a rough sketch of the solution and all its moving parts, your internal team process begins. My team uses BDD to implement our rules, you may use TDD to complete your Kanban tasks, or Scrum to iterate through user stories; that’s up to you. But, it’s at this point that you can start handing off units of work to your team.

Interfacing with Business

While the team is developing, you will most likely not be. We’ll discuss this in a later post, but you are no longer a developer. Get used to it.

What you are, is an interface. The client will have a question or a concern and they will want to talk about how a feature is being implemented. Or they will want to know when the next release cycle is coming along. They will try to talk to someone on the team.

That someone is you. No one else.

What you’re doing is freeing up your team to work.

Guarding the Code

Ahh yes, code. You won’t be writing it, but you’ll sure be reading a lot of it.

The codebase needs to be maintained. And you are the black knight, guarding the bridge to “master”, or “trunk” or the feature branch… whatever your branching strategy is.

Every merge request should be treated as a conversation with both the feature being implemented and the developer who implemented it.

Did they meet the checkstyle and PMD requirements?
Did they provide the necessary code coverage?
Is there an acceptance test that proves the feature is working as designed?
Did the developer implement the pattern you discussed during design?
Are they staying within the overall style guide of your codebase?
The topic of code reviews requires its own article, so we’ll dive in more later. But suffice it to say, you will be reading a lot.

Releasing the Product

Once every previously agreed upon requirement has been completed, you’re ready to launch! There’s just the task of writing release notes, connecting with QA, alerting the DevOps or SysAdmins or whoever is in charge of moving things through the pipeline.

When these people have questions, you’re their contact. Do they need to pull a WAR file from somewhere or update their docker images to a new release tag? Does QA need a run down of all the requirements and how they can test each and every single one?

And then once the product is released, we start the cycle over again when the client finds an enhancement they just need, or a bug that should be fixed in the next release.

Conclusion:

As a Technical Lead, you will be in charge of:

• Figuring out what the problem is
• Designing the solution
• Explaining that solution
• Delegating tasks and ensuring completion
• Releasing the solution into the wild

That’s a pretty straight forward checklist that summarizes the software development lifecycle, shocking I know. But, when you take on the role of the technical lead on a project, you will be hands on from start to finish.

But don’t worry, as you won’t be doing it alone. In later posts, we’ll talk about your team and how they will be helping you along the way. Because, what is a Tech Lead, if they aren’t actually “leading” anything?