How To Be a More Influential Engineer

Heads up, we’ve moved! If you’d like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog

Spoiler alert: you need skills.

One of the most significant transitions for an engineer’s career is when they break dependence on senior team members and start to actively contribute to the team’s decision-making process. Once this transition is complete, the engineer is contributing to the team at levels far more significant than the code they can sling. They become a more productive team member and help unlock team potential by freeing up others’ time and effort. How do you get there? By developing certain leadership skills, and practicing them smartly through a framework we’ll discuss.

Do I need to learn these skills now?

As every senior engineer will tell you, the longer your career, the more you understand that technology is rarely the “hard part.” People, processes, working within teams, prioritizing and sequencing work, are what will trip you up.

Every engineer will go through this learning process at least once. This point of your career is when it becomes necessary to internalize that your job is mostly about people and only partially about technology. The skills presented here are broadly applicable, but are best applied if you find yourself in the following situations:

• You have technical ownership of a subsystem, service, or some other domain on your team. But, work is decided by the product manager, business analyst, tech lead, or some other person who has more responsibility but less knowledge about that specific area than you do. This leads to inefficiencies, because work is scheduled out of order or scoped incorrectly.
• During ritual team planning meetings, you are bored or disengaged because you aren’t going to be able to influence what you or others work on, so you just wait for your name to come up and give your updates / receive your assignments.
• Feedback from team members ask you to take a bigger role on the team. Help plan the roadmap! Take more project ownership! Be a leader on the team! Get those ideas that you have on the roadmap and make them happen! You would — but you are too busy or you don’t have the opportunity to change the roadmap.
• You have specific domain or technical expertise that you aren’t able to fully apply on your team. You aren’t given the space or authority to make that happen.

So what are these skills I need?

When you find yourself in this situation, it’s not because you’re not trying hard enough to make an impact, or that you lack the willpower to be an effective member of the team. The problem here isn’t effort or desire, but knowledge. You need a skill set and a plan to grow said skills — with that, you can accelerate growth into the next level of effectiveness. Let’s break the skill set down:

• Clear, Written Communication
• Meeting Facilitation
• Prioritization
• Breaking Large Projects Down
• High Level Estimation
• Dependency Management
• Work Stream Analysis

Clear, Written Communication

This is probably the most underrated skill for technical leaders. Quality of communication impacts the speed at which information is absorbed, the number of errors that happen in translation, the cost of context switching, and more. Investing in this skill means writing better design documents, disseminating experience reports, communicating via email, writing better tests and code documentation, and generally expressing your point of view in the most direct, clear manner possible.

• Good writers write. Good writers read. Engage with the written word and keep going, even (/especially) if you think you are a bad writer. You will get better over time.
• “All the arts depend upon telepathy to some degree, but I believe that writing is the purest distillation,” says Stephen King. An important element of writing is transference. Your job isn’t to write words on the page, but rather to transfer the ideas inside your head into the heads of your readers.
• Vonnegut recommends that writers “use the time of a total stranger in such a way that he or she will not feel the time was wasted.”
• A former colleague, Xaviar Shay, recommends “On Writing Well”, a great book that focuses on the basics. Starting with these foundational building blocks will help you fight off that overwhelming (and inaccurate) feeling that you’ll never be a good writer. Do the small, simple things and you’ll improve each day.

Meeting Facilitation

To become more influential on your team, you’ll need to bring people together to make decisions, spread information, solve hard problems, and get on board with your ideas. Meetings get a bad rap — because so many meetings are poorly executed. Work to create only engaging, productive meetings.

