So what do you do? Do you mandate that everyone follows the same agenda? (That feels too rigid and doesn't honor that teams are in different places, plus it would never actually work.) Do you let everyone do whatever they want? (That feels too loose and you might end up with wildly different quality of experiences.) Do you try to review and approve every single agenda? (You don't have time for that, and frankly, you shouldn't need to micromanage this.)

As an executive leader, one thing I frequently see is how different team gatherings can be from department to department or team to team, especially in engineering where managers and leaders have different levels of experience planning and leading these sorts of gatherings. Leaders want to create happy, healthy, aligned groups, while recognizing that what each group needs is slightly different. The challenge is figuring out how to ensure some consistency and quality without putting each group in a box or needing them to follow the same outline.

Here's what you can do to balance consistency with flexibility:

1. Outline overarching goals and outcomes

Before any team starts planning their specific gathering, you need to get clear on the high-level outcomes you need from these experiences. Not the detailed agenda, but the bigger picture. What should be true after these gatherings happen? What should people know, feel, or be able to do differently?

For example, your overarching goals might be:

• Every team should have clarity on their quarterly priorities and how they connect to company goals
• Every team should identify at least 2-3 concrete improvements to how they work together
• Every team should leave with documented decisions and action items (not just "good discussions")
• Every team should strengthen relationships across team members

Notice these are outcomes-focused, not activity-focused. You're not saying "everyone must do a vision exercise" or "everyone needs to include a retrospective." You're saying what should be different as a result of the time together.

This gives teams flexibility in HOW they achieve these outcomes while ensuring consistency in WHAT gets achieved. The platform team might need to spend more time on technical strategy while the product team focuses on cross-functional collaboration, but both should walk away with clarity on priorities and concrete improvements.

Share these overarching goals with all the teams planning gatherings. Make it clear: these are the non-negotiables. How you get there is up to you, but these outcomes need to happen.

2. Review plans and approaches

Once teams have drafted their plans, create a lightweight review process. This doesn't mean you approve every single agenda item. It means you're checking that:

• The planned activities actually map to the overarching outcomes you set
• There's a balance between strategic work and connection-building
• They've thought through how decisions will be made and documented
• There's a plan for follow-up and accountability

This is also your chance to spot gaps before they happen. Maybe one team has packed their agenda so full there's no breathing room. Maybe another team has lots of "discussion" time, but no structure for turning discussions into decisions. Maybe a team is planning activities that worked great for them last year, but won't address the challenges they're facing now.

A good review conversation sounds like:

• "I see you've allocated 3 hours to discuss priorities. How will you make sure that turns into actual prioritization, not just talking about priorities?"
• "You've got a lot of great activities here. Do you think it's too much for folks? Will they be burnt out by the end of the first day?"
• "This agenda looks great for the leadership team. Have you thought about how you'll bring the rest of the team along on these decisions afterward?"

The key here is that you're coaching, not mandating. You're asking questions that help them strengthen their plan, not telling them exactly what to do.

3. Plan collective follow-up sessions or shareouts

One of the best ways to create consistency without rigidity is to plan how teams will share their outcomes with each other. This serves multiple purposes:

First, it creates accountability. If teams know they'll be sharing what they decided and what they're committing to, they're more likely to actually make decisions and create real action plans (as opposed to just having nice conversations).

Second, it helps teams learn from each other. Maybe one team tried a new approach to prioritization that really worked. Maybe another one discovered a communication practice they want to adopt. When teams share their outcomes, they're not just reporting—they're teaching each other.

Third, it reinforces the overarching goals. When you bring teams together to share, you can see if everyone actually achieved those outcomes you defined at the beginning. If three teams crushed it on priorities but struggled with relationship-building, that tells you something about what support teams need going forward.

These follow-up sessions don't have to be long or formal. Even 30 minutes in your next all-hands where each team shares their top 3 commitments and one thing they learned can be powerful. Or a shared document where teams post their action plans and what went well.

The key is creating a forum where teams see the common threads while celebrating what made their experience unique to their needs.

4. Send fieldtrippers between teams

Here's one of my favorite approaches for creating consistency and cross-pollination: send people on "field trips" to other teams' gatherings.

This doesn't mean someone sits in on the entire 2-3 day offsite (though it could). It might be someone from the platform team joining the product team's gathering for half a day, or vice versa. Or someone from your leadership team rotating through different team offsites to observe and participate.

I've written about this approach before, but here's why it works for consistency:

Fieldtrippers see what "good" looks like in different contexts. They experience how other teams approach similar challenges. They bring back ideas and practices to their own team. And they create connections across teams that wouldn't happen otherwise.

Plus, it's a great development opportunity for emerging leaders on your teams. Seeing how different groups operate and experiencing different facilitation styles helps them grow as leaders themselves.

5. Hire an outside facilitator

Yes yes yes, shameless self promotion, but this also makes sense... Look, all of this takes a lot of time. Defining outcomes, reviewing plans, coaching teams through their design, making sure quality is consistent. And that's on top of all your other responsibilities as a leader. Additionally, it's possible that you don't have the depth of experience to be able to provide creative, meaningful exercises or approaches to achieving these goals.

An external facilitator, especially one familiar with your functional area (like engineering), can help take some of this work off your plate.

Here's what the right facilitator brings:

They can be flexible enough to design and facilitate an experience that is tailored to each team while also ensuring that high-level goals are met. So your platform team gets the technical deep-dive they need, your product team gets the cross-functional collaboration focus they need, but both achieve the overarching outcomes you've defined.

They ensure a level of quality and similar experience across teams. When you have one facilitator working with multiple teams, you get consistency in facilitation approach, quality of experience, and how outcomes are documented and followed up on. Teams aren't comparing notes afterward and realizing one group got a transformative experience while another just did trust falls and called it a day.

They bring objectivity and can navigate dynamics you can't. An external facilitator can ask questions and push back in ways that internal leaders sometimes can't. They can surface issues that might not come up if someone from the company is leading the conversation.

And honestly? They save you time. Instead of reviewing every agenda and coaching every team through their planning, you have one conversation with the facilitator about your overarching goals, they work with each team to design accordingly, and you get consistent quality without being in the weeds of every single plan.

The Balance

The goal here isn't perfect uniformity. Different teams need different things and that's okay. The goal is ensuring that regardless of what specific activities happen or how the agenda flows, every team is getting a high-quality experience that achieves the outcomes you need as an organization.

Think of it like this: you're setting the guardrails (overarching goals, quality standards, follow-up expectations), but letting teams drive within those guardrails in whatever way works best for them.

Some teams will need more structure and support. Others will thrive with more autonomy. Your job is to provide the right scaffolding so that every team succeeds, while recognizing that success might look a little different for each one.

And remember, this is iterative. After your teams do their gatherings, talk to them about what worked and what didn't. Use that learning to refine your approach for next quarter or next year. The teams that struggled with certain aspects can learn from the teams that excelled. The overarching goals you set might need adjustment based on what you learned.

The consistency you're after isn't "everyone does the same thing." It's "everyone gets the support they need to have a transformational experience that moves their work forward." That's worth investing time and attention in.

If you're an engineering leader managing multiple teams and want help ensuring consistency across your team gatherings, book a free consultation call with me today. I can help you define the right overarching goals, review team plans, or facilitate experiences across multiple teams so you get consistent quality without putting everyone in the same box.

First off, what is a skip level?! A skip level is exactly what it sounds like... a conversation with the people who report to the people who report to you.

Now, here are some common sentiments about skip levels:

• I barely have time for 1:1s, how am I supposed to fit skip levels in?
• It's super weird for me to talk to people when I don't have a lot of interaction with them.
• Meeting with my skip levels undermine the folks who report to me in the eyes of my skip levels.
• My direct reports are uncomfortable with me having skip level conversations.

I've always found skip levels incredibly helpful and effective so I want to give you some ideas and tips on how to introduce them, how to structure them, and some new ideas if you don't have time to really chat with everyone.

How to introduce skip levels

Skip levels often get this bad reputation for being systems to "check in" on a manager or try to catch individuals in some work issue, but this isn't (and shouldn't!) be what they are used for. Skip levels are used to get information about what's working well and what isn't, about what messages or company priorities are understood by folks and what isn't, to help spot gaps within the system, and to further support individuals.

When I roll out skip levels to managers, I let them know that this is a way for me to get to know individuals as people, understand what they're working on, as well as what they think is going well and what they'd love to see improved more broadly. A key detail here is that I tell managers to please give me a sense of what they're talking about to their individuals (either for improvement needs or growth opportunities) so that I can be on the same page. The last thing I want is to go into a skip level and accidentally give someone signals that they're either doing well where they aren't, or provide advice, ideas, or opportunities that are contradictory to where their manager is trying to encourage them towards.

When I roll out skip levels to individuals, much of the messaging is the same... that these are casual conversations to get to know them, hear more about their perspective on their team or the department or company, and understand what they think is awesome and what they're feeling "meh" about. It's also an opportunity for them to get to know me, so they can also feel free to bring anything that's on their mind that they want to discuss further.

The most important part of this is that there truly can't be any immediate negative consequences to someone sharing something in these skip levels. A large part of these conversations is about building trust with both your direct reports and the folks that report to them, so if you hear something that feels concerning or worth looking into further (and you will), make sure to think about how to handle that in a way that doesn't destroy the trust you're attempting to build or maintain.

How to structure skip levels

Usually, my goal is to meet with everyone, individually, once per quarter for 30 minutes (see below if you have a larger department or if once per quarter is just not feasible for you). I'll schedule a handful per week every month and that usually gets me through a good number of folks without it feeling like it pulls too much from my calendar.

I keep these conversations pretty casual HOWEVER I always have a structure for them. We don't need to keep to the structure... much like a regular 1:1, you'll have some folks who come with an agenda and full list of items they want to discuss, and others who will say "things are good" and if you don't have a bit more of a structure, you'll be tempted to end the conversation early or continue it in a way that likely feels awkward and painful for both of you.

My broad questions are:

• What's on your mind? (always start with just a broad opening. This gives people who came prepared and ready the opportunity to jump right into their agenda, and for others, it gives them a chance to share if there is anything they're thinking about)
• What kinds of things are you seeing or working on that's making you happy or feeling positive right now?
• What kinds of things are you seeing or working on that are feeling frustrating or unclear?
• Anything you want to see more of from me or in the department as a whole?

From here, there are always a few "variable" questions I throw in based on what's going on that month.

• I posted about X in the last couple of weeks, did you have any questions about that? OR How did that land for you?

This question is really helpful if I or the company rolled out a new policy, process, or idea in the last couple of weeks. Sometimes I get "oh, I didn't see that. Can you remind me what you're talking about?" From there, sometimes I'll then reinforce with managers the need to share important messages directly with their teams, or it will give me the chance to ask something like: Was the channel I posted in ok? which channel or what method would you have seen it in?

• I've been noticing X, I'm curious if you've noticed it too/if you have any thoughts about that?

This is helpful for information collecting... when I'm starting to see a pattern or trend and I'm curious how it's affecting people.

• I saw X metric change recently. From your perspective, how are you feeling about X?

There are various tools that I use to track and measure developer sentiment and productivity. Sometimes these conversations are after a larger engagement survey, other times after a pulse survey, or a developer satisfaction survey where I'm noticing numbers that have gone up or down. This is my chance to not get the "well I think people might feel," but to really get just from them and their individual perspective how they interpreted a question or how they're feeling about something.

Alternate ideas to 1:1 skip level conversations

Individual skip levels on a regular basis only scales so far. If you have a larger department, you need alternate approaches to keep in touch at this level with folks. It's often the first thing to go or to be cut from the calendar, which leads to issues down the road. So here are a few recommendations for what you can do instead.

1. Small group skip levels: Instead of 1:1 skip levels, you could maintain the same structure of the conversation, but have them with groups of 5-8 individuals. This allows you to hear similar perspectives and ideas around the questions you would ask individually, but with a larger group, covering more people in each occurrence. Something to keep in mind with this approach: you have to be really careful with group dynamics. Don't do small groups of people who all have the same manager, be aware of power dynamics if you have folks who are new to their careers with folks at a much more experienced level, etc. And understand how those dynamics may change how the conversation flows (or doesn't).

2. Office hours: Offer optional, but regular office hours (often monthly) where the agenda discussed is whatever topics people bring to discuss. This gives people a way to proactively bring their thoughts and ideas to you, providing them with that same outlet. I also have periodically posted something like "in this office hours, I'm really curious to hear about X, so if you have a perspective on that or thoughts, please try to attend." These aren't recorded to allow for freer conversation and they can be a great way to understand what is on people's minds or get information on something. A couple of things to keep in mind with this approach: first, you'll get a lot of people who don't have anything specific they want to talk about but want to hear what other people say or ask about. In this scenario, you risk having one individual regularly dominate the conversation, or everyone coming for that reason and no one really having anything they actively want to discuss. Second, it is up to YOU to make office hours compelling and fun. You want people to want to attend office hours. When there's lots of silence or it feels awkward, people start avoiding attending office hours, and then it's just 30 minutes of wasted time on your and their calendar, so always have a couple of fun topics, stories, ideas, etc. to pivot to so people keep coming back whether there's something "spicy" going on or not.

3. Department-wide retrospectives: Quarterly, you can run a longer department-wide retrospective. This gives people a structured way to discuss and address things they're loving and things that are concerning to them. Some critical things to think about when going down this path, that make this option a more challenging one: you're only hearing about these issues once in the quarter, which can lead to people waiting until this retro happens, as opposed to you or others proactively putting improvements or solutions in place. Additionally, you should allot enough time to really get into some of these issues, meaning these sessions will likely be 90-120 minutes to allow for adequate time. Finally, speaking from my experience as a facilitator, you need to have a plan to make sure this conversation effectively gets thoughts and ideas out into the open, while keeping it productive and proactive, and making sure everyone remains engaged for that amount of time. This is hard to do with a large department so it takes time to plan and be really thoughtful and intentional about it.

Additionally, I recommend to always try to do skip levels with a handful of individuals. Pick maybe 15 people to try to meet with quarterly. And RESIST THE URGE to make this group just any of your more experienced/higher level folks who are in that skip level layer. If you're only talking to those folks, you'll get a skewed sense of how things are going. Within that mix, pick a few people that are often vocal about changes, people who report to a variety of managers, gender diversity so you're getting broader perspectives, and some who are newer in their career and/or to the company and some who are more tenured.

Quick tips

