The Dual Role Delusion

For the last 4 years, I’ve lived with a disorder. I am one of many. A half-dozen of my close friends and former colleagues have dealt with it or are dealing with it now. Indeed, I’d argue that most (if not all) who’ve taken a similar path have struggled with it.

I’ll stop being coy.

I’m talking about Dual Role Delusion (DRD). I define it as having the grandiose belief that one can excel at two divergent roles at the same time. It is not a disorder of the mind, but one of profession [1]. DRD could afflict anyone splitting their time between two divergent roles. For the purposes of this article, we will focus on a role split between management and individual contribution, specifically in software engineering.

The most important thing to know about DRD is that it’s going to hit you sooner or later. This is especially true in tech, where the stakes are high and so is the pressure to perform.

Is this your first time transitioning from engineering to management? Are you being forced to take the role due the constraints of your business? Do you really love building things? If you answered yes to any of these questions, you may be more at risk. Worst of all — you may already be suffering from Dual Role Delusion and you might not even know it.

Diagnosis

The mantra goes something like this: “If you want to be ‘insanely great’ at something you should focus.” Extremely few people can split their time and still be considered “insanely great” at both. Yet, I’ll guarantee you that as a first-time manager, you will underperform when it comes to management tasks because you won’t make them a priority. Intuitively, this makes sense. You took on these responsibilities because you excelled as an engineer and felt that you could do well in management by taking the same approach. However, as someone who’s never been a manager before, you have no idea how time consuming it can be. Most likely, you will continue writing code and neglect your management responsibilities. (For the sake of this story, let’s also assume that you work at a startup which does not have “manager training.”)

Early Symptoms — Manager in Name Only

Over time, this catches up with you. As a new manager you had grandiose ideas about how you would change things, build an awesome, high-performing team — but nothing really changed. How could it? You’ve been spending all of your time building the product. The team continues to make the same mistakes and your weak attempts at management are embarrassing you. Maybe it’s because they were non-existent. Maybe you said some things that rubbed people the wrong way, or maybe no one had a clue what the heck you were talking about in the first place.

Only after these early embarrassments does it start to sink in on you how much work management can be. You watch in horror as little things you say in meetings and in 1-on-1s tend to grow distorted and backfire if you don’t take the time to word them carefully beforehand. Furthermore, many things that used to be “above your pay-grade” are suddenly your problem [2]. You learn this the hard way after waiting too long to let go of an employee who is underperforming. The result is that you spend even more time correcting these mistakes by revising your hiring and performance review processes to prevent it from happening again.

Late Stage Symptoms — Double Down

This is when DRD really hits hard. The backlog of work isn’t going anywhere and there are so many bugs (some of them yours) that you wish for another 8 hours in the day to take care of it all. On top of it all, the people that promoted you to your position are counting on your team to build the next great feature that will save the company. For the first time, you realize that people’s livelihoods depend on you. And what do you do in response? You add 8 hours to your day.

Now your average day looks like this. You get in at 8am and start reacting and responding directly to all of the little stuff that pops up. Then at about 4pm, once things have settled down, you start working on the engineering tasks you’ve committed to. And because you’re taking on the same capacity you did before, you finish up at around midnight and head home. That’s what a good day looks like. (On a bad day, forget about building product, you don’t even get a chance to open your laptop.)

Rinse. Repeat - Ad nauseam.

Even though this new regimen is grueling, you justify it with various excuses which stroke your ego and downplay your naivety. After all, you’re the one who took on the additional responsibility in the first place, right?

Long Term Complications

Maybe you survive this way for a while; a couple of weeks, even months before you decide to admit that something has to give. Heck, I wouldn’t be surprised if there were people out there who have been at it like this for years and are convinced that this is how it should be.[3] I know how delusional/stubborn I was about my own situation as a first time manager. Only now, looking back on it all do I fully realize the extent to which it was impacting my life. If you’re not convinced, let me illustrate for you.

