One of the biggest benefits of working at an agency that specializes in digital product development like DEPT® is the exposure to a wide array of projects that may otherwise take several years of job hopping to acquire.
We’ve worked on hundreds of development projects in various business domains, written in different tech stacks, with different team compositions, and different types of stakeholders.
We’re fortunate to be able to pause after projects and reflect on what went well, what we would change, and how we can better influence future projects.
This introspection often leads us to ask ourselves: What makes a product development project successful?
Cutting-edge technologies, talented teams, and clear objectives all play vital roles. However, we believe the secret sauce often lies in soft skills rather than engineering proficiency and management.
To delve deeper into the fabric of successful projects, we’ve asked several engineering leaders at DEPT® for their perspectives on what makes a product project successful.
Jon Principe, Managing Director at DEPT®/Digital Products
The tactic I’ve found to be the biggest indicator of success is being comfortable saying, “I don’t know.”
You can’t know everything, and pretending to do so often leads to wasted time, poor expectation settings, and frustration from clients and team members. Pairing “I don’t know” with the ability to ask great questions will help gain trust from all sides of a project and set the tone of working collaboratively.
Feigning omniscience only strains team relations, fosters distrust, and can create an environment where one person inserts themselves as the lone decision maker who knows everything. Successful projects lead to everyone on the team feeling comfortable and confident in their communication, including internally and with stakeholders. Being self-assured that you don’t need to be an infallible source of wisdom shows others that it’s okay to take some time to research issues and form an opinion other than your first instinct.
Jake Rainis, Software Architect
Every project is too unique and nuanced to apply any rigid structure to guarantee success. A successful project is really just a team of people succeeding together.
When I’m involved in a project in any regard — whether it be as an individual contributor or an architectural lead — I’ve found the following practices to be incredibly helpful in every situation I’ve employed them:
- Try to understand the communication styles of all involved parties and adapt to those styles in a way that allows you to work best together. Setting the right tone is a great way to create harmony across a team of unique personalities.
- When there’s a gap, fill it, even if it’s beyond your scope of responsibility… as long as it’s sustainable. If it’s not, have a conversation with the team and align on a good approach to remedy. If all else fails, and the problem is big enough, let the plates fall and pick them up as a team. Sometimes, things need to get worse before they get better.
- Try not to die on any hills. Technology is the equivalent of sandcastles. We build things, then they weather away. We all have opinions, and sometimes we’re right. In those cases, educate objectively and bring the team along. But unless it’s crucial, giving other people a win tends to net more success than always doing things your way.
Joaquin Gatti, Managing Director DEPT® Argentina
A successful project results from a team working hard to make things happen with one shared goal. Also, I don’t think there’s a magic recipe for making a project successful. It’s just being involved with the objectives set from the beginning or those that appeared when the first ones didn’t work out. The dilemma is, how do we make this happen?
A couple of things can make the account manager, product manager, client, or team life easier. Here are the top ones:
- Having good, frequent, and honest communication with all team members.
- Setting clear expectations on what needs to be delivered and when. This is key to avoiding awkwardness where expectations differ from delivery.
- Don’t put ego or tech before the business goals. Yeah, everyone wants to use the latest hot stuff, but that’s not always the best thing for the project. You can always make things better if the business is still alive.
- Stakeholders should have active participation. They can keep the team motivated by sharing how the work is impacting the business, which, in the end, keeps everyone aligned with the end goal.
Jorge Castellanos, Partner at DEPT®/Digital Products
Alignment is crucial. When the whole team is on the same wavelength, same phase, everything else falls into place. But getting there requires a willing and capable team that has something to get aligned on.
Then, it’s a matter of finding the right level of communication to maintain alignment for a given project. This will be different for different projects, but as a quick initial push, a week-long design or architecture sprint can do marvels.
Joey Eggers, Managing Director at DEPT® APAC
What makes a successful project? In my view, it boils down to three core elements:
- Communication – Communication is the single most important element of any successful project. Nearly every issue can be traced back to a communication problem. Communication is all about honesty, transparency, and ensuring everyone has context. It’s not just verbal, it’s also how we effectively use our tools, processes, and weekly project cadences. Ultimately, these elements ensure that everyone on the team and the client’s team shares the same ‘source of truth,’ vision, and end goal.
- Trust – Having clear and open communication builds trust. Trust encourages team members and clients to raise issues, make suggestions, or admit mistakes without fear of negative judgment. This leads to more open communication and collaboration and better project outcomes.
- Purpose – Something magical happens when your team works on a project they’re passionate about. Personal values and the project goals will align to inspire team members to unite. This alignment instinctively motivates everyone to go above and beyond, leading to higher-quality output and exceeding expectations.
Tim Davison, Principal Software Engineer
One thing that can make or break a development effort is how defined the goal of the software is. It can be tempting to rush into building, especially with deadlines and business priorities looming over the team, but taking the time to define the end state of the development clearly can be an invaluable opportunity for aligning stakeholders and avoiding surprises down the road.
While some engineers might get a thrill out of the hunt in an exploratory project, most will be driven to build production-level code, which may be the wrong approach in a ‘fail fast’ situation. Even projects that use an agile strategy can break down if the backlog is full of spikes blocking actionable tickets, with an unknown outcome that could potentially leave the business with slow or no progress towards solving their original pain point.
Focusing on the end state allows the team to roadmap incremental features and decision points as a plan, not an afterthought.
Jonah Jolley, Director of Engineering
The nature of consulting on custom software is that there isn’t a one-size-fits-all. The technical scope, time complexity, and team size can all contribute to vastly different experiences.
However, they all share some common threads that we try to apply some expectations around.
- Transparent communication and alignment. Unless we did upfront work upfront in an architecture sprint, the goalposts can move quite a bit through the life of a project. Ensuring we are in constant communication with external and internal teams to align on business requirements and definition of project success is key.
- Having two sets of deadlines. Part of collaborating with an external team is that they often deal with their own resource constraints and pressures. We want to be the best partners we can be. A part of that is setting clear expectations, committing to our deliverables, and building trust by executing. When we have dependencies on an external team. Setting an internal deadline, our teams need the dependency to be able to deliver by and communicate an external deadline we need it from them. This allows us to have some buffer for late deliverables and reduces difficult conversations around delivery.
- Team members who aren’t afraid to escalate early. Issues can be solved quickly if we know about them early. But teams need to be comfortable with raising issues and having an internal threshold of what should be handled within the team and what should be escalated. Having a conversation late in a project doesn’t feel good for anyone.
Nat Ring, Director of Engineering
One of the best ways to ensure a successful development project is clear communication and flexibility around the team process. It doesn’t matter if the team is following a strict Agile methodology or if it’s a more laid-back Kanban-style approach.
Figuring out what is (or is not) working about a team’s process while being open to changing parts of that process can tremendously affect productivity, expectations, and team happiness.
Keep an open line of communication between the team so that everyone is on board with any proposed process changes. Once a change is enacted, check in with everyone after a week or two to see how it’s working out. Having daily standup in Slack instead of a meeting might be more efficient. Increasing the approvals required before merging a PR might create more stress than it’s worth.
Just as project requirements often change, we should also remain flexible in our communication processes and styles. Listen to your team and find what is most effective for them rather than adhering to a prescribed set of guidelines set from the beginning.
Phil Gonzalez, Director of Engineering
Sometimes, big money and big goals come knocking for top leaders looking to make a positive impact. But here’s the deal: even the best teams hit roadblocks if the project rules aren’t crystal clear. Those massive projects? They need detailed blueprints.
Now, the Agile approach gives you room to build even when you’re not 100% sure about everything. But as time passes, those “maybe” ideas can become stubborn problems.
For example, imagine an executive that thinks their data squad will update a particular file for an app. They expect it to work a certain way. But if the data squad decides to change things up, the app needs tweaking. If this happens too many times, it’s a headache.
On the flip side, successful apps are well thought out, tested, and tweaked over time. They start with small, achievable goals and grow from there. If an in-house team can’t meet a requirement, no biggie – we’ve got a plan. We can adjust our goals and shuffle our to-do list. We monitor our deadlines, understand what features we’re adding, and talk–a lot.
Instead of rushing to a big “launch,” we prefer a smooth journey from a basic version to a polished product. Oh, and we decide what’s next based on hard facts – like user feedback and data.
Teams that work at the highest level are as focused on interpersonal soft skills and quality interaction as they are on technical aptitude.
If you’ve been fortunate enough to experience successful projects, you won’t be surprised to see our most experienced leaders focus on communication, goal alignment, and trust.
Teams that work at the highest level are as focused on interpersonal soft skills and quality interaction as they are on technical aptitude. Flexibility in processes and adaptability are equally essential. Clear expectations, stakeholder involvement, and understanding of the big picture can significantly influence a project’s outcome.
When you can focus on your work with a low-friction process, you can better find a flow state where you can build a great product and understand where the product can go next.
Strong technical skills are essential for the delivery of products. Still, when you’re used to working with technically expert team members, you can look beyond a strong Javascript engineer with a sprinkle of AWS experience and find engineering leaders capable of fostering these soft skills to benefit an entire team.
That, by extension, benefits the project, stakeholders, and customers. These project leaders don’t show up, write code, and log off. They mentor other members of the team. They will facilitate communication both internally and with non-technical stakeholders. They can set up the most effective processes for the rest of the team, the client, and themselves to enable everyone to do their best work. This helps bridge the gap between the development team, clients, stakeholders, and customers, inevitably leading to a better product than simple engineering skills could ever achieve.
