Define Manager and Manager responsibilities
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 a tireless attention to details and organization. If you’re not naturally this type of person, people management may not be the ideal role for you.
Contrary to what you may see and hear from a lot of people, a manager is not most effective when telling everyone what to do. When you’re responsible for creative professionals, the best results come from creating the environment, structure, and process in which those people can flourish, and then trying to stay out of the way and remove obstacles.
Another favorite move of the busy manager is to schedule a 1:1 for 15 minutes or less. It’s the best I can do, Rands. I’ve got 15 people working for me. First, those 15 people don’t work for you; you work for them. Think of it like this: if those 15 people left, just left the building tomorrow, how much work would actually get done?
Second, if you’ve got 15 people working for you, you’re not their manager, you’re just the guy who grins uncomfortably as you infrequently fly by the office, ask how it’s going, and they don’t actually listen to the answer.
You’re trying to build a team of people you can trust to do great work, which is why recruiting and hiring are so critically important. To achieve scale and speed in your organization, you simply must hire people you can trust, and then give them as much autonomy as possible. These people don’t work for you; you work for them.
Your Time Is Less Important Than Theirs
A good manager is obsessed with removing obstacles and time-sinks. In many cases, this means taking on tasks that would ordinarily distract people on your team. To fully embrace this mission, you should adopt the attitude that your time is less valuable than the teams. Although not strictly true in all cases, this philosophy will give you a useful perspective on how to best spend your time.
The typical workday of a manager is different from an engineer’s in a few important ways. First, it’s full of interruptions and context shifts. Whenever someone has a problem, you’re there to help, no matter what you were already doing. Second, a manager usually talks to more people, more frequently, than an engineer. The job is largely about communication.
Finally, a manager is a pressure release valve for issues building inside a team. By coming to you first, people can head off more destructive outcomes that interrupt the workflow of the larger team.
These differences make a manager better suited for handling a lot of tasks that affect a team. By spending a few minutes resolving a personal conflict or bureaucratic process question, you can save engineer hours of interruptions, learning about things in which they have no interest, and dealing with frustration.
Perhaps it’s not totally accurate to say that your time is “less valuable” than your team’s, but that the time you invest in certain tasks is returned many times over in what it saves your team.
As Thesis Scientist’s Engineering and Design team have grown past 25 people, one thing that hasn’t changed is that I, the VP of Engineering and Design, still screen all resumes and conduct our first-round phone screens. Although it’s appealing at times to farm out these tasks, and I know our senior staff would pitch in without complaint, I continue to resist the temptation.
Screening resumes are arduous, unending work. As soon as you finish one batch, more come in, and unless you’re motivated above all else by the excitement of meeting new people and hopefully bringing them into your team, it will wear you down. I love building a team, and even I get fatigued by the process from time to time.
Asking for help starts innocently, but before long could create a burden that’s stealing hours a week, taking your best engineers away from the work they love, and sowing seeds of frustration. For these reasons, I plan to continue handling the front end of the hiring funnel for as long as possible.
You Care About Helping People with Their Careers
Career development is one of the most important functions of a manager. Creative, thoughtful people want to make progress, learn new things, and work toward goals, and it’s your job to help them. Furthermore, not everyone knows exactly what they want or where they’re going, and you need to help them chart that course as well.
Being effective in career development requires many skills. Chief among them are: Being a thoughtful listener; possessing and being able to discuss relevant experience; and attentiveness to peoples’ goals and potential opportunities.
You absolutely must be a good listener—to have the patience to hear and discuss a person’s goals and thoughts and give them the consideration required to be useful. Don’t interrupt and don’t start giving advice until you’re confident you’ve gotten to the bottom of an issue. If you quickly tire of hearing what other people want or need, management may not be for you.
It’s difficult to advise others on their careers if you don’t share their experience. How can you properly advise them on important choices if you’ve never faced similar ones? Your own path from engineer to manager or leader is a critical teaching point, and you must be comfortable using your experience to educate and advise others.
Furthermore, your credibility as a mentor will be limited if your employees don’t trust that you have the proper experience to guide them. Sharing relevant stories and information about your career is an important way to build the confidence of your team in your abilities as a coach.
Understanding a person’s goals is only the first step. Next, you must find opportunities for them to make progress toward those goals. Do you have an engineer who’s been aching for a chance to move into mobile development? Remember that the next time you have a position open on your mobile team. Has someone been hoping to add front-end skills? Suggest an upcoming conference or workshop that would help.
Being a manager means constantly trying to match people with the correct opportunities and projects. You’ll never make perfect choices, but in order to make the best ones possible, you must remain attentive and mindful of your people at all times.
If you’re only able to talk about career growth, but never able to follow through on it, you’ll eventually lose your team’s faith. Career development isn’t just a discussion of an abstract set of goals—it’s the realization of those goals through real-world projects and responsibilities.
You’re Not Afraid to Correct Behavior
When you see something being done the wrong way, or people behaving inappropriately, are you comfortable being the one to step in? Or would you prefer to wait and hope the issue resolves itself, or that someone else takes care of it?
As a manager, it’s your responsibility to handle problem situations. You shouldn’t be looking for confrontations, but neither should you run from them. Your team is counting on you to know when and how to correct incorrect behavior.
You need to do the dirty work
Although you may have to deal with difficult tasks in the short-term, such as coaching an employee through an improvement plan, terminating a poor performer, or conducting a layoff, you should see clearly that these actions benefit the team and company as a whole. If you can’t convince yourself of that fact, then either you’re not suited for management, or the plan itself is flawed.
These sorts of tasks should be painful. If you actually enjoy firing people, you’re probably also not suited for management. You’re dealing with real people and significant consequences—it should be difficult to deliver harsh feedback or tell someone their job is gone. Only the conviction that your actions are necessary should push you to make these difficult choices.
You Can Trust Others
An effective manager must be able to delegate responsibilities and tasks to others. In some ways, your effectiveness as a manager is the sum (or product) of the actions of your team, so the more you can delegate, the more leverage you get.
Because managerial time has a hierarchy of values, delegation is an essential aspect of management. The “delegator” and “delegate” must share a common information base and a common set of operational ideas or notions on how to go about solving problems, a requirement that is frequently not met.
Be sure to know exactly what you’re doing, and avoid the charade of the insincere delegation, which can produce immense negative managerial leverage.
It takes time to learn when and how to best delegate work, but the first prerequisite is an ability to trust others to do things that you could yourself do. Without this trust, effective (or in Grove’s terms, “sincere”) delegation is impossible.
One useful approach to delegation is to look for ways to make yourself redundant. By creating the ability in others to accomplish your tasks, you free yourself up to work on other, higher-value projects. And by contrast, those who feel threatened by making themselves redundant (because it diminishes perceived job security) are not management material.
It can be a bit uncomfortable to trust others with tasks you can do, especially when you, as their manager, will be judged on the results. Don’t give in to the temptation to jump in and handle it directly—rather, trust your training and monitor progress from a distance. Get involved only if you see things going wrong.
Over time, this trust will be rewarded, as you build a team that can handle not only the tasks you used to do, but a variety of others as well.
You Like to Garden
One of the best metaphors for management is gardening.
To grow a garden, you start by preparing the ground and planting seeds, but if that’s all you do, your results will be disappointing. A thriving garden requires constant care, attention, and small adjustments. Just like gardening, effective management requires patience and diligence. Cutting corners rarely work, and the results correlate strongly with the amount of effort put in.
The seeds of your garden are the people you hire. The soil is the team structure, process, and culture you instill. You must regularly water your garden with one-on-ones, discussions of how to improve things, and events that build team relationships.
Every day you should be looking for signs of disease, over-or under-watering, or any of the myriad other dangers that can befall your team. And the harvest, when you ship your product, is a time for celebration that your diligence and hard work have paid off.
Just as you can’t grow a potato in a week, no matter how badly you want to, you can’t rush things as a manager. Short-term sprints are useful when used sparingly, but if you don’t want to strip the soil—burn out your team—you’ll save them for true emergencies.
You Obsess Over Details
If you miss something important that affects your performance, that’s a problem.
If you miss something important that affects someone else, someone for whom you’re responsible, that’s a catastrophe.
The people you manage depend on your ability to represent their interests, further their careers, and, by extension, improve their lives. That’s a lot of pressure. If you let them down by making simple errors, you’ll quickly lose this trust, and probably feel pretty bad about it too. The best managers double- and triple-check their work, and they learn techniques and tools to help them. These techniques often involve the copious use of noted blogs, calendars, and various types of productivity software.
You Care About Accomplishments More Than Friendships
In many ways, being a manager is a lonely job.
One of the most difficult parts of being promoted to a manager, from within a team, is accepting that you can no longer be friends with those on the team. Your priorities have shifted, and your primary responsibility is now to get the best results out of your team—not to be buddies.
As a leader, you now represent the company to the people on your team. Your actions reflect the culture, mission, and goals of the company, and your people will see you more as a company representative than as an individual. This loss of identity can be difficult to accept.
In some ways, becoming a manager means losing a lot of friends. No longer can you commiserate with your team about decisions with which you disagree or make jokes at the company’s expense. You always have to be “on” in front of your team, showing your best and most professional side. Furthermore, they don’t want to hear about your problems. It’s hard to empathize with your boss.
Your friends are now the other managers at your level—and there aren’t nearly as many.
Personal Experience: First-Time Manager
My first experience as a manager was at local events search startup Zvents (later acquired by eBay), where I was promoted from web developer to manager of the front-end engineering team. Like a lot of first -time managers, I was more confident than I deserved to be. I thought, “I’m smart; how hard can it be?”
Needless to say, I faced a lot of challenges during that time, but one of the biggest changes I had to accept was the relationship change between me and my former colleagues, now my reports. I had a lot of fun with the other engineers. We worked hard, but also joked around, teased each other, and spent time together outside the office.
We also shared our successes and failures. Shipping big releases was a bonding activity. More importantly, when we found bugs and other problems, we didn’t point fingers or try to find someone to blame. Instead, we shared the responsibility of coming up with a solution. When the VP came over to tell us the site was down, we buckled down and fixed it together.
After I became the manager of the team, though, that changed. Now the VP came to tell me, specifically, when there was a problem. Being friends with the other engineers was now secondary to delivering results.
I couldn’t commiserate about things like company decisions we found silly since it was now my job to keep morale up and motivation strong. And it was hard to have fun and goof around when I also knew that I would have to judge peoples’ performance.
This shift was hammered home for me, conclusively and permanently, when I first had to help the company prepare for a layoff. In some ways, laying off an employee is harder than firing them, because it’s less about their performance and more about the companies. It’s an admission that the company, and—by extension—you, have let them down in some way by failing to succeed as a team.
Zvents, like many startups, went through some ups and downs. It reached a point where our burn rate was too high and we simply had to bring costs down. My role in the layoff was small, but it left an indelible mark on my management philosophy.
I came to realize that my commitment to help people succeed in their careers and to make our company successful are more important than friendships and that I would be letting my people down if I didn’t act accordingly.
This experience, and others like it, that I faced while receiving my education in management from the School of Hard Knocks, had me frequently questioning whether management was the right career choice for me. Ultimately I decided that it was, and I have loved my work ever since, but I wasn’t totally prepared for the challenges and decisions I would have to face.
Manager’s Most Important Deliverable
Management work, as compared to engineering work, is abstract and challenging to define precisely. In this blog, we’ll discuss the ways in which a manager adds value to an organization and how to assess a manager’s performance.
People moving toward management in their careers often develop a sense of unease about their contributions. This is natural.
While it’s fairly straightforward to see and understand your output as an individual, a manager’s work product is harder to define. Making peace with this ambiguity, and understanding the subtle ways in which you have an impact, are critical steps in becoming an effective manager of people. In many ways, what you’re delivering—to your team, your manager, and your organization— is confidence.
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.
What I now understand, years later, after many lessons learned both the hard way and the easy way, is that the primary deliverable of a manager—the most important thing a manager can produce—is confidence.
This means different things for all the people you interact with.
Your team is confident that:
You have their best interests at heart.
You give them the timely information and tools they need to succeed.
You help them grow as people and professionals.
You protect them and advocate for them, insulating them from the distractions of corporate politics.
Your manager is confident that:
You get good results from your team.
Your team acts and behaves consistently with company goals and practices.
Your team is happy and satisfied with their situation.
You provide adequate career development for the people on your team.
Everyone else in the company with whom you interact is confident that:
You’re doing the things that the company needs you to do, and you’re doing them well.
You’re a valuable person to have in the company.
Recognizing that your deliverable is confidence makes some things easier—In particular, determining how much value you’re adding. Are these statements true, for your team, manager, and colleagues? If you think they are, how sure are you?
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
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.
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.
Summary: The Value of Confidence
Getting great results from a team requires confidence. Without confidence, people will regress toward second-guessing each other, avoiding risks, and generally not collaborate productively.
Confidence underpins morale and enthusiasm for your goals. Building and maintaining confidence in your team, and in others, is an incredibly important and valuable skill, and the most important one for a manager.
Technical vs. Management Tracks: Helping Your People Grow
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 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
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:
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
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
The other primary path for career advancement in engineering is to become a manager of people. The management path seems to be more widely discussed and understood, which is probably because it’s similar to many other professions.
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.
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
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.
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
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.
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:
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 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 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 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
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 a 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
Managers, by definition, are caught in the middle—reporting to the senior management or executives above, and responsible for directing the contributors (or other managers) below. Conventional wisdom suggests that the former are more important than the latter. They pay your salary, evaluate your performance, and generally tell you what you should be doing.
It’s actually the other way around.
When tech companies hire managers, it’s almost always with growth in mind. They’re looking for someone who can attract and retain top talent. Strange as it may sound, actual “management” is only a secondary concern.
Therefore, the best way to be successful as a manager, in the long term, is for people to love working for you. You will get amazing results. These results might not be exactly what the people above you asked for, but that’s where your skill is required—show that it’s better and that they can trust you and your team more than they thought.
Your career is an opportunity to build a group of people who will follow you anywhere, thus making you very valuable yourself. Getting people to love working for you, while still making senior decision-makers happy, is a non-trivial skill that requires a lot of study and practice. (You’ll make mistakes.)
Here are some ways to earn the loyalty and trust of your team.
Let People on Your Team Grow
Talented people love to try new things. They’re constantly looking to learn new skills, improve their current abilities, and generally expand their knowledge. This is a wonderful characteristic to nurture and encourage in your team.
Here are some examples of how to let technical people grow:
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.
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.
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
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.
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
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
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
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 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.
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
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.
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
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
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.
Here are some more details on each step.
The Ideation phase reflects the creation of a new project idea. These ideas can come from a variety of sources, including employees, customers, and research of market trends. We expect all members of a product team to contribute ideas, not just the product manager.
A project in the Ideation phase should have at least the following:
A clear definition of the concept
A high-level business goal
Projects should be prioritized in Ideation, and move to the next step only when the product manager has been able to define requirements for them.
The goal of this stage is to build a business case for the project. What needs to be built, and what problem does it solve? What is the opportunity, and what is the potential value of that opportunity?
The information for requirements may come from a variety of sources, including these:
Customer feedback and research
Internal analytics and data
Team brainstorm sessions
Other internal company teams
Technical performance or reliability
The requirements should describe specific use cases or user stories, and expectations of desired outcomes. Beyond listing new features and design elements, these requirements should also include communication and marketing tasks, expectations of customer support, and other rollout plans.
The Requirements phase is complete when we have a summary description of the project, business case, high-level task list, and a test plan—a set of tests that can be run by anyone on the team to verify that the work is complete and correct.
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 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.)
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
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.
Technical Architecture Review
Before beginning development, we need at least two engineers (with appropriate knowledge) to review the proposed implementation.
This phase is complete when at least one other engineer (not the developer ultimately doing the work) reviews and signs off on the proposed solution. For small tasks, architecture review might take only a minute. For large projects, this phase could require a design meeting with several engineers.
At this point, the project is waiting for technical implementation. When a developer is available to start, they will assign the project to themselves and begin work. Allocation of resources is accomplished by having developers always select the next, most important project from the master prioritized backlog.
Development in Progress
This is the phase in which the coding gets done.
During development, engineers should consider all possible solutions, regularly review progress with their teammates and the product owner, and adhere to company coding conventions and best practices.
We use Git for code version control, and one of our few strict rules is that all new development—no matter how big or small a project is—must be done in a branch (not master). Only after Code Review (the next phase) is complete, may the code be merged back into master.
The engineers on a project are also responsible for creating all necessary unit and functional code tests. We’ve developed tools to help with this process, such as a client-side pre-commit Git hook that automatically runs all unit tests on a commit, aborting the commit if any tests fail.
When coding is complete for a project, the project’s lead developer needs to perform a code review with at least one other developer. We leave it up to the developer to choose the most appropriate reviewer. Typically, this is another developer with good knowledge of the area(s) of code affected.
As described previously, one important rule that we strictly enforce is that no code should be merged back into our master branch without a complete code review.
The Code Review phase is complete when the following are true:
The code is complete.
The code review is complete.
The code has been tested and verified by the developer(s) against the test cases in the initial project description.
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
New user sign-up 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
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 to 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?
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.
Successful managers have toolboxes with lots of different tools in them. In this blog, we’ve discussed a variety of strategies, techniques, and tools to solve some of the myriad challenges you’ll face while building and leading a team.
In your experience as a manager, you’ll undoubtedly create and archive tips and tricks of your own. Over time, you’ll learn to recognize familiar problems and challenges, anticipate likely outcomes, and call on the most appropriate techniques at the correct times. Maintain an open mind and a desire to keep learning throughout your journey.