Career advice, interview tips, and more resources for job seekers. Hired is a career marketplace for the world's knowledge workers. Starting with in-demand tech and sales roles, we’re bringing together job seekers with the companies who want to hire them.
We all know that software products require code to make the magic happen. But what people often forget is that the code is a product of its own. It constantly needs to be interpreted, changed, updated, added to, and sometimes even cut out and marketed for its stand-alone value.
There are a fewexamples of code quality checklists out there. I’ve taken the liberty to simplify and create my own:
Impactful: The code must deliver something to a user group that helps the business.
Clear: Humans who are not the author have no problem understanding the code.
Efficient: The code does as little as possible to achieve the desired output.
Well-Tested: It stands up to a battery of well-thought tests at each layer of performance.
Extensible: Developers have no problem adding features without issues.
This is great philosophy, but this article is about practicality. How do you achieve high-quality code based on these standards? Here are 4 key steps:
Set Team Guidelines
Communicate and Motivate
1. Set Team Guidelines
It is critical for code quality that standards and uniformity are maintained. Start with widely-accepted language standards. Discuss best practices for how to write human readable (or self-documenting) code, and create a guide with your team.
Make sure there are clear expectations for sharing work. This will reduce chances of duplicating efforts. It also creates a space where code reviews (either as a team or peer-to-peer) are much easier to do, lifting the skillset and the code quality of the entire team.
As a product manager in my heart, I argue this is the most important test. Yes, the product manager should only be asking for impactful software to be built. However, if the end product of the code doesn’t meet the needs of the user, it just isn’t worth worrying about code quality.
3. Review Regularly
These reviews should cover the code as a forum to learn as a group what to model their code after and what practices to avoid. They should also cover the style guide and the sprints as a way to constantly iterate the processes that are supporting writing high-quality code.
Set up a buddy system with similar level engineers or mentorships with senior and lower level engineers. Using both of these systems will keep attention focused on code quality, lift the overall skills of your developers, and lift the overall code quality of your team.
Refactoring can be difficult to perform regularly, but what it the point of studying code quality without implementing it? The best way to refactor code is to do it constantly and little-by-little. For a more in-depth look at refactoring check out Code Refactoring Best Practices: When (and When Not) to Do It.
4. Communicate and Motivate
Prioritize Aspects of Code Quality
Not all code will score 100% across all the metrics of code quality. Make sure you communicate with your team on every project to ensure everyone knows the priorities and expectations around code quality.
Drive Understanding to Non-Software Stakeholders
Like it or not, the people we build software for do not know how software works. Make efforts to educate outside of the software group about the risks of bad code. Drive the company culture to one that values the time, process, and benefits of maintaining high quality code.
While working on iOS at several companies in the Bay Area, one of the most effective and transferable skills I’ve learned is how to accurately estimate my projects.
It’s easy to estimate the minimum amount of time it will take to build a feature, but it’s much harder to estimate when that feature will actually launch after delays, code reviews, and other processes. The latter is a much more important metric for yourself and your team.
When you first hear about a project, the last thing you want to do is guess how much time it will take. You may argue that you’ll finish it sooner if you don’t spend the overhead estimating, but unless you work for yourself (and don’t have any external dependencies or deadlines), the benefits of time estimation are worth the time spent on it.
You will be able to better prioritize and plan your projects, and people who depend on you will have a reliable time frame in which to expect your completed work.
Initial time estimation
I like to follow a linear process of estimating, using both top down estimation for an initial ballpark figure, and bottom up estimation to confirm the validity of the broad estimate.
Top down estimation
When you estimate top down, you think of the project as a whole. This involves thinking of previous projects and past experience, along with your gut, to make a general estimate.
If someone thinks of a new feature during a meeting and asks you, impromptu, how long something will take, you’re going to be engaged in top down estimation. It’s good to make this initial estimate, but since you have no details on it, it’s generally inaccurate.
That’s why, once you’ve made this estimate, it’s good to delve into a little more details.
Bottom up estimation
This kind of estimation involves breaking down the project into the smallest possible pieces, and estimating each piece individually. For example, if you’re supposed to add autocomplete to a search field, maybe you want to think of the following chunks:
Adding autocomplete network API request – 1 day
Adding UI popup to display autocomplete results – 1 day
Integrating network results into the view – 1 day
Sometimes this step involves spending some time making prototypes or researching some libraries that can be utilized.
Once you get this estimate, compare it to your top down estimate and work out any inconsistencies, if any. It’s likely your bottom up estimate is more accurate, but thinking about this can help you make better quick top down estimates in the future.
Buffer time estimation
Once you’ve gotten some more detailed time estimation, it’s time to make sure you add some buffer. How likely are you to get blocked on each item?
One thing to note when you’re estimating your days is that you may not spend the entire day coding. There are code reviews, meetings, interviews, breaks, emergency bug fixes, and whole host of things that can come your way each day. If you have an 8 hour day, maybe it’s best to estimate around 4-6 hours of coding each day, depending on your usual overhead and other obligations.
After I estimate, I normally add about a 30% buffer to my projects. If I initially think it will take 10 days, I’ll add another 3 days to make it 13.
If I’m in a new codebase or using a language I’m not familiar with, I’ll add a buffer of much more, sometimes even doubling an estimate since I’ll be spending lots of my time getting up to speed.
As the project goes on, it’s likely that unexpected thing will still come up and invalidate your initial time estimates. If you added some buffer beforehand, you should be fine, but it’s smart to still go back and make sure things are still on schedule. If your buffer wasn’t large enough, it’s better to communicate that earlier than the day before it’s supposed to be finished.
Review your completed projects
One of the best things you can do to improve your time estimation skills is to reflect on each project that you complete. Look at when you started, when you finished, all the roadblocks along the way, and see how accurately you estimated those during the project. You may see patterns emerge that you can take into account and explicitly mention to your team next time you are estimating.
Becoming a manager is a challenge for anyone, no matter what type of team they’re leading—and, between a tendency towards introversion and a high level of talent, a team of engineers can be particularly testing. Whether you’re diving headfirst into a new role as a manager or looking to brush up on your management skills, it’s worth taking some time to set yourself up for success, which includes understanding some common stumbling points for new engineering managers.
#1: Expecting to be great on day one
Part of the difficulty of managing a team is that—unlike in many other roles—there’s no textbook solution for being successful. Unlike when working with computers, people can be unpredictable and respond differently to the same management styles. So it can be particularly difficult for talented software engineers to come to terms with the fact that they might not excel at management when they first start—and that’s OK.
Instead, think of your new role as an entirely new function… one in which you can bring your engineering expertise to bear in order to be more effective, but which also requires skills you might not already have. Think of each day as a new test, and make the process iterative, trying new things to see what works with which team members and feels natural to you. In addition, involve your team in the process—make it clear that you’re new to engineering management and ask for their regular feedback.
#2: Misunderstanding the skill-set required
While individual contributors typically move upward within an organization by honing their technical skills, managers are judged by their teams’ effectiveness—and fostering this requires a wholly different skillset. Management skills are generally on the softer side, so it can be a particularly tough transition for engineers accustomed to being evaluated on hard skills.
Start to process your role as manager through the lens of a coach. Coaches put their team members in the right position, encourage them to perform to their maximum potential, and positively reinforce things that are going well while creating an open space for healthy debate. So rather than focusing on your own engineering expertise, think about to ways to encourage individual improvement as well as team cohesiveness and collaboration.
In addition to being common, wanting to manage every aspect of your team’s work is perhaps one of the hardest things to avoid for new managers. Good managers take responsibility for mistakes their team members make, so it can be tempting to want to check each and every piece of work that gets put out—but that’s rarely the best use of any manager’s time.
The temptation can be especially strong for new engineering managers, who were likely just days or weeks before writing their own code. In addition to adding stress to your plate, micromanaging can create a toxic team culture and distrust between you and your direct reports. Instead, consciously check in with yourself about how overbearing you’re being (one good gauge of this is how much coding, or code review, you’re doing), as well as soliciting feedback from your team about your management style.
#4: Using meetings ineffectively
Don’t be fooled into thinking that being a manager is all about setting and attending meetings. In fact, spending too much of your time in meetings—and not knowing when to turn down meeting requests—can lead you to neglect other higher-priority responsibilities.
When it comes to meetings you own (1:1s and team meetings), consider your team’s structure, priorities, and working styles to determine how to make these meetings most effective. These meetings can easily turn into simple status updates, which can feel more like a rote obligation than a valuable use of time. Instead, find alternative ways for team members to share progress updates, and use 1:1 and team time to focus on what’s not working and tease out potential issues before they occur.
When it comes to meetings requested from other parts of the business, don’t blindly accept an invitation just because you’re new to management. Question whether you’re really the right person to be in the meeting, what you’ll add, and whether there’s something else that deserves more of your time. Rather than getting in the habit of working through meetings (which can also create a bad impression if you’re not paying attention), be firm about how you allocate your time from the beginning, and others will come to respect those boundaries.
In today’s mobile first world, proficiency in mobile design is no longer optional for businesses. Almost everyone browses the web on their phone and relies on mobile apps to keep them on track. Whether you build websites or software applications, creating a mobile-accessible version of your work is absolutely necessary in order to reach your audience and make your content accessible to the general public.
If you work for clients, they will naturally expect a mobile version of everything you create. All websites must be mobile accessible and any software that wants to become popular should have a mobile app that provides at least basic functionality. However, extending your features to mobile design is only the beginning.
To become a hit with the mobile population, you’ll need superb mobile design as well. Here are five key mobile design tips for front-end developers.
1) Simplify UI Features
First, start by paring down the UI features that fill your usual website or software.
On a full-sized screen, you have plenty of room to offer both horizontal and vertical menus. Floating UI elements, side-bars, and pop-ups are the norm. But for mobile design, it’s important to remember just how small phone screens can be.
You want your UI clean and easy to navigate, which means offering users a small and simple number of options. Everything else can fit tidily into the ‘hamburger’ menu that will take the place of your horizontal and vertical menu bars.
2) Direct Focus with Negative Space
Another reason to simplify your UI is to provide plenty of negative space.
On a small screen, UI clutter and images that span to the edges of the screen seem cluttered and unwelcoming. Instead, direct the focus of your users to quick and easy captions with ample negative space.
Negative space is easier on the eyes. It helps guide focus, letting mobile users know exactly what they should be looking at and what the next step will be.
3) Provide Large Buttons
There are many ways to create buttons in mobile design and you may be tempted to directly translate your desktop software design into your mobile design.
But there is one major difference between UI of the two side-by-side: Buttons are larger for mobile designs.
The reason for this is finger size. Because most mobile users don’t walk around with precision device pointers, they rely on fingers, and a fingertip doesn’t have a pin-point of contact. Large buttons ensure that your user can click on exactly what they meant to without feeling like they should have children’s hands by missing the buttons.
4) Foster Intuitive Navigation
In the years since mobile phones became a permanent extension of modern professional hands, certain standards have been established.
Users expect to navigate by swiping right or left; zoom by ‘pinching’ or ‘spreading’ with their fingers; and clicking with a double-tap.
Make use of this response with features that will be used instinctually by every regular mobile user who accesses your site or uses your app. Integrate the responses that are already second-nature and your mobile design will blend smoothly into customer mobile experiences.
5) Ensure Scalability
Last, but certainly not least, is that your design is scalable for any type of mobile screen.
Not all mobile devices have the same screen size. In fact, both the size and aspect ratio vary wildly between tiny phones to large phones, small tablets to huge tablets… and it keeps changing as new devices are released.
Your design elements need to detect what size screen they are on and adjust accordingly. Expert mobile design includes elements that can resize and rearrange themselves to use the screen size most efficiently.
Designing a great mobile website or app is all about understanding the user experience. Follow these guidelines and look back to your own mobile experiences to understand why each aspect of mobile design matters so much.
While behavioral interviews will always have a place in evaluating soft skills, take-home coding challenges have become very popular components in technical interviews over the past decade. And even though there’s plenty of information available on how to do take home coding challenges, the method in which employers develop a challenge is sparse.
Because every role and company is unique, there’s no precise formula for constructing a take-home challenge, but these general tips will get you started.
Define Goals Up Front
Is there a particular skill you are trying to assess? Are there multiple capabilities the candidate must have? Are you particularly interested in how they respond to specific tasks?
Begin with the end in mind; . Eestablish clear expectations on what it is you are trying to evaluate. You might also make sure these are aren’t already covered in other elements of the interview process. That will allow you to remove redundancy and get the most actionable information from the process.
Here are some things you can learn about candidates through a take-home coding challenge:
Can they write code? (Yes, this should go without saying. But, unfortunately, sometimes it doesn’t.)
How do they approach a problem?
What do they do when they get stuck?
Are they methodical? Aggressive? Meticulous? Experimental? Cautious?
Do they leave documentation that aids in collaboration?
Do they run QA tests?
Are they reflective?
Make Results Quantifiable
Keep in mind some of these skills you’re measuring might be subjective: “Candidate knows React” is not a binary outcome. Create an interviewing scorecard so you will be ready to measure candidates and fairly compare their result on architecture, clarity, code quality, UX, or whatever criteria is applicable. Laying out the success metrics up front will make sure you aren’t compromising when you reach your decision process.
Make it Applicable to Your Business
Candidates are trying to evaluate you as much as you are evaluating them. Show them what it is like to really work there with a realistic example of something they might incur in the job.
Many companies will fork an existing repository and allow the candidate to build a feature on top of a real product. Others will provide a description of a real problem they faced (or are facing) using real or mock data that relates to their business. No matter what you do, be sure to provide the candidate a clear README with context of the business as well as the problem they are working on.
Remember, you‘re trying to understand how a candidate thinks rather than if they can completely solve a problem.
A multiple-step-solution should ensure that missing one step doesn’t hinder the candidate’s performance on what follows. This approach will result in a better outcome for them and a more clear picture of their capabilities for you.
Consider a Soft Skill Requirement
An important element of the process is understanding how the candidate will interact with others on the team. Bake in some time for them to walk you through their work.
Why did they approach the problem a certain way? Can they verbally present their process in a clear and concise manner? How do they handle questions from others?
All these things can help you further ensure the candidate is the right cultural fit for your team/company. It also may help to prevent a false-negative by learning why they approached the challenge in a particular way (maybe they discovered a better approach than you thought possible!).
Most anyone could solve a problem with enough time, but in the real world, deadlines abound. You want candidates who can quickly think on their feet. Impose a finite period of time for the challenge.
A common way to do this is to send the challenge with a specific due date and time. The amount of time should be reflective of what is expected for the job and depends on the challenge.
Keep the work needed to be done under 8 hours (that they do not need to do consecutively.) You want to be respectful of their time and make it fair. After all, they’re still evaluating if they want to work for you as well!
A few years ago, I found myself facing a good problem: the team of software developers I manage–and the internal proprietary software system we’ve developed–had grown to the point that we clearly needed a bug tracking system to help us with productivity and workflow.
I turned to a popular open source system, Bugzilla, but quickly realized that I needed something more sophisticated. In addition to tracking bugs, we needed a way to prioritize tasks, identify who was working on what, determine how long things were taking, and what was preventing tasks from being completed.
I knew we couldn’t be the first development team to have these problems and didn’t need to reinvent the wheel. This is when a search for proprietary bug-tracking software led me to the world of agile software development.
Agile Software Development
Without realizing it, our cross-functional team had already gravitated towards an agile approach, which emphasizes:
Agile software development promises to address the sorts of issues we run into as a team: changing user requirements, evolving time constraints, and uncertainty in user satisfaction.
Two common frameworks in agile software development, Scrum and Kanban, both seemed equally valid, but certain aspects to kanban appealed to more to me both on professional and intuitive levels.
What is Kanban?
kan + ban
(visual) + (card)
Kanban, which translates in Japanese to “billboard,” is a visual approach to tracking work as it moves through a process.
It started with Toyota in the 1940’s when a shop-floor supervisor, Taiichi Ohno, identified a need to track and manage the process of putting an automobile together on an assembly line.
Ohno eventually became the founder of the Toyota Production System, known for its efficiency in productivity by minimizing waste. In his kanban model framework, line workers moved a literal card across columns to signal to team members that a task was completed and ready for the next step. When there was a bottleneck in the pipeline, it was immediately visible to the team. Instead of waiting around, team members jumped in to keep things moving.
Kanban helps you answer the question:
How can I optimize my team so that the requests coming in are getting through the pipeline?
The most simple setup for a kanban board can be defined by three categories:
One of the things I immediately found appealing about kanban is its visual approach to project management. Like 65% of the population, I’m a visual learner– even those who aren’t still process visuals 60,000 times faster than text, according to research complied by 3M (the company behind Post-it).
It helps me to get the “to-do” list out of my head and onto a board I can look at. Because software development is inherently “knowledge work,” it’s essentially invisible. Kanban allows teams to visualize the knowledge work that otherwise exists in our minds.
While the manufacturers at Toyota looked at a literal, physical board, our remote team uses a virtual kanban board on Jira.This allows the team to have shared access to the board and, for a bunch of people who spend most of their work time in front of screens, it was the easiest format to integrate.
Benefits of kanban
The most helpful thing about visualizing the work process, as the Toyota line workers discovered, is that bottlenecks become obvious. An agile team includes members who specialize in one area of development but can adapt and jump in when a project is stuck in another area. Using our digital kanban board as a collaborative group, team members can shift from a productive area to a bottleneck, where the team is getting stuck.
A key for managers using kanban is to establish with your team that once a task is in the pipeline, it won’t get pulled.
Developers work best when they can achieve a state of flow and hate it when they are pulled off a task without getting to see it through completion. You get a loss in efficiency when you determine a task needs to be done in five days, get developers working on it, and pull them off during day three to change to something else.
Because tasks get through quickly with the kanban method, managers can change priorities and shuffle the order in which tasks go through the pipeline without interrupting developers. Developers, then, get the satisfaction of knowing the tasks they are assigned to will be seen through to completion.
Who will kanban work for?
Kanban will work best for cross-functional teams who have…
Evolving user/customer requests
The ability to deliver software iteratively
Management who is open to changing the development process
Get the most out of kanban by ensuring you have…
A leader who will continually re-prioritize the line-up of pending tasks without interrupting those already in the pipeline
Daily stand-up meetings (or shared-screens) in order to visualize the work (this is how a team becomes self-organizing)
Achievable WIP (work-in-progress) limits: there should be a limited number of tasks in progress at any given time, with no new tasks being started until the WIP is completed
Like implementing any change, when you first transition your team to the kanban method, expect some slow-down and delays as everyone adjusts. Some of my developers were enthusiastic about the new method, some were neutral, and some were completely uninterested.
While some individuals on a cross-functional team might believe it’s a waste of time for them to participate in the kanban efforts of tracking tasks and participating in stand-ups, remind them that the group will move faster in the long run. Kanban honors each team member’s time, skills, and talents equally, reminding your team that the whole is greater than the sum of its parts.
As an iOS developer and productivity junkie, I’m always on the lookout for tools that can streamline my workflow. The following is a collection of software tools that I repeatedly find myself going back to while working with top-tier tech companies and startups in the San Francisco Bay Area.
xScope is a great tool for making your apps look pixel perfect. Use this to get distances, measurements, colors, and other things design-related.
I use xScope to inspect both designer mocks and the UIs I’m creating on the iOS Simulator. The Rulers, Dimensions, and Loupe are my most used tools. Just make sure your Simulator and any design mocks are in a “Pixel or Point Accurate” mode so the numbers reflect what you see in the code.
This HTTP debugging tool is essential for viewing the API traffic going to and from your app. The learning curve for Charles isn’t always easy, and the interface isn’t great, but it is an extremely powerful tool.
Sometimes I’ll get assigned a new feature that isn’t fully specced out, and instead of asking everyone for the structure of the endpoints or what endpoint is hit on a certain page (which can be error-prone and out of date) I can load up the app and see for myself.
It’s also a great tool to make sure your HTTP requests are formatted as you expect. Most of this investigating can be done using breakpoints within your IDE, but depending on how complex your networking code is, it can be much easier and faster to get the information you need within Charles.
If you need to debug loading indicator bugs or other networking dependent app functionality, Charles can simulate a slow network as well.
Follow two steps to use Charles for secure traffic on iOS:
Enable SSL proxying for the locations you specify under Proxy > SSL Proxying Settings
*Keep in mind: if you have Charles running while you try to access a website with the same base url as the API you’re using, your browser may block you since it will notice a man-in-the-middle attack (which is you using Charles).
Once you find the endpoints you want using Charles to sniff and watch all the traffic, you can use Postman to test the requests outside the confines of your app. It’s nice to test out the endpoints you’re using to make sure they work as expected. You can make all the different kind of HTTP requests and more.
Use it to keep track of parameters, add auth headers, save endpoints for future use, share endpoints and payloads with teammates, and lots of other features to help you organize all the API endpoints you’re dealing with.
Next time someone sends you a URL endpoint that you usually put in your browser, put it in Postman instead, and you’ll get way more information. You can set up authentication keys to simulate everything just like a user from your app.
You can save previous requests, so if you see something broken on your app, you can load up Postman and make sure the server is working correctly before you even look at the native code. You know it’s always the server’s fault, but with Postman you’ll have proof.
*If you have direct access to a database, this might also be where you check the database with software like Sequel Pro to make sure your flow is working before you start to build the UI on a broken server flow.
Productivity ToolsSmartGit (or other Git GUI program)
As much as I love the command line, a Git GUI program is essential for checking over your changes before you commit them. I really like SmartGit because it has a great side-by-side comparison where you can see the file exactly as it was before and after your changes. You can also do one-line reverts and other changes within SmartGit as you’re reviewing all of your changes.
Resolving conflicts after a rebase or merge is another time when a Git GUI program can make your life easier. Often, you can go directly into the code and find the conflicts via angle brackets, but SmartGit provides a 3-way compare view where you can see “theirs,” “yours,” and the combination that you can edit right there in the software, giving you full context on why the conflict occurred.
As you’re developing, you’ll often need to share some flow or animation with other people on your team. For screenshots you can always ⌘+S on the iOS Simulator, but for videos you’ll need some extra software. Gifox is an easy way to make quick, short animations and send them to your teammates to show off a bug you’ve found or feature you’re developing.
I use them for most pull requests to share the before-and-after of the flows I’ve changed. It’s a great way to share updates with your product designer and other team members to make sure you’re on the right track.
Giphy Capture is another great free gif creation tool, but I find is has slightly more overhead in saving, which makes me prefer Gifox for shorter videos.
Most tech companies grow engineering managers from an individual contributor through a manager track. If this was your path, then you already know: engineers are motivated by shipping impactful projects.
To keep your software developers productive in a way that is measurable, use a two-pronged approach: optimize for impact while maintaining quality.
Maintaining quality means thinking long-term, being accountable, and making sure your team is healthy and happy.
Optimizing for impact means focusing on your roadmap in order to drive growth (or other important metrics for your company).
3 Ways to Maintain Quality
Vision: think long-term
Keeping your engineering team productive starts with a clear vision. What is the long-term impact your team wants to achieve? When your engineering team is on the same page with the vision, you can delegate decisions and trust your engineers with more responsibilities. The vision is also a great way to show your team’s purpose and how it fits into the needs of the company.
Accountability: focus and prioritize
Focus: As a manager, it’s your job to keep the team’s focus aligned with the vision. This may sound obvious, but most companies have a hard time focusing their engineering teams on the right projects. That’s because companies traditionally measure high-level financial metrics, but lack visibility at a team level.
At an individual level, engineers should be empowered to keep their focus on current team projects. Encourage individual engineers to keep a daily or weekly priority list that they can share with the team and stakeholders.
grouping similar tasks into certain times of the day
turning off notifications (Some companies have WFH Friday or No Meeting Wednesday to allow engineers a whole day uninterrupted so they can fully focus on complex tasks.)
use goal automation software like WakaTime to promote working on the right things and allow engineers to own their own productivity
Prioritization: Teach your team to prioritize, so they spend time on projects that advance towards the vision. If a project doesn’t get you closer to your vision, it gets pushed down the list to make room for more impactful projects.
Responsiveness: identify problems early to keep the team happy
An easy way to increase developer productivity is by removing roadblocks with developer tools such as Sourcegraph, which make developers more effective at their work, thus increasing morale. Reasons engineers are unproductive may include:
lack of focus
lack of prioritization
You can identify low productivity through metrics and weekly one-on-ones. Then, work with your team to solve any issues. This means taking time to refactor parts of the codebase that are difficult to maintain. Your senior engineers will most likely notice other struggling engineers before you do. Guide and enable them to help their fellow team members through mentorship.
Effective Ways to Optimize for Impact
The way you measure your team’s impact and productivity within the company is with metrics. While quantified-self metrics like WakaTime measure velocity, impact is measured by experimenting or A/B testing product changes. Tracking metrics your team can directly affect is how you measure the extent to which your team accomplishes its goals.
When your team improves it’s metrics, you should see a proportional improvement in the company’s higher-level metrics. Now you have a way to measure the impact of each team based on how much they move the needle on the company’s metrics.
Drive career growth
Providing a path for your engineers to grow keeps them engaged and productive.
Build management vs engineering tracks each with similar levels of challenges and similar rewards. This way senior engineers can choose a management track or still advance their engineering career without being forced into management.
An engineering manager’s duties include growing and replenishing your team’s headcount. You can’t infinitely retain team members, and keeping team members working on the same thing for too long only leads to burnout.
Managing your team’s resources for future work and planning ahead with smart hiring keeps your team fresh and productive. Always be selling your team’s vision to candidates and other engineers within the company who are looking for a team transition.