It is near the end of “intern season”, and someone asked me what advice I would have given my younger self. Flippantly, my answer was “nothing” because I wasn’t good at taking advice – I was always following my heart instead of my head – but after reflecting a bit I have put together a list of things I wish I had figured out sooner:

• be an apprentice, not an intern
• practice project management
• learn about expectations for each level
• Focus on WHY, not WHAT

That’s a terse list which doesn’t even scratch the surface of what I really mean…

Be an Apprentice, Not an Intern

• immerse yourself in the culture
• pay attention to what your seniors value

What is the difference between an intern and an apprentice?

An intern executes on project tasks under the guidance of their manager. They learn fast and code even faster. Largely, what they improve is their technical skill.

An apprentice tries to absorb the values of their mentors. They go to lunch with the mentors, where they engage in debates and pay attention to the values that are communicated in these personal moments. For example, senior engineers love to complain about things – either design decisions, or projects that aren’t making proper progress, or the lack of proper communication – so much so that “the cranky engineer” is a trope. But in these complaints are hidden clues as to the values of the mentors.

And more than just lunch, an apprentice is always hanging around. Hanging around is important because you want to be there when a quick and easy task comes up which the mentor needs done. Working on tasks (and later, projects) for the mentor is how you grow your skills while getting feedback on your approach and how you could improve the result.

A good apprenticeship effectively changes who you are. You want to become a “tool” that the mentor can deploy, trusting that your values overlap to the point where you eventually need minimal supervision.

Suggestions for further reading:

• Forge Your Own Bubble
• The Hidden Influence of Your Community
• Things I Learned from a Senior Software Engineer

Practice Project Management

• whiteboard the pros and cons
• milestone your project
• ruthlessly prioritize

For a time, I was a contractor working for multiple startups. This required making project proposals and predicting the amount of time I would spend on the project; and like many engineers, I discovered that I was terrible at time estimation! To patch the issue, I began doubling all my estimates. And began investigating “Software Engineering” practices like UML, the Waterfall method, and Agile development.

Over time, I have pruned back my “methods” to a few key ideas.

Use a whiteboard. Arguments about difficult decisions will tend to go in circles. If the decision were easy, it would already be agreed; so we already know that we are considering a design decision with trade-offs that are valued differently by the participants. A typical chat or conversation will focus on the cons of the leading contender, listing more and more until the weight of them is untenable and the idea is abandoned. These same cons will often suggest a different choice, which then suffers the same treatment. Eventually, a full circle is made and the original idea is again the leading contender.

A better discipline is to write all ideas on the whiteboard, and then begin listing the pros and cons in a table. The act of writing it causes you to evaluate all ideas according to the same metrics, rather than whatever the focus of discussion is at the moment. And looking at these metrics might give you ideas for other possible solutions.

Milestone your project. Success of a large project comes from the smaller successes that built up to the larger one. A good milestone is one that enables the team to receive feedback about the approach and pivot early if a problem arises. Hitting milestones builds confidence in the project for both the folks working on the project, and the managers who worried that it might stall out. (Don’t underestimate the value of communicating your work to managers!)

Ruthlessly prioritize. Things happen: friends asking for favors, emergency projects, running out of money. Feature creep is also a kind of distraction that will occupy the team. An amazing project is one where the essential core of the product is decided at the start, and a series of milestones that prove out assumptions and interlock with each other to first finish that core product and then focus on the features that the customers are favoring. In order to get there, you have to be laser focused on prioritizing tasks that bring you closer to the current milestone. You have to learn to say “no” to work that does not serve the project.

A lot of folks get caught up in firefighting, working on fresh bugs and generally being helpful to their coworkers. The problem with this approach is that unless you are recognized as amazing at firefighting, managers will ask “what significant work did you accomplish recently?” The key to “success within the organization” is to focus on your projects, putting your effort into choosing good projects that might be helpful in different ways than the firefighting would be.

Suggestions for further reading:

• My whiteboarding example
• The One Thing
• RISE: 3 Practical Steps for Advancing Your Career

Learn about Career Expectations

Why do so many engineers grow up to be managers? What I didn’t realize when I was young was how your skills build over time, making you more impactful in different roles as you progress.

This is my outline for thinking about the different “phases” of a career:

1. coding machine, fast learner
2. starting to design and manage a single project, under guidance
3. designing and running multiple projects, influencing the roadmap of the team
4. influencing the roadmap of the org
5. influencing the roadmap of the company
6. influencing the industry

The first couple of levels are all about coding and running bigger projects. but at some point you need to scale back on coding and instead start “influencing”. At first, this starts with communicating about your projects. Most engineers resist this as being “advertising”, but well done communication is so much more. It is about explaining the problem you are solving, and why it is important to the company. It is about keeping to the right level of detail for your audience, and collecting feedback.

Good written communication starts conversations.

Advanced influencing can be planting the seeds for projects with engineers, recognizing broader problems, or convincing managers to allocate engineers to an idea.

Suggestions for further reading:

• RISE: 3 Practical Steps for Advancing Your Career

Focus on WHY, not WHAT

I used to love playing with technology for its own sake, just learning “what is possible.” Over time, I saw how that love became a distraction from completing my personal projects. A friend once likened it to Zeno’s Paradox: that you get closer and closer to the goal but never quite get there because the goal is always moving. The way to break out of the paradox was to pull an all-nighter to “finish the project”: as you get very tired at 3am, you start cutting features in your desperation to get to some sleep. What is left at the end is that “core product”, that Minimum Viable Product, which can stand on its own even while clearly suggesting what the next steps for improvement are.

Sleep is precious to me. How can I get the same results without the all-nighter?

The answer is to step back and ask WHY the project exists. What problem is it solving? How does it serve the company’s longer term goals?

Besides helping you trim down the size of a project, these questions also help you understand the competing priorities of the company. You need to know this in order to explain the impact of your project to partner teams while recruiting their help. For example, it’s a lot easier to agree to help on a project that directly improves the capabilities of a revenue generating team, versus a project that enables new features that we hope will increase our user base. Both are important, but the ROI time horizon is shorter for the first.

Suggestions for further reading:

• MOVE: How Decisive Leaders Execute Strategy