• You could start mentoring your juniors because you have that new senior developer now.
• You could do code reviews because everyone wouldn’t always be working at 100% capacity.
• You could formalize your project workflow because the team would finally be rounded out.
• You could start offering services in that new framework because you hired the right person to take it on.

Is that how it would look? Or, would scaling up your team look more like this?

Sidenote: The metaphor here of juggling is not lost on me as a software manager.

You’ll see in the video that at first, Mike Boyd starts “juggling” just one apple. Easy enough, right? Most of us can self-manage just fine.

Within minutes, though, he adds a second apple. It’s a bit more tricky and he does drop the apples quite a few times, but he’s making it work decently well. Remember your first hire?

At only 10 minutes of learning to juggle (and having just dropped in his previous attempt), Mike grabs the third apple and gives it a go. It’s no surprise he drops again and the apples are getting pretty well bruised up by this point.

Nobody expects Mike to be able to juggle within 10 minutes, but the issue is that he hasn’t mastered juggling two balls well enough. He hasn’t trained his eyes where to look or his hands to toss effectively and correct for mistakes. Sure, he can force his way through to juggling three balls, but not without a basket full of busted fruits and vegetables.

How badly bruised will your team end up if you blindly charge towards that “ideal” future team size? What’s stopping you from practicing at building your dream agency today with the team you’ve got?

The post If Only We Were Just a Bit Bigger… appeared first on Garrett St. John.

In what I thought was a conversation between just my wife and me, we discussed taking our daughter downtown for a horse carriage ride around Christmastime. You can tell a kid 1,000 times to not tease their sibling, to feed the dog, or to clean up their room and they can honestly look you in the eye and tell you they didn’t hear you. But in one small, semi-private conversation I had inadvertently triggered my daughter’s new found hearing superpower and promised to take her for a carriage ride that night. Evening came and she asked when we were going and when I broke the news that we weren’t, but that’d we’d go next weekend…waterworks!

Whether you are a CEO, CTO, Tech Lead, or manager of any type, everything you say is a promise.

“I’m going to move you over to Project A next week.”

“We’re really going to focus on TDD this year.”

“I will get back to you about tasks for next week.”

All of these examples are loaded with commitment: “I’m going to…”, “We’re really going to…”, “I will…”. These are promises. But how about these examples?

“Going to that conference would be a great idea.”

“We want to start doing 1-on-1s this quarter.”

“I’d love to get you on a fun little internal project.”

Not so much overt promises, right? Perhaps to you, but to the people that work for you and hear these statements, they are often received as commitments and expect that action will follow.

Promises come from everywhere. They are in your employee handbook, in your 1-on-1s, amongst the things you say at staff lunch, and even in the precedents you set for your organization. Sound like a lot of responsibility? Well, it is. These people trust you to help them succeed, grow, and be fulfilled in their career.

It’s imperative that you become highly aware of the things that leave your mouth or get jotted into an email. Consider if you could be making a promise and if you are, log it as a task to be completed. If you’re not, work to control when and how you communicate and make it clear that you can’t commit to what you just said, but it’s something you will consider. Save the “just dreaming” conversations for closed team leadership meetings, your spouse, or a friend, they’ll understand you are just playing something out in your head.

Just as my daughter was disappointed with a broken promise I didn’t even realize I had made to her, your employees will be disappointed just the same. The negative impact of broken promises cannot be overstated.

The post Be Careful What You Promise appeared first on Garrett St. John.

Week 1: You jump in wholeheartedly. Conversations are had. Goals are set. You even found a new Fancy Tool to track progress!

Week 2: Fancy Tool reminds you to check in on goal progress. Not too much progress yet, but we’re still moving.

Week 3: Fancy Tool emailed you to check in with the team. You were able to ask a few people at staff lunch how things were going with their goals.

Week 4: Busy week. Fancy Tool emailed, but you just didn’t have time to spend on it.

Week 5: Fancy Tool is getting really annoying. You archive the reminder email.

Week 6: Unsubscribe.

…

