Tag: developing expertise

  • Making decisions as tech lead

    Making decisions as tech lead

    When I first started as a tech lead, I often made my decisions based on what the tech lead before me had done.

    It wasn’t a terrible idea. Mike was knowledgeable and competent, a good person to emulate. And I was facing many decisions that were outside of my area of expertise.

    Doing what another successful person did is a convenient shortcut, and it works… to a point.

    A person holding their glasses stands facing a window with several blank sticky notes
    This is another excellent way to make decisions. Line up a bunch of blank sticky notes in rows, and then stare out the window. Photo by Julia Potter on Unsplash

    A decision to make

    It was around the time I became a tech lead that “serverless” architecture became trendy. I needed to decide whether or not we should jump on that trend. (If you have no idea what serverless refers to, no worries. It’s not essential to the story.)

    Whenever I would explain how we were building our application to someone else in IT—something I had to do frequently, because I needed to make some security decisions based on our architecture—people would ask me:

    “Why isn’t this serverless?”

    Neither “because I have no clue what that is” nor “leave me alone, I am just doing the one thing I know to do” was a great answer.

    So I talked it over with my manager, Tony.

    Some managers might have already been on the serverless hype train, ready to insist that we switch to the latest thing. Tony was skeptical. He wasn’t sure we needed to go the serverless route.

    Researching it anyway

    I suggest that we do some research and make an informed decision. If nothing else, I wanted a better answer for my colleagues who kept insisting it was the best choice for us.

    Tony could have pulled rank in that moment. He could have said, “No, what we’re doing is fine. Let’s not waste time researching this.”

    And I’d have accepted that answer. If serverless later turned out to be a better option for us, we could switch.

    Instead, he agreed to let me take some time to research.

    A person holding a mobile device writes in a notebook on a table with other papers, pens, and a tablet, suggesting someone doing research.
    Getty Images via Unsplash

    I did a lot of reading over the next week or so. But most of all, I talked to the fanatics, those colleagues who were already convinced that I should be using it.

    As an aside, it’s fun to turn the tables on people who have already decided that their favorite technology-of-the-moment is perfect for you, even though they have no idea what you’re working on.

    “You should do this!”

    “Oh yeah? Convince me. Why is it right for my use case?”

    They’ll tell you why it’s great in general.

    Okay, but here’s my specific situation. Will it still work for me?

    It depends

    There’s a running joke in IT: that the architect’s answer for everything is “well, it depends…

    Except it’s not just a joke. There are trade-offs for everything. Be suspicious of anyone who claims their proposed solution is the correct answer for every use case.

    Someone holds a blank orange sticky note near three others that are stuck to a window
    Yes… this one. Getty Images via Unsplash

    And the architectural decisions the previous tech lead made for our earlier project weren’t always right for our current project, either.

    That said, the serverless solution, while offering some advantages, had deal-breaking constraints that made it not great for our situation. Tony’s intuition was on target. And now I could reply to my colleagues’ serverless sales pitches from a place of knowledge.

    Trust

    But my biggest takeaway was that my manager trusted me to do the research and make the decision, and that I was entirely capable of it. I didn’t need to copy what other people had done and hope for the best.

    And, with practice, I got better at researching. I began developing my own intuition and expertise as a tech lead and architect, drawing on my knowledge and experience. Now, if there’s a decision to be made, I’m ready to gather the information I need and consider the trade-offs.

    Because, well… it depends.


    Thanks to Oren Yam whose blog post Managers, Don’t Bet on Your People’s Ideas! reminded me of the above story.