What is it that you do again?

What is it that you do again?

I get this a lot. I mean, a lot. My partner doesn’t even know what I do for a living. She just says I work with computers. She’s technically correct, the best kind of correct. But, there’s a bit more to what it is a tech lead does.

Originally posted on TeachingTechLeads.com

It’s not glossy, it’s not sexy, it’s not something that is going to cause the person across the bar from you to go, “wow, tell me more.” But, I like what I do. I interact with a core group of people on a base level to help them achieve more. I get to play with new and interesting technology, but only after wading through incredibly thought provoking design and requirements sessions.

This post was inspired by the fact that every time someone says they are a tech lead, they probably mean something different. And one guy in particular asked me to detail exactly what it was that I did. So, Gergely, this is for you.

How I started

We were working on a project for a retailer known for “just doing it”. The team had grown in size and scope to the point where our current tech lead was becoming stressed to keep up with everything. He was wearing multiple hats, as we tend to do, and we commiserated over a few beers at our company event. That’s where he and the PM asked me to take on a junior tech lead role.

“Sure, why not.”

That project progressed with me taking over code reviews and acting as a bridge between our Spanish TL and our US based developers. I would get up early to chat with him for a few hours before the US team would get online, he’d tag out and I’d explain designs and new requirements that were coming up in the next sprint.

How I progressed

The second phase of that project, I took on a more full fledged tech lead role. It’s probably easier to just bullet list out my responsibilities than try to provide flowery prose:

• Design sessions with the Tech Lead, Systems Architect, and Business Analyst Sprint Planning with Project Manager, BA, SA, and TL
• Interfacing with external project lead(we paired with a front end team and they’d send a guy to our office for a few days once a month)
• Code Review
• Release Documentation
• Training BA to prepare them for sprint showcases
• Backlog grooming sessions
• Pair programming with on site developers
• I coded, every once in a while, usually after hours which turned out to be an awful idea

What you can’t tell from this list is the stress load. That list is only what I can remember, what I haven’t blacked out from that time. This was a year or so after my partner and I had bought our first house and was before our son was born, so… I had some free time.

My office hours were from 7-3, then back online from 8-12 or so at night. I did this through two projects, as we kept on resources from somewhere on the other side of the pond, and I liked being available for all members of my team.

Needless to say, I burned out after about 8 months of this.

How I am now

In my current environment, things are a bit different. Not by much, but there are some stark differences. The team doesn’t subscribe to a scrum methodology, so there are far less ritualistic meetings. That alone frees up at least 3 hours of my day every day.

Yes, I still take meetings, but they all serve a purpose. As tech lead, I meet with our internal clients and stakeholders to review requirements and present them with proposed solutions.

I still spend about half of my time as a second-degree coder, meaning, I am either working on a high level solution with the developer or reading through the code that they have completed.

I don’t have a backlog, instead there is a list of enhancement requests, but that’s up to the clients to decide what they want in the next release and how they want to prioritize that against what my team is currently working on.

I don’t have a retro every two weeks or a 6 hour sprint planning session every two weeks. Requirements are rolled out as they become agreed upon to the developers. And once they’re done with those agreed upon requirements, we deliver that release. The users know exactly what they’re getting, because they asked for it.

We only deliver what they ask for, nothing else. That seems simple, but you have no idea how easy it is to dismiss a change request or a “bug” when you can point directly at the requirement that was signed off on and say, “no, this is working exactly as you asked for it.”

How I see this going

I don’t think much else will change in the foreseeable future. I’ve been with my new company for just over a year now and I run a team of 2-4 developers. Whereas I used to have 6-8 developers and a whole lot of headaches.

I am the lead for one particular suite of applications. There are two streams of work going on for that application, and I shift contexts back and forth between them. I try to keep the devs from having to flip back and forth, because that’s my job.

Do I code? A little. I actually just completed a rule today that took all of 2 hours. It was a two line change, but I had to write up a failing acceptance test and then go check in on another developer in the meantime. I should have seen that coming.

Things come up, they always do. I had a C-level request for an ad-hoc report come in on Wednesday last week that completely botched a release because it stole a resource from his current task. But, that’s what we do.

We direct our resources in a way that gets the client the solution they require in the most efficient manner possible.

To everyone here

Are there any questions about the role of a tech lead that you want to know about? I'm constantly looking for things to write about, here and directly on my blog, so any questions or suggestions help me out a lot.

Thanks all!