Define Manager Responsibilities (2019)

Define Manager responsibilities

Define Manager and Manager Responsibilities in 2019

The job of a manager, when done well, is often difficult and lonely. Those best suited for management positions, and who achieve excellent results in the long term, are individuals who genuinely enjoy enabling the accomplishments of others, are willing to speak up in difficult or controversial situations, and have tireless attention to details and organization.


Manager’s Most Important Deliverable

Manager’s Deliverable

As a software engineer, I always had a good, rewarding feeling seeing my code running in production. I knew that I had helped complete a project or ship a product. 


As I started to take on management responsibilities, a new sort of stress crept in. More than just, “Am I doing a good job?” I started to wonder, “How do I know what a good job is?” And, “What exactly am I doing, anyway?”


There’s an initial temptation to quell this anxiety by simply continuing to do a lot of work as an individual contributor—to keep doing your old job while you learn the new one. For me, this meant writing and shipping code.


For a little while, this makes you feel better and might seem like a solution. Over time, however, the pressures of doing two jobs simultaneously will break you. I speak from personal experience.


My first stint as a manager, at the local events search startup Zvents (later acquired by eBay), was as a “player-coach.” I continued to work as a senior developer while simultaneously assuming the duties of managing the web engineering team.


Not only was I recruiting, hiring, and managing a small team of engineers, but I was also writing and shipping production code under tight deadlines.


At first, I thought I was doing fine. We were keeping up with the development schedule, and everyone seemed as happy as they were before. There was more to do, and I was energized by the new role and happy to do it.


Over time, however, I started to make a few more mistakes—mistakes I normally wouldn’t have made. Bugs were slipping into my code, I wasn’t collaborating as effectively with others, and I certainly wasn’t on top of things with my team in the way a manager ought to be. In hindsight, it’s a little embarrassing I didn’t notice these changes.


I reached the breaking point—I prefer to call it an epiphany—one evening when I fell asleep on the train home and missed my stop. I’m a light sleeper and almost never fall asleep unless it’s on purpose, but on this occasion, I woke up a half hour later, groggy and confused, 15 miles from where I was supposed to be.


It was the first and last time it ever happened. At that point, I knew I had to choose—be an engineer or be a manager. You can’t be both at the same time.


Testing for Confidence

Testing for Confidence

Understanding your effectiveness in delivering confidence is critical.


As an engineer, you typically write unit tests to make sure your code is functioning as desired and to detect when it breaks. Think about the equivalent for assertions about confidence.


Your tests aren’t in code, but people. Who can you trust to tell you when people are concerned about a decision you make? What communication patterns can you establish to tip you off to a looming crisis of confidence? Regular one-on-one and staff meetings, if conducted correctly, are an important part of the solution.


Honesty is absolutely essential for you to maintain an accurate picture of your reputation in the company. In your one-on-one with your team, you need them to be open about any and all concerns they have, to alert you to problems while they’re small and manageable. Here some important ways to foster honesty and openness:


  • Don’t judge ideas when you first hear them.
  • Listen and encourage sharing.
  • Be honest about yourself and open up about important topics.
  • Remember details from previous discussions, to show that you take them seriously.


The same is true for team meetings, especially those with senior or more trusted staff. Your internal leaders should be your early warning system— they have the experience to detect issues before others and the willingness to inform you about them.


Staff meetings are particularly useful because one or more of your staff may have an inkling or partial indication of a problem, which, combined with the perspectives of the rest of your staff, forms a more complete picture. Again, honesty in your team is critical to your effectiveness. You need as much information as possible.


Warning Signs of Losing the Confidence of Others

Other than unexpectedly falling asleep on a commuter train, how will you know if things are going off track—if you’re losing the confidence of others? Here are some warning signs that merit at least further investigation.


People Try to Solve Problems Without You

Solve Problems

As much as it may be frustrating to hear about and deal with problems all the time, it’s much better than the alternative—that people are trying to handle them without your knowledge. As a manager, you’re the chief problem-solver for your team. If you’re not accomplishing that, and your colleagues don’t believe you can do it, you have a serious problem.


When there’s a major bug, service outage, or customer complaint, are you the first person to be notified? If someone on your team is facing a crisis, do they come to you first for help?

People should see you as an indispensable ally for solving tough problems.

solving tough problems

People Go Around You Similarly, it’s a sign of trouble when people cut you out of the communication chain. For example:


  • One of your reports goes directly to your manager for assistance.
  • Your own manager (possibly an executive) prefers to contact people on your team directly.
  • People in other parts of the company go directly to your team with questions or requests, skipping you.

In each of these cases, people have lost confidence in your ability to help them accomplish their work.


People Complain a Lot


If you start to hear an increase in complaints from, or about, your team, something's wrong. People who have confidence in you would come to you in a more open and constructive fashion. When they resort to complaining as a tactic, they’re skeptical that things will improve and are voicing this frustration.


People Stop Seeking You Out for Help

Successful teams are built of people who help each other, and the sign of a healthy organization is that these requests flow freely throughout. If people rarely ask for your assistance, guidance, or opinion, there’s a good chance you’ve lost their confidence.


Your Perception Doesn’t Square with Others

Things happen quickly and there are tons of factors affecting your business, so you may perceive things differently than others from time to time. If you find, however, that you frequently misunderstand important information, such as company strategies, upcoming initiatives, or success metrics, it may be a sign of a bigger problem.


If your perception isn’t consistent with others, or with the company in general, it may be that people aren’t making the effort to keep you in the loop. Dig into the issues and figure out what’s causing the discrepancy. Don’t accept this kind of inconsistency.


