We make sure we give our developers more information than they need
Our project leaders will walk into people’s offices unprompted and give them an information dump. They’ll say, “I know you’ve got this one task to do, but let me explain to you why you’re doing it and what it means in the larger context—not just what you have to do.” It’s part of our culture. We do that a lot with changes, too. We might tell the team, “Just so you know, we just made this decision over there, and you should be aware of it. You don’t need it now, but you might need it in the future at some point. So just be conscious of it.”
We stay open and available
At AVI, we’re very open and inviting. Our manager’s offices are sometimes like Grand Central Station where people just walk in and ask questions on the fly. It fosters collaboration and communication, and it helps everyone to know what everyone else is doing and wrestling with. When your engineers are connected like that, they can make better-informed decisions during development. It takes a lot of energy to maintain this kind of openness and availability, but it works. And it’s a lot easier if you’re a small company.
We haunt the code
Sometimes our managers check out the codebase at 2:00 a.m., just to review the code. That way they can ask the developer questions like, “Why did you do it this way? What happens if you do this or that? If such-and-such happens down the road, how do you think this could be done better now, so it’s much easier later on?” Because we do that (but not too much–we don’t want to be annoying), engineers start asking those questions on their own. They’ll say to themselves, “If I just make this a little more generic, I get the feeling it might be useful down the road.”