Letter to a New Software Development Manager on My Team
Hi friend!
Before we really get into the thick of things, I want you to know that while the moniker “friend” may be somewhat aspirational at this point, I’m not using it superficially. I don’t mean that you’ve joined some kind of a fancy managers club where we meet up on weekends to shoot the shit over a round of golf. I couldn’t tell a golf club from a hockey stick if I wanted to get that going with you. Instead, what I mean is perhaps the highest form of friendship. Since you’re going to be running a subset of my team, you and I are going to care very deeply about the same exact thing. Nurturing and evolving that thing has already been a huge part of my professional life and it’s about to fully take over yours for the foreseeable future. What is this thing, you ask?
Well, let’s start with what it’s not. It’s not adherence to a specific methodology or process. It’s certainly not some kind of a report or a presentation you’ll be asked to deliver on a quarterly basis to explain your work to the leadership. It’s not any specific member of the team you’re going to be managing or even the team as a whole. All of those things and many others are likely to be very important in your work, but they aren’t in themselves your mission.
Any employee in any industry is given some resources and is expected in return to deliver value for the company. In the case of individual contributors, they’re given compensation, some tools and a fairly specific mandate that they’re expected to execute on. In addition to compensation and tools, people managers are given headcount funding in order to address a larger problem for the company. The first thing you and I are going to need to do is to align on what specific value you’re expected to bring to the company. In my experience, the following aspects do a pretty good job of defining a manager’s mission:
- Who are the direct beneficiaries of your work?
- What specific problem do you intend to solve for them?
- How do you measure to what degree you are succeeding in solving the problem?
Making sure that you and I agree upon crisp answers to the above is critical to a productive working relationship. Prioritizing your mission and treating it as the ultimate goal of your work will allow us to avoid the ambiguities many new managers struggle with. Should you code at all, and if so, when? Should you be following scrum, agile, lean or whatever other methodology du jour you heard other managers extol most recently? These and many other questions become a lot less acute when you realize that neither I, nor the company, nor its customers care even a little bit about how you answer them as long as you’re able to consistently deliver on your mission. To put it in terms you might find most intuitive from your software development experience, you can think of your job as implementing a single-function interface that takes in funding and produces value to the beneficiaries of your mission. Everything else is implementation details.
While this mindset can definitely be liberating, with the unbridled freedom comes tremendous responsibility. You alone own the outcomes delivered by your organization. If you default on your mission and your system is unavailable, the customer doesn’t care that this was because John wrote some unreliable code and Sally missed it in code review. The customer will just take their business elsewhere. Sure, you can and should hold people within your organization accountable, but you are the person I’m going to hold accountable for your mission.
That said, I also have a mission and yours is an important part of it. I am accountable for mine, so I’m 100% bought into the success of yours. At steady state, I do expect you to handle your mission on your own, but when shit hits the fan, I will be right there in the trenches with you and we’ll work it out together. If you ever feel like things aren’t going how you expect with respect to your professional life, talk to me early and often. If you’re concerned, I’m concerned.
Although I trust you to run your team as you see fit, you might not trust yourself to do so at the beginning. This is both natural and to a great degree productive. It isn’t hyperbole to say that your decisions are going to directly impact the professional lives of many people around you. It is healthy to regularly ask yourself if what you’re doing is the best thing you could be doing. Although with time you’ll learn to trust yourself more, if you’re anything like me, you’ll never reach the degree of confidence in your decisions in management that you have now with coding.
Luckily for you, your reports, your peer managers as well as managers senior to you collectively have a ton of experience in this business and every single one of them wants you to succeed. The camaraderie doesn’t really stop within the company either. As you’re trying to figure out how exactly you want to advance your mission, there are lot of resources to pull from. Keep in mind though that there’s the word “people” in “people management” and when it comes to working with people, there are lots of different ways to think about it. No two managers approach their work in the same way. You shouldn’t expect any actual answers to come from the internet, books, me or anyone else. Rather, treat external input as a way to stoke inspiration within yourself. Learn about some methods and ideas. Try them on mentally. See if they compile for you.
With that in mind, below are some thoughts or mixins, if you will, that I’ve found helpful in implementing the manager interface myself. I see my job as largely consisting of two large, somewhat separable, but certainly not independent areas:
- Execution: I need to plan and execute on my mission.
- Team Health: I need to create and maintain a healthy team that will help enable the execution not just today and tomorrow, but next quarter and the year after.
Each can be viewed as sort of a simple hierarchy of mixins:
In my experience, you need to have a solution to all of those aspects of management to be successful, but that doesn’t mean you have to do it all yourself. You can outsource just about any part of the above to a team member whom you find to be capable and passionate about it. I don’t intend to provide a complete reference for all things management, but I am going to share some tidbits I found helpful on each of the terminal nodes of this hierarchy. You could then use them to bootstrap deeper investigation into related topics.
Vision Development
Vision development is the work by which you convert your mission statement into your team’s technical direction. Since you’ve likely played a tech lead role of some type, you’re probably at least somewhat familiar with this aspect of management already. This is also an important reason I find it helpful to stay technical as an engineering leader – I like knowing first-hand that the team’s technical direction is in alignment with the mission. Sure, you can lean on your senior individual contributors for this, but a small misalignment here can lead to your team’s effort diverging significantly from the intended direction. I’m all for trusting your team, but I personally wouldn’t be comfortable being uninvolved at this phase.
It’s difficult to give general advice on technical vision development, because much is going to depend on the domain within which you’ll be working. I found this talk by Rich Hickey called Simple Made Easy to be perhaps the closest it comes to that. The talk disambiguates terms such as “easy”/”hard” and “simple”/”complex”, which provides ways to evaluate alternative technical approaches to accomplishing goals. This can be helpful when it comes to any engineering work, technical vision development included.
Project Management
A technical vision needs to be effectively broken down into projects, which then need to be driven to completion. Project management is probably the most thought-through aspect of management. So much so that it seems like it isn’t uncommon for beginning managers to mistake project management for the entirety of their job. Although there’s much more to management than that, it’s nevertheless important. Being unable to get things that need doing done is both an effective and popular way to screw up your mission. Below are some books I’ve found inspiring on this front:
- The Mythical Man-Month by Frederick Brooks Jr. is sort of the prototypical book on software development project management. It’s pretty amazing that the surprising discoveries made in the development of OS/360 in the 1960s still hold true today.
- The Goal by Eliyahu M. Goldratt is a novel that discusses lean manufacturing in a factory context, which eventually laid the foundation to DevOps. The book utilizes the Socratic method in laying out its insights, by which I mean that it brings up questions, rather than simply stating the insights. You might find that it leads you to try to apply those questions to your work and wonder how you might answer them.
- The Phoenix Project by Gene King is very similar to The Goal I mentioned above, except that it’s actually applied to IT, rather than manufacturing. King also wrote The Unicorn Project more recently, but I haven’t read it yet. It intends to lay out similar ideas, but applied to software development specifically.
Team Cohesion
In the achievement of your mission, you’re almost certainly going to need a strong team. People take time to get familiar with systems and context they work within. Similarly crucial is the time people take to warm up to each other before they truly have each other’s backs. All this is to say, you will want to retain strong team members for as long as you possibly can. I say “strong team members”, rather than “strong engineers” deliberately. You’re going to need more out of your reports, than just good engineering. Being a productive member of the team interpersonally is at least as important as being productive technically.
Lots has been written on the topic of professional and social cohesion. Things like hitting and celebrating milestones, building trust and offering training come up frequently. The two things that struck a chord with me are:
- Driving alignment in incentives at all levels across your domain is key to social and professional team cohesion. Make sure that it’s always the case that what’s good for your mission is also good for each individual team member and more – make sure that each team member knows it. It’s for some reason natural for many engineers, especially the more hierarchy-oriented ones, to assume that there’s some kind of a conflict of interests between employees. My conjecture is that this comes from having a partial view of the world giving the illusion of a zero-sum game. The incomplete logic is that the manager has some fixed amount of funding and since it’s a scarce resource, naturally the competition for that funding ensues between all team members. Part of your job as a manager is to make sure everybody is clear that what we’re doing isn’t a zero-sum game. If we do an excellent job advancing our mission, we’ll be trusted with a larger mission and more funding will come our way. Thus, the whole team benefits from any individual doing well and vice versa. This logic should apply across the board. Whenever I make any change on my team I always think carefully to make sure that the motivations of all stakeholders are aligned and if not, I think about how to evolve the change to make sure they are.
- Striving for the highest degree of transparency is fundamental to building trust across your team. Note that you personally have a lot of control over how transparent people are with you and each other. If you’re willing to share and be vulnerable with somebody, they instinctively respond by wanting to be vulnerable with you in return. Over time you can use this to build a culture of transparency on your team. Much deeper and more profound insights into the topic can be found in this TED talk called The Power of Vulnerability by Dr. Brené Brown.
Team Structure Curation
In addition to making your team gel well together, you’re going to want to ensure your team is staffed up for success. You’ll need to bring good new team members onboard, coach the existing ones to be able to take on larger challenges and part ways with those who aren’t contributing and evolving effectively. All of those involve evaluating engineers’ contributions to your mission. In the case of recruiting, it means evaluating engineers’ hypothetical contributions based on very little information. In my experience, when it comes to team structure curation, the most important thing to do is to get over your natural human inclination to think that you can make sound evaluations of people’s value as employees based on gut feeling. It has been shown time and time again that when it comes to evaluating performance, “gut feeling” is simply preferring those who are most like you, or more succinctly – tribalism. Much has been said on arbitrary preference based on race, gender and sexual orientation, but it definitely doesn’t stop there. This seminal work on subconscious bias from way back in 1970 showed that the mere act of creating groups triggers favoritism toward own group members regardless of criteria chosen for group creation!
With this in mind, when it comes to both recruiting and performance evaluation, I’ve found it helpful to follow a structured and data-driven process to the highest degree possible. This is because the closer you stick to a structured evaluation, the further you distance yourself from your subconscious tribalist tendencies. For example, if in your recruiting evaluation you make decisions based on whether you’d like to work with the candidate (shockingly common criteria for recruiting decisions in the industry), you’re going to experience worse outcomes than if you evaluate more specific criteria for what you think might make for a better coworker, such as a specific approach to decision making or conflict resolution. Note that although it’s good to shoot for approaching this ideal, it’s generally impossible to eliminate subjectivity from these decisions entirely. A more practical goal is to move away from subjectively evaluating people – something humans are known to be horrible at. Instead, the guidance is to evaluate humans by an objective combination of several subjectively evaluated non-human criteria. In the example above, how closely a candidate models a specific approach to decision making is a judgement call, but it’s one humans are generally better equipped to make than evaluating others directly.
If structure isn’t already provided by somebody within company leadership, I would advocate sitting down and writing out the specific and, to the degree possible, objective criteria by which you’re going to evaluate current and potential engineers on your team. When you’re doing the actual evaluating, my recommendation is to follow your criteria thoroughly to avoid subconscious bias or gut feeling slipping through. Remember that although you may have the most noble intentions in mind, when you evaluate people based on gut feeling, you are defaulting to the lowest and most savage within you.
This just about completes my high-level survey of the tools and tactics you’ll have at your disposal in the advancement of your mission. I hope it inspires you to do some of your own research and thinking about the aspects of leadership discussed here. It’s a lot to process and it’s normal to be anxious about the growth in scope – at some level it’s concerning if you’re not. Call this my clumsy attempt to be a dealer in hope, but I wouldn’t be talking to you about this if I didn’t believe you’ve got this.
Your friend,
vova
Interested in joining Box? Check out our open positions.