Your Manager Tells You

Finally, your manager might tell you directly about this issue. Obviously, this a serious situation, and you should consider taking whatever steps your manager recommends to remedy it.


Technical vs. Management Tracks: Helping Your People Grow

Management Tracks

In the early days of a startup, when there are only a handful of people and every one of those people is consumed with the challenge of finding traction with the product, there isn’t much time or need to discuss things like career development. It just doesn’t make sense to spend a lot of time talking about such long-term goals when the short-term future of your company is in doubt.


In early 2011, I was part of the founding team of Suitable Technologies, a robotics startup building a totally new type of technology. We called it a remote presence.


Our first product, a telepresence robot called Beam, was a remotely operated mobile video conferencing unit. By integrating multiple cameras, an array of microphones, sophisticated Wi-Fi roaming algorithms, a 17-inch screen, 8-hour battery, and a motorized base, we were able to deliver an experience that felt very much like being there in person.


The operator of the device enjoyed an immersive experience in a far-off location, with full freedom of movement and communication, and the people local to the device had a much more authentic interaction with the operator—far better than existing, stationary video conferencing solutions.


For the first 18 months of the company’s life, our small team was dedicated to shipping the first version of our product. Nothing else mattered. We all knew that unless we were able to demonstrate some viability in the marketplace, there probably wasn’t much of a future or an opportunity to build the next version.


Once your company reaches a certain size or stability, however, topics like career development become relevant and important. This development is typically a good sign for your company; it means that people see a true possibility of the company lasting for a long time, and having the opportunity to grow with the team.


It’s hard to say exactly when and how this shift will occur. Basically, an increase in the importance of career development in your company correlates positively with a corresponding increase in the chances of the company’s long-term success. When risk is high, career development remains an afterthought.


Growth Paths for Engineers

Growth Paths

A common mistake, made by companies everywhere, is to reward top engineers by promoting them into management positions. Though this may seem like an appropriate reward for your most productive people, it often backfires, for a variety of reasons:


  •  Great engineers love writing code. Changing their job in a way that takes them away from writing code may ultimately decrease their happiness with their work.


  • Once you’ve turned an engineer into a manager, it may be difficult to move them back to an individual engineering role without it feeling like a failure. This transition can be made successfully, but often is not.


  • Management is hard. Unless someone is truly committed to training themselves on the skills required and building up years of experience, they probably won’t be highly effective.


The risk, therefore, is that you take a productive, happy engineer and unwittingly turn them into a mediocre, frustrated manager who feels locked into a dead-end position. This characterization may sound extreme, but all too often it ends in people leaving a company to find a fresh start.


Why does this mistake get repeated so often? Promoting an individual contributor to a management position is the way many careers advance. For technical roles, however, it may not be the best choice.


Furthermore, engineers (especially the good ones) take pride in their ability to solve hard problems, so many of them will see management, if offered, as an interesting challenge to attack. Only after months or years of frustration will they learn that it’s not a job they enjoy.


Thankfully, other options exist. Thesis Scientist, like an increasing number of companies, offers engineers two distinct growth paths:

  • Technical leadership
  • Managerial leadership


Many companies recognize these paths with parallel tracks for advancement. Technical leaders set the examples and standards for professional work in engineering, whereas managers build responsibilities in maintaining the performance, morale, and growth of their teams. Both are necessary functions, and both become more highly valued as a person advances.


Many engineers may not want to be managers, but they absolutely care about career growth. Engineers want to build on their accomplishments, develop a larger role in making their team and company successful, and become leaders in their own ways.


In a small to a medium-sized technology company, it can be useful to illustrate the progression of each career path by example. In most cases, the technical path leads ultimately to the chief technical officer (CTO). 


A startup CTO is the most senior and respected engineer at the company, with a broad understanding of all development activity, insight into the future of the team’s architecture and technical needs, and the ability to lead the company’s most important engineering projects.


The managerial path, by contrast, typically leads to vice president (VP) of engineering. A startup VP of engineering is usually the manager of most, if not all, engineers in the company, either directly or indirectly.


In addition to managing people for top performance and retention, a VP of engineering’s top task is often recruiting and hiring talented engineers as quickly as possible, while also building a productive and sustainable engineering culture for the company.


The CTO and VP of engineering roles are complementary in many ways. By focusing on the unique aspects of each, the leaders in these positions can work together effectively to lead all aspects of technical development in a growing company.


In advising engineers on my teams about what career path might be best, and therefore what kinds of skills to develop, I’ve found it helpful to point to specific individuals as examples.


For example, I might ask, “In a few years, do you think you’d like to have a job like mine? Or maybe something more like our CTO?” By discussing the differences in responsibilities between these positions, we’re able to start charting a course for a person to make progress in the way they find most compelling.


Technical Leadership Paths

Technical Leadership

As junior software engineers get started in their professional careers, they typically are focused on learning from others and developing the skills to write clean, efficient production code. As they progress, some will look to take on more responsibility.

  • Technical leadership, as a function distinct from management, has many facets:
  • Setting an excellent example for other engineers to follow.
  • Establishing best practices for technical work.
  • Enforcing best practices and keeping an eye on the work of the broader team.
  • Mentoring other engineers, in an individual or group setting.


Anticipating future technical needs of the product and company. Researching and crafting potential solutions for those future needs.

Creating a strong relationship with other parts of the company. Ensuring communication is smooth and effective, both inside and outside engineering.


When speaking to members of my team, I sometimes summarize technical leadership as “making other engineers better.”


