How to Decide When to Get in the Weeds

I’ve been having trouble even starting to write about this topic because it’s such an interesting topic and something I’ve learned quite a bit about over the years — and continue to grow and learn about as I take on new teams!

As I’ve advanced in my career, I’ve gone from feeling like I need to learn every new technology or programming language (and getting overwhelmed and feeling inferior by the impossible feat) to realizing it’s impossible to know everything well. In the spirit of ruthless prioritization, I have to prioritize what it is I choose to know deeply (where I get in the weeds) and what I choose to only know at a surface level (usually relying on or deferring to the expertise of someone else who is in the weeds).

This approach to staying on the surface works really well when you can to defer to a colleague who you respect as an expert on their work (e.g. I understand we use XYZ technology but for any additional detail, talk to my colleague Jane in Engineering). And often times, a colleague will see this for what it is: trust that you will mind your own business because they’ve got their area under control!

It gets much more difficult when you need to do this with people who might report directly into you. Stay at surface and don’t know enough about their work? You seem out of touch (and isn’t it their job to “manage up” anyway?). Get in the weeds about everything they are working on? Now you are the dreaded micro-manager.

So how do you decide when to go deeper? There are tactics I’ve employed over the years that can help.

Continue reading “How to Decide When to Get in the Weeds”

Flavors of Agile

Many years into my career in software development, I was introduced to the concept of “agility” and specifically leveraging the “scrum” methodology. We were trained up over the course of a couple of days which included silly activities to prove a point like making paper boats. I learned about 2 week sprints, sprint ceremonies (like sprint planning, daily stand-up and retrospectives), and best practices around estimation.

At the time, I was on a very lean team responsible for operating a platform that was licensed to a competitor for what I understood was a large sum of money. Our product was important to the bottom-line so consistently delivering value was the name of the game. I enjoyed the structure that sprinting offered and the constant tangible value delivery to our customer appealed to the dopamine receptors in my brain that get excited when I check something off my “to do” list.

During that time, I also learned about the “agile manifesto” and that there was a real career path for people like me who enjoyed solving human-centered problems. And since then, I’ve worked with a number of different large enterprises that employ various flavors of agile.

Continue reading “Flavors of Agile”

What Homeownership Taught me about Technical Debt

In 2018, my husband and I embarked on buying our first home. We purchased an older home (built in the 1920’s as far as we know) and it was in pretty decent shape. We knew there were some cosmetic things that could be updated (we dreamed of adding a new kitchen and finishing the attic) and that we’d tackle them over time.

What we didn’t realize was the tremendous iceberg beneath the surface: the water line to the house was lead and needed to be replaced for health reasons because at the time, we were planning to start a family; the gutters needed to be fixed because the holes led to puddles that froze over and became ice skating rinks in unfortunate places (like our front door); the home had zero insulation and would need some blown in because otherwise we’d be paying for more natural gas than we really need. I could go on and on. You get the idea.

And you might be wondering, so what does this have to do with digital products?

It is very similar to the concept of “technical debt.”
Continue reading “What Homeownership Taught me about Technical Debt”