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.


what I’ve learned about “women in tech” this week

The past few days have reaffirmed my decision to stay in this weird cocoon of a world, even after saying, “this is my last tech job” more than a few times since moving back to the bay area. I published a post about “Women in Tech” for the very selfish reason of getting it off my chest to make myself feel better. It worked, and with a very unintended but amazing side benefit: people want to talk about it. Not about how I personally feel, either (thank god. how awkward would that be!). They all want to discuss actual issues and potential solutions. Incredibly unexpected and inspiring.

The main lesson I’ve learned is that I know less about this whole effort than I thought I did. But I’ve gained some valuable insight just by engaging in the discussion & am looking forward to more of the same. In a [very large] nutshell:

Men want to – and should – be involved

I’ve heard from men who didn’t know they were welcome at “womeng” events, who admitted their own guilt at letting others’ bad behavior go unchecked, and who wanted to get involved for a variety of reasons. What’s surprised me most is that the discussions I’ve had with those men have been, on the whole, more productive, more inspiring, and more actionable than those I’ve had with women in the past. It’s helped me connect with people and ideas that have re-shaped my own opinions. It’s also shown me that women aren’t the only people who are thinking about it.

I’ve always been uncomfortable with this women-in-tech issue being labeled as a “female thing”, but struggled to explain why. I suspect most people understand deep down that the behavioral issues I covered in my post affect the community at large, not just women. I’m by no means saying that gender bias doesn’t exist; there are plenty of studies that prove it does. But the interrupting, condescension, taking credit for others’ ideas, etc. affect men in our industry too. Some exclusionary discussions I hear fairly frequently:

  • Men’s behavior toward women needs to change. A few men have approached me to make sure I understand that they, too, are fed up with these same behaviors. Maybe it’s time to stop making this about women and start making this about getting rid of the assholes.
  • Women don’t flock to engineering/ops roles because they want to have families, and being oncall is really tough. Yikes. I work fairly closely with three new fathers, and ALL of them are offended by that type of blanket statement.
  • It’s up to women to drive this effort, because most men just aren’t interested in helping. My recent experience leads me to claim ‘hogwash’ on that.

We’ve unintentionally narrowed the audience by the way we talk about these challenges. Even topics outside of the behavioral issues – pay and career progression, for instance – could use more varying perspectives to generate new & novel ideas about how to combat them. Outside of the past few days, I haven’t heard much from my male counterparts, and even less from male managers.

The ‘company’ needs to play a larger role

Most tech companies live & die by hiring referrals. (this is a good short read of that in action at a company that surely can’t be evil) If a jerk starts the hiring effort and that train leaves the station filled with like-minded people, it’s nigh impossible to get them to disembark so the company can start the journey all over again. The companies I’ve worked in with the worst behavioral issues are those where hiring for technical acumen trumps culture fit almost every time. If an engineer (or manager) is technically strong, they’ll get an offer. It’s only the mediocre candidate who’s culled out of the pipeline if they have soft skills issues. In my current role, I haven’t come across a single jerk, and I attribute that to the importance we place on hiring people who play well with others. Another “todo”: figure out how Dropbox managed this & whether we can codify and share that much more widely than we do now. #competitiveadvantagebedamned

It’s up to managers and leaders across the company to ‘model the way’. I’ve yet to work in a place that makes in-depth diversity training for management compulsory. Amazon’s management training was great back in the day, and Twitter’s TC5 is a fabulous all-around program today. Taking it a step farther and creating meaningful content with brains-on participation would surely help managers both attract and lead more diverse teams, and in a more authentic way. A pass/fail mechanism with actual accountability wouldn’t hurt either. We’re so scared of holding people accountable that we don’t even use the word without apologizing. That’s sad and unfortunate.

The cool kids are the majority

