Disclosure : This is not a "process". These are practical values for a technical team leader. I.E. A mental framework for finding zen amidst a wasteland of variations/implementations of agile let alone entirely different feature driven workflows.
Zen you say? Not possible...
You are constantly bombarded by bugs, hot-fixes, processes, managers, teammates, product owners, and people with two or three letter titles... If you get bogged down in details, then ZEN is simply not possible and then your best option is to lay low.
I say, just let the talking people talk and you can simply deal with the important stuff.
Just Say Nay and join me in riding the cool waves of product delivery, a master of the ocean.
You: "Uh oh... wait, are you going to give me some stupid cliche list of ideals?"
Me: "Uhh yeah... duh"
Yep, I'm really going to use an ABC model (well, three c's and a d) to relay these values... Why?? Because while cliche's and mnemonic devices are... well... cliche, they work.
Meanwhile, sales is like "ALWAYS BE CLOSING"...
You might say, "Well, that's sales and tech is different we have to bleep blorp the sleep slorp" and more robot noises... Let's be real, our goals and technique are different but mindset and leadership are contextually the same.
"Always Be" mindset
While closing sales deals is not a tech lead's goal, there's certain simplicity to the "always be" mindset which can be applied to any particular goal. In our situation we're looking at what can we constantly be focused on in all aspects of our job to have confidence in everything we do. Not because you know everything about your programming language of choice but because you are an excellent tech lead.
So, always be... tech leading??
Here's where we diverge from the Glengarry Glen Ross meme of "always be closing". On the technical side we don't "close deals", so what's our goal? This could be a topic unto itself. To keep this short, we want to... wait for it,
Deliver quality software products at high velocity while providing continuous improvement ™
So, what mechanisms as tech lead do we have to be sure we're confident this is happening on our on our team? Well, you can attempt to measure this quantitatively with your agile software du jour but you're wasting your time, real delivery teams run fast when lead by people who care about...
Tech Lead "Zen"
Our goal is to be in harmony with the product demands and our teams.
Assigning
"If we assign tasks or stories to people, isn't that against agile?"
Really???
A wise man one said:
If something is assigned to no one it might as well not exist.
- a really wise person
Ok, no one said that... but it's something you should be constantly thinking about. What good is a task if no ones working on it? If everyone or no one is assigned to a task how can you ensure it's progressing through your workflow. Here are some examples that apply to tasks, bugs, stories, etc...
- Assign a product owner or UX if you need more requirements
- Assign yourself to refine technical details
- Assign a teammate developer to review or prepare to work it (even if you're going to code it)
- Reassign!
Reassigning is the most important. If you're always assigning in every meeting, standup, refinement, kickoff, tickets will change hands a lot and this is good. Encourage your teammates to not be attached to tickets and not consider assignment a fate or reassignment a failure.
Don't be shy. Don't wait for volunteers. You will be shocked at how your teammates crave this as much as you.
Backlog
Always be refining your backlog into "vertical" functional slices.
If your team's tickets read like "Create new API X for Y App" or "Store X data in Y data warehouse," you should be worried.
Vertical Slices vs Horizontal Slices
Question: "Why?? Teams need to build components first to be sure we can have functional deliverables."
Response: "Teams are designed to deliver software features not build components."
Without a use case, your components mean nothing. Resistance is inevitable, design your team to deliver features.
Don't get me wrong, there are good reasons for your team to have stories and tasks that have no functional delivery. HOWEVER, if all your stories are technical tasks, this is a sign of dysfunction in your team. After all, you are an excellent tech lead and you'll settle for nothing less than excellence.
What does this mean? unfortunately you will spend less time coding and more time planning. Embrace it or your life will be stressful as a tech lead (a.k.a. sans zen).
Closing
"Wait, you said we weren't closing??"
Not closing sales deals, but we are tech leads and still close. Reminder, we are "delivering high quality software super fast or whatever I said earlier" and for most software teams this means closing tickets.
Everyone on a team is working to a common goal. While you have project managers and scrum masters who "should" be moving things along, the reality is that you lead by action and your team will reflect the actions you display.
Communication
Is your idea of a technical lead someone who's a genius but doesn't have to talk to anyone? Please... don't be like this guy...
Software engineers and developers sometimes have a reputation of working in caves and being difficult to deal with. This can be the case but if you're an excellent tech lead, you can and do interface with all levels of the business.
- Be available and approachable for all members of your team
- Be present at any meeting you can
- Be involved functional and user experience decisions
- Stay knowledgeable about usages of your features (issues and performance)
Coding (Reviewing)
I like to think technical leads are a lot like head chefs. If you've ever watched "Hell's Kitchen" you'll notice Gordon Ramsay's hawk-like ability to spot issues in quality without even tasting a dish.
Food and code are very different of course, but similarly leads are expected to have keen eye to spot code quality issues. Leads expecting to just sit at their desks and work on "their" code why other devs work on "theirs" are kidding themselves and setting up for a very clunky code review or are blindly pushing merge buttons. Likewise developers on the team who are expecting to issue merge requests and have zero comments or follow up tasks are heading for stressful times.
Code review is a collaborative process. always be asking questions, early and often.
- Why we're making these changes?
- How does this work?
- Is there significant risk?
- How do your test cover the use cases?
Encourage developers to not be offended or afraid. Trust but verify and my final piece of advice.
Sorry, your favorite IDE is no longer a code editor (vscode, eclipse, intellij) it's your code review merge request tool.
- Me"
Decomposing
Don't falter out of the gate, be ready to to execute.
If you're remodeling a house and someone says "I need a new kitchen, now build it". You will spend several days still trying to get everything lined up just so workers can start hanging cabinets.
- Backlog Refinement - break down epics to executable functionality
- Decomposition - break down functionality into tasks.
Ironically, this seems to come naturally to developers. Intuitively breaking down into components seems to be the first thing to come to mind.
Example: Add new like button to content page
- New web and mobile interaction
- Api to support get and set likes
- Supporting models and persistence layer
Generally, pretty typical right? In my experience some leads can believe that this might be their only job besides writing code, please don't fall into that trap.
Back to "Zen"
"Hmm, this sounds really stressful to me..."
If this still sounds really not for you, then it's perfectly fine to be coding components and tests. There are also plenty of opportunities that don't involve leadership.
Remember, this is about focusing on the import things and ignoring the details.
Assigning, Backlog, Closing/Communication/Code Review, Decomposing
Generally software delivery is cyclical with many variations in processes with noisy bumps along the road. Process changes come and go, a technical lead can isolate these from their primary goals to see the forest through the trees.
If you're a lead in a product driven company, it's safe to assume your organization that operates with org charts, process and decision makers, etc. You should never use this as an excuse for compromising on values. First, consider influencing people to treat each other as peers who share your values. Then, if this feels like a wasted effort, find another company where your values blend with your colleagues.
Your business team may not always understand this but in the long run you will be proven an "excellent tech lead".
Top comments (0)