• First, challenge the ritual. Meetings can be rote and boring, making participants feel like they are going through the motions without actually achieving anything. Recurring meetings are rife with this.
• Start with low-stakes meetings and insert change in small ways. These can be stand ups, IP meetings, retrospectives, etc. — each of which are important but often become mechanical and uninteresting. Inject some enthusiasm and test your chops as a facilitator. For example, you can change standup to be a follow the baton, not the runner format. Or introduce a fun but informative Question of the Day. Bring Boba for your team as a treat and a sugar rush to up the level of energy. Whatever it is, change with intention.
• Seek feedback, especially from team members that facilitate lots of meetings. Try your hand at being a facilitator. When the meeting is complete, ask your colleague for feedback on how the meeting went — and use that feedback.
• There are many resources for how to be a great facilitator, so start looking! Two of my favorite books on this are “Agile Retrospectives” and “Visual Meetings”.

Prioritization

As you take on more responsibility, you’ll have increasing influence over what work you do. You’ll need to differentiate the most important work from the “nice-to-have” work and the work to defer for now. The difference between a product that users successfully use and warrants continued investment, and a never-done black hole of time and effort, is prioritization.

• Recognize the core value proposition of the product or feature you’re working on. Your product manager (or some similar counterpart) should be able to help you here, but what they don’t know is what the codebase will support.
• Always try to provide as many technical possibilities to the product manager. This often looks like a list of approaches, with pros and cons, and a time estimate attached. This allows the product manager to get the true value of the product at the lowest cost possible.
• Avoid starting work on a feature with blockers (that is, features or projects that need to get done but you won’t do yourself). Having multiple projects work in parallel and launch at the same time has low success rates. The good news: this constraint actually makes prioritization easier, because you have fewer possibilities to consider. Be honest but firm when setting expectations about the order in which things need to get done.
• Recognize your own biases and actively counter them. Engineers tend to want perfectly engineered solutions, to the detriment of scope or schedule. It is okay to put out a MVP that isn’t a full technical solution. If you can limit the usage of the feature, have a shut off valve (like a rollout flag), or can otherwise ensure technical soundness of the solution, use it! Shipped software is infinitely more valuable than software being written.

Breaking Large Projects Down

As you establish yourself as someone who can take more responsibility, you’ll be asked to tackle bigger, more undefined projects. These can be assigned in as little as one sentence (e.g. “Add a calendar for business to manage their clients.”) that translate to multi-week projects. Your task as the engineer is to take that short description and splay it out into a well-defined set of tasks.

• Start with a list of questions — maybe it’s in your personal notepad, maybe on a whiteboard, maybe in an a electronic document intended for others to consume at a later date (especially helpful for projects that are going to be bigger than just me working on it). One by one, dig into the questions. Often they’ll generate more questions, but eventually you’ll have a manageable set of unanswered questions that you can work through after you start the project.
• Task things out in layers, but completely. As you learn more about how to do the work, you can start to think in broad categories: this project will require database changes, UI changes, a new service, some data migration, etc. These will help to shape the scope of the work and give you areas to further vet. Once you decide that one of these categories is a necessary part of the project, you can dig further and task them out. Go as granular as you want. I like to get down to the level of one-day-or-less tasks.
• Read the code! When you’re breaking projects down, don’t be afraid to go to the code as a source of truth. This isn’t supposed to be an exercise in memorization. Use the code as a way to tell you what is actually happening. Play around with mini-spikes that help elucidate the deeper requirements that will spin out better, more detailed tasks.
• Be careful with descoping. You don’t want to spend too much time on rabbit holes that you won’t actually be building in the project, but you also don’t want to ignore areas of the project that may be important and become icebergs of work. This balance is a bit of an artform, but my rule of thumb is to ask a level or two of questions to test my assumptions about a rabbit hole. For example, for the assumption, “the database already has all the fields, so I shouldn’t need to change anything”, I can test it by fetching the data I need from the existing codebase, and transforming it in the way I need for the project.

High Level Estimation

Engineers early in their career often build the muscles of estimating how long a particular task will take. They provide feedback, and this feedback is usually taken into account at the sprint level, fitting stories into the week or weeks of scheduled planning. Agile and similar methodologies discourage doing detailed planning for periods of time that are on the order of months. There are good reasons for this, but as an engineer helping to make decisions, it is important to give these high-level estimates for long-term planning purposes.

