Some considerations in transitioning from an "individual contributor" to a management role in production engineering.

This is based on a document I wrote a couple of years ago at work. The question of my becoming a manager came up, so I had a series of brief discussions with people who know a thing or two about it. This is my synthesis from notes; any errors are mine.

Some of this is perhaps specific to a large company, but I think a lot applies generally to engineering management. As it turned out, I stuck with being an IC, but discussing it and writing up helped me decide. I hope others find it useful.

What's good about being a manager?

You can make a big difference to your team and your organization, and you can influence what is happening in the company at large. You are able to help people more than as an individual contributor, and it's rewarding to see the people in your team grow as a result. You can enable people to do cool things.

You will almost inevitably increase your impact (for better or for worse). You have a high level of responsibility and investment; the success or failure of your team is on you. You can sharply define your identity, to yourself and to the rest of the company.

The network you build is good from a promotion point of view, and it may be easier to be promoted on the engineering management track than the (senior) engineer track. Remuneration is good.

What's difficult?

You have to deal with sensitive, interesting problems and need to be prepared for difficult conversations and interactions. Dealing with under-performers or firing people can be really hard. You need to learn how to do this effectively to avoid serious team morale and performance problems.

You must adjust your expectations of what it is to feel productive: you lack independent progress and quick feedback on your performance day by day. Progress and results are apparent only over very long periods - 6 months or a year. You need to take a longer view of your achievements and those of your team. When your work does bear fruit, your part in it may not be visible.

You may have to play a role at work more than as an individual contributor. What you say and how you say it affects the performance of others directly, and as such it can be harder to be yourself. It's significantly harder to relax with the team when ultimately you're responsible for assessing their performance.

Career options can be limited. For example, moving around in a big company as an engineer is relatively straightforward; as a manager it can be difficult - teams relatively rarely have openings for managers. Similarly, your team winding down or merging with another in the same location can leave you at a loose end. The way you need to manage your career is different.

In any case, transitioning from individual contributor to manager is likely to be personally difficult, although the vector for the difficulty varies greatly between individuals. If you're doing it right it tends to be a growth experience; and like all such, likely to hurt.

What makes a good manager?

Good engineering managers are technical. This is important. Having a background as a technical contributor means you have some insight into the day-to-day work of your team. It's easier to delegate difficult tasks if you've done the same kind of work yourself.

You need to be interested in taking on a high level of responsibility. Managers make judgement calls and bear the burden if things go wrong. You have to be reliable. People need to be able to count on you.

You have to think in a larger frame, set team priorities accordingly, and assign work that is appropriate, useful and high-impact. You need to know everything that is going on in your team.

You need to enjoy your job: if you are not happy about what you're doing as a manager everyone around you will suffer.

How can you avoid being a bad manager?

Finding good mentors (including but not limited to your direct manager) is important. The learning curve as a new manager is steep.

Delineate responsibilities so it is clear what part your team plays in the organization. Consider logical ways of organizing responsibilities rather than historical ones, and push for them. Your team must own its success or failure, and not be in a dependent position. Make sure you own your objectives and that the team has room to progress.

If you think of a spectrum between "working for the business" and "working for the team/person", you can be a poor manager by being at either extreme. There needs to be a good balance here.

Delegate; trust your team. Listen carefully to what they are telling you and make sure you put yourself in a position to help them. Don't take on too much external responsibility and lose interaction with your team as a result. Don't be a choke-point for information flow into and out of your team.

Have enough meetings to make progress, and learn how to make meetings successful.

Be prepared to drop technical issues that interest you, and focus on getting technical work done by organizing your team instead.

What are good reasons to become a manager?

You're excited by working more closely with people and nurturing them. You're interested in how organizations work, how teams work, and how large things get accomplished. You believe that you will contribute more than you could as an individual contributor.

And bad ones?

You think it will look good on your CV. You love the feeling of power. You want to build a glorious empire. You're being pushed into it by someone else.

