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!

Make my job as a Hiring Manager easier. Please.

Note that I’m not speaking for my company or my organization. This is merely what makes my own life as a Hiring Manager easier. 🙂

I reviewed about 40 CVs in about an hour this morning. Here’s what helps/hinders optimizing my time with each CV in that 90-ish seconds:

Spell check. Seriously. It’s 2014. And while you’re at it, check your tenses. If I have to make a herculean effort to decipher what you’re trying to say in something as important as your CV, then what might your daily communication require?

Mismatched Objective. If you must have an objective, make sure you understand the role you’re applying for & update your CV accordingly. It’s typically one of the first sections of the doc, so make it worth the reviewer’s time. You applied for a hands-on engineering role, but your objective says you want to manage an Advertising team? My first reaction is that you’re using my role as a foot in the door & don’t have any particular allegiance to the work my team does. Or that you didn’t take enough care to update an older version of your CV. Either way, it doesn’t bode too well.

You’re an expert? There are very few people in the world who are experts at any given thing. I happen to be lucky enough to work with some of them (and know a few others). Do some research before you sell your level of expertise. Same goes for listing skills on your resume that you have very little familiarity with. I’d much rather see a one-liner in a cover letter telling me that you don’t know particular skills listed in my job description, but that you’re a quick learner & will do your damnedest to be successful.

What have you actually delivered? This is particularly important for more experienced candidates (which I happen to be searching for ATM). It’s cool that you supported a large-scale heterogenous enterprise environment, but what did you actually deliver? What impact did you personally have on your team, organization and company? Give me metrics! Specifics! Deliverables that you yourself were instrumental in! Then please be prepared to talk about it in phone screens and on-site interviews.

Keep it brief. I tried to review a 4-page CV. I made it through half of the first page before I gave up. I would have kept going, had the content “grabbed” me enough to make me think the best was yet to come. Keep it succinct- it’s one of the traits I cherish most in my team members. And with an average human attention span of 8 seconds (give or take), it’s a pretty critical one to have.

Applying to everything. It’s okay if you apply to a few roles that have similar requirements and responsibilities. But applying for project manager, people manager, sales, software development and SRE roles all at once? That makes me think there’s a lack of direction, commitment to my role, self awareness and/or focus. Pretty difficult for me to decipher whether you’re a good cultural fit for my team- whether you’re invested in the work. The exception being, of course, junior candidates fresh out of college who just don’t know. We can match those skills to the right role.

These are some of the more important ‘soft’ points that will at least make my life as a hiring manager easier. The rest (technical acumen, personality, delivery) is [mostly] up to you. Good luck!

ps- I’m hiring.

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.

Introducing a New Project (to Ops)

Everyone owns slightly (or drastically) differing opinions about how an IT project ought to be managed. I don’t believe in only one correct way to run a project. The best project teams I work with or observe adapt in various ways: project by project, team by team, customer by customer. Regardless of the method, I expect everyone involved in a project to share some core principles:

  • Adhere to Defined Roles
  • Adhere to Defined Processes
  • Communicate

I’ll focus on the introduction of a hypothetical project of some size and breadth to illustrate how these principles should be applied to make the most of the project team at the outset. The first few days or weeks are the most critical for setting the tone and laying the foundation for the remainder of the assignment. For purposes of this scenario, the production operations organization as a whole is involved in 20+ disparate projects this year, and every one of them is “high priority”. At best, we have two to three engineers focused on specialized areas, from networking to storage to infrastructure core services (LDAP, DNS, etc.).

The introduction of a project is vitally important to its success, but it can be marginal at best without a formal process. Assuming there is no well-defined process, I can learn about new demands on my team in myriad ways, including

  • hallway conversations, either directly or overheard
  • random mention in an email
  • second-hand through a member of any number of non-Ops teams
  • request for resources to help with a build-out within a ticket to an engineering queue
  • random entry in a project plan
  • buried in a response to a separate, unrelated query

None of these can or should be considered a “process”.

Introduction of the Project

Here is how this particular project makes its way through the Ops organization. At this point in the project, a commitment for delivery in two months’ time (40 working days) has already been made to the customer, and the PM has already furnished an update to the customer and senior management that the project is on track. No project plan or list of requirements has been furnished to our org.