This type of technical leadership is the growth most engineers prefer—not becoming a manager. They enjoy the technical challenges of their profession and don’t want to leave them behind. Ambitious, successful engineers seek bigger and more impactful technical challenges, leading them to leadership positions.


At Thesis Scientist, the first step on the path of technical leadership is to become a lead engineer in one of our product teams. This role of leading a small group of (typically three to five) engineers boils down to two primary responsibilities:

  • Set a great example for the other engineers to emulate.
  • Make the other engineers better, happier, and more productive.


More specifically, we look for lead engineers to provide mentorship and guidance on all technical matters, to help define engineering best practices, and to ensure that these best practices are being followed in the team. Lead engineers should be thinking a few steps ahead about the technical challenges facing the team, preparing other engineers for upcoming projects or new initiatives.


We also expect lead engineers to be a strong ally for the team’s product manager. Together, the lead engineer and product manager work to scope long-term projects, prioritize tasks, and make sure the team has the information necessary to be successful. We look for all team members to contribute product ideas and business innovation, especially the leads.


One of the most important relationships we build at Thesis Scientist is the one between the lead engineers. Together, this group discusses and plans for all the important technical challenges faced throughout the company.


In regular meetings, the leads share experiences from their own team about what is working and what isn’t, ask for advice from other leads, and generally make sure we’re all on the same page about our top priorities, workflow, and culture.


Each lead engineer is responsible for taking this information about best practices, workflow, and tools back to their own team. They instruct their team on how to follow best practices, make use of new tools, and generally understand the guidance of the group of leads.


 In this way, we’ve avoided building a reliance on documentation, specs, long meetings, and other techniques that feel heavy-handed or bureaucratic, but have traditionally been needed to manage the organizational complexity of a growing team.


The independence and autonomy of our product teams is a defining characteristic of Thesis Scientist culture, and the lead engineers play a critical role in making this possible.


Managerial Leadership Paths

Managerial Leadership

An engineering manager still needs to be technical and have strong technical skills and intuition. Without these skills, a manager will have a difficult time earning the trust and credibility of their team, no matter how big or small.


I believe it’s useful for a manager to periodically test themselves on their ability to do front-line engineering work for their company, such as writing code that follows established standards, conducting code reviews, performing data analysis, and even pushing fully tested code into production.


Becoming a manager does, however, move an engineer into a less technical role, which is something that many engineers prefer not to do. The primary responsibilities of an engineering manager are no longer related to writing code, but rather finding and solving people-related problems, both now and in the future. Technical skill is critical for being able to do this effectively, but it’s no longer the main focus.


Countless blogs have been written on management itself, so I’ll just provide a quick list of the top responsibilities of an engineering manager:

  • Recruiting and hiring great engineers
  • Providing career advice and guidance for engineers
  • Finding ways to deliver high productivity from a team
  • Building a culture that encourages excellent work and high job satisfaction
  • Detecting and resolving performance and interpersonal problems


As a manager’s team grows larger, these responsibilities gradually replace technical contributions.

Engineering managers at Thesis Scientist are distinct from lead engineers. Managers are responsible for the people management functions for a group of engineers across multiple product teams. The roles of managers and leads are quite orthogonal. In fact, it’s entirely possible for a lead engineer to report to a manager, who is in turn part of a different team, following the technical direction of another lead engineer.


Combining Technical and Managerial Leadership

Managerial Leadership

It’s possible for one person to progress toward both technical and managerial leadership. However, such people are rare (and should be treasured!) and are much more of the exception than the rule. These people have executive potential and bright futures.


One common mistake to avoid, though, is to expect a manager to continue contributing as an individual engineer. Being an effective manager is a full-time occupation. Attempting to be successful as both a manager and an engineer, simultaneously, is truly an effort to hold two full-time jobs at once.


I speak on this topic from personal experience. In my first stint as a manager at Zvents, I thought I could continue to hit my engineering deadlines and throughput goals while also learning the ropes as a new manager, as did the company. Certainly, some hubris was involved. After a few mistake-filled months, I came to the inescapable conclusion that I could probably be a good engineer and a good manager—but not at the same time.


As engineers try to map out their future, I encourage them to focus on ­choosing a leadership path—technical or managerial—and see where it goes. Even if you’re interested in both aspects of engineering leadership, it’s best to concentrate on learning these skills separately, so you can acquire and understand the important nuances and details required to be successful.


Transitioning New Leaders

Transitioning New Leaders

It’s best to transition people gradually into new roles, especially when they’re as important and difficult as first-time leadership positions. It’s unnecessarily risky to thrust an engineer into any kind of leadership without some training, mentorship, or at least a bit of warning about what to expect.


Before starting any kind of transition, it’s also useful to share as much advice and experience as possible with your potential leader, so they know what to expect and can make sound decisions about their future. Here is some particularly useful advice to give in this situation:


This is a new role. This isn’t your old job plus a new one at the same time.

leadership position

Our expectations of you are going to change. You were chosen for leadership because we think you have the potential for even greater impact by working with others, so that’s what we’ll expect.


Please let me know if you start to suspect this role isn’t right for you. There’s no harm in moving back to your previous responsibilities, and it’s far preferable to do that than to remain unhappy and frustrated in the leadership position.


Continue setting a model example for other engineers. Now that you’re a leader, your team will naturally look to you for an indication of how to act and work.


Once you’ve had some earnest conversations about what to expect, and reached an agreement that this is a good opportunity for your employee, yourself, and the company as a whole, it’s important to develop a plan.


It’s not as simple as flipping a switch from engineer to manager or lead engineer. Sometimes external events will force your hand, but whenever possible, it’s best to gradually build new responsibilities, with several checkpoints along the way. Here’s a very high-level plan for transitioning engineers into new leadership positions:


