DEV Community: Sean Massa

Theme Pact: Goal Setting Framework with no Goals

Sean Massa — Thu, 02 Feb 2023 00:00:00 +0000

Setting goals seems important, but never feels effective. I never have enough data to estimate proper terms for a goal to make it motivating instead of ignorable or daunting.

Should my goal be to reduce build times by 15% or 20%?
Should I achieve this by the end of the month or quarter?
What happens if I or the business decide that’s not important between then and now?
What happens if I literally can’t complete this because of technical or logistical blockers?

I’ll spare you my long (and boring) history with struggling to answer these questions and deal with the consequences of them. The point is that I need to either find a way to work within the typical framework or find a new one that works for me.

I’ve tried the first approach for many years. It’s time to try the second.

Theme Pact Framework

Pulling from several sources, my framework for goal setting includes:

Theme: a guiding light, a default decision
PACT Goals: specific personal outputs I commit to
Habits: systems for making sure I achieve those outputs

James Clear (of Atomic Habits fame) really summarizes the framework compared to traditional approaches.

You do not rise to the level of your goals, you fall to the level of your systems.

I like this model because you control the direction and personal outputs. Success is therefore under your control. You won’t fail because of external forces made your original goals impossible.

By leveraging the power of direction, defaults, and habits, this framework makes success happen as a matter of course. Well, that’s the theory.

What is a Theme?

This concept comes from the Theme System, developed by Myke Hurley and CGP Grey through Cortex.

Myke and CGP Grey define the Theme System in intentionally vague terms. They want users to use their framework to build a more specific system for themselves.

The themes themselves are defined with a name, description, and a set of ideal outcomes. They call them “yearly themes” for convenience, but these can be seasons, quarters, or whatever works best for you.

For my purposes, I decided a theme has to be:

North Star: A theme is a North Star. It’s a default position. When you come to a decision, you ask yourself, does one of the choices lead me towards my north star? If so, that is your default decision. You can still obviously choose something else, but defaults have incredible power.

Resonant: A theme resonates with you as a deep desire for a high-level focus on a direction. This can be some major thing you want to change, improve, or maintain.

Flexible: A theme is flexible. It should not be overly specific. It can adjust to life (and sometimes world) changes.

Infallible: A theme is infallible. You cannot fail. It’s a direction, not a destination.

What is a PACT Goal?

This concept comes from SMART goals are not so smart: make a PACT instead by Anne-Laure Le Cunff through Ness Labs.

Anne-Laure defines a PACT Goal as:

Purposeful: A PACT Goal calls out to a purpose in your life, similar to how a Theme should be Resonant. Aligning your PACT goals to your Theme will accomplish this by proxy.

Actionable: A PACT Goal is be actionable. It focuses on outputs instead of outcomes to keep you in control of your progress on this goal.

Continuous: A PACT Goal is continuous. It is something you can do periodically and frequently.

Trackable: A PACT Goal is trackable. There should be some measure of either (1) whether or not you did a thing or (2) how many times you did a thing.

I extend this further to include:

Accountable: My PACT Goals are accountable. I share my goal with someone who can prod me when I’m not making progress on it.

Habitual: My PACT Goals are habitual. They either rely on existing habits to trigger new behavior or define new habits I’ll need to develop in order to accomplish the goal.

What is a Habit?

This concept comes from Atomic Habits by James Clear.

James defines a habit as:

Cue: The trigger for the habit.
Craving: What you want that the habit will provide.
Response: The behavior you perform after the Cue triggers the habit.
Reward: The result of engaging in the habitual behavior.

Cues need to be obvious. The best cues are location and time.

Response needs to be easy. Something you can do quickly and without much effort, if at all possible. James suggests putting a 2-minute limit on this.

Craving and Reward are two sides of the same coin. You need to make the habit result in something that you will enjoy in the short term so that you repeat it, leading to the desired long-term change.

I focus mostly on setting new good habits here, but James makes it clear that you can use a similar system to break bad habits.

Setting a Theme Pact

Steps:

Define your Theme
Define the duration (a quarter, season, year, etc.)
Set your PACT Goals
If any of your PACT Goals have blocker habits: define habit breakers
If any of your PACT Goals needs support from a new habit: define new habits
Track your progress

Outcomes

My first stab at this was too much all at once. I did form some useful habits around my theme, but I couldn’t keep up with everything I tried to do.

I (re-)discovered that smaller iterations are better. If you are going from zero to Theme Pact, I suggest iteratively adding pieces until you are comfortable with a given piece. To start, define a theme OR work on forming one good habit OR work on breaking one bad habit.

Resources

If you want to learn more about these topics, I recommend the following.

Theme System: https://www.thethemesystem.com
PACT Goals: https://nesslabs.com/smart-goals-pact
The Power of Habit: https://charlesduhigg.com/the-power-of-habit/

Conventional Comments: Streamlining Feedback

Sean Massa — Tue, 15 Mar 2022 00:00:00 +0000

The idea behind Conventional Comments on Code Reviews is that structure can convey a lot meaning quickly.

This process helps convey understanding of:

what change is suggested
why it matters
how important it is to change now

You can use the process as documented by the author, but I like using the following the following customized version.

Streamlined Conventional Comments

All comments must be resolved before merging, but resolution can look different for different kinds of comments.

All comments are also non-blocking unless otherwise specified.

Format

<label> ([blocking-status]): <subject>

[details]