The bulk of people I’ve worked with have treated me with the same level of respect that they have for the men around me. I lay awake last night thinking, perhaps this is just a “few bad apples” scenario and we’re making this more difficult than it needs to be. Maybe we already have critical mass, and it just needs to be directed better. Okay, it takes more than “just a few” people to create such a large-scale outpouring of consternation and gnashing of teeth. But when I think of all the amazing people – men and women – I’ve had discussions with this week, and the incredible people I’ve worked with in my career, this whole problem makes less sense. The assholes in our industry have got to be outnumbered, right? Why do we put up with it then? Is it the role & level that those jerks in the minority hold that makes this so difficult and pervasive? That there aren’t consequences to being a jerk to the people around them? I just don’t get it, and it seems like understanding that piece is one of the first steps toward fixing this ailment.

Other stuff I’ve learned

  • I’m a part of & represent a community, whether I participate in or cultivate it or not.
  • I don’t know much about “diversity” outside of women in technology.
  • Just participating in these discussions, let alone doing something about them, requires a lot of time, energy and dedication.
  • I don’t know what to call this Women in Tech “thing”, which makes it awkward to talk about at length (I’ve said the words effort, initiative and thing approximately a billion times this week).
  • Solid “why” and “how” data behind these issues is just too difficult to find, assuming that it even exists. But there’s a lot of anecdotal evidence. This makes me sad, given the data-driven environment we all work in.
  • Companies really want people to believe they’re role models for the diversity effort and will go to great lengths to preserve that, regardless of whether it’s the truth.

I’m so fortunate to have been a part of the conversations I’ve had with people from different locales and industries this week. I’ve realized that it does indeed ‘take a village’ and that there are many more people in the world who are interested in making a difference. A huge weight is lifted once you realize you’re not alone/stupid/wrong.


An apology for being a wuss to my friends in tech

This post about women in tech has been sitting in my drafts, not even close to half-finished, for more than three years. It’s one of the many reasons I have an overwhelming feeling I’ve failed the tech community (admittedly in a small way) through my own lack of initiative, and that stinks.

I’ve missed innumerable opportunities to help change the prevailing “bad behavior” regarding women in technology in our community. Every time a woman (or I) complained about a man “stealing” an idea and getting the credit, every time I’ve been interrupted in a conversation and didn’t say anything, every person I should have coached on soft skills and didn’t. They’re all missed opportunities for improving the situation for women in tech that I passed up. As a manager and someone who loves this industry, I should feel ashamed.

So yeah- I’m not proud of the way I shirked my duty, and I’m sorry. But I want the generation behind me to know how I fucked up so they can do more for the community than I have so far… and without spending half their career learning the same lessons first.

Why I’m finally publishing this

Aside from just running out of patience, a couple of experiences I’ve had in the past week are so very indicative of what I believe to be core challenges in making measurable progress in this effort. I think it’s worth writing about.

“womeng” programs

I worked at Twitter – a company that values diversity and has a great women in engineering program – for two years (they also have a solid program for all women at the company). I wasn’t active in that community for various excuses. But Dropbox is just starting up a womeng group of their own, and I attended an initial session last week out of a sense of duty.

Here’s the thing about these efforts. Just like voluntary training for managers, the people who are already interested in supporting “the cause”, male or female, are already involved. 30 women attended that initial meeting last week. There were zero men. Zero! That’s a pretty insulated way to approach something as huge as changing the culture of such a male-dominated industry. I’m not saying that there aren’t men at the company who care and would participate- I know there are, and I would love to see them there. But they’re not the Target Audience for these efforts.

Men do participate in Twitter’s group, but the same applies. The men (and a couple of women, let’s be honest) who struggle with treating women with the same level of respect as men are not the ones who engage in those discussions in a meaningful way. Most of these people feel like their behavior is appropriate and that discussions about women in technology don’t apply to them. Want to make a womeng group really effective? Make discussion and training tailored to your workplace mandatory for everyone in the company, starting with the managers. There are many creative people out there who could pull this off without it being inflammatory or, on the other side of the spectrum, boring as hell.

