DEV Community: Kaity Hallman

Learnings on tech leading: Asking questions that illuminate uncertainty

Kaity Hallman — Mon, 12 Aug 2024 17:55:29 +0000

When I first started tech leading, kicking off a project felt intimidating, especially if the requirements were vague, not well-defined, or even non-existent - which is more typical than you may think. Turning something so abstract into a distinct set of tasks didn't feel possible. I didn't know where to start. There was a lot more that I didn't know, compared to what I did know.

After some thumb-twiddling and minor anxiety (✨this is fine✨), I asked for some advice from a peer on my team who was experienced in tech leading. She suggested that if it's not clear where to start, start asking questions until it starts making sense. I couldn't believe it could be that simple - I was a little skeptical. Despite my hesitance, I decided to give it a try. The results were surprising.

As a new tech lead, you may wonder to yourself how you might know what exactly the “right” questions are. It turns out that there isn’t a secret formula or a prescribed set of questions that fit every scenario. We should begin by asking simple questions that unravel assumptions about how we think things may work. The old adage is true - "there are no stupid questions".

Identifying familiar scenarios

We can begin by trying to pinpoint various scenarios. Let's say we are adding a new feature to a familiar platform. That familiarity can guide us by framing the constraints we need to work within or the implementation details required to integrate successfully with the platform.

The scenarios we consider shouldn't be based solely on the product itself; we also have user scenarios. We should ask how a feature may behave for different user archetypes.

Additionally, we have to consider scenarios where our proposed plans may impact existing implementations. Equipped with this knowledge, we can then raise questions to determine the key points we care about in a project.

Nonetheless, we aren't always blessed with a clear path. As a tech lead, we often have to dive headfirst into the unfamiliar, which can cause discomfort. The best way to get comfortable with the uncomfortable is to ask questions until we recognize our surroundings.

Identifying the unknown?

If you are working on a completely new surface or platform, your existing familiarity can still guide you more than you might initially think. Ask similar questions as you would for a platform you are already familiar with. Let that line of questioning guide the discussion, challenging assumptions along the way. This can help steer you in the right direction or quickly identify if you are off base. You are starting somewhere and making progress, which will clarify the path forward and maybe help define the timeline you are working with.

For example, if my team was tasked with integrating with a new API on the client side, I'd ask questions such as this:

Are other teams using this service?
Is it production-ready?
If we are able to use it, how straightforward will it be to integrate in our service?
Does it require authentication?
Do we need tokens?
What is the expected response?
What is the performance and impact?

...and more!

You might think these are questions one might ask themselves as they dig into a ticket, but asking up front will help better define our work and determine early on if we have a viable path towards solutions. The earlier we illuminate the unknown, the better.

Be shameless

I used to think that asking a lot of questions came off like I wasn’t paying attention, or that I didn’t retain knowledge I had learned previously. That really isn’t the case.

What we once knew may have changed shape over time; or maybe, because of the given scenarios of our project, our assumptions won’t hold weight. We should be shameless in our question asking. We ask from the perspective of our own understanding of the problem at hand, as well as illuminating and providing clarification for others in the room.

Being shamelessly inquisitive is a crucial skillset for tech leading. Ultimately, it helps us produce more well-defined projects, leading us to be more successful in the work that we do.

Learnings on tech leading: Making estimations

Kaity Hallman — Thu, 30 May 2024 18:54:09 +0000

Throughout my early career, I struggled with making estimations for technical work. With less than two years experience under my belt, I had no idea how long most tasks would take, because everything was new to me. That feeling lingered for some time. I never knew how to answer the questions I got from my project managers: "When will this be done?" "How many days do you think it will take?" "Is this something you can finish this sprint?" shrug

A few years later, craving growth and more responsibility, I took on the role of tech lead in my team; I was the accountable person for the delivery of a specific project. One of my duties was to make estimations on technical tasks. Initially, I was pretty uncomfortable with the process and even made some mistakes. Sometimes my estimations were wrong and things did take longer than I had originally projected. Most of the time, barring any major deadlines, this was not as big of a deal as I had feared. As I tech led more, with a new found perspective, I began to identify and understand patterns that I could lean on to make me a better estimator.

The skill of making estimations can differ a great deal depending on context. Sometimes you’re estimating at a technical specification level, which is more precise and specific. Other times, we’re estimating at a high level, such as defining Objectives & Key Results (OKRs).

OKRs & "Big" Estimations

When defining OKRs, our estimations are more an effort of prioritization. We have an overall goal (such as a goal to increase site traffic by X%). We have identified several streams of work related to meeting that goal. We look at past projects, headcount, and existing or competing workstreams to understand what can fit in a given period of time (often quarterly). We prioritize these goals to understand what must be done and what can slide.