label: this is a single label that signifies what kind of comment (see above) is being left:
- question
- preference
- suggestion
- convention
- requirement
blocking-status (optional)
- (blank): does not block merging
- non-blocking: does not block merging
- soft-blocking: does not block merging, but the comment should be resolved in a follow-up code change
- blocking: blocks merging
subject: brief and explicit description, no need for padded language
details (optional): the context, reasoning, and conversational messaging

Examples

question (non-blocking): Were you able to find a case when paging.next doesn’t exist?

When I tested analyzing temporary failures, the URL for next always seemed to exist and be the same across all subsequent polls. I ended up having to check whether items.length === 0 (events.length === 0) instead to break out of the loop.

suggestion (non-blocking): extract functions

In the model hooks especially, I suggest extracting functions aggressively. This makes it easier to see each concept that happens as the result of a hook.

What do you think about something like this?
beforeCreate: async function(model, options) {
ensureEmailMxDomain(model);
ensureLatLong(model);
}
convention (blocking): use last_email_interaction_at

Our convention for database column names says that dates should end in _at.

I marked this as “blocking” because migrations are expensive and risky in this database. We should minimize the number of migrations where possible.

requirement (blocking): invert conditional if (found) should be if (!found)

It looks like the code and test are accidentally checking that the file was found, but I think here we expect the file to not be found.

Takeaways

This structure makes it clear to others what needs to be done. It’s also a good forcing function for the author to consider the feedback they provide more carefully.

The best part is that readers don’t have to know about the structure to understand feedback written in this style.

Detangling the Code Review: Questions, Preferences, Suggestions, Conventions, Requirements

Sean Massa — Mon, 14 Mar 2022 00:00:00 +0000

Teams can have more effective code reviews if they default to approval and have a framework for delivering and managing feedback.

Responsibility

As a team member, you have the following responsibilities to your teammates regard code reviews:

respond to code review requests within half a business day with your review or a note about needing more time
review code with compassion and respect
review code thoroughly, thinking through possible impacts and edge cases
after approving code, you take on a share of the responsibility for that code operating correctly in production

As a code change author requesting review, you have the following responsibilities:

drive progress on the code review being merged
find appropriate reviewers for your code change
make your code easy to review
- submit smaller code changes, when possible
- write detailed descriptions of why your changes were made in review requests
respond quickly to feedback

Understanding Code Review Comments

Your goal is to approve the code change if at all possible. This builds momentum, shows progress, and even in cases where the author needs to make a change, allows their original contribution to be impactful.

There are different types of Code Reviews comments:

Questions are simply that, questions about the code change. They can vary in severity.
Preferences are personal, non-functional tweaks to the code.
Suggestions are alternate, functional ways to fulfill the requirements. Ideally they come with some reasoning or pros/cons.
Conventions are project- or team-based rules to follow. They work best if they are automatically enforceable. That way, no human has to comment about these issues.
Requirements are what needs to be done for the code to accomplish its purpose. The code change must meet its requirements.

Question Comments

Sometimes you need more context. Question Comments are a great place to ask for more information because others may have the same question and/or the answer may add context that other reviewers can use.

When asking questions, make it clear how important it is to get an answer. You may have a mild curiosity or a serious concern.

Blocking? If you need to know the answer because you consider the code change to meet the requirements, block merging. Otherwise, do not block merging.

Preference Comments

There’s a time and place for discussing preferences in a codebase, but that’s not during Code Review. When reviewing code, focus on correctness instead.

When you want to discuss code preferences, bring it up during existing team meetings or schedule a new meeting to discuss this.

All of these are preferences, not facts about what’s best, in most programming languages:

where to put optional spaces before/after other syntax
indentation value (tabs/2-space/4-space)
anything else that’s not pointing out a failure to meet a Convention or Requirement

Blocking? If you insist on commenting with a preference, it should never block merging the code change.

Suggestion Comments

When the code change meets the requirements, but it could do so better in some way, you can comment with a suggestion. If the code change meets the requirements in theory, but in practice there will still be significant problems, then it’s still a Requirements Comment.

All Suggestion Comments should clearly describe what the suggested code change is, why it’s better, and why it might be worse.

This is the fuzziest type of comment because complexity and human judgement creep in. You could suggest a code change because the original code would be slow (for a certain definition) and the suggested change is faster. But maybe that code is only ever run on a handful of items in a place where some delay would be fine, anyway. Is it worth making the code faster? Is the faster code harder to read? Maybe we’re not making the right tradeoff in this case.

Be mindful of the pros and cons of each approach when making Suggestion Comments.

Blocking? If the suggestion is an alternative approach that is debatably better, do not block merging. If the suggested code change is significantly better (in your opinion), recommend that they adopt it now or submit a new code change immediately after.

Convention Comments

There are authoring rules that programmers should follow when working in a given codebase that are based on (1) what currently exists in that codebase and (2) agreed-upon rules of the team that owns that codebase.

As many of these as possible should be automatically enforced in the CI test suite. These tests should be runnable in local development environments as well. Ideally, these are also checked in real-time in the dev’s editor. Linting is the most common example of automating this, but it can include performance tests, generative tests, and more.

Not all conventions will be automatable. These are often related to naming variables and functions.

Code Review should only include comments on conventions when they are not automatable. Even then, they should never be blocking comments. Conventions can always be cleaned up immediately after merging a code change that breaks them without affecting the functionality of the system.

Preferences can become Conventions after discussing the issue with the team. These are best batched into infrequent discussions to avoid Convention thrashing.

Blocking? If you are commenting about a failure to meet a Convention, it should rarely block merging the code change. You can recommended they submit a new code change immediately after to remedy the convention violation.