Week 12: Quarter is over. You sit down for Quarterly Reviews, but no goals have been achieved. Are you surprised? Somewhat. You figure the team would have accomplished something. I’m not their parent!

If this looks even remotely familiar, you aren’t placing a high enough value on your team’s growth; instead, you value their production. The effort was noble, but the follow-through was weak. In fact, you would probably have been better not even asking their goals because at least they wouldn’t be disappointed.

When you ask somewhat how they want to improve, advance their career, and contribute to your team, you owe it to them to make it a priority. Can you imagine a guidance counselor asking a Freshman where they want to go to college and then just expecting to hear they’ll be attending next Fall when their name is announced at graduation?

Goals are not something that gets checked off of a task list today. Their longer-term nature means they need tending to regularly. So, how did we fix this?

• Prioritize: There are 40 working hours in most employee’s weeks. If every hour is filled with billable work, there is simply no room left to make progress on goals. It’s unfair to ask your team to work on their goals after hours, so when will they get done? Invest in your team by freeing up time to work on career development, you’ll see the returns through more maturity and increased loyalty to you and the company.

• 1-on-1 Meetings: Everyone has a different level of self-motivation, especially when it comes to personal development. If you’re having regular 1-on-1 meetings (you are, right?), this is a natural time to check in on progress since last time you met. No progress? Ask why. It’s imperative that you, as a manager of engineers, know what hurdles you can remove to clear the track for your team. Perhaps the goal is too big, break it down into smaller goals. Maybe they’ve had a change of heart, find new goals. Sometimes they won’t know where to start, point them to the starting line.

• Rewards: When your developers achieve their goals, reward them. They set a target and hit it. The reward doesn’t have to be monetary either; many appreciate recognition as much or more than money. The “Team MVP” trophy, parking in the reserved spot, or an announcement in the team chat are all great ways to recognize a job well done.

As a manager, it’s your job to lead your team. It’s your job to make their priorities your priority (while of course still running a profitable business). You must clear the path and provide the space for them to grow or they’ll find somewhere else to grow instead.

The post Helping Your Development Team Achieve Their Goals appeared first on Garrett St. John.

What I am asking you to consider is this:

What would it look like if your team operated like a competitive sports team?

• When your Wide Receiver carelessly drops a touchdown pass in the end zone, are they pulled aside, coached, and then sent back in to make the next catch?
• When your Running Back wants more touches on the ball, do you set clear expectations and work with them to create a plan to get what they want?
• If a strong personality is diminishing the team’s ability to operate productively, do you attempt to correct course? If they can’t change, are you willing to trade them away?
• Are you getting together to watch film after games to help everyone learn from their mistakes and improve as a team?
• If you as the coach can’t coordinate the team and win, should your job be on the line? (yikes!)

When you look at leadership in this way, running a software team versus a sports team is not all that different. You’d never expect a coach that can’t manage his talent to show up in a Super Bowl, so how should your team be any different?

The post If Your Software Team Was a Football Team Instead… appeared first on Garrett St. John.

Don’t Settle for Just Annual Reviews

The worst things you can do is to resign to reviews being mandatory and allow them to be the only time you communicate about performance throughout the year. It’s still hugely valuable to have regular 1-on-1s. This way when the annual performance review rolls around each year both you and your employee already know what the conversation is going to look like; the HR process just becomes a formality.

Deep Dive on a Topic

Pick an area of career development and spend more time discussing that topic than you may be able to in 1-on-1s. The subject should be specific to the individual and could range from improving communication skills to taking on leadership opportunities to focusing growth in a particular area of software development. By spending time planning out a path for growth, the individual will sense your investment in their success. A side effect of your investment is loyalty and loyalty helps to reduce turnover. Everyone wins.

Ask Questions and Listen Intently

“Just listen” is nearly always the rule but it’s worth repeating. Many times as managers or team leaders it can feel that we are supposed to drive the conversation and that we should have a list of talking points to cover, but this is all wrong. Without asking questions and leaving lots of room for our team to share their thoughts, struggles, and desires we fall flat on one of our most significant roles as leaders.

