Full disclosure: I am in the middle of an adventure in uncharted territories. I’m one of those individual contributors who turned to management because it made sense for some number of reasons that felt more beneficial than my urges to continue making individual contributions. I like to pretend that I’m on some sort of engineer-manager pendulum, but in truth I’m just moving from one challenge I don’t yet understand to the next. As I’ve stumbled through management territory, I found a few things that seem to work and have gotten positive feedback from others. I’m writing this to solidify my understanding of these tactics, put them out for wider review, and to ask for feedback on how to improve them.
A couple notes worth mentioning (I don’t think these factors have a huge impact on my points, but they certainly carry some influence):
Since we’re a fairly small organization in a rapid growth phase, it’s safe to say this was one of those “BANG! Now you’re a manager - do things” kind of changes. It wasn’t quite so abrupt, but I wasn’t sent to management training or given a manual or anything to that effect. I immediately starting searching the internet for resources on technical management, startup management, engineering team best practices, etc. I found that there are quite a few people who end up in my position. While that’s comforting (I’m not alone), it’s not immediately helpful.
This is what I’ve cobbled together for Engineering 1 on 1 meetings. I’m gating this within Engineering because I’ve only ever managed engineers and I just don’t have any idea how successful this could be for other types of teams. It’s worth adding that much of this is rooted in concepts of Transformational and Servant Leadership. I think these two leadership types are similar and can be particularly productive with teams of creators (citation needed!).
The core concept is all about honest, direct, and timely feedback. Saying: “You should work on improving skill X, it would go a long way for targets A and B,” to a team member annually is near worthless. Have they really been doing X poorly for a year? Why hasn’t anyone told them? You can not assume that someone else is covering this: surface problems that you identify. Surface them regularly, directly, and with resolution in mind. The Truth Framework that I’m shaping targets this type of feedback leveraging a few concepts:
You can have regular one on one meetings that are productive in their own right, but don’t support the goals of this framework. “Truth” doesn’t come for free, and you can only expect truthful responses from someone who trusts you and your intentions. Your regular one on one meetings should be indirectly pointed at trust-building. I say indirectly because you can’t just have a meeting with goal: “build trust,” it simply doesn’t work like that. You can have meetings that aim to increase trust. We’ll review some of the ways I try to do this in the Regular One on One Meetings section below.
I also want to note that I titled this “A Truth Framework for Engineering 1 on 1 Meetings” for a reason. While any regular one on one meeting processs can go a long way, you can have on-topic, regular one on ones and still not be gaining much. There are too many managers and individual contributors out there who just aren’t truthful in these meetings. There’s no trust in the relationship, and very little impetus on either side to be fully truthful in these interactions. I think this is a foundational problem that sacrifices the effectiveness of the one on one. It is imperative that we focus on our common goal - something like, “Team Success through Individual Development” and establish enough trust to warrant truthful revelations.
I’m assuming that we have a team because 1 on 1 meetings are happening (or at least being investigated). It might be a team of two, but there is a team and that team’s productivity and potential should be an important consideration in the context of each member. Having a team is actually a huge perk in the context of 1 on 1 meetings, because it makes 360 reviews a viable input mechanism. I’m going to plug Robert Bruce Shaw’s Extreme Teams and in particular mention his coverage of Whole Foods team dynamics. From Extreme Teams it’s apparent that Whole Foods both tries to provide their teams with a lot of independence and also a lot of responsibility for their own well being. Shaw relates that on these high-functioning teams 360 reviews are an important mechanism for direct team feedback. I think this focus on having a working framework for meaningful peer feedback is productive, and it shapes a concept that is profoundly important: we want our team members to do well because it makes our team do well. This lets us present the following critique distinctly:
This is subtle, but I think it’s an important point of clarity for a lot of people. If you’re doing something ineffectively but somehow managed to skate through an annual review and it looks like you’re “Meeting Expectations,” then why is there any motivation to change? I’ll tell you why: because Jane Smith is on the team too, and she also said that you need to improve skill X so that the team can excel. The social dynamic is important; this can, and should, be a motivating factor for personal development. We need to be careful here because we’re not trying to instill a sense of competition, but rather have honest conversations about ways that the team can get better. This can be process-oriented (manager needs to improve/fix a process), or people-oriented (manager/individual contributor needs to stop/start/continue X). Trying to make these discussions happen in the moment feels a lot harder than it actually is. Don’t shy away from these seemingly hard conversations. The more honest and direct you can make your intra-team feedback, the faster your team will grow and develop.
I target one on one meetings every four weeks with the members of my team. I also try to make it clear that I have time available in between those discussions for one on one content, and I’m open to feedback on things whenever/however. I do my best to make these meetings non-project specific, it’s not a standup and it’s not a planning session for the current quarter’s goals. I also try to make sure that a few of these have at least a light structure. Those structured one on one meetings fall into a few categories:
The first one on one follows a recommedation from Lara Hogan which I send directly to my one on one counterpart. The only additions I make are that we might find some of this more/less important but that I’m particularly interested in things that make you “grumpy” (Lara’s wording) and how you like feedback/praise. Periodically, I aim to revisit Opener topics to make sure that nothing has changed and that we both still have shared understanding around those questions.
As a small/medium company that was (is) rapidly growing we didn’t have a fully featured, pre-existing implementation for 360 reviews. This is not a reason to skip 360 reviews. Take on the overhead, it’s completely worth it. We’re currently working on improvements and services supporting 360 reviews (and related); and I’m super grateful to our People Operations team for pushing this direction. Until you get there, come up with questions or use some example questions. I use The Balance 360 questions and The Balance more 360 questions, again simply passing the link to others with a note that questions are optional and the feedback is in the interest of bettering individuals and our team.
I currently force feedback to be shared non-anonymously to me, but I do not pass the raw 360 feedback directly to each reviewee. This is a sticking point for me, I’d really like to be able to just have these out in the open, but I appreciate that some individuals are more comfortable providing feedback anonymously. By forcing them to claim their feedback to me, I worry that I’m protentially sacrificing some feedback validity. Even knowing that non-anonymous feedback might limit what gets reported, I still like this pattern because I can relay concerns to the 360 reviewee, and then in later one on one meetings with the reviewer, we can discuss the feedback and results again. Both sides can see that the feedback was useful and what’s happening as a result.
I think one of the most important things we can discuss in a one on one meeting is our assessment of the situation. These are questions like:
This list is by no means exhaustive. However, if you have direct reports, do you know the answers they would give to this (small) list of questions? I do not and I know it. I am also pretty confident that at any given time I will never be able to answer all of those questions for all of my direct reports. This is why it is so abundantly important to have these discussions regularly and make sure that these concepts are surfaced. Many of these result in feedback that is not only useful and important, but actionable and often simple. And guess what, often I find that individual contributors are pretty happy just knowing that you’re interested in these things. While it’s hard to get started, once you do start and manage to open those floodgates there is a wealth of information at your fingertips. You want this data.
I suppose you could also call this a “Trust” Framework. Really what I’m trying to instill is trust, when there’s trust in a relationship (being manager-individual contributor or not) truth is generally more accessible. Most of the honest and bi-directional concept is strongly rooted in the Assessment one on one meetings detailed above. This is another area that I’m experimenting heavily with, and I want to relay a few specific techniques that are working well so far. To be clear, most of these are discussions that occur in a one on one meeting that would fall into my Assessment category above. These topics should not (in my opinion) be reserved exclusively for those discussions, but that’s where they tend to happen for me.
Meets expectations, needs improvement, high performer, 5, above average, consistent, … <– pardon the term, but these are bullshit. If I am forced to use these for whatever reason, I put them on paper and consider the matter over. In discussion, this is what it looks like and how I try to shape it:
There aren’t really team members who are in the middle. If someone is in the middle, then you’re saying the team could thrive without them. Who’s currently making the team better? “Currently” is important, because these are highly transient assessments. This month might have seen some life event for team member Q. Normally Q has a minor issue with communication but a quick check-in isn’t an issue. Q is usually pulling the team forward, except this month when some external thing happened (they do) and Q’s communication deficiencies are a serious issue that impacts the team. Similarly if team member P is notoriously lacking in technical proficiency, and we discover that a different framework/language/project actually fits their skill-set better, all of sudden they’re bringing the team up. This isn’t an annual performance assessment, and it shouldn’t be. Who’s your top performer this month; what was the most challenging event this week; who needs your attention today? Be direct and tune your timescales down as far as you can, it’s not about team assessments at the end of a year - it’s about today and tomorrow.
Let’s get real here. Your top performers? They can get another job. It could probably pay at least as well, or provide other benefits that they find attractive. The same is likely true for your weakest performers. When you get right down to it, this is a battle of attrition. Your best weapon is knowledge about your team and what’s important to them right now. I try to be as forthcoming about this as possible.
During an early one on one meeting (usually the second), I propose the following prompt:
This discussion is super helpful. Take notes, keep them handy, refer to them. Just like the Opener refresh these periodically. Make sure you still have a good handle on the key features that your team is offering individuals and who appreciates what features most. Be honest and direct about this, actively seek to discover why your team members would search for another job - it might be time. People change, they have motivations outside of your team, it could be that a team member is ready for a change that will result in them leaving the company. It is far better to discover this in advance and plan for it, than to get two week’s notice and have to deal with it.
This is hard. I think it helps with honesty, and I hope that it helps with team cohesion and performance. Periodically (probably not often enough), I explicitly ask for feedback on how I’m doing. You may have caught a couple questions in the Assessment phase that hinted at this, but I try to take it a step further. Pick something that you know you do poorly, particularly in the context of a given team member. Use a one on one meeting to highlight that issue and ask if your team member can point out 2 or 3 other improvements you could make to help the team.
“I’ve been slacking on making small changes to our issue workflows and I can see how failing to complete seemingly simple updates must be really frustrating [I do this…]. I am going to work on more diligently completing these updates, is there anywhere else I can improve? What changes could I make that would benefit you or the team?”
Especially at the beginning, this is hard - sometimes for both parties. As a manager, you’re as much a part of the team as everyone else (and you’re not really “more” of a team member in any way, either). Just like any other poor performer, you can bring the team down. Bi-directional feedback and using your team for 360 reviews (of yourself) is critical to making your team successful. You aren’t special, you just do different things with your time. Ultimately, you’re still trying to make your team productive and that means it’s important to get your team’s feedback regularly, AND act on it.
Hopefully some managers/teams find this helpful. I’m excited about these methods, but I am also very interested in how others think they can be improved.
Have you tried some or all of these techniques? What worked for you? Can this sort of technique have widespread success?
What am I missing? What information is important that I’m not getting?
I would love to improve upon this. Please send your critiques, comments, or considerations to @nw_iw.
Special thanks to @bismuth_egg, @sysadm1138, @klyntonj, and Clare Gobel for reviewing this post and making it better.