Managing the First Year
My first managerial role came by surprise.
I had just started as a data scientist at a large consulting firm, and my manager was out for my first week with a sprained ankle. I spent that week getting to know the three other folks on the team, thinking I was the new senior data scientist. I was excited to get my hands dirty.
It was during my second week that I met with my manager and understood that no, I’d been hired to replace her as the team’s manager.
For the next 18 months I stayed in that role, directly managing a team of 4-8 data scientists. That time was a firehose of learning – some were lessons I sought out, and others landed on my head without invitation. I bought many books on management and implemented some of the nuggets I found in those thousands of pages.
But I learned even more from some of the big, stupid mistakes I made – including one that literally interrupted my honeymoon on the beaches of Croatia.
Later, when I joined RStudio, I moved back into an individual contributor role on the Solutions Engineering team. It was around that time I started writing this essay – and I’m now declaring it done, some three years later.
I’m not a management expert, but I did try really hard during my first year managing and I’ve since spent time digesting the experience. My hope is that others will find a few of the things I learned useful when they’re at the start of their own management journey.
Managing the first year
When I first understood that I was to manage the team, I knew it would be very different from doing data science, demanding new kinds of work and new skills of me. But I didn’t know how to do it yet and, to be honest, I didn’t really know what management was.
The next 18 months were an incredible challenge.
As I started, I really didn’t have a clear idea of what management was. I’d had a few good managers over the years – and more bad ones – but didn’t really understand why the good ones had been good and the bad ones bad.
So, I did what I do best — read some books. I read management books, biographies of managers, deep dives on companies that seemed to have figured something great out.
Most of those books were bad (or at least too long by half), but some were good. I developed a reasonably coherent mental model of what managing is.
And yet – I found myself on my honeymoon in Split, Croatia, known for its old-world charm and stunning azure waters. My wife and I were staying in a single-room flat, so humorously small that the bathroom was just a glass-enclosed corner of the room, privacy provided solely by a gauzy purple curtain.
But I was crouched in the dark stairwell listening to voicemails and reading emails.
We had delivered charts to a client during my honeymoon. Charts that included impossible data values, labels that made no sense, and misclassified data points. The mistakes reflected that we, the supposed data experts, had no idea what the data was – much less any cogent interpretation.
Clearly, I had goofed – the person who had created the charts didn’t have the context and knowledge necessary to produce the charts without error.
And then things got worse after I got home and instituted drastic new requirements for everyone’s code to be checked in and reviewed daily. Many on the team chafed under the sudden new requirements and a few weeks after that, I found myself in a number of difficult conversations about how we might lose people on the team, all due to my actions.
But the team recovered. Over the remainder of my time there, the team more than doubled in size, and by the time I left for RStudio, it was a highly functional data and analytics team.
And I loved it.
For some individual contributors, management can seem like an unattractive place to be. An endless flatland of meetings beyond meetings – and none of the creative challenge of IC work. That was not my experience.
While I enjoyed getting things done on my own, it paled in comparison to the joy of watching my team succeed. And I found management to be incredibly creative – dreaming up how to structure our team and our work processes required as much ingenuity as anything I’d done as a data scientist.
So, I hope you’ll get some helpful mental models out of this essay – but even the best mental models are only modest protection against ending up in a dark stairway, listening to the seagulls, wishing you’d never even heard of line plots or line management.
My definition of management
I’ve found management most exciting as a form of leverage. I could only ever type so many lines of code in a day, fit so many models, deploy so many apps. Management was a way to scale myself.
As best I can explain it:
Good management is a flywheel generator — it gives the team clarity and helps them feel safe to experiment and grow, resulting in ever-higher levels of collective performance.
Reading this clever and finely worded definition fills me with the warm glow of a concept well-encapsulated. But let’s be honest, you — reader — are reading in hopes of being a better manager or, maybe even more likely, understanding why your manager is so bad.
If you’re looking to change the circumstances of your management or managing, this definition is maddeningly vague.
When I started in on all those management books, I figured management would be like other things I had done in my professional life. When I wanted to do machine learning, I’d read some books and then used machine learning techniques on some data.
But it turned out management didn’t work like that. It turned out management was a craft.
And like any craft, some theory was helpful, but the hard part was putting that theory into practice.
Management was hard
Unlike data science, where learning more was the answer to a skills gap, my time spent in books didn’t seem to translate directly into being better at my job.
As a manager, I found that it wasn’t knowledge I needed, it was the daily practice of doing the work. And in that, I was constantly bumping up against the limits of my bravery and patience.
When I came back from my honeymoon, I let my ego and my fear of being wrong again get the better of me. I knew that the code and the plots weren’t good enough, and my review could have caught it. I decided that all of the team’s code would be checked into git every night and I would review it.
This was a dumb rule – for many reasons.
The simplest reason it was dumb was that I’d neglected my first role as a manager – to make the team work well. The people on my team were smart, so this mistake wasn’t an issue of intelligence. Instead, I hadn’t shared enough context about these plots so my team could catch the mistakes themselves.
Shortly after this incident got resolved, I adopted the maxim always provide more context. I found that every minute I put into providing context around why the work was the way it was paid back 10x later on. My team was made up of motivated, smart people, so once they had the necessary context, it was easy for them to spot mistakes or find improvements.
For a few weeks after the imposition of my new rules, I found myself in the midst of a howling maelstrom. People were not listening to the new rules, they weren’t doing their work, and they were even threatening to leave for another project.
And I couldn’t figure out why the response had been so extreme. Sure, my rules might be silly, but the response seemed very intense.
It gradually dawned on me that I had touched a live wire. People’s work matters to them. It bumps up against the deepest questions they ask themselves about their value and worthiness.
And in my haste to “fix the problem”, I had infantilized the team. And for my team, mostly recent college grads, the intimation that they still might be children after 16+ years of school was about the worst thing I could do.
Even worse, the new rules were a source of fear. One of the main rules was that code had to be checked into git every night. From my own experience, I knew how hard git is. It is so hard to develop a reliable mental model, and it feels like all the code might go poof with any action.1 And I told my team they had to use it constantly, with no help or guidance from me.
A big component of the problem was me struggling to manage my own fears and insecurities. I watched my team doing fantastic technical work while I perceived the atrophy of my own technical skills. For me, the challenge was avoiding slipping into defensiveness at that thought. To make it all harder – and I’ve read enough to believe this is true of all managers – I got shockingly little feedback on how I was doing.2
Mostly for worse – but some for better – my commute to this job was quite lengthy, and I listened to this episode of the excellent Start Up Podcast in which someone says the line, “organizations magnify the worst traits of their leaders”. I have seen nothing that makes me think this is anything less than 100% true.
My only piece of truly directive advice for any new managers reading this essay:
Go do therapy/counseling.
We all have traits and quirks that are maladaptive in a management role. Therapy won’t fix them, but it certainly helped me be more aware of my tendencies and patterns, more able to step outside and observe them, and (I hope) reduced the likelihood I unwittingly perpetuated them on my team.
Eventually, once I grasped that the main thing I was actually doing was providing context and managing feelings, and things started going much smoother. Instead of walking into work every day thinking through some technical challenge or another, I tried to activate the best of my bravery and patience for the day ahead and I started digging myself out of the hole I’d fallen in with the team.
Management was just a bunch of roles smashed together
Now that you’re bought into the idea that management can’t really be learned from a book or essay, I’m going to go into my mental model of management.
It’s true that a mental model didn’t save me from big mistakes. But it’s also the case that one of my earliest barriers to getting better was not understanding what management was. I didn’t even know what I should be trying to improve.
Hopefully, sharing my mental model can clarify what things you might want to get better at.
Central to my mental model of management is that it isn’t actually a role. Manager is a title applied to a collection of largely distinct roles.
Before I became a manager, I had heard that management is exhausting because of the amount of context switching required. It turned out for me that this was less about having a calendar packed full of meetings with different people on different topics than it was about having to switch the role I was playing from minute to minute.
It felt to me like there were six roles to my job as a manager, from most to least “manager-y”:
As a people manager, I learned what made my direct reports tick, identified their career aspirations, and pointed out opportunities for progress.
As a resource manager, I determined what resources we needed and acquired them. Mostly this meant recruiting, hiring, and onboarding, but it also meant advocating for money for training and team activities.
As a project manager, I collected and triaged projects and project requirements, set timetables and schedules, assigned tasks, and had the final say about when work was “done”.
As the team’s communications manager, I made sure the team’s work was being shared with the rest of the organization, and that everyone on the team knew what was going on outside.
As the process manager, I helped design the team’s processes to make sure we could identify, allot, do, and communicate work across the team.
As a technical mentor and coach, I was an expert who reviewed code, answered technical questions, and gave work feedback to my team.
For the most part, these roles felt pretty distinct from each other, and each of them was a meaningful part of my job.
In fact, in recognition of the fact I was working at a consulting firm where people frequently changed projects, my role was explicitly divided between my role as a people (“career”) manager and a “job lead” who managed a particular project and its resources.
I found that I actually liked this division, as it gave more opportunities to acquire mentors and mentorship. Also, career conversations were truly about career – I wasn’t close enough to the work that status updates made much sense.
My technical skills were relevant in many of these roles – but not in the way I had thought. For the most junior employees, my skills outmatched theirs, and I was able to explicitly teach them technical things. But more senior people on the team quickly matched or exceeded my skills.
The primary relationship between my data science skills and my skills as a data science manager was that my technical skills helped me ask the right questions. Ultimately, my direct reports succeeded and learned more when they were asked questions than when given answers.
Meetings were my main tool
My first, and most obvious, observation about being a manager was that nothing I did was a solo activity. In the work world, any gathering of two or more people is a meeting. Thus, meetings were my main tool as a manager.
The meetings varied widely in both form and content. Many were 1-1 meetings between a direct report and, others were team-wide update or decision-making meetings.
Primal disdain for meetings is pretty common in tech circles. I believe this is a toxic overreaction to cultures where meetings are all that happens or a result of environments (or people) that undervalue the importance of communication. I came to believe that meetings per se were not the problem.
Instead, I came to believe meetings are bad when they:
Result in calendar fragmentation.
Feel useless to attendees.
Preventing calendar fragmentation is a genuinely hard problem. Meetings tend to migrate to places where there are large open blocks of time on people’s calendars. There’s definitely no one-size-fits-all solution, but a focus-time-first orientation to making calendars can help. Aside from that, I found no great solutions here aside from trying to minimize the number of meetings and their size.
There have been so many books written on making meetings (feel) useful. Generally, they present a system or tactic to make meetings (feel) useful. Amazon makes everyone read a memo before they start. Tim Ferris won’t show up if there isn’t an agenda ahead of time. 1-1s are supposed to be “the employee’s meeting” where they come with an agenda and get to do most of the talking.
They’re fine rules.
But I think the focus on tactics often missed the point. Let’s take the example of 1-1 meetings with direct reports, which I found incredibly valuable – even fun!
Up to the point I became a manager, I didn’t have great experiences with 1-1s. Most of my career didn’t feature formal 1-1s, and the one manager who adopted a real 1-1 playbook managed to make them a potent source of toxicity, format notwithstanding.
So, I walked into management really confused about how to do good 1-1s, and deeply skeptical of prescriptive formats.
In the meetings I ran, I found it was important to make clear why we were there and actually focus on that why in the meeting. Sometimes the tactics from books were helpful…but it constantly varied meeting to meeting and I struggled to taxonomize the meetings or tactics.
Keeping the focus on what we were there to do never went wrong.
The one kind of meeting that is always bad is the group brainstorm with more than about four people. Groups that large don’t do good exploratory thinking. Skip them, write a memo ahead of time, and debate options at the meeting.3
My words carried a lot of power
It’s important to be aware of implicit sources of power in a workplace, like identity-based privilege, technical knowledge, and tenure. Despite being pretty comfortable talking about power and privileged in my life, I was surprised by how much power was still embedded in the explicit management structure of the organization.
I initially wanted to believe that nothing had changed because I was a manager – I could still be “one of the team”. But it quickly became obvious that my feedback – positive, negative, and even neutral – carried a weight it didn’t before.
This shouldn’t have been surprising. I’d had the experience of a manager who would frequently message “have a minute to talk?”. Every single time, my heart jumped into my throat, even though it was usually just to chat about something minor.
After I observed myself doing the same, I tried to always explain why in the same message as a request to meet with a direct report.
Even more navel-gaze-y, I realized that the form and timing of my communication mattered, because they implicitly set expectations about work habits for others.
I tried really hard not to send messages outside of work hours – and I made a big deal of visibly unplugging when I went on vacation. I felt those were important norms for our team, and the easiest way to upend them would’ve been to be seen not following them myself.
It took me a while to calibrate just how often – and quickly – I had to give feedback.4 I found that critical feedback has a way shorter half-life than I assumed.
The first few times I had critical feedback I held it, waiting for a convenient time. But after I’d waited a week, it felt petty to bust out, “Remember that presentation last week? You really should’ve proofread it before we showed a typo to the client.” And I was worried it’d be blown out of proportion in my direct report’s head because it had bothered me enough to hold onto for so long.
I never delivered that feedback.
I found the quicker I could give critical feedback, the better – and that the same was also true for positive feedback.
I don’t have a great anecdote from when I was managing, but a good friend of mine was getting very little feedback at her job. She didn’t really know if she was doing well and didn’t feel like her role was valued in the organization – until the day she resigned.
Suddenly, accolades were pouring in from leadership across the organization - all the way up to the organization’s head. She was told for the first time that the program she ran made a difference, and that her role was essential. She was personally lauded for the grace, professionalism, and strategic thinking she brought into every meeting.
It meant she left feeling good, but what an utter failure of management!
Some challenges I could identify, but couldn’t solve
Aside from the many skills I had to learn and the day-to-day skills I had to develop, some of the roles I inhabited as a manager involved ongoing balancing challenges that I don’t think ever really end.
I was stuck in-between
One of the strangest parts of being a first-level manager was how much I felt stuck between the organization above me and the people who worked for me.
I believe my employer genuinely wanted to treat employees well. They were not trying to – as Jack so eloquently put it on 30 Rock – “squeeze the sweetest juice out of workers’ mind grapes.”
Even so, I felt a tension between looking out for the company and looking out for my direct reports. In those cases, I generally found it easy to prioritize the people who worked for me. This was especially true since it was many of their first jobs and they hadn’t quite figured out how to advocate for themselves in a workplace.
This materialized in simple ways, like with the woman on my team who was a dual citizen. The complexities of having multiple passports and working on projects for the federal government meant she couldn’t visit her parents while she was on the project. It was easy for me to frequently ask whether that was still ok or whether we should start looking for another project.
But there were also other cases that were much harder – where there was a tension between my role as a mentor for particular members of my team and my responsibilities to the team as a whole.
For example, someone on the team confidentially shared that she was considering another project that would give her more exposure to machine learning. From my perspective as her professional mentor, this was awesome - that was the work she really wanted to do!
But it was hard for me to keep this information confidential, because sitting on it meant less time to discuss what to do if she left, and more stress for the rest of the team down the road.
My sense is that exactly what you’re stuck between does change depending on the level of management…but I’m not sure this between-ness ever really resolves.
Resource management was particularly hard
I despise the use of the term resource to describe a person on a team, like, “we’re going to need to add a resource in Q3” 🤮.
But the main resource I managed was the number of people we had and the roles they filled. I found that figuring out the right number of people for our team was an entirely new skill to master.
Before I was a manager, I basically just had to figure out how hard to work.
As a manager, I gained the mind-bending ability to make more time by adding people. Simultaneously deciding how much work the team could take on and how many people we needed required solving an underdetermined system of equations.
With no clear right answer, I had to rely on my judgment about the importance of the marginal bit of work and how quickly we could add team members.
And it wasn’t even that simple! Because I was a stuck-between manager, I couldn’t just decide to add more people or even to spend money on other things like a course or a team dinner – I had to convince several layers of management above me that we needed them.
Deciding how hard to push – and when - and for what roles – is a challenge that I don’t think ever really ends.
Mentoring was different
I knew I was a good data scientist with a particularly strong background in econometrics and statistics, and I had become a very proficient R programmer. I had done a lot of teaching, which I loved. I figured I had the mentoring part of the job in the bag.
Yet again – wrong.
It turned out that I was good at teaching and instructing. I was good at clearly explaining technical topics, making them clear and approachable. That was useful.
But it turned out that an even bigger part of mentoring as a manager was coaching, rather than teaching. I had to help my direct reports develop an inspiring vision for their career – or at least for their involvement in the current project. It was a heady task – figuring out how to convey really high expectations for people without setting short-term goals or deadlines that were unreasonable.
Moreover, it was hard to figure out how to balance people’s need for development, letting them slow down and take time to learn, with the need to get stuff done in the quickest way possible. As a manager, it was my responsibility to figure out when we had to focus on efficiency and when there were good opportunities for learning.
I loved management
I’ve mostly written about how hard management was and how it defied my expectations.
That’s all true.
But it’s also the case that I loved my role as a manager. I experienced so much joy as I watched the connections between the people on my team get denser, and the team’s topology came more to resemble a spiderweb than a wagon wheel with me at the center.
I found, curiously enough, that my joy at seeing what the team accomplished was inversely proportional to my involvement in it.
Now, having been at RStudio almost three years and being back in management, I look back quite fondly on that hectic, intense, learning-filled first year.
My hope is that, if you’ve read this far, you’ve gotten a nugget or two that might help your own transition.
So, if you’re there – good luck!
Appendix: Book Recommendations
I’ve read many, many books on management. I think most are not terribly useful – often providing 3 pages of insight in 150 pages of text or providing one interesting insight but adding in a lot of other topics because it seems obligatory.5
I’m not going to badmouth any particular books, but I’ve read many of the currently popular management books. If it’s not on this list, I’ve probably read it and didn’t think the marginal information gain was worth it.
Your mileage may vary.
Theory
These books strongly shaped the way I think about what management is and what a manager is doing.
You’ll notice that I lean towards older books on theory – both of these recommendations were written before I was born! While the computer, internet, and remote work have changed the practice of management, I don’t think the underlying theory has changed at all.
I strongly believe that the core messages of these books are still fresh and important, though some of the commentary and assumptions, especially around gender, have not aged well.
High Output Management (1983)
Andy Groves’ classic on what management is and how to measure a manager. Light on practical advice, amazing for forming a mental model of management. I find myself constantly reaching for quotes from this book to describe good management.
Mythical Man Month (1975)
Fred Brooks’ tome on communicating across large groups and what it is that makes building software complex. Not strictly about management, but it deeply impacted the way I think about the optimal size of working groups and how to help people be productive.
Practice
This book helped me figure out what to do every day as a manager, providing concrete advice on how to do onboarding with people you’re newly managing, conduct 1-1s, and more.
Radical Candor (2017)
Kim Scott’s book on how to provide direct and meaningful feedback to direct reports across a wide range of topics and venues. As a new manager, providing feedback was one of the strangest and hardest things to learn.
Even more so than other managerial tasks, giving feedback is almost entirely craft, so reading about it is sorta useful at best. I think this is one of the best treatments I’ve read.
Crucial Conversations (2011)
This is one I’ve only read recently, but really wish I had read during that first year as a manager. This book gets into the specific skills and tactics for managing yourself in order to manage difficult (crucial) conversations. It will have positive impacts on your ability to manage yourself and your relationships with others – even beyond work.
Footnotes
If you or your team is trying to learn git, I strongly recommend Happy Git with R as a resource. Good luck, git is super awesome once you get it, but it’s a doozy.↩︎
There are some great strategies to create an environment where team members can give feedback to team leaders. These are really important…but it’s pretty hard to get there, and as a manager I was flying blind most of the time.↩︎
Writing is also an important tool as a manager. I’ve found writing really useful for me to work out my thoughts on something – or to get feedback from particular people. I’ve generally found it less useful as a way to convey information.
Makes you wonder who this essay is really for…↩︎
The section on feedback in Radical Candor particularly influenced my thinking on this front.↩︎
I am keenly aware of the danger of speaking ill of others writing, given my own limitations as a writer. But if it can be useful to you, maybe it’s worth it.↩︎