Requirements Comments

There are absolute requirements for a given task for which a code change is made. The code change must fulfill those requirements without introducing new bugs.

If the code change meets the requirements in theory, but in practice there will still be significant problems, then you should still consider your comment to be a Requirements Comment.

Blocking? Failure to meet requirements or introducing new bugs are the only guaranteed way to block a code change from being merged.

Flexibility

This structure gives you a shared set of language and expectations to make code review a more efficient process.

However, there is room for flexibility. When the site is down, feel free to toss these ideas out the window. When you have a good reason to deviate from this, just explain way.

Code Review Framework: Conventional Comments

The idea behind Conventional Comments on Code Reviews is that structure can convey a lot meaning quickly.

This process helps convey understanding of:

what change is suggested
why it matters
how important it is to change now

You can use the process as documented by the author, but I like using the following the following customized version.

Streamlined Conventional Comments

All comments must be resolved before merging, but resolution can look different for different kinds of comments.

All comments are also non-blocking unless otherwise specified.

Format

<label> ([blocking-status]): <subject>

[details]

label: this is a single label that signifies what kind of comment (see above) is being left:
- question
- preference
- suggestion
- convention
- requirement
blocking-status (optional)
- (blank): does not block merging
- non-blocking: does not block merging
- soft-blocking: does not block merging, but the comment should be resolved in a follow-up code change
- blocking: blocks merging
subject: brief and explicit description, no need for padded language
details (optional): the context, reasoning, and conversational messaging

Examples

question (non-blocking): Were you able to find a case when paging.next doesn’t exist?

When I tested analyzing temporary failures, the URL for next always seemed to exist and be the same across all subsequent polls. I ended up having to check whether items.length === 0 (events.length === 0) instead to break out of the loop.

suggestion (non-blocking): extract functions

In the model hooks especially, I suggest extracting functions aggressively. This makes it easier to see each concept that happens as the result of a hook.

What do you think about something like this?
beforeCreate: async function(model, options) {
    ensureEmailMxDomain(model);
    ensureLatLong(model);
}

convention (blocking): use last_email_interaction_at

Our convention for database column names says that dates should end in _at.

I marked this as “blocking” because migrations are expensive and risky in this database. We should minimize the number of migrations where possible.

requirement (blocking): invert conditional if (found) should be if (!found)

It looks like the code and test are accidentally checking that the file was found, but I think here we expect the file to not be found.

Takeaways

The type of comment (Question, Preference, Convention, Suggestion, or Requirement) should lead to whether or not resolution of that comment should block merging the code change:

Question: non-blocking or blocking; depends on context
Preference: non-blocking; don’t comment with this unless you can’t help yourself
Suggestion: non-blocking or soft-blocking
Convention: soft-blocking
Requirement: blocking

However feedback on code changes is provided, they should be communicated with compassion. You should consider how your comments will be received based on team context and experience level of the author. Dr. McKayla goes into much more detail on compassionate code review.

Detangling the Standup: Status Reports, Team Planning, Context Sharing, and Community Building

Sean Massa — Tue, 04 Jan 2022 00:00:00 +0000

Standups are often applied without understanding the problem they are solving. Broken down by potential problem being solved, this becomes more obvious:

Problem	One Solution	Typically Called
unclear project or task status	Status Report meetings	Standup
inefficient team collaboration	Team Planning meetings	Standup
unclear team problems and/or solutions	Context Sharing meetings	Standup
team member silos or other lacks of communication	Community Building meetings	Standup

Because of this, we have new problems:

Not clearly solving a specific problem
Not solving a problem with the best solution
A daily interruption to deep work

What follows is a pragmatic and ideal approach to resolving this situation. The pragmatic approach is to understand so you can excel within that system. The ideal solution tries to change the system to better serve the team.

Note that the value of each process will vary by team composition and project management strategies.

Remote (similar time zones) vs. Remote (various time zones) vs in-person
Cross-functional vs function-specific
More vs. less experienced
Kanban vs. Sprint vs. Project vs. Waterfall styles

Pragmatic Approach

Figure out what kind of standup you have will help you understand its purpose. That will help you accept the value it provides, even if it’s not for you.

You can then try to fulfill that purpose to the best of your ability.

Status Report “Standups”

Individual contributions to these meetings focus on what was done, what’s on track (or not), and what’s up next. They are generally less useful to the individual contributors on a team.

These contributions are most useful to the team lead and/or stakeholders to understand the status of the project.

Yesterday I was working on the “Sign In With Google” story, but hit a weird issue with the integration. I spent a few hours debugging it. I should finish it this morning. Today, I’ll finish that story and pick up the next one.

Context Sharing “Standups”

Individual contributions to these meetings focus on what was done, how, and/or why. They include specifics.

These contributions are generally more useful to the individual contributors on a team. They are less useful to the team lead.

Yesterday I was working on the “Sign In With Google” story, but hit a weird issue with the integration. I spent a few hours debugging it. Turns out, the documentation was wrong about how to differentiate between bad credentials and bad integration.

In my debugging, I built up a wrapper component that smooths over the confusing parts and more clearly validates inputs based on our needs. Make sure you use it in our other apps if you need to implement Google sign in.

Community Building “Standups”

Individual contributions to these meetings pay lip service to the premise of a “Standup”, but spend a non-trivial amount of time on socializing.

These contributions may feel like a waste of time, but are likely useful to all team members. This kind of meeting can build the team community.

Yesterday I was working on the “Sign In With Google” story and I’ll keep working on it today.

