Dir. of Trust and Safety, or: How I Learned to Stop Worrying and Let my Team Do Their Job
Tweet this link on Twitter if you want others to read it.
When I started working at Twitter in October of 2008, my assigned territory resembled nothing so much as the proverbial Wild West of the olden days -- lawless, sprawling, and full of tumbleweeds. As the only person at Twitter solely focused on the problem of spam, I had free rein to develop policies as I saw fit. Over the next two years, my areas of responsibility expanded to include policy creation and enforcement, legal support, and API policy creation and enforcement. Along with these expanding responsibilities came an expansion in staff -- what was once just me became me plus 17 others plus a four-person engineering team dedicated to Trust and Safety’s needs. While this expansion was hugely necessary and greatly anticipated, the hiring of these smart, talented, immensely capable team members was also a little terrifying for a control freak like me, particularly in light of the many months I spent doing all the work and dealing with all the problems by myself.
Even though I was filled with a mild sort of panic over these other people doing my job, I had every intention of being the very best manager possible. My spam team was increasingly capable of handling all of the tickets filed and determining the sorts of algorithmic adjustments needed to make our reports function at maximum efficiency; as a result, I started forcing myself to be more hands-off and instead making myself available to talk about side projects, proposed over-arching system changes, and needed changes in staffing and resource levels. Still, I more than once fell prey to the easiest trap of all: you see a problem that the team is wrestling with, you know the solution that worked last time, you tell them the solution, the problem is “fixed,” and you walk away with a sense of pride and achievement, having helped your team through a tough problem that could have taken them much longer to figure out and fix on their own.
There are a few things wrong with the above scenario. First, stepping in to solve a problem without waiting for your input to be solicited indicates to your team that a) you have a lack of faith in your team’s ability to solve the issue without your assistance and b) you don’t trust your team to come to you with questions they might have. Second, it reeks of micromanagement. Third, in a worst-case scenario, it can promote an attitude within the team that the real ownership for problems belongs to you, not to them, and that they do not really need to think up solutions themselves since you’ll swoop in and save the proverbial day. Not only does this approach not scale, it also hamstrings your team’s ability to grow and gain confidence in their own judgment. If, instead, you make yourself available to your team to give advice and/or insight when it is solicited, your team is more likely to feel confident in their choices and, as a bonus, consult you more for a final sign-off on a proposed solution rather than the quagmire-filled first steps through an old problem.
I took these truths I learned from dealing with the growth of my spam team and applied them to my other divisions and, in the process, had a few more (to me) revelations. The first of these is simply this: the people who do the work should write the policies about how the work they do should be done. By getting involved in the development of these policies, I was once more unwittingly hindering my team more than I was helping them. Due to the nature of my role as the director of the department, any suggestions I made about how something might/could/should be done carried unfair weight and had the possibility of putting a premature end to a team-centered discussion that in the long run might have come up with a better solution. Changing my role here to once more be the person who gives feedback when it’s solicited and signs off on the final draft led again to a team more comfortable in their roles and their judgment calls, as well as underscoring my faith in them.
The second revelation was that the more power you give people over determining how their days at work are spent, the happier they are. This can’t be half-hearted, though -- you have to genuinely believe that your employees are not only capable but also dedicated and that they are doing this job because this is the job that they want to do. Platitudes here will result in this whole system failing. If, though, you can say to your team, “We agree that these are the things that must be done. How they are done will be up to you. If you do them and find yourself with free time, find other things to do that will make your work easier for you or more enjoyable for you and then do them” -- if you can say this and mean it and have faith that they will follow through -- then your staff is going to feel more valued and trusted. Employees empowered to make judgment calls about how their time is spent and what extra projects they take on are more likely to be happier and care more about the work they’re doing. You want your employees to be as invested in the work that they are doing as you are in the work that you are doing; and if either of these investments is lacking, that’s a sign of a much larger problem.
My final revelation was one that seems naive but has thus far stood me in good stead -- work should be as fun as possible; teams should be as cohesive as they want to be; and worrying about the “little things” -- what time someone arrives at or leaves work, if people are chatting online with friends or browsing a website -- is one of the fastest ways to destroy a perfectly good team. I’m lucky enough to have a remarkable team, mind you, and I’m sure not every manager is in as enviable a position. However, it always seems strange to me when I see people working closely together but lacking any sense of camaraderie. Whatever “this” is, from organization to organization and from team to team, you’re in “this” together, so why not share stories, successes, failures, irritants, and amusements? Likewise, when you have a team clearly invested in doing a good job, leave them alone. Don’t nag about things not being done the way you would do them unless you have (non-anecdotal) evidence as to why a given way is bad or won’t work. Be there when you’re needed, be available when you’re sought out, and otherwise put your trust in your team and -- at least in my experience -- they’ll put their trust in you.
titsay
annaxmalina
yousharknotpass
dailybridgerton
izzy806
gummygunk
tangentwithtanner
pixelskylines