The personal effects should be rather obvious. You feel burned out. You find it hard to stay focused. You start getting sloppy and making mistakes you promised yourself that you never would. The end result is that you’re spending 16 hours at the office and only getting in 8 hours of productivity. Worst of all, your irritable demeanor has everyone else walking on eggshells. You’re underperforming.

Unfortunately, the negative effects don’t end with you. Your underperformance is impacting the team as well. As a new technical manager, you’ll find it hard to make time to focus on big decisions. Dual Role Delusion is again working against you. Consider the following scenario:

…

A while back, your product manager, Bob, interrupted you with a question on a new feature while you were 3-hours deep into a debugging session. It was the 12th interruption of the day, you were hungry because you skipped lunch and you didn’t feel like it was a good time to brainstorm. You grunted back, “sure, sounds neat” without fully comprehending his suggestion and quickly go back to your keyboard.

Two weeks later, your best engineer storms out of a nearby conference room, sits down at her desk and starts typing loudly at her laptop. She’s clearly frustrated.

“Um, hey Jennifer. Everything ok?”, you ask.

“Bob said you approved of that new feature, but it invalidates everything I’ve been working towards for the last 2 months. Now I have to throw it all away?!”

You’d totally forgotten the conversation you’d had with Bob weeks earlier and hadn’t taken the time to follow through on all of the downstream impacts it would have on your team. Instead of solving that single problem, you’ve now got two bigger problems to solve — a retention problem with your best engineer and possibly a redesign with Bob. Yikes.

…

Ultimately, Dual Role Delusion can lead to a significant conflict of interest in both roles. On one hand, giving too much preference to your own individual contributions could come at the expense of a clear direction and purpose for your team. A lack of purpose can lead to attrition of your best talent. On the other hand, neglecting bugs and features which you’ve committed to can put the entire business at risk. Now you’re missing deadlines and letting bugs sit to wreak havoc in the wild.

The Unfortunate Truth

So why is it that you continue to deny the reality of your Dual Role Delusion? The answer is Fear. You don’t want to wake up 5 years from now, only to look in the mirror and see the reflection of the “Pointy Haired Boss” staring back at you. You don’t want to become obsolete. You think back to conversations you had with people in management early in your career. You remember how their eyes would glaze over anytime you start to discuss something technical with them. You recall how hopeless it was to get help from them on any topic that actually mattered to you. You vowed that would never ever be you. On top of that, you genuinely love building things.

And herein lies your dilemma. You’re either underperforming and burned out, or you’re an obsolete windbag. These are a horrible set of options.

Treatment

Thus far I’ve been rather hyperbolic and pessimistic. I may have even convinced you that I hate management. I don’t. In fact, I find it to be quite rewarding. All of this was to prove a point about the realities we face as technical managers. Even though the problems I’ve mentioned above are real, there is a way out of the quagmire. Like any other product defect, the sooner you catch and correct the negative effects of Dual Role Delusion, the easier they will be to deal with.

The first thing you must do is admit to yourself that in order to become a great technical manager, you’ll have to take a step back from your commitments as an engineer. Pragmatism here helps. You might actually be able to manage both if you only have 3 direct reports. As that number grows beyond 10 people, you probably should not be writing code day to day. Whatever balance you strike, you can’t do both in the long-term — not without hurting your team.

The next thing you should do is start to set expectations with your boss and your team. You’ll be taking a step back from contributing directly and instead will be delivering clarity, team visibility, increased team velocity and fewer miss-steps. Your time as an engineer will be limited to temporary overflow in extreme circumstances.

With these expectations set, the next thing you should do is make sure that you’ve taken control of your own schedule. Block off non-negotiable time for management and strategic planning. Leave a little room for contingencies to address the unexpected things that will inevitably come up. Over time you will learn when and how you should be switching the context of your personal focus. Figure out a strategy for dealing with your email so that you’re not constantly checking it. A weekly regimen will allow you to keep a maintainable cadence for you and your team. For example, when I was managing a team of 5, I would dedicate the first part of Monday and all of Friday to non-negotiable management tasks.