Last night I took my kids to a trampoline park for the first time. It was bonkers, but a lot of fun. I ended up jumping just as much as the kids.

Team Planning “Standups”

Individual contributions to these meetings focus on what needs to be done, especially before/after/together with other team members today or in the very near future.

These contributions are generally more useful to the individual contributors on a team, but the team lead needs to know as well.

Yesterday I was working on the “Sign In With Google” story, but hit a weird issue with the integration. I spent a few hours debugging it. I’m still not sure what the problem is. Can someone pair with me on this today, ideally this morning?

Ideal Approach

The best approach to tackling the Standup confusion is to make a list of these kinds of problems, decide if your team has any of those problems (solved for, or not), then ensure you have good solutions for the problems your team has.

For example, say your team has a Status Report “Standup”. You would break out the problems:

Potential Problem	We Have Problem?	Current Solution
unclear project or task status	yes	Status Report “Standup”
unclear team problems and/or solutions	no	N/A
team member silos or other lacks of communication	yes	MISSING
inefficient team collaboration	no	N/A

In this example, you believe that your team only really has two (of these) problems that need solving: “unclear project or task status” and “team member silos or other lacks of communication”.

The current Status Report “Standup” is solving the “unclear project or task status” problem. If you wanted to get rid of this meeting and solve that problem in another way, you could work with the Project Manager and/or Team Lead to find out why your project management system can’t produce this without a daily update from individual contributors. From there, you could experiment with other solutions that fill that gap.

The problem “team member silos or other lacks of communication” is not being solved at all! You could propose that the team schedule other meetings with this explicit purpose. Or, if you want to expand the current “Standup”, you could make socializing an explicit part of that meeting.

Alternate Solutions to “Standups”

If you have these kinds of “Standup”, consider proposing these alternative solutions.

Almost all of these solutions reduce the number of meetings team members have. The effect of this will vary per person, but in general, it provides more uninterrupted time for deep work.

Status Reports

Smaller Tasks: During project planning, break the larger tasks into smaller tasks that can be accomplished individually. Bonus points for making these smaller tasks deployable and valuable to the system or users.
- Why It’s Better: With larger tasks, you can spend a long time on one task with no discernible progress in the project management software. With smaller tasks, you can see (for example) 3 out of 5 smaller tasks for a larger chunk of work in the project management software.
More Status Labels: In your project management software, you may need more statuses that can track where a task is. These could include Deployed to Staging, QA Review, and Ready for Design vs. Ready for Dev.
- Why It’s Better: Detailed status labels can make it clearer to stakeholders what the progress is as well as who’s responsible for moving it forward.
Asynchronous Status Reports: Status reports don’t really need to be made in a synchronous team meeting. Instead, have a rule that status reports be submitted in email or chat every morning.
- Why It’s Better: This provides a similar amount of value to stakeholders and leads without requiring a meeting.

Team Planning

Smaller Tasks: During project planning, break the larger tasks into smaller tasks that can be accomplished individually. Bonus points for making these smaller tasks deployable and valuable to the system or users.
- Why It’s Better: If you have larger tasks that have more complex requirements, it is more likely that the task will rely on others’ work in some way. Breaking tasks into smaller pieces makes each individual step less likely to conflict with something else. It also makes it easier to see connections between tasks.
Daily Strategy Meetings: Yes, this is not exactly an alternative to the Team Planning “Standup”, more a refocusing of it. Define the meeting to be about planning the strategy of the day, explicitly.
- Why It’s Better: Instead of spending time on the ceremony of the standup, you are spending time on solving the problem at hand.

Context Sharing

Asynchronous Communication: Add more context in pull requests, code comments, documentation, email, and/or chat systems. It’s important to have some team guidelines on when and where to do this. It really shouldn’t (only) be communicated in a meeting.
- Why It’s Better: Context that’s documented in an expected place is far more value for a far longer period of time than spoken briefly in a meeting.
Frameworks/Conventions: You can remove the need for some types of context sharing by establishing conventions or using frameworks.
- Why It’s Better: This allows future solutions to conventionalized problems to not need (1) novel solutions per problem or (2) sharing context of problem-specific solutions.

Community Building

Augment Standup: Make it known and acceptable to socialize during Standup. Add an optional question to your format that’s more personal, like “do anything fun recently?”.
- Why It’s Better: Teams often work better if the members have a rapport. This should not be mandated, but should be encouraged.
Virtual Breaks: Set up specific times (like Tuesdays/Thursdays from 10am - 12pm) where people can join a virtual break room call. People can hang out, work, and/or chat in that space.
- Why It’s Better: Especially for remote teams, it can be easy to feel disconnected from your team. Having time specifically set aside for socializing can make it happen more smoothly.

Take Away

Standups are not bad, just often misapplied. Understand the problems you need solved and what the best solutions might be. If that’s a standup-style meeting, then go for it. I just don’t think it should be the default.

Detangling the Manager: Supervisor, Team Lead, Mentor

Sean Massa — Fri, 03 Dec 2021 00:00:00 +0000

Main Idea (tl;dr)

The core argument follows. The most important parts are bold.

Manager (title) is usually some combination of (roles) Supervisor, Team Lead, and Mentor.
These roles cannot be played well together because they have conflicting incentives:
- Supervisor: benefit the company
- Team Lead: benefit the team
- Mentor: benefit the individual
There’s a critical conflict between Supervisor and Mentor that makes it really tough to tell your Manager you need help doing your job.
Ideal Solution: Make sure all roles are:
- played at all
- played well
- played by separate people
Pragmatic Solution: As the Manager, be mindful:
- that you should be playing each role
- of when you are playing a specific role
- to assess yourself in each role

