It's a common stereotype that developers distrust anyone who works with clients. We bring badly-scoped and poorly-architected projects to them, expecting them to work miracles to bring our plans to fruition. When we fail to deliver on time, development teams are the ones usually taking the blame for not working hard enough. It's never the fault of the sales team that sold something that didn't exist or the PS team that scoped something completely off-base that made on-time execution nearly impossible.
When we let that distrust fester, and they manifest in even worst ways:
- Development teams become non-participants - Instead of challenging poorly scoped projects and badly-estimated timelines, developers just accept what we give them. They end up consistently working long hours into the evenings and weekends to the point of burnout.
- Development teams start rooting for our failure - Instead of questioning our solutions and our design decisions, developers just "do as they're told". They keep their valuable feedback to themselves knowing what they're being asked to build is going to ultimately fail
- Development teams stop caring - Instead of building the best solution possible, developers will start building to the letter of what you've scoped. When we discover that what we have built doesn't go far enough to solve a pain for our client, developers will throw their hands up and say "Not my problem. We build what you tell us to build."
At the end of the day, no one is happy. Every team we work with ends up pointing fingers at each other.
So how do we solve this? For me, it's a really simple thing: Developers are people just like us. If we care about the work we do, wouldn't it make sense that our colleagues in development would care as well? If everyone cares about the work we do for our clients, then why are we so often treating developers as tools rather than colleagues that deserve an equal voice when we start planning a solution?
To really tackle the problem, we really have to listen to the meta-level feedback -- criticisms not about the projects we work on, but the fundamentals of how we work on projects in general. Dissecting the breakdowns in the way we do our work, it's important to keep in mind 3 things:
Development Should Be Involved In the Entire Process - Not Just The Output
Professional Services teams are often frustrated when they're brought in at the end of the sales process. Our common refrain is: "If we were a part of the sales process, we wouldn't be committing to something that we cannot deliver".
Now, replace "Professional Services" with "Development" and "Sales Process" with "project scoping" and we have a common scenario facing development teams. If we feel frustrated in this situation, don't we think development teams would feel the same way too?
PS teams need to work with development during the entire solutioning process to ensure what we are planning is actually achievable given the technologies at hand and the resources the development team has access to. There's no need to guess if we're biting off more than what we can chew because the intimate knowledge of the development team's capacity and their assessment of technical feasibility becomes first-hand knowledge if they're part of the conversation from the start.
There are many ways to start bringing in development into the solutioning process:
- Include them in the initial brainstorming sessions
- Iterate through our plans and architecture so we get a constant "sanity check" on feasibility
- Get overall signoff on solutioning decisions that they will eventually have to build
The key here is to get everyone collaborating from the very beginning, which gets development teams aligned with the same vision and understanding, and ultimately leads to a shared interpretation of what we're trying to do and accomplish.
Development Should Have a Voice, and We Should Act On It
Getting development teams involved in solutioning is a good start, but that's just a gesture if people are participating solely because they feel like they have to. Why do people begrudgingly participate and silently protest, or worse, sabotage?
It's because we don't take action on what is being told to us.
If we only listen to the feedback, concerns, and criticisms but don't ever deviate from our original plan, then participation becomes a farce. It becomes a fait accompli, and everyone goes through with the empty gestures of meetings and discussions with no expectations of any of their comments being taken seriously or acted upon.
It's so important to internalize and integrate feedback from our developer colleagues because they are experts in their domain. Here are two examples of how we can listen and act to them:
- Build their Timeline Constraints into Our Delivery Plans - When development tells us our timelines are "tough" or "tight", don't just say that's what the client needs. Start asking why they think it's tough. Get a good understanding of their capacity and current stressors. These questions can lead to a discussion on priorities and a timeline that everyone can live with
- Incorporate Their Suggestions in Our Solutions - Development teams are exposed to the latest coding techniques and philosophies. Most importantly, they practice the craft daily. If they pick apart a solution, it's because their expertise and experience are telling us there's most definitely a better, more efficient and effective way of going about solving the problem. It would be irresponsible not to include their expertise in our solutions.
Having a voice is crucial for autonomy. Development teams don't work for us, they work with us. Autonomous teams that are aligned to a shared vision leads to more feedback, more critique, and better outcomes for our solutions.
Development Should Understand The True Objective, So They Don't Work Blindly
Having a say in the solutioning process is a good start, but helping everyone, development teams included, understand the true "why" we are doing something is truly empowering. So often we are so fixated on delivering an output for another group to do their jobs that we forget that people often don't like to be a "dumb tool": we don't like blindly doing things without understanding why we are doing it.
The most empowering part of sharing the "Why" with development teams is that it gives them the leeway to start questioning our approaches. If our solution doesn't help us reach our client's objective, and for some reason, we are too myopic to see that, a fresh voice can help us reorient our direction. Bad solutioning forces us to make band-aid solutions later, and development teams are keenly aware of that. If they help us see faults in our planning, they are helping us avoid future rework and client disappointment. There's no downside here.
There's no good reason to keep people in the dark. They're your colleagues, and are just as capable (and probably smarter) than you, so fully inform everyone as to WHY we are building something, and the objective our clients are trying to reach. Having an objective keeps the whole team focused on producing a result towards reaching that objective instead of just blindly satisfying the letter of the solution document.
Understanding the true objective gives development teams context. Context isn't just for kings, it should be for everyone.
The Bottom Line: Developers Are Your Colleagues, Your Allies, and Humans Just Like You
It's easy to treat the teams that do our work as just another cog in the machine, a means to an end, a tool to get the work done. If we have that mindset, we lose a huge opportunity to gain a voice that can help us improve client solutions. More importantly: developers are people too, just like us. Treat them with respect and build great relationships with those we rely on to build great solutions for our clients.
Much thanks to Steve Khuu for your insight and feedback.