February 21, 2023Developer confidence is a fickle beast. Too much confidence in your development team can lead to a lack of strategic oversight and shoddy QA. Too little confidence, and you’ll end up micromanaging your team to death. But either way, developer confidence is crucial to the success of any software development project.
But how can you tell how confident you ought to be in your dev team?
By definition, if you’re spending time, money and resources on a software development project, you’re going to have questions. Second guesses even. You have to! These solutions are often expensive to build with pitfalls looming all over the place — and decisions you make now could blow budgets, timelines and mission-critical features months or years down the line.
So how can you tell how confident you should be in your team?
We just did an ENO8 Answers webinar about this, but I want to break down some of the higher-level points here in case you haven’t watched it yet.
Just to be clear, we don’t mean how confident your development team is in their abilities — we mean how confident you as the business stakeholder are in your dev team.
It’s also worth noting that it doesn’t matter for purposes of this exercise whether your team is all in-house, fully an external vendor, or some version of a blended team… the takeaways apply across the board.
For this exercise, you need to be brutally honest for the results to be meaningful. We’re going to give you 8 questions to ponder, and you’re going to score your team on a scale of 1 – 10.
10 is perfect: You have 100% clarity and 100% confidence in your answer to the question.
1 is the opposite: You have no clarity whatsoever and your confidence is rock bottom.
5 is obviously in the middle: You have decent clarity and decent confidence, but could be a lot higher.
At the end of the exercise, we’ll add up all your scores and provide a scorecard with actionable intel.
How clear are you on your product timeline?
How confident are you in actually hitting it?
By this I don’t just mean, “do you have a product timeline with benchmarks on it?”, but rather, “how clear is that timeline? Are there measurable KPIs you can access on demand? Has this team or this vendor nailed their timelines in the past? If you don’t have a history with them, what do their prior clients have to say about their timeliness? How much transparency and specificity is baked into the timeline? Is there clear reasoning for why those are the benchmarks and why it’ll take that much time to meet them?”
Questions like that. So, grade your project and your dev team on a scale of 1 – 10 — and remember… be honest!
How confident are you that your architecture plan is solid?
How confident are you that it won’t need a significant rebuild or refactor in the near future?
If users end up loving your software, can you handle a major influx of new users? Most importantly, can you handle that influx without having to re-think or rebuild the whole software solution? Again, do you have a track record with this team or this vendor of building scalable solutions from the jump? If you haven’t worked with them before, do they have a deep stable of similarly sized software solutions against which you can compare your solution?
Again, rate your team on that 1 – 10 scale.
How confident are you that the advice or insight you’re getting from your team is unbiased and accurate?
One of the biggest red flags for me is when I have a question for my dev team, do they always have a ready-fire answer? Because I want them to have to say “I don’t know — I’ll get back to you” sometimes. This admission actually builds my developer confidence. That means they’re not blowing smoke all the time. I’m more confident when I feel like I’m getting honest answers, which often include a version of “I don’t know, yet.”
Likewise, how much do I believe that the advice they’re giving is best for me and my project and not what’s best for them? E.g. are they just trying to throw more developers at the problem in order to increase billing? Or is that the actual staffing required to deliver the solution?
You know what to do now… 1 – 10.
Do you know exactly how much money it’s going to cost?
Do you know how much each stage costs on its own?
This is more about transparency and specificity — how did the team give you their forecasts? How did they arrive at that budget? What was that determination based on? How granular is the cost breakdown? Can you see it by line item or by development stage?
These are the types of questions you’ll want answers to in order to score highly on this one.
Does everyone involved in the project have the same vision?
How sure are you that everyone is working toward that shared vision?
It’s very common that developers will work on something, and they’ll make decisions and implement solutions that might not be in alignment with the founder or the product owner. They’re trying to solve a problem, but it might not be aligned with what you or your end users are actually going to want.
This is where Figma prototypes can be invaluable.
When you kick the prototype over to the developers, they see exactly what’s expected to be built. Then you’re both working from a common play sheet.
1 – 10 — write it down.
How sure are you that you own and control your product artifacts?
You would not believe how often we see this happen — a company hires a development vendor, the vendor builds a solution for the company… but the company doesn’t actually own the source code. Or if the vendor used a code library, the company doesn’t have access to or vision into the actual modules being used in their software solution. This can be something as simple as, do you maintain the actual master credentials to AWS or Azure? Is your project management software (e.g. Jira) set up in your company’s name?
These can be simple questions, but you would be shocked how often we see companies score low here.
Gimme that 1 – 10.
What is your next validation gate?
How confident are you that you’ll hit it on time, on budget and with sufficient insight to move on?
First of all, what is a “validation gate?”
It’s the least amount of resources and effort to get maximum validation at key points along the development process.
Instead of focusing on an MVP, which is often bloated, expensive and messy… we focus on a Minimum Lovable Product — by chopping the development process up and being clear on your validation gates, you’re checking yourself at each step of the way before you write the next check or you make the next commitment.
We’re almost home — second-to-last 1 – 10.
How confident are you in your Minimum Viable Analytics (MVAs)?
How sure are you that you’re meeting them? Or that you’re going to meet them?
What are MVAs? KPIs or metrics that prove you’re doing what you set out to do. These are based in real analytics, not just ~*vibes*~.
Do you have MVAs actually built into the product and its development lifecycle? Are they accurate? How do you know if they’re accurate? What is your dev team basing those analytics on?
Are you hitting your thresholds?
Final time, hit me with a 1 – 10.
So you have 8 scores on a scale from 1 – 10 measuring your developer confidence. So, what does it all mean?
Like we said at the top, if you have more questions or need more clarification on any of these points, check out the webinar we’re going to post pretty soon (or just reach out to us). I go into a lot more depth on each of these points there.
That being said, here’s how we think about the cumulative scores and what they mean for your project:
And what do the scores really mean?
Like we said, based on where you land on here, you should have some actionable insight on what to target for improvement. Or, it should give you the confidence to keep doing what you’re doing… or to pull that ripcord sooner rather than later.
All of this underlines why our Innovation Lab is such an important step for any potential client or partner we’re thinking of working with. We dig deep into their challenge, wade through anything and everything that’s been developed or worked on to date, and deliver a comprehensive set of plans and instructions on how to achieve what you want. This includes detailed budget projections, realistic timelines based on real-world experience, staffing recommendations… the works.
If you have neither clarity nor confidence, your project could be doomed. Let us help you achieve both.
Jeff Francis is a veteran entrepreneur and founder of Dallas-based digital product studio ENO8. Jeff founded ENO8 to empower companies of all sizes to design, develop and deliver innovative, impactful digital products. With more than 18 years working with early-stage startups, Jeff has a passion for creating and growing new businesses from the ground up, and has honed a unique ability to assist companies with aligning their technology product initiatives with real business outcomes.
Sign up for power-packed emails to get critical insights into why software fails and how you can succeed!
Whether you have your ducks in a row or just an idea, we’ll help you create software your customers will Love.
LET'S TALK