Reorganizations are difficult in the best of situations. 

Stand up in your office and yell, “Re-org!”. How many people flinch, grimace or run from the scene? It’s a common reaction; most of us have been through at least one poorly-planned “streamlining” exercise, and that experience sticks with you for the remainder of your career.  

don't let this be you

But it doesn’t have to be that way! Even if you don’t have a lot of time to be 100% thorough (as is the case in most high-growth tech companies), there are some easy wins to make your re-org inspirational and trustworthy, rather than chaotic or, perhaps worse, opaque to the people most affected. 

  1. Have a strategy and stick to it (aka “don’t change for the sake of change”). Choosing to re-factor a team or an organization shouldn’t be taken lightly. As one of my cohorts says, you’re like a general creating a battle plan & marshaling the troops to head into battle. You’re talking about impacting people’s careers, which has a ripple effect on their happiness, the organization’s effectiveness, and even the company’s external reputation if done incorrectly (people talk, it happens). You want to keep your people happy and invested in the success of the transition, and accomplishing that usually means being open and transparent about the reasoning behind it, as well as selling the benefits for each individual involved. Are you making changes in order to better align with other partners in your organization? Shifting focus on specific services or products to better serve the company’s core mission? There are myriad reasons for reorganizing- just make sure everyone involved understands the reason(s) and that you own your message.
  2. Communicate effectively and with conviction (aka “own the message”). Anyone impacted by this type of activity should be able to count on a clearly-communicated plan, how they’re impacted individually, what it means for their own career progression and how it impacts the company. These are pretty daunting questions for most people to ask. Being met with a response that involves passing the buck (“I don’t agree with this, but I didn’t have a choice so you’re stuck with it”) or with a lot of ambiguity won’t inspire confidence. I’m not saying “don’t be honest”, but you’re most likely depending on the people impacted to help with transitions, deprecations, cross-training, etc., and that will be much more difficult to gain if those same people don’t understand the reasoning and don’t have someone with strong conviction leading those efforts.
  3. Control the message (aka “keep your mouth shut”). Seriously. If you’re involved in a re-org, make sure you don’t blab on and on about how “big things are coming” or provide snippets of detail that only provide a fraction of the entire exercise. Having an incomplete picture of something that’s so impacting doesn’t inspire confidence in your leadership, leads to undue worry among people who may or may not be affected, and may even thwart the effort via people throwing up road blocks or sabotaging the exercise. In the absence of clear, consistent information, people will usually believe the worst.
    Involve your HR business partner. Believe it or not, HR folks aren’t just well-versed in handling performance management problems and answering questions about benefits. Most HRBP’s I’ve worked with have some amount of training in organizational development and understand how to approach these efforts in a constructive and structured manner. They should also be involved to help you craft the message and prepare for any potential “fall-out” from the announcement.
  4. Be organized. This should go without saying, but having a tactical plan for rolling out your organizational changes and tracking the various pieces with show that you care enough about the outcome and the well-being of the company & anyone who will be impacted to make sure nothing gets dropped. It also inspires confidence in others if you yourself can confidently say that you’ve been as diligent as possible. You may miss something along the way, and that’s okay. But missing entire swaths of responsibility because you either forget or don’t take the time to think about what you’re doing really is inexcusable.
    Execute. Once you have a plan based on a solid strategy, work quickly to execute on it. Allowing it to languish allows more time for speculation — all those confidential meetings behind closed doors are bound to spawn conjecture, regardless of how well you control the actual message. Executing quickly also conveys your own sense of urgency and commitment to making the right improvements for the good of the organization.
  5. Be flexible. Everyone makes mistakes, and the larger the organizational change, the more likely you’ll be to miscalculate or misunderstand pieces of the situation. That’s okay, as long as you don’t paint yourself into a corner by approaching it as a one-time, non-negotiable exercise. Strike the balance between flexibility and vacillating though. Remember to have conviction and own the message.
  6. Build around functions, not people. People leave companies. One of the worst things you can do is impact multiple people’s livelihoods by catering to one or two people’s wishes, only to have them leave the company or the organization a couple of months later. This should NOT be construed as, “don’t worry about the people”. People are the most important aspect of a company’s success (or failure). If someone expects you to build an organization around them because they’re “important” or might be unhappy, then they probably have some soft skills issues they need to work through. If you do this on your own, what message are you sending to the rest of the organization? “You’re less important. You don’t matter as much, so we’re going to jerk you around. Good luck with that.” That’s pretty bogus leadership.
  7. You can’t please everyone. I’ve been a part of many re-orgs on both ‘sides’ of the coin, and it’s a rare event when everyone involved is “all peaches & cream” at the end. Put some thought into how each individual might react to the news. Have a coherent & considered story for those who challenge the decision or are just plain unhappy with it. And make sure that your fellow leaders are on the same page about that message so you provide a consistent experience, no matter who that unhappy person escalates to. And for cryin’ out loud… if you’ve been diligent and have the best interests of the organization & everyone involved in mind, don’t beat yourself up if someone doesn’t agree with your decision. Be empathetic, but remember to own the message and stick to your strategy.