Last but not least, you’ll want to find the right type of technical involvement. This can be one of the most difficult things that you do as it depends on your strengths, the dynamic of the team and its current focus. While there’s no foolproof advice here, it is usually a bad idea to frequently put yourself in the critical path of development. Instead, focus on things that will accelerate and enhance the efforts of your team. Take a larger role in design meetings, code reviews, and development of internal tools. One good practice I’ve seen success with is taking the first part of every day to review the progress of the team from the day before.

Beyond that, there are a few good places to go to find general advice on management and leadership. One place I recommend you frequent is Rands management series, written by Michael Lopp (He also wrote a pretty decent book).

Risk Factors for Relapse

I wish I could tell you right now that all you needed to do was recognize the errors of your ways and you’d be free from the misery that is Dual Role Delusion. In truth there are a countless number of scenarios and environmental factors that will push you back into your old bad habits.

• Large releases/product launches. This is a big one. Everyone is hustling to make a launch date and there’s not enough time. [4]
  → Solution: Depends. What are your options? Can you still contribute while staying off of the critical path? How far behind is your team? Can you pull in people from elsewhere? If you don’t think you’ll lose your job by asking for more time, then you should do that. If you’re still unsure, get advice from a mentor. You do have a Mentor right? — No? Get one. Heck, get two!
• The Legacy Code updates. You’re the only one who knows it, but it’s not been a priority and it’s been months since anyone’s touched it. Now it’s blocking your team.
  → Solution: Any senior engineer should have the capability to go spelunking through old code. Offer up an hour of your time to get them acclimated with it but stop short of offering them an early “out”. You’ll be pleasantly surprised at the capability of your engineers to figure things out on their own. This advice could also apply to any entry level engineer hungry to “level up” — just be mindful, you may need to do a bit more hand-holding. Extreme cases may need significant refactoring, or even a rewrite. For this you should recommend a good book and give your team plenty of time (assuming its available) to clean up “the dungeon” you left behind.
• Team makeup. You realize that your team does not have the depth or breadth of expertise that you need to be successful.
  →Solution: Stay back from the code as much as you can and invest in your people. If you’ve done a good job hiring, you’d be surprised how much a couple of pair programming sessions will pay dividends. If this problem is quite severe, you may want to consider restructuring your team or adjusting your hiring plan for the right mix of talent.
• Company Expectations. Some expect all managers to spend as much as 50% of their time as individual contributors.
  → Solution: As we mentioned above, this may be doable if you are managing 5 or less people. As you start to get beyond that though, this can become unmanageable. If this get’s too bad, either find a different job or get help from your manager.
• The Layoff. You just went through a layoff and now there is half as many people to do the same amount of work.
  →Solution: First think about cutting scope. What are the most critical things the business needs? If you can’t adjust scope, there no other options, and you still want to stick this gig out, you may want to consider stepping out of management for a short time. Talk to your boss to see if they can take over some of the management responsibilities until you can get things under control.
• See also: What To Do When You’re Screwed

Conclusion

Managing people can be one of the most rewarding things you’ll ever do, but you must make time for it and put a strategy in place in order to be effective. Recognizing your limitations will free you to focus on being a great technical manager instead of a crappy manager and subpar engineer. This is a huge opportunity. Although you may feel overwhelmed by it, the honest truth is that you’re in this position because others were confident in your ability to rise up and own it.

Acknowledgements

I want to give a shout out to the following people for providing feedback/validation on this topic: Ash Rust, Alex Viana, Elliot Lynde, Evan Worley, Jeff Mendonca, Mike Leftwich, Steve Garrity, Vlad Magdalin

Footnotes

[1] DRD is not a real disorder. It’s made it up — and it wasn’t (just) to be cute. Mental and physical disorders are nothing to joke about. Nor would I like to equate the problems of DRD to those facing any real physical/mental disorder. In my opinion, this was the most effective way of bringing light to a topic that I believe is deeply important to anyone straddling the chasm between individual contribution and management.

[2] This should not be a surprise to any founder at an early stage company. Almost nothing is outside of your pay grade.

[3] If I had to guess, I’d say that those same people are making larger sacrifices outside of work than they may realize.

[4] See also Hero Mode, See also Management By Crisis