I owe a specific 100-ish people an apology

I was a member of a panel (2 women, 2 men) about building SRE teams at a conference last week. Some brave soul asked something like, “The ratio of men to women in SWE functions seems to be improving, but SRE is still lagging behind. Why do you think that is? What can we do about it?”.

Bless your heart, whoever you are. Thank you for asking those questions.

Both myself and the other woman on the panel gave some honest, but kind of well-rehearsed answers, and then a strange thing happened: one of the men answered too! Unfortunately, his response only strengthened the opinion that men don’t understand the fundamental issues. But to those people who said afterward, “he should have just kept his mouth shut. lololol.”, I disagree. I guarantee his remarks not only offended the women in the audience (of which there were few), but many of the men as well. It sparked more conversation than anything else from that panel, and I say it’s a great thing it happened.

What I need to apologize for is not immediately correcting the panelist, who I believe in his heart of hearts was trying to help. I just sat there, too shocked to say anything. Hours later, I realized that that situation was the best illustration of the problem that we could have ever hoped to have. And I failed everyone in that room by not having the guts and confidence to point it out and to continue the conversation right then and there. It’s a very typical scenario for many women in our field.

Plain old guilt

I’m seriously disappointed in myself. For keeping my trap shut instead of defending myself. For letting my career suffer because I was too intimidated. For not doing more to pave the way for women who are just starting out in this field. For being too lazy with my time & energy to deliver tough messages to people who actually needed to hear it. That’s a lot of guilt to carry around, so I’m writing this in the hopes of preventing that experience for at least one woman entering the technical world. Because it sucks.

How I’m going to step up

During at least 80% of my evening commutes, I’m kicking myself about one or more of these. This is the advice I wish I could have given the ‘me’ of 15 years ago and what I should have been telling everyone during my career. But since time travel is still a couple of years away (!), I’ll have to settle for “being the change I want to see” now.


Whether you’re a man or a woman, get involved in the discussion. We all want this issue to be a thing of the past, and the only way that’ll happen is if things actually change. If your company has a diversity program, participate. If it doesn’t, there are discussions happening on social media and in meet-ups across the country. Give it a chance before you dismiss it as “not applicable”. The issues apply to and affect everyone in our industry. Spending an hour a month is a small price to pay for fixing what ails us.

Don’t make excuses for yourself or for others

It’s okay to be disappointed in yourself or in someone else. Just don’t make excuses. I catch myself doing this a few times a day:

    “Oh, he means well- he probably doesn’t realize he just took credit for my idea. Again.”

    “He was just so excited he probably didn’t realize that he interrupted me in mid-sentence to explain my idea for me.”

    “He was so nervous about his presentation that he probably didn’t realize he addressed all of his comments to the men in the room and didn’t interact with a single woman.”

Sound familiar? Yep. I’ve done myself and everyone else in the organization a disservice by keeping these thoughts to myself. The majority of people will become defensive, even if you’re a master at providing constructive feedback. But those people will never realize what’s going on if no one reveals the blind spot. And you never know how much fruit you can reap down the road by planting one or two seeds. Don’t wuss out.

Speak up for yourself

Muster up the confidence to defend your position, idea, self. The more often you do it, the more lessons you learn about communicating, about people and about yourself. Communicating thoughts & feelings isn’t exactly the forté of the tech world, nor is listening to and accepting someone else’s position. If you’re uncomfortable, ask someone who has background with the organization and whom you trust for advice. It’s a fine line, and there are risks to voicing your opinion. But those should be acceptable risks. If it turns out to hurt your career, you should really consider whether the organization is right for you.

Don’t take it personally

There’s a lot of insecurity in our industry. That can breed misplaced aggression, taking credit for someone else’s work, being the loudest in the room, and many of the behaviors mentioned in this post. Getting defensive or taking it personally when it happens to you won’t improve matters, trust me. Do whatever you need to do to distance your personal stake from the situation – take 10 deep breaths, yell into a pillow, whatever. Just do it quickly, and provide timely feedback.