None of this really takes much time, but it does take effort. As a leader, you owe it to the company, organization, and people to be a mature steward of the company’s resources and mission. Own it.


team structuring/building ops teams (srecon prep)

I vowed to take new risks when I started at Dropbox about a month ago, so when my Illustrious Leader volunteered my name as a potential panel member at SRECon, I decided to suck it up and go for it. Le sigh. I’ve never been great at speaking in front of large groups of people (or people in general). I want to make sense and provide value when I do speak, however, so I’m brain-dumping in the hopes that I’ll remember at least a few salient points. No guarantees though. ¯\_(ツ)_/¯

Panel topic: discuss the various approaches to structuring, building and maintaining teams dedicated to reliability across multiple types of organizations and infrastructure.

FWIW, I wrote this post back in 2012 about growing an existing team. Some of that’s repeated here. I also care less about the type of infrastructure (hosted, in-house, etc.) because I believe each model can apply to almost any infrastructure, provided some creativity is involved. I’m either still naive or a real veteran. #takeyourpick

How do we build teams that adapt to differing needs [over time]? How can we hire effectively for each combination of org and infrastructure?

First off, as the leader of the team, you have to be flexible and open-minded. There is no single formula for hiring a team based on the type of organization and/or infrastructure. While you can adopt/adapt portions of your past experience to each new role, you will (thankfully) always wind up with something different.