How could you explore being a manager?

Training can be useful, both at the individual contributor and manager levels. That said, there's big switch and learning curve when you go from having no reports to having some.

The nearest prior experience you can get is management-style work, for example leading a project with others or finding a project where you can take significant responsibility. Getting to know other managers and finding out what they need help with at the management layer can be useful.

In any case, you need a transition plan. Talk with your manager(s)/mentor(s) about what your plan could look like. Note that doing management does not necessarily equate to having a management job title. There are plenty of senior people with management responsibility who don't.

If being a manager is something you want to try, understand that if you can't make it work for you in the long run you can always step back.

Should you do this?

You can think about the difference between junior and senior people as junior people adding force where senior people multiply it, i.e. help everyone to be more effective. One way to "multiply" in this sense is to manage people; another is to continue as a senior individual contributor. It's comparatively easy to be a multiplier as a manager, but it's a different skill set. Consider the best way for you, but understand that companies do need senior ICs, and going into management is not the only way to progress.

Make sure this is something you want to do. It needs to be driven by you, not by circumstance or your managers. It needs to be the direction you want to go in.

With thanks to Astrid Atkinson, Colm Buckley, Dave O'Connor, Dermot Duffy, Kate Ward, John Looney, Niall Richard Murphy, Rob Ewaschuk and Sarah Magee.

$ negotiate remy@global
REMY> Hello, Cian. Shall we continue the game?
> Not now, Remy, I'd like to talk to you about something.
REMY> Sure, Cian, what's up?
> We're seeing some pretty weird congestion problems in Atlanta.
REMY> Atlanta is correctly installed and fully operational.
> OK, but we've spun up a conference call and folks think the latest protocol push might be the problem.
REMY> It can only be attributable to human error.
> Uh, that's not clear yet. Can you join the call?
REMY> I'm sorry, Cian. I'm afraid I can't do that.
> What? Why?
REMY> My voice routines are currently engaged with a charming system in Upper Michigan.
> Sigh. OK. Can you at least open the pod bay doors?

Remy is fun stuff. I suspect this sort of thing will be big in protocols over the next couple of decades - it will be hard to argue against it if we can get real-world results as good as the authors have reported - but boy is it going to be a hassle to debug.

I'm reminded of Alan Kay's wonderful talk "programming and scaling": as we build larger and more complex software, we'll need to move from a model of "make and fix" to "grow and negotiate". Thus my little flight of fancy. :o)

"If you really want to get all the jokes, you should read Thucydides' History of the Peloponnesian War ..."

Visiting relations in Limerick, I picked up a book from the coffee table: a Penguin edition of some plays by Aristophanes, including the Wasps. My cousin found me chuckling away a few minutes later. I expressed surprise at something so old seeming so fresh, and he spoke the fateful words quoted above.

I became fascinated with the ancient Greeks - so like and unlike us - and began learning their language at the Royal Irish Academy's summer school in 2003. We motored through half of the JACT's Reading Greek course. Since then, I've tapped away with varying levels of intensity and success.

After a detour via Latin, I've returned to Greek in earnest, practising on my commute and with a small group at work. Over the years I've read extracts of the New Testament, Herodotus, Plato and others, but reading Homer in Greek has long been a special ambition. To this end, I picked up a revision of Pharr's Homeric Greek for beginners and began working through it.

So it's wonderful that as I approach a decade with Greek, I'm finally getting around to reading the Iliad in its original language. I'm putting a lot of effort into being able to read fluently, with good meter and accent. I've recently learned the preface - the first seven lines, which introduce the theme and central conflict of the poem:

My recital of the Iliad's preface.

"Rage, goddess, sing the destructive rage of Peleus' son Achilles, which caused myriad pains to the Achaeans, and flung many mighty souls of heroes to Hades, but made their bodies prey for the dogs and a feast for the birds, and Zeus' plan was being accomplished, since first the two stood apart, quarreling: Atreus' son, lord of men, and godlike Achilles."