During this same time frame, our team is on the hook for delivering two other high-priority projects. Our resource plans show that we’re already 25 man days in the hole without considering this new request, and various engineers have been asked to put in extra time to get us over the hump. We’ve also learned that the project was first introduced to the software development organization four weeks ago.

  • Initial contact with the team comes from three sources: an URGENT email to me from a PM asking for resources to build out a test infrastructure (this indicates it’s already an escalation), a second request from the same PM directly to an ops ticket queue asking for work to be done on the project, and a hallway conversation between one of the Ops managers and a developer on the project with a heads-up that development work is already underway.
  • Early estimates provided to Ops come from software developers who don’t have the time or background to understand our infrastructure or support services well enough to estimate what needs to be delivered.
  • In the next Ops Management meeting, we assign a senior engineering resource to participate in design conversations with the lead developers, and a resource to build out the test architecture once we’ve vetted the design. (the request to build out a test platform makes no sense when we don’t even understand whether the design itself will work in our infrastructure).
  • The scheduling of meetings between the engineers and the facilitation of the discussions falls on our management team. One of our managers will now slip one or more of his own priority deliverables in order to take on this portion of the project.
  • After our engineers complete their design review discussions, it is apparent that the initial resource estimates based on the information we’ve received from the developers are woefully inadequate. The project requires 3 full man weeks of Network Engineering time for design and implementation, a storage engineer for a full month, four weeks of front-line Ops work for deployment of infrastructure, software and testing, and a week of a capacity planning engineer’s time.
  • The project also requires additional hardware which was not factored into our recent server purchase, so we must determine whether we can re-coup machines from other projects or place an expedited buy with one of our vendors. If we determine that we need to “steal” hardware from another project, we add another two weeks of effort from our front-line Ops team.
  • In the middle of trying to work out whether we have enough resources to hit the already-promised deadline, I receive an escalation from the PM for resources to build out the test infrastructure, and am pinged by my boss on why we don’t already have a solid Ops project plan for the initiative. It’s kind of getting ridiculous at this point.

This project is clearly not on track, and due to lack of proactive communication and solid planning, Ops is the blocker right out of the gate. (and you wonder why Ops engineers tend to be surly!) The exercise above has taken five days to complete, which means we’re now down to 35 man days to meet the deadline committed to on our behalf. There is zero chance that we can deliver on this project without missing deliverables on at least one of our other high-priority projects.

Lessons Learned

Based on the core principles listed in the introduction, we have a number of items of feedback for various parties involved in the project.

Adhere to Defined Roles

  1. The roles and responsibilities for everyone involved in the project weren’t clearly defined, including determining the correct points of contact and decision makers within Ops. This led to the PM contacting both me and an engineer for the same work, as well as a developer pinging another Ops manager.
  2. Because there was no single owner, we risked either duplication of effort or no effort, both of which are inauspicious ways to kick off a project.
  3. Ops’ absence in determining the delivery dates for the project meant that the customer received a promised completion date that the project team could not honour.

Adhere to Defined Processes

  1. Multiple processes were used for introduction of the project into Ops.
  2. Because there was no agreement on how to introduce the project into our organization, I received an escalation contact prior to an initial request for resources.
  3. No regular update was given over the first four weeks of the project; Ops might have been able to scramble well enough to hit the deadline had we known about the project earlier.


  1. The lack of a clear project plan or requirements list forced us to spend time gleaning that information from various sources prior to making progress on planning or execution.
  2. Incorrect communication to the customer about our ability to meet the deadline put us under the gun to deliver from the outset.

Preferred Introduction Process

