teams on Brian Online

The Individual Contributor to Engineering Manager Switch

Tue, 20 Apr 2021 09:28:46 -0400

I was in a session for people that might be curious about trying management out to talk with existing managers to hear why they made the switch, what kind of problems exist, and why they keep doing it. This got me thinking about some of the common issues that come up, especially when making the individual contributor (IC) to engineering manager (EM) switch, that are worth talking about. Most notably, I’d like to talk a bit about rewiring your reward center as an engineering manager since you probably are not doing the same things that used to give you satisfaction.

Rewiring Your Reward Center

One of the things that came up, and a relatively common occurrence from folks transitioning from IC to EM, is the need to rewrite the satisfaction centers of your brain a bit to continue to feel successful. If you’re an engineer, debugging a code issue, pushing a feature, and all the many other small dopamine hits are easy to get just about every day. Switching to management means you are choosing to forgo those things most days favoring observing your team and surroundings at a different level to take a different kind of action. However, this doesn’t mean you should give up on similar product-oriented thinking and bug fixing, you might just need to shift your perspective.

Management can feel quite lonely sometimes as you are less likely to get more direct feedback in many cases. Furthermore, the needs of the role are different per team, so it can be quite challenging to give another manager feedback since you don’t know the intricacies of their team dynamics. Looking to establish a peer group is still going to be valuable as a manager, however understand that it might be less solution oriented than seeking engineering advice from an engineering peer.

The kind of things that I now see as small rewards that I used to mark growth are things like seeing engineers speak up in meetings and gaining comfort addressing senior leadership without breaking a sweat, managers telling me their team is more often than not running itself, and they are trying to figure out how to use their time wisely, and peers outside my team asking me about one of my team’s processes. These are small, and certainly more nascent than shipping a feature to production, but it’s where I’ve personally learned to read this as some small successes.

The other useful tool I’ve offered is to give new managers the framing that their organization is the product they are building, and can (and should) approach it as such.

Organization as Product

Embracing the thinking that, as a manager, you’re still building a product, but that product is actually an organization of humans, was incredibly helpful to me. It let me think about what makes a best-in-class organization and what I needed to do to get my organization to that point. The core ideas I usually lean on are as follows:

Iteration
Transparency
Letting Go

Iteration

Just like any product that you ship to customers, you need the ability to iterate on your organization as the growth might not be linear and the needs might not be linear. Building a focus around iterating will let you experiment with ideas for the team, as well as build an honest feedback loop with those that you’re responsible for of what is and isn’t working.

Using the same experimentation approach you would for a product feature can still apply here. Build a hypothesis, present the experiment with a time box to ensure there is a time when you will re-evaluate this decision, get some buy in, run the experiment! Keeping strong alignment with the time box that was set forth will let you also build trust and demonstrate accountability to the team. A team is not a static thing, so your process likely shouldn’t be static either.

If you don’t know where to start with iterating on your process, that’s a great place to start! Perhaps the team is missing a ritual like a regular retrospective to reflect on what they’d like to stop or start doing? If the team keeps meeting deadlines, perhaps it’s worth a specific retro to find out how we might better estimate. As you iterate, you may need to introduce or remove team rituals which will be little checkpoints in your process which will provide as much value as you and the team put into them.

Transparency

Being open and honest about why decisions are made, why processes have failed in the past, or even just what the team is currently working on are all versions of transparency that are valuable to different sets of stakeholders. Just like an application that has no telemetry, a team that is perceived as a blackbox is likely going to make things a bit more challenging both inside, and outside, the team.

Onboarding new folks to an opaque team is challenging as it might not be readily understandable how the team operates since there are no holes cut into the team’s operating process. This phrase was made famous by Andy Grove’s excellent book, High Output Management, but the sections around the black box are well summarized by Michael Dearing here. Being able to let people inside the team and outside the team peer into the process, and be aware that the team has a desire to be transparent will be valuable to create an open dynamic.

Letting Go

Building an iterative process by which you can address needs on the team is critically important, but so it gives the team the time and space to actually figure out what things are broken. There will never be a shortage of things that feel like you should fix them immediately, so you will have to learn to build a sense on what is actually urgent and important to fix/unbreak immediately. For this, I use an Eisenhower matrix to visually bucket things into different quadrants to see where I could/should delegate some things as stretch opportunities for others on the team, or where I actually shouldn’t do a certain thing.

The tool is less important than building a muscle around whether now is the right time to step in and start working on something, or if this is an errant data point for the time being. It’s a hard skill to build, but it comes with time, and it comes with being able to feel comfortable to let go a little bit. Being able to do this will also be a key way you scale yourself as you continue down the manager’s path in the future.

