Category: Leadership

What is Our Culture, and What Do We Want it to be?

~ inrhaf

According to Nicole Forsgren, Jez Humble, and Gene Kim’s Accelerate, a generative culture and team experimentation predict software delivery and organizational performance. Generative culture relies less on hierarchy and power and focuses more on performance and trust. What do generative culture and team experimentation have in common? They both rely on a community of highly-skilled and engaged engineers.

Previously on “Practice Advisors – What do we do here?” we examined the following questions:

  • What sort of things are our engineering teams struggling with currently? 
  • What are our current stumbling blocks? 
  • Do our engineers have enough time to learn, grow, and be the best engineers they can be?

To answer these questions, we started in the most grassroots way possible: talking to people. We sat in high-traffic areas around the office, opened ourselves up on Slack, joined engineers’ discussion forums, and probed at things during office hours.

As we talked to people, we started noticing some trends, both good and bad, and the scenarios that engineers found themselves in stopped being unique pretty quickly. Junior engineers found our mentorship system confusing and hard to get involved with, unallocated folks didn’t feel enough sense of direction, and client limitations stifled independent growth regardless of level. Additionally, without proper cross-talk, initiatives aimed at solving these problems were spun up, but often only amplified the problem, such as our multiple mentorship programs.

What about the positive trends? We recognized that engineers who consider themselves successful at WillowTree have been on projects aligned with their personal growth, or have been able to find other outlets for that growth. They have also likely found mentors along that same alignment that have encouraged their growth both within and outside of their project work.

With this context, we now had a loose mental model of some of the different types of situations that our engineers fall into, but we wanted something more formal, something we could look at to connect and guide our initiatives with our engineers. After all, our engineers are our users. Enter Product Strategy, featuring Hank Thornhill, to help us out!

“Getting Product Strategy to help us is like a senior hopping in to fix a beginner’s issue, they might’ve spent 2 hours spinning their wheels, but the senior’s experience can help get to the solution in 5 minutes. We just have to realize we’re the beginners now.”

-Andrew Carter

With Hank’s help, we were able to devise two axes that we felt illustrated both where we are now as an engineering organization, and where we want to be. One axis is engagement, spanning from Passive to Active. The other is knowledge, ranging from Learning (someone that’s just starting to learn) and continuing up to Expert (someone with a high level of expertise). Combining these axes results in the two-by-two square you see below.

From this chart, we developed some personas to help illustrate what concrete points along these axes may look like. We recognize that these personas don’t represent every individual at WillowTree, but feel that they adequately fill that role of illustration. Some of the traits of these “individuals” are prescribed by the client, and fall on the broader organization to help shift, such as working on a hyper-embedded team. Others are more easily pushed simply by providing more obvious opportunities, such as mentorship.

Chart displaying different axes of engagement

We want to move people towards Active-Expert, represented by the upper-right quadrant of the chart. To do that, we need to engage people and improve their skills. Fortunately, these things feed into each other. Someone that is more engaged and excited, will be more easily upskilled if given the opportunity. This also creates a positive feedback loop wherein active experts are better positioned to serve as mentors, further bringing people up into that quadrant. Organizing our thoughts here has also helped us identify initiatives that can help support these conversions. For example, more opportunities for group learning can move junior engineers toward Expert as they participate, as well as senior folks towards Active engagement as they mentor.

We want to build engineers’ excitement around their craft

With this framework for our thoughts, we now feel prepared to approach the engineering groups more formally than just ad-hoc conversations. This will also allow us to remove some biases in our data that we’ve introduced by relying on people that already felt comfortable talking to us. We’re going to run a series of “retros” across all of our offices during our regularly scheduled GROW time. There we can capture what people’s goals are, what’s supporting them, what’s holding them back, and what they’re concerned about for the future. Tune in next time for the exciting results!

The Culture of an Agency: A New Role

~ inrhaf

WillowTree is an organization that has absolutely exploded with growth over the last 7 years, since I started here as an intern in 2016. At the time, we were at about 150 people in the entire company, and now we’re eclipsing 1,300. With this growth has obviously come change. Information is harder to disseminate, and it’s harder to be on the same page with your fellow engineers when you’re much more spread out. This sort of spread means we end up solving the same problem multiple times, and sometimes incorrectly. My colleague, Andrew Carter, said it best, “building an app is your game to lose.” We have all the tools and knowledge at our disposal with the great minds here within WT, so how do we make sure we’re making the most of them?