1. Actively listen with intentions to learn
2. Formulate a plan
3. Guide, empower, and encourage towards the desired outcome

So, while performance reviews are mostly useless by themselves, when adapted to fit your communication plan they can be used for good. Go forth and do good!

The post Making the Most of Performance Reviews appeared first on Garrett St. John.

Reviews

What is it?

If you’ve been employed for any amount of time, you are likely already familiar with reviews. Sometimes called a “performance review,” reviews are an opportunity to (usually annually) discuss accomplishments, areas for future improvement, and strengths and weakness. An annual review can also often serve as a natural time to extend pay increases or performance bonuses to employees.

How do they work?

In practice, reviews look comparable to 1-on-1s with their main differentiator being frequency (usually annually or semi-annually). Similar matters are addressed in both, including topics such as employee happiness, teamwork, goal settings, strengths, and areas of weakness.

What are the pros and cons of this communication method?

I consider annual reviews to be mostly useless and generally a waste of everyone’s time.

To motivate and correct course with your team, timeliness of feedback is crucial. An annual review cycle lets issues fester and good habits and career growth steps to go unpraised for far too long.

For these reasons, I suggest dumping reviews altogether or at least holding them quarterly if that’s the best you can offer. In their place, implement weekly 1-on-1s where you’re able to stay in touch with your team more regularly and react to missteps quickly.

If you need an opportunity to wrap up the year or give pay increases, pick a specific week’s 1-on-1s and schedule them for an extra half hour to summarize the year and reward each employee financially.

I hope this short series on communicating with your team has been useful. Whatever you decide to do, talk with your team, get to know them, and most importantly listen intently.

The post Communicating with Your Team: Reviews appeared first on Garrett St. John.

1-on-1s

What are they?

1-on-1s are really just that: a one-on-one meeting between an employee and their direct reporting manager. The goal of these meetings is to check in with your developers to ensure they are focusing on the proper tasks, that any roadblocks are made known, and to encourage open conversation about career growth and struggles.

How do they work?

How 1-on-1 meetings are specifically executed can vary based on team size, but here is a framework to work from:

• Allow for up to an hour with each team member with the ideal length landing between 30 and 60 minutes. Too short and there may not be enough time for drawing out issues and fully sharing insights. Too long and attention wanes.

• Most software teams should target a weekly 1-on-1 meeting with each member. This frequency prevents too much time from passing without the opportunity to share struggles and discuss growth steps. For larger teams (>10 devs per manager), a bi-weekly meeting may suffice and might be all your schedule can handle.

• Keep the conversation informal. Is it easier to have candid, open dialog in a conference room or over a coffee? Try reducing the pressure by taking a walk together while you talk or using the kitchen or lobby. If you are a remote team, face-to-face meetings might not be an option, but I would strongly encourage using video conferencing to make it more personal and show employees they have your undivided attention. It’s essential to create an environment that doesn’t feel like every time a 1-on-1 comes around employees should start nervously sweating.

• The role of the manager is to guide the conversation. The best 1-on-1 meetings take place when team members do the vast majority of the talking. Do your very best not to make the talk about you or your needs, and more about them and how you can help them succeed. Here is a list of questions to ask in 1-on-1s that can be used as conversation starts. Make sure to be an active listener and dig deeper on surface level responses.

• Close the meeting by establishing action steps. The steps should be able to be accomplished between the currently 1-on-1 and the next. This means lofty goals of learning a new programming language or submitting a conference talk proposal are well out of reach. Let the steps be created and agreed upon by both of you so that there’s mutual buy-in and commitment to action.

What are the pros and cons of this communication method?

Pros

• Increased loyalty to the company due to open communication channels and a sense that the organization wants to help them progress in their career.
• Higher efficiency and productivity due to less time spent on the wrong tasks or using an errant approach.
• Opportunity for feedback on your management style and how you can improve to help the team better.

Cons

