All Posts 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.

Humane Software Engineering Interviews

Tue, 28 Jul 2020 10:30:00 -0400

Software engineering interviews are bad. While we’ve all almost universally acknowledged this fact as an industry, there’s been little movement to actually shift to whatever might be considered a ‘good’ interview.

Almost no process that I (or many friends and colleagues) have been part of has actually mirrored what happens in the work place when it comes to software development. It seems like it’s probably time to examine a distillation of most interview processes and analyze each step to see where we can make improvements.

Recognizing that you will almost never have a perfect picture of how a candidate operates is really important before embarking on any interview process. If you’ve designed a process that does give you a perfect picture it might be overly onerous on candidates. Any hiring decision is a bit of a gambit, the more your interview process deviates from the reality of how teams operate will increase the risk of that decision.

Current Process

For the sake of digestion we’re going to break up the current process into the pre-onsite and the onsite portions of a typical interview cycle. We’ll hold critique until we get into the questions section.

Pre-onsite Process

The pre-onsite sequence (enlarged)

As we can see, the process is complicated even before a candidate comes onsite. It should be noted that this is a rough generalization of the various interview processes that I’ve personally taken and have also administered.

At this stage the basic idea is trying to get some early signal on the candidate’s abilities. You may even have a manager phone screen somewhere in this process before it gets to the point where a candidate is sending in code or doing a technical phone screen. Some places are trying to ensure they are making managers a high pass filter at the top of the funnel (I personally agree with this mentality) before asking for engineers to review a take home or do a synchronous phone call.

Onsite Process

Most software onsite interviews are an all day affair comprised of a series of technical and non-technical interviews. The mix between these two buckets of interview types will vary depending on the position and level you are interviewing for, but here’s a (non-exhaustive) list of interview types that are typically employed:

Take home project extension
Domain specific live coding exercise
Computer science grab bag question (tree traversal, hash maps, etc.)
Debug this code sample
Résumé review (go through each job listed and ask the same set of questions)
The Whiteboarding Architecture Interview™
Role playing a workplace situation

There will likely be anywhere from 5 to 8 interviews ranging from 45 minutes to an hour each. Hopefully they have scheduled breaks for you otherwise it will truly feel like a marathon.

Emergent Questions

Through reviewing this process, we’re led to a set of questions about the usefulness of this pre-designed process that should be considered when attempting to build out a new framework. Let’s answer some of these questions that may have been brought forward in order to frame how our new framework should operate.

What’s the goal of the interview?

This is a great question, and one that should be asked of anyone participating in an interview process. If you don’t know the goal, how can you successfully participate?

I would venture a guess that most software interview processes have the goal to try to understand what it would be like to work with the candidate on a day to day basis. Ultimately, I would say it’s impossible to judge the totality of whether or not you could work with someone through a finite set of interviews as humans are very complex beings.

However, setting out to try to answer this question isn’t a bad thing. Creating alignment with interviewers (and candidates) is hugely valuable to ensure that the feedback that is received has the same question in mind.

Does this process mirror how we work internally?

If you are guiding your interview process with the desired outcome being whether or not you could work with a person daily, you must examine the process to ensure it mirrors your typical work process.

There might already be some pieces of how you work embedded in the current interview process, but there are likely other pieces which have no daily analog. This lack of analogous daily rituals can be a ‘smell’ used to diagnose ineffective pieces of your interview process. Giving the candidate the opportunity to explore your team’s regular process is valuable to everyone involved to see if that process actually holds water.

Should different people be involved in this process?

Most engineering teams are in collaboration with at least one or two other teams that might contain different job functions. Are these folks part of your interview panels? If not, should they be? Meeting and interacting with folks doing different jobs (and thus, different perspectives) could be an invaluable set of feedback to gauge this lofty question of whether or not you could work with this person successfully.

Many of these interview processes that we all go through only include engineers, what about product managers and designers input? They are hugely valuable in these processes since their angle of approach is totally different.

A New Framework