Start with a partial set of the total responsibilities you plan to give someone. For example, with new managers, I first ask them to conduct regular one-on-one meetings with all engineers.


These meetings are a simple, easy-to-understand, and relatively low-risk function of management,­ and also help develop a good relationship between the new manager and their team. Finally, it’s a small first test of whether the manager enjoys the work and finds it a productive use of time.


Continue gradually adding more responsibilities. Each time you do, have an open conversation with the individual about whether they would like to continue the progression toward leadership.


Have an end date in mind. By this date, the transition should be complete. It’s important that the process not seem indefinite or undefined. Like any engineering project,­ you should track your progress and assess problems as they arise.



I’ve found, through years of conversations with thoughtful engineers, that most people are interested in career development, but often don’t have a clear idea of what’s possible or best for them. The high-level distinction between technical and managerial leadership is a great starting point for many engineers and can help shape productive careers.


As always, the right decision in any ­situation depends on specific and complex factors. There’s no substitute for truly getting to know the people on your team and thinking about what’s right for them, and you.


Tricks of the Trade for Engineering Managers

Engineering Managers

Managers in all disciplines face a wide variety of unpredictable and complex challenges. Compared to a role as an individual contributor, each day tends to be, to borrow a computing term, more interrupt-driven—you need to be ready for anything. This blog contains an assortment of tips, tricks, and advice for many of the situations likely to be encountered by technical managers and leaders.


What Does a Vice President of Engineering Do All Day?

Earlier in my career, I used to wonder what a VP of engineering actually does. I think it’s a fair question for people who have never held that kind of role. I would see VPs and other senior staff sitting in a lot of meetings, talking on the phone, and doing a bunch of other things that seemed less productive than writing code. What did they do what was so important? Also, what had they done to deserve that position?


Years later, out of the blue, a member of my team innocently asked me what I do all day. Now that I had become a VP, I could understand and empathize with his question. He didn’t mean it in a suspicious way; he was just curious. I realized he truly didn’t know how I spent my time, and that we could both benefit by understanding each other’s roles better.


Therefore, in response to an honest question, I was motivated to write an honest answer.

honest question

But first, some details about the team I lead at Thesis Scientist, for context:


  • We have 24 full-stack web and mobile developers.
  • Total company size is around 75 people.
  • Developers are divided into five (Scrum-like) product teams, each of which has its own product manager and designer.
  • We have new developers coming on board all the time and are always looking for more.


Overall, most of my activities fall into one of two categories:

Recruiting and hiring

  • 1. Recruiting and hiring
  • 2. Looking for ways for our team to perform better, now and in the future


And even those two functions are similar in that they’re really about helping other people with their own work. My day is more interrupt-driven than a typical engineer’s—I know, I used to be one, for many years. Several things can happen, at any time, that will make me stop what I’m doing and shift my focus. For example:


  • A new candidate shows interest through our recruiting channels.
  • I get new information about an in-process candidate.
  • A site performance issue occurs.
  • A new bug is reported.
  • Someone comes to me with a personal problem.
  • Someone comes to me with a problem with our team or company.
  • I detect a problem with our team.


Responsiveness is critical for handling these types of issues, so I’m constantly scanning for new ones. With that background, this is what I do all day. This day, specifically, was Tuesday, May 20, 2014, and a fairly typical one for me:


  • 7:45–7:50 a.m.: Quick e-mail check. Nothing urgent.
  • 8:45–9:30 a.m.: E-mail (and chat) time. Today’s topics:


  • Check in with our new hires who start next month — what do they need?
  • Review all new incoming recruiting opportunities (including 16 new resumes).
  • Chat briefly with a team member about the details of our web framework
  • Provide feedback to our recruiters about next steps for two candidates from the day before.


9:30–9:40 a.m.: Set up a meeting for the afternoon about a current project that has turned out much longer and more difficult than expected. Determine who needs to be there, the meeting format (Five Whys), and schedule it.


9:40–10 a.m.: Skim a large code review and comments for this project, which is nearing completion. More than looking for bugs, I’m looking to see whether we’re consistent in our conventions and patterns, whether I agree with our choices, and whether other team members are doing the same analysis.


  • 10–10:30 a.m.: Phone-screen a new candidate.
  • 10:30–11 a.m.: Eavesdrop on product team stand-up meetings while continuing to review code.
  • 11–11:30 a.m.: Continue code review, asking questions of team members along the way.


  • 11:30 a.m.–12 p.m.: Regular (biweekly) one-on-one meeting with a team member.
  • 12–12:20 p.m.: Go for a walk around the campus. Enjoy the sunshine and weather.


  • 12:20–12:50 p.m.: Lunch (casual, not a meeting) with a team member.
  • 12:55–1 p.m.: Meeting prep. Prepare the notes template, get the room set up, have all the material ready to go at 1 p.m. sharp.
  • 1–2 p.m.: Lead the full-team discussion about our troubled project.


  • 2–2:20 p.m.: Synthesize meeting notes to generate specific recommendations for improvement in future projects and circulate with the team.


  • 2:20–2:30 p.m.: Look at a new code review, on a project to start a migration to a new web framework. Try to understand the differences (and improvements) over our current system.


  • 2:30–3:30 p.m.: Do a final review of all peer feedback and notes for an upcoming­ team member performance review. Write up the review (overall assessment, strengths, opportunities for improvement, and goals), review our budget and finalize a decision on a raise for this person, and share with our CEO and director of people operations for review.


  • 3:30–3:45 p.m.: Phone call with recruiting staff at the University of Waterloo to clarify some details of their co-op program.


  • 3:45–4 p.m.: Read Hacker News.


  • 4–5 p.m.: Review new internal (such as marketing and support) projects with our COO and CTO to assess priority and discuss which teams could take them on. Discuss some of the challenges faced by these new teams, and what we can do to improve. Also, discuss the best way to bring our new hires onto the teams and generally learn how things are done.


  • 5–5:10 p.m.: Check in on the status of the code review and bug list for the large project.
  • 5:10–5:20 p.m.: Final review of e-mail and new recruiting candidates, mostly intern or co-op possibilities.


  • 8:30–9 p.m.: Review the latest version of our new company recruiting videos and provide feedback.
  • 9–9:10 p.m.: Review the details of a new candidate forwarded by one of our recruiters.
  • 10–10:20 p.m.: Chat with a former colleague in an effort to determine whether he’s interested in a position.