• Don't take skip level conversations as 100% truth. We know that we catch people on certain days and times. Sometimes they're in a good mood, sometimes not. Sometimes their manager has just had a difficult conversation with them, other times they just got a promotion. Anything that someone tells you in a skip level should be noted, but then, make sure you're checking that information with others or keeping an eye on it. You can also follow up with them in a subsequent skip level, something like "last time you mentioned X, are you still feeling that way?"
• Expect it to take a little while for people to warm up. Your title, no matter what it is, makes you scarier for people. Plus, who knows what you'll DO with the information. They don't want to get anyone in trouble (or maybe they do, but they're not sure if talking to you will backfire) and they don't want to be seen as a tattle-tale or fear retaliation of any sort. Plus do you actually know what they do day-to-day? How could someone at your level know or remember what it's like to operate daily like they do? And there's always baggage from other roles in the past where skip levels either didn't happen, didn't happen consistently, or were weaponized in unproductive ways. So keep all this in mind, don't give up, keep your structure, and remember that it'll take a few skip levels to really get people to start talking to you about things.
• Once it feels like there's a lull, space them out a bit or mix them up. There will be a point when people are comfortable coming to you outside of skip level times. When, if there's really an issue or a question they have, they'll just ask it in a department meeting, chat app channel, or a DM. When this happens, don't just drop skip levels, because you don't want to start them up when something is wrong or not going well, but you can, at that point, space them out a bit or change the format to maximize your calendar and time.
• Take notes! You'll have skip levels less often than 1:1s so you'll want to make sure you're taking some notes so you remember what you talked about last time before going into the next conversation.

Trying to figure out how to make skip level or other meetings more effective and productive? Book a free consultation call with me today. I'll help you talk through what actions will lead to the outcomes you're looking for.

What you hear sounds reasonable. Your direct reports want to hang out together and just have some team bonding time. One or two people have some ideas of a process or approach they want to try out and they want to use that time together to brainstorm and/or get feedback and buy-in. So that's that. You divvy up the agenda, post in a few Slack for good "team bonding activities", and move on to the next things you have to get done.

Does this sound familiar? Probably. It's what I see a vast majority of leaders do when they're planning and thinking through these gatherings.

Here's some hard truth... even though it feels fine, good enough, maybe even productive, it's not. Your expectations are too low.

What's actually happening here

When you ask your team "what should we cover?" you're asking them to tell you what would make a good birthday party, not what would truly drive business goals forward. They're going to tell you things like:

• We should hang out more
• It would be fun to do an activity together
• I have this one idea I want to workshop

And look, none of these are wrong. But they're not strategic. They're not going to move the needle on the conversations you've been having or thinking about for six months without resolution. They're not going to get you unstuck on the challenges that keep you up at night. They're not going to create the kind of alignment that makes the next quarter run smoothly instead of continuing to run to the next fire.

And even if your team can tell you what they need, it's up to you to frame and tackle these challenges in the right way, so that they're looking at the heart of the issue and not just a piece of it. They're measuring success against other gatherings they've experienced, which (let's be honest) have probably also been just "fine."

You can think of it like customer interviews. When you're talking to customers or constituents, they'll give you ideas but you don't build each of those things into features or programs. You take a deeper look at what threads are connecting those requests, examine your customer's journey and their pain points in order to get to what they don't even know to request. THIS is your goal when designing a gathering.

What you're actually optimizing for

Here's what typically happens with this approach:

1. You spend time together
2. People enjoy seeing each other
3. You talk about some things
4. Everyone leaves feeling pretty good and probably with some next steps from some discussions but not all of them
5. Three months later, not much has actually changed

You're optimizing for "did people have a good time?" when you should be optimizing for "what's different six months from now?"

The conversations that have been stuck for months? Still stuck. The alignment issues? Still there (or went away but have since resurfaced). The priorities that feel fuzzy? Still fuzzy. The energy and excitement from the gathering? Gone by the following week when everyone's back to their usual routines.

And look, I get it. People having a good time isn't a bad goal. But when you're investing thousands of dollars (when you count salaries, travel, venue, and opportunity cost), you deserve better ROI than "people enjoyed themselves."

What better actually looks like

Better gatherings accomplish three things simultaneously:

1. Real strategic work gets done (decisions made, priorities clarified, stuck conversations unstuck)
2. Deep connections form through tackling those challenges together
3. Clear action plans emerge that people are still executing (or have completed) six months later

Notice I said "simultaneously." Not team bonding on day one and strategy on day two. Not fun activities in the morning and serious work in the afternoon. The connection happens THROUGH the strategic work. Trust builds when you tackle hard problems together in creative ways and offer people different, more meaningful ways to get to know one another. People leave knowing each other better AND with clarity on what's next.

This is what it looks like when you're asking the right questions during planning:

• What conversations have we been having for 6+ months without making progress?
• What decisions do we need to make that we keep putting off?
• Where do we lack alignment that's causing friction in our day-to-day work?
• What would be different about how we work together if this time was truly successful?
• What do people need to know, feel, and do differently after we're together?

How to actually get there

Stop asking your team what activities they want to do. Start asking yourself what outcomes you need to achieve.

Then work backwards:

1. What are the 2-3 most critical outcomes for this gathering? (Not 10 things. Pick the vital few.)
2. What conversations need to happen to achieve those outcomes?
3. What's preventing those conversations from happening effectively in our regular meetings?
4. How can we create the right conditions for breakthrough on these topics?
5. How do we ensure we're creating an agenda that flows and doesn't just exhaust people with multiple days of heavy or intense conversations?
6. What accountability structures will ensure the decisions we make actually stick?

And here's the thing - you might realize that designing this kind of experience requires expertise you don't have. You can do AN activity. But sequencing 15+ interconnected activities so each builds momentum toward your goals? Facilitating real-time when someone opposes every idea? Navigating power dynamics so all voices are heard? Turning discussions into decisions with real accountability? That's not something you figure out on a Slack thread two weeks before your gathering.

The real question

The next time you're planning a team gathering, ask yourself: Am I planning a birthday party or a business transformation?

If the honest answer is birthday party, that's fine - but own it. Don't expect it to solve your strategic challenges or create lasting change.

But if you actually need business outcomes, if you have real challenges that need solving, if you want your team to be different after this time together - then you need to approach it differently. You need to set your expectations higher. You need to invest in making it actually worth the time and money you're spending.

Your team deserves better than "fine." Your business deserves better than "good enough." And you deserve to walk away from a gathering knowing that something real has shifted, not just hoping it made a difference.

Ready to plan a gathering that actually produces lasting change? Book a free consultation call with me today. I'll help you identify what outcomes you really need and design an experience that delivers them - not just another "fine" gathering that everyone forgets about by next quarter.

This final post will cover the last group affected by reorgs... the individual contributors.

Often, individual contributors end up getting lost in the shuffle when a reorg happens. Here's what I see:

1. The reorg deciders (this can happen at the C-Suite level, or lower, depending on the size of your company) have had months to look at options, map out different scenarios, think through what works best, and socialize this with one another.
2. The direct reports of those folks are looped in. Usually a few weeks to a few days before the reorganization, so that they have time to wrap their heads around what will happen, align on the messaging, and get on the same page about any working agreements, teams, or processes that may need to change as a result.
3. Individuals are informed through wide-reaching and then subsequent communications that announces the plan, what's changing, resulting organization structure, and why.

Now, don't get me wrong. I actually think this is the right approach. I don't think reorgs should be decided through committee or we should strive for consensus when doing this. For many reasons, it's best when this decision comes from an individual who has solicited feedback from various levels about the new plan, not in the least because individuals have different appetites for change. Some would be fine with a new team or reorg every week. Others get stressed when it happens once a year.

But where I think many places go wrong is expecting this announcement to be a quick blip in the workday and then expecting everyone to get right back to work, without any productivity loss, as if nothing happened. At the very least, people need a little bit of time to process to figure out what it means for them and if there are any changes that are impacting them and their work. So here are a few suggestions, that can be executed at any level, to help make reorgs more palatable for your group and hopefully both allow for and diminish the productivity loss through these announcements.

Ensure the 'why' is there

I've seen varying degrees of effective high-level communications. Sometimes, these are excellent and other times they leave a lot to be desired. Additionally, depending on how much trust there is in leadership levels (or how many layers there are between individuals), the whys that are stated may need to be additionally reinforced. Make sure to provide this information to your subgroup. I'll give a couple of scenario examples:

1. Communications come from a CEO and there are 4-6 layers of managers between the CEO and individuals. If your group is more than a skip level away from whomever the communications are coming from, you should reinforce either with the same or more nuanced messaging specifically for your group(s).
2. Communications from a CEO that is only 2-3 layers of managers in between but there's a lack of trust, or the communications feel very broad and the why isn't super relatable for your subsegment. Here, you also want to provide additional communications and messaging for your group so that they aren't left guessing or filling in those blanks for themselves.

For any messaging about the why, you want to make sure it's aligned with the overall message, is as specific as possible, and reassuring. You're likely not going to win over everyone, but hopefully for the folks in that mushy middle, many of them feel better once seeing both overarching communications and messaging from you.

Help people clearly understand what is and isn't changing for them

I've said this before and I'll say it again, in the absence of a story, people will create their own. Oftentimes, that wider-reaching messaging is meant to be broad and not specific. What it means is that the more specific you get from company to department to multiple teams to single team, it doesn't feel specific enough. Some things you want to make sure to answer specifically...

• Is my day to day work changing at all?
• Are the people I work with changing at all?
• Are the expectation for me and the role I'm in changing at all?
• Is the way I do my work changing?
• Is there a new team or department mission? Beyond that, if some of this is unsure, make sure to say that and provide what answers still need to be figured out and by when (ideally) there will be some answers around any changes rolling out.

Help people rightsize the change by having a little fun with it

During periods of high growth, or high contraction, reorgs are going to be more frequent, because people are being given growth opportunities and/or it doesn't always make sense to backfill every individual. When this happens, the reorg fatigue is real and can become very disenchanting for folks. The "why" doesn't matter as much when it's happening so often and it can feel like there's constant change happening without any ability to restabilize. Sometimes, this is true, but more often than not, even though team names, structures, or other aspects may change, the actual work that's being done, processes people work with, and more, aren't actually changing that much. My goal is always to help people try to see some positives in the reorgs and also understand that maybe it's not such a big deal.

I was at one company where someone made a "reorg playlist" and whenever a reorg was announced, that playlist was posted and played. One of my favorite things to do is toss a few fun questions about change into Slack throughout the day. Things like: What's your most versatile piece of clothing? Or what's the piece of furniture in your house that has moved around the most? What's your favorite song about movement or change? Any of these can be fun ways to both recognize that people are probably less productive and having more Slack conversations day-of while also adding a bit of fun and levity to these announcements. Now, of course, one warning, when I'm talking about these fun messages, I'm referring to specific reorg announcements. If your company is announcing massive layoffs and there's a reorg announcement coupled with that, please don't try to ask fun Slack questions in that scenario.


Good luck if you're in the middle of a reorg! And if you're not, keep these in your back pocket for when you are, because it's probably just a matter of time.

Going through a reorg and realizing that what your group really needs is time together to make decisions and just get to know each other better? Have an intro conversation with me today about designing and facilitating your next gathering. You won't regret it! Book a free chat.

In a reorg, the leader shifting roles and the individuals on the ground get thought about a lot. How should we communicate this? How will people feel about these changes? What is the leader at the top-level of this reorg looking for? Frequently, however, middle management gets overlooked. Here, I'll define middle management as any manager in between the top-level individual taking over new teams/groups and the individual contributors. These managers are often given information in a haphazard way, when plans, goals, and timelines are usually only partially thought-through and decided.

These individuals quickly shift into understanding what this means for the people reporting to them but not for them specifically. They skip over that part and then succeed or fail under their new manager not because of strategic and purposeful planning and decisions but as a matter of coincidence. Let's talk about 5 things you should do when you've been reorged under a new manager to be successful.

1. Understand who you new manager is as a leader

This is often a suggestion I make because it really affects how you as a manager can be effective with others. What makes them tick? What are they optimizing for? What kinds of things are important to them? Understanding these fundamentals will help you adapt your communication style and priorities to align with theirs (or understand where alignment might take longer), but it goes deeper than that.

You'll want to find out or ask about how they prefer to receive information. Do they like detailed written updates or quick bullet points? Chat app messages or a doc? Deck or a 1-pager? What kinds of information do they like to receive, and equally important, what do they not need to know about? How do they perceive success, both for themselves and for the people reporting to them? These insights will shape every interaction you have moving forward and help you position yourself as someone who makes their job easier rather than harder.

2. Assume a deep dive into your area

Here's the reality: your new manager is going to want to understand what you do, how you do it, and what's currently happening in your space. You should be prepared for this conversation, and you should approach it strategically.

Start by thinking about everything you want to make sure to communicate to them, and then here's the hard part – slim it down to 1/3rd of those things. This individual is going to be coming into information overload from multiple areas, not just yours. You want to make sure they know and remember the primary 3-5 points you want them to walk away with. Of course there's a whole lot more, and there's time for that later, but prioritize ruthlessly.

Focus on your biggest blockers – what's preventing your team from being more effective? What are you MOST hoping for them to do or help you with? What have you been trying to advocate for or push through for a while that maybe now, with new leadership, might have a chance? Are there any people reporting to you or any projects that you truly want to highlight because they're either doing exceptionally well or need immediate attention? Come to them also not just with problems, but also with ideas. Offering something like, here is something that is a blocker or concern for us and here's what I think would help make it better. Remember, this is your chance to set the narrative about your area, so make it count.

3. Help them get to know you and your style

While you're learning about them, don't forget that this relationship is bidirectional. Your new manager needs to understand how you work best, what your management philosophy is, and what you need to be successful. Give them a little overview into how you run things – are you hands-on or do you prefer to delegate? How do you like to communicate with your team? What does your decision-making process look like?

Be honest about your pet peeves and the things that really matter to you. Maybe you're particular about how information flows to your team, or perhaps you have strong feelings about meeting cadences. What information do you need when showing up for a meeting where you're presenting? Whatever it is, surface it now so your manager is aware. This loops back to item 1, where if you know these things about them and they know these things about you, you can often figure out where you might have points of friction and where together you'll compliment each other effectively. The goal is to find your working rhythm as quickly as possible.

4. Provide additional reading

Here's something I've observed time and time again: companies and organizations often work the same way... hurry up and wait. What do I mean by this? I mean you should always be ready with the next 5 things you would do if you suddenly got the bandwidth or approval to do so.

Something I often see, for example, are managers or leaders talking about needing headcount or to hire additional folks. They ask and ask and ask for a while, never getting approval. Then, one day, their boss gives them the approval and all of a sudden, they have to think about a job description, how to hire that person, what the interview process should look like, etc. They're scrambling because they weren't prepared for the "yes."

Now, of course you don't want to over-optimize and spend all your time on initiatives that won't see the light of day, but you want to have some groundwork laid for that sudden yes. Who would you hire and why? What strategic initiatives would you kick off and why? What processes would you implement or change? Having these thought through, even at a high level, positions you as someone who's strategic and forward-thinking.

This ties directly back to your area deep dive in number 2. You want to have your new manager walk away with key points from your initial conversation, but you also want to have the documents, key points, and decisions outlined in a clear and concise way so that if you're asked for more details or your manager wants to dig deeper, you can quickly and easily pass additional information along to them. Being prepared shows that you're thinking ahead and that you're someone they can rely on.

5. Build relationships with your peers

Often a move to a new manager also comes with a new peer group, and this shift is just as important as your relationship with your new boss. Just as important as understanding how your new manager works and what they care about, you need to get curious about your new peer group. These are the people you'll be collaborating with, potentially competing with for resources, and hopefully supporting as you all navigate this transition together.

What are the top things on their mind right now? How do they like to work – are they collaborative or do they prefer to work independently and sync up periodically? How do they view their peer team versus the folks that report to them? What is that balance for them between supporting their direct reports and supporting their peers? Understanding these dynamics will help you figure out how to be most effective in this new structure and how to build the alliances that will help you and your team succeed.

The reality is that reorgs happen fast, and middle managers often get caught in the shuffle. By being proactive about these five areas, you can set yourself up for success under new leadership instead of leaving it to chance. Remember, your new manager is likely dealing with a lot of change too, so making their job easier by being prepared and clear about your area will go a long way toward building a strong working relationship.

Stay tuned for part 3, where we'll dive into how to make re-orgs easier for individuals across the organization.

Looking to up your management game this year and become the leader everyone looks to? Book 1:1 time with me to help you get there.

We've all seen a thousand of them.

The women's leadership retreats that focus on how busy women are. We balance so much. There's so much mental load. We do all the work things, then we come home and do all the house things, and then you add the kid things on top of that. Often women's leadership retreats are promoted as a chance to take a breaks and for self-care.

Or you have leadership retreats. Experiences that are meant to put you in the room with other peer leaders. There are many of these too. Learn X framework, meet others, talk shop, and more.

These are great. And they all serve a purpose. AND most people know that the best part of these experiences is the hallway track. It's those people you happen to meet. Did you sit at a good table for that one dinner? Were you stuck in the bathroom line with someone who you really vibed with and exchanged business cards? It's happenstance. It's serendipitous. And it's the reason people sign up for these kinds of experiences.

But what if the serendipity was intentional? What if instead of having 5 minutes to chat about who you are and what you do in the bathroom line, you had 50 minutes to understand more about where and how your lives and experiences intersect and how to leverage that in a meaningful, non-transactional way.

I hate calling Extraordinary Machines a "Women's Leadership Retreat". Because those words are so loaded, and the space is so crowded, and there are so many assumptions about what that kind of thing is.

It'll be different, because it's what is needed by so many women looking for that mix of personal development, professional development, and camaraderie. But enough about Extraordinary Machines and how amazing it will be (hey you, have you signed up yet?!?! You gotta to it before October 1st).

Let's zoom out a little bit. Thinking about your next professional development experience, how to convince your manager or company to pay for it, or thinking about planning something? Out of hundreds of professional development sessions, conferences, and experiences, what makes a really good one?

1. The Right People

There are a variety of ways in which organizers get the right people into the right room. I know we live in a world of AI, but I'm hesitant to say that an algorithm can make this magic happen (although it can potentially be a start). There's a human touch here that is super important. I often think about this in the same way that I think about putting teams together, hiring, or creating effective smaller groups of people. It's a puzzle, where some of the pieces are obvious, and some are a little more challenging. Every puzzle piece belongs to a puzzle, and every puzzle needs all it's pieces to be complete. This can often be done through a recommendations-base or vetted network (for example, needing to be recommended by someone who's in the network or has done the experience in the past), in addition to some sort of application or conversation.

2. The Right Opportunities to Actually Meet Those People

Ok, I feel like if you've been following this blog for any period of time this is one of the things that I post about the most. A gathering is NOT just about putting people in a room (even on the surface, it seems like that's all that's been done). It's about giving people opportunities, easy ins, and fun ways to actually get to know each other. Think about it this way... a handful of times a day someone asks you how you're doing. And most often, people respond with "I'm good" or "I'm fine" even if they're great! or awful! It's because most times people don't actually want to, or feel comfortable enough, giving the real answer. And that one time a day or week where you can actually, really, truly tell someone how you're doing, it feels so refreshing.

3. Content That Makes You Think or See Something In a Different Way

Let's not fool ourselves, we also go to these experiences to learn something. Maybe that's learning about something practical and tangible, or maybe it's learning something about ourselves that feels like a lightbulb moment. When you are presented with new knowledge or understanding of something, a new viewpoint or lens, that leaves you continuing to think about it beyond that session, that's gold.

4. Having Something You Can Immediately Put Into Action

Yes, the above-mentioned perspective shift or idea that you're left with is important, but, just as important is to have something you can actually do within a few days. I have notebooks upon notebooks upon notebooks of notes and information. And I'll refer to them, but in order to feel productive and really give me some momentum post-travel and settling back into my routine, I need to be able to quickly and easily take action on something.

5. That Just Right Feeling

Yes, I'm always looking for that Goldie Locks moment. These experiences can feel too advanced, or too basic, but what's just right? I often recommend one of the best ways to spend your money is with coaching but that leaves you without the people and camaraderie. If you can put one through four together, then it's likely to hit all those high-points that help people walk away with that "just right" feeling.

I'm building the experience I wish existed. The room I want to be in and that I want to share with you. If you've been looking for that same room, maybe we should talk. Book a quick chat with me today.

These opportunities can be exciting but also daunting. You're not new to the company and so you don't get that same "I'm new here" grace or as much time and space to learn. You're expected to understand what needs to happen and act quickly communicating up, down, and around with expertise and care. To add to it, rarely when there's a reorg, is it completely business as usual. Accompanying these reorganization decisions is often the need for new or updated processes, changing mandates, or clarifying expectations.

Here are five things to look for when overseeing a new department or area.

1. Goals

   You can tell a lot about a team or department by what their goals are (or if they had any goals). These don't necessarily have to be formal OKRs or KPIs. Maybe these goals are written somewhere and checked in on regularly, maybe they're just scribbled somewhere. Maybe there are department goals, or maybe goals are just set team by team. All of this information tells you a lot about where the department and teams are. Some additional questions to ask are:

   • How the goals are set (bottom-up? top-down? a mix of both?)
   • Once goals are set, how often are they checked on? How do people show the status or progress towards goals? And is that only transparent for the group leaders or is it communicated somehow to individuals as well?
   • Once goals are set, how often are they changed or stuck to? How frequently do the goals set become irrelevant because new priorities came in?
   • What did the group actually achieve in the past few quarters? This is less about saying if a group is "bad" or "good" but just understanding what gets written down vs. what actually gets accomplished (we all know that's frequently different) and what were some of the reasons for delays or issues along the way (because there are ALWAYS some delays or issues... again, not necessarily a bad thing, but important to understand what those were and how visible they were/how they were communicated, if at all)
     

2. Team Effectiveness

   To summarize this... are the right people in the right seats? And where are the growth opportunities for individuals. Real talk - not everyone is always in the right seat, and sometimes a new leader needs to come in with an outside perspective to ask different or new questions and understand the state of things. I'm always one to try to work with individuals, provide feedback, and help them grow in the right ways, but sometimes there is just a mismatch of skills and ability, or a career desire mismatch where what the group needs from someone doesn't align with what they want to do with their career.

   These are rarely blatant. It's looking for things like is there a team or group that is completely misaligned with the rest of the company? Is there a manager or leader who is in super protective mode as opposed to really providing the feedback their group needs? And if so, where does this stem from? Is it from the individual? or is the individual manager operating with past baggage or how they felt they had to operate under a previous leader based on that leader's potentially non-optimal leadership style?

3. Alignment and Clarity

   Alignment and clarity are really about understanding how this group's work fits in with the bigger picture. Is the team clear on why they're doing something? Do they know how their work contributes to what the company as a whole is trying to do (which honestly may or may not be connected to the company goals. In an ideal world, there's a clear connection, but it isn't always there)? Do all the teams in the department understand how/if their goals relate to one another and fit within the larger department?

   It's easy in larger organizations (and even sometimes in smaller ones) to operate in a silo - to be very clear on what their team is doing but have no sense of adjacent teams, departments, or individuals (in smaller companies) goals and how it all fits together. If there isn't clarity or even awareness, it's a clear spot where you as a new leader can provide those connections and start creating that connective tissue with other areas.

4. Barriers

   Ok, you might not get this right away depending on what trust needs to be built and the circumstances of the reorg but understanding where people think the barriers are is such an interesting conversation to have when you're walking into somewhere new. Now, these barriers might be problems or might not be. They also might not be the actual barriers but it's always interesting to understand the perception here of individuals in different areas and different teams. Basically, what do people think is holding them back from whatever it is. It could be holding them back from being a high-performing team, from accomplishing goals, from communicating effectively, from having the culture they want... all sorts of different barriers might be present. The goal here is just to listen and then see where there are patterns or places you want to explore further.

5. Culture and Communication

   It's common for assumptions about areas of a company or organization to be around talent, who is in what role and if they're able to execute on their role and responsibilities. AND, it's very possible that some things need to change there (see item 2), but I've found that more often than not, understanding the culture and communication that is happening in a department, in teams, or between all of the above, is incredibly telling.

   Now, this bucket is HUGE. Some of the key things I try to hone in on are:

   • What is the mood? If you were to describe how people feel about the department (or if you ask them), what are the 3 words they use?
   • How do people interact with each other? And are there differences between written communication (slack or chat app) and verbal (in meetings, for example)?
   • Do people depend on each other? What's the level of perceived trust and reliability on each other (either within a team or between teams)
   • What communication seems to be happening "up" and "down"? In other news, how is a manager or individual managing up and what information comes to you as the person who they're reporting to and just as important, how is information getting to the team? When you talk to the team, does it seem like they're hearing the messages you're conveying to their manager that you're assuming is being amplified? or does it seem like they're not getting that message for whatever reason? This communication could be through formal OR informal structures (which is also interesting to notice)

Here's what I commonly see after a re-organization...

• A top down message for the department from you, as the new leader
• A deep dive from the leader with each area they're taking over
• Showing up to a variety of meetings
• Potentially skip levels or small group conversations that are mostly a listening tour
• Talking about coming up with a new strategy or plan (sometimes even with an associated goal timeline)

Here's what I don't see as often... Actually getting people together to make this progress. Note - I didn't put many qualifiers on this statement. Is it getting people together virtually vs. in person? Is it the whole group or just the leadership? Really any of these is better than what currently happens.

One of the most overlooked opportunities when taking on a new department is bringing people together. As a leader, this gives you the chance to set the tone, meet everyone face-to-face, and most importantly, make real progress on key initiatives that will move your teams forward. Whether it's the entire department or just the leadership team, a well-designed gathering can set the foundation for the incredible work ahead. Of course, you want this time to be useful, valuable, and memorable—which is where thoughtful design and facilitation become essential to striking the right balance.

Now, of course you want this gathering to be good (and, shameless plug, this is where a professional comes into play and can be very helpful), so here are some suggestions about what to do with that time:

1. Helping the team get to know one another. Not through a happy hour or "field trip" (although an experience together can be excellent, if it's been thought through and isn't just branded as "team bonding" that doesn't actually bond the team). This doesn't have to be fancy or expensive. It needs to be meaningful. It needs to actually spark new and interesting conversations, and it needs to build trust.
2. Identify what the group considers as pain points or places where there can be more efficiency. The best way to do this depends on a handful of different factors apparent within the team, but bringing to the surface these issues and then providing space and time to talk about them in a constructive way helps lay the groundwork for how this first team will work together in the future.
3. Dream a little bit. It's exciting to get a new group together, even if the circumstances of the reorg were based on constraints or other company issues. Now, you don't want to do a full blue-sky brainstorm if you can't actually take action on any of that, but there are great ways to frame these kinds of sessions so they're still inspirational and energizing while not making empty promises.

That right there is probably 2 full days of time together, which gives you plenty to work with.

Stay tuned for parts 2 and 3 of this reorgs series -
Part 2: How to adjust and operate if you're reporting to a new manager
Part 3: How to make re-orgs easier for individuals

If you're looking for someone to run your gathering so you can focus on participating instead of running the sessions, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you GSD to set the right foundation with your new team.

Often, in the fall, companies have the opportunity to do this in person at a company offsite. Other times, it's remote, but i'm here to say... please make it memorable and engaging. Your staff is tired of looking at a bunch of slides that they have to learn about, process, and respond to within 30 minutes.

Usually, when I say this, I get a variety of responses:

• People like this format. I always get good responses to it. Unsurprisingly, people don't want to tell the CEO, Executive Director, or someone likely multiple steps above them hierarchically that the information they conveyed wasn't done so in an optimal way.

• This is what people are used to. They would get confused if we did it a different way. This is a risk, and it definitely involves more time and planning to get it right but if it's planning effectively, then you minimize this risk. Plus, when was "we've always done it this way" the best reason to contunue doing anything the same?!

• But how can we do this differently? We have a lot of information to get through. It's hard to think about how to get through as much information but there are lots of interesting ideas. There's also sometimes a question of what information does everyone need to know and then beyond that, doing an optional session for folks who want to know more or get into the weeds on certain things.

• I don't have the time to think about a different way of facilitating this information. Hi. My name is Allison :-) But in all seriousness, this is where outside resources can be helpful. You can talk about what information you want to convey, how you've conveyed it in the past, and then work together to convey the information differently and have a better, deeper conversation (either structured with or facilitated by someone outside of the organization)

So, what does this look like in reality? Here are a few ideas (that probably won't exactly for your organization, but give a basis that you can make some small tweaks and changes to)

1. Pre-recording and pre-collecting questions - this enables individuals to actually process and think about the information in advance. My recommendation is to send this at least a week in advance so people can fit it into their schedules. And still keep the time tight... just because you're pre-recording, doesn't mean you should create 40 minutes of content instead of 20.
2. segments - do a segment and then breakout rooms with something to DO, not just a question to discuss. For example, this can be an open question where you want ideas from people, or writing down what work they know of that maps to these focus items, or have them outline the top 3 things they're excited for and where they think the risks are of the plan.
3. stations around a room (think about this like museum exhibits and everyone gets to walk around and learn at their own pace). This allows more of your leadership team to get involved as well. They could be presenting facts or information, graphs, short clips from customers, and individuals can ask questions focused in the areas they know less about and spend more time at those stations than the ones for their specific teams.
4. A more off-the-wall idea - Sending out the information in advance, then coming in and doing smaller group discussions, and having a couple of people volunteer to do slideshow karaoke (15 pre-determined slides, advancing automatically every 15 seconds) with their content based on the state of the company information. It's bound to be memorable.

For those who know me, you'll laugh at this opening because many tell me I'm one of the most productive people they've ever met. And it's true! I utilize every minute of every day. My to-do list is immaculately organized into days, subcategories, big things, small things, and a "most important" section. I love systems that streamline my work and maximize what I can accomplish.

And yet, I've had this nagging feeling, really since COVID started, that we're so focused on productivity that it's become unproductive. We're trapped in a paradox where our pursuit of efficiency is actually making us less efficient.

The Burnout Behind the Numbers

The statistics paint a stark picture. Despite all our productivity tools and optimizations, 67% of workers believe burnout worsened during the pandemic, and 69% of remote employees are experiencing burnout symptoms. Is it possible that in an attempt to optimize ourselves and make ourselves the most efficient versions we can be, that we are accidentally burning ourselves out faster? Over half of remote employees report working more hours than they did in the office, with 31% working "much more" than before the pandemic. Counteract this with the stories we hear of people holding multiple jobs at once and bragging about working in their PJs or half-heartedly from bed. It's almost as if we're trying to prove we're not those people, that we're the ones who are actually productive, even if it means working ourselves too hard.

We all have bad days and good days, but somewhere along the line, the bad days became less acceptable, even just to ourselves.

How AI Adds to the Problem (while being a believer in its potential)

Then came the latest productivity panacea: artificial intelligence. The claims are breathtaking. McKinsey research suggests generative AI could add $2.6 trillion to $4.4 trillion annually to the global economy, and 64% of businesses expect that adopting AI will significantly impact productivity growth. Some studies show AI improving employee productivity by 66% on average, with claims reaching as high as 126% improvement for programmers using AI tools.

But here's where the productivity paradox reveals itself most clearly: 77% of employees say AI tools are doing the opposite of what's expected, actually adding to their workload, and 47% report not understanding how to achieve the expected productivity levels with AI.

I see this in my own work. AI certainly makes me more productive for some tasks - it helped edit this very blog post and answered at least a dozen random questions today. But it also took significant time to set up properly, over the course of months and experimenting with many of the new tools coming out every week. For some workflows, the initial investment was worth it. For others, I've definitely fallen into the sunk cost fallacy, wasting time thinking I could optimize something that didn't need optimizing.

The Optimization Trap

This is the heart of our productivity problem: we're spending so much time trying to be productive that we're not actually productive. We optimize our systems, download new apps, read productivity books, and reorganize our workflows - all in service of being more efficient. But these meta-productivity activities often consume more time than the actual productivity gains they provide.

First, it was about proving we could be productive working from home. 81% of remote workers check email outside of work hours, including 63% on weekends and 34% on vacations, hardly the picture of improved work-life balance productivity was supposed to deliver.

When that productivity started to wane (or was perceived to wane), we saw calls for return-to-office mandates, with leaders citing productivity concerns. Yet Bureau of Labor Statistics research finds "little relationship between labor productivity and the ability of workers in an industry to work entirely remotely".

The Science of Strategic Slowing Down

Here's what's particularly interesting: there are decades of research showing that breaks, rest, and unproductive time are essential for actual productivity and creativity. A study published in the Journal of Applied Behavior Analysis found that 75% of students were substantially more productive during sessions with planned breaks. More than 85% of employees believe taking regular breaks would boost their productivity, yet more than one-quarter of workers don't take any break aside from lunch. There are proven systems like pomodoro set up to encourage breaks and yet we still work through them or question their value.

The research is overwhelming: rest breaks do not impact adversely upon productivity, and when coupled with health-promoting practices, can contribute to a paradigm shift for workplace culture. Taking effective breaks in the workplace has been associated with benefits to wellbeing and productivity in several roles. Studies show deliberate rest can boost productivity by 15% and improve work satisfaction by 37%.

Yet despite this mountain of evidence, every conversation, every tool, every minute feels like it needs to be productive. Unproductive time leads to guilt, pressure to make up hours, and more stress—which, ironically, makes us less productive.

Breaking the Productivity Paradox

Workplace stress inflicts an annual cost of around $300 billion on the U.S. economy, yet we continue to optimize for the appearance of productivity rather than actual results. We're measuring the wrong things and optimizing for the wrong outcomes.

The most productive teams I've worked with, and the research backs this up, aren't the ones with the most sophisticated productivity systems or the longest working hours. They're the ones that focus on outcomes rather than activities.

Maybe the real productivity hack isn't another app or optimization technique. Maybe it's figuring out what helpful unproductivity looks like for each of us personally.

Because in our quest to optimize every moment, we might just be optimizing ourselves out of the very creativity and sustainability that true productivity requires.

The irony is fascinating: to be more productive, we might need to care a little less about being productive.

Probably most of us have had that direct report (or BEEN that direct report) who just doens't connect with having to write goals. Why spend the time? What is it for? They don't find it motivating at all. And it's relegated to a silly HR checkbox that has to be checked.

So if this is happening everywhere, what's the point?

The biggest hurdle in effective goal setting isn't the mechanics of writing SMART objectives or creating detailed action plans. It's getting people to genuinely care about the goals they're setting. Without emotional investment, goals become nothing more than bureaucratic exercises or forgotten items on a to-do list.

Three Approaches That Actually Work

1. Understand Each Person's Relationship with Goals

Start by exploring how people naturally think about achievements. This is about meeting them where they are, not where some management book says they should be. Ask questions like:

• Do you set personal goals, or just professional ones?
• Are you someone who works steadily toward milestones, or do you tend to hyperfocus on things until they lose their appeal?
• Can you think of a goal you accomplished in the last six months? What was your process?

These questions help people understand their own goal-setting patterns and allow you to tailor an approach that works with, not against, their natural tendencies.

This conversation can be revelatory for many people. Helping them recognize what goals they actually DO set, even if not explicitly, helps them realize how they naturally break down tasks and things they want to accomplish every day. Maybe they're someone who plans elaborate vacations by researching and organizing every detail, or even just committed to cooking more often and how they accomplished that task. These patterns reveal how they naturally approach accomplishing things.

2. Create a Future Story One of my favorite approaches is asking, "What's the story you want to tell about yourself a year from now?" This flips the common "letter to your younger self" exercise (which I personally don't really like) by putting people in their future seat. What would your future self want to say you accomplished this year?

For me personally, I really relate to the vision board style of this exercise — what do I want my year to look like? What words or images jump out at me when I'm looking through magazines? What am I trying to avoid? This process helps me turn visuals into concrete thoughts about what I want to achieve and how I might do that.

This approach works beautifully because it taps into a personal narrative and identity that feel more "me" and more compelling. (Hot tip, because I'm always talking about how to facilitate conversations effectively, vision-boarding is an awesome group workshop activity that can be done using physical OR virtual boards.) The conversations that emerge and what people realize about their goals for the upcoming year are often better (and easier to translate in to words) than what comes from traditional goal-setting exercises.

3. Break It Down to Build Momentum Once someone has identified meaningful goals (starting small with just 1-2 things), help them break these down into manageable steps that match their working style. The right breakdown feels achievable rather than overwhelming, making it less likely they'll abandon the goal midway. Draft a dew of these smaller items and then ask - when you look at these steps, do they feel exciting to tackle or do you start thinking of everything else on your to do list you could do instead of these steps? It's a great gut-check.

Making Goals Matter

A common pitfall I've observed is that people often pick a goal of accomplishing a specific project, but they actually have no control over whether that project gets prioritized or if the scope changes dramatically. It's really important to think about what you can do that's within your control and also the WHY behind it. Why does learning a particular skill seem interesting? What will it enable you to do?

The true test of effective goal setting isn't how well the goals align with some prescribed format — it's whether people naturally reference and work toward them without being prompted. When team members start mentioning their goals in one-on-ones unprompted, or when they excitedly share progress updates, that's when you know you've helped create goals that actually matter to them.

When we reimagine goal setting not as an administrative requirement but as creating the story we want to tell, the process moves from obligation to opportunity. The secret isn't in the framework—it's in connecting goals to what actually matters to each person.

As a leader of any company, organization, or department, one of the most important skills to learn is about what to communicate, when to communicate, and how to communicate (I know, I'm not telling you anything new here). This becomes increasingly complex because at every stage of leadership, it changes pretty dramatically based on what the group is optimizing for.

A helpful exercise to start with is who are you writing for (pick 1 audience), what information is important to them, and what level of granularity do they need. When communicating up or out, even though it's opposed to what most studies state, many of us provide _too_ many details because we feel more information is critical to get our points, progress, or problems across to the reader.

Here's a broad generalization of that exercise that you can use as a starter

For your peer team at a leadership level
Context needed: what problem is the work related to
Impact on them: what will the impact be on the company or organization as a whole
What information they need: what dependencies or needs do you have from their (or other) teams.

For your manager (this could be a board president or CEO)
Context needed: risks and general understanding of progress
Impact on them: How these risks might change priorities or plans that have been communicated previously
What information they need: how concerned or not concerned they need to be

For your team
Context needed: How their work fits in with other teams and the greater
Impact on them: what will the impact be on the company or organization as a whole? What do I need to do support-wise, resources-wise, or decisions-wise?
What information they need: what dependencies or needs do you have from their (or other) teams.

Let's focus in on thinking through your manager at the executive level... in these communications, everyone is optimizing for time. This might sound silly, but focus on less words that mean more and are easily digestible in a glance. What do I need to do as the person reciving this update?

As you can see even from the brief mapping above, executive level communication should be more succint, concrete, and focused over some of the additional details, context, and information you may want to provide to your department or team. Now, this doesn't mean this is all the information YOU have. You present the absolute most important pieces of information. If you're presenting a new idea or initiative, it should be framed with a clear impact on the company or organization as a whole and framed in a way that focuses on what your CEO or Executive Director (or Board President in some circumstances) cares about. For example, we will move from X to Y by doing this.

If you're providing a status update, keep it clear and actionable (see the template below).

Now, your influence won't grow overnight, but gradually with more effective communications, your level of earned trust increases. You become a person who always has the information that's needed, has thought about metrics or company impact, and projects that get green-lit are thoughtfully managed with clear and productive updates (a special note: this doesn't mean every project has to be flawless, but there should be reasonable explanations and conversations around when work gets offtrack in order to get it back on track). Additionally, once how you communicate is more clear, you can focus on if you're pitching the right kinds of ideas because getting your projects, ideas, and initiatives prioritized has 2 parts... part 1: are you communicating the idea effectively? And part 2: does what you're communicating result in better/more company or organization-wide impact than the ideas and desires others are bringing to the table in the eyes of the company leader or leadership team?

Below are two templates you can use. One for mapping some details about who you're communicating with and the second for the actual update to provide.

Mapping Your Audience

Download PDF

Executive Communication Template

Download PDF

Trying to nail that communication? Book 1:1 time with me to help.

1. Engineers are asking for it
2. Product thinks it's a great idea
3. It's energizing, you can feel the excitement when ideas come up, when teams start working, and when groups are demo-ing at the end
4. People get to work with others they don't usually work with
5. It's relatively easy to organize. There are a few different approaches but they don't change that much and mostly the expectation is that engineers will self-organize effectively.

The intended outcome of this time together is a high performing team that encourages one another and, for business goals, realizes how quickly they can ship and iterate when they put their mind to it.

At the end, the entire department or company are cheering with a variety of emojis and excitement. They're in awe of this team that usually works behind the scenes, quietly shipping the work that moves the entire company forward. This is their time in the spotlight and they love it.

And yes, hackathons are great for vibes and feels in the moment but it doesn't actually accomplish some of the key goals of gatherings.

It doesn't actually bring people together and allow them to make meaningfully deeper connections that enable productive work and communication.

It doesn't actually energize people outside of that moment.

It doesn't actually make engineers think or motivate them to work faster and more iteratively when they put their mind to it.

It doesn't help the larger company understand more deeply what engineers care about as company employees or the difficulties they face every day.

And it actually frequently damages morale and expectations in unseen, unspoken, and undocumented ways.

At this point, I bet a lot of you are saying, Hey now. That's not fair. We get great feedback. People love it! They're always asking to do them again!

When this is the case, the goal is to dig into each of these reasons WHY you do a hackathon and ask why or how.

Why are engineers asking to do a hackathon? From my experience working with multiple teams, departments, and companies, it usually falls into 3 buckets.

Bucket 1: we don't know what else we would do that would be a better use of our time and please please don't make us do ice breakers or sit through a dozen presentations (which commonly seems like the only alternative).

Bucket 2: I don't have the ability/autonomy to work on great product ideas that I have. This is my chance to prove myself and if I do a great proof of concept/demo, then my idea will make it onto the product roadmap, will be prioritized, and we'll be able to ship it (which feels damn good, when you see something you thought of go into production and be used by real customers)!

Bucket 3: There so much tech debt, it's driving me crazy. Flaky tests, refactoring, migrations. If only I had a few days to tackle these items, I'd be able to make the codebase so much cleaner and easier to work in.

But if you dig deeper, what are the long-term outcomes?

How do hackathons actually help people connect? They don't. People might work with new folks to pitch an idea or break down tickets. Maybe they jump on something to pair together, but those moments are often few and far between when a group is trying to get something demo-able within a short period of time.

How do hackathons create sustaining energy that lasts beyond the hackathon? They don't. Here, there's a double-edged sword. Either hackathon work makes it into production when it isn't quite ready adding to the maintainability burden OR hackathon work never actually floats to the surface compared to other priorities and work-in-progress pull requests wither on the vine collecting merge conflict after merge conflict until it's decided that if that work happens, it'll just need to start from scratch anyway.

How do hackathons help engineers believe they can do work faster if they put their minds to something? They don't. However, a result of seeing what a team can produce in less than a week often leaves non-technical executives asking "why can't this be our every day velocity and rate of shipping?" which is both unreasonable and dangerous.

There are ways you can create deeper connections, talk about technical concerns and topics in a way that is exciting and energizing, and help convey expertise and contribution to the larger company and non-technical teammates, but a hackathon ain't it.

If you're eager to discover what an exceptional offsite, retreat, or gathering facilitation could look like for your group, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you create magical moments and get to GREAT. Whether you're seeking a complete overhaul of a traditional format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

To mindfully and meaningfully approach this emotional area of performance reviews and getting feedback, it’s important to first note some of the realities. Performance reviews are a fact of business, and frequently, when performance reviews aren’t in place, it’s even more difficult to understand a perspective that is different than your own about how your work, impact, and behaviors are being seen by others. Even individuals who work independently take moments to pause and reflect and ask for feedback from others around what is going well and what could be going better. An individual who doesn’t do this, regardless of company status, promotional desires, and a whole host of other factors, is just not going to grow and learn as much as those who are regularly reflecting, even if that reflection result is “I think I should keep doing a majority of what i’m currently doing.” Second, sometimes it is true, you may not have gotten great feedback (or even verbal feedback beyond what was written). Your manager might not see enough of what you do or really understand certain aspects of your role.

But here’s something that I always keep in mind, especially for feedback that I don’t agree with OR where I know there are a variety of contributing factors: Why am I getting this feedback? I often try to think about why I’m getting this feedback through 3 lenses… perception, reputation, and visibility. What does my manager think of the work I’m doing? Why might they think that way? What is my manager hearing? Why are they hearing that? What is my manager seeing? Why are they seeing that?

Perception - Perception is looking at how the work or individual is perceived. What does the manager think about the work they're seeing? Is that perception real? Or is it being influenced in some way? How could the work that's being done, conversations, or other interactions be perceived in different ways by different individuals?

Reputation - This is what your manager (or maybe others... remember from the first blog post, a review isn't only reviewed by a single manager, it is often discussed by other parties as well) might be hearing about you or your work. What's the reputation you think you have? Is it something you want to change (because it might not be, and that's ok!) It is common that individuals have reputations at organizations that either work for them or against them.

Visibility - What is the manager seeing? This becomes even more critical as you have managers with larger and larger scopes of responsibility themselves, or when your scope of responsibility grows. It becomes more difficult for you manager to track what you are doing, what progress you are making, and what your day-to-day looks like. In this scenario, you don't want to give them a play-by-play (especially the higher up your go) but you do want to find ways to provide visibility into the work you're accomplishing so they have a better overall view of it even outside of performance review times.

And now, what can I do with that information to help my manager better understand how I am executing in my role, why, and see if we’re aligned on that. After all, while I want to look good, a large part of what we do is making our manager look good or making the company look good. What are THEY optimizing for? What’s helpful for them in their role? These questions can be used whether your manager is the CEO all the way to a team manager.

Trying to reframe and not getting anywhere? Book 1:1 time with me to help.

People don't frequently think of the post-review review. This is another kind of self-review. It can be a lot to process all at once, and, as humans, we tend to focus on the critical feedback as opposed to the positive feedback we’ve heard. Often individuals in high-performing, high-expectations roles are always striving to do better, not necessarily for a promotion but to be seen as more competent, more capable, and therefore more successful in the challenges roles they take on.

First is the mindset that you go into reviews with. Yes, I might sound like an HR talking head for a moment and this line might feel very “corporate” to folks, but regardless of how performance reviews are used at your company, the true and desired goal is to be able to give individuals valuable feedback that help them succeed at the company. Now, does this play out perfectly and always feel that way at every company? Of course not, but trying to go into reviews with that attitude, and picking out the pieces of the review that resonate with that wavelength, can really go a long way.

Second, is how to process. I always start with give yourself some time. It is hard to give feedback effectively, and it is hard to receive critical feedback. This is why so many people go so long in their careers getting feedback like “just keep doing what you’re doing” or without getting feedback that truly allows them to grow, learn, and improve. When you’re getting feedback, try to take a beat. If you agree with it, great! Ask some clarifying questions and you’re ready to move on to the next step. If you don’t agree with it, or are confused by it, I encourage you to express the confusion or use a statement like “I’m processing this and I’m not sure how I feel about it. I need to think so that I can come back with better questions that will better help me understand where this feedback is coming from” (more on this in the next post). Oftentimes people land on “we agree to disagree” which is an ok place to land but of course not ideal from anyone’s perspective as likely similar feedback will continue surfacing as a result.

Third, and this is the trickiest, is determining what feedback you think is legitimate and not legitimate. We live in the real world and what that means is that people have conscious and unconscious biases. They also see some things and don’t see others. To be honest, they pay attention to some things and don’t pay attention to others until performance review time comes around. After using the processing language above, and before fully coming up with a plan, make a note of what feedback is easy for you to understand, process, and take action on, and what feedback feels more challenging. Not to tease the next post again, but in the interest of keeping this post a reasonable length, stay tuned for more on what to do with the feedback that feels challenging for you to process.

Fourth, use this information to come up with a plan. Hopefully you’ve received actionable feedback with good examples providing where your areas of growth are, but, let’s face it, the higher up you are and the more experience you get, the more likely it is that you’ll get vague or nebulous feedback and will need to figure out how to turn that into actionable feedback for yourself. Don’t try to tackle all the things at once. With your manager, or on your own, attempt to determine which piece of feedback is most impacting your success in your role or at the company and then take some time to figure out what you may be able to do about it. Is it more reading and research? Is it connecting with peers or a mentor on the topic? Is it something else? And by when do you want to do that? Once you have the feedback and you know what you want to do and by when, you can also use that timeline to try to measure the effectiveness of the actions you’re taking to improve in that area, either on your own or with your manager. Having a plan, continuing to look at it, and regularly reflecting on where you think you’ve made progress is the biggest takeaway to a performance review because so often we get the feedback, process it, and then put it down or keep it in the back of our minds without really regularly doing a self-check-in on it.

Notice that this post isn’t at all about giving feedback or having the performance review conversation. There are lots of posts and books about that, but I think what exists less is how to process and what happens as the recipient of a performance review.

If you’re trying to process your performance review but finding it challenging, book 1:1 time with me to help.

1. Think about the individual’s impact. Sometimes it can be easy to overly focus on code shipped (either by that individual or by a manager’s team) but what was the impact of what was shipped. Additionally, hopefully you company assess performance on more than just code shipped. Code shipped shouldn’t overshadow teamwork because one person shipping a lot of code doesn’t set a team or company up for success, so beyond shipped code, where else did the individual have an impact? Or where could they have more impact? This line of thinking is important for both individual contributors and managers at any level of a managerial role.
2. For reviewing people in management roles in particular, it’s important to look at multiple inputs. What is their team saying about them? What are their peers saying about them? Where and how is their impact felt multiple levels “below” and “above” them (putting in quotes because I hate the terms above and below, but it’s the easiest way to describe things if you’re picturing an org. chart). AND how can you contextualize that information with what you know is happening on a team. For example, a department lead or VP of Engineering looking at turning a team around may not have excellent reviews from the individuals in their reporting line but knowing what challenges they are facing and how they are overcoming those is critical.
3. Recognize your role in their success or failure. As an individual’s direct or indirect manager, frequently you have a role in what opportunities are offered to those folks. If you’re writing a review (or reviewing ones from your department) and it feels lackluster and when you go to provide constructive feedback to the individual but it feels inactionable, the correct next step is to look in the mirror. What can you delegate, what opportunities can you provide, or what opportunities should you be advocating for them to receive based on their opportunities for growth.

One hot tip (that might not help you now but will help you in the future!)... take 1:1 notes! Holding effective 1:1s regularly and taking notes during them is the most effective way to make writing performance reviews a whole lot easier than trying to remember all of the incredible things your direct reports have done over the past number of months.

Looking to up your management game this year and become the leader everyone looks to? Book 1:1 time with me to help you get there.

Just like a performance review written for you, your goal in writing a review for your manager is to help them become better. You want them to be the manager of your dreams and what you imagine effective management to look like. You want them to be better and do better, because we all always have critical growth areas. Without keeping this in mind, sometimes you may edge towards writing a review that reads “they should keep doing what they’re doing” or you might provide very vague feedback.

Writing a review for your manager can be tricky because you’re never totally sure how the information is used.

Here are some different approaches that your skip level (manager of your manager) might use:

• Copy and paste excerpts of reviews into their review of the manager
• Sharing the reviews directly with the manager (even if they are anonymous)
• Take concepts and ideas from the reviews to formulate their own review
• Disregard them completely

Each of these come with risks… for example if reviews are shared directly with the manager, even if they are anonymous, a manager might try to figure out who wrote what, which means people are less likely to provide specific feedback that could be important for the skip level manager to read or for your manager to receive.

Additionally, your skip level reading these reviews is synthesizing a lot of information… they have their own opinions, they are reading the manager’s self-assessment, likely looking at pulse or company survey results or additional metrics, and reading the reviews from the manager’s direct reports, which may present lots of different trends or information.

First, pick your battles. A performance review shouldn’t be a time to unload all of your complaints and concerns about your manager. Whether you’re having a lot of trouble with your manager or you only see small areas of improvement, a performance review is a time to focus on what are the specific areas they can improve on. Is there a specific area in the career ladder that you feel they’re struggling with? Is there a behavior or something you’ve noticed time and time again that is troublesome or causing issues on the team? Are there barriers that are preventing you or the team from performing to the best of their abilities? Those are really the key areas to focus on.

Second, know what your manager is optimizing for. If you think your manager is doing a great job, this is an awesome opportunity to leverage the skills they’re looking to highlight with their manager, or to get more opportunities to do higher impact work. Where does your manager want to grow? What are they looking for? There’s nothing wrong with understanding that and helping them get there or highlighting some of their accomplishments in that area.

Third, know what your skip level is optimizing for. If you’re looking for ways to connect with your skip level, this is a great reason to put a meeting on their calendar. You can ask them directly what is the most helpful for them to hear about in a review of the manager. And if you’re concerned about how they use the information, as mentioned above, you can ask them. Then you’re operating from a place of knowing as opposed to guessing.

Finally, if, when writing your review of your manager, you have a lot of concerns and feelings that come up, your skip level probably wants to hear about them. Instead of documenting everything in a performance review, it can be helpful to provide some key highlights or areas of improvement using language like “I wish”, “I hope”, or “it would be great if” and then set up a skip level meeting to elaborate on some of the items you wrote.

If you’re trying to write an effective review for your manager either to celebrate them or express concerns, book 1:1 time with me to help.

Let's start: Writing a good self-review

Performance review time can feel like a useless check-the-box exercise but writing reviews (including our own) provides critical information to a variety of audiences. First, let’s go through the audiences for your self-review, because there are some hidden ones you might not often think about.

• Yourself: Self-reviews can be a nice time to reflect on your accomplishments over the last handful of months. It can be challenging to take time to understand what you’re shipped or accomplished. This is a good way to think about both work that has been accomplished, as well as ways that you have elevated and empowered your team including those who report to you, those who are your peers, and those who you report to.
• Your manager: This one is the most obvious. Your manager should be reading your self review. They’ll use it to understand things you’ve accomplished that maybe they didn’t see as much and understand what you feel are your strongest accomplishments during the review period.
• Your manager’s peer leadership team: Most companies have a calibration process of some sort where peer teams talk about reviews and expectations to ensure alignment and that everyone is evaluating teams and individuals in the same way. Self-review highlights and manager reviews are frequently surfaced as ways to explain an individual’s performance or determine promotion readiness.
• C-suite leadership team or a level or two above your manager’s leadership team: This one depends a little bit on the size of your company. If you’re at a huge company, all performance reviews won’t go all the way to the C-Suite but they will still go a level or two above your manager’s peer leadership team.

The goal of a self-review in a performance review is to easily highlight and tell the story of the impact and behaviors you’ve exhibited during the performance review period. If you have specific career ladders or company values, this information should speak directly to those with honest assessments of what you’ve accomplished and where you’re hoping to grow. Finally, if you are reporting directly to the CEO or a C-Suite individual, your self-review is frequently for yourself. At that level, your role is not one where you get a lot of concrete feedback from someone who deeply knows your field, but writing a self-review can still be helpful in pinpointing what kind of help you need to seek out from your peers or mentors to continually improve.

How should you format your self-review?

Working with leaders and teams, I often see 2 types of self-reviews. One are teams and individuals who put a lot of pressure on themselves to formulate beautiful paragraphs that articulately explain exactly what was done in lengthy paragraphs. From these, it’s challenging to understand the highlights and exactly what happened and what the result was. The other are teams and individuals who simply will drop a ton of links. Your manager likely doesn't have enough time to click on all of these links and put together the story themselves. 2 approaches, same problem… information that does not make it easy for the reader/your manager to get the information they need. There is a balance between overthinking it and not really putting enough time in. Bullet points are ok (actually, for me as a manager, they are great!) as long as they have enough of the critical context i’m looking for.

For self-reviews, make sure to cover the “elevator pitch” of what was done and any necessary context. Was there a metric or measurable impact? Did you get feedback from peers? What results did you see as a result of the work you did? Instead of simply listing the things you did, think critically about why they were done and what your role was in making it successful.

The higher up you are in an organization, the more concise and specific your self-review should be so that your manager can easily consume the information and get a great picture of the fantastic work you’ve been doing. Remember, department leads, VPs, etc. will need to have a good sense of YOUR review, as well as everyone else’s to be able to advocate effectively. Your goal is to make that as easy as possible for them to do.

Feeling stuck? Try these tips:

• Interview a friend. As a friend or colleague about what sticks out to them about the work you’ve done during the review period. They don’t have to write it or make it robust, just whatever is on the top of their mind.
• Start with this template:
  • What 3 things am I most proud of?
  • What was my previous growth goal and how did I make progress on that?
  • What was something really challenging for me that I attempted to get better at?
  • I enabled my teammates by…
• Review 1:1 notes. If you take 1:1 notes, look through them to see what was shared, celebrated, or what feedback was given. It’ll give you a good place to start from.

Did this resonate but you're still feeling stuck? Book 1:1 time with me to be your hype woman and help you figure out what to highlight OR use your self-review to work with me to close those gaps that you've identified as areas of growth.

A key highlight of the work I've been doing and how I work with clients is focused on getting moving beyond the surface level. So much of our time is spent in a certain level with our work and our peers. We run from meeting to meeting, often trying to tick things off the to do list in between, without any time to really gather our thoughts and focus on our deeper goals.

That's what this workshop is for. On January 15, 2025 from 1:00-3:00pm eastern, we'll virtually dive into the topic of planning an effective gathering: from goals to actionable outcomes.

Register Today

This workshop will be capped at 20 participants so grab your spot today

This won't be any ordinary workshop (after all, my whole shtick is about providing experiences to individuals that are engaging and interesting without defining success as being extroverted). Through our 2 hours together, you'll pick a gathering you have coming up (or that you wish you had coming up) and really delve into what you want that gathering to accomplish and how to make that happen. It'll be hands-on, creative, and a unique experience. Instead of focusing solely on the logistics of gathering, we'll drive towards the content aspect to help you plan an incredible experience for your company or team.

Here are some highlights:

• Gathering and facilitation best practices and practical tips that anyone can put into action
• Interactive exercises (that won't make you wish you had your camera turned off)
• A deeper understanding of how gatherings drive positive outcomes (good for getting that budget request approved or further justifying the need for it)
• Sample agendas and activities
• Tools, tips, and tricks
• Small group peer networking (meet other amazing people who are also working on planning their gathering)
• Considerations for different teams, especially when working with individuals from STEM backgrounds
• Reusable worksheets and materials

and there might be a few additional goodies coming your way as well.

Make sure to grab your spot today! and if you're still unsure or have questions, feel free to schedule a quick 15 minute chat with me.

Logistics

• Budget what is your budget? Have you accounted for everything and added a bit more “just in case”?
• Travel: will folks be booking their own Travel or will someone be booking for them? Don’t forget to set a “book by” due date so that you’re not spending extra money on things like last minute flights.
• Accommodations: hotel block? Airbnb? Remote or in the middle of a city?
• Meeting location: While it’s tempting to have the meeting location at whatever hotel you are staying at, I frequently recommend to try to do it closeby but in a different location. This helps with a change of scenery and minimizing food and beverage minimums. The exception to this is if you have someone who needs a lactation room during a gathering. In this scenario, it may be easier to be in the primary hotel so that the individual(s) have easy access to their room and a comfortable place to pump.
• Food: will food come to the location? Provided by the meeting location? A certain amount provided for meals on their own? Delivery to the meeting location for lunches? Don’t forget to account for a variety of dietary restrictions and needs. Don’t forget about snacks and water!!
• Accessibility: What kinds of accessible needs to individuals need? This could be anything from a particular kind of chair, to knowing about breaks needed, to wheelchair accessibility. This is helpful to know not just for the travel, accommodations, and meeting space, but also for any groups meals or outings you may be planning.

Suggestions for logistics:

• Have people send you or post into a central form their flight information or where they’re staying. This helps for coordinating rides to and from the airport.
• Have people fill out a form in advance detailing dietary restrictions or any other accommodations or needs they have.

Content

Logistics are important, and, as you can see, involve lots of details and things to think about. As a result, the content tends to be put off or not thought through as critically. While there are less questions there, each one goes much deeper and really have the ability to create transformational experiences for attendees that make all those logistics worth it.

• Mandatory or not? Providing Clarity for folks on which and whether activities are optional or mandatory is critical in setting expectations
• Goals - Gathering goals and outcomes/deliverables that are agreed upon by all stakeholders
• Agenda, including breaks, breakouts, and a logical flow that creates the right storyline, vibe, and focus for your gathering. This also might include determining different people who will plan and/or lead each session
• Ideally each person will have a detailed outline or semi-detailed outline for their session, the individual session goals, and design and facilitation of it.
• Outside speakers or facilitators needed
• Materials/setup/information needed for all sessions
• Check-ins on whether content is ready/planned (no one wants a session planned on the flight over to the gathering)
• Team or sub-group gathering within the larger gathering?
• Reservations at any restaurants or locations the group will be visiting

Extras

• Covid policy
• Sick policy
• Emergency policy (yes, I am a worst case scenario thinker)
• Communication (internal and external) with related timelines
• Supplies
• Swag
• Think about the folks that your participants are leaving in order to participate in this gathering. Is there any way you can provide a thank you or any support to them to make this time easier for the person who’s away and the people who aren’t
• Any religious related accommodations that need to be made?

Just-in-cases

• Small, in between get-to-know-you activities
• Easy ways for people to start conversations with one another
• Snacks

What did I miss? What would you add?

If you're eager to discover what an exceptional offsite, retreat, or gathering facilitation could look like for your group, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you create magical moments and get to GREAT. Whether you're seeking a complete overhaul of a traditional format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

To start off, a bit about why I chose this program. I’ve been designing and facilitating meetings and gathering for over 20 years. One would think that by this point, I might not have much to learn about styles, techniques, and approaches, but everyone has growth edges and there’s always more to learn! I decided on this course for a few reasons. First, it was recommended by a handful of friends. I was a part of Cohort 13 (Lucky 13 as we called ourselves!) Each cohort has about 20 people in it, so I was able to chat with a handful of individuals who had previously participated and everyone said it was life changing and gave them so many new tools for their toolbox. Second, there’s always more to know! I’ve used a huge variety of approaches, some that I’ve learned about and others that I’ve created, to facilitate meetings in engaging and interactive ways, but there’s there are so many different approaches to learn, people to connect with, and get that hands-on learning around a modality which goes beyond just reading about it. Third, as a newer business owner, having the official certification is sometimes helpful in order to provide that amount of clout and trust in the experience level. And fourth, as you progress in your career, it becomes more and more difficult to find valuable professional development experiences AND these experiences are significantly more expensive than they are earlier in your career. I was craving a professional development experience and also wanted to be sure it would be a good one.

The course consisted of 4 modules. Each one with a different focus, from understanding who you are as a facilitator, to DEIB, to remote/virtual/hybrid facilitation, to understanding how to approach the design for different clients, groups, and meeting types. Throughout each module, we were both directly experiencing the modality (facilitation approach and design) while also learning how to design and facilitate it ourselves. And, an interesting and vital part of the course is how we were connecting with one another, and, learning how as facilitators to create space for that kind of connection to happen. This last part is super important because while the content of any meeting or gathering is important, the more important piece is how to connect with yourself and others around that topic to experience and engage with it more deeply.

Here’s the part that everyone wants, and those are the straight-forward takeaway tips. BUT here’s what I learned… the tips and tricks are less about bullet points that can be easily taken away and mostly about how you can feel and know where a group is going and what they need in the moment to ensure successful outcomes. There aren’t really clear, easy takeaways because… and the engineers reading this will appreciate it… it depends! You can’t design two identical gathering designs and how you facilitate it for two different groups because they are different. This is similar to how I personally approach engineering leadership work as well, while the same or a similar solution might be useful to put in place… the things that I essentially consider my “playbook”, what it looks like and how it’s implemented for different teams is just that, different. My specific takeaways were personally becoming more comfortable with pivoting and adjusting a plan that’s in flight to give groups what they need while still reaching desired outcomes (and achieving them even more fully by often navigating through instead of around blockers). And recognizing the work I can do in advance and in how I design gatherings to get the group discussing and interacting on a different, deeper level that will result in better conversations, interactions, and outcomes.

And, as I’ve stated other times and in other places, it all comes down to your goals. The one takeaway that I can pass along is that for every meeting and every gathering, know what you’re trying to accomplish and what you want people to walk away with. If you continue to tie each session and moment of the experience back to that (including breaks, social experiences, etc.) that you’ll be able to stay focused on creating successful outcomes.

If you're eager to discover what an exceptional offsite, retreat, or gathering facilitation could look like for your group, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you create magical moments and get to GREAT. Whether you're seeking a complete overhaul of a traditional format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

WRONG!!!

I'm here to tell you that a virtual offsite, while challenging, can be great!! When most people think about a virtual offsite, they think of endless hours in front of their computer screen. They think of so many meetings that could have been emails. And they think of endless presentations. But what if your virtual offsite wasn't that? Because it doesn't have to be. Here are some of my top tips and recommendations for a successful virtual offsite.

1. Update your goals. The goals of a virtual offsite CANNOT be the same as an in-person one. Spend some time thinking about the reasons you want to put the regular day-to-day work down. What should people walk out of this virtual offsite knowing or feeling? You'll have less time in a virtual offsite, so distilling the goals down to the most important items is critical.
2. Think about timezones. This is the trickiest part of a virtual offsite with a distributed team!! Map out all of your timezones to determine what your core overlap hours are and then critical masses in any other time zones or time zone overlaps. Use those alternate times as ways to plan different team building options or even run the same program twice and then bring it together in the overlap time.
3. Make it fun. No one wants to sit and watch presentation after presentation. Virtual offsites require extra magic. One thing I've done in the past is use "travel days" creatively to encourage mindset shifts as well as practice with whatever virtual tools we're using in a fun way. I've also sent "offsite kits" to each participant that remain closed until the offsite arrives. It provides a bit of mystery to the week and is a great group "unboxing" activity. In addition to these add-ons, there are some truly excellent virtual team building events and options that teams can really get into and have fun with. You don't have to sacrifice the fun just because things are remote.
4. Know your tools. The variety and options these days of virtual tools are incredible. Additionally, you can use these boards and tools in non-standard ways to keep people moving and keep things exciting. Think about use of polls, pictures, breakout rooms, virtual whiteboard, post-it-ing, and even just google docs structured in the right way to encourage active participation. I wouldn't recommend using too many tools as you might confuse participants, especially if they are unfamiliar with the tools being used, but again, the options are there and can fit within any budget.
5. Hire a professional. Planning a virtual offsite takes even more care and consideration than an in-person one. You need to think through a whole variety of tools, agendas, team dynamics, accommodations, and more in order to ensure a fun, inclusive, exciting, engaging, productive event. Hiring someone can help you shortcut hours of research and learning that you'd need to otherwise do on your own.

If you're eager to discover what an exceptional offsite looks like, talk about what's happening with your group right now, or have the ability to advocate for the budget to have an offsite today, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you get to GREAT. Whether you're seeking a complete overhaul of the traditional offsite format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

• About half of companies are taking the time to do team gatherings again. There is no trend in terms of company size (some small companies are very committed to doing gatherings frequently, while others aren't, and the same is true for larger companies).
• Almost no one feels like they have a clear budget or budget guidance when they embark on planning these gatherings
• There is almost universally no way that these gatherings are being evaluated. Now, I'm not talking about asking people if they had a good time, how they would rate the experience, and those sorts of questions... that type of post-event survey is happening, but I'm talking about the bigger picture. Did the team walk away feeling more aligned? Did they truly create closer connections with others? What is something they learned? The questions that really help determine the business value of team gatherings.

Additionally, one interesting insight was that teams that are in person tend not to set aside these deeper focus days. The thought is that people see each other every day and therefore gatherings such as these aren't as necessary.

I've written posts in the past about not cancelling your offsite and how an offsite isn't a perk or benefit, but days become weeks and weeks become months and months become years. So... when was the last time that your team (team, department, company... however you want to define it) set their day to day work down and truly delved into larger topics and things they need to think more deeply about. And, if we can think about this at the leadership level (because, seemingly, regular and even frequent leadership offsites are still occurring), why is that same time and space not given to other levels of leadership or to groups of individual contributors. As we look back at the last few years, for many, the cancellation of gatherings due to COVID went right into the cancellation of gatherings due to spending constraints. Whether your team is in person every day or remote, connecting them to one another and allowing them to take a step back to solve key, critical problems means so much to them and to the business.

And I'll push even further... think of the last leadership offsite you had. Was it useful and valuable? Did you make the best use of your time? How could it have been better or different? And what changes are you making for next time to ensure the time is spent well?

So... when was the last time folks got together? And when will be the next time?

If you're eager to discover what an exceptional offsite looks like, have the ability to advocate for the budget to have an offsite today, or think about different ways to get your team together Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you get to GREAT. Whether you're seeking a complete overhaul of the traditional offsite format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

If you manage multiple departments or teams, having an individual "field trip" to a different team's offsite can result in some really interesting opportunities. One of the challenges of having multiple departments or segments of engineering reporting to an individual is the silo-ing that happens between groups. Sometimes, this is unintentional, where teams aren't working together even though they should be. Other times, it doesn't make as much sense for different departments or teams to work together but is still beneficial to create some sort of connective tissue in between these areas. By having someone field trip to a different offsite, it gives individual contributors or other leaders a chance to get to know someone from a different department. Even if they are only participating in sessions as a "fly on the wall", during meals or other social time, folks can ask them about their work, what their department or area is focused on, what their current and future work looks like, and how they work. If desired, you can also organize some special sessions around this individual. Maybe they do a short presentation on the kind of work they look at, or what teams they most frequently interact with. It might be interesting to have a Q&A with them or have them talk about a particular way their team plans or organizes their work. There are lots of interesting possibilities for how to include the fieldtripper into an offsite to provide valuable information, friendship, and cross-departmental interactions.

This also has benefits for the person selected as the fieldtripper. It can be a professional development opportunity for them to see how a different team or department runs. It can give them a chance to come back and teach the rest of their team or department about something, similar to how they might come back from attending a conference. It can give them an opportunity to lead a session (even just one that is focused on social connections as opposed to business output) in front of a group of their peers that may not be as close or familiar to them.

Realistically, when you're planning an offsite or onsite, one additional person will likely not make a significant impact on your budget as a whole. The next time you're thinking through an offsite, talking with your teams about the offsites they are having, or sharing ideas with peers, consider the impact having a fieldtripper could make.

If you're eager to discover what an exceptional offsite looks like, talk about what's happening with your group right now, or have the ability to advocate for the budget to have an offsite today, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you get to GREAT. Whether you're seeking a complete overhaul of the traditional offsite format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

One of the hardest parts about working remotely is not getting much of a change of scenery AND this is also one of the best parts about working remotely. As a leader, it's vital to find the spaces and places that help you get "unstuck" and tap into a different part of your brain or even motivate you to do something differently. Sitting and typing at a desk can only get you so far when composing blog posts, thinking deeply about company growth, or tackling some complex strategic planning. This can be done through both new and innovative spaces that you might explore as well as through embracing the broader concept of environments that foster creativity, strategic thinking, and effective problem-solving. So, what are these creative spaces? or ways of thinking that help lead to these breakthroughs?

Thinking beyond the desk

Your desk is likely the easiest place to work. It's (hopefully) set up in a quiet place and organized to your liking, but I'm not sure about you, but sometimes I feel like my desk traps me. It traps me into a certain way of thinking, it distracts me with other tasks that might feel more urgent and important, and it almost robs me of my ability to think more strategically or let something else flow. WHen I think about my work spaces and the options available to me, I try to focus in on the task i'll be doing and what I feel like will provide me with the most inspiration for that task. Sometimes that task truly needs creative thinking, like planning for an offsite, and sometimes, I just need a change of scenery to be able to focus in a different way, like when i'm writing performance reviews. Here are some of my favorites:

• A comfy seat or couch. for me, this is best for reading books or articles in a spot where i'm far enough away from my keyboard and computer that I can't just easily jump into or be distracted by something else.
• A coffee shop. This is best for me when I need some ambient noise that I'm actively tuning out in order to get other work done and fuels my thoughts in a particular area.
• Coworking. This can be at a coffee shop or at a coworking space. This is useful when I want or need to feed off of the energy around me for work i'm trying to accomplish and/or when i'm working on something where i'll want to take some regular breaks that feel more social.
• My floor or a different wall of my office. This is best when i'm trying to post-it note brainstorm or do some big picture thinking on larger pieces of paper (more on that in the next section).
• A different, unique location based on where you live. I'm lucky enough to live in Washington, DC. This means that I have all the Smithsonian museums at my disposal. While they are awful places to take meetings from, they are fantastic for inspiration. Some of my favorite places to work from have been the Renwick (while this museum is small and doesn't have many spaces for working, with a notebook and pen, it can be a great space for brainstorming, depending on what exhibits they currently have), the Museum of Natural History, and the National Portrait Gallery's courtyard.

Changing how you work

In addition to the change of scenery, finding your creative space might include changing how you work. There are a variety of interesting ways to use your imagination to outline or jot down thoughts when tackling a larger project. One example is just some old-fashioned whiteboarding. I love getting in front of a whiteboard or big blank sheet of paper to just see where I go, write down whatever pops into my mind, and then use that to organize my thoughts later. Sometimes it ends up in an outline, sometimes just a lot of different ideas, and other times key concepts, approaches, or themes I want to dig into further. I always keep a post-it table top easel pad in my office for this reason!! A similar idea is to do this same thing with post-it notes. Use post=its as a way to get out all your thoughts and then move them around, group them together, and see where you end up. This is a great technique for group conversations but it can also be really effective for solo endeavors as well. Finally, you can try a mind map which is similar to a brainstorm but where each idea is connected to something that's already written down and branches get identified along the way. All of these methods are ways to think differently or get your brain going as you're tackling different kinds of work. They're about seeing problems and solutions through a different lens, one that is less linear and more holistic.

As you find your creative space, both physically and mentally, don't forget to follow tried and true advice. Habits like taking regular breaks, going on walks, and interacting with nature can significantly increase productivity and creativity. So the next time you're stuck, try a new way of thinking, a new place of working, or just going for a walk to see what clarity you can stumble upon.

In the end, the creative journey is as diverse as the leaders embarking on it. Whether through a change in scenery, a novel approach to problem-solving, or the simple yet powerful act of taking a break, these elements are crucial in nurturing creativity, strategic thought, and visionary leadership. As leaders, we must continually seek and embrace these spaces and methods that best ignite our creative and strategic potential, for in these spaces lies the key to unlocking a more innovative and impactful future.

So, how does one get all of this out of a 1:1?

TL;DR:

• Embrace Vulnerability: Both you and your reports should feel comfortable being vulnerable in these meetings.
• Balance of Conversation: Ensure a balance between listening and sharing, especially with particularly quiet or talkative reports.
• Contextual Adaptability: Adjust your approach based on each individual's communication style and needs.
• Role-Specific Challenges: Recognize how the dynamics of 1:1s change as you progress to higher leadership roles like CTO or VP.

Second, let them talk about whatever is on their mind. And, always give it more than a surface level "everything is fine" nod. If you have someone who doesn't talk as much or who frequently responds with everything is fine, probe further into that. What feels fine? Could things feel better? Is there anything this week that was frustrating? or that they were really excited about? Allow for some silence as well. While this might feel uncomfortable, it might also be the space and time someone needs to figure out what their real answer is. Conversely, if you have someone who is quite verbose, you can also use these questions to focus them or, as they're sharing, ask questions like what about this feels the most important to you? What feels fixable and what feels out of your control? How can I support or help?

Third, and this is not widely agreed upon, while I try to keep most of the time in 1:1s as their time, I do use the time periodically to cover things that I need to review with them. Common examples are: something I observed that they need feedback on, something I observed that one of their direct reports might need feedback on, understanding how their team is doing, addressing any projects or work that might be off-track, ensuring understanding on something recently rolled out on the department or company level, or clarifying expectations or asking for reinforcement around something I might be rolling out (as well as asking for the mood and perception from their team on these announcements). Relatedly, recognize what information you need and what you don't. Here are some common mistakes I see being made especially by higher level engineering leaders: they use 1:1s as a way to dive deep into technical problems and solutions because they miss being closer to the code (or because they think they need to maintain that level of details on ongoing work). They use 1:1s as a way to get broader updates, especially in 1:1 with department leads who have multiple managers and teams reporting to them. They use 1:1s to vent about what they're frustrated about at their level as a way of connecting further with their reports and ICs. Recognizing what 1:1s should be used for and what they shouldn't be used for is helpful for determining what other meetings you might need to have or communication structures you should have in place, as well as identifying how your relationship might need to change based on the role and position you are holding at the company.

I also have some 1:1 logistics and principles that I review with everyone when I start doing 1:1s.

TL;DR:

• Note-Taking: Keep shared notes for transparency and future reference.
• Template Utilization: Use a 1:1 template to maintain structure and efficiency in meetings.
• Flexible Adaptation: Adapt the template based on individual preferences and needs.

First, I always take notes that are shared with the person I'm doing the 1:1 with. I do this for a variety of reasons. So that I and the person I'm meeting with have an easy place to re-review what was discussed or any action items that were decided during our time together. So that if we have a conversation around some more constructive feedback or feedback that might be difficult to hear, we have a place to reflect on that feedback. I also always take notes not just on the feedback but on the conversation that happens about the feedback. This is helpful if someone wants to clarify something after that fact that might have been said or expressed. And finally, I take shared notes because it makes performance reviews SO MUCH EASIER for both myself and my direct if we can just flip through 1:1s from the last 6 months or year and get a sense of what we talked about.

Second, I like to use the 1:1 template that I have linked below. This is not a requirement for folks but I do find it helpful. I also go over how different people utilize this template. Some start next week's 1:1 issue/space as soon as this week's 1:1 has ended. That way, over the course of the week, whenever they think of something, they already have a place they're adding it to. Others take 10-15 minutes before our regular 1:1 to fill out the issue so they can keep their thoughts organized and so that I can do a quick read of whatever we might not get to. Others make sure to give me a "heads up" if they have something particularly frustrating or emotional they might want to discuss so that I can go into the 1:1 with the appropriate information and in the right brainspace. And others, don't fill out the template at all. But we'll still go through the questions and i'll use it as a basic structure as I take notes. These thoughts are usually not full sentences, they're more bullet points or memory joggers to make sure we're using our 1:1 time in the best possible way.

This template can be used in notion, as a github issue template where you open a new issue each week, in a google doc, or in any HR 1-1 note taking system your company may be using.

Some final thoughts on 1:1 "logistics":

1:1s should be scheduled for either every week or every other week and, in my opinion, should be somewhere between 30 minutes and an hour. I usually start with 30 minutes for everyone and if we regularly find ourselves going over time, or having more to discuss, I update the timing. I also try very hard to keep 1:1 time as reserved and try, as much as possible, to not move around 1:1 timeslots.

Below is the 1:1 template I use. Some has been developed by me. Other questions borrowed from managers I've worked with in the past. I hope you find it helpful!

Download PDF

If you have questions or would like 1:1 guidance, Book a free consultation call with me today to talk about my 1:1 mentorship and advising offering.

The concept of offsites as a 'perk' paints a misleading picture. They're often perceived as a company's generous way of giving employees a break, a 'thank you' wrapped in the guise of a business trip. While they may offer a change of environment and a break from the routine, their core purpose goes beyond these surface-level benefits. Offsites are strategic investments made by companies to foster better communication, teamwork, and overall productivity. Studies have highlighted how social interaction outside the traditional workspace can improve communication patterns by as much as 50%, a testament to the value of these gatherings. To categorize offsites as a mere benefit, even the ones solely focused on coworking or hanging out, is to overlook the integral role they play in fostering a cohesive, dynamic, and productive work environment – especially as more and more companies (especially engineering teams) become remote or hybrid workplaces.

Beyond their purpose, let's address the less glamorous side of offsites or the side that isn't frequently spoken about. Offsites can pose significant logistical challenges, especially for those with health concerns, mobility issues, or caregiving responsibilities. For such individuals, offsites are not a leisurely escape but an added stressor and often, a significant expense both financially and mentally to ensure all homeside logistics are covered while someone is away. For these employees, offsites aren't a luxury; they're a hurdle. The struggle to participate fully can outweigh the potential benefits. This doesn’t scream 'perk'; it shouts 'obligation'.

Offsites as Business Essentials

Now, don't get me wrong. I'm a HUGE believer in the importance of offsites. I think offsites are critical for business and team development and that any team not doing offsites today is making a critical and expensive mistake but that doesn't mean we shouldn't change how we think about them and how we talk about them. In the realm of remote work, the importance of offsites is magnified. The potential isolation that comes with remote setups can affect productivity, with some studies indicating a reduction of up to 21% in isolated employees. Offsites offer an important platform for face-to-face interaction that is vital for team cohesion. When well-supported, remote teams equipped with opportunities for real interaction can surpass the productivity of traditional in-person teams.

The value of offsites extends to the overall health of a company. Motivated workers, often a product of well-planned team interactions, can outperform less engaged peers by over 200%. Furthermore, the happiness fostered by positive team dynamics can increase business productivity by 31%. These aren't just numbers; they are compelling arguments for the necessity of offsites in any business model.

Investing in the Future

Recognizing offsites as essential rather than optional changes the narrative around them. They become a critical investment with tangible returns: enhanced team dynamics, reduced turnover, and a strengthened company culture. Offsites aren’t merely a line item in the perks section; they are a crucial line item in the budget, an investment in the human capital that drives business success.

It’s time for a shift in perspective. Offsites are amazing and fun and wonderful and critical. And also, offsites should be viewed and talked about not as perks but as vital components of a successful business strategy, especially in today’s increasingly digital and remote work landscape.

When we think of offsites (offsites/onsites/team or department get togethers... for the sake of simplicity, i'll refer to all of them as offsites here) - those pivotal events for groups that are meant to foster team building and alignment, address challenges that need to be addressed in person and bring people together, tackle complex conversation where in person time is critical, and generally recharge everyone in a different way than the usual - we often imagine them in their ideal state... as carefully curated experiences, ones where everyone walks away rejuvenated and excited about the their team, the company, and the future. Even for those who try to keep planning low-key, focusing more on hanging out, the hope is that these goals, at the very least, are accomplished. For those planning more detailed gatherings with additional goals, the ideal state is that each detail has been planned and every outcome has been achieved precisely as envisioned. This dream, buoyed by ambition and aspiration, is what sets us on the journey of offsite planning. It's a journey filled with promise, one where every session and activity we plan is expected to ignite camaraderie, stir innovation, and renew focus.

But the path to a successful offsite is seldom as straightforward as we envision. Let's delve into the nuanced reality of offsite planning, a task that is as challenging as it is rewarding.

The initial phase of planning an offsite is often marked by a surge of optimism and creativity. We start with expectations and hopes, sketching out (even just in our minds) what we envision as the perfect gathering. Engaging activities, deep-diving sessions, recognition of the most important pieces to discuss and address, and moments of genuine connection - these are often just a few of the elements we aim to weave into the tapestry of the event. We see in our mind's eye a team returning not just refreshed, but truly excited, focused on new goals and a renewed sense of purpose. This isn't just another gathering; it's a catalyst for growth and change. This vision is what you talked about and advocated for to get the budget approval to have an offsite! This vision is why people are brought together and why the cost (both monetarily and in time) is deemed as necessary.

However, as planning progresses, the unpredictable aspects of professional life begin to make their presence felt. The day-to-day demands of our jobs don't pause to accommodate our offsite planning efforts. A crisis arises that needs immediate attention, or a key project veers off course, demanding more time and resources than anticipated. Board meetings, stakeholder engagements & alignment, and unforeseen challenges continue to vie for our attention, each adding a layer of complexity to our already packed schedules. Offsite planning drops towards the bottom of the to-do list. "It's not for a while" or "this other thing is on fire and must take priority" is what we think as we re-order and adjust our "must do's".

And then, as offsite planning truly gets underway, the logistical aspect of the event takes center stage, often overshadowing the more strategic elements of the plan. The logistical labyrinth of organizing an offsite is daunting - from ensuring travel arrangements (everything from letting people know dates and times to reminding people to actually book their travel) and accommodations to managing dietary preferences and venue selection (not just for your daytime activities, but also for dinners, team fun time, and more). Each of these tasks, while seemingly mundane, is critical to the success of the event and demands a significant investment of time and effort. And, these things end up taking the "extra" time you have because, realistically, if the venue isn't reserved, or travel isn't booked, then without any participants, an offsite is a mute point anyway.

In the whirlwind of managing these logistics, the core purpose of the offsite - the content and the experiences that will make it truly impactful - frequently takes a back seat. The initial vision of meaningful and engaging sessions gives way to a race against time, with the focus shifting to ticking tasks off a checklist rather than crafting an enriching experience. This shift can leave little room for considering innovative presentation methods or exploring fresh, engaging approaches to content delivery. Because what you've done in the past has always worked "well enough", hasn't it? After all, no one has walked away hating the offsite. And so that becomes the goal... plan a "good" offsite. Plan something that people think was mostly an ok use of their time. Maybe the outcomes won't be as good, maybe you won't accomplish everything you had hoped, but surely it will be fine and some important things will get discussed, decided, and people will probably enjoy just seeing one another and hanging out together.

In response to these mounting pressures, delegation becomes a necessary strategy. Different aspects of the offsite are handed off to various team members, each contributing their piece to the puzzle. We rely on the collective effort, hoping that when these individual contributions come together, they form a cohesive and effective whole. On the journey to the venue, we often find ourselves finalizing plans and ironing out details, realizing that there hasn't been enough time to fully develop the kind of deep, engaging content we initially envisioned. We think... this will be fine and maybe next time we can make it great.

From Good to Great

In the realm of offsite planning, one of the most significant challenges is envisioning what truly exceptional looks like. Most of us have attended various offsites throughout our careers, and for the most part, they've been acceptable. They've met the basic requirements of bringing teams together, offering a break from the usual routine, and perhaps touching on some key organizational goals. A few might stand out in our memories as lackluster or even counterproductive, but generally, offsites tend to land in the realm of "good enough."

The reality of offsite planning, with its blend of high aspirations and challenging logistics, brings us to an essential question - how can we ensure that our offsites are both meaningful and feasible?

This prevalence of "good enough" sets a subtle but powerful benchmark. When our experiences are mostly of offsites that are just passable, it becomes challenging to imagine something that goes beyond this norm. How do we conceptualize an offsite that doesn't just tick the boxes but truly elevates the team's experience, engagement, and productivity? How do we even know what that looks like or feels like if our exposure to truly great offsites is limited, it's hard to set a vision that goes beyond the standard, the familiar.

And there's some good news and bad news here. The good news is, there are numerous templates and tools available to assist in the planning process. These resources can guide you through budgeting, provide checklists for logistics, and offer frameworks to get started. However, the bad news is that most of these tools focus predominantly on logistics. They often fall short in guiding you through the more critical aspect of offsite planning - the content. Templates can't capture the unique dynamics of your team or the specific goals you want to achieve. They provide a structure, but not the substance and often leave out critical budget items or checklist boxes to address this portion of the offsite.

AND, as with most ways that we address the fact that we don't know what we don't know, this is where bringing in someone with specific expertise becomes invaluable. It's about breaking the mold of the 'good enough' and venturing into the realm of the extraordinary.

The first step is to start planning early. For example, if you're thinking about a spring or early summer offsite, you should start planning now. Time is a crucial asset in this process. The earlier you begin, the more space you have to balance the logistical details with the substantive content that will make your offsite truly valuable. Second, think about working with someone. This can help crystallize your vision, aligning it with practical realities and ensuring that every aspect of the offsite, from the logistics to the sessions, is thoughtfully planned and executed.

Planning an offsite shouldn't be about settling for the average or the known. It's an opportunity to explore what greatness in team gatherings looks like, to push beyond the boundaries of the 'just okay,' and to craft an experience that resonates deeply with every participant. Imagine your next offsite as more than just another item on the calendar - but instead as an event that leaves a lasting, positive imprint on your team and organization.

Remember, no one sets out to plan a sub-par offsite. Get the support and resources you need to make your vision of an ideal offsite into a reality. You got this!

If you're eager to discover what an exceptional offsite looks like, talk about what's happening with your group right now, or have the ability to advocate for the budget to have an offsite today, Book a free consultation call with me today. With a range of pricing options and levels of involvement, I'm here to help you get to GREAT. Whether you're seeking a complete overhaul of the traditional offsite format or looking to infuse your event with fresh, impactful elements, I can help guide you through this journey.

Equally important is how you are making time and space for yourself. As you hear, absorb, and listen to pain from others directly or through news sources and social media, it takes a toll on you, especially if you are also directly affected. Here are some thoughts and ideas for supporting your people and supporting yourself.

Supporting Your People

I'm often very quiet on these issues, and maybe I'll delete this post in the future but right now Jewish employees are practically begging their non-Jewish friends, colleagues, and companies to reach out. To say something to acknowledge the pain they are experiencing. Your statement does not have to be long, and it does not have to be complex. As a manager, your outreach does not need to be long and it does not need to be complex, but it does need to happen. Here are some things you can say:

• How can I best support you?
• Reaching out to say I am here for you
• I can't imagine what this is like
• I'm so sorry

Some things you can actively do right now for anyone affected by what happening:

• Make space for what they need
• Recognize that what an individual needs might ebb and flow based on news consumption, processing, social media, news they hear from friends and family, and more. When someone tells you what they need, don't assume that's what they need for the next week(s).
• Help clear other obstacles for them. If there are parts of work that take more patience or mental energy, those might be tasks they can't or don't want to handle right now. This goes hand-in-hand with helping to recognize and listen to what support they need

Supporting Yourself

• Make sure you are making time for yourself.
• Try to communicate what you need as well from others, from your manager, peers, and/or direct reports
• Find your spaces of support. I know that can be extremely difficult, especially for Jewish leaders. It can feel isolating or like you have been deserted. If you find yourself there and can't find a supportive space for yourself, let me know. I'm here for you too.

Some additional resources from folks who are much more articulate than myself in this moment:

• How to talk about the war in Israel when you don't know much about it
• Resources for leading through Crises

1. Planning Effective Offsites: Beyond Team Building

The word "offsite" often conjures images of team-building exercises and leisurely activities. While these are essential, an effective offsite should also drive strategic alignment, foster innovation, and enhance team cohesion.

Why sign up for a time? Come with questions about:

• The essential components that differentiate a standard offsite from an impactful one.
• Setting clear objectives for your offsite and determining ways to measure its success.
• Designing activities that not only entertain but also align with strategic business objectives.
• Translating the enthusiasm and alignment from an offsite into tangible, daily operational outcomes.

Grab your spot today

2. Evaluating Your Engineering Team’s Health: A Holistic Approach

The health of your engineering team doesn't solely hinge on deadlines met or code deployed. It encompasses team dynamics, mental well-being, skill development, and the ability to innovate under pressure.

Why sign up for a time? Come with questions about:

• Tools and methodologies to assess team health beyond traditional metrics.
• Recognizing the importance and impact of mental well-being on productivity and innovation.
• Cultivating a team environment that encourages continuous learning and growth.
• Identifying potential signs of discord within the team and proactive strategies to address them.

Grab your spot today

3. Hiring Engineering Leaders: Making Strategic Choices for Your Organization

Navigating the hiring landscape for engineering leaders requires more than just sorting through resumes. It’s about recognizing potential, understanding cultural fit, and predicting how a leader can drive innovation and growth to solve the problems you are currently facing.

Why sign up for time? Come with questions around:

• How to discern between technical prowess and genuine leadership potential.
• Strategies for identifying candidates who genuinely align with your company's vision and culture.
• Addressing challenges related to fostering diversity and inclusion in tech leadership roles.
• Tips and best practices to refine your hiring processes for long-term success.

Grab your spot today

Why Focus Advising?

Being at the helm, leaders constantly juggle myriad responsibilities. The urgency of day-to-day operations often leaves little time for deep dives into specific areas. Focus Advising sessions offer this precise opportunity - to pause, reflect, learn, and act. By dedicating time to a singular area of concern, leaders can garner in-depth insights, engage in meaningful discussions, and walk away with actionable strategies. It’s not just about troubleshooting; it’s about evolving and leading with confidence.

So, if you want to enhance your leadership prowess, ensure your team's sustained success, or just think through an issues you've been grappling with, these Focus Advising sessions are designed for you. Dive deep, learn, and lead fearlessly.

If you're looking for a longer session, reach out! I'm available for 1:1 advising and mentoring sessions on a regular basis on any topic you'd like to cover.

Register Today

This workshop will be capped at 20 participants

I'm offering an interactive workshop on October 11, 2023 where you'll plan your goals and outline the deliverables you want to get from your next offsite.

Jumpstart your Engineering, Product, and Design offsite planning with purpose and clarity. Let’s face it: One of the most challenging aspects of orchestrating an offsite is ensuring every minute counts. Dive beyond the surface-level objectives of "uniting the team" and "finding common ground." This workshop is your gateway to designing an offsite experience that seamlessly juggles diverse priorities while communicating the indispensable value of such a gathering to stakeholders.

In a dynamic 90-minute session, this workshop will inspire you to:

• Spark innovative ideas through brainstorming

• Exchange insights and solutions with like-minded leaders

• Establish compelling goals that focus on tangible and intangible outcomes

• Preview examples of robust, efficient offsite agendas tailored for both in-person and virtual settings

• Start to understand diverse methodologies to design captivating sessions

Why should you sign up for this workshop?

• Cost-Effectiveness: Guarantee that your offsite's return on investment is significant, saving both time and money. The potential savings from optimizing your offsite can easily amount to thousands.

• Break Initial Barriers: Overcome the primary planning challenges, accelerating your offsite's preparation.

• Tailored Team Insights: Grasp the unique perspectives of engineering, product, and design teams - how they resonate with offsites, their distinct outlooks, and the language and frameworks that truly engage them.

• Compelling Advocacy: Equip yourself to persuasively present the need for offsites, securing the necessary resources and backing from higher-ups.

• Concrete Deliverables: Transcend discussions and draft tangible action items, follow-ups, and results that will transform your team's dynamic.

• Enhanced Team Unity: Lay the groundwork to foster a sense of alignment and camaraderie among team members, leading to consistent collaborative success.

• Idea Exchange Platform: Immerse in a rich exchange of strategies and solutions, drawing from the collective wisdom of peers.

• Peer Inspiration: Engage with an assembly of forward-thinking leaders, absorbing ideas that could be the game-changer for your next offsite.

Note: This workshop is limited to 20 participants

Register Today

Need help getting started? Book a free consultation today or check out my offsite planning service

Interested in the current state of offsites more broadly? Fill out this survey to provide information about your company's offsites and I'll reach out with summarized and anonymized results after they survey closes.

September is what always gets me into a particularly reflective mood. It's not the end of the year but, it kicks off a period of reflection as new beginnings start. The transition of summer to fall is a meaningful one, often with more signs and symbols of changes than the end of the year. The pace changes for myself and for most folks around me. You can feel people coming out of summer mode, summer pace, and summer vibes to get back into focus in a more deliberate way. Kids start school, camps end, and the day-to-day looks different.

More specifically, for me personally, beyond atmospheric and schedule changes, to really trigger the SELF reflection piece, Jews also enter the month of Elul. Before the high holidays (most notably for folks Rosh HaShanah and Yom Kippur), we experience Elul, the last month before the new year but the focus of Elul is self-reflection. The Shofar is blown daily to remind us to do some reflection.

This transition and self-reflection time is a great opportunity for companies to reflect as well. Fall offsites focus on getting teams and individuals aligned to finish strong and NOW, not in December, is when planning, thoughts, and strategy conversations begin to take place for what 2024 will look like. Going into the end of the fiscal year, for many, what do they want to accomplish? Coming out of the summer, how are things going? And, most importantly, how are you self-reflecting to hold yourself accountable and make smart decisions about what YOU want the end of YOUR year to look like. If you're starting your planning conversations and thinking about how you are doing, what you're prioritizing and what you aren't prioritizing, here are some questions to think through:

• How are you doing? But for real, how are you really doing?
• What do you wish you had time for that you don't?
• What is going well?
• What do you wish was going better?
• How is your team doing?
• What do you invest in that will pay dividends in the future? for yourself and for your company?
• How will you solve those problems today?

so... what are you reflecting on as a new quarter comes up and we creep closer to the end of the year?

Here's a helpful worksheet to help you think through current blockers, how you're solving them now, how you want to solve them (or even just brainstorm all the potential solutions!), and what sorts of resources you'd need to solve the problem. I'd encourage you to think through what resources you need to solve the problem in the most ideal way and then also what resources you need to solve the problem in the most realistic way. And then finally, what actions you'll take to find those resources that you need.

Download PDF

Need help getting unstuck or solving these problems? Book a free consultation today

As layoffs continue to deeply affect the tech industry, and companies look at every dollar they spend more carefully, more and more companies are cancelling their offsites. This is a mistake, plain and simple. But I also get it!!! Think about the last offsite you were a part of (or even the last one that you planned).

• Did people have fun? Probably but what about these other aspects...
• Did you have a rubric or a clear way of measuring success? And I'm not talking about the "was it nice to see everyone in person" success (because it's almost always nice to see everyone in person), I'm talking the realer, deeper questions.
• Did the offsite result in any deliverables being produced?
• Was everyone clear on next steps, action items, and who was owning what?
• Did folks with additional logistical constraints to work out so they could travel feel like it was truly worth their time?
• Did there end up being some sort of people-related issue that also occurred and then had to be addressed effectively after the fact?

I wouldn't be surprised if your answers to those questions were yes, no, no, no, no, yes, in that order. And so when you couple all of that with budget constraints, of course it might feel like it makes the most sense to cancel your upcoming offsite.

But you shouldn't do it

Here's why -

Offsites connect teams. They connect individuals to each other. They connect individuals to company goals and milestones. And they connect teams to each other. They (should) energize people. They (should) give people time to process celebrations and grievances in order to move forward in a healthy way for themselves and for the business. Finally, offsites create that connective tissue that allow individuals to work together so much more effectively. Time after time and study after study has shown that teams that know each other better and communicate more effectively are more productive. And that teams where people have closer ties to one another have higher retention and lower turnover rates. And no, this doesn't mean that bringing everyone back to work in person is the solution. It means that these thoughtful, creative, effective touchpoints are critical, not just for your team now, but for where your team will be 3 months and 6 months from now.

If you're not paying for your team's offsite now, you'll just be paying for it in a different way through communication gaps, team dynamics, and productivity hits later. The cost of an offsite is just easier to identify and easier to remove from a spreadsheet than the more hidden costs of teams that aren't quite meeting their potential or don't quite have the motivation that they once did.

But make sure it's worth it

If you're going to spend the money, make sure it's worth it. Make sure you're giving yourself enough time to plan an effective offsite. This starts with thinking about all of those questions above, about what led to all those "no"s and ensure that, this time, you have goals and deliverables that are balanced with fun and truly great experiences.

Need help getting started? Book a free consultation today or check out my offsite planning service

Interested in the current state of offsites more broadly? Fill out this survey to provide information about your company's offsites and I'll reach out with summarized and anonymized results after they survey closes.

Need help leading your team to the next level? Book a free consultation today or check out my Fractional VP of Engineering service

While the latter promises an inviting mix of travel, leisure, and informal conversations, it often unwittingly favours extroverts, leaders, and those who know each other already, thereby leaving others on the periphery. Moreover, measuring the success of such offsites is nebulous both for the organizers and the attendees. Have people made new, meaningful connections? Have they delved beyond small talk? Was the offsite worth their time? Here are some suggestions about how to make your hangout offsite truly inclusive, engaging, and impactful without losing its laid-back vibes.

1. Set expectations and understandings beforehand.

Even with a gathering that is more of a hangout, pre-offsite communications are important. Here, you might include suggestions for questions to ask or ways for folks to engage with one another. You might ask people to come with a certain mindset or ask folks to think about ways in which they can connect with others authentically as opposed to just working from a different location for that week. Helping to frame the mindset for the week is really important to determine how people show up.

2. Build in ways for people to meet others they might not otherwise interact with.

One of my favorite ways to do this is through a short unconf. An unconference is a participant-driven time where the agenda is created by the attendees at the beginning of the meeting. Unlike the structured format of a typical conference, an unconference encourages spontaneous and interactive discussion. This can be a brilliant way to make your offsite more engaging.

At the start of the time, invite your team members to propose topics they're passionate about or challenges they're facing that they believe others could benefit from discussing. You can decide if you want to limit the topics to ideas that are work-related or open it up to anything people want to talk about! Vote to determine the ideas the most folks are interested in. Then, create a schedule based on these suggestions and let the organic conversations unfold. This not only encourages active participation but also brings to the fore diverse thoughts and ideas that might not surface in a typical team setting. It allows folks to get to know one another differently.

There are a variety of ways to add in similar aspects to a low-key offsite including pairing folks, having people sit next to different people for every meal, creating rotating walking buddies for breaks, and more. The goal here is to allow folks to interact with people they may not normally interact with AND go deeper than surface level conversation. Remember, you can always make some of these things optional as well.

3. Do one session that's all together and don't let that session be a solely frontal presentation.

Most teams or companies that get together do at least one session with everyone together... if not, it seems like a missed opportunity! But these sessions are frequently a "state of the company" or a usual all-hands that just happens to be happening in person. But what can you do in person that you can't do virtually? Don't miss the opportunity to have folks engage and interact with the material being discussed to really digest it. And no, i'm not talking about a Q&A. I'm talking about a small group discussion after the fact, or a big, but brief brainstorm about next steps, or even fun appreciations or an excitement/fear post-it exercise that enables folks to see what others are thinking and allows leadership to get a better sense of where their team is at. This doesn't have to take a lot of time, or be long and arduous, but if you don't want to miss our on the opportunity to talk to everyone together, in one space, then you definitely don't want to miss out on the opportunity to make it a lasting experience that will stick with people beyond the offsite.

As the businesses navigate hybrid and remote landscapes, thinking critically about how to connect individuals in ways that energize them and make the company more productive as a whole, it's crucial to reconstruct the idea of an informal hangout as a transformative, communal experience. By incorporating participant-driven activities like unconf, fostering deeper conversations, and capitalizing on the opportunities presented by being physically present, we can shape offsites that cater to a wider range of personalities and preferences. These enhanced offsites, while maintaining their relaxed atmosphere, can forge profound connections among team members, bringing about heightened understanding, empathy, and, ultimately, a more productive and cohesive team. The success of such an offsite then becomes a shared, palpable experience, far removed from the intangible benefits of past gatherings, setting the stage for a new age of team building and collaboration.

Need help leveling up your offsite? Book a free consultation today or check out my offsites service

1. Simplify Tracking of Team Availability

During the summer, the challenge of tracking who's available or out can mount as vacations accumulate. It's not uncommon for team members to be reachable only via email or Slack on certain days. Having a clear overview of everyone's availability can be beneficial for both managers and teammates. It's essential that your team has a concise checklist to follow when preparing to be out, which should typically include steps such as submitting time-off requests to the official HR system, updating adjacent and relevant calendars like their individual calendar and a team calendar (including noting "email/slack only" time), and setting Slack statuses. I also highly recommend a vacation or stop emoji. Several HR systems and Slack PTO integrations can automate this process and help in maintaining transparency.

2. Implement an Easy Out-of-Office (OOO) Template

• Project in progress: create one entry for each project in progress including the information below. What is the project/ticket/initiative being worked on? If possible, provide a direct link to where the information lives in case anyone needs to access the work in progress while the main point person is out.
• Who's taking it over (if anyone): If this work is being handed off to someone, or even just "babysat" but someone during PTO time, explicitly say who that person is and how to contact them.
• Any important notes or things to know: This doesn't have to be a full project write-up, but mostly just important things to note. For example "waiting on x" or "should start with a spike answering at least x, y, and z". Especially if the work is expected to continue while you're out, think of this as transition notes, or even reminder notes for when you or your teammate is back.
• Level of urgency: Clearly state what the level of urgency is for a certain project/ticket/initiative. This can be anything from very critical and work will be fully passed off so that it can continue while away to intending for the item to be put down or paused until you (or the point person) returns. Even if something is expected to be fully paused until returning, it's good to list it as a project so that if there is a question about it, it's clear who they can go to and that it won't be picked up again until the person returns.

3. Set Clear Expectations for Transitioning Out for PTO

Setting clear expectations for someone going on vacation limits this from happening. Folks know who to go to for questions, they know what work is continuing and what is paused, they can clearly see in a slack channel, slack status, or on a calendar that a person is out. The items above shouldn't take someone more than 30 minutes to complete and it helps so many people do their jobs effectively while one (or many) individual(s) is out.

4. Have a plan for transitioning folks back in from PTO

Allow the returnees a day or two to catch up, and if you're a manager, provide them with a summary of what they missed. Encourage them to ask questions and take time to settle back into the workflow (especially if someone was out for 2 weeks or longer!). For leaders, it's ok for you to take this time and space too! Give yourself permission to do so. Finally, if someone handed off all of their tickets or work before they left, make sure they know what they're coming back to and what work to pick up.

Embrace the summer season and have a fantastic vacation!

Once upon a time, I was responsible for leading immersive experience trips for college students. For the summer trips, we would receive upwards of 300 applications, for 3-4 buses, with 40 spots on each bus. Seems easy enough, right? Just put people on buses... maybe group them by age or just randomly, they'd have a good time. But this was the trick. These immersive experiences were meant to be life-changing. They were meant to have an impact long-beyond the course of just the trip experience. To create lasting friendships and memories that persisted for years to come. For that to happen, the trip itinerary was one piece... how you moved a group through the experience gradually and stretched their minds but, more than that, the actual people in the group had a tremendous impact on the experience as a whole.

This is how I still think about teams today. Think of teams as puzzles, with each individual serving as a unique piece that fits into the larger picture. And putting together excellent teams means more than just looking at resume bullet points. So how do you start to hone this skill? And can you do this without the gauntlet that is the usual tech interview system?

I'm not gonna lie, it takes time and practice to hone this skill and get to a place where you can ask the right questions and know how to read between the lines on answers in order to determine if someone will be a good fit or not for the team you're building.

Step 1

Step 1 is to know who is on your team and what skills and personality traits they bring to the table.

For technical skills, what does familiarity and expertise look like for each individual? (Note I said familiarity and expertise, not years of experience because someone with less years of experience can still be more comfortable or knowledgeable in a certain area of the codebase). What languages are they familiar with? What have they had exposure to in the past? What do they enjoy doing and what do they dislike digging into?

Assessing non-technical skills is a little trickier... how do they interact with conflict or conflicting opinions on the team? How do they communicate - both written and verbally? What does it look like when they resolve issues? When they look at new codebases or new areas... what's their approach? Do they hold the team together in any way?

When you have a good baseline sense for each individual, you can start to think about how these situational or behavioral traits interact together in order to understand the dynamic and balance that exists on your team. People build off of each other so thinking about the variety of personalities and how they cooperate and conflict (in a healthy way) with one another is critical.

Step 2

Step 2 is to determine what you need. When you think about the best teams you've worked on, or even the best ones you've observed, what was their "it" factor? It's usually the result of lots of different personalities and types of people coming together... someone who's really extroverted, someone who asks a lot of questions, someone who makes and creates jokes and brings levity to situations, someone who helps balance that with understanding the seriousness of some things, someone who takes a little bit to mull over information before providing thoughts or opinions. And these don't have to be all individual people, it's the collection of characteristics you're looking for.

Balance that with technical needs... How deep is your bench for your critical technical skills? Will you need to stretch into different programming languages in the future? And if so, is there someone that would be a good guide for others in that scenario?

While this might seem overwhelming, especially if it's your first time, understanding your team members on an individual level and observing their group dynamics will make it easier to identify which puzzle pieces are missing that, if added, would bring everyone together and make the entire team a little bit better. Although beyond the scope of this article, the same strategies can be employed to identify individuals who may be exerting a disproportionately negative impact on a group.

Step 3

Step 3 is to craft questions that helps you assess these traits to see how they might balance with your team. There are many articles and posts that hotly debate the best way to assess a candidate's technical skills (I have my own opinions as well that I'll opine on in the future) so here, I'll focus on some of the other skills you might be focused on hiring for. So, back to my buses... seems like a lot right? To interview 300 candidates, decide who would be accepted, and put them all onto buses... seems like it would take a while. Well, I had about 2 weeks. 2 weeks to to interview every individual, make decisions, and get them sorted on a bus (or not). The questions I asked had to be brief. They also had to be informative enough that reading the notes of interview 1 would still mean something after interview 201 and straight-forward enough that I could rely on fellow teammates to conduct interviews as well and get adequate enough notes to make decisions. Those interviews were 15 minutes each. They asked 3 questions:

• Which friends are you applying with and how do you feel about potentially being on a bus without them?
• What activities are you involved in?
• What do you hope to get out this experience?

In addition to that, the "short sheet" had their name, year at school, and major (or what they were thinking about majoring in). It seems brief, it seems like how could I get enough information in 15 minutes and with just these 3 questions to break people up into groups that would help them have a life-changing experience, but it worked. It was just enough to get a sense of them, who they were, what their personality was, and what they loved. Using this information, I'd put together buses that had a little bit of everything... the really positive folks who would lift everyone up on tired days, the super aware folks who would make sure that everyone's voice got heard, the extroverts, the folks who did glue work, the ones who quietly helped, and the ones that pushed boundaries and challenged questions or situations. All of these different types of people were critical to bringing everyone together in a way that just worked.

Despite the tech industry's notorious reputation for multiple rounds of interviews, a clear understanding of the kind of person and skillset needed can ensure the successful filling of any gaps in your team. Those are usually behavior or situational interview questions. I'll give a few examples:

• Tell me about a time you mentored someone and what you learned from that process
• What's something you've done for your team that you've found really fulfilling and meaningful? As a follow up, you can ask how they got other teammates involved or how teammates felt about it.
• How do you usually approach providing a code review?
• Tell me about a time you disagreed with someone. What was it about and how was it left?
• What's something thoughtful that a teammate or manager has done for you in the past to show appreciation?

A team is a puzzle where all the pieces need to fit together. A team is an orchestra that sounds beautiful when it's working together really well. A team is also a living being. Every time someone leaves or someone joins a team, it's a new team, a different team, that has a different personality. Teams are constantly evolving and changing. People are constantly learning from one another and advancing or improving their skills in different ways. Being able to see who your team is, where they are at, and what they need to be even better takes practice, but do it enough, observe it enough, and you'll continue to keep getting better at it.

Need help figuring out how to do this or what this might look like for your team? Shoot me an email, set up a call, or check out my services! I'm happy to help.

What is a retrospective? A retrospective, usually known colloquially as a "retro", is an opportunity for a team or group of individuals to reflect on (ideally) immediately past work and determine what changes or improvements can be made for the future. While retrospectives became popular as a part of an Agile workflow, they don't have to be used strictly in that sense. Teams do retrospectives when it makes sense for them. Some teams do them at regular intervals regardless of where they are in a workstream, others do it at the end of each sprint, and others will run a retro at the end of each project or feature. Folks can also run retros looking at larger periods of time, for example, a retrospective of the last quarter or the last half of the year.

Inspiration for retros can strike from anywhere and there are dozens of different ways to run effective retrospectives. The primary goals are that you provide folks with:

1. A way to look back and share both positive feelings about what's going well and what felt a little rough
2. Space to talk about the aforementioned items
3. Identified actions moving forward to make things better

So, what on earth does this have to do with the show Jewish Matchmaking? Well, in episode 4, Aleeza pulls out a worksheet that shows a suitcase (it's right around the 10 minute mark if you want a good visual). Her goal here is to have someone assess their dating history, or otherwise, their dating baggage: "Dating baggage can include negative dating experiences, fears about dating, everything that's inside that you can't see." She then goes on to say "And we're going to put it on paper to evaluate it together to lighten that luggage." The goal is to recognize what individuals are carrying around, and what are they thinking that likely impacts their actions, which ultimately also impacts how a project gets executed. This same idea can be used as a retrospective but I've also seen tactics like this used in a "pre-mortem" which is a way to discuss and hopefully allay fears or concerns before a project kicks off. Reflection, understanding, and discussion are the primary ways effective teams move forward and continue to get better and better every day.

Now that we've defined what a retro is and what it's used for, here are some of my favorite retros:

• 6 hats. I love using this one. It has a good variety of approaches and you can even switch up how you do each hat to allow for better participation from both introverts and extroverts
• The sailboat retro. The general gist of this one is that you draw a boat with a sail and an anchor and you use the picture to write, post-it, and discuss what weighs you down and what gives you speed.
• Liked, Learned, Lacked. I used this one frequently as a personal retrospective when I wanted to do some personal and professional self-reflection. You make 3 columns, liked, learned, and lacked, and write ideas/thoughts down for each one
• Draw the sprint/project. Folks draw (or find a gif) that represents the work you're retro-ing on. It's both fun and informative to then have people share and discuss why they drew (or chose) the image they did.

The most important thing to remember when running a retrospective is to make sure that there are action items and point people assigned to those at the end of the session. One common pitfall I see frequently from teams is that they are going through the motions of having a retro, but the same issues keep coming up, and there's no progress made on those problems or concerns from one retro to the next. Additionally, action items distilled from the meeting aren't revisited again so they get lost in time and space until the issue happens over and over. The retro is useful for the reflection time, understanding, and discussion but then the actual actions and fixes need to follow in order for this to be an effective use of time and energy.

With that, I'll leave you to it! Go Retro on and don't forget to have fun with it!

So what is the painters tape of leadership? The ability to be versatile. A large part of being a manager and leader is understanding versatility and crafting your skillset to be versatile. Versatility is defined as the "ability to adapt or be adapted to many different functions or activities." This shows up in so many different ways. Think about your last week or last month of your role. In what ways did you adapt to someone else's communication style? What about their leadership style? In what ways did you take on a new task that required you to be versatile... to dig in and tackle something new requiring you to stretch your current abilities? As leaders, we're constantly looking at how best to communicate with our team or our peers, showing up in different ways that are effective in different groups. And beyond that, you can identify who on your team is more versatile and who's less.

So what can you do to push yourself to be more versatile:

1. Learn from others. Ask why things have been done a certain way to understand where they're coming from.
2. Get comfortable with being uncomfortable
3. Break down scary tasks into smaller pieces that you can tackle one at a time.
4. Be curious

The next time you're challenged with a task or pushed out of your comfort zone, or attempting to do the same with someone who reports to you, ask yourself what's potentially preventing them, or you, from being more versatile.

I hadn't had much time previously to play around with these tools. I had used Dalle once or twice to generate images for conference talk slides, but that was mostly it. And then I decided to give my website a refresh to give it some new energy and focus on my engineering leadership consulting services. It gave me the perfect opportunity to really utilize ChatGPT and Midjourney to see what they could do. Here are the top 5 ways I used them:

1. Color Palette choices: Admittedly, I do not have a great eye for color palettes and knowing which colors work well together. Instead of looking on color palette sites and trying to determine the best path forward, or what made sense for my website, I asked ChatGPT to please provide me with three business-forward color palettes that have a feminine feel, including the hex value for each color and noting which color would be used for a series of elements (for example, a button, a main section background, a highlight/sidebar, etc.).

2. Explain it to me like I'm 5: Let's just say that it's been a little while since I've dug deeply into my Jekyll website to keep everything updated and in proper working order. There are also amazing tools these days that weren't around when I first launched my website a decade ago... things like Vercel and Netlify, new static website generators, and more. I was so excited to get my hands dirty with these newer approaches but I also wanted to make sure that I wasn't spending too much time in the planning and researching stage before getting to the building stage. ChatGPT was incredibly helpful for a whole series of "please explain this to me like I am 5" questions. I asked things like what is the difference between Astro and 11ty, what are the differences between Vercel and Netlify, how many people are using each, what are the top themes for some of these static site generators, and more. While I dug a little further on my own, being able to ask these questions and even drill down further, gave me a huge shortcut as I got going.

3. Coding skills clarification or refresh: For my website refresh, I ultimately decided to start from scratch and use an 11ty template (see way 2 on how I made this decision), but it's been a little while since I have coded every day, and syntax like Nunjucks was new to me. When a piece of my code wasn't working, or when I needed to refresh my memory on how to do responsive column layouts, I could quickly and easily paste some code into ChatGPT and ask it to please help me out a little bit or explain how something was working.

4. Updating my About Me section: This piece was a bit more iterative. First, I took my previous about me and asked ChatGPT to highlight it in a few ways, for example "Please rewrite this bio focusing on my community work" or "Please rewrite this bio highlighting the strategy work I did". Then, I took a few different pieces of writing... a couple of versions of my bio, my resume, and previous about me, and asked to please combine them.

5. Midjourney for images: I knew I wanted to have some images, especially to go along with my services offerings. Midjourney was so much fun to use and, I think, ended up providing me with some really incredible images that provide a great visual compliment to what the text on my site is saying. I'm gradually finding more and more uses for Midjourney and reaching for it as a tool more than I thought I would, to be honest. I intend to also use it to create images for blogposts (see below).

6. BONUS: I used ChatGPT to provide me with a one-sentence description of this blogpost to put in the description field.

Overall, for many of the ways I used ChatGPT, I found that I wasn't using it very differently than how I would use google search in the past. Most of the responses ChatGPT generated couldn't be simply copied and pasted without reading it over and making sure it was correct or what I was going for. The main difference between my regular, usual googling for information and utilizing AI tools instead was that I could drill down on specific parts and pieces. It was sort of like having an engineer or friend sitting next to me where I could say "I like this part but not this part, what would be a different option?" or "I didn't quite understand this point, can you please explain it further?" And, of course, the areas where I used ChatGPT to summarize or combine pieces of writing wouldn't be possible otherwise.

• Retrospectives - a meeting where you look back and look forward to iterate and improve upon a working relationship either within one team or amongst a number of teams
• Planning meeting - a meeting to look at what's coming up soon and how that work should be broken down, prioritized, tracked, etc. to get everyone on the same page related to milestones and progress markers.
• Pre-mortem - a chance for folks to express their worries, fears, concerns, and excitement usually around a larger undertaking coming up and pre-emptively work to address some of those pain points.
• Post mortem - similar to a retrospective but frequently with a slightly different methodology focusing on trying to dig towards fewer, more specific root causes and related action items
• Team hang/watercooler - chill time with your team for non-work chit-chat
• Virtual offsite - Multi-day gathering potentially covering a wide variety of topics and goals. See offsites.
• Focused brainstorm meeting - A longer meeting (1.5-3 hours, in my experience) focusing on collecting a variety of ideas and frequently driving towards creating strategic alignment for the future. Popular methodologies come from places like the Luma Institute or other interactive facilitation sources.
• 1:1 meeting - regular time for an individual and their manager to connect.
• Skip level - regular time for an individual to connect with the manager of their manager
• Sync meeting - A chance for everyone to get on the same page. This often happens at a regular cadence (ie- weekly or every other week) but may also happen ad hoc
• Quarterly planning meeting - Similar to a regular planning meeting but focusing on a longer timeframe, looking at and planning for initiatives, epics, and other work planned for an upcoming quarter. This may also happen for an upcoming half depending on your company's planning preferences and anticipated roadmap iterations.
• Performance review meeting - A dedicated time to talk more deeply about an individuals performance and provide feedback. Often some level of feedback and performance check-in is happening during 1:1s but performance review meetings usually have a bit more formality and are a dedicated time to dive specifically into performance related strengths and areas of growth.
• All-hands - regular larger meetings, usually larger than one team (a meeting with a team may be a regular sync or planning meeting). This may be a full department or all-company. The format differs wildly based on the engineering leader planning it and goals of all-hands meetings.

You can read more about meeting cadence by checking out my Manager Tools Repo.

What season is your team in? What do you do? What don't you do that might be useful? What meetings have you run or attended in the past that you've found particularly useful.

One unexpected consequence for me over the last couple of years was the absolute frustration I felt staring at a blank page. When the pandemic hit, i was blogging regularly, I was speaking at conferences regularly, and, like others, had multiple conference talks cancelled or changed to virtual as organizers pivoted and figured out what to do next and how to do it. What followed was 2 years of fog, just trying to get myself and family through day-to-day. My littlest's preschool didn't open, my older one did virtual kindergarten (which, amazingly, went pretty well. I credit our household "normal" of someone working from home for his entire childhood in addition to his incredible teachers for that success). THankfully, we had an extra pair of hands in the house during this time. This year, everyone went back to school in person, with masks, frequent testing, constantly changing rules and accommodations, and regular decision-making around literally every little thing. In addition to this, throughout the pandmeic i've been in a leadership role, supporting others also living and working in a pandemic. Making sure that I was a listening ear, strong support system, and creating accommodating conditions for others was my top priority.

And then I would open up my computer and stare at a blank page.

I'd sit there, thinking about the conference proposals I should be submitting, the people I missed talking to at conferences, the blog posts I should be writing, and then podcast I should be continuing. But I was empty. No matter how frequently I tried, I was just stuck. And that stuckness led to frustration. Other people were writing, other people were speaking, other people were getting things done.

But here's the truth of it... I was getting things done, but what I needed to get done was different. What I did (and still) get done revolves around numbers, exposure, vaccination rates, and risk/benefit calculations. Making sure that I and my family need to be happy and healthy.

And also, I miss it. I miss putting out posts that are hopefully helpful to others. I miss speaking at conferences (or even just attending conferences and catching up with people I used to see regularly!!!). So I'm trying again. I might not succeed. I might not be able to stick with it. But i've reserved 1 hour every saturday morning to sit outside at a coffee truck and write.

Or stare at a blank page for an hour but remind myself that it is ok because i'm building the habit again, and i'm making the time and space for good stuff to happen. Which is the most important part.

The space and time you make for yourself.

Virtual conferences can be scary... maybe even scarier than speaking in person. While there's plenty of stuff that can go wrong in person, there's other stuff that is challenging virtually. Mainly, it's difficult to figure out how the audience is reacting when you can't see them. And there usually isn't a great way to interact with the audience afterwards in the same ways you would in person. But, having now done it a few times, there are some things to look for and ways to counteract that.

Look for conferences or speaking opportunities that include some sort of interactive component. Is the conference creating a way to interact with the other speakers? Or with the attendees?

Make the time. One of the biggest mistakes I've made so far is making time to present during my time slot but not being present for more of the conference. Being present is a way to engage with others through other content, through twitter, or through whatever other platforms the conference is providing.

Think about places to grab attention in your talk. We know it. We've experienced it. We're all sitting at screens watching talks. It's easy to get distracted with notifications or email or other things. This happens in person as well but when you're in a room with other people, it feels easier to snap back in to what's going on. As a speaker, make it simple for folks to tune back in to your talk and provide places in your talk where the slides or words grab the audience again.

Ultimately, we speak at conferences to teach or help others. Hopefully, we're talking about something that provides people with a new perspective or information they didn't have before. That doesn't change regardless of whether the conference is virtual or not. I can't wait until I'm able to see everyone again in person and speak at conferences. But in the meantime, this virtual conference thing isn't so bad.

Shameless plug - As one of the conference chairs for RubyConf this year, we'll be providing a unique conference experience that provides value to speakers and participants, with options to pre-record your talk or deliver it live. Submit your talk proposal today: https://cfp.rubycentral.org/events/rubyconf2020 or, if you're not submitting to speak, buy your ticket today! http://rubyconf.org/

To get practice and follow along, download this worksheet

One of the things the teachers have mentioned that they struggle with frequently is the idea of muting the children. They talk about muting "out of love" and helping the children understand why they need to mute someone sometimes. They dislike muting the children though because, in their eyes, it is literally taking away their voice and their ability to share about themselves.

This week, however, they decided to use it as the trigger for one of their class discussions. The email home started by explaining: "Loris Malaguzzi, the founder or of the Reggio Emilia approach said, 'The child is made of one hundred. The child has a hundred languages, a hundred hands, a hundred thoughts, a hundred ways of thinking, of playing, of speaking.' Well, the Zoom meeting is our 101st language and we should explore and learn about it just as we are exploring, learning and discovering any other new language that we are introducing in the classroom."

What a fascinating conversation! I spend all day, every day on Zoom, with peers, with managers, with my team, and I honestly have never thought about processing for myself or with others what that is like. What do I love about video conferencing? What's great? But also, what's not so great? What is frustrating? and what is more exhausting about zoom meetings when compared to in-person ones? The teachers mentioned they would cover all of this with the children as well as ask them how they prepared for meetings or what kinds of things they did before coming to a Zoom meeting?

Well, needless to say, I was very excited to listen in on this conversation and hear how the teachers facilitated it as well as how the children reacted to it. I didn't catch the whole conversation (because my son wanted to take most of the meeting in his room with the door closed) but I did catch the end, which was a fascinating pivot. I honestly assumed that the focus on this conversation would be to help the children process why they were being muted and what the benefits were to conducting a class BUT INSTEAD, the teachers focused on personal responsibility. They took notes throughout the call (on big pieces of paper with a :-) or :-( ... hello retro!) and then used those to help empower the children to realize their own power and responsibility related to the mute button. They helped the children figure out where background noise was coming from and how background noise impacted the class discussion. They had different children muting and unmuting themselves so that they could get a sense of the difference and talk about it together. And they ended with helping the children be excited about helping one another to be heard and recognizing their own power, ability, and responsibility to the rest of their classmates and friends.

I've been thinking about this all week and waiting to find time to write a blog post about it. In summary, what an interesting concept and perspective? While this is an example on a preschool level, I've been thinking about it in the professional world as well. How do we exercise our responsibility and power to ourselves and to our friends related to muting? How can we more effectively notice when someone unmutes and give them space? How can we recognize what our background noises are (either real or metaphorical) in order to be more present or also just be aware of when we may not be able to speak because the actual or mental/emotional background noise is too loud at the moment.

First, the anxiety. I feel as though I've settled in to a new, higher baseline level of anxiety. Even when I try to I seem unable to fall asleep before 2am. Every evening is spent reviewing the previous day and determining what will change for the next day. Do I need to wear a mask to the same places today as I did yesterday? Can we do the same activities? Should we get delivery groceries instead of shopping ourselves once every 2 weeks? We're so conflicted on food delivery. What are our thoughts on it this week. How is our grocery pantry? What will it look like 3 weeks from now and is there anything I anticipate needing in the next month that needs to be ordered? Because if so, I should put that order in now.

And part of this anxiety is a crushingly new level of mental load. How are the kids? Are they doing ok? Are there new behavioral issues to address? At this age, social interactions and dealing with peers is the most important thing for development... how can I facilitate that when my children can't actually be around any of their peers? What are fair and unfair expectations for young children living through a changing world? What should their schedule be? Am I not spending enough time thinking about what my daughter needs because I'm trying to craft a more effective schedule for my son? When does my mom need groceries again? Should we try to drive and see her this weekend even though we can only stand far apart and the kids lose their patience pretty quickly? Are my partner and I coping with everything ok? Are there improvement we need to make working together? When was the last time we tried to create an at-home date night or something special for ourselves so that we're supporting each other and not just trying to keep everything else running ok? At first, it just felt like every night there was just a little more to review. On top of the normal stuff like, oh, I have to switch out the kids clothes for the new season or a new size, there were a few additional things to talk about. But... we're talking about all these things most nights, and there's so much left to do once the kids go to bed. And then I'm getting less sleep. It's ... exhausting.

Second, I am jealous. It's not something I want to admit or that I like to admit but I'm jealous. I'm jealous of people who have stay-at-home spouses and I'm jealous of people who don't have children. I love my little ones but for me, this all is a constant 24/7 balancing act. The are no side projects, I am not continuing my work on my manager tools repo which I was so excited to get kicked off earlier this year. I'm not thinking of new conference talks, or finishing writing the ones that have been accepted for postponed conferences. Even writing this blog post felt like a sacrifice... I'm praying that my littlest doesn't wake up from her nap (or if she does that she will pleasantly play in her room for a bit while I hustle to finish up my thoughts) and that my older one will continue enjoying his backyard time. Because I'm trying so hard to stay focused on my day job during the day, I can't squeeze time in there. I honestly can barely handle work and kids, let alone the fact that I'm still producing the Parent Driven Development podcast, which seems more important now than ever, and on the Ruby Central board, in addition to new "fun" weekend to dos like sewing masks and preparing for lengthy supermarket excursions that need to be carefully crafted, planned, and executed. And it's actually not so much that the work load all of a sudden feels immensely greater, it's that every day and every moment requires more thoughts, more intention, and more brainpower. I worry that where parents were barely keeping up in the past or finding creative ways to keep up with childless peers, we will be completely left behind in this time where we are balancing so much. There is no binge watching, no new hobbies, and no time to find new creative outlets. It feels like there are only more and more to dos that will not get to done for a long long time.

Third is something I've just figured out this week. The past couple of weeks, work has been affecting me more, which felt odd. Work does not seem that much more or less standard that it was a few weeks ago. The amount of tasks and to dos on my plate is nothing extraordinary and definitely nothing I haven't handled in the past. I'm organized, I'm a list maker, I get sh*t done, and generally, almost anything thrown at me I can handle without getting overly annoyed, without getting overly frustrated, or, if I do, I can generally get over it pretty quickly. But the last couple of weeks have felt... stickier. Like it was harder to have things roll off my shoulder, harder to bounce back, and harder to simply say, I've got a lot of stuff to do today, here's my plan for that, or even, here's what I can control so I'll do that and here's what I can't so this is how I plan to deal with that set of things. I think, right now, it's just a little too much chaos for me. It feels like it's coming from everywhere. From home, at work. I'm more frayed and I've found myself needing to be a bit more careful about getting overwhelmed, what to do when i'm feeling anxious, etc.

Okay, so there you have it. Those are all my feels. But now, i've named them. For the moment, I've sort of figured it out, which means I can put in coping mechanisms and solutions because, at the same time, I have a team of people I manage. I need to be there for them. I want to support them and make sure that together we are able to accomplish incredible things. So, here are my takeaways as a manager. Here are the things that I need to be aware of...

• I need to make time to have moments of hanging out, chatting with others, and remembering to connect
• I need to lean on my support network
• I NEED TO TAKE BREAKS EVEN WHEN IT FEELS LIKE I CAN'T BECAUSE I HAVE TOO MUCH TO DO
• I need to take a walk, even if it's late, after the kids are in bed
• I need to recognize and be okay with all of the things that I can't control right now
• I need to get better at determining my 2-3 absolute priorities every day and consider everything else a bonus and finally,
• I need to support my team doing the same

Sitting in the room with other parents all who had varying numbers of kids and children of all ages, 0-18, the day ended up being applicable to much more of my life than just my role as a parent. I was amazed at how many strategies related to creating mutual agreements and buy-in and focused on the choices we make.

For example, the day started with an example of 3 scenarios. In scenario 1, you have new carpeting in the dining room. The rule is everyone eats in the kitchen but your partner, trying to get away from the noise and chaos, takes chili in to the dining room, trips and spills some. In scenario 2, your boss is over for a work dinner and spills some wine on the carpet. In scenario 3, your child is home while you run some errands. They eat some tomato soup in the dining room and accidentally drop the spoon. Thinking through each scenario, your reaction to each individual is likely different based on who they are. However, as you may be able to tell, the basis of the situation is the same... someone stains the new carpet, but your reaction is different. Your reaction is the choice you make.

This idea of choosing reactions and thinking about why you choose certain reactions with certain individuals can be applied to home and work life.

Another tool that jumped out as being particularly applicable to managing teams was reframing the problem. Every morning, we have issues leaving the house. It's easy for me to quickly assign blame in this situation. My son doesn't listen, doesn't do things when I tell him to, and I need to ask him 5000 times to do something. But really, the problem isn't solely his. It's all of ours. The workshop suggests figuring out what the core problem is. Without assigning blame or talking about the who, what is going on. In our case, the problem is leaving the house in the morning. The next part is not trying to solve the problem when angry. We recognize that getting out of the house is a high-stress situation so you set up a meeting specifically to talk about it.

Now, what happens next... At the meeting, you start by stating the problem and that it needs to be solved. Then, everyone gets a chance to offer solutions. Solutions are brainstormed together and every idea gets written down. Once brainstorming is done, together, the involved individuals determine which solution(s) they want to try. This should be thought of as an experiment. There is a problem. There are possible solutions. Let's try something and see if it works. The group decides how long the experiment will last. If the problem is daily, then often trying to stick to the solutions for a week or two is enough. If the problem happens less frequently, then a longer experimental period is necessary. And finally, the group decides how to keep each other accountable. What happens if someone doesn't abide by the solution everyone (including them) agreed to? It's important that this accountability doesn't slide in to punishment and that it isn't thought about in that way, it's simply a reaction or action that will keep everyone engaged and committed to participating in the experiment at hand. And, of course, if the solution doesn't work, then the group comes back together and determines a new solution to try out.

While this works for families (we very recently had our family meeting so I have my fingers crossed that our agreed upon experiment will work), it immediately jumped out at me how effective this approach may be with teams. Creating buy-in, encouraging experimentation, and including everyone in the discussion and decision are key components to successful teams.

Finally, a fascinating component of the workshop was a section called primary emotions. Anger is a secondary emotion. That means that you choose anger (I know. When I first heard this my reaction was, do I really choose anger? I'm pretty sure people make me angry, but stay with me here...). Anger often covers up primary emotions and when you dig deeper into anger, you can recognize what you're really feeling. I thought about the situations when I'm most likely to yell, lose my temper, or feel angry.

For example, when I thought about it more, I realized that my anger in the morning trying to get out of the house is caused by the anxiety of getting to work. I do drop-off and then eat breakfast, get ready, and pump (until recently). All this needs to get done before I have my first meeting of the day. Thinking about it while watching the clock makes me anxious.

In a different circumstance, oftentimes when I get annoyed at my partner for something, I realized it was really because I felt exhausted or overwhelmed by the amount of things I feel I do at home and that manifests in me getting angry as opposed to calmly expressing the way I feel or removing myself from the situation until I can.

Primary emotions are things like exhausted, overwhelmed, devalued, scared, anxious, humiliated, inadequate, disempowered, lonely, ignored, etc.

There was more talked about in the workshop. Some other topics included physical responses to anger or frustration to recognize the early warning signs and understand how your body and brain work when you get angry, mechanisms for helping children of different ages deal with anger, the best strategies to use when you're feeling angry, practicing I statements, and more.

While I was skeptical upon leaving the class, I've actually been working really hard to put these practices in place both at work and at home. The instructors told us we'd just need to keep practicing until these reactions, responses, and mind-shift became second nature. I still need to actively think and keep repeating to myself the lessons I learned but I've been pleasantly surprised at how different our household feels, even just a few weeks afterwards.

Supplemental Links:
PEP, Parent Encouragement Program
Feelings List
Emotional API

• We've recorded over 40 episodes covering a whole variety of topics, issues, ideas, geniuses, and failures.
• We've said goodbye to some panelists and welcome new ones
• We have listeners in almost 10 countries
• We've had episodes that have hit almost 800 listens.
• We've hired an incredible assistant who's helped to so much to keep us on track

I'm really happy with what we've been able to do so far and I think folks who listen to the podcast have enjoyed, laughed, maybe cried a little, learned, and felt less lonely as a parent in tech. But I've still got big plans for this podcast because it's important.

Someone once asked me what would you do to get to your goal if there were no boundaries or obstacles? I've started thinking about challenging projects of opportunities in this way because it frees me from my concerns about thinking about what's realistic or not, and allows me to simply dream big. With that in mind, here are some of my goals for the 3rd year of Parent Driven Development.

1. Garner more financial support

Right now I'm paying out of pocket for all PDD expenses which includes audio editing, podcast assistant costs, website hosting, etc. I think that Parent Driven Development sends an important message and plays a necessary role in the technology ecosystem to make parents feel less alone and make companies and colleagues more aware of common struggles. It provides education, comic relief, and camraderie. But I would love to break even on costs.

Some more specific goals and ideas around doing this are to attract and retain more patreon supporters, engage with sponsors, and attract advertisers.

2. Do more with more support

There is SO MUCH MORE we could do once we're breaking even and maybe even a tiny bit in the black. For starters, a few small things I'd love to tackle this year would be: Swag (hello onesies, nursing tanks, and more!), and small gatherings or get togethers at conferences or events which could include some live recording.

3. Increase listener numbers

We haven't done badly. I'm proud of the number of listeners I have and consistent downloads but our numbers could be better. And the more listeners, the more likely we'll be able to reach some of our other goals, get listener questions, and be able to move beyond, what feels like, the "starter" stage. We're doing more with social media. We're also engaging with different content and brands that we love and who hopefully love us. We're hoping that by reaching out and providing more content, conversation starters, and additional touchpoints, we'll get more listeners, subscribers, and people passing along Parent Driven Development to their friends.

Check out episodes

Support us on Patreon

Contact us if you're interested in sponsorships

Twitter: https://twitter.com/parentdrivendev Instagram: https://www.instagram.com/parentdrivendev/

• Empathizing with anothers perspective
• Being ok with someone being unable to see my logic or thought process
• Responding to other's emotions with kindness and patience
• Recognizing that anothers understanding may be completely different than mine
• Knowing that even when I think im being clear, I'm probably not
• Adjusting my personal styles to fit someone elses
• (Parents of multiple children) knowing that each person is an individual and what works for one may not work for another
• Being confident in the fact that sometimes providing boundaries or rules help the result
• Being comfortable knowing that sometimes I will need to do something that will not make another person happy
• Being ok with someone responding unhappily and at least trying to help them understand the reasoning behind the decision or request
• Knowing that the more resources I can get, the better I will be
• Understanding deeply that I will always need to work on being better
• Telling the difference between what is important and what isn't to me which helps me realize what decisions I can fully empower another to make
• Knowing that I won't know if I've done a good job or not for a long time
• Being efficient AF
• Recognizing tradeoffs and their impact on project, work, home, and other individuals
• Constantly coming up with creative solutions, compromises, and suggestions

What can you add to this list?

First, remembering the responsibility leaders have. As the "Bnei Mitzvah" year (13th year or the age a young Jewish person becomes a Jewish adult with a responsibility to the larger community), this year's theme was all about responsibility. Thinking about what it means to be a responsible leader, thinking about being able to respond as a leader, and more. The week was broken down in to three sections: our responsibility to ourselves, our responsibility to our community, and our responsibility beyond that. In our responsibility to ourselves, there were workshops about self-care and we, as busy individuals, were reminded of how you need to take care of yourself in order to take care of others. In our responsibility to the community, we worked to help each other solve problems, took peer-led workshops for skills building, and had "braindates" with one another. Finally, our responsibility beyond that focused on a massive open space session where topics ranged from educational models around the world, to climate change and what we can do about it, to inclusivity and what that really means. On an extremely important note, the conference ended with us thinking about who took on additional responsibilities in our lives in order for us to attend the conference. From colleagues to spouses to others, for me, it was a really interesting note to end on being sure I took time to think about the responsibilities I was able to abandon for the week and who took on more responsibility so I could immerse myself in the Summit experience.

Second, the conference helped push me to reframe problems. Our three keynotes each dug in to challenges they faced and how they persevered through challenge after challenge. They talked about luck and authenticity, owning your narrative, and thinking through problems and solutions. Spark talks, which were select participant lightning talks, focused around life-changing experiences they had and how perspectives (both theirs and others) were changed as a result. I took a molecular gastronomy class that talked about how molecular gastronomy takes foods we know, adds an element, and completely changes them... not how they taste but how they appear, how they transform, and what you can do with food in different forms. The leaders took this experience and related it to the way we think about problems. Lastly, we went through a lightning round case study session where we got in to groups of 4 and used a specific timeframe and structure to help solve one another's problems, not in an obnoxious advice-y way, but in a thoughtful, sincere way.

Third, there was a focus on really getting to know people. Sometimes, until you're really connecting with people, you don't realize how infrequently we do so in every day life. We were broken up in to small group pods of 5-6 people and immediately dove in to deeper topics. The conference encouraged us to think about telling each other what they would know "if you really knew me" as opposed to just covering where we lived, what we did, and the usual "starter" questions. This was reinforced by workshops and sessions. In one session in particular, we spent 30 seconds writing down how we describe ourselves and sharing that with a pair. Then we met with another pair and described how we were feeling in that moment. It was astonishing how quickly we got past the simple descriptors we usually assume describe us to others and got in to more of who we consider our real selves, talking about real things happening in that moment.

I was thrilled and inspired when the final keynote speaker started talking about each of us leaders as dots and took the Hebrew word Tikvah (hope) and broke it down (a common practice when interpreting things Jewishly is to look at the letters that make up a word and derive meaning from it's structure, the order of the letters, etc.). She said that within tikvah is the word kav which means line. She spoke about how hope connects leaders (dots) with lines. She continued telling an old Jewish tale about a "lost and found" rock that people would go to and how people were responsible for returning lost items there and helping others find and reclaim things that were lost. However, it went deeper than that. The interpretation talked about how this rock was not just for things, it was also for people... people who had lost hope or inspiration and others who would wait at the rock to help them find it again. How we need to get to know people in order to find what is lost and return things to others, especially those who are unlike us.

I loved this conference. Here's the recap video if you're curious: https://www.facebook.com/watch/?v=2378525749103296

A string-wise CRDT algorithm for smart and large-scale collaborative editing systems
"CRDTs Illustrated" by Arnout Engelen
CRDTs and the Quest for Distributed Consistency
A CRDT Supporting Selective Undo for Collaborative Text Editing
A CRDT Primer Part II: Convergent CRDTs
A CRDT Primer Part I: Defanging Order Theory
A CRDT Primer: Defanging Order Theory conference talk
"Practical data synchronization with CRDTs" by Dmitry Ivanov
A Conflict-Free Replicated JSON Datatype
Efficient Synchronization of State-based CRDTs
Efficient State-based CRDTs by Delta-Mutation
Conflict-free Replicated Data Types (CRDTs)
Supporting String-wise operations and selective undo for peer-to-peer group editing
Delta State Replicated Data Types
High Responsiveness for Group Editing CRDTs
Teletype CRDT library

Summary

Parent Driven Development (PDD) is a podcast about being a parent in tech, talking about challenging, interesting, and fun topics from a variety of parenting perspectives. We record and publish episodes every 3 weeks.

We're looking for a Podcast Assistant to help accomplish a variety of crucial audience-growing tasks. You'll work with our teams to:

• Ensure more people are hearing about and enjoying PDD
• Help disseminate and report important podcast updates
• Improve the listener's podcast experience

A week in the life of the PDD podcast assistant

Our panel and guests are distributed worldwide which means a lot of our communication is asynchronous. Your typical week would include:

• Drafting, scheduling, and publishing social media posts on twitter, facebook, and instagram
• Providing regular social media analytics updates
• Manage the podcast calendar to ensure invites are up to date
• Periodically reaching out to media outlets for content promotion opportunities
• Following up with guests before their episode will air
• Establish and send out a monthly newsletter
• Execute guided and targeted low-key PR efforts
• Write brief show notes

Must have

• The ability to prioritize a weekly workload
• Excellent verbal and written communications skills
• An effective process for self-organization
• The desire to be a self-starter
• Experience with social media

Nice to have

• PR experience
• Podcast experience
• Parenting experience
• Experience with outreach and establishing external partnerships
• Remote work experience

Hours: 7-12 hours per week
Compensation: Commensurate with experience

To Apply

Please send a cover letter and resume to Allison at admin@parentdrivendevelopment.com with "Podcast Assistant" as the subject.

So on to the brainstorm. I've run a few guided brainstorm sessions through asking a few prompts. The brainstorm takes about 30-45 minutes. You want to allow yourself time to think through each promot completely and even when you think there's nothing left to thnk of, give yourself an extraa 30 seconds. Additionally, write down ALL ideas. Anything that comes to mind should be written down. Don't censor yourself or start thinking about whether it would be good in a conference context. Write it down and you'll revisit that part at the end of the brainstorming session.

Prompt 1: What are things you find REALLY interesting (regardless of your level of expertise in them)? And this doesn't just have to be related to work or tech.

Prompt 2: What is something that you specifically have done in the past that you've found really interesting?

Prompt 3: What is a code pattern you've implemented that has made things easier for you as a developer? Is there anything that you feel like you must implement when you step in to a code base for the first time?

• for prompt 3, you can tailor this to the type of talk you want to do. So, the above prompt is focused on technical brainstorming but if you were looking to do a talk on a soft skill, the prompt would be something like What are processes or structures you've implements that has made things easier for you as a manager? Is there anything that you feel like you must implement when you join a new team? and so on.

Prompt 4: What are some (popular?) blog posts you've read where your reaction was like, "yeah, I knew that"?

So, now you have a list of ideas. Looking at this list, which ones are you excited about? Pick a color and put a dot next to all of the ideas that sounds exciting to you.   Finally, pick 3, circle those, and noodle on those. Conference talks are difficult. Whatever you want to present on, you will probably end up presenting on half or even a quarter of that information.

Parent Lesson 1: Accept the Differences

As a parent, you quickly learn that your child is different from you (or maybe they are the same as you which can sometimes be worse!) and if you have multiple children they are different from one another. Being able to reconcile these differences manifests in two ways as a manager (and as a parent). First, as a manager or parent I've always needed to recognize my personal style and figure out how to adjust it to fit with the personality of my child or team. As a parent, I am so willing to take a step back in order to determine what my child or children need... do they need more structure? Or more freedom? What sorts of conversations of discipline work best for them? And I've found it differs for each child because they are different people. As a manger, i need to be willing to do the same.

Second, I need to understand and really lean in to the strengths and weaknesses of my children. What do they love to do? And what do they dislike? In what sorts of scenarios do they thrive and where do they need to be coached? My son gets frustrated really easily but if you remind him he can do something and encourage him to break down the process in his mind, he calms down and can solve his own problems. My daughter needs to be left alone. She doesn't want to see you or hear from you. SHE can figure it out and I need to give her a bit of space to do so. Like others, they have different styles and different language works for them. And just because they dislike something, doesn't mean they don't have to do it.

When I work with folks I love to recognize what they are good at and enable them to find a team where their strengths are balanced with their areas of growth and where they can work really well with a team. And I use those lessons from parenting to figure out what sorts of conversations work for each individual to support (and challenge) them best.

Finally, for lesson 1, parenting helps me recognize where my biggest struggles are. Sometimes when my children are the most like or the most unlike me (on either end of the spectrum), it is the most difficult to parent them. Sometimes it's challenging for me to recognize where they're coming from or why they're responding to something in a certain way. Other times, I completely understand and empathize with the issue at hand but I can get sucked in to it as well because I feel the same way. These are the places that are most challenging as a parent and also as a manager.

Parent Lesson 2: Getting Buy-In

If you're a parent, How often have you said or wished you could just say “because I said so”. Think about the most stressful time of your parenting day. For most of us, this is morning time or bedtime. There are so many questions! So many things they should be doing! It's like every morning or every evening they have NEVER done this routine ever before in their life. UGH. Sometimes I actually find myself saying “we do this EVERY MORNING for basically your ENTIRE LIFE. WHY is getting out of the house so difficult?!” (Can you tell what one of my parenting trigger points is?)

But neither in management nor in parenting can I say “because I said so” because here's the thing... no one gives a shi*t. It doesn't matter what I say... in both scenarios. Maybe as a manager you can make your reports do something because you told them to or maybe they'll do it because you asked (this happens sometimes in parenting as well), but it won't work long term. Long term, you'll be seen as the bottle-neck. No one will do anything unless you tell them to do it. And they won't be bought in. They're solely doing things because you told them, not because they understand or because they believe in the actions being taken. And really, again, this isn't comparing individuals you work with to children, it is a situation that occurs in both roles and for very legitimate reasons. So what are some of the approaches the can be employed?

First, take a step back and focus on the problem. Using facts and without blame, what is the problem that you are trying to solve? We need to get out of the house on time. We need to ship a product on time. Etc. Then, leading by asking questions. What do others feel are solutions? What do they feel are aspects contributing to the problem? Or, do they actually know what's next? Sometimes a confidence boost is needed or people just need to feel heard and the best course of action is to say, what would be the next best thing to do here? If you would have picked a different answer, dig in to if it matters. Is your answer more right because it has to be? Or could things be done differently? Others (your children or team) may not accomplish things in the same way you will but it will be accomplished nonetheless.

Second, allowing others to make decisions and knowing when you need to make the decision. Creating buy-in also means empowering others. Giving them choices between two things or even just having individuals decide themselves and using it as an opportunity to stretch where they are currently at. And encouraging others to make decisions also means there can be a conversation about owning outcomes and failures. Sometimes decisions may turn out to be the wrong one. In the car with my son, sometimes we'll reflect a bit on a decision he recently made. If he feels like it was a good decision or a bad decision. What he thinks he might do differently in the future. While I use toddler-friendly language with him, the same important conversations occur with folks I manage because those are their growth opportunities.

Parent Lesson 3: Growing Individuals

It is my job as a parent and as a manager to make individuals better. To help them feel supported, confident, engaged, and challenged. There are a variety of ways in which I do this and language I use with both my teams and with my children and they differ slightly but the core purpose is the same.

One of the things I think is most important is knowing what people are interested in. Allowing people to talk about their lives or encouraging children to direct play are great ways of going about this. Frequently we find ourselves directing activities... let's go to the playground. Do you want to ride your bike? How's that project going? But asking more open questions and allowing others to talk about the things that matter to them or dictate what sorts of activities you participate in can be really enlightening. You can get a sense of what sorts of activities someone loves doing and can dig in to those to create learning and improvement opportunities. This can also be done through asking more direct questions. Asked my children or reports something general like “how are you doing?” Or “what did you do today” will often lead to broad, unhelpful answers. Instead I ask in 1:1s “what's on your mind?” Or I have a list of more specific starter questions I can use (or they can use) to spark conversations. Likewise, at home I'll ask “what made you laugh today?” Or “were you kind to your classmates?” Or even “Did anything make you sad or make you cry today?” I get much better answers on all front that lead to better conversations and discussions.

Lastly, part of helping people grow is embracing the things that you are not comfortable with. People fail and it's hard to watch. You want to set them up for success and you don't want them to feel pain or sadness. With children, the costs can be greater. Sometimes allowing a child to do something you're not comfortable with could lead to injury (for example falling off of a bike) but they are also important things to learn. My son and I are working right now on crossing the street. It's terrifying. The stakes are high. We're currently just practicing in VERY low traffic areas but even though I'm scared, he's ready for the challenge AND one day he's going to need to walk to school or walk around a town and he'll need to know how to responsibly cross a street. This can be the same with folks you work with. Their mistakes could reflect poorly on you as a manager, there could be legitimate consequences or delays shipping a product as a result, and yet, if you don't give them the opportunity to grow in ways that may make you slightly uncomfortable, they will never grow and may not feel that thrill of accomplishment and remain even more engaged. Like my son crossing streets, it's important to find some ways to do this in baby-step style, to reflect, and ensure they're ready for each next step.

So the next time you hear someone compare parenting to management or you say it and immediately roll back the statement for fear that it will be misunderstood, think about all the ways parenting and management can be boiled down to core lessons of communication, recognition, and growth and be happy that if your manager is a parenting, even if they're a little more tired, they're probably a better manager as a result.

But the year of podcasting hasn't been without it's challenges. First and foremost, oy is it difficult to find a time that works for folks. We all have children and jobs. Things come up at work, things come up at home, we try to record at the same time every other week but we'll adjust our time based on guest availability or other things. It is definitely tough to make sure we're finding a time that works for everyone. Next is all the kid related stuff. One panelist mentioned that he thought every snow day declared this winter had happened on an episode recording day. We have to contend with that as well as flu season, illnesses, summer schedules, the transitions to camps and different schedules, and more. As with most of parenting, it all basically comes down to being able to roll with as much as possible and trying to record no matter what... even if only 1 or 3 panelists happen to be free. I wouldn't be surprised if we had a future episode with just one panelist talking about any parenting topic interesting to them. We're also always looking for new or diverse panelists. It's important to maintain a balance of gender identities, experiences, backgrounds, and more. Sometimes finding folks or knowing who should be on our radar is tough. And finally, it's hard to be vulnerable on air for whomever is listening! We're talking about our kids, our families, our failures, and our struggles. We use this time to share these parts of ourselves and we never know how folks are going to react to the things we say or do. Sometimes that can be really scary.

I wanted to highlight some of my favorite episodes (although they're all great and you should go binge-listen now).

• Episode 3: Internet privacy and your children. Thank you to Heidi for being our first guest when we had no idea what we were doing!
• Episode 9: Planning a conference with childcare. Abby came on to provide some protips on what to think about when thinking about offering childcare at a conference.
• Episode 11: Being a Trans Parent. Jess (now a panelist!) talked about talking to kids about gender identity. I learned SO much from this episode.
• Episode 15 where we discuss on-call duty with Allyson which is something so many of us deal with.
• Episode 20 was very impactful for me. We talked with Adam about fertility struggles, one of the most difficult topics to discuss related to parenting and something that affects so so many individuals. and finally
• Episode 23. This one was special to me because it really helped me process a difficult holiday season.

Check out all the episodes here.

Now for a whole lot of thank yous!!! First and foremost, thank you to Mandy who is the most amazing podcast producer EVER. She does an incredible job making sure we all sound intelligent even though we're all so tired, booking guests, wrangling panelists, and more. This podcast definitely would not survive without her.

Thank you to the current panelists and to the former panelists as well. I'm so grateful you all give your time, energy, and parenting perspectives to this podcast on a regular basis.

And finally, thank you to all the amazing guests we've had!!!

Stay tuned, we've got some great topics and guests coming up.

If you have questions, comments, or topics you'd like us to tackle, let us know at panel@parentdrivendev.com

(and we're always looking for patreon supporters and sponsors if that's something your company would be interested in!)

• The Hard Parts of Open Source, Evan Czaplicki
• Git from the Ground Up, Safia Abdalla
• Towards Language Support for Distributed Systems, Heather Miller
• A Little Taste of Dependent Types, David Christiansen
• A Tale of Two Asyncs: Open Source Language Design in Rust and Node.js, Ashley Williams
• Algorithms for DNA Data Storage, Ruthie Nachmany
• Tree-sitter - a new parsing system for programming tools, Max Brunsfeld
• From Papers We Love: The Future of the Grid: Policy, Technology, and Market Changes, Casey Canfield

• Study on Denmark wage gap
• 2014 study on wage gap
• The Childcare Penalty
• You Should Have Asked. A cartoon about mental load
• In Her Sight
• Fairy Godboss
• Lunar Baboon
• Parent Driven Development Podcast
• Parental leave repo
• Dividing Household Responsibilities

Now is where things get a little confusing. I had added my secrets.yml file the .gitignore so that my secret keys, etc, wouldn't be checked in to Git, HOWEVER I had added my SECRET_KEY_BASE to my config vars on Heroku which I felt would solve the issue. I re-referenced the Heroku docs because generally they're amazing and I was really surprised that they didn't include anything about this issue. And I saw a handful of stack overflow answers but they seemed pretty convoluted. Heroku makes it a little difficult to deploy a single file that isn't checked in to GitHub, so, while I originally felt like using a gem for a small side project was overkill, I did end up using the dotenv-rails gem.

The dotenv-rails gem is pretty straight forward. You install the gem and then create a .env file which you ensure is in your .gitignore. Then you add your ENV vars to that file and that's it. Then I redeployed and all was good on my new site.

Teddy Bears Picnic - I liked this book and I even have a record that goes with it. But when you actually READ the story, good lord!! What a creepy plot! A kid sneaks in to the woods and sees teddy bears and has to wear a mask so that the teddy bears don't catch them? That sounds like a horror movie in the making.

The Giving Tree - Oh. My. Gosh. I HATE the Giving Tree. Lots of people have different interpretations of this book and maybe my life experience has made me a bit more cynical but to me, this book is about an asshole man who takes and takes and takes. The woman (the tree) is supposed to just be happy but the guy keeps coming back complaining and taking more. The woman keeps saying it's fine (but it's really not) and then at the end, she's super happy when HE'S finally happy with who she is even though by that point he's worn her down to almost nothing. That, my friend, is a crap story and that tree needed to say "Fuck you boy. You cannot take my trunk, you have already taken my apples, leaves, and branches."

Pout Pout Fish - Now, I was excited about buying the Pout Pout Fish. I wanted a book for my son where everyone and everything wasn't happy. And it's mostly a great book. But the book ends with a shiney fish swimming over and kissing the pout pout fish which turns him in to a happy fish! The moral of this story... physical love makes someone happy and without physical love from another, you can't be happy. What a bummer moral.

This one I found at the library... the Berenstein Bears Tooth Fairy book (this isn't the actual title but I can't remember the exact title)- I remember this one from when I was a child. It was great. BUT it's been redone. The best part of this book is when sister bear gets less money than her friend but more money than brother bear got a few years previously. The book goes on to explain fair market price and appreciation vs. depreciation comparing it to gas prices instead of using it as lesson explaining different people and different socioeconomic statuses or to appreciate what you get.

Sylvester's Magic Pebble- This book is probably ok for a child but pretty traumatizing as an adult. Basically, a donkey finds a magic pebble that grants wishes. He's out one day and gets scared and wishes he was a rock. He turns in to a rock and then can't hold the pebble to make a wish and stays a rock!! (There is a happy ending when, years later, the dad picks up the pebble, sits on the rock and wishes he had Sylvester back.) As a parent, this story is about a child who gets lost!! It is a terrifying read for a mom. Makes me want to cry every time.

Sister Says No - This is an old book from my childhood but what most stands out to me is an utter parenting failure. Basically, the older brother has a play date and his little sister keeps saying no. At one point, the big brother and his friend decide to go in to his room so that they can play without his little sister controlling everything and the mom makes him open his door for his sister! I'm sorry, but let the poor kid play with his friend! And figure out something to do with the little sister who is obviously in the early toddler "no" phase.

Frederick - Frederick is actually one of my husband's favorite children's books but when I see Frederick, all I see is a lazy, totally stoned mouse. This mouse tells stories to keep his mouse family warm in the middle of winter once they've run out of food, but here's what I think. If Frederick had just helped his family gather food and prepare for the winter, then maybe they wouldn't be starving and freezing before winter was over.

I Just Forgot is another one from my childhood but honestly, I find it infuriating to read. It's basically about a toddler who either forgets or doesn't forget but just does what he wants. So sometimes he's like, oh, I just forgot to do this and it made a big mess. Other times he's like, I didn't forget, I just don't like doing that. Tell me, why would I want to read that to my son? All he'd do is get ideas.

Sam and the Firefly is a dangerous asshole who causes all sorts of issues by writing incorrect and misleading directions in the sky. And then, when he's caught, we're supposed to feel bad for him! I just don't.

And now for my top stories...

The Little Engine That Could. THIS is a classic book. I don't think I know anyone who doesn't know this story. What I didn't pick up on though until recently is that all the trains that pass by the toys that need to get over the mountain to the children are men but the little engine is a woman. Basically, the books is about a bunch of selfish bros who won't help a little train until the lady train comes along (it's the only train referred to as a She) and believes in herself to get over the mountain. I guess this isn't an annoying or frustrating book to read, just really interesting thinking about the role of pronouns in children's literature.

And finally, The Sloth Slept On is about a sloth that a group of kids find who escaped from the zoo. They don't realize he escaped from the zoo and so they send him back to the rainforest where he is from, but then the sloth wakes up and asks how to get back to the zoo. This is classic stockholm syndrome and this sloth actually has no idea how to live in it's real habitat. I bet he's eaten by a predator within five minutes.

And there you have it. My rant on ridiculous stories we read to our children. I bet there are dozens more.

So what do I mean when I say compacting garbage collection? Currently in Ruby, when objects are garbage collected, they can't be moved around, which means they can't be condensed in an optimized fashion in order to free up more of the heap. Compaction enables these objects to be moved around and the references to them (a reference tells you where the object is) get updated. A majority of our work so far has been looking at which of these objects can be moved without messing a whole bunch of stuff up and then how to move them and ensure the reference is updated. The terms below are some of the important ones to note and understand when thinking through and solving this issue.

First is IMEMO. IMEMOs stand for internal memos. They are classes that are used internally in Ruby. The Ruby internals are Ruby objects that shouldn't be exposed and therefore are hidden. In order to ensure that they don't get exposed, iMEMOs are specified as the class type so it's more explicit.

Next is an iseq. An iseq, or instruction sequence, is an object with the type of imemo. Instruction sequences are written in c and are compiled to get Virtual Machine instructions. Instruction sequences are important because they are often pointing or referencing objects like strings or other iseqs that we are trying to unpin or not pin in the first place, so that they can be moved and have their references updated. Iseqs were also quite important to us at this point because a lot of the work we did was to disassemble these instruction sequences on compaction in order to allow them to move.

CDHash. A CDHash is a part of a set of instructions. It's a Ruby hash that is stored IN the instruction sequences. When the code is compiling, these instruction settings happen last. This means that objects in the CDHash need to stay alive until the instructions are all set and compiled. In this scenario, alive means that we want to make sure it doesn't get garbage collected before the insturction sequence finishes compiling. When a CDHash is garbage collected before the instructions are finished compiling, the entire program crashes. Understanding this fact was vital in debugging an issue that was happening when we were disassembling the instruction sequences.

The final term I'll go into is an embedded array. Through this whole dive in to instruction sequences, we talked a lot about arrays. You can see in Tenderlove's post a whole segment on instruction sequences and how they relate to a mark array which affects memory savings potential by reducing the size of the mark array. Though this, I learned there are embedded arrays and non-embedded arrays. An array is 40 bytes. A normal array points at malloc data with a specific size (and then the array size can grow) but if an array is small enough, we don't want to allocate any data. If the array has less the 40 bytes of data, then instead of mallocing, we can just store the data in the array itself and then change it to malloc data if the array is more than 40 bytes. When this happens, the elements of the array are embedded inside the array itself instead of in the malloc (memory allocation) meaning it's an embedded array.

Hope this is helpful and allows some of you who are less certain of the complex technical terms to feel like you can dive in and continue to follow our work.

The Good

I'm not sure if it's because I have a child or because it's just become more visible in the industry but it feels like I see parents in tech everywhere. New babies are celebrated and not hidden on Twitter. Moms attend conferences with their kids. I'm part of NUMEROUS slack teams that have parenting channels filled with amazing, supportive, honest individuals. Talking about being a parent doesn't seem as taboo anymore. It feels like jus a regular life thing that happens and that people actually embrace. The tech world of today for parents, while still a work in progress, feels very different than the world of 3 years ago when I had my son.

Along with that fact comes better maternity leave policies. It seems as though almost everywhere I look (although I know it actually isn't all places) parental leave policies are improving. From how long parents can take leave for to the constraints around that time, it feels as though there is a greater understanding and support for recognizing that forcing parents back to work early is not effective for employees or companies. And as companies of all sizes adapt more progressive policies, other companies are forced to do the same in order to remain competitive. That being said, however, my favorite question to ask random recruiters in LinkedIn is "what is the parental leave policy of the company you are hiring for since I only consider working for companies with progressive policies in this area?" If you're not interested in recruiters contacting you, ask this question and most will stop messaging.

Next, I'm glad that this time around I'll be more experienced in tech. For my first I had only been at my first full time job in tech for 10 months before having a baby. That is NOT a lot of time. Everything still felt so new. I never had any idea what I was doing and I was trying to build confidence in myself as a developer and then I was out on leave for 6 weeks. 6 weeks is not a long time to be out when you're a first time mom but it's also a lifetime when you're a new developer. Not looking at code for that time set me back a bit and returning to work while still super sleep deprived and just barely understanding who I was as a mom and who my baby was made jumping back into everything as a junior developer really challenging. This time, as someone with a few more years experience, I don't think it is going to feel quite as foreign to come back and I have a sense (although I could be totally wrong about this) that it won't be as difficult to do little things like watch conference talks or read blog posts while on leave (if I choose to do so!)

And finally, knowing what's up. This isn't related to tech at all, it's just me. I can go into this new parenting experience with a little more knowledge about what it's like to be a parent. Every child and every pregnancy is different but I know how I changed as a person, how my brain chemistry and learning style changed, and how I am as a parent with my first. I have at least some sense of what to expect the second time around. I am going into the experience with better resources for what I need to be successful as a mom of two and more confident in myself as a mother. Even having a broad idea of what to expect and what I may need as an individual, new mom, employee, and more feels like I'm starting this journey in a much better place than I did with my first.

Oh and also onesies!! So many more companies have adorable baby onesies now! I can't wait to outfit my new little lady in as many baby tech clothes as I can get my hands on.

The Bad

There are lots of great things about being a second time mom and lots of positive changes I've seen in tech over the last few years, however that doesn't mean there aren't things I'm still dreading a little bit. Here are the things I'm not looking forward to.

Pumping. Uugghhh. Pumping is the bane of my existence. By far the worst part of being a working, breastfeeding mom in my opinion. That heavy pump you've gotta lug around with you everywhere. The forced breaks you have to take in order to do it. And for a full year! It honestly seems like forever when you're in the midst of it. I pumped for a year with my first so he'd have breast milk until he was a little older than that and intend (hopefully) on doing the same for this second child. Fortunately, I work from home so there are a whole slew of logistics that I don't have to worry about and I really only have to lug the thing around when I'm traveling but one of the biggest downsides to being remote and pumping is that you're basically tied to your house. I'm not sure what my schedule will be like with number 2 but with my first, because he was not good at nursing, I was pumping about every 2.5-3 hours. This often meant it wasn't worth it to try to get to a coffee shop or cowork because by the time I was settled, I'd have to head home. There's basically no way to pump at a coffee shop and a vast majority of coworking spaces do not have locking, private lactation facilities either. When basically every break you take during the workday is allocated towards pumping, also being remote and tied to home really increases your isolation factor and, for me, is definitely a struggle.

Next, Recognizing the impact it will have on my career. I think with adequate maternity leave this time around the impact might not be as tremendous but in the talk I've done, BDD: Baby Driven Development, I speal about an answer to a survey question where parents answer if they feel having a child(ren) has had an affect on their career and if so, what this affect has been. The results are fascinating. More folks who identify as fathers feel having a child has had a neutral or no affect on their career however an overwhelming number of mothers feel it has had a negative affect. As I mentioned earlier, after 6 sleep deprived weeks, it was challenging to jump back into code. I had a lot of ramping up to do and that ramp up was slower as I learned how my brain worked differently. Additionally there is the greater mental load that comes with being a mother. Even if you and your partner are fantastic at sharing responsibilities related to house and childcare, it's still very likely that the woman will take on a lions share of the mental load of being a parent. There are hundreds of small tasks related to being on top of children-related things and making sure your household is running smoothly. Having to keep track of all of that plus transitioning back to work (while pumping and with a sh*t-ton of new hormones in your system) is incredibly challenging. Career driven moms want to be awesome and want to be successful and I think a lot of us put a lot of pressure on ourselves to be all things to all people all the time. Plus, being a new mom means making some sacrifices. I spoke at a lot of conferences last year and while that was awesome, this year I've applied to less because of third trimester travel restrictions, knowing I won't want to travel just after the baby is born, etc. Taking this sort of break is challenging for me and when I am able to return to conference speaking, I can't do quite as much as a mom of two with a full time working spouse. I'll need to be a little choosier about which conferences I apply to and what opportunities I seek out without letting that part of my career, which I love(!) go completely. In short, this time around, one of my goals is to recognize the impact all of these factors have on each other and be the best I can be while being realistic which, most weeks, will probably mean feeling like something won't be quite as successful or prioritized as I want it to be.

Also, the prebirth schedule. Hi. It's currently 5am as I write this. Why am I writing this at a ridiculous hour? Because biologically, as you get closer to your due date, your body switches you from being on a 12 hour circadian rhythm schedule to being on a 24 hour one which is what your baby will need. That means I'm awake. Every night. From about 3:30-5. And I'm super tired. Every day. From about 11:45am-2pm. Know what that's not convenient for?! A FULL TIME WORKING MOM WITH A TODDLER WHO IS NOT DRINKING ANYTHING CAFFINATED!!! At least I feel like I'm using the time productivity this evening to write a blog post.

Finally, all the logistics. Do you know how annoying it is to think through attending an event or a conference as a breastfeeding mother with a full time working spouse?! There are about 1000 things I need to organize on the homefront before going away in addition to thinking through everything that will need to happen at the conference. This includes... will I have access to a fridge and freezer for breastmilk storage purposes, making sure you've got all the parts and pieces you need for pumping, coordinating with conference organizers about what pumping facilities will be available (this is getting better, thank goodness, AND I'm more willing to be picky about what conferences I won't attend if they don't respond or don't have any available facilities, but 3 years ago it was a serious pain!), depending on where the conference is and where those lactation facilities are, how much of the conference will I miss because I'm pumping, and what is the travel like? Will I need to pump on the plane (which sucks and is still not something I'm super comfortable with) or at the airport (probably in a bathroom stall), how difficult will TSA be about getting breastmilk though security, how difficult will gate agents be about having a pump as an extra carry on, etc. (see, I told you pumping was super annoying). All of these factors are enough to make anyone think, well, I'll just stay home instead. They're not unmanageable but they are really taxing to think through.

I don't know if everyone feels this way but I feel like there are both things I'm excited about and things I'm not as excited about. That doesn't mean I'm a bad mom, it means I'm a person with complex emotions. In the end, though, there is something really awesome and powerful about being a full time working mom. At the end of the day, how many of your colleages can say they shipped a feature while also growing a freaking human inside of them! I'm looking forward to where this new journey, with this new child, takes me and what sort of kiddo this next one will be.

First, think about the goals. I like the think about these gatherings in a few different pieces.

Ideally there is group bonding and a sense of camaraderie that comes out of the week (or few days). This may happen on a few levels, so you can think about it as team, department, and company because it’s important folks leave the week feeling energized and closer to all three of these entities.

2. I think it’s also important that there is some sort of professional development or learning that takes place.

3. I like for these weeks to be fun.

4. Provide updates and increase transparency. This could happen at all levels. What needs to be clarified or worked out for your immediate team to be more effective. What’s new in the department that needs to be discussed or addressed. Finally, what inspiring company-wide message needs to be given to both inform and encourage everyone.

With these four goals, it’s time to get to planning. I’ve found it helpful to break up days into subject so that folks know what is more or less planned. So, for example, if you have 4 days, your schedule may be: Day 1: Team day Day 2: Department Day Day 3: Company Day Day 4: Learning Day

Then figure out which elements should be put on each day. Here are some options to consider. On team day, group code review, mob programming, or discussions about team process and flow could be helpful.

On department day, workshops bringing everyone to a more similar level on a technology you’re hoping to move to or even talking through patterns/best practices that the whole department will adapt would be great. Something like talking about a new department style guide, pairing practices, or doing effective code review is great. These discussions and workshops tend to take longer and be more in-depth because there are more people involved and folks may be at different levels or have a variety of opinions. Additionally, you could also have a longer fun activity that gets everyone socializing and speaking with one another.

On company day, I’ve seen day-long hackathons related to the company’s core values, a substantial company update, and some of the fun activities I mentioned on department day. You could have a fun activity on both days, one that includes more folks from different departments that your team/department might interact with and one that is only just the department. Depending on how large your company is, department day and company day may be pretty similar or they might be very different.

Finally, learning day could be an unconference broken up by lightning talks (not necessarily about tech but about anything anyone wants to speak on) or even paired or group learning that folks sign up for in advance.

On each of these days it’s important to think about the fun components as well, even if everything isn’t company sponsored. What’s going on for lunch? How about dinner? Is there a game night or some sort of optional evening activity? How are you making sure all these activities are accessible and inclusive as well. What is mandatory and what is optional?

This might seem like a lot of work but you really aren’t planning four full days of activities. And remember, some things should be passed off to individuals. The planning team should have a point person on each team that will determine what that team is doing for team day, etc.

Here are some general tips:

Set expectations with the team. If you have folks that are colocated and others coming into town, this step is even more important. How much are folks expected to participate in? What’s the expectation about daytime vs. evening events? What is or isn’t family friendly? When are the travel days for remotes?

Plan with a team. I’ve never worked at a company where a person had this sort of planning as part of their job which means folks are often trying to come up with a successful event while also accomplishing their other regular tasks. If you have a team planning with you and divvy up the responsibilities, everything will go much smoother.

Have a “master of ceremonies” or know which teammate is in charge of each planned item on the agenda. The most successful gathering I’ve planned had a shared google doc which each item written down chronologically. The document listed the name, time, location, and point person for the session, as well as a brief summary of what was needed from the point person (ie- MC lightning talks, or introduce guest speaker, etc.) and a list of any materials needed.

Put scheduled sessions in everyone’s calendars as early as possible. This helps folks plan out what their week will look like and determine what a realistic workload looks like for that week since the focus is team bonding, but oftentimes real work does need to get done as well.

Send a survey afterwards. There will always be more to improve upon as the team changes. Make sure to send out a post-gathering survey to get anonymous feedback, thoughts, and opinions.

The goal is to have everyone walk away excited about where they work, loving their team, and ready to dive back in and do awesome work.

Being a mom in tech Written December 9, 2015

A few years ago, I transitioned to being a software developer. I was doing nonprofit management for a few years, left it to launch a startup, and through that decided to learn to code. While I expected to hate it, I actually loved the challenges that programming brings and knew it was an industry I would never be bored in. I’ve been a developer for almost two years now and I do love it. It is challenging and interesting and I learn something new every day… which is not something I could say two years into any position i’ve had in the past. BUT therein lies the challenge.

When I started I put in HOURS of extra time. I knew as a career transitioner and an experience professional who was new to code, I’d need to put in the extra effort to get up to speed. I’d spend my weekends working on code side projects, studying more about the methods, practices, and tools we were using at work, and would watch videos, read books and do as much as possible to stay up to date.

As a women in tech I also didn’t mind being the only woman on a team. I didn't really feel different than anyone else, didn’t think I was treated differently, and when my female perspective was different, I treated it as a way to widen others’ perspectives and not something to shy away from.

And then everything changed… then, I became a mom.

Being a mom in tech has been one of the most challenging adjustments I’ve ever had and I am still working on how to balance life and work.

Because I learn something new every day, I need to be sharp every day. Something that isn’t always possible if your baby is having a bad week and you’re getting significantly less sleep every night. The weeks that I only get 4-5 hours of (interrupted) sleep a night and can’t depend on a few cups of coffee during the day to give me those pick-me-ups are tough.

Because I dive into tasks and can work on a problem for hours at a time in order to really understand and solve it, pumping is difficult. I have to pump every 2-2.5 hours in order to have enough milk for my little guy every day and when I pump, I need to force my brain through an enormous context switch… from knee-deep in some technical issues to a relaxed, clear, calm mind that mimics how I would feel if my baby was nursing. I’ve tried working through pumps before and I can do some ancillary email or light-weight tasks, but I can’t continue pushing through a complex technical problem. (and thank goodness I work from home because the days i’m not home and need to find places to pump are even more difficult).

And because I need to continue learning and continue improving my skillset, I need to find blocks of time outside of work to do so. There are no 4 hours blocks of time in my life anymore. Remember, even if I have 4 hours, I need to pump at least once during that time and the moments i’m spending leveling up myself are moments that i’m not spending bonding with or leveling up my child. It’s hard to figure out which is more important and when because neither is more important all the time. It makes it extremely difficult to decide if i’m going to commit to open source, work on a side project, or read some material on a subject i’d like to learn more about… all these options weighed against spending quality time with my child.

While it’s great that I have flexible hours in my industry, it’s also challenging because there isn’t as much understanding around the idea of a hard-stop at the end up the day. And while i’d never noticed many differences between me and my co-workers, those differences are getting harder to ignore and harder for them to relate to. And I understand… they don’t have the context and have never been new dads which might give them some empathy but still isn’t the same as being a new mom.

Being a mom is a new and different experience. It is different than being a new dad in tech, it is different than being a woman in tech. It is just different. I can’t be the only one that feels this way… newly pulled in different directions and trying to determine how to balance it all so that we’re advancing ourselves and our children, giving as much as we should be to our family and our jobs without feeling exhausted all the time.

When we're looking at upstream and origin, we're basically just looking at working with 2 different remote origins, one origin and one upstream. Upstream is the original repo. When you commit to open source, you often fork the repo and then clone that repo locally, so you need to set 2 remote origins. You need ot set upstream to the original repo so that you can rebase and make sure to keep up to date with any changes that happen there. And then you also need ot set origin which is your fork of the repo. Setting the origin to your fork is just like a regular workflow… you want to set the origin so that when you push, pull, commit, etc. you're doing so from your copy of the repo. And now here's the best part… you will always have pull access but not push access to upstream. It only ever acts as the root so we can make sure to be keeping up with the MOST recently updated version of THEIR master. This also means that because you don't have push access, you really can't F anything up.

Just knowing all of this information makes me so much more comfortable with the idea of contributing to oepn source and gives me a much better understanding of both upstream and origin and why we use both remote origins when contributing to open source.

Eventually I decided it was time to make the idea a reality and so it's finally coming to fruition. Parent Driven Development will launch sometime in January and will start by releasing one episode a month (although we're excited to increase the frequency of that schedule if our audience wants more!). The goal is to talk about all sorts of parenting related issues, focused on both children and parents. For example, how do we practice self care as developers and parents? How do we continue learning and stay on pace with peers? We'll also cover additional topics like the importance of parental leave and supporting parents as they return to work. And finally, tougher issues like internet privacy and children, handling difficult situations at work, how to talk about race and gender identity with children, and more. I'm excited that we'll have a diverse panel of folks from all different backgrounds and children of different ages. This podcast will not just be for parents.

Since I've spoken more publicly about my triumphs and struggles related to being a parent in tech and bringing my child to conferences, I've had tons of people approach me. Some ask what it's like to use conference childcare, others say it's nice to know when they have children that they don't have to drop out of the tech world or pick a different career. I've heard dozens of stories about the successes and failures from parents themselves or about the companies they work for. I'm hoping this podcast will bring visibility and an awesome support network for parents in tech, as well as be a valuable source of information for managers, hr representatives, and colleagues looking to support their peers.

Stay tuned for updates as we get our website up and plan for the release of our first episode.

If you or your company is interested in sponsoring or contributing to this project, please let me know by emailing me.

First, use git push --force-with-lease insted of just force pushing. What does force with lease do? Well, it ensures that you're not overwriting someone else's code with your own to make sure you don't lose work (and piss off your coworkers). Recently, a coworker and I were working on the same branch AND we were working alternate hours and irregular schedules. We tried our hardest to make sure we were communicating when either of us did work on the code and what we changed but we also knew that wouldn't be perfect. So we also made sure to use --force-with-lease to make sure we weren't overwriting each other's changes.

Second, I learned about git reset --hard head^. In the past, I've always used git reset --hard HEAD~<number> trying to figure out how many commits I needed to roll back. This is most commonly used (for me) when I accidentally commit onto the wrong brach (for example master when I really want to commit to a feature branch). By using git reset --hard head^, the carrot essentially "pops" off the last commit so that you can then switch to the branch you wanted to ACTUALLY commit the code to and commit it again.

Goal:

To have folks think critically about the company values and how they relate to them individually and their team.

To solidify in peoples’ mind’s what the core values are and how to incorporate them into every day thinking

Trigger: Break the group up into the number of teams equal to the number of core values you have. For example, if the company has 3 core values, break into 3 groups. If there are 10 core values, break into 10 groups, but try to have no more than 8 people and no less than 3 people in each group.

Give each group 1 large piece of paper with 1 core value written on it and some markers. Each group will have 10 minutes and then will pass the paper clockwise. Do this until every group has gotten every paper.

In those ten minutes, discuss the core value as a group. Write down on the paper what you think of the core value? What words or concepts come to mind when thinking about this core value? What are some ways in which your team demonstrates this core value? (if the group is comprised of people from multiple teams, you can write down ways in which each team demonstrates it and if there are any ways in which all the teams demonstrate the value)

facilitator note: it might be helpful if you have a screen or whiteboard to write the above questions (and any others you add) so that groups can check in and remember what they’re supposed to be writing on the paper. Also, on these papers, people should feel free to be creative. They can write words, stories, sentences, or can draw pictures.

Discussion: Have each team skim over their paper and then take 3 minutes to present it to everyone else.

The presentation should summarize: What were some examples of things written down? How did groups interpret each core value? Was there duplication or agreement about a particular set of ideals?

Put all the papers up on a wall (or table) and give everyone 5-10 minutes to walk around and read through the papers.

Then reassemble the group for the discussion- Which core value do you think is most important to your team? Which is most important for you as an individual?

Conclusion: Give each person a smaller piece of paper with 1 section per core value. Give the group 10 minutes to individually write down in each section how they incorporate (or want to incorporate) each core value into their day-to-day.

Feel free to discuss these with your manager or hang them up in your workspace so that you keep them in mind as you go about your day-to-day work.

Supporting materials:

Core values and any information written about them

If possible, documentation about when, how, or why the core values were determined and how they came to be

Materials needed:

• Large pieces of paper with 1 core value written at the top of each.

• Markers

• Pens

• Smaller pieces of paper with core values in sections

• Find the room safe. This will keep your child occupied while you childproof the rest of the room.

• Stuff pillows in between the bed and the nightstand. Most hotels have a rectangular or square nightstand in between the two beds (or next to the one bed if you're still using a crib). There is usually a small gap and sharp corners, but shoving a pillow in there will keep you child from getting caught and from bumping into the corners.

• Unplug all the phones, both the phone from the wall and the receiver from the phone base. Added bonus, your child can now walk around the room "on the phone" which is really what they want.

• Find the refrigerator (which you probably need for milk, snacks, etc.) and tape it shut. This way your child won't open and close it incessantly over the next few days which will likely drive you bonkers.

• Take any chairs and put the back of them against the side of your kid's bed to act as a bed rail.

• Put extra pillows on the floor on the side that does not have chairs as the bed rail.

• Always use the security chain or extra lock at the top of the door. Most hotel room doors are easier to open than your doors at home. If you're really lucky, your child will figure out that they can open it while you're in the bathroom or doing something equally convenient.

As an aside, I've never had to do this, but you can also use washcloths and tape them around any sharp corners.

Materials needed: Duct, masking, or painters tape. These three tape options will be sticky enough for what you need but won't damage any of the hotel room.

I love this theme. It started in Matz's keynote, where he shared that he is honestly embarrassed by the phrase MINAWAN (Matz is nice and so we are nice) and instead wishes RINASWAN (Ruby is nice and so we are nice) had caught on. It continued through Chad Fowler's talk on growing old and Andy Croll's talk on the impermanence of software. Both of those talks focused on how the code you write goes away, it gets refactored, it dies and that how you treat people, mentor others, and show your kindness are paramount to the code you write every day. Finally, the theme was concluded with Sandi Metz's talk You're insufficiently persuasive where she used psychology and books like Influence and How to win friends and influence people to talk about what makes people and teams happy when dealing with one another. She dove into the idea of psychological safety which is about being nice to folks and making everyone feel comfortable and left us by saying "you are good enough.”, something we often don't hear enough of in the tech industry. The idea of being nice, reaching out, and the importance of our Ruby community was concluded in the ignite talks after lunch on that last day (which I was lucky enough to participate in).

All of this talk about code and growth and being good enough got me thinking deep thoughts about my career. At times, I feel as though I'm becoming the same developer with a few years of the same experience and not a developer that is constantly being exposed to new challenges and opportunities. This realization strikes panic in to my heart. I've posted before about my dislike of code challenges for a variety of reasons, but, honestly, one of those reasons is I'm just plain not good at them! For years I've worked in super complex legacy code bases. Ones where the schema is challenging and every ticket is an adventure (not always in the fun way). In legacy codebases you have different considerations, you need to carefully consider various problems and solutions not just in regards to the bug or feature you are building, but thinking about the system as a whole. While this is a super valuable skillset, it also means the number of times I spin up a new application or write def initialize is minimal, leading me trying to remember those early days of coding whenever I even think about doing a tech interview. These are gaps I need to fill and that I want to fill.

I also am very honest with myself and I know that I have limited outside of work hours and bandwidth. There are some things I can drive myself to do solo, but this is not one of them. Over the next few weeks, I'll be looking for pairs, preferably on open source projects. People who like teaching and pairing, to work with me on some of these fundamentals. If you're one of those people, please let me know.

• What I think makes a strong conference proposal{:target="_blank"} from my experience reading over 500 talk proposals for RailsConf. Also related to RailsConf was how to RailsConf successfully{:target="_blank"}.

• A fun piece on how we work remotely{:target="_blank"} with some tips from the team.

• Running a retrospective through the lens of your company's core values{:target="_blank"}. After all, they should be more than just posters on the wall.

• An excellent workshop I attended at Codeland Conf{:target="_blank"} about Web Based Virtual Reality{:target="_blank"}.

A few posts based on conferences I've been speaking at:

• Write/Speak/Code and what makes it so special{:target="_blank"}.

• Strange Loop and the power of learning{:target="_blank"}.

• All Things Open and Open Source at Collective Idea{:target="_blank"}.

I hope you enjoy!

I'm not a new developer. I'm no longer a junior developer. But that doesn't mean that I'm not learning new things. That's part of being a developer, right? Continuing to be faced with problems and challenges that you need to solve and architect solutions for. I love that there are new things I face every day. It's honestly one of my most favorite parts of being a developer. And I do a fair amount to track my learning and growth. I journal. I have a digital notebook where I outline both what I want to learn and what I have learned. I do personal retrospectives every week that summarize what I've learned. I keep a "happy thoughts" folder where I have documents with positive feedback or screenshots of recognition I've received. And I make sure to reflect on where I was 6 months ago, a year ago, a few years ago, etc. But there are so many new things and what I'm realizing is that my attitude and confidence level are starting to make the largest impact on my productivity level.

I'm sure I'm not alone here. Sometimes I feel like I can tackle anything and other times I feel like I'm not even sure if I've learned anything over the past few years. But, it's not about practice. When I first mentioned code confidence on twitter, a lot of people responded with ideas for code exercises I could do, but I know that's not the core of the problem I'm solving. It's not about practice, it's about the fact that when I feel confident, on days where I'm making progress and feeling good, I accomplish a TON. I tackle hard problems. I pick up tickets no matter how familiar or unfamiliar I am with the area they deal with. When I ask questions, they are pointed and have been thoroughly thought through and researched until I truly am stuck. And when I pair, I drive effectively or offer solid thoughts on what direction we should go in next. I can almost always do more than I think I can, but only on those days where I'm feeling confident.

The days where I'm not confident, the opposite happens. I'm hesitant to pick up a ticket unless I can almost immediately see what the solve will be. When I pair, I often offer for the other person to drive and may suggest ideas quietly but infrequently. I think I'll get stuck early and therefore I do. I've worked with some great folks in the past and some not so great folks. I've worked on teams and in situations where the disrespect is obvious and it's hard to be heard or seen as a peer. This is often exasperated by the fact that I work remote. Sometimes in person, it's easier to lift yourself out of a lower place because you have other people around to help you do so. No matter how much chat interaction you have, when people can't see you and you can't see people, it's easy to stare at code and mope until you can reach out for help, and if that request for help goes unanswered or the wrong person answers that cry for help is more easily muted as a remote worker.

The right pair or right sentence can lift me out of a funk and into a better place but I don't want to have to depend on others to do this.

Every year I set goals for myself and every quarter I revisit them. This quarter (and for the next 6 months), I decided that working on my code confidence, or my ability to stay in this confident, more positive mindset for more days or more hours at a time. There are a variety of action steps I've outlined for myself to make progress on this goal but step one is how do I even track this?! I'm curious to learn id there are trends related to when I feel more or less confident. Is it when I get good code reviews from folks on my team? Or does a more difficult review make a difference? Is there a difference between Mondays and Fridays? Do I have confident streaks and then streaks of not feeling confident? Do both trends last the same amount of time? What questions should I be asking myself about this covering some sort of survey or scale on this topic? Does my assessment of the difficulty of tasks I'm working on make a difference? Should that even be noted?

An easy way to track this is to just be able to mark down a happy face or a frown face (or red days and green days) and then go from there, but maybe there are more questions that I'm not thinking about. And if it's just a happy face or frown face, there isn't much context or ability to determine patterns or trends related to it. This is going to be subjective and that's ok. This is really just an experiment for me to think about me, which is why I also want it to be EASY.

Does an app like this exist? Is anyone else doing anything like this? The best way to solve a problem is to know as much about it as possible and so that's what I'm trying to do.

Trigger: Split the group into a few smaller groups (no more than 4). Give each group a repository to look at. Have them pick an issue to look at. Give each group 25 minutes to look into the issue and discuss it. What words are new? What seems like the most critical parts of this issue? How would you go about starting to contribute to this issue?

Take notes, feel free to start coding, etc. At the end of 25 minutes, you’ll present to the other groups what you learned and discussed in form of a song.

Discussion: What feels scary about contributing to open source? What’s challenging about contributing? What’s fun or exciting about contributing to this repository?

Conclusion: Go around and say one thing you’re excited to bring to the open source community *If possible, provide 45 minutes-an hour for folks to actually contribute while there.

Supporting Materials:

• Glossary of common open source words used
• A few blog posts about research into open source contributors or contributing to open source in general
• GitHub’s guide to open source

Materials needed:

• Links and names of a few repositories
• Computers

Most folks generally get some feedback via code reviews which can be helpful but that's a whole different subject and post regarding how to get and give feedback on a code review. Regular reviews are also helpful if your company does them but because colleagues know that salary, raises, etc. are dependent on them, many are resistent to giving completely honest or blunt feedback (and for good reason). I find that a helpful way to get feedback is to check in monthly with the folks that you work with the most... both those with more and less experience than you have. You can ask these questions in a meeting or 1:1 OR email them in advance to teammates. I've done both styles before depending on the personalities of my teammates and what I think would work best.

For people with less experience:

• What do you like about working with me?
• Am I approachable when you have questions or are stuck?
• Am I a good pair? Do you feel our pairing sessions are productive and do you learn from them?
• What do you think is my best contribution to the team?
• Where do I hold the team back?

For people with more experience:

• What do you like about working with me?
• Where could I improve as a teammate?
• Where could I improve technically? and/or technically-speaking, what do you think I should know or be better at compared to other developers at my level of experience?
• What would you like to see me doing in 6 months? (ie- where should I be technically? contributing to the team more effectively, etc.)
• What do you think is my best contribution to the team?
• Where do I hold the team back?

Sites

http://confreaks.tv/videos/rubyconf2016-methods-of-memory-management-in-mri http://confreaks.tv/videos/railsconf2015-speed-science http://confreaks.tv/videos/rubyconf2013-object-management-on-ruby-2-1 https://www.youtube.com/watch?v=kZcqyuPeDao&t=258s

https://www.youtube.com/watch?v=yl_zYzPiDto

https://www.youtube.com/watch?v=t8dj56h2gbg http://schneems.com/2017/05/17/ruby-backend-performance-getting-started-guide/ http://patshaughnessy.net/2013/10/24/visualizing-garbage-collection-in-ruby-and-python http://michaelrbernste.in/2013/05/20/adventures-in-GC-pedagogy.html http://www.schneems.com/2015/05/11/how-ruby-uses-memory.html https://blog.codeship.com/debugging-a-memory-leak-on-heroku/ https://www.sitepoint.com/ruby-uses-memory/ http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code/ http://help.apm.scoutapp.com/

https://ruby-doc.org/core-2.2.0/ObjectSpace.html https://www.schneems.com/2017/04/12/jumping-off-the-memory-cliff/ https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby  https://medium.com/@monfresh/a-trip-down-memory-lane-with-derailed-benchmarks-9d77cbd64f48

http://www.justinweiss.com/articles/a-new-way-to-understand-your-rails-apps-performance/

https://collectiveidea.com/blog/archives/2015/02/19/optimizing-rails-for-memory-usage-part-1-before-you-optimize

https://www.speedshop.co/2017/03/09/a-guide-to-gc-stat.html

https://thorstenball.com/blog/2014/03/12/watching-understanding-ruby-2.1-garbage-collector/

Books

The Garbage Collection Handbook: The Art of Automatic Memory Collection by Antony Hosking, Eliot Moss, and Rhys Jones

Garbage collection by Richard Jones

The conclusion is how you bring it all together. When you run a great workshop, you need to “close” it in a thoughtful way. A conclusion can be a thoughtful statement, a call to action, or a final thought from the group as a way to conclude. One example is having everyone go around and say one thing they learned about themselves during the course of the activity. Another example is having folks write on an index card their next step and keep it with them. Conclusion statements or activities are generally pretty short… under five minutes.

The supporting materials are what give workshops staying power. Sure, you as the facilitator may know everything that needs to be known about the subject you’re running a workshop on, but, if you need to have multiple facilitators (like if you break people up into smaller groups), the supporting materials are how YOU know that everyone knows the information they need to in order to guide the conversation intelligently and thoughtfully. Finally, supporting materials allow anyone in the future to “pick up” this workshop and run it themselves. Supporting materials are NOT books… you need to ensure that your materials are manageable for a person to get through in a short amount of time. It could include a few blog posts, a particularly good article, examples of leadership styles, or a book excerpt (if you choose to provide a book excerpt as supporting materials, try to get as specific as possible and even go as far as highlighting the key sentences or points).

The materials needed are the final portion of running a successful workshop. This part keeps you happy and organized and also allows others to run your workshop successfully in the future. The materials listed in materials needed should be anything and everything needed. Need scissors to cut big pieces of paper? Tape to put stuff on the wall? Pens? Again, this should cover everything.

And that is how you write an engaging workshop. The first few times you work through this, it will likely take you a bit of time but as you run these workshops you’ll get better and better at writing them, facilitating them, and ensuring that you’re leaving a legacy that future employees can utilize as well.

Be on the lookout for examples of workshops like this in the future!

The discussion is an incredibly important piece of the workshop. It gives everyone a chance to actually talk and reflect on the activity they just participated in. They hear each other's thoughts and ideas (and sometimes feelings and emotions depending on what sort of workshop you are running and your goals) and can pull a lot of the pieces together. To create discussion questions, think about your goal and what you're hoping to get out of the activity and tailor your questions around that. For example, if you're asking someone to draw something or chose something, ask them to share what they drew or chose and why. If you're doing some sort of quiz, you can ask people what surprised them about the results they received or if they weren't surprised at all. There are also a few different ways to run a discussion. If you have a large group or a good amount of introverts, try starting the discussion in pairs or small groups. Getting people talking together will help them be comfortable before getting to the discussion with a larger group. And, for example, if you do some sort of a quiz, you can have people get together based on their quiz results and then broaden it to the larger group.

A few tips for facilitators:

1. Get comfortable with silence. If you don't interrupt the silence, someone else will. While it sometimes feels uncomfortable to sit there because it feels like no one has anything left to say, if you just wait a little longer than you're okay with, someone else will often times chime in. Silence also gives introverts a chance to think through what they want to say before volunteering to speak.

2. Ask open ended questions. A closed question is something with a yes/no answer and in a discussion, if you ask a yes/no question, you will get a yes/no answer. However, if you frame the same question as an open question, something that involves responding with an explanation and not just a yes or no, you'll get more involved, more in-depth answers that will often lead to other people speaking and will keep the conversation going.

3. Make sure to call out people who haven't spoken. Don't do this by calling on specific people because that can be intimidating, but if you say something like "does anyone who hasn't spoken yet want to say anything?" It gives folks who might not be comfortable inserting themselves into the conversation the space and time to speak up.

4. Keep the discussion on topic but let it flow. This one is tricky, but if you have a list of questions you want to ask as a part of the discussion, don't ask them as a list. It's weird and makes things feel more like a quiz than a flowing conversation. Keep many of the questions in mind and try to bring up questions naturally as the discussion sort of organically leads to them. Don't worry if you're not good at this right away... this is really tricky to do and takes some practice.

Part 3

Be on the lookout for examples of workshops like this in the future!

The formula for a workshop is simple:

• Goals
• Trigger
• Discussion
• Conclusion
• Supporting Materials
• Materials Needed

We'll talk through the goals and trigger here.

The goal is both the easy and most difficult part. Think about what you want the session to achieve. What are you hoping everyone learns? What do you want the participants to walk away with? You can have multiple goals for a workshop... I usually have between 1 and 3 depending on the topic and audience. Some examples of goals could be: To help the team learn about each other's leadership styles. To understand and work through different communication and conflict styles. To help each person look at what type of leader they want to become. To learn about sorting algorithms.

The trigger comes next. The trigger is what kicks off and gets people thinking. It's the pre-cursor to the discussion. A trigger activity can be anywhere from 5 to 45 minutes depending on what needs to be accomplished to give the participants enough to have a thoughtful discussion about it afterwards. There are hundreds of ways to execute this, including skits, drawing, social barometers, quizzes, self-identification. An example of a trigger would be making a line down the middle of a room and having one side be agree and the other disagree. The leader of the workshop would then make statements and people would choose which side of the line they stand on. Another example would be everyone breaking into groups and learning something and then doing a skit to present that information to the entire group. These triggers are NOT complex, but they're creative, they get everyone thinking and moving and really engaging with the topic at hand.

Stay tuned for the post on what's involved in the discussion, conclusion, supporting materials, and materials needed.

Part 2

Be on the lookout for examples of workshops like this in the future!

1. Find people who have similar schedules

This book club met once a week, virtually, for an hour, during the weekday. For me personally, meeting during the workday was important because I don't have much outside time. This also meant that this group was also comprised of people who preferred to meet during weekday office hours, an important point to realize for book clubs that are looking to have more diverse participants. Another book club meets virtually on Sundays for an hour. A book club does not (and maybe should not) be a lot of people so find a core group of folks that can meet together based on what works in their lives... and the book club doesn't need to be with only work people. One of the things our book club really liked was that if one person had to skip because work was challenging that week, it didn't mean that bookclub couldn't happen. Additionally, having a book club with people who work at different places and in different codebases, led to really interesting discussions and a greater ability to learn from each other's experiences.

2. Meet once a week and have point people

At the start of book club, each person claimed a chapter or two. In order to participate in book club you had to claim a chapter. Claiming a chapter meant that you were "presentng" at the beginning of the meeting. This didn't have to be anything intense, simply a 5-10 minute chat that summarizes the chapter and goes over the main highlights. This way, if someone didnt have a chance to read that week, they could still attend and could still discuss, ask questions, and participate. That person would also facilitate the discussion which often focused around just discussing the different parts of the chapter, looking at code exercises, or talking about what parts we liked or disliked.

3. Every section/few weeks, add in a week dedicated to code sharing/code challenges

One of the main issues that we found was that people did not often have enough time to both complete the code exercises in the book and read the chapter. For Elixir in Action in particular, the book is broken up into three sections. At the end, we realized that it would have been helpful to add a "code" week at the end of each section which would have enabled us to actually write the exercises and share them with one another.

4. Keep the momentum going but allow yourselves 1 or 2 catchup weeks

Book clubs can be long. If you do 1 chapter a week, you're often looking at a 3-4 month book club for most books. It can be really challenging to keep that momentum going through vacations, holidays, busy times at work, etc. It's important to continue to take the pulse of your book club and determine when you might want to skip a week. We did this twice when we realized no one had had a chance to read the chapter except for the chapter point person. Instead of trying to force a conversation, we just postponed the chapter to the following week and used that allotted time to catch up on reading.

5. Try to set reminders and communicate in between meetings

Our book club had a private slack channel which was great for setting up pairing sessions if someone wanted to pair on an exercise, or share links and resources that came up during our meeting. Additionally, for reminder, the easiest thing to do was to set up 2 reminders. One reminder was the day before book club and the other was 2 hours before.

6. Take notes

Each week, the note-taker was the person who would be "presenting" the following week. This note-taker then put up a pull request in our book club github repo. This is helpful to look back on but was also helpful if someone had to miss a week of bookclub. They could easily catch up on what they missed.

Book clubs can be great but they can also be really challenging to run successfully, especially with certain books that might not have as much fodder for discussion. What do you find that works? Or if you still haven't hit on something, feel free to try these tips out.

Goal: To help individuals think about their current values as a leader and reflect on how they have changed in the past few years

Trigger: Have each laptop sticker represent a characteristic.

The characteristics are:

• transparency
• work/life balance
• teaching, learning
• fairness
• integrity
• decisiveness
• authenticity
• empowerment
• communication
• freebie (ie- something you think about when thinking about Judaism that isn’t covered in the other aspects)

Participants have 10 minutes to walk around and this about the things they value the most as a leader. Tell participants they can pick as many or as few characteristics as they would like and they can pick multiples of a sticker if that value is particularly important to them.

Discussion: Who would like to share which stickers they chose and why? Think about which stickers you may have chosen 5 years ago... would they be the same? or would they be different?

Conclusion: There are many different leadership values and leadership styles and we are always evolving as leaders. Feel free to keep these stickers on your laptop or in your office to periodically think about if your values as a leader have changed since doing this exercise.

Supporting materials: none

Materials needed: 11 different types of small laptop stickers with enough for each participant to take a couple, pieces of paper in case someone doesn't want to put stickers on their laptop. Sign that shows which laptop sticker is which characteristic

There are many ways to think about your progress as well as continually jot down things you want to learn more about which can help lead to easily figuring out future goals. This does involved blocking out a small bit of time to reflect but you can do this by leveraging the meetings you currently have to do this. At the end of every sprint, look at the stories you've completed or the pull requests you've reviewed. Determine what you learned during the past sprint. Jot down these items in a separate tab. If you have time, do a little reading about each item in spare moments. If it's not a specific goal, you might not absorb every detail but you'll get a slightly better understanding, and if there is a recurring theme, you can think about making that subject a future goal. If you don't work in sprints, make time to do this every 2 weeks or so. If you remember, you can also do this adhoc... every time you come up against something new, jot it into a note (or whatever system you're using) to read more about it later. I have a running "Things I want to read more about" section with a note for each week and I add topics to it each week. Then when I have a chance, I'll go to that list, start from the top, read a bit and jot down notes in that same file. Do I do this every week? Nope. But it's there and I try to do it at least every couple of weeks without being too hard on myself if this part slips (as long as I'm still accomplishing my larger goals).

You can also use retrospectives to think about you personally. In addition to a team retro, at the end of every week, I take 20-ish minutes to do a personal retro. I learned this technique from a colleague a few years ago. It's simple and to the point. I take out a piece of paper (or a digital note since I like to keep these documented) and I write three sections... Liked, Learned, and Lacked. And then I spend 20 minutes filling it out. I note the things that were great, the things that were not so great, and the things that I learned. I also don't keep this focused on work. Sometimes life is life and sometimes my work week is affected by what's going on in my world. I make note of these things as well because a personal retro for me isn't just a personal work retro, it's a retrospective and chance to reflect on my week as a whole person.

And keep a work notebook. My work notebook is a mix of above, it's my personal retros plus the notes I take on the things I want to learn more about. When I look at the end of every quarter at all of the retro notes and all of my notes on things I've learned, it really helps me assess if a goal fell by the wayside or if I was able to make good progress.

Figure out what tools work best for you. I personally use OneNote or Evernote (you can see more on this in my how I organize{:target="_blank"} post). I have 1 note listing all my goals and then additional notes whenever I learn things or take notes. I'll also go old school often and just write things down in notebooks. You can also use alternatives like Trello, ToDoist, Wunderlist, etc. Whatever you use, just use something so that you can look at your goals and action steps frequently.

Reflect at least every six months. I prefer to reflect at the end/beginning of every quarter to determine if I need to change goals, focus on a specific goal more, or just maintain my current course of action. It's important to set a date and put it in your calendar or on your goals list so you don't forget. If you never look at your goals or never update them, then it's just like you don't have any at all.

Finally, most of the examples I've used in this series focus on technical learnings and challenges, but you can use this same technique for soft skills. For example, if you want to get better at communicating or pairing or giving positive feedback, you can use these same tips and techniques to discover opportunities to practice and evaluate during the work day.

I hope you've enjoyed this series and you have a new excitement towards learning and getting the most out of your work day.

Read Part 1, Part 2, and Part 3

• To have colleagues and peers think introspectively about themselves as a leader and end the workshop with a better understanding of who they want to be

Trigger: Give everyone a large sheet of paper and tell them to spread out around the room. They can grab any writing implements they would like (and can always get up during the activity and grab more/different ones). Explain to them that we're going to spend some time drawing who they want to be as a leader and then we'll discuss it (if they'd like). Facilitator Tip: In between each direction/step, give a few minutes for the group to really thinking about what they're doing (usually around a full 4-5 which feels like a lot but is really important for critical thinking and allowing people time to think of things that didn't immediately come to them when you first ask each question) ... you can judge the room to see how many people are done vs. still working on their drawing

• You can start with drawing the outline of a person, it can be as sophisticated or as simple as you'd like.
• To the side of the person, anywhere on the page, write the three characteristics you think are most important for a leader to have (a leader is whatever you define it as). Put a box around these words.
• Now, let's start filling in the person, think about the whole person. Start with the head, what characteristics do they have? Think about their eyes, ears, mouth, hair, jewlery, accessories, etc.
• Now let's look at the rest of the person... what are they wearing... clothing, shoes, again accessories, jewlery, etc.
• Think about the tools this person needs and draw those... what are they holding, what are they using. Do they have a bag? if so, what's in it?
• Around the person write down all of the things about them, what impacts them as a leader and their leadership style?
• Add anything else to your picture that you feel represents who this person is as a leader.

Discussion: Facilitator tip: Bring everyone together (with their pictures) into a circle

• Who wants to share what they drew and why they chose to draw what they did?
• What aspect was the most difficult to think about/draw items for?
• Now that you are seeing other peoples, what do you wish you had thought of/added to your drawing?
• How is this similar or different from the leader you are today?
• What are some concrete steps you can take to become the leader in the picture... the one you want to be?

Conclusion: We'll go around the circle and say the 1 leadership characteristic based on your drawing that you want to start focusing on immediately.

(after doing that) Feel free to hang your drawings up, keep them somewhere, and refer to them periodically as you're coming up with your goals for yourself and for you on the team.

Supporting Materials: None

Materials Needed:

• Large pieces of paper
• A variety of writing utensils including markers, crayons, colored pencils, and pens _ If you want to get REALLY crafty, you can also use different materials, construction paper, etc. in which case you also need glue

First, think about your day to day tasks. If you're already a professional developer, you likely work on stories (or cards or tickets, depending on what project management tool your team uses). Keep a close eye on which stories relate to your learning goals. As much as you can try to accomplish your goals while accomplishing your work. If you can, the best thing to do is pick up or assign yourself to the story most related to your learning goals/goals. For example, if you want to improve your JavaScript, pick up the story that you know has some simple JavaScript tasks (at first) and then as you learn more, pick up the stories that involve more complex JavaScript. At first you might only pick up a story that involves reading and making a small change, but then as you make strides to accomplishing your goal, you might pick up a story that forces you to write JavaScript from scratch or refactor more complex JavaScript. If you can't pick up the story, pay attention to who does pick it up and ask if they would be willing to pair on it. You might not have control over which tasks you accomplish but if you can pair, even for a part of the story, you'll be learning more about what you're trying to accomplish. If your team pairs a lot, make sure to gradually drive more and more in order to ensure the lessons are sinking in. Finally, if you can't pick up the story and you can't pair on it, make sure to read the pull request closely once it's up. Regardless of whether the PR is open or closed, you can read through what's going on and ask questions on parts you don't know much about or don't understand. If you have a team that won't support the questions you're asking, then jot down methods, syntax, etc. that you want to understand better and look them up when you have a chance.

Second, think about which of your goals are slightly broader, for example, they might touch on more stories. Whereas for a goal related to JavaScript, you may need to really try to pick up JavaScript-related sotries, think about a goal related to testing. You could be learning about testing for every story you pick up and every task you accomplish. Start a story by looking at the tests... do they exist? What do you think of them? Compare them to the file they are testing. Think about why each method was tested and how it was tested. Really think through the foundation that's there. If there aren't any tests, great!! Look at a similar file (if oen exists) to see how tests were written there. If possible, test drive the story you're writing. If your company doesn't allow that, hopefully they at least allow you to add tests afterwards. And specifically call out your test files in your PR. Ask for feedback specifically on your specs and spec file. Depending on how your team is at giving feedback, try to ask questions you're likely to get good answers to. You may need to come up with more concise, specific questions to get the feedback you need to learn more. You will likely be learning lots of different things in every task you complete, but I've found when I have limited time, I can't absorb everything so I learn a bunch but I make sure I completely understand and pay a little more attention to the items related to the goals I've set.

Lastly, think about what additional resources you can use as time-fillers and try to have these queued up in tabs or bookmarks. You likely won't be busy every second of every day. Often, if you're stuck on a task and no one is free to assist, or you're waiting for code review, etc. you can often find yourself with 30 minutes or little bits of time here and there to learn. Find the folks that talk about you're learning goals on confreaks, figure out some good blogs to check out or blog posts to read when you have time. I honestly don't recommend books because if you're trying to learn during work and just have bits and pieces of time here and there I find it difficult to follow and keep momentum going with a book, but if it works for you then have a book handy as well! Find some not-super-time-consuming code exercises (like Project Euler or old code challenges from technical interviews) that you can use to practive. Discover a podcast or 2 that you can listen to when you take a walk or are driving somewhere and note the episodes that relate to what you're trying to be more proficient at.

In summary, you can incorporate all this learning and complete your goals within the confines of your workday if you stay focused and creative.

Read Part 1, Part 2, and Part 4

In Part 4, you'll learn how to assess if you're achieving the goals you've set and how to make time, without making time, to figure out what you've accomplished and naturally determine what your next goals may include.

The next step is to add action steps to each of your goals. You've got broad goals identified and a timeframe in which to complete them. This next step is all about identifying how you will measure success and what you need to do in order to be successful. I usually do this by just adding a few bullet points below each goal outlining the action items. Think through the following questions:

• How will I know if I'm making progress?

• What are the smaller things that need to be learned or done in order to accomplish this goal?

• What is my plan for breaking this goal down into smaller parts in order to accomplish each of those one step at a time?

Goals are larger and broader. If you try to tackle them without a plan and without being able to celebrate small wins, it'll be rough going.

Here are some examples based on the example goals from the last post:

• Write a useful script

  • Research common scripts
  • Determine 3 scripts that might be both helpful and easy

• Understand the basics of relational data modeling and relational data

  • Understanding datatype structures of postgres (char vs. text vs hstore)
  • When given real world objects, how do you UML model that (ie- people)
  • Normalization up to the third level (read about)
  • Practice some SQL statements
  • Joins, different kinds
  • Unions
  • Sub queries
  • Working with a GUI for visualization

• Continue to improve in testing and learn more about testing concepts like stubbing, mocking, and message chains

  • Test setups from scratch
  • refactor and evaluate current tests

• Give constructive feedback

  • Read at least 5 more PRs every week than I currently am
  • Make comments on at least half of the PRs I read
  • Determine what constructive feedback looks like via asking teammates, reading blog posts, etc.

Finally, show these new, beautiful, wonderful goals to a few people. You need some allies to help keep you accountable and motivated. Show these learning goals to a friend, a manager, a peer, etc. and ask if they'd be okay with you checking in with them about it every ince in a while.

Read Part 1, Part 3, and Part 4

I had my son when I was only 10 months into my first full-time developer position after doing a career transition and teaching myself to code. After having my kiddo, I needed to figure out how the heck I was going to keep up and continue learning. While having a child is what sucks all my time (in the most wonderful way possible), I also started to understand other folks. The people that have larger families, are taking care of older or sick relatives, ones that work multiple jobs... copious amounts of free time is NOT always an option. This series will provide some tips and tools to making the most of your work day because in this industry, we've all gotta be learning all the time.

Tip #1 is to create learning goals. You can't focus your desires unless you know what you want to learn. Think critically about these goals. They should be achievable within the timeframe you're setting for yourself, actionable, measureable, and concrete. This is SUPER hard to do in software development because you usually can't set as a goal to build a specific feature, for example, especially if you're looking at accomplishing these goals within the context of your work day. Remember, you also aren't always in charge of your destiny at a company. They could switch what project you're on, change your priorities, etc. so banking on a goal related to a specific feature is challenging. Make sure your goal is also a little flexible and will work no matter where you are. Not to mention the fact that creating measurable goals is challenging.

Make sure to develop goals within whatever timeframe you're determinig for yourself. My personal style is to write goals at the beginning of every year and revisit/revise them quarterly. I try to make most of my goals achievable within a quarter, but there will often be 1 or 2 of them that go a little longer than that.

Measurable goals are tough within software development because there are very few quantitiative measurements you can commit to. For example, you can't say how many lines of code you'll write or how many features or refactors you'll complete. When determining a goal, also think about how you might measure your progress and determine success. We'll talk about this a little more in a future post as well.

Don't write too many goals. I usually try to keep my list to around 5, some smaller and some bigger. Remember, you're confined to the work day and want to make sure you're getting all your work done so don't overcommit.

A great resource to read through is learning about SMART goals. These goals are specific, measurable, asignable, realistic, and time-related. You can read more about it here or by Googling "SMART goals". A lot of these posts provide some really helpful tips for making sure you can actually assess success or failure of a goal.

Okay, so here are some examples, without the additional action items which we'll cover in the next post:

• Learn more about APIs
• Ask at least 100 questions per week
• Write a useful script
• Increase my confidence level as a developer
• Understand the basics of relational data modeling and relational data
• Continue to improve in testing and learn more about testing concepts like stubbing, mocking, and message chains
• Give constructive feedback

Try writing a few yourself and see how it goes.

Read Part 2, Part 3, and Part 4

There are also literally hundreds of different methodologies and ways to run retrospectives. I suggest rotating who leads them (which also provides a valuable training opportunity), and, if possible, allow whoever is running the retrospective to pick what methodology is used. Often times I think teams will find a methodology that works for them and that will be chosen regardless of who's running it, but it's nice to allow for the option to "mix it up" a little bit. My two favorite sites for retrospective ideas are here{:target="_blank"} and here{:target="_blank"}.

Finally, think about how to make retrospectives remote-friendly. For example, use google docs or trello boards, use collaborative whiteboards, have everyone log in from their own computer, etc. Just because a methodology is presented with post-it notes or isn't a remote-friendly format, doesn't mean you can't change it to be so.

I think one of the most important aspects of a retrospective is that teammates respect one another and respect what each individual is saying. If you have a "bad influence" or detractor on your team, one way to help ensure they respect the other teammates is to use one retrospective to "create a contract". This often happens at the beginning of group experiences when you want expectations to be set for how the group will behave but don't want to be the manager or individual that says "here are the rules". In this approach, you start by saying that you want these sessions to feel as comfortable and productive as possible and so it's important the team comes up with the rules they, as a group, want to follow. Generally something about listening and respect will be suggested by someone in the group and agreed upon by the rest.

I'll be posting more tips like this and full outlines of retrospectives and learning workshops, so keep a lookout.

Happy retro-ing!

This is a lot. Really, almost a crazy amount of stuff to be doing on a regular basis. If I wasn't organized, I would probably go crazy. So, I thought i'd share how I juggle all these things and make sure no balls get dropped.

Tweetdeck{:target="_blank"}: Twitter is an important part of how I learn and find interesting things to read. I use tweetdeck to organize my twitter streams and people I follow into specific categories and then I have them listed in order or priority. There are some streams I check twice a day, while others I just check once a week or when I have time. It helps me keep focus on a specific subject and stay in context amidst the twitter noise. It also helps me not miss important announcements like conferences cfp openings or meetups and keep up with friends.

EverNote{:target="_blank"}: This is now a legacy system for me because of their changed pricing, but evernote was great when I used it. It's flexible and searchable. You can even take pictures of things you've written by hand and that will also be searchable (sort of... depending on how legible your handwriting is). You can also organize things into notebooks and you can open up notes in separate windows enabling you to look at multiple notes at once. I use evernote to keep track of to-do lists, thoughts, blog post ideas, conference talk proposals (before they're fully formulated), code notes, and terminal commands or screenshots after walking through code so I can look over it again in the future. The downside is the new free plan limits you to 2 devices and there are always syncing issues.

OneNote{:target="_blank"}: I switched to OneNote when EverNote changed to having their service only available on 2 devices. OneNote is pretty good. The same syncing issues exist in OneNote as do in EverNote. Additionally, the thing sthat really drives me crazy is that OneNote is constantly asking me to sign in in order to sync. But there are some great features. Besides being able to use it for the same purposes as EverNote above (ie- idea management, notebooks, code notes, etc.), but within a notebook, these items can show up as tabs and within tabs you can have many pages. So, for example, I create a list of items I'd like to cover in my weekly 1:1s. I keep a 1:1s tab in my work notebook and then under the tab, I have a "page" for every week. It's easy to find the notebook/tab/page when the meeting rolls around or when I have an item to add to it. The major downside to OneNote is that you can't open up tabs, notes, or pages into separate windows so you can only look at one note at a time. In terms of note-taking/to do type applications, I've also heard good things about todoist{:target="_blank"}, wunderlist{:target="_blank"}, and, if you've got some $$, Ulysses{:target="_blank"}.

Airmail{:target="_blank"}: I'm a big believer keeping up with email. Maybe this is an irrational stresser, but when I've got that red number hovering, I feel like it's something that NEEDS to be taken care of (this is also why I often close my email or hide the app bar when I'm programming.) Airmail allows you to get all of your inboxes in one place. I currently have five email addresses and if I had to go to separate places for all of them, I'd go crazy. The other nice thing is that you can easily file specific emails into folders in a different email address and you can get an email at one address but reply from another which I find really convenient. One tricky part is that any time you need to create a new folder, you need to go into the interface to create it and then re-map the account. Another is that you need to be careful to make sure you're emailing and responding from the account that you want to be.

Github repos{:target="_blank"}: Github is great for a variety of reasons. I use public and private repos for the same reason others do... to keep track of projects and things I've worked on codewise. One thing that's a little unique, I think, is that I use a private repo to keep track of conference talk proposals. For unique conference proposals, I create a folder for that conference and keep any proposals I've submitted under that conference's folder. For proposals that are more standard and the basic information like abstract and details, I just keep the proposal files in root. I also have a file for my bio and the list of conferences I've proposed to or want to propose to with the date of the conference, location, and when the proposal is due. The BIGGEST win for this approach is that when I'd like feedback, I can just create a PR and invite a few people to review it. They can review in one place and see each other's comments to agree or disagree.

Calendars{:target="_blank"}, a few of them: If you think five email accounts are crazy, wait until I tell you how many calendars I look at.... it's eight. A few works ones, a few personal ones including both one that I share with my husband and one that is just my personal one. Calendars are great and I basically live my life by them. My work calendar tends to be pretty succinct and simple but my personal calendars are a bit more complex. Mostly, my calendar with my husband has EVERYTHING. It's how we know who's doing what for which evenings (we each get at least one night a week toddler-free) which allows us to figure out which nights are best to cook (we still cook 4ish nights a week), in addition to things like doctor appointments, conferences, travel, and more. The most helpful aspect of calendaring is using it as a reminder system. If there's something that needs to be done in a few months (like an appointment to be made) or a person I need to follow up with, I set it in my calendar and am reminded to do so. Finally, since I work from home I also use my personal calendar to remind myself to take a walk a couple times a week.

OneTab{:target="_blank"}: OneTab is a great chrome extension that keeps me focused. The premise is simple. If you have lots of tabs open, you can pull them all into one tab. When you pull everything into one tab, it organizes all the tabs/links into a group and then you can close, re-open, and move around the tabs. It's really helpful. I do, however, make sure that once I hit 90 tabs, I take some time to prune them or go through them and read the things.

To-Do lists: I LIVE by my to do list. I used to do it pen and paper but ultimately decided to migrate it to a virtual platform so that it would sync and so that I could add to it regardless of where I was and what piece of tech I had with me. My to do list is fairly specific which is why it's been difficult for me to use some of the other options I metioned earlier. My to do list is broken down by day of the week. At the end of every day, I look at the list for the next day, decide what didn't get done from that day and decide what day i'll move it to. Every weekend I look at every day of the upcoming week and I make sure things are balanced... days i'll have more meetings and therefore might be choppy, I'll put some additioanl smaller tasks because I likely won't go heads down as much, and days where I'm mostly free, I limit my to do list items so I can focus on code. I also look at evenings and make sure I'm only making a day's to do list as long as the amount of time I have in that day. So, for example, if the daytime AND evening look pretty packed, I try not to have more than 4-5 items on the to do list and i'll balance it by having a few more things on the to do list for different days. Now, here's where my to do list doesn't fit the mold... I have a "weekend" section and an "other" section. The weekend section is often things I think about during the week that are personal and need to be taken care of over the weekend. The other section are longer term things... things that don't need to happen this week or next week, but maybe a month from now that I don't want to lose track of. For example, recently I've been thinking about purchasing a new keyboard. I don't want to put this on the calendar because it's not really a "remind me to do this at some point" type of to-do. It's a "when the time seems right and I've got some extra funds, pull the trigger on this". Occassionally if something has remained on "other" too long, i'll try to filter it into the to do list for that week or the following one if it makes sense. Finally, there are a few recurring items on the to do list, like a personal retro every Friday (more info on that below).

Personal retros: Being busy can be really challenging. In order to make sure you're accomplishing and not falling into the trap of being busy for busy sake, you need time to reflect. Every Friday I take 30 minutes to do a personal retro. It's super simple and I keep all the notes in a OneNote notebook. I look at the previous week and think about what I've LIKED, what I've LEARNED, and whats LACKED. This is not just focused on work things but should definitely include work stuff (especially the learned part so you can keep track of what you're learning).

Time blocking for specific types of tasks: The last part of the puzzle is minimizing context switching. I can't code for 30 minutes and then read a book and then answer some emails and then make a haircut appointment, etc. etc. If I'm going to have a lot of meetings, I put lots of small tasks on that day... knock out a few blog posts, think about solutions for a committee I'm on, tweet to recruit speakers for the meetup, etc. Which also means that those tasks are taken care of for the days I do have pretty clear and on those days I can really go heads down and focus focus focus on technical challenges. Even within the smaller tasks, I try to limit context switching. If I know I have a meeting related to a specific topic, I'll try to also accomplish related to do list items.

None of these tools are perfect. There are trade-offs to each one. And sometimes I still go a little crazy or feel a little overwhelmed. These systems took a bit of time to put in place initially, but now that they're established, they've become lifesavers for me and my busy life. I'd love to hear your favorite apps for organizing!

How we use sticky notes for professional development - This is a great post about creating goals and accountability to keep individuals focused and moving forward. The thing I really love about this audio post is that it is an interactive methodology to workshop through these thoughts.

How individual contributors get stuck - A great piece by Camille Fournier about paying attention to individuals. This is a great list of things to think about if you manage a team or do 1:1s. Additionally though, as a colleague, if you are in a company that has little structure or management, this is a great list of things to recognize in colleagues in order to encourage and motivate one another.

Stop setting goals you don't actually care about - Got this one from KWu posting it on twitter. Goal setting is really hard (and I think a lot of people don't even really do it) but it can be super helpful in moving yourself and your career forward. This is a good piece on making sure you are creating goals that work for you and that you want to work for.

The reality of developer burnout - Yes, we all want to advance professionally but it's also important to take care of ourselves. This is a good, short piece about recognizing when things are going wrong and what to do to change it and help yourself.

Code Review best practices and code review in remote teams - Two posts that really break down good code reviews. I'm a big proponent of constructive feedback in code reviews as well as making sure you're talking about the positives of the code as well. These two reads give tangible steps and things to keep in mind when reviewing code. It's hard to keep these things in mind when you're in the midst of reviewing a pr so the next time you do, after reviewing, open up one or both of these and check out how your comments align with these best practices.

In Matz’s Keynote{:target="_blank"}, there were some really interesting things discussed. Matz focused on the community, talking about keeping Ruby relevant through innovation and the strength of the community. He also introduced guilds which is a new concurrency model. Every object belongs to a guild and you can transfer object between guilds. Guilds run on independent threads and every guild is parallel. This seems like an interesting idea that will continue to evolve in the near future. The other thing that was discussed are type interfaced and a new type of static analysis that will be coming that will be like structural typing with type inference… words that i’m excited to learn more about.

I saw an amazing talk by Chris Arcand{:target="_blank"} called Deletion Drive Development{:target="_blank"}. I made a decision a couple minutes into the talk to stop taking notes and just follow along. It was a super interesting talk about figuring out what pieces of code are no longer being used, looking at edge cases and the different pieces you need to look at in terms of looking at the Ruby parser, processing the Sexpression, etc. The slides are excellent and the talk is really good. Highly recommended.

Jeff Cohen’s{:target="_blank"} ’s talk on CS-The Good Parts{:target="_blank"} finally explained to this non-cs degree holder what a linked list is and what a binary tree is so that was pretty awesome.

Tara Scherner de la Fuente{:target="_blank"}’s keynote{:target="_blank"} had some really great points. First, a top to use Docs Doctor which is apparently now Code Triage{:target="_blank"}. My favorite part were her tips for writing… just do it, write a readme, write installation instructions or do the second draft of a thing. To make it good you want to use simple sentences, no jargon, think about the context and user, write your way to the main point and then move the main point to the top, and use specific examples.

Andre Arko{:target="_blank"}’s talk on Contributing to open source{:target="_blank"} gave a very honest look at the tradeoffs to consider when working on open source projects and actually acknowledged why some people legitimately can’t spend the time contributing to open source so applause for that. The part of the talk I liked the most was the overall message that you should do the thing that has the tradeoffs you’re happy with.

Jonan{:target="_blank"}’s talk{:target="_blank"} about using alexa and hal to deploy was really great. I learned a ton of new concepts and it was a lot of fun to watch. I also want to do a shout out to Brandon{:target="_blank"}’s talk{:target="_blank"} about becoming a senior developer was also really good. He spoke about 12 traits of senior developers and different levels that folks will be at for that specific characteristic when they’re junior, mid, senior, or beyond.

Lastly, the talk I think I took the most notes at was Stella{:target="_blank"}’s talk about servers{:target="_blank"}. This is actually something that has come up recently and an area I wanted to level up in so it was perfect. She talked about sockets, listening for requests, handling requests, and closing a socket. There was great information about stream sockets and datagram sockets, stepping through how a server works and common problems or issues.

All in all, as usual, RubyConf was a great time and I continue to love how friendly, welcoming, and nice our community continues to be.

I accepted an offer at Collective Idea a full three weeks before my actual start date. At first I thought that was great! I would actually have some time and space to get things done! And at first it was great... until I started thinking about my new position. That's when the doubts started creeping in... will they fire me in the first 20 minutes of my first day? What if they're disappointed in my abilities? What if I can't deliver what they're hoping I can? Not to mention the fact that I've never worked in a consultancy before so didn't really know what to expect.

Well, I'm happy to say that I've been at the company for over a month now and I'm still employed! I think I'm adding value and hope that I'm seen as a good hire. But that got me thinking... being new is hard! I honestly (and almost laughably) thought that after I had my first developer position, all other job starts would just happen without issue or concern. But there are new and different concerns you have when starting another developer position. For me, these concerns were things like, what would I be expected to know? How quickly should I be able to pick up new things? What is my role/responsibility as a more experienced developer outside of a technical capacity? How many questions are ok to ask? How much time should I allow to learn things? and the list sort of goes on.

As a new person on a team, here are the things I found myself doing:

1. Ask a lot of questions, but try to learn who to ask which questions to. This is slightly more complicated at Collective Idea because there are no managers, PMs, etc. Everyone works as a team, recognizes what work needs to happen where and steps up to do it. Therefore, I ask technical questions to people on my project team (and sometimes outside of my team depending on availability). I ask company process questions to either a few of the people who did my initial introductory onboarding or my 1:1 peer. And I ask company technical questions to learn about preferences like Rubocop, etc. in our general channel. By asking questions to a variety of people in a variety of places, I'm also able to connect with different people at the company and not bother one person all the time.

2. Try to pair. This is definitely a personal preference but I love pairing and I know that pairing is the fastest way for me to ramp up and learn, especially now that I'm working on greenfield applications, something I haven't done in years. I'm sometimes worried about asking in a general room to pair so it's also been really helpful to have a handful of other folks in the company outside of my project ping me to offer to pair. In general though, pairing is encouraged and I've found myself pairing a majority of the week which also helped me quickly build bonds with colleagues, especially as a remote developer.

3. Get a handle on the slack channels. At some companies there are literally hundreds of slack channels so this can be difficult but at ours, the number isn't so overhwelming. It's really nice to scroll through them and pick a handful, as well as ask for recommendations, to learn where some of the off-topic banter takes place.

4. Learn the company vibe. As a person who's got a signficant background in management and company culture, I always feel like that's where I can provide value fastest... and I ALWAYS want to try to prove myself as quickly as possible, but this often isn't the right approach. As a new employee, I need to understand the company vibe and flow, the individuals there, how things work, and how people interact in order to effectively make suggestions or contribute new thoughts and ideas down the road.

5. Get some face time. This tip is particularly important for those working remotely but if you're working remote, try to get some face time in. The first week I was at Collective Idea, I mentioned in our daily standup, and on slack, that I would love to do get-to-know-you hangouts with anyone who was interested. A few people took me up on it and it was great to get to know and a handful of people on the team. Additionally, I was lucky because a company retreat was already planned for three weeks after I started which was the best. Since a majority of the company works from an office in Michigan, it was really great to get out there to visit, chat, and get to know everyone. While I don't think working from an office every day is necessary, face time with individuals and building that rapport is a must.

Those posts weren't up here but instead were posted in conjunction with the Leaky Abstractions group on Medium. Here are the links to those posts... Conference Childcare: For Organizers{:target="_blank"} Conference Childcare: Parent Preparation{:target="_blank"}

This year, I started StrangeLoop at the pre-conference day attending the first ever Elm Conf. Elm Conf was GREAT! Last year, Richard Feldman gave an amazing introduction to Elm talk and i’ve been playing around with/keeping an eye on the language ever since. It was really fantastic to get to attend the first confernece. It started with Evan speaking about the language and community… a great way to set the tone. The moved on to Ossi talking about doing client work using elm and interesting approaches and learnings he’s had through actually using elm in production. Then, there was a talk from Luke about the more human side of programming and elm and afterwards lightning talks. The day continued after lunch with Joel talking about using random in elm through a great example of generating Roman names, Jeff speaking about Storytelling, Jessica talking about a cool new way to use templates which makes programming in Elm EVEN better, and Murphy walking us through a music app written in elixir, phoenix, and elm (this is sort of what I want to explore more) that was pretty sweet. The day ended with Richard talking about using elm to make it impossible to do things that shouldn’t be done (ie- you should only be able to compile VALID css stylesheets) and a Q & A which I sort of missed because of a small childcare issue. I would have loved to know more about who was in attendance at Elm Conf, and I hope the organizers are able to get information about who in the room is using Elm at work or in production, who is playing around with it, and for whom was Elm Conf their first exposure to Elm. I met some really friendly, awesome people throughout the day which always makes me happy when looking into a new language and I hope the Elm language and community continue to grow in a positive way.

The next day started off with a brief trip to the emergency room for nursemaid’s elbow… just one of the side-effects of deciding to bring a kid to a tech conf I guess and so I missed the first keynote. I’m just going to touch on each talk with a sentence or two on what they were about. One of the best things about Strange Loop is that they get the talks up online within days, so you can already check them all out.

Nicola speaking about journalism and collecting data to write stories spoke about look at data from a microscopic view, tearing it apart to decide if the information journalists have are able to provide them with a full picture in order to ethically report on an issue. The talk covered a few different stories that have been published over the last few years, went over the data received from these stories, and how that data was collected in order to help the audience determine if the story was a feature (a great story to report on based on the data received) or a bug (a story that maybe had some questionable components when looking at the data and how the data was received).

Zach spoke about what information you want to keep in mind when building a server and how to keep the factors in mind when you’re designing a system. His talk has a great example called “the parable of the pumpkin carver” which provides a great example for thinking about resource distribution and load balancing.

Julia who’s excitement is contagious dove into linux debugging tools covering strace, wireshark, perf, egrep, and a few more. Definitely check out this talk and the related zine for some straightforward commands that will help you debug problems faster. We explored the tools above using three mystery scenarios… the first, a missing config file, the second, a slow program, and the third, a website showing up in french instead of english.

Adam spoke next about network defense and a need to create trustworthiness in critical systems. He provided some tools and suggestions but his main take-away was that companies, even those who are adversaries, should work together when they experience an attack because if one company is experiencing an attack, it’s likely that a similar company will have the same issue.

Afterwards, Scott talked about netflix caching. As a fan and frequent user of netflix, it was pretty interesting to learn about the different pieces of the interface that are cached and how. He also talked about some of the architecture, what everything is built in, and how everything connects together.

And then lastly, I went to Mike’s talk on Alexa and go. I seem to have not taken many notes (I’m pretty sure I was doing some therapeutic coloring which is really important at the end of a StrangeLoop day). This talk was really interesting though because it went though how modules and components of programs for new tech like Alexa are being built.

The day ended with an incredible keynote from Ashley. It was really fantastic and I highly recommend you watch it. Numerous times, it caused a lot of the audience to tear up and was really interesting and compelling.

Day two

Day two began with Paul talking about mobile and how mobile web has changed, evolved, and whats coming.

Then Lee spoke about GraphQL and how the language was created. He spoke about the principles and lessons that they learning in the process. These included things like, think like a client, make sure you’re solving a real problem, and using software as communication.

Afterwards, Andre talked about metrics and how some numbers can be decieving. There are lots of great point in here about looking at things like runtime lag, VM lag, routing, request time, etc. but one of the most important things he talked about was to not rely on averages. Average numbers make you think that you understand whats going on and make you think that an average is also standard distribution but it’s not, so you need to look closer at the numbers.

One of the best talks I went to was Lea’s about the languages for 3D knitting. This talk was really awesome. As a crafty person, it’s great to hear about some of the science and tech behind industrial knitting machines. Lea spoke about knitting terms and different machines that do industrial knitting and how they all work. She then talked about knitPaint and a variety of other languages that you can use for designing and executing patterns on a knitting machine. She went over a few libraries and other things out there as well related to programming and knitting.

Next, Jennie talked about monitoring. She covered different types of monitoring… system monitoring, application monitoring, and business intelligence-related monitoring. She talked about scaling online games and talking about what that scale looks like (which is huge) and walked through a pipeline of information and where and how pieces need to change in order to accommodate better monitoring at scale.

In the next session, Andy talked about Guile which is a new programming language based on Scheme. He spoke about the different types that exist in the language, aspects of the language like speed benchmarks, etc. and finally what’s coming up in language development.

Almost closing out the day, Gary talked about reproducibility, or having the same action do the same thing. He spoke through three interesting systems of react rendering functions, bundler, and git, to show different mental models and how the actions always lead to the same results, One of the main takeaways was the reproducibility leads to good mental models which leads to the tools we love where the designs aren’t obvious.

In the closing keynote, Leigh did a great job talking about security and what folks should keep in mind.

As a sidenote, two talks I wish I went to were the talk on Tulip and the talk on diversity. Definitely check them out as well if you have a moment.

If you want to check out other notes, Trevor did an amazing job here.

Most companies I spoke with have 4-6 rounds in their hiring process (that includes some sort of take home project if one existed). For a candidate, this is a lot of time to dedicate to an interview process. Diving into the rounds, in the first round, where we (the candidate and company) were just getting to know each other, almost all companies spoke about the benefits offered as a way of selling their company, but when I asked about parental leave, almost none (and actually maybe not a single company I spoke with) knew what their policy was. Second, when I asked what they look for in a candidate, 90% of the interviewers answered "someone who can learn." Now that's lovely but what does that even mean? I can show dozens of examples in my work history and personal life where I have had to take a challenging problem, break it down, learn what to do, and have a successful outcome but this wasn't actually what most companies as looking for.

As I solved take home code projects that had nothing to do with the every day job of being a developer and weren't related to anything I had accomplished in the past two years, I found myself getting more and more frustrated. These projects didn't test my abilities. They tested if I had time. Time to complete these challenges. Time to practice these types of problems which were totally different than my day to day role. They were essentially an ineffective use of time that had no bearing on if I would be a good employee or not and they definitely didn't test if I could learn effectively. Code challenges are like any test you take in school. Most of us probably had a class in school where we knew all the material but weren't good at taking the type of test the class was given. Maybe you liked science but were awful at multiple choice tests so you got a C and were so-so at history but got an A because you were a good essay writer. How frustrating was that? If only you could be tested in a way that would both evaluate you as a student and give you the opportunity to show that in a way that's most effective for you.

In addition to thinking about what companies could do to assess candidates more effetively{:target="_blank"}, what I wish companies would do is think about what they're trying to accomplish through their hiring process. I don't just want a wish-washy answer like "we what smart people who learn well". That doesn't help a company or the candidates applying. I want real ideas like "the ability to create an architecture for a problem's solution", "knowledge of databases", "the ability to communicate ideas and work together effectively", or even "the ability to assess different solutions and put them in place." And then think about how you are getting those answers through your hiring process. Hint hint: if your goal is to find someone who can communicate ideas effectively and work with others, a take-home code challenge probably isn't getting you anywhere near the ability to assess that skill.

Oh yeah... And I'm still waiting to hear back from at least 10 companies who I spoke with about two weeks ago and said they'd let me know within 3-4 days. I know it seems like a waste of time to follow up with someone who you're going to reject but it really doesn't take much to create a nice form rejection letter and spend 10 minutes sending that out. It'll also make a big difference in your reputation. When job hunting, I specifically ask about bad hiring processes or unresponsive companies so i'm not wasting my time applying.

In this job, just like my last, when considering offers from similar companies that met my must-haves and nice-to-haves, I gave a lot of weight to their interview process and how I feel I was treated throughout. I will also be sure to recommend to colleagues companies I felt had a great interview process and will warn away from ones that were good on paper but in reality had time consuming code challenges, unnecessarily lengthy processes, or were just plain unresponsive. Because if that's what a company is like when they're recruiting you, I can only imagine how it will be when you're working there.

In case you're curious, here's my list of must-haves and nice-to-haves...

My must-haves:

• Family friendly company
• Maternity leave policy with, at the VERY least, 6 weeks of paid leave and an additional 6 weeks of unpaid leave
• Some work from home opportunities
• Desire from the team to pair and mentor
• Salary increase

Additional points for:

• Fully Remote
• Support for attendance and speaking at conferences
• Thought-out interview process that respected a candidates time and effort
• Diverse team
• Support for learning and growth at all levels

If you'd like help in figuring this out, check out my consulting page{:target="_blank"}

I ended up using the so simple{:target="_blank"} theme. There were some plusses and minuses to this. The main plus was that I really like the design and documentation. The minus was that there were a lot of features and items I knew I wasn’t using which meant I needed to spend some time carefully cutting code, deleting sections, and making sure I wasn’t accidentally deleting a piece of code I needed.

There were two tricky things I ran into when I started that I wanted to share.

1. There are actually different docs related to getting started on a Jekyll blog and github pages. I started by using these docs{:target="_blank"}. When I ran into trouble getting everything working, I was pointed in the direction of this link{:target="_blank"}. What the second link and set of docs does is basically set up Jekyll and using Github pages via a Github pages gem. The gem pulls in everything you need for it to all work nicely together. So, in short, if you’re getting started and google ‘Github pages blog with Jekyll”, don’t follow the instructions in the more basic post, make sure to build your blog with Jekyll using the github pages gem.
2. When I started working with the theme, things weren’t actually loading and working like they were supposed to. This is because I had downloaded the _site folder in addition to everything else. What I later learned was that _site is auto generated by Github pages so if you’re using a theme and you see that before you start entering your unique content, you can delete it and it’ll regenerate when you run jekyll build and jekyll serve.

The I needed to import all my old blogs. I expected this to be sort of complex and annoying but it was way simpler than almost anything else i’d done with the blog. Following the instructions on the Jekyll docs, I got a backed up copy from blogger of all my posts, then I did:

ruby -rubygems -e 'require "jekyll-import";
JekyllImport::Importers::Blogger.run({
"source" => “PATH/TO/FILE.xml”})’

in the terminal and that was that! Pretty nifty.

There are a few random points from this talk that really struck a cord with me. First, guest/host is NOT junior/senior. In the same way that sometimes you’re a guest in someone’s home and sometimes someone is hosting you, it works the same way with code. Regardless of experience, sometimes the person with less years of developer experience might have more experience with a specific codebase, in which case, they are the host, and vice versa. Second, I’m a BIG proponent of “don’t touch my keyboard” when pairing because I don’t learn as effectively. This is often really difficult for people and I understand why but nadia’s talk gave a great example. She spoke about a guest she had who she took to dinner a few blocks away one evening. She led the way and her guest just followed. A few days later, they were discussing a meeting place and she said to her guest “just meet me at the restaurant we ate at the other night.” Her guest then asked for directions and she didn’t understand, they had just been there the other night. Here’s the key, the guest wasn’t paying much attention and even if she was she had only been there once! If she had led or even chosen what restaurant they were going to, she would have likely been able to find her way there again, or at least gotten halfway there. This is SO similar to what I think about when I tell people not to touch my keyboard.

Some suggestions for being a good host include having your codebase in a state ready to receive guests by naming things well and having objects with clear responsibilities. Orientations also help. You can do this by providing diagrams (maps) or visual cues (turn left at the big monument), and documentation like a travel guide or readme file.

Nadia provides a template for code hospitality here{:target="_blank"}. It walks through things you might want to document at your company about an app like the history, approaches, reading material, and a walk through. You want to tell teammates the story of the codebase while still creating a safe space for questions, failures, etc. Make sure you’re demonstrating to new teammates that they should feel at home and help make them comfortable.

Finally, she talked about ways in which teams could communicate using this example. For example, realizing that there might be many directional ways one could get to a specific location. You want to have retros and give effective feedback that offers a solution. So instead of saying “it was great” about a pairing session, you could say “I felt like I was being heard when you stopped typing and explained that concept to me. I really enjoyed that.”

Code hospitality enables us to empathize. In closing she said, only when we treat our colleagues as guests can we thrive.

There are lots of benefits to having learning built in to your culture mainly related to attraction and retention of talent. There are three phases when putting a learning plan in place. For each phase, Joe covered what the phase is, what the approach is and then what worked and what some of the pitfalls could be during this phase. I’ll go through the phase and approach for each but will leave you to check out the slides for what worked and the pitfalls.

When no learning plan is really established, you’re likely going to start with phase 1, Guerrilla learning. This is often ad hoc learning, boarding from stoties, only a few folks are driving the learning initiatives if there are any, and there’s resistance to taking time away from shipping. The approach to use here is to think opportunistically, focus on things that will provide fast returns without a lot of time investment and things that improve people in their primary roles. At this point it’s less about learning what you want to learn and more about learning something that could make you better every day so that you can prove to managers that spending time learning is important.

The second phase is when you expand to others. This is where new hires learn a bit, people want more but maybe aren’t quite empowered yet, there’s often some group learning initiatives, a slightly more standardized on boarding process, and still a core group of people who drive the learning forward. For this phase, you want to look at cross-trainings, leverage internal experts, make sure you’re shining a light on good role models, mentoring the mentors (this is big! You want to do this so the mentors don’t burn out and so they feel they’re getting something as well as opposed to just organizing and giving), and you start to initiate learning opportunities with a longer payoff.

Finally, you want to make it stick. In this phase, learning should start to be self-sustaining. It should be so normal that it’s borng. You want to build momentum so that it’s sustainable and there is likely dedicated learning for all engineers. For this approach, you want to make people forget that learning was ever NOT part of their job. Everyone in every department gets involved and you can try some riskier things.

Creating a learning culture is difficult but so great when you can actually make it to phase 3 so good luck and follow the suggestions if you’re working on it!

ps: Both Joe and I work with companies{:target="_blank"} in order to help them put plans like this in place so if it’s something you want to do or that you’re struggling with, please reach out! We’re happy to chat.

First, when you’re looking to contribute to an open source project, Sean recommends following this process:

1. Read the contribution file
2. Have tests
3. Follow the style guide
4. Write code you’re proud of

Okay, so now into PRs. PRs are actually NOT about code. Make sure to keep the size reasonable. No one has time to review a PR with 10,000 changed lines of code. Then, don’t assume context. Make sure to link to the docs, link to any related sections, and even link to other links or code. When you’re contributing to a large open source project, convince the folks in charge why the problem matters, again, give context to the issue. Then think about how many users will be affected by the fix? how complex is the fix? and is there an easy work around for the issue?

After that, show that your change is the best solution. Explain why you wrote the code the way you did. And remember that features are easy to add but hard to remove. You can also give context in the commit message. Pro tip: if you’re confused about what a piece of code is doing, use git blame to read the commit message from that piece of code (also why you should write good commit messages). As you’re coding a solution, you can also write longer commit messages in order to alleviate the need to put comments the code. But remember, if you squash your commits, amend the commit message.

Finally, remember that your third pull request is when you start to make an impact because it takes time to get to know a codebase, a reviewer, for a reviewer to get to know you, etc. And remember to be nice. Not everything can be merged. Maintainers are working hard to have a clean codebase and sometimes it sucks when they say the PR you worked on actually won’t get merged in. You can be sad, but be nice and the key is empathy.

In the end of her talk, she gave some examples of what someone can do with their luck. You can expand the problem pool by following people unlike you, volunteering, and amplifying voices, and you can incorporate these things into your product but thinking about accessibility, internet speeds, and conventions.

This talk was good, but to be honest, when I sit in a talk like this, I wonder what “unlucky” people think. I know a lot of people in our community have a lot of luck and privilege. I’ve had some privilege… I went to college and graduated without any debt, I’ve always had access to computers and internet, etc. but I also didn’t have the freedom to take european vacations or unpaid internships and knew, for example, when going into college that if I could work harder and finish in three years, that would be better than finishing in four and needing to pay that extra year of tuition. And there are lots of people out there who, no matter how hard they work, won’t be able to go to college and are working ten times harder than most of us just to get by. There is space in our community and at conferences for people to talk about the privilege they have and what people like them with privilege can do to help others but, in a talk like this, I wonder how many of those folks without luck and without privilege are in our industry and if they feel like there’s a space for them to talk abut what they think could be helpful and how people with privilege could help them. I think about Mike’s ordinary people talk from the day before where he says that we shouldn’t think about how a woman or person of color would design a product for them but we should actually get THEM and hire THEM to design the product. In reflecting on this talk, I think that’s who I want to see a talk like this from, not someone who has privilege telling others with privilege how to use their privilege but someone without it telling others what is and isn’t helpful.

npm past

Npm is all about sharing code, that’s how and why they started. Npm helps you share code, make packages, discover, and install. There are over 4.5 million people using npm and over half of cpm users have only been using it for six months. JavaScript code before npm was hard to share. Some of the perks of npm as a package manager is that there is no dependency hell and there’s semantic versioning. Related to dependency hell, npm and the module loader were written at the same time so they work very nicely together. For semantic versioning, we know versions as something like 2.15.54, or breaking.feature.fix, or major.minor.patch. Using semantic versioning reduces risk and allows for lots of small modules in npm. Small modules are super popular, it’s actually one of the reasons npm is s popular. There are over 300,000 modules in npm. And this works because npm makes it really easy.

The registry stores the packages. Modules are hosting in a variety of places but everything is in the registry because you don’t want to have to just rely on GitHub. Npm exists to make sure js, node, and everything else are working well together. The registry also enables discovery. A registry is faster than having to do a git clone or something similar. Git is for developing and collaborating but npm is for distributing.

npm present

This section was sort of a greatest hits of cool stuff about npm you should probably know.

So first you want to make sure you’re always updating your npm by doing npm install -g npm. Currently you can also use a scope command which let you publish your packages under your own name. You can also group packages together and have private packages. The npm init file controls how npm runs, you can add defaults there, change it, etc. There’s also promzard. You can do npm install with - -save to add a package to your dependencies. You can also do - -save-dev to only in stall it to your dev dependencies. Bundled dependencies makes downloading packages faster. Additionally, when you npm install npm goes to the server, gets a list of all the versions, and puts one of those persons on your computer. It also puts the version into the local cache of your computer. Because of this, you can also do an install offline.

There are run scripts, mainly npm start, npm stop, npm restart, and npm test. You can use these scripts to get dev dependencies for specific things like mocha.

Now on to .npmignore. It works like .gitignore and automatically excludes things from your package. You also need to remember to change your semantic versioning number when you change you package. You can do this right from the command line by doing something like npm version patch -m “bump to version %s.” There’s something called shrink wrap and then finally npm organizations. There you can give permissions to specific teams by checking out npm team and npm access. In team, you can create, destroy, etc. and in access you can grant, revoke, etc.

You can work on multiple packages by linking them user npm link and you can publish with distinct tags. You can also npm unpiblish <pkg>@<version>, but you actually never want to do this. First, you can’t unpublish after 24 hours. Second, once you publish, it’s out there in the world and unpublishing doesn’t get that data back.

In order to keep packages up to date you can check out npm outdated and do npm update, There are package config variables that you can change with the npm config set command. There are also lifecycle hooks like publish, test, start, etc, and each of these has a pre command and a post command to allow for work flow automation and validity checks. You can put default config options in your .npmrc file. Install the Wombat cli which gives you the latest experimental stuff and allows you to manage web hooks by doing npm install wombat -g. And you can use web hooks to automatically deploy.

Wow. That was a lot of commands. So now for

npm future

Npm is now the package manager for javascript. There are some big challenges coming up related to discover and trust and es6 modules. For example, discovery is great but finding the best module for something you want to do is becoming really difficult AND people want to know if they can trust a specific package. And then security is an issue. There’s the node security project which checks a package against known vulnerabilities. Npm is also thinking about reliability via greenkeeper.io{:target="_blank"} which check for outdates dependencies that will break things and about efficiency since the size of packages is becoming an issue.

After that very brief intro, Kelsey then jumped right into a demo (he warned us at the beginning that this wouldn’t be an intro to kubernetes talk but rather something a little more advanced). The demo was that we have a container and we want to run it. Kubernetes does the deployment but we do not want to pin the app to nodes. He showed some simple commands to create the deployment in kubernetes and launch 5 pods. Then looked at these pods, then got nginx running. Kelsey mentioned to update servers, you set the image and then update the declaration inside kubernetes which will do a rolling update without any drops.

He spoke about building your own schedule, saying the anything you create in kubernetes is in a central class and needs the global cluster state. We want them to feel reactive. And finally we want to use a resource scheduler to look at incoming workloads and make decisions about placement to make sure we’re efficiently using resources When the video is posted, check out the awesome Tetris example used in order to explain this concept... and give Kelsey an excuse to play Tetris on stage.

Finally, he walked through a great example related to updating certs in an application which helped explain the usefulness of a framework like kubernetes.

The slides for this talk aren’t up yet, but it looks like Kelsey has done it a number of times so recordings of this talk or very similar ones are online.

Then we moved into discussing refactoring. When refactoring, you want to alter the arrangement of the code without changing the behavior. The nice thing about code smells is that every code smell has a recipe for fixing it.

From here, i’ll honestly refer you again to the slides{:target="_blank"} because Sandi’s examples are always excellent and are documented so clearly visually. This is always the point in her talks where I fin it MUCH more valuable to put down the pen, stop taking notes, and just watch the magic happen.

I will say at the end she did mention a few tools for looking for code smells in your code, the main one being reek{:target="_blank"}.

Peephole optimization is where you remove useless instructions. Wikipedia says “peephole optimization is a kind of optimization performed over a very small set of instructions in a segment of generated code. It works by recognizing sets of instructions that can be replaced by shorter or faster sets of instructions.”

Case/when byte code is generates a hidden hash and dispatches something but this only happens in certain scenarios.

When looking for optimizations, you want to find the call site. In ruby, the call site is the “.”. For example, in hello.world! the call site is .. In x=foo(Object.new) there are two call sites. The . in Object.new and an implicit call site on the left of foo because it is self.foo. Call sites are everywhere.

Ruby VM recap which is important for call site caching. You see the instructions and the stack. Stack-based where the byte code is stored as an array or arrays. In this, you see the operator and the operand. So if the instruction is push 6 and the stack is 6, the operator is push and the operand is 6.

Find-method- looking for the method, if it’s not found, then it moves up the stack to find it. Method lookup is an O(n) operation because you BenchMark to check out the speed. The more ancestors there are, the slower the call.

There are also ways to speed up method calls. For example you can cache things that never change. The call cache is a data structure that contains the method lookup and is stored inline with byte code. This is called an inline cache.

Somehow this leads you to be able to look at a hash where they key is the class serial number and the value is the method.

You can tell if the cache is missing by doing p Ruby(M.stat). If it’s global, the method state should never change.

There can also be runtime breakage, which is where a singleton class access breaks it. The cache also typically misses new classes or modules.

The session also briefly covered monomorphic, polymorphic, and metamorphic cases. These terms related to the number of types at a call site.

Aaron then touched on measurement of these things saying you need to measure the impact of the cache by measuring the impact of the call sites that are polymorphic and you can do this by logging the method caches.

Finally, in summary, Aaron said that you should only optimize cod that matters and everyone should use polymorphism for better optimization.

Hopefully this summary at least exposed you to some new words and concepts. I’ll let google take it from here.

First, Barrett talked about window functions. The definition from the documentation is that “a window function performs a calculation across a set of table rows that are somehow related to the current row.” There are lots of window functions but the ones to focus on are lead(), lag(), first_value(), last_value(), and row_number(). The slides are really good for walking through and example. We then went into subqueries and the piece to really look at is the fact that in the examples we have a base query and then named subqueries. They’re wrapped in an outer query and then we can refactor in order to DRY out the whole query. We then talked a little bit about DB views. Barrett recommended to check out Scenic{:target="_blank"} which is actually something i’ve been hearing a bunch about recently.

Highlights that are just words or phrases in my notes to look into further include “view concurrently” which will be available in PostgreSQL 9.4 and subqueries for field values.

Finally, we discussed a little bit of tooling which included the psql command line, pgadmin{:target="_blank"}, navicat{:target="_blank"}, visual query plans (which helps explain and analyze) like https://explain.depesz.com/{:target="_blank"} and http://tatiyants.com/pev/#/plans{:target="_blank"} which will let you see the hot spots (note: this will differ depending on the environment you’re looking at). Finally, database datatypes that are awesome and you should look into more are Array, DateRange and TSRange, JSON and JSONB, and UUID. And check out upset which is an update or insert for data.

Also, here's Barrett's twitter handle{:target="_blank"} and he's got an awesome new book out{:target="_blank"} if you want to dive into this further.

That’s when the talk actually started to get deeper. He was speaking from the perspective of a designer and saying that designers could change the world but the world isn’t changed by people who apply to do it, it’s changed by people who just want to live their ordinary lives. He also put the onus on the audience and said that we can change the world because we don’t have an option… we don’t get to opt out.

He then went a bit into how to do this. (I’m pretty sure there are three steps in this process, but I only seem to have notes for two so you’ll have to just be on the lookout for the slides to be posted to get that third vital part). First, get ignorant about your place in the world. What he means by this is that empathy is important but empathy only allows for those who have time to feel it. Design a system where you could be on the other side of the results and it would be okay. So, for example, he talked about AirBnB. AirBnB is great for the people on the good side of it but if you place yourself on the other side of it… the people who are getting evicted because a landlord can make more money if the place is an AirBnB rental, would you be happy? Would that be ok? Probably not. So when you design systems, you want to keep that other piece in mind as well. Second, look like the world. You don’t want to assume how people would behave in a situation, hire them to design it. You see examples of this all the time… a male designer is trying to figure out how to design something for women… how about ask a woman to design it? People are more informed about themselves than others. Ultimately, your role in the world is to leave it in a better state than you found it (this actually might be the third point, but I didn’t note it in my notes). We need to change what we design, how we design, and who designs.

He closed by talking about how important it is to think critically. think critically about how you spend your time, about how the world works, etc. He ended by saying that we need to remember that we are ordinary people and that it is our job to help and elevate one another.

The talk was definitely funny and to the point and in the end, I think the story that was told was excellent and it definitely was perception-shifting. I’m glad I decided not to leave and see where he was going with his opening.

In this talk, Casey covered the twelve factors that lead to operational maturity. It’s based on the factors outlined here{:target="_blank"}. For each factor, Casey mentioned what the factor was, what the anti-patterns the exist are and what the best practices should be. So here goes…

1. Code base deploys to a stack. The anti-pattern here is that you build separate images for staging and production and then you manage the config. You often also have tags for dev and prod. The best practice is to have feature flags or an ENV file of some sort, It takes some work to do feature flags correctly and effectively but if you put in that time at the beginning, it’s well worth it in the end.

2. Explicitly declare and isolate dependencies. Dependencies can also be abstracted and managed externally. The anti-pattern here is to look at latest but there can be major api incompatibilities and this can be very problematic because containers are an immutable packing that you’ve built. You want isolation between the build phase and the deploy phase. The best practices are to declare version numbers of upstream dependencies. Oftentimes you’l use a base image and then build on top of that and second, to depend on the base images for the default file system and run time. This makes it easier to rebuild intermediate containers.

3. Store config in env. The anti-pattern here is to have a config.yml file or hard-coded feature flags. The best practice is to simply use environment variables.

4. Treat backing services as attached resources, connecting to data stores, microservices, etc. The anti-pattern here is to rely on a stateful,long-term local disk. If you don’t use the 12-factor principles to build the application, then this is often the first issue you deal with. One env that does to this well with local disk is google cloud. He then talked a little bit about volume mounting in this scenario. The best practice to to connect to network-attached services using connection information from the environment with a service like Vault{:target="_blank"}.

5. Strictly separate build and run stages. The anti-pattern here is to install on deploy but the best practice is to build immutable images, then build, deploy, run. Secondly, you want to respect that lifecycle of buid, run, destroy.

6. Execute the app as one or more stateless processes. The anti-pattern here is NFS or a network file system. I don’t know much about NFS so unfortunately, can’t provide more details but would be happy to be pointed in the direction of some good resources to learn more. The best practice is to schedule LRPs by distributing them across a cluster of physical hardware. This can provide a return of interfaces between the application instances and the underlying software.

7. Export services via port bindings. Don’t hard code the ports the software runs in. Get the port from the env.

8. Scale out via a process model. This takes down processes when the load is low. (can you tell my brain was getting tired at this point in the talk?)

9. Maximize robustness with fast startup and graceful shutdown. You want to mitigate against traffic spike by having fast startup times. And you want to have a graceful shutdown if an instance blows up, you want to make sure you have have bad, corrupt, or lost data. The key term I learned while discussing this point was the “Hug of Death” which sounds very ominous.

10. Keep dev, staging and prod as similar as possible. Best practice here is to run containers in development. It helps you spin tup architectural dependencies so you can tweak instances. etc. You can also run the app in dev against the app in prod to compare if both are in containers.

11. Treat logs as event streams. The anti-patterns here is to have random log files all over the file system. Instead of doing this use STDOUT and manage logging applications and systems.

12. Finally, run admin and management tasks as 1 off processes. The best practice here is to reuse application images within specific entry points for tasks.

There are more factors to explore like api as first class in an application, secrets management, health metrics, and global distribution.

There was a short additional part about becoming cloud native and the difficulties there but I think the 12-factor walk through was really the meat of this presentation.

Brad started talking about the idea of companies and brands. As a user, I want to see 1 brand. In order to think about this, someone has to think about six different types of style guides. First, there’s brand identity. Does the brand convert a clear identity of who they are. West Virginia University was given as a brand that does this well. Then there is a design lunges style guide. This related mostly to material design. Third, the voice and tone style guide. How does the company want to speak? What sort of language do they use? Mail chimp is a great example of this. One thing to note is that it’s easy to think about a fun playful tone you want to create for the positive scenarios or confirmation messages, but make sure you’re thinking about how to use that tone and voice for negative scenarios as well, like when a credit card is declined. Fourth, there is the writing style guide for grammar, etc. Fifth, the code style guide which could be things like SMACSS, BEM, css guidelines, modularity, and more. GitHub has a good example of code guidelines. And then finally, pattern libraries looking at the pages, responsive design and looking at designing systems of components. For example, tools like bootstrap and foundation are great but it does mean that so many pages end up looking so similar. The other framework pitfalls might be that you don’t need everything that’s in the package and you’re subscribing to some els’ed structure instead of creating your own. There were a few more pitfall points that I didn’t quite capture in my notes.

The major benefits of pattern libraries, which is what the rest of the talk focused on, are that they promote UI consistency and cohesion, they lead to faster production because you’re not reinventing the wheel every time you need something, there is a shared vocabulary, they’re easier to test, a useful resource (great to go back to as you continue developing), and finally, they are pretty future-friendly because you set them up once and son’t have to set them up again. Brad showed some great examples of how many different button types exist on large airline or bank sites to help demonstrate these points and more. He then went on to talk about how you sell the idea of investing time in creating a pattern library style guide to a company. You can to show, not tell. SO first, conduct an interface inventory which shows the decision-makers all the different button types, styles, etc. (The slide provides a great list of different things you can inventory). This also helps you as the person selling the idea to point out all the inconsistencies which lets you get buy-in, establish a scope of work, lays the groundwork, an plants seeds for spending time on something like this.

Once you are given permission to actually work on this, there’s a great methodology he introduced called the atomic design methodology. He also wrote a book{:target="_blank"} on this which I believe is either free and asks for a donation or is very very well priced. Here’s the methodology… atoms -> molecules -> organisms -> templates -> pages. So, you start with atoms. You want to really break the interface down as much as possible. Look at the h1s, buttons, fields, images, etc. The you want to take those atoms and put them together into molecules, a molecule is a UI component like a search form. The the molecules make up an organism so you take the molecules and put them into context like a header might include a search form molecule and a nav molecule. From there, you move on to a template which takes the organisms and puts them into a page layout, so the content and skeleton of a page. Finally, you make a page by putting content into the template. You validate or invalidate the underlying assumptions, you test variations like dashboards, alert messages, etc.

To break it down a different way you can look at it as reference (atoms) -> build (molecules, organisms, and templates) -> review (pages)

You want to stylize pieces at a time and explore different ideas together so that the dev-designer interaction isn’t do the discovery, then do all the design, then hand it over complete to the developers. Make you're you’re making element collages and not putting too much time into high fidelity mockups too early.

The first of many

The first talk I went to was one by Jose Valim{:target="_blank"} on Exploring Elixir{:target="_blank"}. I haven’t had a chance to play around with elixir at all yet but had heard a lot about Elixir and phoenix and know a fair amount of companies that are starting to move in this direction. I figured this would be a great intro into some of the key terms and vocabulary used. Part of the focus was on the fact that Elixir is great for building concurrent applications. Concurrency means a bunch of processes that are isolated and every time they change information, the process needs to send that information. In Elixir, every process has a supervisor so that what is going on in one process doesn’t affect the other process. Processes can be things like stats, mailers, etc. that package and run our code. They can also be started and stopped. Processes have supervisors and both are packing into applications. Then the message passing is how the processes communicate.

Jose used the elixir REPL (which is like IRB) to show us a few things. He talked about how things are named obviously which is helpful and that you can run an observer that will then show you all the information you’re looking for. Opening up the tools for discovering all of this information, you can look at nodes and even use the UI to kill nodes in order to see what will happen. For example, when you kill a node, the pool will notice something is wrong and will start a new process. These applications give us visibility into the state, introspection and monitoring abilities, and make it each to break aspects into components. All of this means Elixir applications are concurrent, allow developers to fail fast, and fault tolerant.

He mentioned the goals of the language were compatibility, accessibility, and productivity. Compatibility means that you can call Erlang from elixir, for example, without an issue. Accessibility means there will be a tool for making more tools of the same kind, like writing tests or a library that writes queries using Elixir. Productivity means that everyone has a good programming experience resulting in priorities like good error messages, documentation, good tooling (Exunit{:target="_blank"}, Mix{:target="_blank"}, and iex were mentioned specifically), and hex package management.

From there, we did a quick demo app. Here are some highlights. You can clear error messages in tests. Documentation is write-in markdown. The framework can take documentation and write a test for it. Alchemist{:target="_blank"} is a toolkit for writing code (demonstrating the types of tools that are starting to exist in the community). Finally, to get started with Elixir go through the “getting started” guide{:target="_blank"}.

1.  Are you a self-sufficient worker? As a remote worker you need to set up a schedule for yourself and get into a routine. You need to push yourself through the days where you're tired and a little checked out. And you need to be filling in the gaps. Working on an issue and stuck but no one is free to pair? If you twiddle or thumbs or go watch tv, remote work is not for you but if you say to yourself, "ok, I can't figure out this problem but it has to do with ______. I'm going to read the docs, find some blog posts, or find a conference talk to watch until someone is available to pair" then you're on the right track. 


2. Can you boldly, bravely, and shamelessly ask question? This is the most difficult part. You can't be fearful and let imposter syndrome take over because you'll never get anything done. When you're stuck, no one can see that you're stuck or maybe frustrated. You can lean over and say "hey, can you check this out real quick?" You've gotta announce it in a slack channel. And sometimes that sucks but it's important! When I began, I made it a goal to ask 100 questions a week so that I could frame asking questions as a positive thing. It wasn't something I needed to do because I didn't know anything, it was something I had to do to learn and accomplish my goals. 

1. Coworkers to work with. But you're remote you say? How would this happen? Well, there are lots of other remote workers as well! I generally try to cowork at least once a week preferably with a group of ruby developers. There's no doubt in my mind that you do miss some learning when you're not in an office. You miss overhearing snippets of technical conversations or jumping into a conversation because it sounds interesting so try to creat that for yourself.


2. Regularly scheduled pairing sessions. As I got more experienced and started working on more challenging tickets, I would get stuck (as everyone does). Additionally I try to take a "challenge ticket" every week. Challenge tickets are tickets that are just above my skill level. I know they're within reach but I can't quite wrap my head around how to start them or what an effective plan of action would be. They're tickets I have to pair on. We have a pretty small team so sometimes there wasn't anyone free to help. I decided to set up scheduled pairing times. I have one hour a week with two coworkers that is in the calendar to ensure the time is blocked. The time can be used to ask some quick questions and get a few tickets out the door, work on a challenge ticket, or pair on something they are working on. And sometimes we cancel it if it's not needed but the point is that it's there, blocked off. 


3. A regular way to evaluate yourself. I try to do weekly personal retros which is something I noticed a coworker doing. He just reviews 3 things; liked, learned, lacked. I keep these documented in Evernote and they're a great way to looks back and see all the things that have been going on. 

1. Someone who takes initiative. There are going to be bumps and issues and as a non-senior dev. In order for the employee to learn and grow as much as they possibly can, they’re going to need to make some decisions, put improvements in place, and get the rest of the team on board with what they need. Make sure that as a company, you look for someone who has done this in the past or has the potential to do this.


2. Good communication skills. This is necessary for any developer but especially when remote. How can they articulate their thoughts, the research they've done, a problem they're facing, etc. 


3. Learn about their past. Are they a new professional or just new to development? When I became a developer I had about 7 years of prior professional experience and had already been working from home for 2 years in different industries successfully. I might not be a senior developer technically, but I’ve got all the other skills necessary to be successful.


4. Make sure the person understands what remote work is all about. Ask them about the best and worst parts of working remotely. I don't like working remotely because I can work in my pjs (which I don't do, for the record). I like it because I have a schedule, more work time without a commute, and a quiet distraction-free workspace. I also have opinions about the parts of working remotely I don't like. I’m aware of all the good parts and bad parts of remote work and I know what i’m getting into when I accept a remote position. You want to ensure you’re hiring someone who also understands these aspects or has at least thought through them.


5. And maybe most importantly, someone who isn't afraid to say to a slack channel that they are stuck, frustrated, or need help. Without this personality trait, the individual won't be successful because asking questions is probably the most important skill a developer can have.

1. A good manager who has had some experience/training. This person will be vital for support and working through issues that may come up on the team. They should be an ally and be able to recognize when issues are actually opportunities to help the team as a whole grow and learn more about things like diversity, empathy, mentorship and more. 


2. A kind, caring team. It is easy as a non-senior Dev to be scared of asking questions but if the team they are put on is supportive, thoughtful, positive, and constructive it will really go a long way in creating an environment with lots of psychological safety where it is easy to learn. 


3. A system of regular check-ins. It's great if you have a good manager but that manager (or even a tech lead) need to be regularly checking in with this person, especially at the beginning. I think 1-1s are a vital part of a healthy team culture regardless of experience level or if folks are remote, but it’s even more important when you don’t see each other every day in person.


4. A partially remote team. Even if your current team of remotes are only senior, having a partially remote team means you understand some of the baseline difficulties of remote work regardless of level. It also hopefully means you have some processes in place to allow for easy, async communication and remote pairing tools that are widely used and understood. I'm not saying it won't work if your first remote hire is non-senior but it's definitely going to be a steeper mountain to climb. 

1. Write code
2. Push up the branch and create a pull request
3. Put a few details in the description about what changes were made
4. Wait for comments
5. Improve code based on comments if needed
6. Ship it

• Rspec
• Advanced Newbie (including mentorship, cs without a cs degree, importer syndrome, and ways to step up as an advanced newbie)
• Freelancing
• Everything APIs
• Functional web stacks
• productivity tools hack
• infrastructure as code

• making a safe space.

class Action

  attr_reader :attributes

  def initialize(params) 
    @attributes = params
  end

  def title
    @title = attributes['title']
  end

  def description
    @description = attributes['description']
  end

  def reference_name
    @reference_name = attributes['reference_name']
  end

  def action_key
    @action_key = attributes['action_key']
  end
end

# def self.fetch
   #Nokogiri::XML(SalsaLabs::Client.new.request_data('/api/getObjects.sjs', object: 'Action')).css('item').map do |attributes|
   #SalsaLabs::Action.new({title: atributes.css('Title').text)})
   #end
#end

def initialize(api_client)
  @api_client = api_client
end

def data_request
  return @data if @data 
  body = @api_client.fetch('/api/getObjects.sjs', object: 'Action') 
  doc = Nokogiri::XML(body) 
  @data = doc.css('item') 
  @data
end

def get_results
  data_request.map do |attribute_set| 
    new_action(extract_attributes(attribute_set)) 
  end
end

def extract_attributes(action_data)
  action_data.children.inject({}) do |memo, node|
    memo[node.name.downcase] = node.text 
    memo
  end
end

def new_action(params)
  SalsaLabs::Action.new(params)
end

response = conn.get do |req|
  req.headers['cookie'] = authentication_cookie
  req.url endpoint, params 
end 

return response.body

def reply_random(m, list)
  m.reply list.sample
end 

  on :message, /.(coffee)./i do |m|
    reply_random m, [
      "http://wac.9ebf.edgecastcdn.net/809EBF/ec-origin.chicago.barstoolsports.com/files/2012/12/badcoffee.gif",
      "http://thoughtcatalog.files.wordpress.com/2013/08/tumblr_ln3pef2aly1qaq98ro1_400.gif",
     "http://25.media.tumblr.com/57acd60ebc217bc00169fd73b52be5a6/tumblr_mi5u4eeJZv1qcwyxho1_500.gif",
      "https://encrypted-tbn2.gstatic.com/images?q=tbn:ANd9GcSP8TfZHYrpS1Hz2jM_vdwOToNN949vYDPFZ74G3vw41r4rNH6k",
      "COOOFFFEEEEE!",
    ]
  end

def action_or_reply_response(m, list) 
  list = list.sample    
    if list.first == :action     
      m.channel.action list.last 
    else
      m.reply list.last  
    end 
end

  on :message, /.morning./ do |m|
     action_or_reply_response m, [
      [:reply, "Good morning to you too!"],
      [:reply, "it's a brand new day!"],
      [:reply, "I'm sleepy today"],
      [:reply, "http://gifrific.com/wp-content/uploads/2012/04/bunny-sleep-work.gif"],
      [:action, "yawns"],
      [:action, "makes coffee"],
      [:action, "throws open all the windows it's a glorious day today"]
    ]
  end

• Involved in the community
• Setting goals
• Doing something every day
• Try ruby
• Ruby in 100 minutes
• Read Why’s poignant guide to Ruby
• Learn Ruby the Hard Way
• Ruby monk
• Ruby Rogues (listened to at least a few)
• Learn to program by Chris Pines

def nick_id(nick) 
  set = score.where(:nick => nick) 

  if set.empty?
    nil 
  else
    set.first[:id] 
  end
end

def insert_or_update_score(nick, points)
  nick.downcase!
  if nick_id(nick)
    row = score.where(:id => nick_id(nick)).first
    updated_points = row[:points] + points      

    score.where(:id => nick_id(nick)).update(:points => updated_points)
  else
    score.insert(:nick => nick, :points => points) 
  end
end

def lookup_score(nick)
  score.filter(:nick => nick).first[:points] 
rescue 
  nil
end

require 'singleton'

class DB
  include Singleton
  
  def initialize(file = 'sqlite://bot.db')
    @db = Sequel.connect(file)  #setup the DB connection
  end

def score
  @db[:score]
end

on :message do |m|
  if rand(500) == 0
    m.reply "SQUIRREL!"
  end
end

on :message, /#{config.nick}?/i do |m| 
  response = [
    [:reply, "Did someone ask for me?"],
    [:reply,    "http://31.media.tumblr.com/fe021d747a605a8a7cba5767011251e1/tumblr_mjpo4q44aj1rjatglo1_500.gif"],
    [:reply, "what do you want now?"],
    [:reply, "#{m.user.nick}, why are you bothering me?"],
    [:reply, "it wasn't me."],
    [:reply, "yyyyeessss?"],
    [:action, "hides"],
  ]
  msg = response.sample    
  if msg.first == :action   
    m.channel.action msg.last 
  else
    m.reply msg.last  
  end
end

require 'problem7/problem7'

describe 'Prime number positions' do 
  
  it "is the 6th prime number" do 
    expect(Problem7.prime_place(6)).to eq 13
  end

  it "is the 10001st prime number" do
    expect(Problem7.prime_place(10001)).to eq 104743
  end

end

require 'prime'

module Problem7

        def self.prime_place(position)
          prime_place = Prime.take(position).last
        end

  puts Prime.take(10001).last

end

 Find the greatest product of five consecutive digits in the 1000-digit number.

 73167176531330624919225119674426574742355349194934
 96983520312774506326239578318016984801869478851843
 85861560789112949495459501737958331952853208805511
 12540698747158523863050715693290963295227443043557
 66896648950445244523161731856403098711121722383113
 62229893423380308135336276614282806444486645238749
 30358907296290491560440772390713810515859307960866
 70172427121883998797908792274921901699720888093776
 65727333001053367881220235421809751254540594752243
 52584907711670556013604839586446706324415722155397
 53697817977846174064955149290862569321978468622482
 83972241375657056057490261407972968652414535100474
 82166370484403199890008895243450658541227588666881
 16427171479924442928230863465674813919123162824586
 17866458359124566529476545682848912883142607690042
 24219022671055626321111109370544217506941658960408
 07198403850962455444362981230987879927244284909188
 84580156166097919133875499200524063689912560717606
 05886116467109405077541002256983155200055935729725 
 71636269561882670428252483600823257530420752963450

require 'problem8/problem8'

describe 'largest products of consecutive numbers' do 
  it "is the largest product of 5 consective numbers" do 
    expect(Problem8.product(7316717653)).to eq 1764
  end

  it "is the largest product of 5 consecutive numbers" do 
    expect(Problem8.product(7316717653133062491922511967442657474235534919493496983520312774506326239578318016984801869478851843858615607891129494954595017379583319528532088055111254069874715852386305071569329096329522744304355766896648950445244523161731856403098711121722383113622298934233803081353362766142828064444866452387493035890729629049156044077239071381051585930796086670172427121883998797908792274921901699720888093776657273330010533678812202354218097512545405947522435258490771167055601360483958644670632441572215539753697817977846174064955149290862569321978468622482839722413756570560574902614079729686524145351004748216637048440319989000889524345065854122758866688116427171479924442928230863465674813919123162824586178664583591245665294765456828489128831426076900422421902267105562632111110937054421750694165896040807198403850962455444362981230987879927244284909188845801561660979191338754992005240636899125607176060588611646710940507754100225698315520005593572972571636269561882670428252483600823257530420752963450)).to eq 40824
  end
end

module Problem8
  
  def self.product
    arr = []

    "731671765313306249192251196744265747423553491949349698352"<br />    "0312774506326239578318016984801869478851843858615607891129"<br />    "4949545950173795833195285320880551112540698747158523863050"<br />    "7156932909632952274430435576689664895044524452316173185640"<br />    "3098711121722383113622298934233803081353362766142828064444"<br />    "8664523874930358907296290491560440772390713810515859307960"<br />    "8667017242712188399879790879227492190169972088809377665727"<br />    "3330010533678812202354218097512545405947522435258490771167"<br />    "0556013604839586446706324415722155397536978179778461740649"<br />    "5514929086256932197846862248283972241375657056057490261407"<br />    "9729686524145351004748216637048440319989000889524345065854"<br />    "1227588666881164271714799244429282308634656748139191231628"<br />    "2458617866458359124566529476545682848912883142607690042242"<br />    "1902267105562632111110937054421750694165896040807198403850"<br />    "9624554443629812309878799272442849091888458015616609791913"<br />    "3875499200524063689912560717606058861164671094050775410022"<br />    "5698315520005593572972571636269561882670428252483600823257"<br />    "530420752963450".each_char.map(&:to_i).each_cons(5) { |a| p arr << a.reduce(:*) }     
    puts arr.max 
  end
end

bot = Cinch::Bot.new do 
  configure do |c| 
    c.server = 'irc.freenode.net' 
    c.realname = 'Rosie' 
    
      c.channels = ['#rosie'] 
      c.user = 'rosie_' 
      c.nick = c.user 
  end

The sum of the squares of the first ten natural numbers is,
 12 + 22 + ... + 102 = 385

 The square of the sum of the first ten natural numbers is,
 (1 + 2 + ... + 10)2 = 552 = 3025

 Hence the difference between the sum of the squares of the first ten 
 natural numbers and the square of the sum is 3025 − 385 = 2640.

 Find the difference between the sum of the squares of the first one 
 hundred natural numbers and the square of the sum.

require 'problem6/problem6'

describe 'up to 10' do 
  it "finds the sum of the square of the first ten numbers" do     
    expect(Problem6.sum(1..10)).to eq 385
  end

  it "finds the square of the sum of the first ten numbers" do
    expect(Problem6.square(1..10)).to eq 3025
  end 

  it "finds the difference between the sum of the square and the square of the sums" do 
    expect(Problem6.difference(1..10)).to eq 2640
  end
end

describe 'up to 100' do 

  it "finds the sum of the square of the first one hundred numbers" do 
    expect(Problem6.sum(1..100)).to eq 338350 
  end

  it "finds the square of the sum of the first one hundred numbers" do 
    expect(Problem6.square(1..100)).to eq 25502500
  end 

  it "finds the difference between the sum of the square and the square of the sums" do 
    expect(Problem6.difference(1..100)).to eq 25164150 
  end 
end

module Problem6

def self.sum(number_set)
  sum = (number_set).map { |i| ii }.reduce(:+)
    #put here the sum of squares of the numbers
  return sum
end

def self.square(number_set)
  square = (number_set).reduce(:+)**2
    # put the square of the sum of the numbers
  return square
end

def self.difference(number_set)
  difference = (number_set).reduce(:+)**2 - (number_set).map { |i| ii }.reduce(:+)
  return difference
end

puts Problem6.difference(1..100)

end

module Problem6

def self.sum(number_set)
  sum = (number_set).map { |i| i*i }.reduce(:+)
    #put here the sum of squares of the numbers
  return sum
end

def self.square(number_set)
  square = (number_set).reduce(:+)**2
    # put the square of the sum of the numbers
  return square
end

def self.difference(number_set)
  difference = square(number_set)-sum(number_set)
  return difference
end

puts Problem6.difference(1..100)

end

2520 is the smallest number that can be divided by each of the numbers 
 from 1 to 10 without any remainder.
 What is the smallest positive number that is evenly divisible by 
 all of the numbers from 1 to 20?

require 'problem5/problem5'
describe 'lowest common multiple' do 
  it "find the smallest number that can be divided by 1 through 10 with no remainder" do 
    expect(Problem5.divided_by(1...10)).to eq 2520
  end

  it "finds the smallest number that can be divided by 1 through 20 with no remainder" do 
    expect(Problem5.divided_by(1...20)).to eq 232792560
  end
end

module Problem5

def self.divided_by(number_range)
  list = (number_range).inject(:lcm)
  return list
end

puts Problem5.divided_by(1..20)

end

A palindromic number reads the same both ways. The largest palindrome 
made from the product of two 2-digit numbers is 9009 = 91 × 99.

Find the largest palindrome made from the product of two 3-digit numbers.

require 'problem4/problem4'


describe "largest palindrome" do        

 it "finds the largest palindrome of 2 digit numbers" do
   expect(Problem4.answer(10...100)).to eq 9009
 end

 it "finds the largest palendrome of 3 digit numbers" do
   expect(Problem4.answer(100...1000)).to eq 906609
 end
end

module Problem4

def self.answer(largest_palindrome_range)
  max = 0
  (largest_palindrome_range).each do |a|
    (a...largest_palindrome_range.end).each do |b|
       product = a*b
    max = [max, product].max if product.to_s == product.to_s.reverse
    end
  end
  return max
end

puts Problem4.answer(100...1000)
end

Each new term in the Fibonacci sequence is generated by adding 
the previous two terms. 
By starting with 1 and 2, the first 10 terms will be:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ...
By considering the terms in the Fibonacci sequence whose 
values do not exceed four million, find the sum of the even-valued terms.

require 'problem2/problem2'

describe 'solution' do 

  it "sums the first two terms to generate the third term" do
   expect(Problem2.fib(2)).to eq 1
  end

  it "sums the even-valued terms up to the limit" do
    expect(Problem2.fib(4000000)).to eq 4613732
  end
end

module Problem2

  def self.fib(limit)
    arr = [] 
    a,b = 0,1 
  
   while a < limit 
      arr << a 
      a, b = b, a + b 
    end

    sum = arr.select { |i| i.even? }.reduce(:+) 
   
  end

  fib(4000000) #sets the limit
end

The prime factors of 13195 are 5, 7, 13 and 29.
What is the largest prime factor of the number 600851475143 ?

require 'problem3/problem3'

describe 'answer' do 

  it 'will have the largest prime factor for 13195' do
    expect(Problem3.prime(13195)).to eq 29
  end

  it 'will have a largest prime factor for 600851475143' do
    expect(Problem3.prime(600851475143)).to eq 6857
  end
end

require 'prime'

module Problem3

  def self.prime(num)
    primes = Prime.prime_division(num)
    primes.last[0]
  end
end

require 'problem1/problem1'

describe 'solution' do

it "sums the multiples of 3 and 5 under 10" do
    expect(Problem1.multiples(10)).to eq 23
end

it "sums the multiples of 3 and 5 under 1000" do
    expect(Problem1.multiples(1000)).to eq 233168
end

end

module Problem1

  def self.multiples(stop_counting)
    (1...stop_counting).find_all { |i| i%3 == 0 || i%5 == 0 }.reduce(:+)
  end

end

export TWITTER_KEY=your_key_goes_here
export TWITTER_SECRET=your_secret_goes_here

$ echo $TWITTER_KEY 

ENV['TWITTER_KEY'] 

OmniAuth.config.logger = Rails.logger

Rails.application.config.middleware.use OmniAuth::Builder do
puts "key: #{ENV['TWITTER_KEY']}"
puts "secret: #{ENV['TWITTER_SECRET']}"
binding.pry

provider :twitter, ENV['TWITTER_KEY'], ENV['TWITTER_SECRET']
end

echo "leading env, yay"