Reading these questions, it’s clear to me that in many cases we have work to do. Many interview processes do not effectively mirror what a typical cycle of work looks like. As mentioned, many don’t include other important roles to give input on the various skills that engineers might not see.

For the remainder of this discussion, we’re going to focus solely on the onsite interview process and some remedies we can conceive of. It should be noted, that the following approach could be extended to the pre-onsite portion a well (I think). While the pre-onsite part of the interview process is important as well, it is complex enough to warrant it’s own post at some point probably.

Most onsite interviews that pull from the aforementioned set of examples we’ve listed in a previous section inherently introduce a high amount of context switching into the onsite process. They are designed to be completed in isolation and graded in isolation. On the face of it, this is not a bad thing when you’re solving for having a variety of problems that you could ask in your process. However, these are all disjointed. How often do we go from using a shared text editor to parse items in a two-dimensional array to whiteboarding a completely unrelated question to extending some code that we’ve already written? It’s just not rooted in reality. Also, the candidate doesn’t come away from the interview learning anything about how your teams work together, which is bad.

Project-based Learning

I’ve described this interview framework to a few friends and coworkers, one of which used to be a teacher. This teacher gave me better language to describe this framework (it’s not a new idea!), and it’s called project-based learning. The general idea is that you pose non-trivial problems to students and give them the space to ask refining questions, debate ideas, make predictions, and design plans/experiments among other things. This is a very good description for how most software development processes actual play out within companies. Granted we’re time constrained in an interview context so this isn’t a perfect substitution, but it’s moving in the direction of mirroring how we work, which is good.

Project-based Interview

So with our brief introduction to this project-based approach, what can we do with our onsite process? We’ve talked about how we have a desire to have our interview mirror a bit of how we actually work to both give the candidate an idea of what to expect if they were to get the job, and for us to get actual signal if this person could perform the regular duties of the job in question.

For this example, let’s start with assuming that most development processes have 3 parts:

Designing a solution.
Implementing a solution.
Getting code review for a solution.

These could each be an excellent interview within a project-based theme for someone’s onsite interview day. Generating a project theme can be as easy or hard as you’d like. I personally like the idea of extending the candidate’s take home project (if they submitted one) with a new feature, but having them go through each of these steps in different interviews that can be reviewed individually.

Being able to think about one consistent thing throughout the interview day will give (I believe) more clarity to the entire exercise, allow both candidate and interviewer to go more in depth with each interview, as well as be something that can be a conversation at each step of the way. While it might seem weird to have a candidate work through a Google Doc template writing out how they’d build a new feature in the app they submitted, it’s something that many engineers do every single day. Granted this example is based on my experiences, but you should examine how your teams design features before implementing them and mirror that.

These broad interviews also give you the ability to add other people to the process. You could easily have someone from design or product be part of the designing the solution interviews to work through constraints or desired look and feel. This provides a natural place to get the larger team involved without feeling forced.

The overall idea is to put the focus back onto the candidate, not the problem. These interviews can be supportive, questioning, and thoughtful just like they are outside of the interview context!

–

Project-based learning is only one way to re-implement an onsite interview. The more important part here is to take a mirror to your interview structure and ensure that it mirrors how your teams work day to day. Give your candidates a process that let’s them see how you work and make the decision if that’s how they want to work and learn. Refocusing your interviews onto how the candidate explores your process and works within it (or outside of it!) will yield higher quality signal that you can map to every day experiences.

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.

Being Generous with your Time

Mon, 30 Mar 2020 20:05:51 -0400

One of the best parts about being in any industry for 10+ years is that you get to move from trying to find connections and actively building connections to being someone who has the ability to be the one that helps others connect.

I’m not talking about venture capital style of connections, but mostly just a network of friends and colleagues that you respect, who would do you a favor or two of chatting with someone. Having this level of access to other folks is certainly a level of privilege that should be acknowledged and opened up to others.