Building an app is your game to lose.

You hear it all the time in the industry; a company got big and lost its culture. But why? Is it that culture intrinsically cannot scale? Is it that hiring needs to become less specialized to fill a larger number of seats? I think the answer depends on the organization.

WillowTree’s engineering culture has always heavily emphasized the importance of growing our own engineers’ abilities. A focus on mentorship, combined with truly great people make this formula work very well, and you can see it in WillowTree’s success. Pre-2020, this culture was heavily dependent on colocation. When the Covid-19 pandemic pushed all of us to work from home, that was a big shift, and our special sauce needed to be adjusted a little.

We saw a lot of changes happening with this shift to working from home. A lot of the crosstalk that would naturally happen across project teams simply stopped because we were no longer sitting together. Folks that were hired after this point (see: the majority of the company) were coming in with no opportunity to share a physical space with coworkers. It became much easier to lose your identity as a WillowTree employee, and be pulled solely into your project work. In the short term this may seem great, no pesky distractions from delivering quality products on time, but in the long term this has negative implications for things like mentorship, individual growth, and in turn, project outcomes. These implications are then compounded further when you consider the massive growth we’d taken on in that time. With that growth, it become more important to maintain our ability to raise people up internally and make them the best versions of themselves.

This is where Andrew Carter and myself come in. Some very smart people before us identified that there was a need for a more centralized role; one that wouldn’t be billed to a client. A role that would exist as a conduit for folks to more easily share information across project teams, and in turn, across the org. That role has been dubbed “Practice Advisor,” with Andrew and myself being the first two to take it on, specializing in iOS and Android, respectively.

“So what the heck does a Practice Advisor do exactly?” Great question; we’ve spent the last few weeks working on that, and to be honest, we’re still figuring it out 😬. But really, our first steps are focused primarily on setting a baseline for ourselves and for the organization. What sort of things are our engineering teams struggling with currently? What are our current stumbling blocks? Are there mistakes we see getting made repeatedly across the org, or are we learning from our own teams? Do engineers have enough time to learn, grow, and be the best engineers they can be?

By maintaining our technical expertise, we can stay close to the engineers doing the work, but serve as liaisons to impact broader org changes.

We’ve been spending a lot of time tracking and advocating for people’s involvement in some existing WillowTree shenanigans. For example, we’ve been looking at GROW, which is a space for folks to come present something they think is cool, something their team had a tough time with, or just something they’d like people to know. This has been flourishing recently with an influx of folks coming from Andrew and I’s consistent berating informing. Our backlog of content now extends two months out, and attendance has never been higher with our most recent GROW having over 40% of each practice in attendance. Besides GROW, we’ve also started holding Office Hours. These are meant to be a space for anyone to come and either ask questions about mobile, or have larger group discussions around potentially-controversial topics in the space (viewmodels with SwiftUI anyone?).

Looking ahead we’re going to be meeting more closely with various levels of the organization to further spread awareness of the role while also garnering more information about people’s needs or wants from the role. Andrew and I are still in client services, it’s just that now the client is WillowTree itself! We’ll be posting additional journal entries like this as we continue to flesh out and evolve this role, so check back to stay informed about this role and the other engineering happenings here at WillowTree!

What even is Staff Engineering? A Series

~ inrhaf
What even is Staff Engineer?

“What does a ‘Staff Engineer’ even do?” My coworker asked, his inflection implying something I wasn’t too enthusiastic about.

I shifted uncomfortably in my seat. Not because he was being a jerk or anything — the question was asked in jest — but because he’d been working very closely with a Staff Engineer for years at this point. For the most recent several months, that Staff Engineer had been me. If he didn’t know what I did, how was I supposed to answer this? And that was the weirdest part about this: I actually didn’t know how to answer this.

30 seconds before that conversation started, I would have told you that I was super confident in my abilities, my talents, and my position here at WillowTree. Now, I was questioning everything I’d ever known about my career. Nay, questioning everything I’d ever known about life. I had to take a long walk in the mountains (I like the mountains) and consult several oracles (confused strangers) in an attempt to find myself (ironically, I got lost on a hiking trail).*