Here is how I would expect a project of any weight to come across our organization’s radar. I am not saying that adhering this this particular process will remove resource “crunches”, late-binding requests, or competing high-priority projects. It will, however, allow for control over how projects are prioritized and how resources are distributed across them.

  1. During initial conversations regarding a new project, the PM and lead developer answer a base set of operational questions provided by the Ops team. The list of questions will vary depending on the request type.
  2. Answers to the questions are submitted to the Ops management team to be discussed internally. That discussion yields basic resource estimates and the assignment of an operational engineer to participate in design reviews.
  3. Shortly afterward, a project review meeting is held with all stakeholders to discuss requirements, resourcing, timing, and roles & responsibilities within the project team. The ops organization should send the engineer(s) slated to work on the project, at least one manager who can represent the org, and the PM responsible for the operational work.
  4. A full project plan should be published following the meeting, with clear requirements, deliverables and milestones defined. Project plans and meeting notes should be posted to an easily-accessible file share.
  5. The PM should review the plan with the customer quickly, and any requested amendments should be re-visited with the project team immediately.
  6. After the review of customer feedback, the project plan is locked down, and any new requests are considered “scope creep” and added to the project’s backlog in priority order. Each high-priority request should be discussed within the project team and should include stakeholders in order to determine whether it can be accommodated prior to committing to it.
  7. Regular succinct project updates should be furnished to all stakeholders to avoid last-minute escalations when a milestone is in danger of slipping.

Initial Project Meetings

The first meeting in any project should be a simple high-level walk-through of the project with whomever can define the proper resources for the initiative. This should happen as soon as the project has been approved and really shouldn’t last longer than 20 or 30 minutes. All we care about is getting the correct people in the room for the full scoping exercise and understanding the priority of the project compared to the other initiatives on the slate.

The second meeting should be of longer duration and include all of the resources necessary for delivery. I would much rather schedule a half day for this one than to head into a large project without all of the critical information. The agenda should cover defining the roles and responsibilities of each team member and ensuring that every participant understands the requirements well enough to scope their deliverables and provide reasonable time estimates for milestones. Engineers expect very clearly-defined roles and responsibilities up front, and I can’t blame them. Worrying about who they have to talk to about specific portions of a project, who makes what decisions, what bits of information are important and which aren’t, or who owns specific pieces of the technology direction or implementation just reduces their ability to do their jobs properly. Some questions to consider for that second meeting:

  • Who is the primary customer, and have they provided sufficient requirements?
  • What are the requirements and end goal of the project?
  • What is the priority of the project compared to other current initiatives? (while this should be addressed in the initial meetings, the engineers should also understand the relative priorities)
  • What is the communication channel with the customer?
  • Who is the subject matter expert for each major piece of technology?
  • Who makes decisions on the technical direction of the project? What happens if there is a stalemate on making a decision?

And the ‘soft’ stuff:

  • What is the escalation process? What is or isn’t worthy of escalation? Where does the buck stop?
  • What is the project manager’s role in the project?
  • What is the expectation around scoping dates for deliverables and milestones? Is contingency time added into each deliverable? Does the project itself have padding to allow for slips?
  • How often are the engineers expected to give an update on specific deliverables versus the overall progress toward the next milestone?
  • What do various stakeholders want to know about on a regular basis, and how would they like to see that information?

Answers to these questions should all be documented in an easily-accessible and visible place in the project’s doc repository from the beginning. Quite a bit of the information can be defined on an org- or company-wide level and shared across projects. I would expect a link to the document to be included in the header of the project plan and of every project meeting agenda. Any new member of the project should review the information with the PM prior to any participation in the project. Every manager who has an engineer involved in the project should also be familiar with the info, particularly anything to do with resourcing.

Regular project meetings should be scheduled (scrum/agile, waterfall, whatever). Every person with an outstanding deliverable, anyone expected to provide technical support and any “decision maker” for outstanding questions should attend or provide an update prior to the meeting if they’re unavailable. I’m a fan of stakeholders staying away from these meetings unless a prioritization discussion needs to happen. Too many pointy-haired bosses detracts from actual engineering progress.

the never-ending battle

Supporting Thoughts

Aside from the introduction of the project, there are many other facets of project management that are important for ensuring smooth delivery. Communication, defining roles and processes, and reporting at the right level are all integral to a project’s ongoing success.

Communication Is Most Important

The most important responsibility of a PM is to not only facilitate communication, but to have clear, crisp communication herself. This is important for the other participants as well, but engineers are typically paid to focus on technical delivery first and foremost.

Don’t be afraid of people. A PM shouldn’t shy away from human interaction (face-to-face, video conference, phone) and at least 50% of her day should be filled with talking to people (I pulled that number out of thin air, but it seems pretty reasonable). Like it or not, you can’t get the entire context of why a deliverable is late or why an engineer is spending “so much time” on a particular deliverable from a tracking ticket.