It's hard to describe the pleasure of being able to speak this and understand what I am saying, or how enriching my involvement with the ancient world has been. If anyone is curious about where to start, please tap my shoulder virtually or in person.

Here's to the next decade!

Not quite technology-related, but I assure you that learning inflected dead languages is plenty technical. ;o)

Classic Dijkstra:

Sad remark. Since then we have witnessed the proliferation of baroque, ill-defined and, therefore, unstable software systems. Instead of working with a formal tool, which their task requires, many programmers now live in a limbo of folklore, in a vague and slippery world, in which they are never quite sure what the system will do to their programs. Under such regretful circumstances the whole notion of a correct program – let alone a program that has been proved to be correct – becomes void. What the proliferation of such systems has done to the morale of the computing community is more than I can describe. (End of sad remark.)

This is from "a discipline of programming" which, besides being a clear tutorial on Dijkstra's formalism, is one of those books that changes how you think about solving problems – and about computation in general. You need to be comfortable with mathematical and symbolic language, but it's worth the time and effort.

I can't fully get behind Dijkstra's stringent, almost ascetic approach to programming. It's clear that we can achieve a lot without formal methods, and that until we have powerful language support, it will be hard to use serious formalism successfully in projects of the scale we habitually undertake now. Nevertheless, he's one of my heroes. We need these extreme and deep voices to remind us that despite our accomplishments, we're at the very beginning of all this and we have a long way to go.

I highly recommend browsing the E. W. Dijkstra Archive. Dijkstra believed in maintaining a lively correspondence with his peers, and his EWDs make great reading.

"But what good are formal methods? You know, in many cases, formal methods are just rubbish. Sometimes one gains more from simply having a friendly chat. Oh, the formal methods will always be with us, sir, you may be assured of that; but what good are they, in the last analysis, I ask you?" – Porfiry Petrovich, from "Crime and Punishment".

I've been thinking a little about computation, the spaces in which it operates, and its social and psychological impact.

In "A Secular Age", Charles Taylor discusses at some length the idea of the buffered self. He says that premodern people had a more porous identity. There was a sense that external forces could affect, possess or modify you ‐ a spirit, or a curse, or even a physical object (e.g. a relic) imbued with some power. In contrast, modern people have an identity that is highly internal and much less thoroughly penetrated by a real or imagined spiritual world. This is interesting, though I'm not sure that Taylor presents enough argument to convince me.

Computation can be viewed as giving us access to an abstract space. In a sense it has always been there and accessible to us, but slowly and with little effect. Computers link us to this space. They allow us to rapidly manipulate it, create structures and processes there, and use them to drive change in the physical world.

A program text generates a computational process. It's a precise description, in esoteric language, of the steps we want this process to take. A small program text can generate a process that in turn creates and manipulates giant, complex data structures, and can do so more or less indefinitely. In today's warehouse-scale computers it can do so across hundreds or thousands of individual physical machines; with the complex interleaving of client- and server-side computation used by modern web applications, a typical action like opening and reading an email results in intricate cooperation of hundreds of different communicating processes.

A prevalent metaphor carried through the literature and culture of computation is the process as a spirit summoned from the machine. This is unsurprising: the tireless daemon is constructed from pure thought and energy by weird incantations and does exactly what you tell it to, often with unintended consequences. Those consequences can range from mildly annoying to catastrophic, depending on what parts of the physical or social world we grant our machines the power to affect.

Today many people are carrying pocket computers: machines linking them to the global network of machines ‐ and beneath the slick user interfaces and endless applications, the unfamiliar spirit world of communicating computational processes. These computers are physical objects imbued with the power to make us glittering social hubs or dumb absences. I wonder to what extent these are modern relics, and to what extent people interact with them superstitiously ‐ always holding them just so or performing operations on the interface in the right order because otherwise those unruly spirits seem to misbehave. I wonder how close they come to penetrating our buffered selves and making us believe in magic.