Not every day is the same, but this one seems pretty typical. It’s a great job and I love it, mostly because of all the ways I get to work with and help other people build great software.


Levels of Engineer Performance

Engineer Performance

I’ve conducted many performance reviews over the years, and the engineers involved have ranged from difficult and underperforming to superlative and delightful. No matter how well someone is doing, they always want to know how to do better—particularly when it comes to compensation, promotions, and overall responsibility.

Through these years, I’ve created and refined a simple model for evaluating engineer performance. It has four levels:


  • A mediocre engineer does what is asked.
  • A good engineer does what is asked, and does it well.
  • A great engineer does what is asked, looks for possible problems, edge cases, and overlooked issues, and solves those as well.
  • An outstanding engineer does all of the above but also tells you about problems you didn’t even know existed, and plans for situations you never envisioned.


To make it even simpler: How much can you improve the happiness and productivity­ of other people?


The most basic required skill for a software engineer is the ability to write code that meets requirements, is relatively bug-free, and relatively on time. To progress beyond a limited individual role, however, an engineer needs to learn to how to make things better for others.


By others, we might mean other engineers, who benefit from suggested improvements for their own code, learning about new techniques, or the enjoyment of working with a pleasant colleague. As an engineer, helping your colleagues fix bugs or solve difficult problems is always appreciated. Even better, help them find the bugs and problems, explain how you did so, and then help with the solution.


An engineer can also improve the productivity of nonengineering colleagues, such as product managers, designers, and testers. Even if they’re not writing code, you can still help them with whatever challenges they confront, such as designing new features, brainstorming future projects, or debugging part of a product. You might also build tools to help make them more effective.


Finally, a great engineer should push people in management and leadership to be better. These engineers bring not only ideas and concerns, but also suggestions and solutions. They constructively challenge their managers and others in positions of authority, helping improve the overall organization.


This model of engineer performance is a useful teaching tool. It helps explain what is required to be a successful engineer, and outlines what it takes to advance in an engineering career.


A Word About Promotions


I frequently encounter a misconception about how promotions are given. (Full disclosure: I first encountered this misconception in myself.)


People often overestimate the amount to which their company is observing their performance and assessing their potential. They believe that at some point, their manager will approach them about being promoted to a larger role, based on their ability to grow into that role.


In truth, promotions are usually given to people who are already fulfilling the duties of that larger role and haven’t yet been recognized formally for doing so. The promotion is more of a reflection of reality.


If you’re interested in promotion—and not everyone should be, as your current job may be the one you enjoy the most—the best strategy is to look for ways to start doing the job. It’s critical to do this in a constructive and helpful way, of course. Don’t try to steal responsibilities or decisions from others.


Prove that your team, and the company as a whole, will be better off if you’re in that new role and that you’re totally capable of being successful. By doing so, you make the decision to give you that role a no-brainer.


Upside-down Engineering Management

Engineering Management

Here are some ways to earn the loyalty and trust of your team.


Let an engineer try a new language or platform for their next project. Do they need to write a message queue and have always wanted to learn more about Erlang? Maybe this is a perfect time. Ask a developer to design a new feature themselves, rather than being handed a spec. Put them through the design review process to build an appreciation of what other team members contribute.


Put your staff in direct contact with customers. Trust them to represent the company’s interests and contribute to the requirements-gathering process. Different things will appeal to different people, but everyone wants to learn.


Grow Yourself

Grow Yourself

Be humble, and ask your team how you could do your job better. This requires an open, trusting relationship, so do everything you can to nurture that as well. If people trust you, they will not see this as an opportunity to take advantage of you. They will respect you for trying to improve.


You should also apply the same advice and encouragement you share with your team to yourself. Do you encourage people to read technical or business blogs as a way of developing new skills?


Share your own learning from blogs as you read them. Are you looking for engineers to contribute to open source projects or attend technical conferences? Find a way to participate yourself. Lead by example, demonstrating your own desire to grow, and your team will follow suit.


Fight for Your Team

Show that you advocate their interests throughout the company, whether it’s in terms of compensation, strategy, or culture. As a manager, you hold a critical and highly influential role in people’s careers. Demonstrate to those people that they can trust you to represent what’s important to them and their colleagues.

product managers

In my early days as a manager at Zvents, I began to perceive frustration on the part of several engineers at the way product requirements were delivered, which was typically in the form of a long, detailed spec document.


The product managers meant well. They were attempting to provide all the relevant information and instructions in a nicely packaged format so that it would be clear what needed to be done. From the engineers’ perspective, however, this approach had a few problems:


 No matter how detailed a spec was, some things were always missing. This is simply a fact of life in a dynamic, fast-paced environment. Having the spec in hand, however, created an expectation that an engineer should exhaustively process and understand it all before raising any questions, which added a lot of time and effort to handle small clarifications.


