Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

careers #67

Closed
wants to merge 6 commits into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
85 changes: 47 additions & 38 deletions src/docs/goals/careers.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,41 +12,50 @@ the goals of Auxiliary Engineering is to give senior engineers a new archetype
which feels challenging, rewarding, and well aligned with their long term career
success and ambitions.

## Influencing without Authority or Dependency

## WORK IN PROGRESS NOTES

- On Dependency
- When someone has unique strength in an area, it's too easy to lean on that
person
- In the short term, dependency can satisfy one's ego, and it's generally the
path of least resistance
- In the long run, dependency feels bad, and it also bakes a lot of risk into
a team
- In a 3 month engagement, the end of the project is always looming on the
horizon
- This makes it easy to challenge knowledge dependency early on, and prevent
single points of knowledge failure from forming
- Expectations

- Breadth of influence across the organization
- Regularly shaking up their problem domain
- Being in a position to identify the meta opportunities and having autonomy to
drive innovation

- Senior talent enjoys working on a variety of projects
- Similar to high-end consultant
- Feel more connected to results than a consultant
- But it's not a 0 sum game like consulting
- There's no incentive to build dependency.
- Building strength without dependency
- There's an explicit goal to NOT build dependency
- Healthy knowledge sharing
- Feels impactful. One sees the results first hand
- Large business impact
- Moves some of an organizations most talented engineers around the company
- Able to influence a large number of projects in healthy ways
- Influencing as part of a team, not an outsider disconnected from
implementation / results
- Avoids "powerpoint" architects. Keeps principal engineers writing code
- This helps keep them marketable. It's good for their career.
## Diversity by Design

Providing a fresh problem space with some familiarity on how to solve it can be
refreshing for individual contributors. By delivering value in many areas
through their direct involvement, a shared goal in Aux Eng lies in providing
technologists with a meaningful degree of influence. That influence comes
from understanding many of the diverse problems in a software ecosystem.
Especially in senior technical tracks and leadership roles, this kind of
exposure and influence in an organization goes a long way in building a career.

A shared goal that benefits both the platform an engineer supports, and the
engineer itself, is the ability to recognize patterns in a software ecosystem.
Finding opportunities to shake up the expectations technologists hold about a
platform or implementation allows for stronger practical innovation. Put
another way, exposure to diverse problems and people creates pattern
recognition to build better tools — a benefit to both the platform and the
career of the recognizer.

## Practical Practice

As platforms (and _careers_) mature, it's easy for individual contributors to
get bogged down (or caught up) in doing stuff that isn't code or practical
work. A lot of strategy and planning can take over their schedule, and it's
easy to become disconnected from the technical problems being solved. Mentally
and socially, it is exhausting to switch between high-level thinking and
low-level implementations.

It's our goal in Aux Eng to provide a structure that leaves deliberate time for
planning and implementation separately. Given that the practice requires a
subject matter expert to be effective in running an engagement at all, this
feed into the happiness of the contributor, and is a secondary goal for the
program. We want our people to feel like they're involved in the organization,
solving real problems. We also want them to avoid being a "PowerPoint
architect" who barely has the chance to actually play with the software and
systems they build.

Through direct involvement, as well as the planning of said involvement, we
grow the seniority of our individual contributors. We retain senior engineers
more effectively with these programs by allowing them to "just code again".
Not only just code, a large part of engagements is coding and working
with other teams to see how they code, problems they're solving, and how
it applies to work a core team does. By providing pair programming back to
exhausted technologists, Aux Eng gives the opportunity to write and read
code while solving real problems in engagements.
The knowledge sharing from our senior technical staff, and the satisfaction
they get from being able to practice their craft is a win-win-win for the
platform, the contributor, and the team engaging with us.