Note that everything I say here has been exhaustively experienced, internalized, and formalized with Trek Glowacki.

Conflicting Roles and Incentives

The term Manager means a lot of different things to different companies. It can include Project Manager, Product Manager, Technical Lead, Team Lead, Mentor, Coach, Supervisor, as well as Individual Contributor. Most often, in my experience, a manager is responsible for at least these roles: Supervisor, Mentor, and Team Lead.

Supervisor Manager: They are most concerned with ensuring the cost of employees is justified by their output. They are incentivized to benefit the company.

Team Lead Manager: They are most concerned with the performance of the team as a whole. They provide team vision and quality. They are incentivized to benefit the team.

Mentor Manager: They are most concerned with helping team members become better versions of themselves, in a professional context. They are incentivized to benefit the individual.

For each type of manager, they play their secondary roles to a lesser degree, sometimes being absent entirely. There are managers that can play all three roles reasonably well, but they seem very rare.

The Mentor role is most often absent and most often needed. It also exposes the strongest conflict between these three roles. Mentor directly conflicts with Supervisor: When you feel like you are not doing a good job, you should be able to talk to a Mentor about it, but a Supervisor may judge you for it, affecting your opportunities and compensation.

Ideal Solution: Separate Roles for Separate People

I think the clearest solution is to split the roles, but that option isn’t possible for every organization. Either your company is too small or too rigid in organizational structure. If you can’t split up the roles, see the next section on a Pragmatic Solution. If you can split the roles, read on!

Manager is not a role. It’s a position in a hierarchy, a title. Instead of having titled managers, make sure you have people playing the different necessary roles. I’ve found the following breakdown to be effective.

Department Head as Supervisor: A Department Head is a good place to have someone playing the Supervisor role. That means you will have no other supervisors in the department. For this to be successful, the person playing this role has to do a good job setting expectations across the department. This can be done through progression and review systems. It’s not easy, but it’s also the most important role to split out from the product team’s day-to-day work because of the detrimental nature of the conflict between this and other roles.

Team Member as Team Lead: Teams should not grow so large that the person playing the Team Lead role has to focus 100% of their time on that role’s responsibilities. That leaves time for them to contribute to the team’s work on the product itself. I’ve found that a 50-50 split between Team Lead and Individual Contributor roles often works well, but it will ebb and flow throughout a project or team’s lifespan.

Company Member as Mentor: Anyone in the company with the understanding of their mentee’s role can play the Mentor role. This could be a more senior engineer in another team or your current team’s project manager. This does not need to be kept within a team boundary. This can be a 100% focus role, but that will be rare until a company is quite large. This is more likely a 25-50% role for someone playing a different role.

For those playing multiple roles, expectations should be set appropriately. It’s all too easy to expect an Individual Contributor to perform similarly to others on a team even though they are also a mentor or a team lead.

This works! The role conflict melts away, leading to a happier, more productive department.

Pragmatic Solution: Strategies for Playing Conflicting Roles

Companies aren’t always large or flexible enough to split up the Manager’s roles into multiple people.

The core strategy to resolve the internal conflict is to try to only wear one role’s hat at a time. While doing this, you still have to acknowledge the conflict between the roles you play. You also need to acknowledge this to your teammates.

Act as Different People: In 1:1s, you are sometimes playing the Mentor or the Supervisor role. If possible, schedule separate meetings per role you are playing. For example, this could be a performance review meeting as a Mentor and a compensation adjustment meeting as a Supervisor.

Develop a Leadership Voice: In product management, project management, and status meetings, you are often playing the Team Lead role, but sometimes also the Individual Contributor role. Make sure that your suggestions are made as one or the other. For example, you might share a project management decision from your work with the department head and other Team Leads. You may suggest a fellow engineer explore a different technical approach to their work. One is broadcasting a decision, the other is suggesting an option.

Stay Self-aware: In other ad-hoc interactions, you may be playing any of these roles. Recognize that your suggestions can come across as commands. Be explicit with teammates about which roles you are playing when.

Performance Assessment of Your Many Hats

If your company doesn’t have clear expectations per role, you should write them out for yourself.

Given your roles’ expectations, do a self review as each one:

Supervisor
Team Lead
Mentor

Then, ask each Team Member to review your performance of each role they interact with:

Supervisor
Team Lead
Mentor

Performance Review itself is a topic for another day. The import part here is that each role is reviewed separately.

Continued Learning

For me:

@endangeredmassa

For you:

Delegating when only you can do the work

Sean Massa — Tue, 02 Mar 2021 17:33:33 +0000

by Trek and Sean

Leaders often end up in the situation where they accumulated more responsibilities then they can execute alone. Delegation is the answer, but you can't just had someone a new task and expect them to succeed.

How do you delegate when only you can do the work?

There are three steps to this no longer being your problem.

Drive Collaboration: The first step of delegation is collaboration. Identify a team member who you want to be able to do this task. Ask them to help you complete the task. The goal here is to get them comfortable understanding what you are doing and how you do it.

Navigate Collaboration: After the team member has a handle on the task, have them do the task while you assist. You are still there to make sure it's done properly, but make sure they are the one actually doing the work.

Delegate Execution: After the team member can handle the task without your help, delegate it!

You are still (probably) responsible for this task being completed, but not for executing it.

If you want to hear more about this and related topics, sign up for our newsletter! We will never sell your information. We send ~1 email per week.

