Learning good habits by watching a staff software consultant

What is good software consulting?

I recently started work with my fifth client team since joining Test Double as a software development consultant. Each client engagement has been absolutely different, presenting an amazing learning experience and an entirely different set of challenges. They have also entailed very different onboarding experiences based not only on the culture of the companies but also on the scope and staffing of the engagement.

I built up my own notes, playbook, and values for what makes a successful onboarding for me. Joining my most recent client, however, was the first time I started an engagement along with a Test Double staff engineer with 8 years of consulting experience. During this onboarding in particular, I benefited from observing and noting from afar how things go and how the engagement is shaped from the beginning.

The opportunity to watch and observe an experienced Test Double Double Agent lead the way has given me some insight into the consulting process—and I wanted to write up some thoughts and notes from the perspective of the less experienced member of the team. Sometimes we see things differently than the one driving the behavior, but sometimes we also notice things that are typically unnoticed because they are good consulting habits that don’t rise to the requirement of observability.

Kevin

So who is this Staff Engineer I speak of? Why, he goes by the name of Kevin Baribeau, and has been at Test Double for eight years. Kevin has worked with many, many, many clients in many, many, many different engagement environments. Having done lots of reps on starting new clients and being an empathetic human being makes him a wonderful software consultant to learn from.

A quick note on consulting at Test Double

One of the interesting things about working at Test Double is there is not a set playbook for how we engage with clients. We work to be as impactful as possible, help teams where they are, delight them, and deliver great software with the rest of the client team. It can sometimes feel like it’s pretty much up to you to figure out how to do any of that. And while that’s a good thing because we value letting people closest to the problem own the solution, it can also be scary!

Further, because the engagements are so different—from staff augmentation to education to team formation to greenfield work—a prescriptive play-by-play, laundry list of things to do as a consultant seems fairly guaranteed to fail quickly. Which is why, in part, such a thing does not exist around here! So no playbook, lots of differing requirements, high standards to live up to … woah! What I am supposed to do here? It’s my hope that shedding light on others’ approaches can help us all develop our consulting tool kits.

A Staff consultant approach to week one

Pre-work

Before starting an engagement, you will typically have the opportunity to meet the client, do some research on their business and learn about their team. During my meetings and interviews with the two client-side stakeholders, I was busy selling myself and Test Double. I also had some of the usual jitters around an interview process, even though I use that term lightly. It was a friendly discussion more than anything where we discussed my experience and what they were looking to add to their team. As a result, I took very few notes about the business, about the engagement priorities, and only captured the basic outlines from memory after concluding the calls.

Kevin, on the other hand, exited his “interview” having done more interviewing of the client than vice versa—or so it seemed to me! He had captured in his extensive notes details around the business, revenue numbers, timelines, a rough cast of characters, as well as specifics around their tech stack and requirements for us to consider during our engagement. He had armed himself with the tools needed to create impact at the client early on and he then used that understanding to leverage the first week of work.

The get started task

A lot of times when onboarding, either as a consultant or as a full time employee, you will get a semi-trivial initial task to get started with. This is great in that it helps give your installation and setup of the code base a purpose, your initial code-explorations some structure, and gets you into the work stream of your team.

Kevin has an approach to this: Get that first task done as fast as possible. And also as well as possible. And if you can do any extra work, do that too. Just as long as you do it as fast as possible.

The reason for the speed is that this is your first opportunity to build trust on your team. If you come out of the gates like gangbusters and get a quick ticket under your belt, your team members and client-side manager are more likely to value you and consider you able to participate on the wider team.

Funny, my whole life I’ve been doing it wrong! Looking at the first ticket as a learning experience for oneself vs. as an opportunity to solidify membership on the team is a very different lens and has a very different impact on your ability to contribute over time.

Understand the primary focus

With the Get Started Ticket down, it’s time to get to the real work. The way I saw this manifested was in a conversation with our client manager. Kevin informed him of the first work being completed—faster and more completely than initially expected—and opened the door to having a serious conversation about how we were going to move into the primary focus of our work.

In my experience, Test Double sometimes does not have a lot of hard definition around the scope of work that we are going to tackle on the delivery side. Don’t get me wrong, there’s usually an area of need or a challenge the team is facing. But it is part of the expectation that what we do is help identify with the client where we can be helpful and how we can contribute.