Minimize interruptions. I would also expect a PM to also strike a balance and be reasonable with the interruptions. If a deliverable is due in two weeks and yesterday’s update shows that it’s on track, I don’t see any reason to interrupt an engineer for yet-another-update. Everyone’s time is at a premium every day. Use discretion, common sense, and the guidelines that were set up in the initial meetings to determine whether that daily update is really necessary.

Be succinct. I don’t know too many people who enjoy reading a 3-page project update or listening to a 5-minute monologue, only to learn that the project is on track and there’s nothing to worry about. Verbal diarrhea during project review meetings is pretty terrible to sit through.

Call out important points explicitly in email. Use bold fonts, red colour or something similar to call attention to new actions items or issues. I’m a fan of the ol’ TL;DR format. A bulleted list containing what I honestly need to know about at that top of an email makes the team more efficient and appreciative.

Project Roles and Responsibilities

I believe that a Project Manager who is expected to lead an Ops project should have basic understanding of operational concepts. There are varied opinions on this, and some will say that if a PM asks the right questions, it doesn’t matter whether they understand systems or networking. I say that’s hogwash (because I’m old), and that if an Infrastructure PM doesn’t know enough about managing a system with cfengine/puppet/chef/etc, then they can’t guide the conversations, ask the right questions or help work out dependencies. At that point, they’re a Project Coordinator (big difference), and I shouldn’t be expecting them to drive a project on my team’s behalf.


I believe there’s a difference between a project coordinator, a project manager, and a program manager. Too often, these roles get confused or just plain aren’t defined, which leads to incorrect expectations from those involved in the project. Each organization needs to set their own job descriptions, but here are mine:

Project Coordinator: Project Coordinators are purely tactical. They get told what to do & how to do it, then it just magically gets handled. These are the people I prefer to work with. Part of it is a trust thing. I don’t dole out the responsibility for managing my teams’ resources easily, mostly due to the points I make later in this post. Part of it is that I’ve historically had strong technical leadership on my teams who can manage scoping and resourcing fairly well on their own.

[Technical] Project Manager: A really good project manager understands the resources and deliverables well enough to make suggestions about how to scope a project. They should also have enough knowledge to formulate considered, relevant questions to spur the right discussions. How does this project for X service impact its interaction with Y downstream service? I would not expect a TPM to know the answer, but I would expect a good one to be able to ask the question and grok the answer. I would also expect a solid TPM to call BS on time estimates that are just obviously way off base. The build-out of a new data centre is scoped at 3 days & you have no tools/automation to facilitate that? Dude.

[Technical] Program Manager: I confess to not having worked with too many honest-to-gosh program managers in my career, so I’ll just say that I would expect them to have a larger, more high-level view of really gnarly initiatives spanning multiple organizations, and to manage other project managers or coordinators who would take care of the lower-level responsibilities such as task tracking, updating project plans and keeping track of resources.

Other Project Team Roles

Engineer: Engineers should be focused on technical delivery as much as possible. There are a few other things that need to happen to facilitate that delivery.

  • Be realistic and take your time when asked for estimates on deliverables and milestones. Then pad those estimates, based on the project guidelines.
  • Know your audience. Keep updates less technical when necessary.
  • Learn about escalation – when, why, how. Escalation isn’t always a “bad thing”. Sometimes asking for assistance or feedback is the best thing you can do for yourself, the team and the project. If you’re already overloaded & don’t tell anyone about it, then we’ll continue to assume that you have the time to hit your deadlines or take on new work.
  • Being proactive on relaying progress, blockers and risks will enable the PM to remove those blockers and escalate issues before they become hair-on-fire scenarios
  • Provide feedback into the process constructively. Yes, Ops Engineers have that well-understood culture of…. curmudgeon-itis. Let it go, and be productive in your discussions with PMs. They honestly are trying to make your life easier.
  • Be patient: not every PM or customer has perfect technical understanding. If they did, they’d be your engineering team mate.

