I recently retired after 38 years in the software industry. I have been a software engineer, architect, chief architect, team lead, development manager, director of engineering, and VP of engineering. I’ve worked on and led teams from <10 engineers to >100 engineers at companies like Lotus Development Corporation, IBM, Intuit, Nokia, Elastic, and a bunch you’ve never heard of. I’ve built software for everything from 8-bit microcomputers to Cray Supercomputers and shipped it in boxes, downloads, web services, cell phones and Linux appliances to customer bases ranging from hundreds of specialists to millions of consumers. I’m sharing these retrospectives just to say “here’s my perspective…” I think there are lots of ways to succeed in the complex business of software engineering, these just describe my approach..
I have been asked more than once: “What is the job of a manager?” All of my management experience has been managing software engineering teams. So, my answer is in terms of that field, but I think a lot of it is the same across fields. The HR department might have a whole bulleted list of responsibilities for managers, but I don’t often refer to those. My answer is usually a combination of saying what a manager does and what they shouldn’t do. Often the things you don’t do are very important.
Their manager had created an enormous spreadsheet, listing hundreds of product features, ranked in some arbitrary way. “Here you go, these are your priorities” they said. There was nothing to tie the features or the ranking to any business goal that could be measured. Weeks later the manager was frustrated saying “Why did they choose to do THOSE things? Those aren’t important.” The team said “See, we ticked off these things from your list! They were easy to get done.”
I think the most vital role that a manager has is to communicate the team’s goals and the relative priority of those goals to the team. This is hard to do well because it involves understanding the reality of the business and organization that you’re working in. It is not as simple as just listening to your boss and passing down whatever they say. You should understand your team’s stakeholders needs and how high priority they are, how much business impact they have, and where your team is in terms of satisfying their requirements. The team itself is a stakeholder, often generating goals internally that need to be aligned with the wider business.
A manager needs to at some regular interval update the team’s priorities and goals and reflect back to the team where they are in terms of accomplishing their goals. It is critical to give ownership of the “how” part of accomplishing the goals to the teams almost entirely. It’s fine to apply “taste & discretion” or “guidelines” to their work, but the manager should not delve down into implementation details. The manager should ask their teams for a plan for how they will address the goals, and that plan should include what is going to happen, who is doing what, and what order things will happen; sometimes they also include time estimates. A manager should provide feedback and coaching on the plan, seek to reduce scope and risk, and question unnecessary work. When the work is in progress the manager should look at how the work is tracking to the plan and suggest re-planning if new information supports that.
All of this planning and feedback should happen in the context of the set of goals and priorities and the goals should support the team’s decisions. If you find yourself or a team going away from those goals, then it’s time to re-evaluate the goals.
A new manager comes to take over an existing team, they’re informed by their boss: “This team is all messed up, you’ve got a lot of performance problems. Here is a list of the people you should get rid of…” The new manager asks “Have you given them any feedback about their performance?” Their boss responds “They know what’s expected of them…” In other words, “no.” The new manager reviews the performance of the people in question and gives them appropriate feedback. The majority of the team improve their performance immediately. Some of them are managed out of the team. The rest of the team gets regular feedback and they steadily improve.
This gets into the second highest priority of a manager: giving feedback. Once you’ve been clear with your teams about goals and priorities, and they have given you plans and status, which you’ve reviewed, you’ll probably have great content for feedback. First rule of feedback is: “Don’t wait!” As soon as there is an opportunity to learn something together, it is time to talk about it. The punctuated reporting schedule of HR systems is not a good structure for managing successful projects.
Feedback should be 75% praise, 25% critical feedback. If you can’t come up with 75% praise, you probably have a real performance or morale problem. The 25% critical feedback that you give should be for the highest priority things that are impacting the effectiveness of a team or individual. These should include one to three points, with accompanying suggestions for how to take action as a prompt for the person or team to suggest their own ways to improve. The critical feedback should be something that is measurable in a goal or deliverable.
Solicit feedback regularly from the team or individual’s stakeholders and summarize the trends in that feedback, both positive and critical. Often the best language and suggestions for describing improvements come directly from stakeholders (including peers). Be careful not to overweight feedback based on the age/rank/level of the person giving feedback. Similar feedback from multiple stakeholders is much more useful than cranky feedback from an executive. Of course you should monitor that crankiness and perhaps discuss it with the executive, to try to keep that executive from developing a grudge against your team or employee.
The CTO would rigorously review every project schedule with dedicated project managers, schedules, and task lists. The same CTO would drop in on the most productive engineers and ask them to build things for them, speculative projects that didn’t appear on any plan. Projects would then miss their dates, deep concern would be expressed, and pressure applied to correct the issue… The speculative project would be sidelined and never shipped. The cycle would repeat.
The third thing is to drive a cadence in the work of your team and protect them from chaos agents. In some companies that are very early stage or prototypical startup efforts, chaos is the normal environment, but there are processes to focus and control that chaos and as a manager you should work to do that. The key thing is to allow your team to complete projects and have the satisfaction of delivering things to the market. This isn’t as simple as saying “no” to everyone; it involves working with your teams to determine a structure for how to acknowledge, prioritize, and sequence the new work that inevitably comes in. The other thing to fold smoothly into the workflow is technical debt or maintenance. This needs to be a high priority and carefully chosen, so that it doesn’t end up completely overwhelming the flow of work at random, unpredictable intervals.
Supporting your team in resisting distractions when they come in (from executives with a great idea, internal teams hacking up competition to their products, etc.) is a key part of this process. There may need to be some reserved capacity for ego maintenance of executives, but like a lot of political capital, it needs to be carefully managed because the backlash will be even worse if the team fails in its core mission for the company while delivering an executive’s pet project. Usually engaging executives in the boring process of figuring out all the trade-offs required to make room for their project can make them wander off to bother a different team.
Everyone who applied and passed the phone screen by the recruiter was sent to do an online coding test. Anyone who got past the test was interviewed by the team. People were often rejected after seven interviews, seven hours, by at least seven different people. The team’s hiring rate was very low and the people they spoke to were often not senior enough for the role and were being rejected at the final executive interview. None of the interviewers were clear on what they were interviewing for and what criteria they should use; they often passed people along figuring the next person would reject them. Sadly, the automated coding test was causing some of their best candidates to be offended and to simply opt out and take a different job at another company.
The final key is to make sure that you have great people on your team and that they are the right people for what you’re doing. This involves hiring as well as performance management and internal staffing. You should be clear on the profile of the folks the team needs, both from a “skills and experience perspective,” but also personality type and social fit. The hiring process should be as short as possible, but comprehensive in having at least a couple of people check out each attribute you’re looking for. I personally like combining an interview step with multiple goals; for example, an interactive coding session with two engineers and having the candidate work through the problem with them and interact with them in a similar way to the way the team would work. This can answer questions beyond “can you code?” and get way into team fit.
Like any process, you and your team should examine your hiring process at regular intervals and ask if it is delivering what you want. For example, it is expensive to have your team interview and then not hire people. So, the more that candidates can be screened at the resume screen or at the initial phone contact, the better. Likewise, if you have an executive approval phase in the interview process, you should have addressed all of that executive’s concerns before a candidate gets there, because that is the most expensive time to have someone exit the hiring process.
“Look, “ I said “you are very good whenever we have a support escalation, I get messages from customers praising you and marveling at how passionate you are about solving their problem. On the other hand, you struggle to keep up with even our most junior engineers, people have to step in and correct or redo your work. You are visibly unhappy whenever we talk about your job…” They had already started sobbing. I continued, “Why don’t we talk to the support organization and see if they have something…” They look up in amazement. “You’re not firing me? You want to help me?...”
Performance management is the other side of the coin, and you should act promptly when someone is under-performing. Effective 360 reviews and close examination of status vs. planned assignments will help identify team members who aren’t meeting their goals. Finally, metrics on code base productivity can be useful to support or refute a performance issue. Understandable feedback (along with clear explanation of the consequences of not improving) is crucial all along. Again, don’t wait for a review: As soon as you know something is going on, give the feedback. There are HR processes for dealing with folks who can’t listen to feedback and respond to it. Don’t be scared of them—work with your HR person and replace people quickly who are not performing well. Even in the best teams, a poorly performing person is a drag on morale and will impact the whole team.
A different problem is having the wrong person for a role. Once you recognize this, start a career path discussion with that person. Sometimes they can find a role in the company better suits them, and you can replace them with someone who is a better fit for your team. You can usually differentiate this situation from other performance issues because the person will sincerely try very hard to respond to feedback, but will swing back and forth, first getting better, then worse. They will also show symptoms of disengagement, lack of attention, lack of communication, etc., so it’s vital to suggest changing roles for folks in this situation.
I talk about some organizational context for these four parts of a manager’s job in the next post: “Management: Getting the most out of your team’s brain matter…”