Collin Greene

@collingreene

Manager lingo for engineers

A while back I changed from an engineer to a manager.

With that came a whole new set of manager-y words that I had previously nodded along with but not deeply understood. This article is my definition of these concepts in a way engineer-Collin would understand.

Preamble

Engineers build¹ a $thing. Managers build the team that builds a $thing.

Everything revolves around each groups respective focus, including the vocabulary.

Conversation around software engineering is rooted in detail: scale, design, trade-offs. The manager-side equivalent are more abstract but revolve around: team direction, health, output, etc.

As an engineer I remember hearing these terms primarily during planning or review season.

Vision

Vision is the version of the future you want.

Roadmap

The near-term manifestation of the vision, made concrete. Comprised of projects or tasks.

Mission

The underlying purpose of a team, project or company. Doubles as a heuristic to determine if a given project/goal/task should fall to a given team. It defines the edges of your team or problemspace.

Impact

Impact is the effect you and your team have on the company/world. Revenue, cpu cycles, engineer time saved, monthly active users, data breaches avoided, etc. The magic of software is that high impact projects are often scalable.

Influence

The ability to excite, convince or motivate. Often used in service of selling a vision because big ideas are rarely achievable solo. An engineer convincing other engineers to join an effort is utilizing influence.

Vision++

Vision is one of the most interesting concepts, and one I struggled with, so it gets extra attention.

Again, vision is articulating the version of the future you believe should exist. It is often a big bold sort of pronouncement.

Vision is inherently anti-detail. This is because it defines the ends, not the means. This can be uncomfortable for someone who likes to wallow in the details, or who immediately starts thinking of ways something could go wrong.

Vision must be succinct. Like a joke if you have to explain it it has failed.

By the end of the decade, we will put a man on the moon.
– John F. Kennedy, 1962

A computer on every desk and in every home.
– Bill Gates, 1980

We will sell our excess compute capacity
 — Jeff Bezos

These are audacious ideas that are easy to get excited about, possible to define success for and succinct.

Vision is useful even if its unachievable, ex: We ship zero security bugs, ever.

Vision by no means has to come from the manager, it often bubbles up especially with some encouragement.

A clear vision has strong downstream benefits:

Seeing a SpaceX employee assembling a large part, he stopped to ask him, “What is your job at SpaceX?” He answered, “The mission of SpaceX is to colonize Mars. In order to colonize Mars, we need to build reusable rockets because it will otherwise be unaffordable for humans to travel to Mars and back. My job is to help design the steering system that enables our rockets to land back on earth. You’ll know if I’ve succeeded if our rockets land on our platform in the Atlantic after launch.” The employee could have simply said he was building a steering system for landing rockets. Instead, he recited the company’s entire “Mission-to-Metrics” framework.

Ali Rowghani

Vision is a top level concept, from which roadmap, projects, tasks all derive.

The most interesting instances of vision, and the most difficult, is recognizing a future that has never existed. Its much easier to bring an idea you have seen work to your current company. E.x: Facebook had a great built system, lets get something similar here.

Conclusion

As an engineer your manager owes you their own definitions of the above concepts with plenty of examples to illustrate. To further understand your manager check out some good writing on the topic.

These are just my definitions for these terms right now, I am sure they will drift and change over team. I would be interested in hearing how others think about these.

Footnotes

  1. Build is a stand in verb for conceive, design, build, ship, maintain and are generally responsible for
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!

More by Collin Greene

Topics of interest

More Related Stories