Level up your team with a secret sauce — The Tech Approach

I was on a team where my manager suggested that I move from to find a team that better fit with my goals and personality. I was switched to a new team within the week. Soon after, I had the project up and running, and even submitted an MR for a small bug fix.

I felt like I was doing somewhat well, but I wanted something that I could really sink my teeth into. Not just a few CSS changes, but some real meat & potatoes stuff dealing with Redux state, and some new React components.

I was given the opportunity, and like some *cough* all *cough* developers experience, I got stuck. I felt like I was making progress, but as the expected completion date came and went, there was a problem. I wasn’t done, and I felt like I was almost there. The senior developer on my team asked me some prodding questions about my implementation, and he gave me some hints that I didn’t have the right answer.

It was true. I thought I knew what I was doing. My senior saw a solution much simpler than the one I was writing. I really just wanted him to tell me what it was. I spun for a while and in the end it was given to him to finish up. I was embarrassed.

I was frustrated with myself, and luckily I have a good enough manager that could see this was a growing opportunity. We talked in our 1-on-1 about what I could do better, and we decided on the tech approach. I am now what you might call a tech approach evangelist.

Thank you rawpixel.com

As an aside, when learning something like this, I like to know what the thing is, why it is important to me, and then how to implement it in my own life, so I have headers done that way. I hope you like it as much as I do.

What is a tech approach?

To be clear, when I say tech approach, I may mean a different thing than when other people say it. I mean sitting with the team for any sizable story and breaking down all the steps to get the feature done. In my case, it would be talking about what components we need to create, what props they take, any contexts that need to be made, and what action creators or selectors we might need to implement.

This allows the whole team to come to a consensus on the solution. So when anyone touches the code, everyone for the most part knows how it works. This helps more junior developers learn how to think and architect better, while also making sure that they understand what needs to happen.

This is also a good time for more senior developers to clear up any misunderstandings between themselves, and coach juniors on what is going on.

How do I conduct an effective tech approach?

There are some key elements that in my (limited) experience make tech approaches useful. My “tips” are not exhaustive by any means, and I would love to hear about the ways you run tech approaches that allows your team to be successful.

1. Have everyone explain how they see the solution to the problem. Push them (especially juniors) for details so everyone sees their ideas to their conclusions, good or bad. Better to weed-out poor solutions while the cost is just a few minutes of talking. This might go as detailed as writing out some basic UML diagrams with classes, methods, properties, and arguments. If it does, Great!
2. Hear everyone out. Juniors can have great ideas that add to overall discussion. This isn’t a meeting for them to just sit in on.
3. When you feel like people are talking past each other, or are not on the same page exactly, address that ambiguity. The team should be on the same page. Not just think they are on the same page. The two are very different.
4. Engage everyone on the team. I am not sure how to explain how to do this, but it needs to happen. A team member that thinks “I’ll just agree with whatever ____ says” has the wrong attitude. The team needs to own and have pride in the project. If the tech approach ends with someone like this, they likely didn’t follow the discussion, and aren’t sure how things will work.
5. Everyone on the team needs to agree, not just “allow” something like point #4. If there are those on the team that disagree, they need to air their grievances, and it needs to be worked on. Mob or seniority rule is not an option (aka: 3 vs 2, majority rule, or follow the most senior). Sometimes people need to be heard, whether or not their concerns are valid. Teams are made up of people not machines after all.
6. Take as long as it takes. Slow is fast.

The overall goal is for everyone to be on the same page about how a feature will be implemented.

Why Tech approach?

The whole fiasco with me running behind schedule on a feature could have 100% been avoided with a well-run tech approach. The senior developer could have pointed out why my solution was inferior. We could have come to a consensus instead of me just thinking “I got this.”

This is part of engineering. Some might think that another meeting is a pain in the behind. Tough noogies. I love tech approaching. It gives myself an opportunity to bounce ideas off of people that are smarter than I am and learn from them. It allows me to help coach and grow my skills as a teacher. It is also exciting to solve a complex problem with an elegant solution even without writing code.

Like authoring a book or any typed media (apart from my medium posts), there are drafts, outlines, conversations and sketches. Anyone that thinks they can write truly great code on their first go are either mistaken, or a genius, and most of us aren’t geniuses.

After my manager and I talked, I have happily led tech approaches for features we work on in the beginning of a sprint. Our productivity has improved, our solutions are more elegant, and we can make more precise estimates on when we will finish features. They are fun, helpful, and important for growing members of your team.