The spec was created with a finality that removed opportunities for engineers to be creative and add their own ideas to the design. Engineers don’t typically look to redesign everything in their own image, but still, enjoy being able to be part of the discussion. Specs get out-of-date quickly, creating a burden on the developer to verify the correctness of everything as it’s being implemented.


Reflecting these concerns, I began to push for some changes in our product development process. I felt it was necessary to speak up on behalf of the engineering team.


Thankfully, our product managers were supportive of looking for alternatives (they had their own set of frustrations with the process). With the support of other key staff and internal leaders, we began a process of experimentation and training that eventually led the entire company to adopt Scrum methodology.


While not perfect, Scrum was a major improvement for everyone involved (not just engineers), in terms of both productivity and job satisfaction. If you see people suffering, do something about it.


Be Proactive About Rewards

Be Proactive

Sadly, some of the largest raises and promotions are given to employees when they threaten to leave. This is, of course, the worst time for such a reward, as it means you already have a crisis on your hands. Don’t let it get to that point, as it may already be too late.


Treat your team like the precious resource that they are, and you will be rewarded in the long run. You should feel that your people are compensated fairly, at all times—not just when they bring it up or when problems arise. If you were to try to hire them today, what would you offer? Is it more than they’re currently receiving? Get that fixed.


When people start to wonder whether they’re fairly compensated, it starts a dangerous series of dominoes—talking to friends about it, maybe talking with a recruiter, interviewing with other companies, considering other offers— each one increasing the chances they might decide to leave.


Don’t let the first domino fall. Be proactive about compensation and rewards, so that it never even becomes an issue. Preventing Big Projects from Becoming Big Headaches


Has this happened to you?

Your team starts out with an interesting project. You know it’s a pretty big one, but not that big. You should be able to get it done in a few weeks or so, and it’s going to be awesome.


Things go smoothly at first. You’ve got high-level goals, scope estimates, and everyone pretty much knows what they need to be doing.


Fast-forward to your target ship date. Lots of new features have been added, mostly in the last week, bugs are piling up much faster than the team can handle them, and now the question isn’t whether you’re going to ship late, but rather by how much.


How did this happen?

That’s an easy question to answer: Life is complicated. Things happen. They always do. A better, and more difficult, question is this: How can you prevent this from happening next time?

Here are four specific techniques to prevent projects from ballooning out of control.


Break Things Down

Look for ways to break a project down into smaller, discrete pieces—not just conceptually, but operationally. Make sure that all project tasks have been decomposed into subtasks that take no longer than a day or two, and that team members report their progress just as often. Daily stand-up meetings are an excellent tool for sharing status among all members of a small team.


Ship Constantly

large project

Your team is making its way through a large project, which has been nicely broken down into discrete subtasks. You may still be setting yourself up for a big headache at the end, however, unless you’re also completing the release to production for each of these subtasks.


A group of many small tasks, each completed successfully but not deployed, can add up to a huge, monolithic changeset, a mega-merger, and a daunting code review. Ship all these pieces as you go.


If you do, your development codebase will never differ from what’s running in production by more than a day or two’s worth of work. This relatively small delta is valuable if you unexpectedly need to accelerate your schedule or make other changes.


Use Feature Toggles


The term feature toggle, or gatekeeper, refers to a software switch built into your code that allows you to activate (or deactivate) it at the desired time. Toggles have many benefits, but the key one for this discussion is that they allow you to ship your code before the whole project is finished. In order to ship your product constantly, you may need a tool to selectively activate new code as it hits production.


Shipping your code one piece at a time usually means you don’t want that partially complete code used until the rest is ready. With a toggle in place, you can ship your code incrementally, running each portion through your full set of reviews and tests. Once everything is fully deployed to production, you can then toggle your new feature on with confidence.


You probably don’t even need to write the code for your feature toggle. Many options already exist, for a variety of languages, frameworks, and platforms.


Keep Everyone Working on Only This Project

Over time, it becomes more likely that other projects, issues, and demands on people’s time will creep in. Try to make sure this project is the only thing on which your team is working until it’s done. The fewer projects that are in progress simultaneously, the more likely each project will be completed on schedule and with good results.


Finally, managing a large project requires vigilance. It’s easy, for both you and your team, to lapse back into what’s comfortable, easy, or convenient. Watch closely to see whether things are breaking down, and if so, why.

Or to put it another way: Ship early and often.


Managing People with More Experience Than You

Managing People

My first experience as a manager (at the local-events search startup Zvents) evolved naturally from being a senior member of a web development team. I could speak confidently and authoritatively on most matters affecting the team, and had the necessary experience to mentor and guide the other engineers.


My second management position, however, at robotics startup Suitable Technologies, presented me with a new challenge: for the first time, I was managing engineers with significantly more experience than me.


Though it adds some complexity, managing people with more experience is certainly something that can be done well. Here are some tips:


• Don’t deny the reality of the situation. Everyone on your team, including yourself, needs to see you and treat you as a manager. If you have any lingering self-doubt about your position, do your best to move beyond it.


• Don’t pretend to have more knowledge or experience than you do, in an effort to maintain authority. Be honest about what you know and what you don’t know, and ask for help from your team whenever needed. They’ll respect your self-awareness and desire to learn.


•  There’s a good chance that your senior engineers aren’t totally interested in being managers, or else they might already be in that position. If so, they’ll be happy to let you do your job, since they don’t want to do it, and they know that if you can’t, some of that responsibility may fall to them. They should be your strongest supporters.


