Abstract: Managing projects is one thing, but managing people is another. Whether we’re hired as managers or grow “organically” into management roles, sometimes technical people end up leading technical teams (gasp!). I’ll talk about lessons I’ve learned about hiring, retaining, and working long-term and day-to-day with highly tech-competent humans. I’ll also talk about navigating the politics of libraryland, juggling different types of projects, and working with constrained budgets to make good things and keep talented people engaged.
- introduction
- "soft" skills are hard
- being a human
- recognize that others are humans
- in conclusion
- bye
- references
[slide: introductory slide] Hi folks, I'm Erin White and I am the web systems librarian at Virginia Commonwealth University in Richmond, VA. Today I'm going to talk about being a technical person who becomes a manager of technical people. Or being a human who manages humans.
[slide: didn't sybil just talk about this?] You're probably wondering if I'm going to cover the same stuff as Sybil. Well, we schemed ahead of time to avoid dwelling on similar topics. I am talking a little more about working with yourself and one-on-one with the people you manage. And, I'm talking more about the first few years of management - the takeoff rather than the flight.
[slide: agenda] The gist of my talk today is: "soft" skills are hard, be a human and recognize that others are, too.
[slide: soft skills and hard skills] The Code4Lib schedule this year isn't just about code. I'm happy about that. Our work is about hard skills and soft skills. I'd probably be more comfortable up here talking about an app we developed, but it's also important to talk about this, and I'm glad you thought so, too. I hope that we'll continue to see sessions like this at Code4Libs future, and coming from people who aren't women, too.
So what's the diff?
Hard skills are rule-based. Algorithms, syntax, functions, standards, best practices. With hard skills, you may even at some point have a feeling of mastery, or near-mastery.
Soft skills are human-based. They change. They are contextual, societal, social, personal. Soft skills are really damn hard. And they have just as much impact on our work.
Both types of skill need practice and intentional growth.
[slide: my story] I started my job straight out of library school doing web design and development. When my supervisor left 6 months after I started work, I became the manager of the web team.
The stakes were low - "the web team" was me and a part-time programmer who had been there a long time, knew what he was doing, and understood the environment.
When he left, things got real. I had to recruit, hire, train and retain a new person. I had to set the direction for the team and the web. Though part of me was excited I was Getting Management Experience(TM), I was mostly just terrified.
But over the course of 5 years, a revolving door of hirings for part-time and full-time positions, and some foibles, I can say that I am slightly better at managing people than I was in 2010. Now I manage two full-time employees who have been here for a spell and haven't quit yet, which to me means success. I wouldn't say I'm a fantastic manager, but I've learned a lot.
[slide: management in libraryland] My story is a typical tale of management in libraryland: in general, it's a haphazard process and folks going into management positions can be ill-prepared and inexperienced.
In the kind of environment where you want to spend the little development money you have on conferences like Code4Lib, management training doesn't make the cut (this goes back to the soft skills idea from earlier).
So, newbie managers + very little admin support for training = lots of "room for growth" and nervous humans.
[slide: michael scott] Why the hell do I have a slide about "being a human"? Shouldn't we all be good at this by now?
Well, I won't speak for everybody but I do know that I made a lot of assumptions about how good a boss I'd be before I was a boss. I assumed that being a boss was like being a regular person on a team with some added paperwork. I assumed that because I was good at the things that made me a boss, I'd be a good boss. Those things are not true. Management is a skill you have to work on, and if you don't think that, you are probably going to be a terrible manager.
Also, the power dynamic changes when you are in a formal management position and the rules you follow for "how to be a human person" with others on your team change. You're no longer a friend or an equal or a confidante, nor are you viewed as one. And that's okay. It's just different. The worst way to cope with this is acting like it's not the case or doing things just so you can be liked. This is awkward for everyone.
[slide: lumbergh] Our typical view of managers has been framed by depictions of inept, cubicle-lurking pointy-heads - Dilbert and Office Space come to mind. That view of managers is a depiction of the typical command-based management style: I tell you what to do, you do it without asking questions, you are the cog and I am the genius, grrrrreaaaat. The command-based manager assumes that you naturally are up to no good, that you don't want to work, that you're disengaged. Has anybody ever had a boss who clearly thought like this? Yeah, me too. The wording is blunt, but this is actually how a lot of managers still think and how a lot of people think of managers.
More and more, though, we collectively envision a newer type of manager - the service-based manager who empowers their team and becomes the conduit for that team's work. This manager guides strategic direction, sets goals and lets the team decide how to get there with as little obstruction as possible. This is the ideal situation and one that encourages people to do good work that they can stand behind. This is a great model, and doing this is really hard!
[slide: tinkerers] Part of pursuing this service-based model is recognizing your own assumptions about your team and making sure that they align with where we need to be. Rather than assume the worst, my assumption is that the people on my team are curious, mission-driven tinkerers who want to be here. All assumptions about the work they do and their motivations flow from there.
[slide: your work, lol] Speaking of "the work your team does" - do you know that saying, "your work isn't your work anymore when you're a manager"? It's true. Your work is your team's work. It took me a while to get over the fact that at the end of each day, I hadn't lovingly crafted a thing with my own hands. Despite my sadness I have developed a few rules of thumb:
- Don't roadblock. When possible, take yourself out of the development workflow. Do you really need to code on this project?
- Cross-train your team, document, and delegate. Sybil talked about the benefits of delegation.
- Prioritize: your job is to help your team get their crap done, and anything you're working on comes second.
- Be interruptable: Just prepare for it. If there's a time when you really don't need to be interrupted, close your door or leave the building.
Letting go can be hard, especially if you're really close to your old job responsibilities. This is one I've learned the hard way: when hiring someone new into your old position, make sure you relinquish all of the responsibilities for that position. Communicate your expectations and then let it go. If you're feeling bold, tell that person to tell you when you're being too hands-on. Many people are too nice to do this but just saying it out loud will put pressure on you to mind your dang manners.
[slide: staying current] Though I just said to stay out of the active development workflow, it's important to keep somewhat current on your code stack so you can speak intelligently with your team and ask the right questions about problems we're trying to solve. To do this, I pick small, non-urgent maintenance requests that I can commit and fix. This is also a great way to test documentation. :D :D :D
[slide: welp] Becoming a manager makes you face some truths about yourself as a human. A thing I've learned about myself since I became a manager is that I really fear change. I have a hard time with big new project ideas, or changing up the way things have been done for a long time, or the idea of new technologies...the list really goes on.
In an effort to be mindful about this, I've started to be really aware of whenever I feel fear or defensiveness. In my mind I call it The Clench. I feel it, acknowledge it, give it a minute, rationally evaluate it, and then move on with my life. If it's someone on my team presenting a new idea, I'll say, thank you for the idea, give me a minute to think on it and let's talk about this more next week.
And, because I am predictable in this way, my team knows how to approach new ideas with me.
And I also know now that I need to hire people who are going to scare me, push me a little.
[slide: balance] One thing I talk about a lot lately is balance. We were working on a big project in 2013 and I didn't really take vacation that year. It was terrible. It took a toll on me and strained relationships with my team. I should've taken my damn vacation.
It's important to recharge and separate yourself, you, human person, from your work, no matter what a curious, mission-driven tinkerer you are.
It's a sign of trust in your team that you feel comfortable leaving for a week without chiming in on e-mail every day.
And, by taking vacation (reallllly taking vacation) you signal to your team that it's okay for them to do so, too.
If you're worried that something will come up that really does require your attention, give them your phone number. They won't use it but you'll feel better.
Also, unless you are a library director, you don't need to send a dang e-mail at 10 p.m. on a Wednesday. No 10 p.m. email is a good email. Go home.
[slide: 3 - others] Okay, now that we've talked about some ways to appear to be a human being to yourself and your employees, let's talk about the humans you manage.
[slide: recruiting and hiring] Sybil talked a little bit about hiring in her talk. I won't add a whole lot here.
Most of the people who have come to work on our web team have come over from the private sector because we do mission-driven work and use a semi-modern code stack (seriously).
For many, the appeal of library work is that at the end of the day, maybe, just maybe, you're helping someone. But that isn't going to be enough, on its own, to get people in the door. If we can't match private sector salaries - most of us can't, but we should still try - there are other things we can do to make positions appealing:
- Emphasize non-pay benefits - free tuition? Cheap gym membership? Great health benefits for you and your family? Paid time off and a lot of leave around the holidays? Check, check, check.
- Emphasize that it's only a 40-hour workweek. Sadly, in the U.S., this is a perk.
- Advocate for telecommuting opportunities. Some Code4Libbers work 100% off-site. Even one day a week is a big sell for people and it gives people time to focus uninterrupted on a project.
- Fight for travel funding. Send people to conferences and pay for training.
- Build 10 or 20%-time projects into the job description for employees to choose their own adventure - learn a new technology or work on a project they think would benefit the organization.
- Build learning into the job description. Encourage people to learn on the job rather than at home, after hours.
[slide: keeping people around] So, you've brought someone in, onboarded them, and they are doing it! They are really working. You are excited to have a human on your team. How do you keep that person around?
Relatively soon after someone starts you should have the first Talk.
- How do you want to grow?
- What are you excited about?
- What do you want to learn?
- What do you need?
- What do you want your career to look like?
Rinse and repeat regularly, more frequently than yearly evaluation cycles. This helps you figure out how to support someone's growth and how that can align with future projects.
This may be the several years of hiring only part-time employees talking, but I let people know really early on that, though I'd like you to stay as long as you want, I know you probably won't be here forever. I want us to do what we can to keep you, including trying to match outside offers or flex the job responsibilities to match your goals, but if you just want to move on I will not take it personally. Do good work I'll happily give you a good reference.
[slide: billable hours] One thing that's different about library work is that our coding jobs are not about billable hours (unless all y'all are billing your hours in secret?). Here are some things I define as "work" that are not coding: going out for coffee with your boss, travel to/from another library branch, talking with coworkers in a hallway about a project, attending another department's presentation, reading articles about libraries or technology, experimenting with a new javascript framework, brainstorming ways to solve a design problem while staring off into space.
In libraryland, if what we're doing contributes to the mission of the organization we work for, we are working. That space gives us room to breathe and grow. For people coming from the private sector, this is either a breath of fresh air or a seriously difficult transition.
[slide: types of projects] A lot of us have several projects we're working on at the same time. And in libraryland, some of those projects can be boring or tedious. I've tried to balance out the not-so-exciting projects with cool stuff. On our shared project board we've broken out these projects into "core" and "satellite" projects - thanks to Ben Crowder and Grant Zabriskie at BYU for these terms.
Core projects are mission-critical projects that affect the core services we provide online: either updating the underlying code base for all our web applications or prepping for an upgrade to our 3rd-party discovery system.
Satellite projects are not mission-critical services, but they're projects that excite us and usually the rest of the library, and they let the team flex some technical skills. A recent example of this is an interactive atlas to accompany a digitized collection in ContentDM. The key with satellite projects is keeping the momentum and giving the team agency to finish a project in the best way they deem fit. And often the new technologies introduced in a satellite project are eventually moved into the tech stack for core services.
Balancing core and satellite projects can be difficult, but having a little bit of both at the same time can make a world of difference for morale.
[slide: messing up] Things aren't always puppies and rainbows. Sometimes stuff breaks, somebody makes a mistake, something goes wrong. This happens, and it's fine - nobody is going to die. What's more important is how failure is handled and if you learn from it.
In social psychology there's a term, fundamental attribution error, defined thusly:
"people's tendency to place an undue emphasis on internal characteristics to explain someone else's behavior in a given situation, rather than considering external factors"
This goes back to the idea of tuning our assumptions about our team members and assuming that errors of judgement are due to external, not internal, factors.
At the first Fail4Lib we discussed Etsy's process of blameless postmortems. The assumption there is that people make the best decisions they can based on the info they have at the time. It isn't some malicious intent or fundamental flaw on the employee's part.
It's not about pointing a finger of blame - it's about figuring out what happened, trying to ameliorate it if need be, and doing better next time. Supporting other curious, mission-driven tinkerers.
And get good at acknowledging areas where you screwed up or are roadblocking. Acknowledge, fix it, move on.
[slide: communication II] No shocker, inevitably something goes wrong because of a breakdown in communication.
A manager's biggest job is talking with your team and the rest of the organization. It's really hard to overstate this.
Sybil talked about regular 1-on-1 meetings. Those are so necessary.
And, ask about how people like to work.
- "What's the best way for us to communicate?" and
- "What's your best way to communicate in a team setting?"
I live and die by e-mail. Our designer and developer respond faster to GitHub tickets.
Whatever the situation, make sure to give people enough information to succeed. This is especially important for people coming from outside of libraryland because holy crap, y'all, libraryland is so strange. Our technology is really weird. And, libraries are profoundly interested in helping people, often to the detriment of things like design standards and sensical business rules. It can be very confusing.
- Explain rationale for wanting to talk about changes or new features as design problems - this in turn gives people the opportunity to provide alternate solutions.
- Be honest about your motivations, and any other political factors that give context to a project. In general, I try to be as transparent as possible. There is such thing as TMI, though, and that is when the info I'm conveying is a negative attitude about other people or processes in the organization. This is rarely helpful and always poisons the well. Being kind a jerk signals to your team that it's okay to be a jerk. Be honest but don't be a jerk. As my boss said to me recently, "We're all smart here. Try to be kind." This includes people inside and outside of the room.
- Is there an important constraint? Technically, organizationally? Business rules?
- UX your interaction. Does this person need a piece of documentation they may or may not remember? Mention it, link to it if you can, fwd the old e-mail chain. Don't just expect everyone to remember everything.
- And for shit's sake, be open to different solutions to problems.
So to sum up, being a manager means needing to work on yourself, tune your assumptions about yourself and others, and communicate more than you ever thought necessary. Be open to change and to developing yourself. And, remember that you are not your work, and nor are the people on your team, so don't take it personal. Just keep trying.
Thank you for your time, Code4Lib!
- team culture at angellist - hire lazy people, reward them, let them fail, enforce humility
- how etsy increased diversity
- UX leadership, part 1
- If you want to be in management, don't expect to be liked
- From operator to guide
- How to interview sysadmins
- Blameless postmortems and just culture at Etsy
- Why do you want to lead people?
- How to make the leap from engineer to manager
- User experience management
- Harvard business review: Manage your boss
- MVC: Command management vs service management
- Book: UX Management
- Book: Leading Snowflakes