• Always, always make sure that your stakeholders know that high level estimates are always wrong and should only be used to do medium-to-long term planning, where accuracy of estimates are less important than the general shape of the work.
• High level estimation comes with nuance and high variability. It is the job of the engineer doing high level estimation to inform and burn into the mind of stakeholders these realities. I may say that this project you are asking about will take 3 months, but my assumptions are a, b, and c. Even if all those assumptions hold true, there is a high likelihood that I’m still wrong.
• The process of doing high level estimation should be to gain a rough understanding of the product requirements, create a mental shape of how many things this product will change, add up the complexity of that, and translate relative complexity into relative time scales.
• Another interesting nuance of this process is that the answer should always come in the rough form of person-weeks or person-months. A four person-week project may not actually take four weeks to accomplish if parts of it can be worked on in parallel.
• Many other skills complement this skill in isolation. Being able to do good dependency identification, analyze potential work streams, and knowing how you might break a project down into smaller deliverables would all help inform more detailed, nuanced discussions of high level estimates.
• Risk analysis can be an important tool to understanding the relative variability and the information that you need to share with your stakeholders. Yet another CRUD app may be low risk and low variability, but a project requiring skills that the team does not already have (e.g. a new platform) could be fraught with risks. Use risk analysis to identify and communicate those.

Dependency Management

When you work on larger projects that touch many things, dependencies become a significant factor in the success of a project. Learning how to identify and measure risk for each of these becomes a key skill. Dependencies on outside teams, analysis, design, or engineering work can really slow a project down and put it at risk.

• Start with what you know: what are the engineering systems that you will depend on and how much control do you have of them? Can you contribute to them at all? Can you create reasonable alternatives to them or find workarounds for them? For example, you may identify that your project requires a new API from a team at the same company. Depending on your working relationship with that team, you may or may not be able to influence them to make changes. Either way, make sure to bring it up as a risk and talk through ways to mitigate it.
• The best way to mitigate risk of dependencies is to eliminate them. For example, if you find yourself in a position where you are waiting on the design team to get back to you on how they want the project to work, you might be able to get away with building a not-well-designed stand-in as an MVP. Even if the user experience is poor, you can get some valuable feedback from the intended audience of the feature and get a walking skeleton out the door that the designs can build off of instead of starting from scratch.
• If you cannot eliminate risk, increase communication. Set up regular check-ins, drop by to ask how things are going, send status reports about your work, grab coffee with the team you are working with, sit next to them, share Slack channels, pair with them. Do whatever it takes to make sure that you are both getting and giving the information that needs to be shared to make the project successful. My favorite example of this was when we were working on a project that dealt with a complicated legal relationship with an outside entity. We were needing to work through our legal team to make sure that everything was going to work out okay. Because of this, we invited a representative from the legal team to our stand ups, planning meetings, and design meetings. She was able to provide the information we needed so that we didn’t have to go back and forth on email for days with legal, but instead got the information right when we needed it.

Work Stream Analysis

Given a bunch of tasks for a single feature, we can often separate out the work for individuals or for team members to do the work in parallel. Understanding work that can be done in a different work stream that doesn’t step on each other’s toes can accelerate the delivery of a feature. For big projects, this is essential so the project doesn’t take months to ship.

• Understand the interdependence between small tasks. Do these two tasks touch the same database? Does one task depend on a task created in another? Are there service boundaries that you can take advantage of? Getting a strong grasp of this is key to making sure that tasks are good to run in parallel.
• Use a tracer bullet to build a super slim slice of the work that others can then go build on. This can be something as simple as just displaying the name of your record in the database on a webpage. You can then start to add in more fields, more domain logic, actions that can be done on the record, etc.
• Define your interactions up front. For example, you could define the JSON structure of an API and split the work up between the client and the server. Be careful, though, because this can often be the road to integration disaster. You should prefer tracer bullets, or building the API first and then building the client, but you can use this in a pinch, or if the work is well defined and very small.

A step-by-step way to build skills, trust, and influence

