How I think about career development

| categories: career, thoughts

Over the years I’ve come up with a basic approach to my career:

  • Figure out what I want from life, and how work can support that;
  • Use role models and writing to imagine possible futures;
  • From those, map out the skills and capabilities I want to develop;
  • Lean on my current work environment - or change it - to support my development.

From time to time I talk with colleagues and friends about this. These are some notes to make sharing easier.

Assumptions

I’m writing about software engineering, systems engineering, and adjacent careers. Mainly for individual contributors, because that’s what I know best.

We are on the hook for managing our own careers: a common mistake for less experienced engineers is believing that their manager will do this. Sometimes, managers will be a help; often they won’t.

Everything is learnable. We’re not fundamentally limited by our current roles, skills, whatever.

Starting out

I think about what I want my work to enable in my life.

For some people, that’s wanting to travel, or to learn specific things, or to settle down in a beautiful place, or to found a company, or things related to family, or all of the above.

My personal list is rather general at this point, but well tested. I want to:

  • Support my family in a good life;
  • Help other human beings do things that are meaningful to them;
  • Work with teams I trust;
  • Be trusted in turn with a high degree of autonomy;
  • Learn a great deal;
  • Solve interesting problems;
  • Leave things better than I found them.

This is in rough priority order. Had I thought about this more clearly, earlier in my career, I think the order might be different. At times, particularly when changing jobs, I might have had more specific ideas. Many companies and types of work can support everything above. Some simply can't.

I like having this list because it helps orient me around the things that I need or am looking for. If I can check off everything above, or I am making positive progress, then I feel like my career is in a good place. If there are things lacking, maybe I need to take action to fix that.

It also makes the classic “where do you see yourself in five years?” feel somewhat tractable. :o)

Drawing a map

We have a starting point, but assuming that we want to meet some specific need, how do we figure out what moves to make, where to go?

I like to have a map, a way of identifying the gaps between where I am and my possible futures.

I often use role models for this - colleagues current and former, industry people I respect. What do I value about what they do and how they behave? What do I want to be when I grow up? :o)

Another useful resource is published "job ladders". These are a good way to look at the things various organizations value and how they see careers progressing. Examples:

It’s worth having a think about how much you value the skills and capabilities listed, and how different companies’ ladders differ, particularly at senior levels.

Finally, there’s an expanding literature around how senior engineers work:

There’s a lot to like, to learn, and to model in all of these.

Filling in the gaps

I tend to think in terms of skills and capabilities.

Given all of the above, which skills do I have but could develop further? Which do I lack entirely? What capabilities do I think my role models have that I don’t? Which do I value the most? Which would have helped me in my recent work? Which will enable me the most in future?

Now I have a list of specific things I want to be better at: the beginnings of a plan! I look for ways I can manoeuvre myself into work that will stretch me in those skills, build those capabilities.

Where I think it will be useful, I advertise! Let my manager, my mentors, my team know that I am trying to develop these skills. Can they help me find opportunities to improve? If I can find ways to work directly with some of the people I find inspiring, on those specific kinds of work, even better.

Note that this can form a good basis for annual or quarterly goals, so that’s another pain out of the way. ;o)

Considering context

While you work on your plans and your goals, pay attention to what’s going on around you.

Keep notes on what’s working and what’s not: in your own work, your team, your org, your production systems. This can be a useful source of ideas for specific projects or development opportunities.

If you can, find ways to make your goals work with those of the people around you. Developing your career can and should be something where everyone benefits.

Wrapping up

I have a particular perspective, and I’m certain I am missing a lot: I generally think in terms of skill acquisition and deployment, and I’m not sure how well any of this will apply to different kinds of work or different kinds of people. Take all of my advice with a grain of salt. We’re all just working this out.

To recap:

  • Think about what you want out of life, and try to make your career serve that.
  • Imagine possible futures by using role models, formal career “level” guides, and the best writing you can find on being an engineer.
  • Move towards those possibilities by mapping out a path in terms of skills and capabilities.
  • Ask for help getting what you want, and try to make it work well with what everyone around you wants.

With thanks to Tanya Reilly and Niall Richard Murphy.


A little negativity about OKRs

| categories: process, thoughts

Archiving a Twitter thread:

Niall's thread is as thoughtful, judicious, and balanced as I'd expect. Allow me to be a bit more negative about Objectives and Key Results. :o)

First, the planning horizon. At $megacorp and anywhere that follows that playbook, OKRs are a quarterly process.

"Be careful what you measure": if your planning cadence is quarterly, there's a strong chance it'll become your delivery cadence too. That is too slow.

I love having a plan. Honestly, I enjoy the chaos as we watch it crash into reality, particularly in teams that are constrained by operational concerns (read: basically everyone with real customers).

Plans go out the window. That's fine, they're still useful.

But a quarter - for most teams and orgs I've worked with, including at $megacorp - is too big a chunk to let us respond well to inevitable change.

So OKRs become a big, expensive activity that swallow a bunch of team and management bandwidth without allowing room to react.

Second, "KRs considered harmful" (with caveats).

Making good KPIs is a known hard problem, right? As an engineering example, consider the difficulty of producing meaningful SLOs.

Coming up with a brand new set of good KPIs each quarter is high overhead and prone to failure.

"KR 1: produce the metrics we're going to use to track this objective." :o)

It can feel really hard to tie quantitative measurement of KRs - often proxy metrics - to the real outcomes we're trying to drive.

Finally though, it's not all gloom.

Objectives are a good tool for driving alignment. They can build a coherent narrative around strategy and tactics, from execs through to delivery teams.

I like to de-emphasize the measurement part though.

Where we do have KRs, ideally they're tied to longer-term KPIs that we can iterate on and come to understand better over time, on the order of months or years.

SLOs are a good example. Or from a team perspective, the DORA metrics. Or "north star" product / business metrics.

As for planning horizons: I am strongly attracted to ~6 week "bets" like Basecamp's or Intercom's.

Where I've worked like this, it's felt lighter-weight and more agile in the best senses.

All that said, whatever your particular team, org and/or company are doing to plan their time: get involved, and try to make it work as well as possible.

Channel your reservations into creativity. Use and improve the system. Try experiments. Share them.

Planning is good!


ICs, managers and bears! Oh my!

| categories: thoughts

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.


Negotiating with the machine

| categories: fun, thoughts

$ 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)


Reading Greek

| categories: fun, thoughts

"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)


Next Page »