• It is, however, important to understand whether any of your engineers do believe they should be the manager and whether they resent you being given the position.


The easiest way to find out is simply to ask. If this is the case, you should explain, and ultimately demonstrate, how your managerial skills will help them grow, and prepare them for opportunities in their own future. Pay special attention, though, to see whether they support you more over time.


In general, your approach to management should be the same, regardless of the relative seniority of your team. You’re looking to give people the tools, guidance, and environment they need to do great work. Managing experienced engineers is, in some ways, a special opportunity for you to learn even more and expand your own knowledge and skillset.


Leading a Team Without Deep Domain Knowledge

Leading a Team

Another new challenge of leading the software team at Suitable Technologies was that, for the first time, I was responsible for technical work that I didn’t fully understand. I had years of experience in web development, but now I was leading a team that was building robotics systems and video conferencing software.


This situation is similar to managing people with more experience, and the approach is basically the same:


  • Be humble. Don’t pretend to know things you don’t, and try to learn as much as you can.


  • Focus on providing value with your management skills. Your team will appreciate these contributions, as they care more about the product they’re building.


  • Provide mentorship and career guidance for your team. This is fairly independent of your technical domain. It’s fun to learn new things. Leading a team outside your field of experience is a unique opportunity to grow as both a manager and a technologist.


Lessons from a Case Study of Engineering Process

Engineering Process

As companies grow larger, they are forced to adopt additional layers of process and hierarchy to manage the increasing complexity of projects and relationships. It’s just simple combinatorics. The number of pairwise connections in a group of people grows quickly. The math looks like this:


C(10, 2) = 45 (or “10 choose 2”)

This equation indicates that for a group of 10 people, there are 45 possible pairs of 2. Notice how the number of combinations accelerates:

C(20, 2) = 190

C(30, 2) = 435

When you consider larger groups, it becomes even more alarming:

C(30, 3) = 4,060


For a company of 30, there are over 4,000 possible groupings of only 3 people­. This is where the process becomes necessary, in the form of documentation, meetings, specifications, standards, formal best practices, and so on.


These techniques, which are necessary to manage the increasing complexity of a growing team, are also what starts to make it feel like a “big company.” What one person calls to process, another person might call overhead or bureaucracy.


A critical tipping point comes when an organization is sufficiently large that not everyone knows everyone else. British anthropologist Robin Dunbar famously hypothesized that this point (now known as Dunbar’s number) is around 150 people, based on research comparing primate and human brain sizes.


Whenever it happens, reaching this size in an organization requires the adoption of more-formal organizational structures, titles, and communication patterns. Without a shared context between employees, it’s important to supplement their interaction with additional guidance and information.


Like many startups, Thesis Scientist strives to maintain the agility, dynamism, and rapid iteration of a small startup, even as we grow larger. Our journey isn’t yet complete (75 employees at the time of this writing), but we’re off to a great start.


This section describes some of the tools, architecture, and yes, a process we use to maintain agility and a “startup feeling” in our product development team.


Product Teams

Product Teams

The core building block of product development at Thesis Scientist is what we call a product team. Similar to Scrum, these teams are composed of a product manager, designer, and a few engineers. We believe strongly, as do most practitioners of Scrum, that the ideal team size is around seven people.


Each product team is focused on one specific area of our product. For example,­ at the time of this writing, we have five teams:

  • New Users (all unpaid use of our site)
  •  Premier Users (all paid use of our site)
  • Tutoring and Q&A Products
  •  Mobile
  • Internal Tools and Services

One of the most important aspects of our structure is that each team is given a large amount of independence and autonomy. As much as possible, we want each team to feel like its own seven-person startup (with one critical difference: the teams have secure funding). Each team has its own mission, list of long-term goals, metrics to track, and roadmap of upcoming projects.


The teams share some process—each team has a daily stand-up meeting, weekly status meeting, and a quarterly planning and vision discussion. We also strive for a consistent engineering workflow, which I’ll detail in the next section. But other than those things, the teams are free to come up with ideas and solutions that work best for them.


Development Workflow

Development Workflow

Each project, in each team, follows a consistent sequence of steps. The table lists each step along with the member of the team responsible for it.

Development Workflow at Thesis Scientist

Project Phase                    Phase Owner            

  • Requirements                             Product
  • Scope Meeting                           Product
  • Design Ready                             Design
  • Design in Progress                     Design
  • Architecture Review                  Developer
  • Development Ready                    Developer
  • Development in Progress            Developer
  • Code Review                              Developer
  • Final Testing                              Product
  • Launch                                        Product


Some steps may be quick, and others may take days or weeks. In all cases, though, each step must be completed, and there must be a person responsible for that step. In addition, some steps may need to be repeated. For example, if a problem is discovered during Code Review or Final Testing, the project might be sent back to Development in Progress as the team works to fix the code.


Scope Meeting

Scope Meeting

This phase is a meeting with everyone who is expected to be involved with this task, including the following:

  • Product owner for this task—a team member responsible for driving this task to completion, but not necessarily a product manager
  • Technical lead—a developer with appropriate expertise and experience, but not necessarily the one to complete the work
  • Design lead for this task—similar to tech lead, but for the front-end design
  • Anyone else who has a task assigned as part of the project, such as marketing or customer support

The purpose of this meeting is to review the requirements and provide an initial scope.


Thesis Scientist’s work estimates take the form of engineer days or designer days—the “real world” number of days required to complete the task, factoring in overhead such as bug fixes, code reviews, meetings, and everything else that isn’t writing code or generating designs.