How to Run Strength-finding Interviews

Sean Massa — Wed, 25 Mar 2020 19:54:48 +0000

I was on DojoLIVE! to discuss Strength-finding Interviews. Check it out!

In an effort to highlight candidates at their best, Trek and I have been running Strength-finding Interviews over the past few years. Over the course of 2 companies, 94 phone screens, 27 interviews, 14 offers, and 9 hires we've refined this approach into something that increases our confidence in no-hires and success in yes-hires. Approximately half of the candidates provided unsolicited positive feedback about the process, even when they were not made an offer.

The key difference between a Strength-finding Interview and traditional interviews is that the interview format is customized per candidate to assess their individual strengths. You can still maintain consistency of assessment by making sure strengths are always tested in the same way and that certain core strengths are always tested.

What follows is a walk-through of the process as a guide for how to do this yourself. You can expect to gain:

more confidence in positive and negative hiring decisions
more enjoyable and fair interview experience for candidates
better word of mouth about your interview process, even among candidates you don't hire

In this post, we'll focus on the most unique aspect of the Strength-finding Interview process: Negotiating an Interview Format.

A Job and a Candidate

Let's assume we have an open position for a Web Software Engineer position we'd like to fill.

📋 Job: Web Software Engineer

FlashRecruit is a funded recruitment technology startup with massive traction (SaaS based) looking for a Software Engineer (for full stack development) to join our growing team! We're building chat-based (and other) software to make the job seeking and recruiting experiences better.

Opportunity
You are invited to join us on this adventure! There is a unique opportunity here to not only be a part of what we're building, but to influence the direction we take. You will be able to contribute your different skill sets to the various problems we'll solve together.

In this role specifically, you'll be collaborating with the development team to build new features, new products, and iterate on our processes. These efforts will directly lead to happier customers and more sales for the business.

We'd love to tell you more about what to expect, but the team is small and growing. It's hard to predict what the future will hold. Joining now gives you an opportunity to shape that future.

Context
We work in the recruiting software landscape, which is complex and crowded. We're doing something unique in the space by offering the ability to chat with a recruiter before applying to a job, which is exciting. We're not stopping there.

We're also a small startup, which means you'll likely wear different hats at different times. We expect you to spend most of your time writing software, but sometimes other related hats will be necessary.

We have an office in Oakbrook, which you are free to use if you like, but the engineering team is fully remote. The company fully embraces remote work. You will be collaborating with others that could be working anywhere in the US (for now). Because of this, communication is key. This includes screen sharing, remote pair programming, writing documentation, virtual meetings, and more.

Expectations of You
There aren't many technical requirements. We don't want to exclude you based on something you could learn quickly enough on the job. Instead, we'd like to focus on the skills that we find to be critical to happiness and success in self and team.

Continuous Improvement: For each other item, you don't have to already be great. The core expectation and real requirement is that you improve over time. The processes and expectations in place will facilitate that, but you should be motivated to continuous improvement as well.

Code: Writing software is the core of this role. You should write software that is tested, modifiable, and clear. We have no expectations around computer science concepts, but you should be open to learning about anything relevant to the work.

Worked on Web Software: You should have built web applications or the systems supporting them before. Experience with our entire stack is not necessary. It is helpful to have some experience with at least one of these:

Node.js (API)

Ember (Web Client)

React Native (Mobile Apps)

Heroku/S3/RDS (Infrastructure)

Collaborate: You should work well in a collaborative environment. As a team, we'll be building software, reviewing code, deciding on architecture, and iterating on our processes. You don't have to do all of these things, but we'd like you to be involved with the team more than just executing individual task after task.

Write: Because we fully embrace remote work, you will often be writing messages, pull request descriptions, the occasional document, and more. Technical Writing is an important skill in general, but especially in a remote environment.

Give Feedback: You should give feedback on the product, team, and team members. Feedback should be specific, actionable, and timely. For individuals, it should also be directly related to the job they are expected to perform. You should also be mindful or biases when giving feedback.

Receive Feedback: You should respond well to valid feedback. Responding well can mean many things, including disagreement. We want to build a strong, trust-and-respect-based relationship across the team that allows us to give feedback about actions, not judgements about people.

Benefits

Competitive compensation

Equity in a funded, early-stage startup poised for exponential growth

Full-time W2 employment

Health Care Plan that's good for families and individuals

Flexible time to allow for a work-life balance that works for you and your family

Minimum Required PTO with suggested 4-weeks per year

Intentionally Guided Culture based on inclusion and respect

Remote work

If you aren't sure if you should apply, please apply anyway. Don't self-select yourself out. We'd be happy to discuss any concerns you have with the job post matching your skill set.

FlashRecruit is committed to creating a diverse environment and is proud to be an equal opportunity employer. All applicants will receive consideration for employment without regard to race, color, religion, gender, gender identity or expression, sexual orientation, national origin, genetics, disability, age, or veteran status.

Side Note: I used text.io in the writing of this job post and I'm very happy with the results!

Jessie decides to apply for our job.

👩🏾‍💻 Candidate: Jessie

Education: Self-taught
Experience: 4 years web development

Worked on chat software before

Designed and implemented APIs in Node.js

Implemented web applications in React

Wrote API documentation

Managed API project by breaking down tasks and communicating across teams

Negotiating an Interview Format

This starts with a request for information from the candidate. The request boils down to "what are your strengths that overlap with our needs?"

We sent Jessie the following email in response to their application.

✉️ Subject: FlashRecruit Interview Process

To: Jessie
From: Sean

