Developer career growth

1. Keep evidence of your impact

Once a week, write down one example of:

• A problem you solved or a decision you helped make.
• A risk you reduced, delay you avoided, or process you improved.
• The result for your team, users, or service.

Use these notes in check-ins, performance conversations, and updates to your resume or profile.

2. Look for decisions, not just more tasks

Some assignments are mainly about carrying out an agreed plan; others require deciding which plan makes sense.

• Execution-focused: implement a design the team has already chosen or produce a report with agreed requirements.
• Decision-focused: compare design options, identify the right measure of success, or recommend which user problem to tackle first.

Both kinds of work matter. To broaden your experience, volunteer for a piece that includes framing the problem, explaining trade-offs, or making a recommendation—not only completing the agreed steps.

3. Choose a stretch you can start

Choose work that matters, teaches you something new, and has enough structure to begin responsibly.

• Do: agree on a useful outcome, a first task, available support, and a checkpoint.
• Do: leave room to learn and revise your approach as new information appears.
• Don't: choose work that repeats skills you already use every day if your goal is to grow.
• Don't: take on a vague, oversized assignment without first clarifying its scope, authority, or help available.

If you are unsure how to begin, ask someone to help define a smaller first deliverable before you commit.

4. Make space through knowledge sharing

If one recurring responsibility depends on you alone, make it easier for the team to cover.

1. Write down the steps, context, and common pitfalls.
2. Pair with a teammate as they take on the task.
3. Agree how to handle questions and hand over ownership safely.

Good coverage supports your teammates and makes it easier to take on different work.

5. Make a specific request

Bring your manager a proposal that covers four points:

• The work: the project or bounded piece you want to own.
• The benefit: how it helps the team or its users.
• The transition: how your current responsibilities will stay covered.
• The learning: the capability you expect to build.

If the timing is not right, ask what smaller contribution could be useful and when to revisit the conversation.

6. Learn against a real deliverable

Try not to make finishing a broad course the prerequisite for starting useful work; you may spend time on material you do not need yet.

Instead, name the next deliverable and list two or three knowledge gaps that could block it. Find a focused answer in documentation, a short lesson, or a conversation with a teammate, then use it in the deliverable.

Review the result, note what remains unclear, and choose the next small learning step. For example, before proposing a service redesign, learn just enough about the current system and its constraints to compare a couple of options.

7. Make progress and obstacles visible

New work can take longer while you build context. Set expectations early, share progress in small increments, and ask for feedback before the final delivery.

When you get stuck, describe what you tried and what decision or help you need. Avoid hiding delays or trying to compensate by working in isolation; surface risks early so the team can help adjust the plan. If the work is not meeting expectations, discuss the gap and agree on a recovery step.