Manager: First point of escalation. In Operations, managers are typically better-poised to assign and manage resources across multiple projects. Project managers aren’t usually deep enough into the scope of our work load across all projects or the specialized skill sets within the team to address this themselves. We do include the PM in the conversations so that he understands what’s involved in the process.

  • Listen to the PM when he escalates to you. If something doesn’t make sense, then ask the relevant questions to get to the heart of the issue & then use the interaction to refine the escalation processes.
  • Hold engineers accountable for hitting their deliverables.
  • Listen to your engineer when she tells you that she’s overloaded, that a deliverable or milestone is in danger of slipping, or that the team flat-out missed something in scoping exercises. Not listening just sets the team up for either heroic efforts or missed deadlines.

“Decision Maker”: When there are conflicts regarding the direction or prioritization of a project, the buck stops with this person. For some projects, there may be multiple decision makers for technical issues or cross-project prioritization. You are responsible for ensuring you have all of the relevant information to make a considered decision. Make sure you are updated on the progress of the project and any potential conflicts. If you don’t have enough information to make a specific decision, then be vocal and ask as many questions as necessary to make the call quickly.

Define the Escalation Process

This could have been included in the section above, but to me, escalation is such a critical component of managing a major project that it deserves to be called out separately. While you’re defining the key decision makers in the initial meetings referenced above, you might as well define the escalation process, including details about what’s worthy of escalation and what isn’t, the method for escalating an issue, where the buck stops, and how to communicate that an issue has been escalated. For example, depending on your culture, it might not be acceptable to notify the entire project team if one person’s deliverable slips. A portion of this information could (should?) be defined at an org or even company level. Then all you have to do is play fill-in-the-blank with the owners for your specific project.

Defining this up front encourages people to communicate in the most sensible and productive way from the beginning, teaches participants to have open, frank conversations to try to work out issues on their own (no one likes being escalated on), and it saves the ‘punch’ of escalating for things that are legitimately critical. As a manager, there are few things worse than realizing that you’ve missed a critical escalation because it’s gotten lost in the noise of a million other unimportant pings.


Stakeholder Updates

Each audience involved in a project requires different types and amounts of communication. I honestly didn’t understand this until I became a manager of managers and had multiple teams and projects to keep track of. As an engineer, I wanted to drink from the proverbial fire hose and have access to every tidbit of information possible. Nowadays, I manage four teams spread across approximately 15 projects at any given time. On average, I have somewhere between 10 and 15 minutes to devote to any one project per day.

Project Team Communication

The most valuable information project team members receive are updated project plans, progress against blockers they’ve raised, any changes to project scope, and changes to project timelines. I’m a fan of the daily scrum, where the team can all get on the same page in 15 minutes or less. It’s efficient when customized to your particular organization. Notes should be sent out after each meeting; simple bullet points should be sufficient.

Executive Summaries

There’s a difference between Executive Summaries and communication meant for a technical project team. If I’m asked to read and sift through a 3-page treatise in order to find the one embedded action item meant for myself or my team, it’s useless and a waste of my time. To boil it down, this is what I would expect:

  1. Is the project red/yellow/green based on the current milestone? If I see green, I need to be able to trust that things are on track and I can safely file it away.
  2. If the project is in jeopardy, what is the bulleted list of the blockers, who owns them, what the ECD (estimated completion date) is and what I actually need to worry about. I don’t want to see more than two sentences for any one bullet point. Do I need to find another resource? Do I need to step in and help guide things along?
  3. Did we complete a major milestone on time? Did one of my team members go above and beyond to improve the design, help the project team, etc?

General Status Reports

Include positives like hitting milestones. Make the communication clear enough and at the right technical level for the least-technical stakeholder who honestly needs to understand what’s going on with the project. C-level people and managers in organizations not involved in the project might be in that group (it all depends on your own org though, of course).

Basic Ops Questionnaire

It’s always a good idea to make it as simple as possible for PMs or developers to provide the right ops-related information for an internally- or externally-driven project. If you don’t have a formal NPI (new project initiative) process where these questions are codified, a simple document should suffice. We’ve begun using a google form open to anyone within the company for these types of requests. Some of the questions we expect answers for include

  • What is the request? X customer would like us to host a few customer service tools in our data centre. We would like to extend Y service to serve global requests, rather than serving requests from just Z service.
  • Who are the main technical and project contacts?
  • Who will be administering the service? If said service is ‘hosted’ rather than an internal one.
  • Will you need authentication for your administrators?
  • Does any data need to be stored locally on the machines? If so, what types?
  • Is there an admin UI or set of management scripts to administer the app? Or just backend processing?
  • Is this a mission critical service? Do you require notification during scheduled/unscheduled events?
  • How will the service be monitored?
  • Do you need server/network redundancy? Honestly, I can’t imagine ever putting something into production that isn’t redundant, but some people just don’t want to pay for it!
  • Are there any specialized hardware requirements for computation, storage, etc?
  • Do you have capacity numbers through the next 12 months? If not, when do you expect to have them?
  • Is integration with other services internal or external to our infrastructure required?
  • What security considerations or concerns do you have, if any?
  • How will you handle code deployments?
  • How will you handle packaging?
  • When do you need the environment(s) in place?
  • Are you prepared to furnish operational run books?