Hello Jessie!

Welcome to Phase 2 of our interview process!

Phase 1: [Audio Call] Confirm Expectations

Phase 2: [Email] Interview Negotiation

Phase 3: [Video Call] Strength Finding Interview

Phase 4: [Variable] Follow Ups

Phase 5: [Video Call] Meet the Founders

The goal here is to really highlight your strengths. Take some time think about what your strengths are, what our problem domain looks like, and how those overlap.

Our stack is:

Node.js (API)

Ember (Web Client)

React (Deprecated Web Client)

React Native (Mobile Apps)

Heroku/S3/RDS (Infrastructure)

Our problem space is the recruiting software landscape. We're currently focused on improving our job board and streamlining customer on-boarding.

That means:

integrating with third party APIs

building and running recurring processing tasks

consuming XML feeds

iterating a relational-database-backed API

iterating a web client for a job board

iterating a web chat widget

rethinking the job board

Please send me your thoughts on what your strengths are and what would best highlight them. This doesn't have to be lengthy. We'll work together to get a set list in place. Then we'll tailor the interview to that list.

Example Strengths:

Data Modeling a user and authentication system with a focus on security

Finding and fixing poor DB performance

Turning a bug report into an actionable bug fix

TDDing a feature end to end

Refactoring a too-large model

Breaking down large tasks into smaller ones

Optimizing a UX flow

Designing new views

Documenting a gnarly part of the system

Then, we'll schedule the actual interview. We like to book 4 hours for that, but if that large of a block of time doesn't work, we can split it up.

If coding in an interview setting won't show you at your best, we can provide a homework problem for you to tackle or you can provide a suitable work sample. In those alternative cases, the scheduled interview would involve talking through homework or work sample.

If you have any questions or concerns about any of this, please let me know.

Thanks!
~Sean Massa

The candidate then responds with their strengths. If they shared some relevant strengths, select a couple to build into the interview. If not, either (1) select less relevant strengths as a way to assess their ability to master something or (2) follow up with them to see if there are other strengths you could focus on.

✉️ Subject: My Strengths

To: Sean
From: Jessie

These are my strengths that seem to overlap with your needs:

Technical Writing

API Design

Outside-in TDD of a Feature

System Architecture Design

Breaking Large Tasks into Smaller Tasks

I don't typically do well programming in an interview setting. My past work is all private, which means I have no work samples I can provide. Can we do the homework problem you mentioned instead? I'm most comfortable with Node.js for APIs and Jade templates or React for web apps.

Thanks!
~Jessie

Interview Modules

Interview Modules are how you can find balance between consistent and adaptive interview experiences for candidates. The format is flexible around which modules are chosen, but a given module should remain as consistent as possible across candidates.

Selection: Some modules will still apply to most candidates. In our interviews, we typically do the same 2 modules for everyone, then leave room for 2 other modules to be flexible towards the candidate's strengths. Modules should also span technical implementation skills as well as collaboration/communication skills.

Format: Collaboration is very important. If the candidate is comfortable with it, try to make at least 1 large module involve collaboration with a team member. That doesn't have to be live coding in a high-pressure situation. Collaboration could be talking through an architectural design, planning a project, triaging (not necessarily fixing) a bug, or the like.

Construction: As you use this process more, you'll build more and more modules. This will require some work, but it's also worth the effort. When building modules, try to make them as realistic as possible. The domain should be the same or analogous to your domain by default, although you can shift this per candidate too. The tasks should be representative of the work required to do the job. Try to be flexible on technology choices, as well. Candidates will do a better job if they can pick tools they know to solve a problem.

For our job, we could really use someone with strong API Design and high-quality execution. We also want to assess how well they will work in a remote environment.

Let's set up an interview that highlights the candidate's "API Design" and "Testing". We already asked for a technical writing sample and the homework problem includes a writing section as well. We can dig further into how well the candidate works in a remote environment during the Q&A.

✉️ Subject: Interview Agenda

To: Jessie
From: Sean

We're excited for your interview!

Proposed Interview Format

Here's a breakdown of the interview format we'd like to use. Let me know if you have any comments, questions, or concerns.

Intro and Overview (15m)

Homework Discussion: Chat App (1hr)

Break (10m)

Collaborate: API Design (1hr)

Collaborate: Refactoring and Testing (45m)

Break (5m)

Two-directional Q&A (45m)

Intro and Overview

We'll walk through the general landscape of FlashRecruit's industry and architecture. This will help us get things flowing before digging into the other modules.

Homework Discussion: Chat App

Strength: Technical Implementation

We'll discuss the decisions you made and the product you produced for the homework assignment. This will include what you would plan to do if you had more time.

API Design

Strength: "Designed and implemented APIs in Node.js"

We’ll take a page from our system and talk through how we’d go about architecting the API of it from scratch. We’ll dig into general strategy, URL schemes, wire formats, resource relationships, data backing, performance monitoring and optimization, and wherever else you have related skill.

Collaborate: Refactoring and Testing

Strengths: Refactoring and Testing

We'll discuss refactoring and testing strategies in general and with a specific example from our system.

Two-directional Q&A

We’ll take this time to ask more specific questions about each other.

Summary

Please do the following:

provide a technical writing sample

confirm the interview format

provide availability for a 4-hour block in the next week or so

The candidate agrees to the format and sends the requested information. Now we build the assessment scorecard for this candidate.

Each module can assess multiple skills, some deeply and others less so. There can also be a lot of overlap. A scorecard format helps us gather notes from multiple sources about a specific skill.