This isn’t advocating to pass along every single email or LinkedIn request that you get, but it you do get these you should read them in earnest if they are from an individual looking for help and if you can help, try to. I would also consider going a step further. Open yourself up to connect with folks face to face where possible if you’re comfortable doing that. Putting a face to a name and email dramatically changes perception and understanding.

This is about advocating against the idea of closed off networks that exist purely to create have and have nots sets of folks. Even within the tech community, getting into a large company is hard, but once you’ve been in one it’s relatively easy to move around between them. There are a number of factors for this (yes tech interviews all suck), but part of it is literally just being able to connect with someone that’s had those experiences and help people level-set (and shit, maybe become an advocate for them).

Open Hours

One way that I’ve been trying to be more generous with my time is by literally offering my time to others for free. Similar to how professors hosted office hours, I just open my calendar up to folks and advertise on Twitter (or any Slack groups that I’m part of) and see if anyone signs up.

There is no gate keeping, no screening, just a calendar form. I just show up to whatever appointments folks booked on my calendar with hopefully a little context of what they’d like to discuss. I don’t think I’m some industry pundit, but I do recognize that anyone who has been doing roughly the same thing for 10 years might be able to provide advice for someone earlier on in their career. Also, it just feels like the right thing to do to try to give back to folks in this very small way.

Setting up your own hours

It’s relatively simple to setup a calendar for appointment slots if you’re using something like Google Calendar for work or school, so I’ll outline that approach as well as a newer one that anyone can do if they don’t have an enterprise GSuite account.

For any of these approaches, I’d recommend making a new calendar in whoever your calendar provider is. I personally just find it a bit easier to manage all of these appointments in a new calendar. There is also maybe a bit of de-risking your personal calendar if you’re limiting which calendars are being looked at by default.

Calendly

I recently switched to using Calendly to make it easier for non-Google account having folks to book time (and provide a bit of a nicer interface). I would write a tutorial on how to use it, but really, this is exactly what Calendly is set up to do. If you follow their wizard you will end up with office hours that folks can book without issue.

I like this as it allows non-Google account holders to book, looks nicer, and lets me ask people how they want to meet (Hangout, Zoom, Facetime, etc.) which is half the battle when trying to schedule time with anyone in the first place.

Google Calendar

(Note: this approach will only work if you have a corporate or school GSuite account)

After creating your new calendar you need to make it public so that folks will be able to find the appointment slots.

Click the settings gear icon
Click Settings
Click the name of the calendar you just created under the “Settings for my calendars” section
Click the “Make available to public” checkbox under “Access permissions” section (Note: this will make this particular calendar public to 100% of the Internet)

You will then have to add a new event on the days/hours you’d like to offer these office hours. Do that just like you would for any calendar event but make sure you have “Appointment slots” selected as the event type not “Event”. Here is a support article from Google if you get stuck.

When you visit the appointment page of this event you should be able to publicly share that URL and people will have to book it with another Google account. I would use a link shortener like bit.ly to make this link a bit more memorable/digestible for folks.

I’ve been lucky to connect with a bunch of folks looking to ask questions about going into management, or that are managers just looking for someone to talk through some issues with. I also am really looking forward to whoever else decides to sign up and chat since I’ve been able to learn something new about someone (and typically myself) every time I’ve had the opportunity to chat with someone.

If you’re curious about this article, or idea, or just want to chat about something else I encourage you to take a look at my open hours and grab some time at https://bit.ly/bsm-oh.

Looking forward to chatting with you 💬

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)

👋

Things That Are Work

Mon, 22 Apr 2019 01:01:15 -0400

This is just a running list of things that I consider work, this list is unordered as there isn’t an inherent prioritization in these items. However, they should all be considered in the total set of things that should be valued as ‘work’.

This list is not exhaustive.

Things

