Management: The Final Frontier?

This a chapter of the book Get a Better Developer Job. It’s best to start at the beginning.

A post on Hacker News got a lot of attention. In it, a programmer laments his one regret was never entering management. Should you be concerned? And if you’re interested, how do you go about it?

In this chapter you’ll learn about the different styles of organizations, plus strategies and tactics for getting the job. I’ll give you a full overview of the profession including which skills are valued, how to get the job, and how to avoid getting stuck in a rut. I start by giving an overview of the two software management styles, then cover career strategies.

Note: this is not just my opinion. Several CTOs, heads of engineering, and directors at companies ranging from established startups to IT stalwarts have vetted this information.

Many developers assume they’ll eventually become managers. In a market where developers have better job security than managers, and some are better paid, when is it the right move? And what path do you take?

The answers depend on the organization. And as I show, in some organizations, managers remain technical – it may be your only option if you want to handle architecture. In others, you won’t have time for hands-on contributions.

First, identify what kind of organization you’re in, or want to be in. To simplify it, let’s call them “traditional” and “modern” orgs. Traditional organizations include pre-dot com software companies, non-technical companies (e.g., manufacturers, insurance, healthcare, finance, etc.), and most IT services and enterprise software companies. In general, they are sales driven vs. engineering driven.¹ The presence of PMPs is a huge sign you’re in a traditional management organization.

Modern orgs include software startups and prestigious software companies like FAANG. A strong sign you’re not in a modern software company is a leadership page that’s missing your CTO – despite more than 30% of payroll going to engineering.² If top management doesn’t consider it a software company, don’t bother arguing with them. A lot of media companies are in this bucket.

Traditional

In a traditional company, you’re often promoted to management due to people skills and a willingness to take on non-technical tasks that programmers dislike. People would ask me how to become a lead and I’d say, “Don’t hate documentation.” At a lot of places, that’s really it. Most programmers only want to program, so taking on other responsibilities sets you apart immediately.

Managers here are responsible for:

• requirements gathering
• bug/issue tracking
• documentation
• deployment/CM oversight
• schedule
• budgeting
• employee evaluation
• training
• business development

With all that time spent managing, how do they fit in engineering? They don’t! They contribute little on the technical side, and only when they make a special effort to do so. A rule of thumb is that you lose 25% of engineering time for each employee you manage.

Many of these companies follow “matrix management,” which splits functional and project management. Employees are grouped by job function (development, ops, etc.) and have a functional manager who finds them a project to work on. This manager is also responsible for raises and career development. Project managers are assigned workers from the different functional groups. This allows functional managers to specialize in the tech domain and project managers to handle the business domain. Both can advance to executive. Project managers, as they are promoted, are often referred to as program managers.

But there are often unspoken requirements. If your company worships at the temple of the Project Management Institute, you can pick up a PMP cert at week-long boot camp. Because people skills are so valued, you will get a lot out of taking a Dale Carnegie course. Another activity popular with managers is Toastmasters, which combines networking with improving your public speaking skills.³

More likely, a graduate degree is required, but look around! Most of the time you want an MBA, but in aerospace, engineering degrees are more common, at least for lower level management. In healthcare it’s another story. My friend has undergraduate and graduate degrees from the world’s most prestigious engineering universities and could rise to the top in aerospace. Unfortunately, all the top brass in healthcare have an MD. Despite his intelligence and credentials, he knew he’d never get to the C-suite.

Do many execs at your company have a degree from a specific school? Are they all Ivy League? If it’s a company you want to be at long term, follow in their footsteps.

Modern

Like traditional orgs, modern ones have two types of managers, which I’ll refer to as technical managers and supporting managers.

Technical managers are the people you call “the boss.” They directly manage developers and are promoted into management because of technical prowess. This is reflected in their job ads.⁴ From startups to mid-size companies, all technical managers (including the CTO) are hands-on. At a minimum they handle architecture, and many make time to code. This track is a path to CTO and even CEO. Satya Nadella is a good example. And Bill Gates was notorious for grilling people on tech specs, even as CEO.

As you can see from the stark contrast, staying technical requires doing less of the traditional management work yourself. These managers rely on “support management” such as technical project managers or scrum masters. Support managers handle many traditional management tasks, such as requirements gathering, schedules, documentation. They may also do general cat herding (e.g., chasing after developers to get status updates) to allow tech managers to remain hands-on.

The painful truth is in these in modern organizations, I rarely see good advancement opportunities for managers who have allowed their technical skills to get rusty. Most of the moves for scrum masters and technical PMs are lateral, while the technical managers move up the ladder. I’ve seen many sharp programmers move into these roles because it was seen as a reward. But then they lose their technical chops and find themselves unqualified for both traditional and technical management jobs. And they have trouble going back into development for the reasons already laid out in this book. I’m sure there are exceptions, but like Admiral Akbar, I see this as a trap.⁵