One of the biggest reasons the title of “Staff Engineer” is so hard to wrap up in one quick explanation is because it entails such a wide scope. Over the course of my time as a Staff Engineer, I’ve had responsibilities that fall into all of the following categories at one time or another:

  • Bugs on prod that need to be dug into
  • Product-wide refactors
  • Technical feasibility questions
  • Building/editing pipelines
  • Implementing brand new patterns or frameworks into a project
  • Helping maintain a project’s full test suite
  • Helping other devs with really off-the-wall issues
  • Fixing process issues or tweaking the process to get around things you can’t fix
  • Oh and let’s not forget about that one time a client reached out and was like “Oh hey, all of our certs expire Sunday evening can you, like, fix this?” (I probably don’t need to tell you this, but this obviously occurred on a Friday at 2:30 because when else would it have happened.)

And the list doesn’t end there. I’d argue that it’s an endless list. The main point here is that the responsibilities that land on a Staff Engineer are less a list of responsibilities and more a general comfort and skill-level with the SDLC process and with software engineering as a whole. As a Staff Engineer, you’re your team’s (or teams’, depending on your given role) go-to individual for solving the tech questions you run into as you build out your product.

Questions a Staff Engineer is expected to answer will vary wildly from week to week, not to mention from project to project. They might be problems with your project’s software. Maybe your team just discovered a technical limitation they didn’t know existed and they need you to lead the conversation in figuring out a solution, or maybe a severe production issue just reared its head and needs to be fixed yesterday. Or, they might be software problems that would crop up if you didn’t foresee them. I spent a large portion of my time on the last project working on a number of large refactors that made the codebase easier to work in for our devs. If I hadn’t done those refactors, the project would have undoubtedly gotten too complex for any human (with our squishy, human brains) to maintain. My current project is one my team and I had to build from scratch. A large part of my role in setting things up was ensuring that good practices and patterns were built into the codebase from day one. Solving problems before they become problems is always going to be far easier and cheaper than the alternative.

Sometimes, the tech questions you’ll have to answer are literal questions from the client. “What if we built the thing we told you we definitely would never need?” “What if we scrapped all of the work you just spent 3 months on and did something else instead?” “What if it’s crucial that we have some piece of functionality that you’re only just hearing about 6 months into development that isn’t going to be a quick addition?” In a perfect world, our products would be fully and perfectly defined on day 1 and would never have any of these tech questions crop up. But, as anyone who’s ever worked in tech (or, honestly, anyone who’s just tried to get their computer to do something it didn’t particularly want to do) can tell you, we don’t live in that perfect world. Constraints change (sometimes for the better, usually not). Key libraries you were hoping to lean on get deprecated. Software engineers are imperfect humans and write code with bugs. Your role, as the Staff Engineer on a project, is to make these obstacles as insignificant as possible for your team. And if the scope of potential problems is limitless, it stands to reason that your list of responsibilities and the tech you work in will also be limitless.

That might sound intimidating, but worry not! You don’t need to be the kind of “10x” engineer who needs to do everything yourself (protip: don’t be. Not only will you be much cooler to work with, you’ll also be under a lot less stress.). The good news is you aren’t the only person on your team! You’re going to be surrounded by incredibly talented engineers, each of whom has their own specific area of interest and expertise. One of the most important parts of your job is to know what you can and what you can’t delegate. Because of the nature of the position, Staff Engineers tend to bounce from one thing to another in an endless game of Staff-Engineer-Pong. Often, multiple problems will pop up at once, and it’s your job in these instances to delegate work that can be delegated. If two high-severity problems are dumped on you at once, and your team mate is an expert in the field of Problem 1, you can ask for them to take it on while you tackle Problem 2. I spent a large portion of my time in my first Staff Engineer role figuring out where I was the single point of failure and making sure other people got trained in those responsibilities. This meant that I could delegate things that popped up if the need arose. Spoiler alert: the need arose. Many times.

So as a TLDR…well, there really isn’t one, which is why I need a few whole blog posts to walk you through what it looks like to be a Staff Engineer. If you’re doing your job well, you’ll find that things like prod issues or other unexpected problems should be less common. In between those emergency issues, there will likely be things you focus on more than others. I’m hoping to get into some of those in my follow-up posts, so keep an eye out for that beautiful name (mine) that induces calm and happiness: Chris Sellek. Thanks for reading! See y’all in a bit.

* Absolutely none of this happened.

—

If this topic interests you and you want to take a deep dive into it, I want to take a moment to highly recommend the book The Staff Engineer’s Path by Tanya Reilly. Tanya does an excellent job discussing this topic in depth in her book, so go grab a copy!

Today’s blog post is the first in a series written on what the Staff Engineer role entails.