Reviewing code
Thinking about code
Making a spreadsheet
Reading e-mail
Responding to e-mail
Organizing your calendar
Helping someone fix a problem, bug, etc.
Cleaning up your workspace
Having a face to face conversation (in-person or on video chat)
Reviewing team, personal, organizational goals
Taking time off from work
Writing code
Leaving/answering comments in a document that someone thought to send to you
Organizing an event
Mailing something to a distributed teammate
Providing feedback
Helping with hiring in literally any way
Eating lunch
Defending your calendar
Saying no to things
Organizing your todo list
Realizing that you haven’t made progress on something and getting up to go for a short walk
Flying to collaborate with co-workers in different places

All of these things are work.

Attention Fatigue

Sat, 20 Apr 2019 16:34:08 -0400

Controlling your attention, and the things that ask for it, are argubly one of the hardest things to stem the tide against. However, even if you can’t control this attention, what do you do when you have the sudden streaks of being able to focus?

Recently I’ve been running into an issue where a bunched up schedule suddenly relents, and while there are a number of things to do ranging in importance, I just kind of spend the time trying to prioritize what to do next.

A regular Monday on my current schedule.

The Attention Barometer

I like to think of my attention a bit like a barometer. When performing similar activities, maintaining the same level of pressure allows for me to perform the same activity repeatedly, without issue. However, once a gap is introduced, or a new activity type, instead of going back to the baseline of mental effort required to do the new task a dip below baseline happens.

While switching into a new, pre-defined activity (maybe going from a regular meeting, to a 1 on 1 meeting) quickly makes up the deficit that exists to re-establish the baseline, and then build some more. It’s times where there are no other pre-defined activities already set forth that actually exacerbate this dip.

What’s worse, is that when this dip happens I feel bad for not immediately knowing which thing to tackle next as I feel like I need to maximize use of this undefined time since it’s a scarce resource. So this has lead me to try and figure out better strategies to use this space without having to spend time reprioritizing my todo backlog for maximal output.

Strategies So Far

Do nothing, and respect that maybe this feeling is fine.
Groom my todo backlog every morning and execute on them in priority order (drink the GTD punch.)
Use this as time to read through professional publications like hbr.org for material for next manager meeting.

None of these strategies so far have made me feel “good” about this time as it feels like a good manager would always have something to do in this time, but honestly, it’s nice to just have a breather to connect with people in person in the office to see how they are doing. This might also be a sign that I need to defrag my calendar again to better align meeting contexts where possible.

Mostly, I just wanted to acknowledge this problem that I have sometimes and put it out there if others feel the same way. I’d be curious to know how you’ve learned to feel different about these times, and maybe make the best use of it. Also, what does “best use” mean in this context for you?

Feel free to send me a message about it @brianmichel.

2018 Year In Review

Thu, 27 Dec 2018 19:15:34 -0400

Overall 2018 was a bit of a mixed year for me. There was a blend of good and bad, but all of these things added up to, I think, a pretty good year overall. I wanted to catalog a list of things that happened this year so I can take stock of the good, and the bad. Let’s start, these aren’t in any particular ranking or order.

Started a new blog!

This is it, you’re reading this post on it. I’ve always wanted to have my own space online, but usually relied on things like Medium or Tumblr to be those places. This year I took the time to make this Hugo blog and made my own austere theme, and I really enjoy having this space online to publish my thoughts, as well as knowing that I own the content.

Home Improvements

This year I recognized the value of really making my apartment my own and got some plants, and a Roomba, which really makes a quality of life difference to me of just keeping my place a little extra clean. Also, having something to take care of at home is very enjoyable and plants just really brighten up my space.

I also did some small projects like reorganizing my things, and trying to make the best use of my space, which makes my space feel larger and just like I’m more in control of where and how I live (a weird thing to say, I know).

I also started making cold brew, and recording each of the times I make it and all the variables that I can track to see how each batch comes out.

Worked Through A Bad Breakup

Yup, these things happen to everyone for sure, but when it happens to you, it’s always different. Not much to say here other then I was very sad, and through time and talking with others it’s getting better. I feel much better now than I did 6 months ago. Thank you to my friends and family, and everyone else that’s been there for me to talk to.

Relationships are hard, so are emotions.

Merged Two Teams Together At Work