Below are the modules we're going to run along with the skills we can capture signals for in those modules.

📝 Assessment Plan: Jessie

Homework Discussion: Chat App

UI Component Architecture

UI Component Development

Testing

CSS Implementation

Technical Writing

Breaking Down Tasks

Maintainable Code

Collaborate: API Design

API Design

Testing

Technical Writing

Collaboration

Collaborate: Refactoring and Testing

Refactoring

Testing

Working with Existing Code

Culture: Empathy and Understanding for Past Decisions

Collaboration

Maintainable Code

Two-directional Q&A

Giving Feedback

Receiving Feedback

Remote Work

Collaboration

Continuous Learning

That's It, for Now!

You may be able to imagine how we take that scorecard through to the execution of the interview, but either way, there will be future posts in this series that cover the rest of the process.

I hope you found Strength-finding Interviews useful. This is the result of research, experimentation, and iteration across years of work, quite often in collaboration with Trek. You can read Trek's earlier take on this format, as well.

I consider this to be an evolving process. If you have questions or feedback, please let me know! Please send it to @endangeredmassa, endangeredmassa@gmail.com, or comment below!

Related Resources

An Incremental Approach to Linting to Your Projects

Sean Massa — Tue, 08 Aug 2017 00:00:00 +0000

I have gone through the process of adding linting to existing, large projects a couple of times. I’ve learned some lessons about how to approach this so that it’s not disruptive to the team doing other work. Follow these steps to get robust linting into your project without pulling team velocity to a halt!

What’s So Great About Linting?

The really great benefits to code linting are that it:

fixes potential bugs
removes unnecessary code
enforces internal coding style
(optionally) enforces community coding style

Consistency of code removes the need to make decisions (individually and as a team) about hundreds of small things where the actual decision doesn’t necessarily matter, but having a decision is valuable. With linting, your team can have those conversations once, then enforce them throughout the life of the project. And yes, those can change over time, but it’s much easier to update a rule and fix all of the violations at once!

It can also be valuable to adopt coding styles shared by a larger community. Your language, framework, or tools’ communities will have their own conventions. Aligning with those can help alliviate friction when a developer switches context between internal and external code as well as when a developer changes jobs internally or externally.

How Do I Get Started?

Collect Existing Conventions

You may already have a styleguide or a set of explicit or implicit conventions. Whatever you already have in place, document it as preparation for a Code Convention team meeting. Don’t worry, we’ll only have one meeting in this process!

Discuss Conventions

Take those notes to a team meeting to talk about what the conventions are and what you’d like them to be. Try to stick to higher-level issues (indentation, spacing, keyword use) rather than every single possible decision.

Your conventions will directly and indirectly inform many linting rules, but there are far too many of them to have the team agree on every single one. Starting with a solid base set of rules will allow you to (1) make fewer decisions and (2) leave your team room to make decisions where it matters to them. See the last section for my personal recommendations on linting tools and configurations.

Enforce Passing Conventions

One tool or ruleset at a time, install and configure it to run. Ideally, integrate this into your build process and test suite.

You will probably see a lot of linting failures at this point. Go through the list and disable all rules where there is at least one falure. Now you should see no failures. Keep a list somewhere of which rules are turned off because they fail (as opposed to turned off because you disagree with them). We’ll need those later!

Commit this and submit it for review. What you have now is a set of rules that are enforced and all currently pass linting check as well as a TO DO list of rules to turn on. This should be low-impact to the team while still enforcing the linting rules you were already following.

Fix Failing Conventions

One (or a few related) rule(s) at a time, enable the rules and fix all of the failures. Some tools like eslint will fix some of the failures for you (eslint . --fix).

Submit the changes for review. Team members can disagree and have a conversation in the pull request, but hopefully the earlier discussions make this uncommon.

Repeat this step until all rules are back on!

The Result

We now have a process for incremental maitenance work that we can do in small chunks to improve the state of the code. As long as your team has the appropriate slack time dedicated to maintenance, you’ll get through all of this work in no time!

I Want More!

There are a lot of great linters out there. Here’s a list to get you started!

Happy linting!

DEV Community: Sean Massa

Theme Pact: Goal Setting Framework with no Goals

Theme Pact Framework

What is a Theme?

What is a PACT Goal?

What is a Habit?

Setting a Theme Pact

Outcomes

Resources

Conventional Comments: Streamlining Feedback

Streamlined Conventional Comments

Format

Examples

Takeaways

Related Topics

Detangling the Code Review: Questions, Preferences, Suggestions, Conventions, Requirements

Responsibility

Understanding Code Review Comments

Code Review Framework: Conventional Comments

Streamlined Conventional Comments

Format

Examples

Takeaways

Detangling the Standup: Status Reports, Team Planning, Context Sharing, and Community Building

Pragmatic Approach

Ideal Approach

Alternate Solutions to “Standups”

Take Away

Detangling the Manager: Supervisor, Team Lead, Mentor

Conflicting Roles and Incentives

Ideal Solution: Separate Roles for Separate People

Pragmatic Solution: Strategies for Playing Conflicting Roles

Performance Assessment of Your Many Hats

Continued Learning

Delegating when only you can do the work

How to Run Strength-finding Interviews

A Job and a Candidate

Negotiating an Interview Format

Interview Modules

That's It, for Now!

Related Resources

An Incremental Approach to Linting to Your Projects

What’s So Great About Linting?

How Do I Get Started?

Collect Existing Conventions

Discuss Conventions

Enforce Passing Conventions

Fix Failing Conventions

The Result

I Want More!