—

Rewriting your reward center is not the only thing that made the switch easier, but it certainly was the largest thing that helped me along my journey. Over time, you accumulate more tips, tricks, and tools to figure out what the shape of engineering management on your team actually is. Hopefully, this helps.

Change at Scale

Fri, 17 Jul 2020 09:28:39 -0400

Change at scale, and by scale I mean a product or an organization that is scaled out, isn’t always purely about good and right ideas, but also about timing and the angle of approach. As organizations scale, appetite for risk (read: change) naturally drops. One of the main reasons for this that I’ve seen is that the folks who have helped stabilize or scale the product or organization in question typically ascend to more lauded positions within the organizational mythos (usually through actual or perceived heroics during the ‘wartime’ stabilization efforts, problematic, but not for this post) and can easily recall how bad things were in the before time to cast a serious enough doubt if the idea being proposed is worth doing right now.

This idea isn’t new, Michael Lopp wrote about this kind of shift in personality in the book Managing Humans where Lopp refers to this split of personalities as “Stables” versus “Volatiles”. People can migrate from the volatile category, someone always agitating for change and movement, into the stables category usually through a large company-changing effort. I’ve never personally witnessed the transition in the other direction (stable to volatile), but that’s not to say it’s impossible. Once you’ve become a stable it seems hard to have the perspective of a volatile as you’ve been through a mountain of work to make this organization, product, etc. better than it used to be.

So how do we approach change in these situations? I think the 3 main things that help planting a seed that will successfully grow in these folks minds are Archeology, Documentation, and Marketing.

Archeology

One of the best skills I learned at Twitter was to become an archeologist regarding company history. Twitter had been around long enough that it had developed a decent culture of writing things down and putting them in a wiki or in some searchable format. I quickly learned that if there was a common idea about what feature should be built on Twitter the chances that it was pitched, designed, and then shelved is pretty high. Digging through these old design decks and product briefs is illuminating as they are all well prepared and it’s clear that the timing is just not right.

Many years later (when I was working there) you started to see the re-emergence of some of these ideas indicating that the time had come to bring some of these ideas back to light. While this happened mostly serendipitously I still found this fascinating to watch good ideas come back from the great wiki graveyard.

Being a good company archeologist lets you understand how this idea may have been framed in the past which can inform how you frame it today, and demonstrates a significant amount of due diligence in understanding prior art and previous sentiments. Additionally, whomever had put together these previous presentations, docs, and designs has tons a huge amount of work for you already that you should voraciously consume (and thank them if they are still at the company)!

Any company that’s been around for a few years is likely ripe for some archeology. Building your search skills, personal network in the company, and general company history will aid you in being a better archeologist.

Documentation

Like any good project you should be documenting what you’re trying to change with clear guidelines of how you think the process of this change should be laid out. These documents are the place to reference anything you found in your archeological dig. The added benefit of these documents you are creating lets future archeologists (yourself included) easily jump back in & immerse themselves in this proposal.

Articulating why now is the right time to do whatever it is you are proposing is the key piece you want to make sure is clear here. If you’re including the prior reading from what you’ve found through your digs it will be nice to contrast why it was not the right time back then and what has changed to allow this to be the right time.

Marketing

Good ideas just don’t take hold of a critical mass of people at any organization after a certain size. This is not a malicious thing, but if your company has done their job well in hiring, you should have people that hold differences of opinions on things which is good! You should seek out these differences and understand them well.

While it can feel annoying to go talk to actual humans that share different opinions on what you are proposing, seeking divergent perspectives from what you believe will be incredibly useful. These perspectives will give you a whole new lens to view your current proposal from which honestly may make you shelve things yourself (and may provide understanding as to why this idea was shelved originally). Demonstrating a desire to seek more information, and demonstrate some humility about what you do and do not know, goes a long way in my experience at the marketing of any idea.

—

While these steps are not foolproof in any stretch of the imagination, I’ve seen too many ideas for changes die on the vine due to hubris or believing that ‘good’ organizations should be a meritocracy where empirically good ideas are always championed at all costs. This just isn’t the case, and it’s not for people desiring to do the wrong thing.

Any organization of humans is a living, breathing, changing thing that requires attention, care, and understanding. Trying to bring people along with you on your idea shows that you care and are willing to be wrong (it’s okay to be wrong).

Take care in making change.

Hospitality & Software Engineering

Tue, 21 Jan 2020 00:00:00 +0000

Managing software teams, and being an engineer myself for just about a decade, has eventually lead me to form my own perspective (likely not a unique one) on how I approach software engineering and really what I’d hope that others would think about when they write software.