• “Just another meeting” can feel like a distraction from getting work done to some developers. To avoid this sentiment, come prepared to 1-on-1s with notes and a defined structure to avoid aimless talking. As employees realize they are being heard and supported the value of these meetings will speak for themselves.

1-on-1s are quite possibly the most valuable communication practice you can implement within your software team. They give employees a regular opportunity to talk and for you to listen.

In my next post, I’ll be wrapping up team communication strategies with reviews, how they work, and the pros and cons of implementing them.

The post Communicating with Your Team: 1-on-1s appeared first on Garrett St. John.

Retrospectives

What are they?

By definition, the word “retrospective” means to look back on a past event or situation, and that’s precisely what this communication method is all about. Similar to the concept of stand-up meetings, retrospectives come out of the Agile software development strategy but are useful to all team. The goal of these meetings is to debrief at the end of each development cycle; typically a sprint or whatever release cycle your agency chooses to use.

How do they work?

A retrospective is a gathering of all team members involved in project work. Each meeting typically lasts 30 minutes and should be held at the end of every development cycle. The following three questions are posed to the group at each meeting:

1. What went well?
2. What did not work well?
3. What could the team do differently to improve?

The retrospective can be structured in many ways, but here is a loose agenda:

• Gathering progress (10 mins) – What did the team accomplish this cycle?
• Gain understanding (10 mins) – What went well? When was the team most productive? What did not work well? What roadblocks occurred? Where did processes break down?
• Plan moving forward (10 mins) – What are the highest priorities for the next cycle? How can processes be improved? What will remove roadblocks and maintain productivity?

What are the pros and cons of this communication method?

Pros

• Retrospectives allow the team to step away from grinding through work and consider how to work better, both individually and as a team.
• All team members are given a chance to express their opinions and management is able to hear about their work and general progress of the project.
• The exercise strengthens the team by allowing them to voice their concerns and work through areas of conflict in a healthy group setting.

Cons

• Without attendance and engagement from the entire team, these meetings will be less productive. Attendance to retrospectives should be mandatory for all team members.
• Due to the group nature of these meetings, expressive individuals may tend to be more vocal than those that are more internalized processors. Encourage everyone to provide input.
• Gained knowledge is valuable, but without action it’s worthless. It’s critical to take the feedback from each retrospective and adjust processes for the next development cycle.

Retrospectives are a valuable practice for all successful software teams. They are an excellent opportunity to give the team a voice in how the agency executes its work in the best possible way.

In my next post, I’ll be discussing 1-on-1s, how they work, and the pros and cons of implementing them into your team communication strategy.

The post Communicating with Your Team: Retrospectives appeared first on Garrett St. John.

There are four main communication patterns I have come across and plan to cover: stand-ups, retrospectives, 1-on-1s, and reviews. Let’s jump into stand-ups in today’s post.

The “Stand-up” Meeting

What is it?

I first heard of the stand-up meeting along with the popularization of the Agile software development method. The concept comes from the idea that standing for extended periods of time is uncomfortable and forces the length of meetings to stay short. I believe these meetings tend to lend themselves to a bit more of an informal atmosphere that mimics “water cooler” conversation.

How do they work?

The goal of a stand-up meeting is to allow team members to share challenges with their work and to coordinate efforts among team members where it makes sense. Let me hit some bullet points on the structure of these meetings:

• Meetings occur daily at the same time and place each day, usually the office kitchen or a conference room. For both entirely or partially remote teams, a conference tool like Zoom, appear.in, or Skype are helpful solutions to allowing everyone to attend.
• Attendance should be required of all employees, but absences or tardiness do not result in a canceled or postponed meeting.
• The meetings have a hard start and stop time and last no more than 15 minutes.
• The meetings are intended to be an uninterrupted (no phones, laptops, etc.) communication opportunity between team members, not a time for status updates to management.
• The goal of a stand-up meeting is to spark follow-up communication and to identify issues before they can have a significant impact.

A typical stand-up should pose the following three questions to each team member and should be answered within a maximum of 60 seconds (the duration of each response may vary by team size but should total to 15 minutes maximum):