In contrast, product managers can advance to VP or higher. Their responsibilities and role can vary. They may be a full product owner, reigning over the feature set, or more of a market strategist. So tasks can include requirements, specs, competitive analysis, usability/UX, analytics, and conversion optimization. It’s not uncommon for them to have actual P&L responsibility. Note that in some big, modern software companies (Microsoft, et al), they are called program managers, not to be confused with the high-level project managers described above. And if you’re doing all these things, but you’re called a project manager, you might want to ask for a title change.

It’s well known that people in modern orgs are biased against people in traditional ones, even on the engineering side. This makes more sense for managers since the tech skills are missing. Part of it may also be size, where startups don’t believe managers at big companies understand their problems. Bottom line, it’s harder to move into a modern org from a traditional one vs. just starting there or switching while a developer.

Strategies

General

Few lower level manager jobs go through recruiters as there is no need.

First, they will try to promote from within. This signals to employees that there are opportunities for advancement. And, of course, employees know the systems best, along with the employees they will be managing.

This can be a drawback. I have seen “Mexican standoffs” where employees tell their boss, “If you ever promote X to manager, I’m quitting.” And X is saying it about Y, and Y about Z. You might be shocked to learn that X and Y and Z are friendly otherwise. Or not, if you’ve been in a typical corporate environment for any length of time. So management hires from outside.

If there are no viable candidates, an outside search will get tons of applicants. They’ll get engineers looking for a promotion from team lead (that’s typically a hard requirement) and managers looking for a new employer.

Networking is a critical skill. If you’re looking to be promoted, I recommend buying a different manager lunch every couple of weeks. Work your way through the org chart.

I’ve said this for developers, and it’s true, but managers absolutely, positively must measure their results! I remember reading a book on resume writing and thought, “Wow, these look so much more impressive than mine!” But it wasn’t the formatting. These applicants had fully quantified their results. This is sexy. Doing so sends a clear signal to your superiors that you’re business minded and care about your impact on the company. Recruit your manager’s help, as they should be just as interested in this.

Traditional

What you say during your lunch meetings with managers is important. When I was at Boeing, we had once a president from another division address us in an all hands meeting. An eager young engineer raised his hands during Q&A and asked what he should do to further his career. The president saw a great opportunity to both answer the question and publicly humiliate and demoralize the young engineer.⁶ He said you don’t ask how to further your career, you ask what you can do to best serve the company. He explained how he rose to power by making a series of lateral moves to groups that were desperate for help. He’d fight their fires, then get promoted.

Companies make it clear where they need help the most. The job description mentions bonuses, high referral fees, and relocation assistance. That manager moved all over the country before making president, because the greatest need is often in East Nowhere. It’s pretty easy to shine in these positions, so it was good advice, even if he was a jerk about it.⁷

But you may not need to move. At your lunch, ask the manager what the company’s greatest needs are and how someone like you can help. I recommend talking with both technical and non-technical managers (HR, accounting, etc.), because the latter don’t know what’s possible with software and are often neglected by IT. You might come up with a project that both saves their department money and generates works for your department.

Another technique was used by a friend to become one of the youngest program managers at NASA: he offered to take the lead on every assignment. Soon he was telling his manager, “I need you to assign me people to finish it all on time.” It was a virtuous circle.

Modern

In order to stay technical after taking a lead position, track your time doing management tasks and make sure it doesn’t go above 25%, no matter how many people you manage. That’s already two hours out of your day. If you see it creeping, be sure to delegate tasks as needed, and get developers to be self-managing as much as possible. This means updating their tasks in the tracker, documenting their work, etc., at a high level. If there are technical disagreements on a subsystem you’re not actively working on, you don’t have to be in the room. Let them work it out and come to you with the solution. If there’s any push back, explain how this allows them to remain technical as they take on responsibility, too.

Also, keep an eye out for are tasks that are outside of your specialization. Good chance you got promoted for being the responsible one, and when you see deployment, QA, and other areas being sub-par, you want to pick up the slack. Don’t. Not unless you want to change specialties. Delegate it instead. Odds are, someone will find this work interesting, especially if you stress the importance, quantify its value to the company, and pay for training. As lead, you should be taking responsibility for the most challenging and important development tasks, so you should have the least amount of time for this.

Some of you will be shocked by that. Isn’t that selfish? Machiavellian?! It’s OK. I give you permission. A while ago I read some crucial advice that I will pass onto you: you are responsible for your own career. People act like it’s obvious, and consciously it is, but we usually don’t behave that way. And your manager, if he or she is any good, will make you feel like they are looking out for your best interests. And they are, unless it conflicts with what’s best for the company, because that’s what’s best for their career. This taps into our praise-seeking behavior, that internal honor student who wants to make the adults happy. Now you’re the adult, and it’s time to make you happy!

Help somebody's career:

Next chapter: Resume Mistakes and Tips