At the core of any piece of software engineering is a problem to be solved. Behind every problem to be solved are humans that we are solving it for. So many times when writing software we remember the former, but not the latter. It appears that software engineering is falling far behind other industries that already know this, and put a deep focus on it as they realize the deep connection to serving the human and repeat business.

Many of these ideas of serving the human while solving these problems has been an area of focus for many people for decades under the umbrella of hospitality, or hospitality management. If you’ve ever been to a hotel, a restaurant, or any where that has customer service you’ll have experienced hospitality front and center.

I’d like to break down some of these principles of hospitality and align them for software engineering teams since I believe that we are here to serve the humans that use our software no different from the staff at a restaurant.

Principles of Hospitality

While there are many principles behind the concept of hospitality I’d like to focus on four that I think are deeply important and inform many of the other concepts within the realm of hospitality. We’ll discuss the ideas of respect, vulnerability, personalization, and anticipation as they relate to engineering teams and the products they produce.

Respect

It should go without saying that respect should underpin everything that we’re talking about, however, often times it does not. Remember that people are choosing your software, your team, etc. While it might not be an easy choice for them to make (and maybe they don’t even like the choice) they are here and should be treated with respect if you ever want them to respect you back.

It is 100% true that with regard to respect that you get what you give. If you are dismissive to the needs of your customers they will be dismissive back. We’ve learned much about what respect means in the physical world for face to face interactions, but still have a ways to go when it comes to digital respect.

Vulnerability

Establishing a respectful connection to the humans that you are serving will open up the opportunity to be vulnerable with them. This means that accepting feedback about the experience should be the expectation of this relationship as well as being able to express what you are, and more importantly are not, offering as part of this experience.

Being vulnerable doesn’t mean that you are there to be a door mat for excessive complaints and abusive behavior. You can’t please everyone, and that is the unfortunate reality with any service based product. Recognizing when the time to be vulnerable to feedback and critique has vanished because the respect has evaporated is just as important as being vulnerable in the first place.

Personalization

While personalization can often seem like an after thought (especially in the world of software engineering) it’s something that allows people to feel like they own part of the shared space that you and your team are creating. Remembering someone’s name that comes in all the time establishes them as a ‘regular’ and demonstrates a level of care at an incredibly basic level which gives comfort and safety.

This is not to say that you should memorize everything about your customers and tailor every single aspect of their experience. People are smart when it comes to detecting themselves being pandered to. This level of personalization (which is common in software engineering) is creepy, and typically only useful to retain people in your software while providing an experience of questionable quality.

Small touches of personalization at the beginning of the experience helps better set the mood and respect levels for everyone involved rather than completely overt personalization throughout the entire experience.

Anticipation

This final component is really where things start to feel like magic for the folks that you are serving. Being able to anticipate their needs and proactively give them the things they don’t need right now, but will need in the very near future completes this sense of hospitality.

You shouldn’t be aiming for anticipating every single one of their needs, but a few of the larger needs will provide the right balance of thoughtfulness and magic. Beyond that it will seem overbearing and as if you’re removing autonomy, which isn’t a great look.

Applying Hospitality to Engineering Teams

When looking at these principles and how they apply to teams, I like to think of personalization and successful anticipation as the byproducts of creating a respectful and vulnerable agreement between all involved parties. Executing on the former will create the space to allow you start venturing into the latter for the community of folks you are supporting.

There are many ways to create respect and vulnerability on your teams, however it starts with you as the manager. Doing things in service to the careers and needs of your team is a great first step in cultivating respect, however, making sure you’re actually delivering on the things you’re promising is more important than saying yes to anything that comes across your plate. Being judicious about where you can actually help someone and where you can’t more clearly sets expectations between folks which drives a behavior of openness for both intra-team and inter-team relationships.

Some key items for creating respect & vulnerability within your team:

Be honest (admit when you’ve fucked up, or when a situation isn’t great)
Be transparent (similar to the above, but the point here is to proactively offer information from your scope of view within an organization)
Follow through (deliver on the things you said you were, explain why you don’t deliver on something, etc.)
Exercise restraint (be judicious about what you and your team signs up for through the lens of the careers you are responsible for and the end product you are creating for the people who use it)
Remember the humans (your team is full of humans, and everyone is different, remember this)

While not exhaustive, these items will allow managers, team members, and any other stakeholder to easily refocus on what’s important. While at times it’s hard to remember all of these actively, creating a culture that tries it’s best to look at the world through a set of lenses like this empowers everyone.

Continued Reading

If this is a topic that interests you I would recommend taking a read through the following books to get a different perspective about hospitality than you might normally be exposed to:

Be Our Guest by Disney (link)
Setting the Table by Danny Meyer (link)

👋