1. What did I do yesterday that helped the team meet its goals (for the sprint, deadline, launch, etc.)?
2. What will I do today to help the team meet its goals?
3. Do I see any blockers that prevent the team or me from meeting its goals?

What are the pros and cons of this communication method?

Pros

1. Stand-ups open the lines of communication and allow for knowledge transfer between team members.
2. As each team member shares the answers to their three question, the entire team can get an idea of where the company is moving as a whole. This open sharing helps prevent the feeling of isolation within a particular project or feature.
3. Stand-ups are time limited to prevent them from dragging on. This restriction helps eliminate soapboxing or diving into specifics and keeps it from being just another meeting.
4. They serve as a great time to make quick introductions of new hires to the rest of the team. Breaking the ice for new team members makes them feel welcomed and gives everyone a chance to say “hi.”

Cons

1. The stand-up is not an adequate level of communication for a Tech Lead to have with their team members but may be just enough to fool them into thinking they can check off their “team communication” task for the day.
2. The development mindset often has a hard time distilling down the intricacies of their previous and current day to at most 60 seconds.
3. Team members may be inclined to wait to express their concerns and blockers until the next days stand-up meeting rather than communicating them immediately.
4. If you have a flexible start time or employees spread across different time zones, it can be hard to find a mutually agreeable time that is non-interruptive for everyone.

I highly recommend all teams implement daily stand-ups. The benefits are substantial and the cost to implement them is low.

In my next post, I’ll be discussing retrospectives, how they work, and the pros and cons of implementing them into your team communication strategy.

The post Communicating with Your Team: Stand-Ups appeared first on Garrett St. John.

Be Specific

Saying “thanks” is a great habit to be in, but it doesn’t often have much impact. If you look at any given day, you will likely say “thanks” at least 100 times. Someone holds the door open for you, “thanks.” You sneeze and someone blesses you, “thanks.” Your kid finally cleans up their room, “thanks.” We are in the habit of almost reflexively saying “thank you” for nearly anything.

We see this with little kids when they sheepishly apologize to someone. “Sorry,” they say. “Sorry for what?” we guide them. By forcing our children to state clearly what they are sorry for we hope to have them add weight to the apology.

Much the same applies when offering thanks to our team. When sharing praise with your team be specific about what it is they did well, the impact it had on the project/culture/company, and why you appreciate their contribution.

Give Praise Regularly

Encouragement should be given early and often. If you are waiting to round up all of the good things your team did for their annual reviews, you are doing it way wrong. If you are holding on to praise for a weekly one-on-one, you are doing it better but still wrong. When you notice someone doing their job well, going beyond expectation, or growing, don’t hesitate to stop what you are doing and make a note of their positive contribution. This brings me to my next point…

Make It Public

A personal gesture can be sufficient, but a public one carries more weight. Recognizing your team with a megaphone means you are so pleased you’ll share it with anyone in earshot. On the receiving end of public accolade comes the positive feeling of knowing your peers see the excellent work you’ve done and leadership has noted it.

Spread the Praise Around

Working extra hours, solving the most complex problems, and being the “shining star” developer are not the only reasons to give recognition. It can be easy to spot the positive impact top employees are having within an organization, but they are not the only ones deserving of praise.

Praise should be spread around to everyone on the team for their respective contribution, growth, and development. What this looks like is a Junior Developer finishing a training course, a New Hire making their first project commit, or a developer jumping in to cover for someone out sick all receiving praise and recognition. Keep a watchful eye out for even these small opportunities to applaud your team.

Encourage Praise to Not Just Be “Top Down”

Finally, praise should not come just from leadership. It’s essential to build a culture where everyone acknowledges efforts that push the whole company forward. There are a variety of ways to facilitate spreading praise amongst your team ranging from a dedicated corkboard where notes of thanks can be pinned all the way to software tools like Lattice that integrate into a team chatroom like Slack. Find a method that works for your team and your work environment, then start by leading the effort to spread the love around.

The post How to Give Meaningful Team Recognition appeared first on Garrett St. John.