A product manager, product owner, or engineer that has ever been tasked with taking the helm on a new website, app, or service understands that the paths to production—regardless of a defined end goal—aren’t always clearly outlined. Even in cases where the outline is clear, how do we know if the established path is the best or most viable?
It can be tempting to dive headfirst into development, but with an ever-growing cavalcade of libraries and frameworks, we suggest hitting the brakes. Instead, we recommend adopting a consultant mindset and crafting technical solutions. This strategy encourages carefully choosing an approach, the tools, and a strategy that will put the longevity of your product over being first to market.
At Sparkbox, a consultant mindset is how we, as developers, approach our products, projects, and clients. We call ourselves “consultants” because we are not only called on to help build products, but we also advise teams and present approaches and solutions based on specific needs. With this mindset, we are able to take a comprehensive look at the problems we (our team, our partners, and our clients) are looking to solve and propose strategies based on our collective experience of building a better web.
Defining a Consultant Mindset
A developer with a consultant mindset is one that challenges assumptions and emphasizes making the right decisions for right now—they don’t let past thinking wholly inform next steps. This can take shape in many ways.
For one, adopting a consultant mindset ensures you’re targeting the correct stakeholders during the onboarding process. This is vital because it’s where we, as developers, take our first steps toward building a product. Often, user interface designers are part of the initial discovery conversations, but what if we’re missing important representation from the engineering or information security departments whose input can affect how we approach selecting our tech stack?
Beyond the initial stakeholder meetings, a consultant mindset might help disrupt (for the better) routinized thinking. If engineers believe there might be a better technical fit for a product than a previously-selected technology stack, a consultant mindset could bring that better fit to the fore. Angular might be the default choice for a new web app at a company with an existing suite of Angular apps. But are there other established UI libraries like React or Vue—especially considering the growing population of experienced React and Vue developers—that might be easier to maintain?
A consultant mindset also allows for thinking about different time frames.
Thinking short- to medium-term: Can we use this as an opportunity to test out interesting or emerging frameworks, libraries, or languages that we might be able to incorporate into our technology portfolio over time?
Thinking medium- to long-term: Do we anticipate our selected technology to grow or stagnate in the future? How does this selection fit into the trajectory of the company’s long-term technical strategy?
A consultant mindset asks us, as developers, to take a step back from the project, take a holistic look at what we’re building, and ask higher-level questions. What problems does the project aim to solve, how does it integrate with the business, and what does its long-term evolution look like? It’s not just about using technology to build websites, apps, or services. Instead, it’s how we can creatively build technical solutions to address non-technical problems by choosing the best path forward among many.
Bringing a Consultant Mindset to Your Organization
Although organizations routinely associate the term “consultant” with an external advisor, a consultant is truly any person providing professional expertise. This means that you’re empowered to be a consultant in your own organization and apply a consultant mindset to your projects without the help of any external agency. You can start internally by asking questions like these.
Are we choosing the correct technology?
This is one of the most basic questions we find ourselves, as consultants, answering about engagements. There are many considerations when it comes to answering whether or not your chosen stack is the best selection.
To start, ask if your engineering teams have the expertise to work with your selected stack. If your team is used to working with PHP-based CMSs like Drupal or WordPress—and is selecting technology for a new frontend application—what selections can you make that your team currently has the capacity to support? Even if your organization’s long-term strategy is to move away from PHP, going with PHP-based frameworks for your backend HTTP-based APIs, like Laravel, might be a better choice in the short-term rather than going with something new like Node or Rust.
Keeping an eye on the future is important, but just as important is navigating the path in front of you. Too much change at once can cause a more rapid accumulation of technical debt and make iteration impossible. Choose stacks your team currently has the capacity to support and develop a plan to iterate after initial work has been completed.
Finally, be sure you’re choosing technologies that are embraced by development communities you trust. One of my favorite resources for gauging this is GitHub’s annual Octoverse report, which includes, among other things, favorite web technologies and languages used in projects hosted on GitHub. The web is a revolving door of tools and what once was in can quickly be out. Keep your finger on the pulse of technology to make sure you’re investing your time and intellectual capital wisely—embrace the evolving landscape.
Are there opportunities for exploration?
Of course, this question isn’t novel—but it might be one of the most fun! A consultant mindset pushes us as developers to ask: “How does the tech stack of this project fit into our organization’s technical portfolio?” Some of your favorite companies trial new technologies in small parts of their applications before widespread adoption. For example, React (originally FaxJS) was originally used by Meta, née Facebook, in a search feature on the newsfeed before more widespread adoption. With this mindset, you can adopt similar practices by looking for opportunities to explore and trial new technologies in small parts of your application with the option to expand their use within a project—possibly even within your organization.
If your team has organizational ambitions to migrate to different tech stacks, opportunities for exploration can also include dipping your toes into the technology you want to move into over the long term. For example, if your team is well-versed in Ember.js but you have long-term plans to move to a different frontend framework like Vue.js or React, are there places within your project where you can trial this new technology to get some experience? While the majority of the organization could still be using Ember.js, maybe the user-login flow or a settings page could test out some of the frameworks your team has a long-term eye on. If your organization is aiming to decrease its use of Ember.js and increase its use of React or Vue.js over the next five years, what choices can you make on this project that fit into that longer-term trajectory?
Does the solution treat the core problem or only the symptoms?
It’s not uncommon for eager teams to jump on a solution that treats the outermost exposed symptom of the core issue. Maybe the server hosting a series of HTTP-based APIs is frequently crashing from overload. Using this example, imagine the following exchange when asked why the server was failing:
Q: Why is the server crashing? A: It doesn’t have enough resources.
It seems we might have a good set of next steps. So, let’s allocate more memory or upgrade to a beefier CPU. We can treat the symptom and try to allocate more resources or implement load-balancing, but does that treat the root of the problem?
A better, consultant mindset approach would be to make sure you’re solving the core issue by implementing The Five Whys. This approach was originally used in Toyota’s manufacturing process and was designed to get to the root of a problem. This system of prompts requires you to repeatedly ask “why” up to five times to get to the root of the issue. Let’s revisit the original question, applying the Five Whys:
Q: Why is the server crashing? A: It doesn’t have enough resources
Q: Why doesn’t the server have enough resources? A: Because the API requires more resources than the server can offer
Q: Why does the API require more resources than the server can now offer? A: Because the APIs are computationally expensive
Q. Why are the APIs computationally expensive? A: Because the API architecture is built to handle many different types of large requests from the application
Q. Why are the APIs so bulky? A: Because they had to be built quickly and when originally adding support for these services, scalability wasn’t taken into consideration
After this exercise and asking “why” only five times, it’s revealed that maybe the core problem is that the APIs themselves are too resource-intensive, possibly because they were created hastily. Instead of allocating more resources to the server, other solutions could be explored, like microservices that might offer better performances by breaking up larger monolithic requests into smaller, more nimble ones. By moving into a consultant mindset and repeatedly asking “why,” you’re able to move past the superficial external markers of a root issue and navigate directly to the cause.
Sparkbox’s Experience in Providing a Consultative Mindset
Over the years, Sparkbox has worked with countless partners to build websites, web services, and web applications. Each project has had its own set of technical problems that required a consultant mindset to solve. Here are three engagements that highlight how having a consultant mindset led to success.
Selecting the Right Technology for the Present
A multi-billion dollar manufacturing company approached us with a simple project—they wanted to build a mobile application that could be distributed in the Apple App Store. However, their team didn’t have the engineering background to use native mobile technologies like Objective-C or Swift. The client was originally interested in using a low-code solution, but we had some concerns that this wouldn’t actually give them the flexibility and technical level of control they were looking for. We also had concerns about the long-term stability of the application being tied to a specific PaaS. So, we approached the client’s project by suggesting a different, more tailored solution using React Native.
Read the Case Study on Selecting the Right Technology for the Present
Evolving Solutions and Fortifying Boundaries
An autonomous vehicle company knew they needed help from experienced developers to build an application that would be used for tracking vehicles on their routes throughout a warehouse. What they didn’t know was this application was the foundation of a deployable component library that could be used for additional applications the company was seeking to build. Read about how we helped our client succeed beyond our engagement in Jon’s case study Evolving Solutions for Our Client’s Futures.
Read the Case Study on Evolving Solutions and Fortifying Boundaries
Making Technical Decisions for the Future
How can technical decisions made now pave the way for a long-term project? When the subsidiary of a multi-billion dollar services company approached us to work on rebuilding a legacy application in a modern framework, we knew that we had to carefully consider the tech stack and processes—it would have to survive a long-term build. To set the client up for success, we chose frameworks and languages that would be familiar to a team of backend developers and an iterative process that would allow the existing application to be used alongside the newly-migrated one.
Read the Case Study on Making Technical Decisions for the Future
Develop Your Consultant Mindset
Taking on the mentality of a consultant developer in your organization will undoubtedly lead to successful solutions. As engineers, it can be easy to focus so much on the technical challenges that come with writing code and building a project that we lose sight of the core problems the technology is there to solve. That’s why it is important to prioritize stepping back and ensuring that you’re making the correct decision—even if it’s not the quickest or most convenient. This takes time and can temporarily slow down or even halt the progress of your project, but the alternative risks long-term success for short-term velocity.
So what can you do now to be a consultant within your own organization? You can start small by looking for opportunities to incorporate technology or frameworks that have the capacity to improve the technical direction of your organization. Maybe you’re on an older project with disorganized CSS and could migrate to Dart Sass. Or perhaps you’re building a new application that will consume data from an old monolithic HTTP API and you think this would be a good opportunity to migrate to microservices. No matter the scenario, a consultant-minded developer feels empowered to examine previous thinking and propose new tailored solutions that set your project up for long-term success. The web is a perpetually-changing landscape of tools, frameworks, and languages. By embracing the mindset of a consultant developer, you can guide our present-day decisions by looking to the future.