Thanks for reading all the way to the end. If I work with you & you see me not doing any of the things above, kick me. Or maybe just send me an IM to call me out. I need the help. 🙂

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!

My title is Enabler

Wanna play ’20 Questions’? 

What if we changed the typical titles in the tech world?

What if instead of a people manager, you were called an Enabler? Because isn’t that what we’re supposed to be doing here? Enabling our people to be as productive, happy and successful as possible? That still encompasses everything we’re asked to do, from project planning & management to removing road blocks to career planning.

What if every engineer was instead called a Leader? “Site Reliability Leader” has a really nice ring to it. Would that make engineers feel more invested in their role in the team and the company? Would it serve as a daily reminder that as they rise up the ranks, they’re expected to lead other people through mentoring and shaping technical direction? Would they feel more empowered to own their space? Or would it be laughed off in typical neckbeard fashion as PHB speak?

What if a Director suddenly became an Facilitator? What if instead of an Architect, you were a Trailblazer? (I hate the title “architect” and think it should be abolished regardless, but that’s a different story.)

Would this make any difference in the way we perceive our roles in tech? The way we’re measured in that role? Would it change our behavior? The direction, velocity and/or performance of the tech sector in general? And if so, how long would it take for those changes to really take root? What would this DO to the type-A personalities and egoists who typically overwhelm the tech ranks? What effect would a simple title change have on the number of successful women in technology? Would the male-dominated tech industry even be able to make the jump? Or would they just scoff at it as a touchy-feely attempt at ‘feminizing’ their sector?  (serious question is serious.)

Just something I’ve been marinating on as an alternative to those who recommend just doing away with titles altogether. I actually don’t mind them- as long as folks aren’t boxed in by them. If I ever have an opportunity to be “in on the ground level” of a company that has legs….

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.

Trust & Delegation of Decision Making

I recently read a blog post by Josh Patrick about passive ownership, which I interpreted as “learn how to trust others to make strong decisions at the right level in your organization”. I agree with everything in the article, but I left myself wondering, how does this look on a tactical level?

I learned the fine art of delegation at Amazon, where I was lucky enough to have a team of trustworthy and knowledgeable leaders reporting to me (most of whom I hired). That made it easier for me to back away and focus on longer-term, broader issues. My managers had more control over their teams, were more invested in the solutions and understood better how to set the same example for their own directs. Those types of virtuous cycles consistently make your team stronger, more active and more comfortable with suggesting and taking calculated risks. I was also fortunate enough to report to an executive who trusted me to make the right level of decisions, and who understood that I could and should own the journey toward hitting our goals.

Mr. Patrick is correct, however, in that it takes mature employees and systems as well as a clear vision and direction to make the jump without endangering the business. Your structure doesn’t have to be perfect in order to start delegating and trusting, however. It’s never too early to begin coaching your directs and showing that you care about organizational trust and growing your employees.

Identify the Correct Decision-Making Level

The goal of the effort should be to let the people who have the relevant amount of information make the right types of judgements. Treat this like a project, complete with scoping exercises, milestones and stakeholders. Create “decision buckets”: categories of decisions you believe you are and aren’t the best person to make. It’s tough to create guidelines, but a basic way to frame the exercise might be:

* If you’re an Engineer: Trust people more junior than yourself or with more expertise than yourself. Chances are, the more senior you become, the more specialized you become as well. That means you’re not qualified to make or even necessarily give input on, every decision in the company.
* Front-line manager: You’re probably slowly (or quickly) moving away from the day-to-day responsibilities of your team. At some point, you won’t have the expertise to decide on the proper way to write a puppet policy or write a tool to manage LB configs. And unless you were hired for & are expected to be a hands-on manager, you shouldn’t be required to have that knowledge. Delegate!
* Senior manager/Exec: You most likely haven’t been on call or hands-on for a few years. There’s very little possibility that you are the correct person to make decisions on technical implementation details. Don’t make it your “hobby”. Your job is to ensure that any requirements or goals are well-defined (and not by you unless you are the primary customer), and that the teams have the right resources to hit those goals.