This is by no means an exhaustive list, but it helps drive the proper conversations from the beginning, and it also helps Ops management determine which resources to devote to a particular project.

Happy Dance! It’s Performance Review Time!!

I love performance review time. People assume I’m crazy when I say that. Oftentimes, as an Individual Contributor (IC), it’s the one time each year when there’s a focus on what you’ve accomplished over the past year. As a manager, it’s incredibly satisfying to look back and realize just how much your team has delivered.

I completely understand that reviews can be stressful. Typically, I get that knot in my stomach when I don’t exactly know where I stand in terms of my performance. Some people freak out because they aren’t being objective about a flaw and don’t see it as an opportunity for improvement. The combination of those can lead to people assuming they won’t receive a raise, they’ll be demoted, maybe even lose their job. It’s a dangerous and unproductive way to approach something so potentially charged as a performance review.

There are many different ways to lighten the emotional and intellectual load of reviews. Just search for how to write a performance appraisal online and you’ll get so much information back that it’s overwhelming. I stick to a few simple things that don’t require much effort but allow me to really enjoy this time of year.

Prepare All Year

Ongoing preparation makes filling out a performance review so much simpler and less stressful. Otherwise, it’s like cramming for an exam in school, except the stakes are your career progression.

  • Keep a record of what you’ve accomplished. I use a ‘fuzzy folder’ in email, both for myself and for my directs, containing highlights (delivering a project or taking a leadership role in some way) as well as constructive feedback and instances where I or my directs have had… challenges. It gives me a balanced retrospective of performance and it makes it much easier to identify and write feedback on significant events from the past year.
  • Insist on goals. Ideally, IC goals will be built around the goals and values of the company and the organization. But even if those aren’t available or well-defined, it’s possible to create meaningful S.M.A.R.T. goals around making your environment better, saving the company money, growing your skill sets or many other categories. As a manager, identify these categories for the IC and have them create their goals so they have more ownership in the successful completion of them. As an IC, gain your manager’s support for the goals you’ve created and then revisit them frequently so you can make sure your performance stays on track.
  • Use your 1:1s wisely. Whether you’re a manager or an IC, use regular 1:1s throughout the year to ensure that there are no surprises during the discussion portion of the review. I use a regular 1:1 doc so I have a record of the discussions throughout the year, and so I can remember my deliverables. My directs are responsible for filling them out and sending them to me the day before our meeting so I have time to come prepared to make it as beneficial a discussion as possible. It really does help- especially if your 1:1s are infrequent.

Providing Written Feedback on Yourself

  • Be as objective and balanced as possible. Remember that no one is perfect, and include both strengths and areas for improvement, even if it isn’t requested. Your manager ought to be gathering feedback from your partners, customers and peers, not all of whom will have purely positive things to say. It’s a pretty uncomfortable discussion when an IC’s review is completely glowing; everyone has blind spots or holes they need to fill. Your forward-looking goals and development plan also won’t support and drive your growth as much as it should if your ego gets in the way.
  • Don’t short-change yourself. Providing balanced feedback also means that you should cover the positive aspects of your year. Major deliverables, times when you showed leadership, went above-and-beyond… they should all make it into your review. I strive for a 60/40 split between positive and constructive points, both when I’m reviewing myself and my directs. It’s always nice to look back at your review and read about what you’ve done right every now and again.
  • Be quantitative in support of subjective topics. Any time you address a ‘soft’ skill (communication, organization, etc), make sure you include examples in support of your claims. Metrics are the best (can’t argue with numbers!), but if that’s not possible it’s still better to give slightly anecdotal evidence that can at least be followed up on.
  • Take your time. Provide as much feedback about your performance as you feel necessary. You’re selling yourself through your review, and the amount of time and thought you put into it directly reflects on the ownership you have in your career. Or at least that’s how I feel about it. 🙂 Even with the ongoing preparation above, I typically spend about 6 hours writing my self review- about an hour per page.
  • Stay focused. Agree on the message you would like to convey in each paragraph, section, etc. and then stick to it. It makes it easier to give feedback as a manager, and it helps guide the discussion of the review itself.