Using past experiences

As we dig deeper into our identified workstreams, we can utilize that knowledge of past projects to understand where points of complexity might come into play. Whether we have to create a new component or integrate with new or existing APIs, our past experiences help us define the level of effort or how long it may take to complete the task.

Eliminate uncertainty

We should ask ourselves: of all the tasks we need to complete, what do we think will be the hardest thing to do? Whatever that is, do it first. Many times, it’s where our uncertainty comes from. If there is anything we are unsure of, we should work to answer open questions early on. Uncertainty can cause delays and large shuffles. We should try to eliminate as much uncertainty as possible.

Parallelize!

Next, consider tasks that include external stakeholders. We should aim to parallelize it. The team can then focus on priorities within our control while our stakeholders produce required dependencies.

Writing strong user stories

During this time, we are often working on the first draft of a tech spec. After that first draft, estimations get a little easier. We know more than we did before, after scoping our work and answering questions to unknowns. This is where the skill of writing strong user stories comes into play.

We want to have working software; we want to focus on delivering in tiers. We should be breaking our work down into atomic units, lending to milestones that bring value to our users. For instance, when working on a new feature on a non-existing page, we should first deliver the page itself as a milestone (even if it is initially barebones), then introduce the component integration later on.

Minimize context switching

This is helpful both for your team when working on delivery, as well as minimizing context for involved stakeholders. When there are too many variables in play or the scope is too large, we might make mistakes or overlook what might have been obvious in a smaller frame of reference. A good example of this in practice is during QA test sessions. We usually bring in folks from other teams to manually test our work before release. If there are too many variables to consider, a bug may be missed or it may be difficult to contextualize.

Breaking down work

Taking one step deeper, we may need to break down our work further and define how many days it may take for a task to be completed. That can be a little difficult to do. Even well planned and understood work can produce unknowns or difficult to answer questions. Rather than saying a task will take [x] number of days, we can look at it through a lens of relative complexity. If you know it will take one day to complete if you were doing the work, use that as a baseline. We can then point other tasks relative to that level of effort. If it is an unfamiliar task or work that sets a brand new precedence, inflate that complexity. Increase. Add a point for the things you don’t know. If new work comes into play, don’t blow the scope; add it to the backlog.

Enjoy the process

Ultimately, it comes back to writing good user stories. We don’t want to add all of the work to one ticket. Every logical component should have its own story, even if you’re working on it solo. When we learn something new, we can change our estimations. The tech spec leads us in a project and is a valuable process, but at the end of the day, our backlog is the source of truth. The process is the reward.

In the words of Nike, just do it

Making estimations is a tough, yet valuable skill. People get better at making estimations within the context of their team and their org by doing it. Use your memory. Remember what went well or what went wrong last time, and use it as a guideline for projects in the future.

Developing T-Shapedness In Practice

Kaity Hallman — Thu, 25 Apr 2024 21:25:09 +0000

Overcoming self doubt by embracing growth discomfort and applying core engineering skills to new domains

I’m a front end developer, front end engineer, web engineer. The title doesn’t matter as much as what I do – the web is my specialty. I’ve been doing web stuff for the last 9 years, doing it professionally for 8 of those years. I’ve seen the landscape change a lot since then, as most of us who started in this era and beyond have experienced. The web has gotten increasingly complex, but I’ve held on tightly to the fast moving pace. It’s been an enjoyable ride; I absolutely love what I do.

While I always considered myself a web gal, I did dabble in the back end throughout my career. The engineering bootcamp I attended focused mainly on back end development. When I started working professionally, I worked on back end tickets here or there as needed, but rarely independently and never very in depth – almost strictly pair programming and/or XS-sized tickets. I was glad to work on back end if it was what I had to do to help my team. I wanted to learn, too. But it didn’t give the same warm fuzzies that front end development did.

Not too long ago, my team at work had a new feature we wanted to build; we made our predictions and it looked as though it was going to contribute a sizable amount towards our quarterly and yearly goals. There was a back end service in the organization we knew of that would give us the data we needed to build the feature.

There was another team in the org who wanted to use the same service in their new feature. The service could not handle the requests per second (RPS) volume. This elevated RPS ultimately ended up taking the service down (and a portion of the rest of the surrounding system too 🫠).

The service was not a big focus for the owning team at that moment in time (not to mention the owning team technically did not exist anymore). My team stepped up to “be a good neighbor”, offering to contribute to improving this back end service. A workstream formed around the need. My manager asked if I’d be interested in participating as an embed with the team. I volunteered; it was multifold. I wanted to unblock the affected teams and our project. I knew the impact it had; I wanted to enable us to move forward.