Guard against over-rotating, and be prepared to explain why you believe some decisions ought to remain with you. For instance, I’m not planning on attempting consensus across my entire organization about career levelling definitions. My managers own the inputs and I own the review. I don’t expect or want our engineers to spend their valuable time grok’ing headcount planning in fine-grained detail. If they did, they’d be managers.

Solicit Constructive Feedback

Once you’ve recognized the need to back away, show the people around you that you’re committed to making the effort to delegate the right level of decisions appropriately. Review your “decision buckets” with a mentor and folks who are familiar with your organization to evaluate your perspective versus those of others in the org. Ask these people for feedback on where you need the most help, and listen to them. Getting defensive at this stage is a sure-fire way to make this process more combative and longer than it could otherwise be. It’s best to do this as early as possible in your soul searching. You may find that you have blind spots that have secretly impacted the well-being of your organization or your business for eons.

Now that you have a solid idea of what you’re trying to accomplish, schedule time with the target decision-maker(s) to review your current approach and your expectations, and to gather feedback from each person on their own decision-making processes to make sure your methods are aligned.

Continually Evaluate Your Involvement

Each time you make a decision, be self-aware enough to ask, “am I the correct person in the team, organization and company to make this call?” Then be honest enough with yourself to answer “no” when warranted, accept it, and do something about it. Sometimes you’re forced to make the decision anyway (people go on holiday, it’s too time-sensitive to wait for the proper person, etc), but recognize that those are one-off decisions, and do what you can to remove the possibility of it happening again in the future.

If you’re not the correct person, then include that engineer or manager in the discussion and allow them to make the call. Walk through the decision-making process with them until you’re comfortable with blind delegation, but realize that it doesn’t have to be done your way, as long as all of the requirements are met and the business goals are achieved.

Back Away Slowly

There’s no requirement for going “whole hog” on this exercise. Not only do you need to re-train yourself, but you also need to get your delegates used to the idea that they hold the keys to the kingdom in certain circumstances. Take time to do the following:

* Work with others on decision-making. (aka “teach a man to fish”) Have other people shadow you to make sure they own the right competencies to make the decisions. Continually recognize that even if the person doesn’t make the same decision you would make, it doesn’t mean that it’s the wrong one.
* Continuously revisit and modify your list of “decision buckets” to make sure you’re staying on track with growing your career and the careers of others around you.
* Recognize that you’ll go through withdrawals. Backing away slowly will allow you to take steps to avoid regressing at the slightest hint of churn or what you may believe is a bad decision on someone else’s part.

You need to show progress though, so don’t go too slowly. Since you’ve mapped out your plan, everyone should have the same expectation about the new world order. Just follow the plan. Make it a part of your own career goals and development, and review it in your own 1:1 with your manager.

Don’t Punish the Decision Maker

Sure, if someone makes a rash decision without due consideration, then they should be chastised. But if someone is diligent about gathering the proper information and has a rational argument to stand behind their decision, then practice some empathy. Would you have made a better decision if you were in their shoes? Should the decision have been delegated to them in the first place? Did the person seek and receive the right amount of coaching to make the right determination? You must allow someone to make small mistakes and learn from them. Only step in when the gravity of the decision and the risk to the business warrants it.

Fill Your Time With What You Should Be Doing

Regardless of whether you’re a front-line manager or a CEO, there’s a responsibility for growth & vision that needs to be filled by you. Instead of agonizing over everyone else’s decisions, fill the void with the roles and responsibilities that are commensurate with your position in the company. Work with your manager or mentor to figure out a plan for doing this if you’re unable to do that yourself.