I’ve had the pleasure of working with many internal development teams in my career in software development. For our company, working in partnership with internal development teams is, in fact, a common project type. Clients call on our particular services for any number of reasons but the most common are to a) increase development traction or b) supplement core internal skills with outside development expertise.
We’ve worked with internal teams comprised of a single developer as well as internal development teams for vast, multinational tech companies with internal departments that dwarf our entire company.
We’re highly successful in these partnerships because, among other reasons, we know how to integrate with internal development teams. This capacity goes beyond mapping our communication, development practices, task tracking, and source-code repository needs to what best suits those teams’ workflows.
The key to our ability to fuse successfully with an internal team and provide services in a seamless way also rests in our interpersonal approach to working with internal teams.
Good team integration must be egoless.
Let me clarify: Egolessness isn’t apathy or disengagement. On the contrary, it’s highly engaged and engenders deep ownership of the project and its outcome. Here are the keys to an egoless technical partnership:
- Compassion. The internal development team may be defensive or suspect of bringing in an outside vendor to complete work. Many times, the decision has been made to use an outside vendor by people outside of the engineering department. We recognize this reality and approach the development team with compassion. We also proactively and forthrightly address their concerns. The objective is to assist them, to support them, and to ensure that they succeed. If at any time, we feel our involvement is compromising this objective, we’ll discuss our concerns and, if need be, work to efficiently and safely extract ourselves from the project.
- Vulnerability. We may know the specific technology we’ve been hired to use or we may bring additional expert bandwidth to a project but we don’t know the project as well as the internal team does. Nor do we know the technical and business-level decisions that have been made to bring the project to its current state. A project, of any size and age, is an amalgam of compromises and choices. To assume that we’d make a different choice or compromise would be arrogant. We partner with the internal team by asking them to explain the code we’ll be working with or writing against. We assume the best of intentions.
- Trust. Trust is earned. Trust is established over time and trust is broken in mere seconds. Trust capital is essential to a long-term relationship. We understand that an internal development team has to trust us but that we also need to demonstrate that we are trustworthy. To that end, we take great care in presenting our advice, ensuring that the logic is sound, outlining the pros and cons of following that advice, assigning a risk value to both following and not following the advice and then we implement whatever the decision. We also don’t shy away from bad news or the risk of alerting the team to some, even remote, issue that we’ve identified. It’s important to report early and, from there, collaboratively make a plan to address an issue.
- Communicating with Intention. We offer suggestions, not judgments. We strive to be cognizant of tone in both written and spoken communication. We provide transparency to what is being undertaken and done in a way that makes sense to the internal development team and is formatted in a way that is readily consumed by them. We support the internal development team in their internal reporting needs. Wherever possible, we lessen their burden and ensure they have the data to manage the project and report to superiors on the effort. We endeavor to be collaborative on all things and avoid competitive or adversarial stances as, in the end, regardless of who is right, everyone loses.
- Acceptance. We are willing to accept where an internal development team cannot go. Maybe they are married to a particular technology that isn’t our preference, maybe they’ve been so traumatized by a certain set of features that the idea of revisiting them is just too exhausting right now, maybe they are convinced that a less-than-best-practices implementation is exactly what they want. We can only suggest but we cannot demand or subvert. We must accept where the internal development team is and what they can and cannot mentally, emotionally, or ideologically accept. We must meet them there and move with them from there.
Partnering with internal development teams can be highly rewarding and, if undertaken with an eye towards more than just implementing ruthlessly, can be a fantastic way to build years-long relationships. If the focus of attention remains on serving the client’s needs and ushering the application through to successful completion, success is nearly assured. The trick is to meet the internal development team with collaboration, openness, empathy, and respect. To shelve the ego . . . and leave it on the shelf.