The list of skills needed to make this transition can be daunting—it’s a lot to learn. But each of these skills are additive: you don’t need every single one of them to improve yourself as an engineer, and it isn’t necessary to be an expert in all of them at once to overcome the plateau and start making a larger impact.

Skills, though, aren’t the only thing that you need to be effective. You need to build trust and influence within your team; people should be looking to you to participate in high-value team decisions and that doesn’t happen just because you have the skills needed. If you haven’t established yourself as a trustworthy source for this information on the team, you may not be included in the decision making process.

And, finally, even with skills and trust, you have to make the decision to consciously step into the role of greater responsibility and impact. The rest of your team should know you want to and you should ask for their support, mentorship, and feedback as a part of the process.

So, here is a framework (not the only framework, just a framework) for achieving your goals, and then we’ll break these down:

• Start with intent
• Pick one tool
• Find mentors outside of your team
• Regularly review progress
• Build trust

Start with Intent

Work with your manager, tech lead, product manager, or all three to set intentions that you’d like to be involved in these team decisions. If you are new to this, state your recognition that you are learning and are approaching this with a beginner’s mindset. If you believe you have the requisite skill set, explain you think you can contribute but that you’re open to learning and feedback (and mean it!).

• Your team members have a vested interest in making you the most effective colleague you can be. Don’t make them guess at how to help. By being explicit, you enlist your team in your own growth and goals, and they help to support you in those.

Pick One Tool

Try to focus on one skill at a time. For example, you could pick meeting facilitation and ask if you could run the next roadmap discussion or planning session. Focus on that one thing and see what you learn from the process.

• Focusing on one tool makes the challenge less daunting. And, because each of these skills are additive, you are incrementally improving yourself as a team member with each new skill that you add to your repertoire. You’ll get experience in other things along the way, which is great, but keep your specific goals focused on one at a time to maximize growth.

Find Mentors

Find mentors outside of your team. This can be people on adjacent teams, or people outside of your company entirely. Lean on them for ideas, approaches, and learnings from their experiences.

• Mentors can come in the form of discussion groups, books, learning or networking opportunities outside of work, etc. Keep your head on a swivel looking for new sources of information and connection.

Regularly Review Progress

This can be in 1:1 settings, feedback discussions, or during coffee breaks. Actively seek out feedback and ask for specifics on the tools you are working on and the level of trust you’re trying to build.

• Feedback is an important tool in accelerating learning, especially when you are attempting to learn new things or stretch yourself. Others have the benefit of an outside view and some of them have gone through your same struggles. They can provide insights and potential shortcuts.

Build Trust

Build trust through humility, servant leadership, and by calling your shots. Find the ways you can be most helpful. For example, if you have specific knowledge of a particular technology that isn’t widely known, talk about your experience and what you think may affect estimates. Call your shots. You’ll be wrong, but you’ll also be right as long as you hold yourself accountable.

• An example of this might be during high level estimations. “Feature A will take two weeks to build,” you say during the meeting. When it takes five weeks and the team is retrospecting it, call yourself out and mention what you learned. “Wow! I thought this would only take two weeks, but all of the edge cases really extended the work. I’ll try to be really diligent about edge cases in the future!” This accountability helps rather than hurts your credibility. Team members will recognize your fairness and desire to improve.
• Humility is really important, even if you aren’t just learning the ropes of the tools. You might have less context on the domain or the problem than others, and being cocky isn’t just off-putting — it can destroy trust.

The combination of these skills and this process in your repertoire can increase your influence—and thus your contributions to your team, the product, and others’ careers. You can drive product and engineering changes that you feel passionate about. As you build trust, you’ll be given more opportunities to make decisions, which will then build more trust. It is a virtuous cycle.

As these skills are honed, more opportunities will arise. It isn’t just about how to be influential on the team, but instead where you want to be influential. Do you want to be a technical leader? Do you want to help design and build the architecture? Do you want to be a product focused engineer? Do you want to dig deep into tough challenges that no one else has the patience for? All of these are futures opened up by laying the foundation of influence and trust within your team.