00:00:09.599
My name is Paul Elliott, and I work for Hashrocket, a Rails consultancy in Jacksonville Beach, Florida. My role there is as a consultant and programmer. I previously worked in the enterprise sector doing Java web development, where I was part of teams that were quite similar to the teams I work on now, always interfacing with business stakeholders and non-technical people. I never really considered myself a consultant until it became a formal part of my job when I started working at Hashrocket. In hindsight, if I had recognized my role as a consultant earlier in my career at larger product shops, I believe all my interactions would have gone better, my projects would have been more successful, and I would have built better relationships with the business people I worked with.
00:01:01.079
When most people hear the word "consultant," they picture individuals like the characters played by Bruce McCulloch, the Bobs, from Office Space. I remember when I told my mother-in-law about my new job at Hashrocket and my role as a consultant; she asked, "So what do you guys do in big companies?" That really isn’t the right way to look at consulting. While the characters are a joke, companies do hire process consultants who come in to analyze how teams work with the intent of redefining those processes to make them more efficient. After spending months assessing, these consultants come back claiming to have developed a brand-new, state-of-the-art software development process, often coupled with custom software they plan to sell to us. They promote this to the product team, explaining how their newly structured process will dramatically reduce the timeframe from two years to just six months.
00:02:09.679
However, what they essentially deliver is a polished version of the same waterfall process we've been using. They don’t offer any real consulting; they merely continue the same ineffective practices that put the "con" in consulting. I'd like to change that stereotype because a consultant, in the broadest sense, is anyone who offers expert advice professionally, and this can encompass many different fields. This certainly includes all of us, as we are all experts in something, likely in something technical, whether it’s web development with Rails or another area of expertise.
00:03:10.360
Consider, for example, a coffee shop. I regularly drink Americanos, which are just espresso and water. If I walk in during the fall, craving something festive despite Florida’s unseasonable warmth, I might ask, "What would you recommend?" The barista might suggest a pumpkin spice latte, a festive option, and just like that, he’s acted as a consultant by advising me with minimal input. This scenario mirrors what we do; he didn’t see himself as a consultant, but he essentially fulfilled that role. Think about another situation: you take your car in for servicing. The mechanic examines your vehicle and explains, in technical terms, why it's not running smoothly. As the layperson, I'm most concerned with whether it's going to be fixed, rather than the specifics of all the technical details he provides.
00:04:05.079
Similarly, when you take a taxi in a new city, you might be asked if you'd prefer the toll road or the highway. The driver knows the routes better than I do and could easily make that decision, saving me the trouble of thinking about it. This is a common situation where the expertise should be with the consultant, and if properly managed, it can allow for a much smoother experience for both parties. In our field, we are often a passionate group, full of opinions, and we've trained ourselves to break down complex ideas into manageable solutions. Yet, we risk forgetting that our clients may not see the nuances and complexities of what we do. For instance, when I was approached by a potential client who wanted to create a software platform for people to pay for restaurant reservations, my instinct was that it was a ridiculous idea. My perspective was biased by my lifestyle; I seldom make reservations as a busy parent.
00:05:32.880
However, as a consultant, I needed to overcome my biases and engage her in a meaningful way. By asking targeted questions about her business plan, I learned that people were already offering cash to hosts for better reservation chances, which indicated a market existed. The relationship began by showing genuine interest in her business, even if it was outside my typical experience. Building that relationship based on understanding and asking the right questions is vital for establishing trust early in our engagement. One critical aspect of being an effective consultant is owning that role and managing the relationship proactively.
00:08:15.919
Clients typically come to us trusting that we can provide expert advice, based on the compensation we receive for our services. It's critical to uphold their trust and build a constructive relationship, even when the situation is challenging. There are times when you must push back against their ideas because they can come up with unrealistic requests, like suggesting a levitating keyboard in an application. It’s our job to guide them toward feasible solutions without sacrificing the project’s integrity. For instance, I once had a customer who insisted on adding FTP capabilities for their complex JavaScript system. My reservations about FTP’s brittleness led me to question this approach, but they were deeply set on this method, citing their enterprise clients’ preferences. Recognizing when to push back while keeping the relationship intact is essential. Sometimes, it's necessary to step back and concede rather than continue a fruitless debate.
00:09:20.800
Later, the same client needed to allow a single enterprise customer to whitelist certain IP addresses, which created a larger conversation. I suggested using SFTP instead for its enhanced security. This was more cost-effective and demonstrated our care for both their interests and those of their clients. By presenting a better solution, we helped build trust, showcasing that we were looking out for their best interests. Scope creep is another common challenge; I experienced this with a startup founder who was constantly updating us with demands for new features outside the MVP requirements. After repeatedly insisting on focusing on the MVP, we noticed she began disengaging entirely, which ultimately jeopardized the project. Instead of allowing this negative cycle to continue, we shifted strategies to focus on listening rather than dismissing her ideas with a flat ‘no’.
00:12:01.679
Reengaging her by being more open to hearing new ideas drastically improved our relationship and kept her involved in the project. Even when she shared unlikely suggestions, like pitching her app to well-known figures, our interjections became constructive dialogue rather than obstacles. The language we choose carries substantial weight; during another project, when a team member expressed dissatisfaction about the quality of the code, it reflected poorly on our abilities. Instead, our communication could have framed the scenario positively; we could have stated we had explored multiple options and successfully established a solid solution, rather than framing it as a failure. This approach fosters a healthy environment where clients understand that struggles are part of the development process, yet still perceive progress.
00:15:05.440
We also operate under a principle I refer to as the "unified front," wherein we do not engage in discussions or disagreements in front of clients. Presenting a cohesive team image upholds their trust and confidence in our operation. Prior to meetings, we share potential questions and ensure thorough internal communication to avoid redundancy. This builds rapport as it shows professionalism. Similarly, we reference the concept of Goldilocks, where information presented should neither be overwhelming nor underwhelming. Each stakeholder interacts with us from a different context and their interests vary. For example, project managers are often focused on timelines and progress, while business stakeholders may only care about delivery dates.
00:18:24.320
I once made the mistake of overcommitting to technical details about MongoDB, leading to wasted time for both me and the client. It became clear that it is far better to provide succinct, relevant information tailored to their interests. Keeping discussions brief and on-point helps clients see you as efficient rather than as someone who is wasting their time. In many ways, software development can mirror TV cooking shows, where chefs often critique menus that are overcrowded with options. Applying this to development, presenting a set of solutions that include both good and poor options confuses clients. Instead, leading with a singular, superior solution upholds both trust and clarity, allowing the consultant to shine.
00:21:32.240
Consultants should strive to create optimal solutions rather than merely fulfilling requests. When the US sought to go to the moon, the NASA team oversaw complexities when trying to innovate. They created expensive tools rather than consider simpler solutions other organizations did. In some project cases, clients articulate complex needs, only for us to find simpler pathways that achieve their goals just as effectively. A recent example involves a client who anticipated an elaborate payment solution for their exclusive services. Upon further inquiry, their actual need was simply to accept credit card payments, leading me to propose a straightforward solution that saved time and money without complexity.
00:24:30.560
As a consultant, you are primarily an expert in your client relations. Much of your work hinges on understanding their true needs and pivoting away from unnecessary complications. Building trust and demonstrating that you're looking out for their best interests will significantly impact your long-term relationships. As consultants, how we relay information is crucial. It requires understanding and adapting to different stakeholders’ needs; business stakeholders prefer high-level summaries while developers favor technical depth. Accepting these roles allows projects to unfold more smoothly and ensures everyone is aligned. Remember, focusing on their contexts builds a success-oriented partnership. Ultimately, your role as a consultant is not just to provide solutions, but to create a strong bond based on trust and mutual respect.
00:28:16.679
Thank you very much for coming to my talk. I welcome any questions or comments you might have, either now or during the conference. If you prefer to reach me later, feel free to email me as well.
00:30:07.440
Furthermore, when dealing with more technical clients, I absolutely provide more detailed explanations. It's vital to consider their expertise and interest levels, as I typically lead with as little information as possible, preparing to elaborate when necessary. This keeps meetings focused and productive.
00:30:40.480
Indeed, addressing IT technicalities with tact is significant, and sometimes an additional stand-up meeting may be required to discuss that in further detail with your team, ensuring everything is synchronized before client-facing discussions.
00:31:30.840
Balancing discussions effectively with your colleagues is essential, and maintaining that unified front protects team integrity.