Developing People in a Distributed Environment

This is Part II of a three-part series, An Engineering Manager’s Guide to the Future of Work.

Engineers want to believe that distributed relationships can work perfectly; that you can just do your work and not be bothered with the people aspect. That’s false. In a distributed environment, it’s even more critical to form human relationships and prioritize “noise” so that we can all better calibrate the signal.

Embrace the Noise

As many have said, one-on-ones are essential. Currently, I have weekly one-on-ones with my direct reports, and bi-weekly ones with all of their direct reports. That face time is so valuable, for pairing, for collaborating and especially for getting to know each other. These one-on-ones are time spent fostering ‘noise’ which is the key for building trust and calibrating the signals in your relationships.

Just like mastering anything, the more you improve the more you’re aware how far you have to go. In my early one-on-ones, I was totally allergic to the notion of talking through progress or team dynamics for a half hour. You think: “Shouldn’t I be building, or strategizing, or blogging, or clarifying our direction?” Or: “They’re just going to complain, and I’d rather avoid that.”

Wrong. Whereas your first inclination in a remote one-on-one may be to run down the list of tasks and blockers, digging into how productive and empowered your direct reports feel is often a better use of your time.

Not only are one-on-ones absolutely critical for building trust, but they double as an early warning detection system within your organization.

Not only are one-on-ones absolutely critical for building trust, but they double as an early warning detection system within your organization. As a manager, actively seeking out issues is fundamental — if there’s something you don’t know, you need to race toward it as quickly as possible. If you can become the lightning rod for issues, you become the person who can triage these issues. The earlier you have these signals, the earlier you can move from fire-fighting to fire prevention.

What’s your VDAP?

Once you’ve made time and embraced the “noise,” I’m finding it’s important to create a system or protocol where you’re able to get the right signals through all of that noise. “VDAP” — Velocity, Direction, Acceleration, Position — is something we’re trialing at Andela to facilitate productive relationships within teams.

Velocity is meant to gauge an individual or project’s current progress. Do you feel like you or your product is moving well this week? Are you getting things done and overcoming blockers?

Direction captures a broader understanding of the project and the team’s goals. Do you know where you’re going? Do you know what the goal of the current project is — and how it fits into the company’s goals?

Acceleration is a measurement of learning and growth. Is this week better than last week? Are you or your team moving more quickly than you were last week?

Position focuses on the current and future state of not only the project, but more importantly the individual’s role on the team. Are you happy with your progress? Do you like your current role? Do you understand where you’re at, where you want to be, and the difference between the two?

It’s absolutely critical to understand how your team sees and feels about their work. VDAP is a really helpful, concise method to detect boredom, drowning or blockers.

It can be a nice, casual protocol such as “hey, what’s your V-Dap?” with quick responses. Or, you can go in-depth on a project and break down each piece accordingly.

The goal of VDAP is to isolate key signals and burrow down into them to get a regular cadence. It borrows a bit from physics — literally, an object moving through space — as well as agile concepts, mainly Velocity and Direction. At Andela, we prioritize getting people pointed in the right direction and accomplishing things every day, and use small course corrections over time to steer the ship.

Distributed teams benefit from VDAP because it provides a framework for thinking about your work and how to communicate it upwards in a compact format. If you can recognize when a team is getting things done but not moving faster each week, you have a good signal to dive deeper into how to optimize. If they’re getting things done but not sure where they’re heading, it’s a signal to step in and help that team plan out the roadmap.

The ideas coming from the bottom are good ones — and as a distributed manager, it’s your job to expose the larger business goals and challenges to your team.

Ultimately, the people building the application and the code have a lot more information about the problem than you do as the manager. The ideas coming from the bottom are good ones — and as a distributed manager, it’s your job to raise them upward. It’s also your job to expose the larger business goals and challenges to your team so that they’re able to think about how to break down those problems. And chances are, their solutions will be much better than what you (the manager) could come up with. To put it simply, they see what you can’t.

The Zone of Proximal Development

Great work is great learning — if you’re truly delivering, you’re learning constantly. If your VDAP is high, you’re in a position to maximize both output and learning velocity simultaneously. Now we can optimize the process.

The “Zone of Proximal Development,” or “ZPD,” is a place where an individual can level up consistently. It’s that goldilocks zone where whatever you’re working on isn’t too easy, and it’s not too hard — it’s attainable but also challenging enough for you to build. In the same way that smaller pull requests are easier to review and merge, tasks in the right ZPD are easier to level up on.

In order to speed up learning velocity we need two things: a developer’s ZPD and a task’s relative difficulty level for that developer. Neither of these problems are simple. Determining a developer’s ZPD — a moving target — requires a historical record of output and some methodology to determine if a person already ‘knows’ something. Determining a given task’s relative difficulty requires categorizing and understanding it at a granular level, taking a best guess approach and then iterating on it as you collect more data. Thankfully, this leads to a system that improves over time. The more data we collect, the better we can match types of tasks to developers and then improve their learning velocity.

But what about determining if someone ‘knows’ something? It’s more challenging than it sounds.

But what about determining if someone ‘knows’ something? It’s more challenging than it sounds. You can’t ask if someone knows something and expect any real accuracy. Universities solve for this by administering tests that ask students to provide an output that’s congruent with the knowledge they’re supposed to have. Engineering interviews tend to fall on the same crutch using whiteboard questions as a proxy. Our methodology is a bit different and it revolves around the latest advancements in learning sciences.

Instead of tests, assessments or whiteboarding, we’re looking to observe behaviors or beliefs to confirm whether an individual has a certain knowledge set. By collecting data points on these behaviors and beliefs that we’ve been observing for each of our developers, every day for the past three years, we can create a probabilistic model to determine confidence in someone’s knowledge. Leveraging this in the future, we will soon be able use machine learning and other AI techniques to give us predictors of current knowledge levels and determine what feedback is necessary at what time to help someone improve.

For instance: If I have a GitHub pull request of JavaScript, I can statically parse that and have a pretty good sense of whether you understand prototypal inheritance — and we can figure out the probability and the accuracy of that. If we determine that you don’t fully grasp the intricacies of prototypal inheritance, then we can look at your past knowledge and how you’ve learned to determine if it’s in your ZPD. If it isn’t, we can identify the gaps, fill them and prepare you better to try and tackle it.

At Andela, we’re building the systems that allow us to understand when a task is in the right ZPD for an engineer. We’re in the early days, but the potential impact for engineering organizations that are able to leverage the learning sciences to develop their individual contributors at scale is massive.

But more on that to come. Stay tuned for next week’s post, where we’ll discuss how to scale efficient, distributed teams across all parts of the organization.