Still in the favorable light of a quick win, Kevin was able to pull out those detailed notes from earlier and get down to business with the engineering manager discussing how we will contribute further and where. At this point, the conversation is still high level and vague, pretty much as it should be, but with the beginnings of a shared understanding and trust from the team. This then leads to the next phase I observed, define a consulting MVP.

Define an MVP

In the absence of the aforementioned “hard definition” around scope, it is important to define some specifics around what’s next. A lot of people, myself included, might be happy to leave that first Primary Focus meeting with an action item of “Do More Research.” Kevin on the other hand was really focused not just on understanding how the Primary Focus will have impact on the business as a whole, but how he could break down the vague task into specifics—right there on the call.

Moving from understanding the primary focus at a business level to being able to define a first draft of an MVP code and team deliverable is not easy. One of the advantages of the way Kevin handled that specific aspect of the conversation was by not making it final.

Phrases like: “For an MVP we could expect to have X, Y, and as a stretch goal Z” helped involve the client manager—and crucially helped define a finish line for how we could talk about our own success at the client.

“Is X sufficient for 1.0 or do we have to have Y to go live?” was another phrase Kevin used to leave the door open to both explore the problem as well as further define expectations.

Lay out next steps

Laying out next steps is a crucial follow on from having a defined MVP. This is not just giving ourselves as software engineers a path forward, but gives us immediate touch points for how to follow up, telegraph progress, and measure incremental success.

This step also served as a way to wrap up understanding of the focus, the MVP, and confirm that we were all working toward our goals on a path that we understood and agreed to.

In addition to setting ourselves up for success, I also understood this as the first of a few steps underscoring that we were able to work in a self-directed manner. In the same way that a client may not know if you can accomplish a small task or how you will accomplish it, they also may not yet trust your ability to be self-directed and motivated. Setting out these next steps has an accretive effect on trust. It’s an additional demonstration to the client that they have made the right decision by deciding to work with you and with Test Double.

Propose a solution

I see this step as optional, because of course it depends on how you are able to pattern match between the MVP and the next steps based on your own experience and arrive at an interesting and potentially valuable solution. It also helps to pursue good ideas from other people who don’t have time to make them happen. That is, after all, why they hired us!

In my situation with Kevin, he was able to very quickly identify a potential solution to the problem of too much work happening in process: nightly sidekiq jobs instead of event driven syncing of information. Kevin again demonstrated knowledge and experience by quickly and directly suggesting a solution to an unaddressed problem.

This, I guess, might be the riskiest communication to date. If you are off-base with your previous understanding of the Primary Focus and the MVP, or if you do not have the experience to recommend not only the next step but the right next step, you risk subverting the little trust that you have just built. Remember, a beginning is a very delicate time! This is where those reps come in as a Staff Consultant and having built up that experience across many different clients and businesses—you can rely on that past experience to guide you to making valuable and on-point suggestions.

Generate a public list of tasks

This is another step to demonstrating through action that you know what you are doing, have confidence in your now defined approach, and deserve the trust of the client. The key aspect I would call out here is that this is a public list of tasks. Working alone or in a silo against a project that doesn’t yet have visibility team wide, puts you very much at risk of being thought of only as an outside contractor rather than an embedded member of the team.

Engaging with the client’s process planning, ticketing tools, and timeline estimation has the added benefit of getting you on a footing where you can very quickly start to understand aspects of their software development life cycle and better understand client needs from a process and consulting perspective.

Conclusion

The first week of this engagement has served as a template for our work over the first month with the client.

• Iterating on the process of getting tasks done, defining or redefining the MVP
• Staying focused on having a goal that we can complete
• Exploring options and conducting research to clarify next steps
• Tracking those next steps somewhere visible to the whole team
• Working openly in public

These are all components of healthy, agile software development! And it’s no surprise given the process we started off with. Trying to put all this together, I have created for myself a little cheat sheet for an operating manual for starting my next new engagement:

1. Interview for impact
2. Nail the get started task
3. Drive towards understanding in your first 1:1
4. Define and agree upon a deliverable with a time frame.
5. Lay out next steps
6. Propose big picture solution
7. Work in public

There’s nothing magic about any of this. And these are all steps any software engineer can use to become a better consultant or even more impactful to their current engineering team.