At work, I felt successful bringing together two different groups of people, dramatically increasing the purview of my team, while empowering folks to really try to own their given area of our code. This was a huge growth opportunity for me since I have never done such a thing before, and has proven to yield continued challenges (in a good way).

2019 will the year that I solve a personal scaling problem to ensure the 12 engineers that I work with have the same level of coaching, while also giving myself free time to focus on being strategic for both our team, and for each engineer’s growth plan.

Yoga 🧘‍♂️

I’ve started doing yoga every week. This came out of the break up thing, but has been something that I’ve stuck with and enjoy. I like spending some time in the morning before work doing some yoga to wake myself up for the day, as well as to just start my morning a bit more slowly than a younger me would.

I used to just wake up, shower, and go directly to work. Now I have the flexibility of starting work a bit later, so I use my time in the morning for myself, to welcome the morning in by doing some basic yoga.

Side Project!

I’ve started working on a side project with my friend Amelia which has been fun to work on even though it is very, very early days with it.

Books

This year seemed to be a very good year for me and reading books. Granted I haven’t finished all of them, but here are the books that I have read, or am in the middle of reading right now:

Travel ✈️ ⛴

This year marked me traveling internationally for the first time in my life, and then I did it 2 more times on my own 😀. It was a blast to travel around the world this year, and see things that I would have never done otherwise. The highlight of my trips would have to be going to Japan for work. I would 100% go back again since it was such a joy to visit. I feel incredibly lucky that I am able to travel and see other places.

That’s it! A brief summary of my 2018 (at least the things that come to mind!) I’m ending the year happy, and hopeful for 2019 both professionally as well as personally.

✌️

Retreating Inwards

Sun, 14 Oct 2018 17:46:54 -0400

A few weeks ago, I had the good luck of going on a retreat with a group of fellow managers at work. Initially I was hesitant to get together with a bunch of different people managers from around the company, whom I mostly didn’t know, to talk about our different situations as managers.

The hesitation arose not only around my lack of knowing them, but also around feeling like I wasn’t going to be “productive” for my team while I was away at this retreat (which is something I always think about when travelling for work). I kept thinking about how my time here would help make my team better, and avoid thoughts of it feeling like a selfish gesture to go on this trip.

However, at the end of this retreat I came out with a new group of peers to grow and learn with. Knowing that we have similar challenges, and that we all want what’s best for our teams.

The Scene

The location was beautiful. A retreat center nestled into the hills of Los Altos which very much allowed us all to shrug off our regular thinking and open up to each other about the problems we all face as managers.

There were about 15 of us, all different kinds of managers from all around the company. Design managers, Data Science managers, Product Managers, etc. Having a variety of folks there was nice in that we can all compare and contrast our different experiences and teams to see the issues we all have, and maybe some new ones that we should be conscious of that we didn’t know about.

I could tell some people, like me, went into this entire thing a bit unsure if they would get anything out of it. Over the next couple days I could see us all opening up more, trusting each other, and forming a bit more of a bond.

Some people had just become managers, some people were new to the company, and others had been there for a much, much longer time! All of us were in the same boat though as we’ve never been in the same room together.

So Now What?

Through this retreat, and bonding with fellow managers, it has re-shown me the importance of investing in yourself and your career. Whether you’ve been doing management a while, or are new to it, the potential to “lone wolf” situations you are in is very high. This is even more so if you’re either distributed or the only one in your position at your company.

As managers, we learn through experiencing new situations. Sometimes we make the wrong decisions; we still learn, but it can be painful. Finding a peer group is literally getting to draw on everyone’s shared experiences to ensure, if nothing else, that you have the most information you could have when making a decision. These folks can advise you, and you can advise them. You can share stories, and ask for feedback that folks in your direct management chain may be unable to provide.

Finding that peer group isn’t always easy. If you work somewhere where there are other managers you should try to talk to them. The odds of you both having very similar problems might be very high, or maybe they’ve already experienced this issue and can provide guidance. If you don’t work somewhere that has peers in the same situation as you, I’d recommend joining a management community like The Watercooler (paid subscription required) or The Engineering Managers Slack Group (free) to join a group of folks that share similar sets of problems.