These estimates must also be a Fibonacci number: 1, 2, 3, 5, 8, 13, 21, and so on. Ranges and other values are not allowed. (We require such a number to demonstrate that estimates are necessarily less precise as they grow larger.)


Design Ready

A project in this phase is waiting to be assigned to a designer. This phase gives designers visibility into their upcoming tasks and allows other team members to prepare for future work.


Design in Progress

At Thesis Scientist, the design includes not only the preparation of visual assets, but also user research and front-end development in HTML, CSS, and JavaScript. The Design in Progress phase has three subcomponents:


1. Research into the user interface and user experience design trends, looking for best practices and patterns

2.Development and iteration of storyboards, wireframes, mocks, and final messaging and content, including any user research on these concepts

3. Front-end coding and final asset production

The design is complete when the front-end code is finished and reviewed by at least one other designer.


Quality Assurance

Quality Assurance

Thesis Scientist has no full-time testing staff, so all members of the team share the responsibility to test our products. Projects in this phase are ready to launch but need to be tested, and should be running on one of our staging servers. The testing tasks may be shared, but final sign-off on the readiness of the project is the sole responsibility of the team’s product manager.



We made it! At this point, the work is running live in production.

Thesis Scientist puts every new project through an A/B test to verify that it’s an improvement on our existing product. Each test is unique, but we typically measure metrics such as the following:

  • Web traffic impact
  • Conversion rate
  • New user sign-up rate
  • Revenue impact
  • Bounce rate

If the test results look good, the final step is to optionally execute a communications plan around the new feature or product. For example:

  • Notify internal stakeholders or customers
  • Update customer support about the feature
  • Launch external marketing and communication


The project is totally finished when all communications, test analyses, and bug fixes are complete.


Thesis Scientist’s Engineering Principles

Thesis Scientist’s Engineering Principles

The Thesis Scientist product teams have a large amount of autonomy and independence and are free to solve challenges in whatever way suits them best. To provide high-level consistency for our engineering team, we’ve established a list of five engineering principles:


  • Ship Early and Often
  • Only One Project at a Time
  • Testing is a First-Class Problem
  • Communicate Openly and Frequently
  • Always Be Recruiting

Here’s a short description of each principle.


Ship Early and Often

A common pitfall of large projects (or even small projects that unexpectedly become large) is that by the time they are complete, the changes are so large that a huge amount of time is expended merging code, testing, and checking initial requirements.


Our preferred approach is to break a project into small pieces and ship those pieces to production incrementally. Here are some more specifics of how we do this:

  • Engineers conduct code reviews throughout a project, rather than waiting until the end.
  • As subtasks are completed, they’re code reviewed and merged with our master branch.
  • A feature toggle is used to allow partially completed projects to be shipped to production, but remain inactive until the entire project is complete, at which point we can simply “flip the switch” to activate them.


Only One Project at a Time


We try to resist the temptation to do a lot of things at once. Engineers should say no when necessary, or at least, “I’ll have to do it later.” We believe that an engineer should be focused on one task—whichever one is currently the most important—and give that their full attention and energy until it’s fully completed.


Testing Is the First-Class Problem

Testing is an important part of everyone’s job. For an engineer, testing your code is just as important as writing it. For a product manager, testing a product before release is just as important as doing market research and writing requirements. Testing should never be shortchanged because of other tasks, and test plans must be completed as part of a project.


In addition, it’s important to include the time to develop software tests in all project estimates. Don’t leave tests out in hopes that you’ll get to them later.


Communicate Openly and Frequently

We believe strongly in the DRY (don’t repeat yourself) principle, especially at the team level. Before implementing a new library, component, or widget, ask around to see whether there might already be something similar that could be used.


We encourage all team members to leverage their team to the fullest—to ask for help when they get stuck, or to clarify something that’s confusing. A simple question can save hours of work and headaches.


Always Be Recruiting

As a company in constant growth, we want everyone to share a recruiting mindset. You never know where an opportunity might arise, so it’s important to be attentive and proactive.


We strive to make every candidate’s experience at Thesis Scientist an excellent one. Even the people not directly involved in our recruiting or hiring process should be welcoming and friendly to all visitors they encounter at Thesis Scientist.


Every person, not just job candidates, should leave our office thinking, “I really want to work there.” Even if we don’t end up extending an offer to a candidate, they might share their experience with others.


Finally, having a recruiting mindset means thinking critically about how to make Thesis Scientist the ideal place for you to work. We don’t want to settle for what’s good enough right now. What will help us attract the best and brightest for the future as well?


Pair Programming

One of the most important ways we try to build a culture of collaboration at Thesis Scientist is through the use of pair programming.


Our definition of pair programming is any situation in which two engineers are working on a problem at one computer, and only one of them is controlling the keyboard and mouse. We don’t force people to pair but try to encourage it whenever possible. The benefits are numerous:


Pairing is an effective way for engineers to learn from each other. For this reason, it’s typically best to let the less-experienced engineer control the computer. Otherwise, they may have a hard time keeping up.


Pairing catches a lot of bugs. Having an extra set of eyes on a problem can save a lot of time spotting problems, and working next to another engineer tends to make people more careful too. Pairing can be fun. Working on a hard problem can feel less intimidating or frustrating when someone is by your side.


Pairing is an excellent way to converge on common coding standards and best practices. This kind of informal information sharing is a beneficial side-effect of working on projects together, and the more pairwise combinations you foster in your team, the faster you’ll achieve consistency of thought.

Many people are reluctant to try pair programming because they think it will decrease a team’s throughput by half. The benefits I’ve described, however, often outweigh any short-term delay and lead to great productivity improvements in the long run.