When I started this particular role, one of the first paradigms I was faced with was embracing T-shapedness — a person who has a depth of knowledge and skills in a specific domain, with flexibility to learn and take on tasks across different domains. My mindset hadn’t changed since years past – I was glad to do back end work if needed. However, I wasn’t over-the-moon-excited about it. I wanted to get better at web! I was starting to climb the precipice of what later felt like a plateau in my web skills. If I had to do back end, wouldn’t that take away from me being a strong web engineer? Deep inside, I aspired to be a specialist rather than a generalist.

In fact, my first week of the embed, I had a bit of the ick. Back end wasn’t visually interesting or easy or FUN. It initially brought on a lot of negative feelings. I felt isolated; I handed off a project I had been working on and leading for some time to another engineer on my team. I felt like I was watching them from afar, jamming away on next steps, and here I was over here trying to make a dumb integration test run on my system.

As the embed started, I bumbled through our back end onboarding documentation. I could barely complete a tiny task independently. I knew I had to set healthy expectations, but at that moment, it wasn’t in my intuition. I was hesitant to ask for help. I’m a senior engineer, I should be able to figure this out, right?

Okay sure, Java back ends do not have a visual aspect and therefore it can’t be visually interesting. Of course it wasn’t easy or fun (yet). This was brand new to me. Dabbling in back end over the years had nothing on the many years I have spent learning web and honing my craft. I didn’t just have the ick; I was feeling growth discomfort in a big way. I kept comparing my web engineer self to my budding little back end engineer self. That isn’t a fair comparison.

In other areas of my life, I’ve been trying to reframe negative thoughts. Instead of reacting to them, I wanted to take a pause, observe my thoughts, and respond to them. Just because a thought popped into my head didn’t necessarily make it real. What was I really feeling?

I was so busy focusing on how much I was tripping over syntax or language specific intricacies that I didn’t notice that my intuition was pretty on point.

For instance, one task was to migrate an API from one service to another – both services I had next to no familiarity with on top of my burgeoning Java familiarity. Reading through the code felt somewhat foreign. New syntax, new naming conventions and folder structures, new concepts… I felt troublingly slow on the uptake.

While my mind was swimming with self doubt, I came up for air. I reminded myself that I’ve refactored code in web projects so many times before. I had a north star to point towards – the “definition of done” in the ticket. And most importantly, I had my workstream mates there to support me. They were glad to answer my questions and even pair program with me. Maybe I didn’t know how to achieve what was required of a ticket immediately. But most of the time, I was on the right track.

At no point did anyone ever say, “Wow this is so bad and incredibly wrong, you call yourself an engineer?! You’re dumb!” The only negative framing was coming from my own mind. I quieted those “should-be-able-to’s”, and just asked the questions. If I had all the time in the world, I am positive I could figure it out. But it isn’t a team of me. We have the ability to lean on each other, to learn from each other. And as I asked, I felt my mind grow.

By slowing down, taking a moment to respond rather than react, I empowered myself to grow. I spent a little more time watering my garden rather than standing in the sun expecting it to grow all on its own without a little love and nurturing. I’m not just a talented web engineer; I’m a talented engineer.

With this mindset shift, I was able to complete tasks to help the workstream complete ahead of schedule. The stability improvements transformed a service chock full of outages at elevated RPS into a service that exceeded that RPS without any degradation of service 🎉. We even could have wrapped our project early. As a result, we expanded our scope and took on work from an adjacent workstream. My workstream mate told me that I was doing great work and commented on that intuition I had, just like I observed about myself.

Additionally, this experience reinforced some important lessons within myself. This embed didn’t take away from my web skills at all, as I had feared. In fact, expanding my breadth in a new domain helped me to increase the depth of my web knowledge. Embracing T-shapedness more has given me the ability to use my newfound back end abilities on another project, completing a large chunk of API work independently. Working on both the back and front end of this project has created a seamless integration and a deeper understanding of how the systems connect. Knowing the intricacies of the complete system will help us scope future work in this area. I can also pair program with my teammates, teaching and empowering them to grow their T-shapedness too. Plus, I actually like working on back end now. What I didn’t know before is that it does appeal to me, it just works out a different part of my brain. It’s exciting to have this new, shiny nugget of knowledge in my back pocket for when I need it.

This experience gave me the confidence to trust myself and my abilities in new landscapes; it gave me the tools to tear down the wall that growth discomfort tries to build up. It helped me challenge the negative thoughts that are too often my go-to, responding and reframing. That will go above and beyond just being a web engineer. That will help me as a person. That’s one of the best parts of what we do.