Before You Make Your Org Decisions

  • Before you hire anyone, understand who your customers are, their expectations and the longer-term direction the company is headed w.r.t. infrastructure and your organization. You don’t want to hire a core of systems-focused engineers with python skills if your main responsibilities include providing deep-dive code reviews and troubleshooting for production services written in java.
  • Get data to support any anecdotes from the conversations above. It’s not uncommon for people to grossly over- or under-state their needs, even if they’re in “ops” themselves. Don’t guess. Hiring and training n00bs is a huge investment, and hiring people before you have an understanding of where you’re headed can lead to a larger time suck and quick attrition if you make the wrong assumptions.
  • Determine the metrics that will tell you whether you’re successful at any point in time (technical debt reduction, # of outage minutes, number of internal customers/teams the team supports, etc.). Re-visit these regularly to make sure you’re still on track, and don’t be afraid to admit that changes based on those metrics need to be made (that will almost invariably happen). Make smaller, more frequent adjustments rather than waiting until a wholesale re-structuring is necessary.

Hiring Effectively for Each Combo

  • Regardless of the type of infrastructure or the size of the team, hire people who can help themselves through automation and standardization. This doesn’t necessarily mean “build a framework for All The Things”. Start with small scripts that can be cobbled together into something larger when the time comes. Build momentum by tying these efforts to actual metrics that the team and org can get behind and be proud of.
  • Hire people who are open to new experiences and learning new skills. My worst hiring decisions have come from bringing someone on board who couldn’t or wouldn’t grow with the team and the changing landscape. Managing someone out is drastically more difficult than justifying keep a req open until you find the Right Person™.
  • Don’t be afraid to hire juniors. When you do, make sure they have a tight mentoring relationship with a more senior engineer, a solid onboarding plan and a clear growth path.

Adapting to the Changing Landscape

  • Accept that you can’t plan out more than 6-8 months in any great detail if you’re in a high-growth situation. Keep one eye on at least 12 months into the future & communicate what you think you see to your team/partners/customers regularly to gather feedback, adjust strategy, etc.
  • Have a structure in place for ongoing education/learning & allow engineers time to take advantage of it. Make sure your customers/partners understand that N% of each team member’s time will be devoted to learning new skills that will make him more efficient and productive over the long term.
  • Create a hiring ‘flywheel’ within the company if possible. Partnering with other teams (NOC, datacenter ops, etc.) opens up another avenue and provides you more control in the type and quality of candidate for your role(s) over time. Some things to consider if you’re partnering with other teams:
    • make sure there’s a tight communication loop between the teams from the beginning
    • include those teams in your education program
    • create ‘pair programming’ or mentoring relationships with those teams
    • follow through on your commitment to the flywheel when the time comes
  • Unfortunately, not everyone on your team will be able to – or want to – change along with the role over time. Attrition happens. The best you can do for your team is to be honest about the challenges and provide everyone the opportunity to learn and grow. It’s okay if someone doesn’t want to take advantage of that though, so don’t beat yourself up over it.

What are the different organizational models?

Again, this should be underpinned by who your customers are, their expectations, your commitment to them, the direction of the company, the profile of the work load, and the team you’re assembling. This obviously isn’t an exhaustive list, and I’m sure I’ll miss many pros/cons to each. But that’s why there are multiple people on the panel.

Centralized “Infrastructure” Team, De-Centralized Service Ownership

Steph’s Def: Systems and Network Engineering, sometimes tiered, with “sysadmins” or NOC engineers comprising the first tier. More traditional (“so 7 years ago”) model, with less development work. Software development teams wholly support their own service(s) in production, although Infra may be responsible for overall availability/reliability.

Benefits/Pros Challenges/Cons
Devs “eat their own dog food” so they’re closer to the impact their changes make on production. The same benefit can be had from the “devops” option below. Can lead to multiple disparate operational processes and tooling/automation solutions if solid solutions aren’t already in place.
Infrastructure engineers may have more opportunity to hone Subject Matter Expertise in their specific area(s). Risk of inadequate prioritization of operational issues vs iterating on “product”
Built-in recruiting ‘flywheel’ with more junior engineers, as mentioned in the section above. Requires a strong commitment from all teams to maintain operational excellence, and solid, consistent communication between Infrastructure and Development orgs.
There’s still a larger pool of “Infrastructure-only” engineers to draw from today than hybrid dev/ops engineers (at the level we’re talking about). Can create a “black box” or “us vs them” mentality between dev & ops if the latter team is expected to support/troubleshoot production services.
Access to production may need to be restricted to a smaller subset of people, depending on your compliance profile.

Embedded DevOps/SRE/PE/Whatever-You-Want-To-Call-It

Steph’s Def: SREs are embedded within each development team, dotted-line reporting to the dev manager, direct-line to an SRE manager. Oncall duties are shared. SREs submit code and troubleshoot code-related issues alongside the devs, and devs are able to handle basic systems ops tasks.

Make sure your work load supports this structure. If you hire a bunch of senior-level engineers with software development experience, then ask them to babysit sick boxes all day, you’ll have a pretty high self-imposed attrition rate. As a leader, understand that making a distributed team an actual team, with shared knowledge and similar service levels and offerings, is hard. That effort must be shepherded by a strong leadership team (managers and engineers) who are all pulling in the same direction and communicating effectively.

Benefits/Pros Challenges/Cons
Better chance of creating a lasting partnership between dev & ops if team members are sitting together. Consider how likely you’ll be to actually find people with this level of expertise who are interested in the position. You’ll most likely need to invest heavily in the education and growth of team members to “get there”.
Greater number of internal career options/paths for team members. Must have a strong, communicative management team to pull together the embedded team members. Or just accept that you’ll provide inconsistent service offerings across the company.
Provides more fuel for promoting operational staff in dev-focused companies Everyone must able to handle the ongoing conflict between operations and new product/service development in a mature way.

Hybrid model

Steph’s Def: Traditional sysadmins and more development-focused ops engineers together on the same SRE team. This feels like more of a transitional state or temporary stop-gap, rather than a long-term solution.

Benefits/Pros Challenges/Cons
Easier to tailor your support offering to each customer’s situation and needs. Can create confusion across supported dev teams, particularly when teams compare what they’re getting out of your team. “Why do they have someone submitting code, and all our ops engineer does is maintain puppet configs all day?”
Functional structure when transitioning into a “devopsy” kind of structure over time. Managing multiple career paths within the same org structure can be difficult for less experienced managers or organizations. (this matters, believe me)
SysAdmins who want to learn dev skills have a built-in pool of mentors to work with. In a dev-focused organization, sysadmins may be seen as “low man on the totem pole”, with corresponding hurt feelings, etc.

No SRE or Ops Team

Steph’s Def: All engineers are responsible for everything in production, from system configuration to writing/deploying code to maintaining production services. Hey, it’s an option. Don’t shoot the messenger. If it’s a small shop running in a hosted AWS-like environment with none of the bells & whistles needed for managing larger, more complex infrastructure, then this is probably an okay solution? (I dunno- it physically hurts me to say that) I don’t have any pros/cons here, other than to say that once the infrastructure needs outgrow a basic implementation, you should probably look for a few operationally-savvy engineers quickly, because you’re probably already behind the curve on scaling, tooling/automation and standardization.

Okay, that’s it! Now at least I have some talking points for next week. If you’re around, stop by the Dropbox booth to say hello!

Holding 1:1s

I recently conducted a short management training session on holding 1:1 meetings, and I realized that I really should post that content somewhere. The practice is such an important one for the organization. I touched on this in my post about performance reviews a few months ago, but it definitely deserves its own spotlight.


1:1 meetings allow both the employee and their direct manager to prepare for performance reviews all year long. It’s a way of guarding against having to spend an obscene amount of time trying to recall what an employee’s goals were at the beginning of the year, what she has accomplished, and what her hurdles were. There’s less risk of forgetting major milestones when they are consistently discussed and documented. There should be no surprises or last-minute rememberances when the actual formal review is delivered.

There are a few other benefits to holding these meetings, aside from the regular focus on the employee’s career progression:

  • it’s an opportunity to provide her timely feedback, both positive and constructive, outside of her documented goals
  • the meetings provide a regular forum to talk about personal and personnel issues, to the extent that he is comfortable talking about them
  • it’s time set aside to talk about the environment as it relates to the employee, the team, the org, the company, and even the industry
  • it’s a great opportunity to receive feedback on your own performance as a manager

Ensuring the efficacy of 1:1s is a shared responsibility between both participants. If the right level of care is taken in preparing for these discussions, the potential to strengthen your employees and your team can be immeasurable!


Preparing for structured 1:1 meetings takes time, effort and attention- especially if it’s a new discipline for your team. It’s time well spent, however, and encouraging the proper habits up front makes the ongoing discussions more focused and productive.

The Initial Meeting

Schedule a long enough time slot for your first meeting to address all of the basics. This ensures that you are both clear on the ground rules and are beginning from the same point of view. An hour or hour-and-a-half should be sufficient. Just be sure to emphasize that subsequent 1:1s don’t necessarily need to take that long.

  • Use the first meeting to set goals, if the employee doesn’t already have them. Employees rarely have time to think about their own career, or they’ve never been taught how to think about it to begin with. One of your main responsibilities is the care & feeding of your directs. What does he want to do in the next one, three and five years? Often, employees don’t actually know where they want to be that far in the future. Start by probing what interests him, what he likes doing, who he admires. At the same time, explore what he likes least about certain roles and why (sometimes a person’s perception of a job doesn’t reflect reality). Then, build a plan around allowing him to explore a few roles within the company that might interest him.
  • Review the 1:1 document you will use to track your discussions together. Send this out prior to the meeting so the employee has time to digest it and prepare clarifying questions if necessary. If you have time, fill out a portion of it with them during the meeting to give them an idea of where to start.
  • Decide on the proper frequency for your meetings with the employee. His level, performance, how autonomous he is, and his length of time in the organization and on the team, and the demands on your own time are all factors that inform how frequently you should meet. If 1:1s are a new phenomenon for the team, I would start everyone on a weekly recurring meeting until both participants are comfortable with the routine. I would never pare a meeting schedule back farther than bi-weekly, however. Even if the meetings last ten or fifteen minutes, you both still need the opportunity to re-focus on his career to make sure everything is going according to plan.
  • Commit to your scheduled time. This is tough, especially if you have a more junior team who needs a weekly cadence or if you have a particularly large team. Interruptions to the calendar are always a risk; do a quick prioritization check before rescheduling a 1:1 to accommodate a late-binding request though. The more frequently you reschedule, the less apt the employee is to believe that you truly care about her performance.
  • Set clear expectations about the regular goals of the meeting, and make sure that your 1:1 doc format supports those goals.

Ongoing Prep Work

Most of us don’t have a lot of ‘free’ time nowadays (I can say that word- I’m old). But putting effort into making sure you’re prepared for each discussion will allow you as a manager to get the most out of the meeting and will reinforce the fact that you really do care about the employee. Devoting ten to fifteen minutes to gathering your thoughts prior to the meeting is definitely a worthwhile way to spend your time as a people manager.

  • Read previous 1:1 docs/notes to refresh your memory of what has been covered and what needs to be followed up on. If possible, carve out time in your schedule to do this at least 24 hours prior to your 1:1 to give yourself time to follow up on any actions that may still need attention.
  • Read the updated 1:1 doc from your employee (see below). Make notes where applicable.
  • Read the ‘fuzzy folder’. Most managers keep an email folder for each of their directs that contains communication about deliverables, performance, etc. I call it a ‘warm fuzzy’ folder because I like the thought of it only containing positive messages. 🙂 If there is anything new and noteworthy, add a note to your copy of the 1:1 doc.

The more frequently you prepare for the meeting, the less time this prep work will command. Once you’ve completed your own checklist, you’ll be ready to have a productive conversation.

The Doc

I’ve uploaded a copy of my own 1:1 doc template for reference. I haven’t had to update it much in the past ten years, although I did create a slightly different one for 1:1s with managers, and I’ve moved to using a private google form to make it easier. It isn’t pretty, but it allows us to cover all of the topics mentioned in the first section without wasting real estate.

I believe that the employee should make time to fill this out themselves and send it off to the manager ahead of the meeting. Owning the content forces them to think about their career outside of one recurring discussion, and it gives them the control over where and how to focus the meeting. The responsibility for making the most of the chat is shared between both participants, but that control is a pretty important factor in showing that the meeting is meant to help the employee, not the manager.

  • Progress Against Goals This is a fairly self-explanatory section. Define the frequency of reviewing this based on the length of the goal, level of employee, and the consistency of progress made against them.
  • Opportunities This section is broad by design, and could cover anything in the environment, the team, the org, the company, or the industry. Basically, it’s a chance for the employee to tell you where he believes more effort should be focused. I would rarely let someone get away with saying they have no new ideas for opportunities for improvement within the environment. It’s a challenge to them to keep making their job, team and/or company better.
  • Project Status I use this section more for managers than employees. I get enough project status reports to choke a horse, so unless there is a pressing escalation I need to know about, this is the area I spend the least amount of time on. (no animals were harmed in the writing of that sentence, btw)
  • What Have You Learned? If someone isn’t learning as a part of their job, it might be a sign that they aren’t challenged in their current role or need a fire lit underneath them. Even if their comment is, “I learned I need a day off”, it will give you insight into their mind set and open up a discussion if it’s not already covered elsewhere in the doc.
  • What Do You Need From Me? Get your team used to using you as a resource. Show that you care about making the most of their experience on your team. Ask for ideas on your areas for improvement, blind spots, etc. It’ll only make you better as a manager, and it may provide valuable insight into the dynamics of the team and the employee’s role in it.

You can always add a separate section into your own template to track previous action items or any number of more discrete subsets of the information below. Keep it focused on the employee’s career and the health of the team, rather than tactical project topics if possible.

The Meeting Itself

I only have a few recommendations about the meeting itself. Most of the work is in the preparation and follow-though.

  • Keep the mood and tone consistent with the team’s culture and your relationship with the employee. Introducing formality into an informal environment can hurt the process of gaining the trust necessary to have an open and honest conversation.
  • Create an environment where you can concentrate on the meeting. Close any applications aside from the one you use to take notes in, and set your mobile phone to vibrate (or just turn it off if that’s possible).
  • Keep focused on the agenda. If you run long, make sure to schedule a follow-up meeting to address any important points you haven’t gotten to within the next 24-48 hours if possible. (keep the momentum!)
  • Review your notes together at the end of the session. Canvass the employee for feedback to make sure you leave the meeting with the same understanding.
  • Send your notes to the employee as quickly as possible after the meeting.

That’s it! Short and sweet.

Having Tough Conversations

Constructive feedback helps an employee improve, and should never be called negative. It’s the same reason that performance reviews should cover areas for improvement, rather than weaknesses. This is more than just semantics. It sets the tone for every subsequent conversation you have with the employee. This topic is obviously worthy of many books, but here are some short points I’ve picked up over the years that have helped with having tougher or more critical discussions.

  • Be honest. No one likes to be lied to, and she should appreciate the fact that you’re delivering the message in a straightforward manner like an adult.
  • Be objective. Separate the person from the conversation, and be prepared with concrete examples. Make sure to include the consequences of their actions. (e.g. “failure to deliver your portion of the release caused three of your team mates to work overtime”) Keep the feedback anonymous if possible, though. If you need to bring someone else’s name into it, either represent it as your own feedback (if you’ve noticed it yourself) or consider inviting the other person in for some facilitated discussion. If you’re not trained or experienced, bring in your HR representative to help.
  • Recognize perception issues You should have enough information about your employee’s performance to ascertain whether feedback can be attributed to her performance or someone’s perception of her performance.
  • Deliver the message clearly. Avoid the old “sandwich” message, such as, “You’re doing great! You could work on the timeliness of your code submissions, but overall your performance is solid.” Does he really need to work on timeliness? If so, then be clear about it.
  • Take ownership for delivering the message. Don’t play the “good cop” role and blame someone else for the constructive feedback. If legitimate feedback is given to you by someone else, delivering it is in the best interests of your employee. If you disagree, it may be clear that there is a perception issue that you still need to address. Either way, you are the authority for your team, and you should own the message. Just don’t be a jerk about it.
  • Don’t pressure the employee for a response, especially when broaching a new topic. But don’t let her go away and fester for days or even weeks either. The end goal is to coach her, and you need to give her enough time to participate in a constructive conversation.
  • Give the employee ownership in the actions. Increase his investment in the solution by allowing him to help define the action plan, where relevant.

Following Up

It’s not enough to just bring up a performance issue and then assume that the employee will take care of it.

  • Follow up regularly. If you provide constructive feedback to the employee, it is your responsibility to maintain focus and make sure she is making progress toward addressing the issue. Following up shows you are invested in her improvement and that you expect her to hold up her end of the bargain.
  • Solicit ongoing feedback from any affected parties to make sure the plan is working. Provide timely updates to the employee so you can work on correcting his course quickly if possible.
  • Call out positive progress as reinforcement. I don’t know too many people who thrive on a consistently negative message. If she’s doing well, then make sure she hears that. She’ll be more receptive to feedback the next time around if you’ve shown that the process is meant to make her more effective and happy in her role.
  • Recognize when to bring in HR. Use your HR partner liberally, if only for a sounding board prior to having the conversation. If you are uncomfortable at all with driving the discussion on your own, ask him to give you guidance or attend the meeting along with you. A manager should always be present during performance-related conversations, but it doesn’t hurt to have someone more experienced there to help guide the meeting. If you’re unsure about whether HR ought to be involved, just ask. They should be willing and able to guide you through it.

This process does take time, but it’s so much better to have a tough discussion at the first sign of an issue than to wait until it’s out of control or affecting the team or your customers.

Headcount Planning and Management

Headcount planning and management across a team or an organization is a complex process. In a changing environment, current and forecasted headcount should be revisited regularly in light of many factors, including changes in strategy, level and type of work load, the changing work force landscape, and goals & growth plans for individual team members.

This post might be short, but the process itself requires a good deal of time and considered thought. Here are the main factors or questions I tend to ask myself and the team when reviewing current and future states. Additional ones will always pop up during the evaluation exercises, of course. And keep in mind that the process doesn’t just apply to increasing headcount. Like it or not, contraction is also sometimes a necessity if you’re running your organization like a business that wants to succeed. I’ll focus on growing the org here though. It’s a happier thought.

Understand your current work force

In order to evaluate your headcount plans and make any decisions on whether to potentially change course, you need to understand your current state.

  • Do you have a plethora of specialists? Mostly generalists? A combination of both?
  • Is your staff a mix of experience levels? Or are you heavy on seniors or juniors?
  • What are the goals and career path for each member of the staff?
  • Are any key people planning on moving on within the next 12 months?
  • Where are your human single points of failure?
  • If you have a global team, are you balanced across sites appropriately? Does it matter if teams are imbalanced?

This exercise may take considerable effort the first time you complete it. Every time you revisit it, it becomes easier, assuming extensive time hasn’t passed and the organization hasn’t changed drastically. Discuss it with your peers and customers to get their perspectives, then document it so you don’t have to reinvent the wheel down the road.

Analyze your current work load

The second piece of the pie (mmmm… pie…) is to analyze your work load. I’m not talking about knowing what your work load looks like, but actually understanding it. Throw your metrics from projects, tickets and interrupts into a spreadsheet, then use a handy-dandy pivot table to slice and dice the data if that works for you. What’s the profile of the work for your team?

  • If you lead a technical team, is the majority of the work technical? Or are ‘soft’ responsibilities such as planning and project management that are usurping time from actual engineering?
  • Are there any staggering imbalances? For example, do you have 20 senior engineers on your team, but 20 junior engineers’ worth of work?
  • Does a large percentage of your work load fall onto the shoulders of a small portion of your team?
  • Is there “crap work” that should be automated away or just removed? Do you have the right skill set to address those efforts?
  • Does all of the work your team is doing belong in your team? Or should it be distributed to other teams in the organization/company?

Really, you just need to answer the simple question, does your current staff actually serve your current organization well? Depending on the number of surprises you encounter during these first two exercises, you may need to refactor your work load or quickly re-organize the current staff to alleviate immediate concerns. Just make sure that you’re not making changes for the sake of change, and that the moves you make will serve the needs of the organization for a while to come.

Understand your forecasted work load

Now it’s time to force yourself to think longer-term. Where should your team or organization be in 12, 24 or 36 months in terms of headcount and skill set? This requires visibility and foresight into the company’s and industry’s direction. If you don’t have a well-defined 3-year plan, it’s okay. Make solid estimates through the length of the well-codified information you have, then extrapolate from there, keeping an eye on potential changes or demands in the industry regularly.

  • Do you have the requisite skill sets and the proper number of people to cover the major initiatives on the horizon?
  • Do you have redundancy and contingency in technical and leadership skill sets?
  • How many of your current employees are likely to remain in their current roles – or even within your organization – in the next 1-3 years?
  • Will efficiencies or other environmental factors play a role in the required skill level in the future?
  • Are there new developments in the industry which could change the mix of skill sets in the future?

So now you know what resources you might need in order to address your forecasted work load. Now how are you going to facilitate the potential growth and the ongoing management of it?

Understand the Recruiting Landscape

Say you’ve now figured out that you need to double your work force over the next 12-18 months to hit your mid-term targets. How do you know if that headcount ramp is realistic?

  • What does the recruiting landscape look like? For example, much has been said lately about the ongoing dearth of system administrators. How will that impact your ability to cover the forecasted needs for the team?
  • Do you have the resources to recruit and interview enough candidates to hit your targets?
  • Can you create your own recruiting flywheel? Does it make sense in light of your forecasted work load? If you have the opportunity to hire junior engineers and/or managers and grow them within your organization, it’s a viable option for various reasons: it’s an opportunity for mentoring for your managers and senior engineers, shows the org believes in career progression, gives you a chance to positively influence a new manager prior to them moving into a position of greater authority or influence.
  • Does it make more sense to augment your staff more quickly with contractors or interns for specific roles? If utilizing interns is a viable alternative to bolstering your work force, then great! Give them challenging and meaningful work so that they want to come back and work for you afterward. It’s a great way to kickstart that recruiting flywheel.

There is substantial investment in just getting candidates in the door and through the interviewing process. The same can be said with managing interns or contractors on an ongoing basis. If your org can’t handle that additional work load along with the responsibilities already on your plate, then it might be time to re-think your forecasts.

It’s not just about hiring engineers

Planning for growth isn’t just about how many engineers you need and how many you can realistically hire. There has to be a framework to support the people you bring in.

  • What changes must be made to your leadership staff to accommodate the growth? Do you need more managers? Does your current management staff own the proper knowledge or experience to lead a larger organization, which inherently has different challenges?
  • Do you have sufficient manpower to train your new hires while still making progress against the road map?
  • Do you need to consider creating another level of leadership to accommodate expansion? Perhaps you don’t need more managers, but rather team or technical leads to act as a buffer for more of the day-to-day activities. If there are changes or additions to be made, make sure those are fed back into your headcount estimates. Keep in mind that if you promote a more senior engineer into a lead role, you will lose some or most of their productivity, and they will most likely be replaced by someone either more junior or less familiar with the environment.
  • Will the infrastructure, facilities and HR processes & tools support a significant increase in headcount? If not, who owns making sure those grow along with the organization?
  • If there is an increase in projects along with headcount, do you have sufficient capability and staffing to accommodate the management of those projects?

Once you’ve answered these questions, ask yourself again, is your headcount ramp realistic? If not, what are you going to do about it? It might be time to gather your information into a coherent argument based on the numbers and deliver the tough message to senior management that the forecasted work load just isn’t reasonable. Otherwise, happy hunting!

“Rock Stars”

While this isn’t a post about hiring specifically, I’ll add a word about hiring exceptional people. “Rock stars” don’t just exist at the most senior levels. Juniors who come in with a great fire & attitude are at least as valuable, since they may have a longer life span within the organization, have a fresh perspective, and may be a bit more malleable. Regardless of their skill level, every person in the organization needs to be continually challenged and given growth opportunities. If you can’t cover that, then don’t hire them. There’s too much investment in hiring, training and coaching to make that mistake.