Providing Written Feedback on Your Directs

  • Avoid matching length. As a manager, receiving a self review that’s just a few sentences long is depressing. We all want our people to show that they’re invested in their careers, of course. If an IC submits a short review, take the opportunity to set an example by providing more feedback. If you have the opportunity, pass the review back to the person and ask them to put a bit more thought into it and re-submit it.
  • Avoid matching tone. Be objective to ward off being emotional in reviews. Most people invest a lot of themselves into their careers, and people who have had a challenging year can become fairly defensive, or even offensive. Keep the tone of your responses consistent and non-confrontational so you can focus on improvement. Use facts and anonymous quotes from peer and customer feedback to support your message.
  • Minimize the surprises. You should be using regular 1:1s to ensure that there are no surprises come review time. Sometimes, however, you may receive new constructive feedback from someone from out of the blue. If that’s the case, make sure you state that in your write-up so that it’s on record.
  • Be firm and direct. Make decisive statements, and stand behind your them. As a manager, you’re responsible for making decisions every day, and your credibility hinges on not being wishy-washy. Treat performance reviews the same way you treat the rest of your job. If you have the proper supporting feedback, this should be fairly easy. (also, see below, “Avoid mixed messages”)
  • Solicit balanced feedback. Choose peers/partners who will give a well-rounded view of the IC. Managers don’t see everything that goes on day-to-day, and supporting evidence from external parties helps round out feedback. Even short five-minute ‘interviews’ with people around the office are a great way to gather this input. Just be sure to send your write-up to the interviewee for approval prior to using an anonymous version in a review.

Discussing the Review

First off, I hate it when managers approach this as “delivering” a review. It automatically puts the manager in the driver’s seat and doesn’t breed collaboration or offer the IC the opportunity to own their own career. Running through a performance review ought to be a discussion. The points below apply to both ICs and managers and can promote a dialogue, rather than one person’s stream of consciousness.

  • Be open-minded. Be open to admitting you may have missed something and to changing your mind. You should still be prepared to ‘agree to disagree’ on one or two points, but make sure that you’re really listening during the conversation and that you’re being objective about the issue before accepting an impasse.
  • Be rational. Take your time and think before you speak. Don’t let the discussion devolve into an emotional match. Feel free to just say, “I feel like this is getting rather [defensive/heated/etc]. Do you mind if we come back to this part once we’ve both had time to cool down and consider it?” Just make sure that you take the time to revisit the discussion, rather than leaving it unresolved.
  • Discuss the facts. Focus on actual events whenever possible. This goes hand-in-hand with being rational. There are times when this isn’t feasible, such as reviewing 3rd-party constructive feedback or evaluating performance around the softer skills (“plays well with others”). If you can isolate those instances that could be touchy, the chat will be much less stressful. Supporting evidence for those discussions will help attenuate the situation too.
  • Avoid mixed messages. It’s a common management failing to deliver criticism wrapped in happy thoughts. We’ve all done it. As a manager, concentrate on delivering constructive feedback in a straightforward manner so everyone is on the same page. Avoid the ol’ “You’re doing great! You could really improve your communication skills, but you’ve definitely delivered some great stuff.” Either as an IC or a manager, ask clarifying questions if you’re unsure about the message being conveyed so you can reach a common understanding.
  • Allow time to digest the feedback. Just as a manager expects an IC’s review to be submitted well before the 1:1 discussion, an IC should expect to have some time to view and digest their manager’s feedback prior to accepting it. If you run into contentious places during the discussion, it may make sense to schedule another follow-up conversation a day or two later just to ensure that both people are ready to move on and focus on the year ahead. If you’re an IC, you should request this if it’s not volunteered and you feel that it’s warranted.