18F guide to consulting engineering
Over the past few years, 18F has moved from a product organization (“we’ll build a thing for you”) to a consulting organization (“we’ll teach you to build, buy, and maintain a thing yourself”). We’ve found this to be a better fit for us and for our partners; it lets us consider not just tech but the systems in which tech operates, and it helps our partners practice the skills they need to keep building on our work long after we’re gone.
Consulting organizations need consulting engineers. These are people who can straddle the line between strategy and engineering, and who can bring their software engineering experience to bear on understanding and solving a broad range of partner problems. They’re not “developers who consult;” they’re “consultants who code” — people who can team up with with, coach, and mentor their partners.
As a consulting engineer at 18F, you’ll need more than just your technical background. You’ll also need empathy, quick understanding, and solid communication. You’ll use these skills to listen as the partner describes their pain points, dig in to understand them, formulate a hypothesis quickly, and explain to the partner how testing the hypothesis can get them closer to a solution. And you’ll need to be able to explain the outcomes and make recommendations for next steps. All of these skills are things that can be learned, practiced, and developed.
At first, this can be difficult, especially for engineers who are used to very concrete and tangible solutions. Consulting engagements by their nature can feel very uncertain, vague and fuzzy. They may have a different definition for success than “a thing was built.” But your teammates and partners will be looking to you to create clarity out of that confusion and propose actionable solutions. That’s the core of what being a consulting engineer at 18F requires: you may never write a single line of code on a project, and that’s not a bad thing.
Working this way may be different from what you’ve done in previous roles. But the skills you’ll need to be a great consulting engineer are all learnable — and you don’t have to learn them alone. Whether you’ve been a consultant for 25 years or you’re starting from day one, 18F will support you as you learn our particular approach to engineering consulting. And that starts with this guide.
Qualities that will make you a great consulting engineer
- Strong communication, empathy, perspective-taking, and collaboration skills. That means:
- Helping people realize and accept hard truths
- Negotiating stakeholder buy-in
- Delivering bad news compassionately and voicing discomfort early
- Teaching and mentoring
- Speaking confidently while remaining humble
- Strong principles, from which you can quickly reason and act within partner situations, tempered by a willingness to compromise where appropriate. That means:
- Working rapidly with the information you have and making confident choices.
- Biasing toward action, even if the final destination isn’t yet fully known.
- Keeping an agile mindset — just as you iterate on your code, you stay flexible in engagements.
- Being willing to experiment quickly, fail gracefully, learn through action, adjust and move forward.
- Acknowledging the legitimacy of organizational, political, monetary, etc. factors to influence technology choices.
- A willingness to let go of platform snobbery. That means:
- Being willing to engage with legacy technologies.
- Digging in with partners to understand the platforms and systems they have now.
- Being open to using less desirable platforms due to partner staff capacity or integration needs.
- A willingness to try non-engineering things. That means:
- Helping with research or gathering user feedback
- Contributing to the overall project strategy or facilitating workshop activities. Embrace these opportunities. You can learn a lot, and you’ll become a better engineer.
- Being resilient despite situations with ambiguity and project setbacks.
- In government, many people say “no” and the people with the authority to say “yes” may be hesitant to make that decision or may set a high barrier for their approval.
- Build an understanding of the reasons for “no” and seek creative, compassionate ways to turn it into a “yes”—but recognize that in some situations, you just might have to accept the “no” and invest your effort elsewhere.
- A drive to find accomplishment in empowering others to succeed and to hand off ownership. Ask yourself, “When I leave, will the people who I’m working with be able to own this?”
What skills do you bring to consulting engagements?
You bring a wide variety of needed skills and perspectives to a consulting engagement. First and foremost is your up-to-date knowledge of how to develop software following modern best practices. Partners who spend their time maintaining legacy systems may not know what’s now possible, either in terms of development methodologies or in terms of modern software stacks. Our expertise can help seed ideas for new ways to solve their problems as well as help them avoid common pitfalls.
Another significant role engineers can play in consulting engagements is to demonstrate concepts through functional prototypes. Showing partners how they could do things, rather than telling them, is most effective at demonstrating the value of agile and user-centered development.
You can also be highly effective bolstering the qualitative data being gathered through research and user interviews. Most engineers tend to be very good a pattern-spotting, finding the sticky piece(s) in large systems, and analyzing available data and visualizing how things fit together. These are all highly valuable skills in a path analysis team.
Finally, by involving engineers in consulting engagements, we have the opportunity to help set the direction of a project from the beginning. This allows us to have more leverage on big efforts by using small, early, engagements to influence where we put our larger efforts moving forward. This will result in builds that are better focused on solving the problems our partners face.
Working with your team and partner
First, keep in mind the principles outlined in How We Relate to Partners and always work with trust, respect, value, and collaboration. As the technical specialist on the team, also realize that people will look to you as the expert in the room and expect you to quickly understand the partner’s problems, land on potential solutions, and to be able to present them in a respectful and helpful manner.
The classic engineering belief that being super blunt is always the best approach is probably not going to be effective. A little diplomacy is very helpful. That said, trust your instincts and don’t be afraid to gently disagree with the partner.
You’ll also need to respect the diversity of skills and backgrounds on the engagement, both on our side as well as the partner’s side. You may be the only software person the partner engages with, so it’s important to respect and value all the other perspectives you’ll encounter. The problem that a partner describes may not be the one they really need to solve, but it’s the one they experience, so honor that.
Also remember that you’re not doing this alone! You’ll be able to bounce ideas off others on your engagement team as well as ask for feedback from the engineering chapter #dev.
Resources at your fingertips
On a consulting engagement, you may often find yourself operating on the edges of your expertise or exploring areas that are unfamiliar. That’s OK. You have a pretty robust support net.
Everyone at 18F who works with partners can consider themselves “in consulting.” This means there’s a lot of value to be found in project or chapter discussions across the whole organization. Don’t hesitate to join Slack channels or attend meetings that will help you broaden your experience with 18F projects. The below resources will offer a lot of context for the partner-facing and organizational challenges of consulting projects:
- #path-analysis (archived, but still has valuable history)
- Project Artifacts repo
- #c-consulting (and its regular meeting)
If it’s a technical issue outside your wheelhouse, talk with our specialists. They’ll be happy to help you find a solution:
Don’t hesitate to call on the Acquisitions, Content and Design Chapters as needed, either. They have guilds and labs specifically aimed at helping you.
Also, don’t forget about our portfolio of existing solutions like Cloud.gov, Login.gov, and Federalist who may be able to offer useful services to your partner. If you think they might be able to help, talk to them.
Keeping your skills sharp
Because consulting engagements may have relatively few opportunities to code, you may find yourself looking for opportunities to sharpen and expand your skills. If so, some options you might want to look at include:
- Billable projects — Cloud.gov and Login.gov often can use some extra help across a broad range of skill sets. Check their staffing issues.
- #microrequests may have a small (less than 12 hours, usually) project that needs some engineering help
- Non-billable projects — talk with your supervisor about pitching in on an internal project like Tock
- Give a tech talk or participate in some guild efforts
- Self-study and other professional development opportunities
What will engineers get out of this work?
Consulting engagements provide the opportunity to have a huge amount of impact, and when engineers are involved early, we have an opportunity to evangelize the technical topics we believe in, help set the framework of the solution, and help set the tone of the conversation. By providing technical backing for the early recommendations, you have a chance to show our partners the value of the techniques we believe in.
You’ll get a chance to test and validate the depth of your knowledge as you share and teach. Talking about things you may consider part of the basics gives you practice in communicating complex ideas and connecting those ideas with a broader picture.
These projects are also a chance to learn new skills or make leaps in old ones. Client communication and rapid prototyping, project scoping and problem analysis, pattern recognition skills and human (soft) skills are all areas for growth. These skills can be valuable for developing architecture and system design capabilities as well as for your career growth.