Leveling in IA and engineering

We do things in a backwards way from engineering, and I would argue most other fields. Maybe this is also part of being in an information profession that operates orthogonally to others. We also have the dubious distinction of usually working alone.

I started thinking more clearly about systems design when I was at a big tech company and helped people refine their self-promotion employee review packets. Most of it was straightforward, helping them map their accomplishments to the next step up the engineering ladder:

• As a Novice going for Junior, you had to prove you could fix bugs without too much supervision;
• Going for Senior, you had to prove you could implement a whole design with little supervision;
• Going for Staff, you had to show you could produce designs based on business problems with basically no management;
• Going for Senior Staff, you had to solve bigger and bigger business problems; and so on.

After helping a few dozen people with their assessments, I noticed a trend. Most developers mapped well onto the ladder, but some didn’t fit, even though they seemed like great engineers to me.

There were two groups of misfits:

1. People who maxed out as a senior engineer (building things) but didn’t seem to want to, or be able to, make it to staff engineer (translating business problems).

2. People who were ranked at junior levels, but were better at translating business problems than at fixing bugs.

From apenwarr

That #2? That’s us. That’s what information science programs are putting out into the world, whether the thing they’re not as good at is fixing bugs or monkeying with Figma designs or whatever.

References

Pennarun, Avery. 2020. “Systems Design Explains the World: Volume 1.” Apenwarr, December 27. https://apenwarr.ca/log/20201227.