Lastly, if none of those work for you, or if you just want to chat about management feel free to DM me on Twitter @brianmichel, and I’ll do my best to answer any questions you might have.

✌️

Manager Readme

Sat, 13 Oct 2018 19:15:34 -0400

I’ve seen a few of these floating around and wanted to take a stab at some introspection on my own part so that I can try to observe myself, the tools I like to use, and the different ways that people may not know that I prefer to work. I wanted to do this since I just came back from a manager offsite and we talked a little bit about this kind of thing there as well.

I feel that outlining how I work will help those that I work with more quickly understand these pieces of me in hopes to make our working relationship that much better.

—

Hello! Welcome to our team, we are very excited to have you here with us 😀.

I wanted to take some time to outline how I work to accelerate our working relationship together. Also, I’m very much looking forward to getting to know you better through our one on ones, chats, and all other variety of communication that I’m sure we’ll have.

This document is:

a way for me to introduce myself.
something that can answer some likely questions.
a reasonable set of expectations you can have of me as your coworker.
alive. As I change & learn, this document will do the same.

This document is not:

A set of expectations I have of you

Our Cadence

We will have a one on one every week, for at least 30 minutes. This meeting is our time to get to know each other better on a human level. Ideally, it should not be related to project status updates as I can locate those things through JIRA, or in other ways. I would like you to drive this meeting by default, but I will also drive if you ask me to.

You can message me through Slack whenever you want to. Typically I respond very quickly, however I might ask you to e-mail me since I put many reminders / follow ups in e-mail.

I have zero expectation of you working on the weekends. Sometimes I do a little bit, and might Slack / email you during that time, but you should feel free to ignore that information until the work week begins.

My calendar is mostly public, and up to date. If something is private it will be marked as private so folks cannot see it. If I am traveling, I try to keep my regular meeting schedule (albeit adjusted for time zone if needed). If you are curious about a meeting on my calendar, please ask me about it.

Guiding Principles

People > process every time. People are the building blocks of any organization, product, or process. I believe that when people can contribute their ideas, express themselves, and be happy with their work that a higher quality product always emerges. Diversity in background and thinking is key to building a great team.

Autonomy & empowerment unlock potential. I believe in the Directly Responsible Individual model of working. Giving people the ability to make decisions and act on them is key to growth and understanding. This does not mean I expect you to make every single decision on your own. I am here to provide mentorship & guidance on any decision (or assist in finding someone who can help).

Helping others is the right thing. Whether it’s doing a code review for someone else, reading a document that was asked of you, or just cleaning up after yourself I believe that helping others causes an outsized impact, and is just generally the right thing to do.

Honest feedback is a basic need. In order to grow and learn, I believe that myself and others need to receive and give honest feedback. This does not mean that feedback should be blunt and designed to hurt. It does mean that feedback should be delivered in a timely fashion and always seek conversation with those it is being delivered to.

Assume positive intent from everyone. Trying to think that everyone is out to get you is incredibly exhausting, and almost always not true. Going into things with a positive mindset allows for easier personal operation in most situations.

A decision is better than indecision. Moving forward, or not, in a decisive fashion allows you to more quickly evaluate almost all situations. Endlessly waiting in indecision will rot your brain.

Idiosyncrasies

I am not an extrovert. This may seem untrue if you encounter me in the work place. I am good at working in groups and with many other people, however I do not receive energy from those situations and my energy through the day will likely gradually be on the decline.

I will answer technical questions through the eyes of an iOS engineer. This is what my work experience as an engineer is mostly in. It is not meant to come off as any specific bias towards one platform or another, it’s just what I know.

Sometimes I curse. Sorry. It just comes out sometimes when I’m excited, and incredibly rarely when I’m upset. If this bothers you, I’d ask you that you let me know so that I can check my language.