While reading up on value and culture statements from various engineering organizations, one of the most common themes everyone seems to be striving for centers around consistent learning, curiosity, and/or personal growth.
Demonstrating commitment to this value often means things like offering professional development budgets, 20% time, finding a way to assess for candidates with a passion for learning, etc. While I agree these can be positive influences on the adoption of that value, they fail to take advantage of the many organic opportunities that exist for reinforcing it.
Values-based behaviors that can be woven into the day-to-day of engineering are easiest to define when you can latch onto small, specific act that can serve as a representation of that value. With respect to curiosity and learning, I like the idea of leveraging the question as that anchor to lean on.
A question is a fundamental, first step in learning something new, influencing change, and challenging what we think we know. Think about how many questions are asked within your engineering organization every day — during pairing sessions, PR reviews, team stand-ups, executive meetings, etc. Their frequent presence provides reliable and consistent opportunities to embody a value at every level of engineering.
If we want to put the question to work for us, we have to give it a little pedestal so that policies, processes, and standards can be built around it. Below are some of my initial ideas around how it’s done:
1. Expect questions rather than encouraging them
Think of the last time someone was giving you a brain dump of context you’d need to complete a complex task. Did they hand you all the information and then move onto their other work? Or did they invite you to ask follow-up questions?
When we don’t provide the invitation for people to ask questions of us, there’s an implied sense of “You shouldn’t have any,” which can lead to a sense of self-doubt, or wasted time and effort struggling alone. Ending with “let me know if you have questions,” can create a drastic mindset & collaboration shift right away, but I like to encourage folks to take it one step further, and expect questions:
- “let me know what questions you have”
- “I’ll be free at xPM to answer follow-up questions”
- “send me a list of whatever follow-up questions you have when you’re ready”
These are small tweaks in wording, but can make a huge difference in how people are expected to take ownership of their own learning and/or mentorship responsibilities.
Setting this expectation of ownership right from the start makes the onboarding process another amazing area for reinforcement. Most engineering teams I’ve worked on have had some sort of onboarding checklist for their new hires, which can provide a great opportunity for fresh eyes to create impact through their questions.
It’s easy for a new engineering hire to get hyper-focused on submitting their first PR or pushing their first contribution to prod, to prove their worth and potential impact. Instead, have their first deliverable focused around what questions they have as they begin to explore the systems, tools and processes at the organization. New hires tend to have some of the most enlightening questions that can prompt significant change, as long-term employees often become desensitized to pain points and areas for improvement.
Have a formal expectation set for them to share these questions with their manager or relevant leaders, expressing that this is their first major impact. Questions are the most valuable thing new hires can add to an organization right away, until they are well-versed enough in the systems and codebases they need to navigate in order to contribute code.
2. Define how to ask a good question
If we’re going to expect questions, we want to make sure we have some standards for how we go about asking them. An over-acceptance of questions can lead to a culture of learned helplessness — where people become less inclined to think critically about their problem before reaching out for help.
I’ve often told engineers: “Ask me anything, but come with your receipts: tell me what you tried, what your goals are, where you’re stuck, and what lead you to reach out to x person/team specifically.”
Providing written guidance on how questions should be asked ensures that they maintain their value and lead to positive outcomes. This is especially important when questioning policies and processes. Organizations put these things in place for a reason (safety, efficiency, etc.), and each varies in how accepting they are of being challenged. I personally believe any process and policy should be open to questioning, but again: you must have clear guidance on how to properly question these things. If modifying or removing a policy is the answer to some roadblock you’re facing, the receipts I’d ask for might look like this:
- what changes are you proposing & why
- are you asking for an exemption or a permanent change
- whose priorities will these changes benefit
- what alternative options might satisfy your current needs
- are we making any tradeoffs that need to be weighed with these changes
Questions that are crafted with upfront thought and care make them more likely to provide valuable feedback that can prompt change in the right direction.
3. Treat questions as feedback
Being on the receiving end of questions can sometimes get overwhelming, and I’ve seen the burden weigh heavily on lead engineers, support teams, etc. Our most common answer for reducing this burden within engineering is often related to writing docs and tests, which absolutely helps (as does defining how to ask a “good” question from above) — but I like to encourage engineers to always view questions as feedback. This mindset shift can help uncover useful ways to move forward.
Let’s say you have an engineer who asks a question that’s answered by internal documentation you expected them to have read. Instead of being frustrated they missed it, ask yourself “Is this is a signal that information is unclear, or needs to be made more obvious?” With just a single occurrence of the question, you might not have enough data to make that decision — and you don’t want to be impulsively reacting to every question with change. But let’s say that happens again with another engineer, and we start to notice a pattern. Maintaining this “feedback-first” mindset will help you more easily recognize these patterns when they appear, and keep your focus on what’s in your control to change. This leads to healthier working relationships and more intentional change rather than reactive change.
4. Celebrate questions as contributions
When ambitious efforts are successful — e.g. a big feature ship or refactor, a new process rollout, etc. — the celebration around them most heavily focuses on the people who did the hard work. (Rightfully so, IMO.) But I love when they also elevate the people who planted the seed — the people whose initial questioning and observations may have identified the problem, sparked the enthusiasm, and garnered the effort that led to success.
Questions are the catalysts for improvement and should be highlighted as such. Being able to do this requires a high level of consistent collaboration and diligence with historical record keeping. We’ve started doing this more thoroughly at Articulate through the use of RFCs and ADRs, which have been great outlets for nurturing a seedling of an idea into action, and have allowed us to maintain that bit of origin history so we can be sure to celebrate it later.
5. Enforce a cadence for cornerstone questions
In every role, there are some grounding questions that should be consistently revisited with diligence to ensure you’re continuing down a successful path. In leadership, for example, we must be constantly questioning if we’re working towards the most impactful things. Without dedicated time to question what we’re doing, it’s easy to get lost in the day-to-day details. This is a reactive way to be working, and puts up blinders that keep you on whatever path you’ve been working towards since the last time you checked in on your priorities.
If you don’t have a formal cadence for revisiting the cornerstone questions of your role, you’ll have certainly missed a left turn somewhere that may have lead to more impactful outcomes. Some questions I regularly ask of myself (and the engineering leaders my team works with):
- What is my team currently working towards?
- What originally prompted us to focus on these priorities?
- Has anything changed since then that make those guiding factors irrelevant? (e.g. are there new solutions for pain points that didn’t exist before, has a new process lessened the urgency for this priority?)
- What do we have starting to present itself as a ‘Next Up’ priority, and why?
- Is our current path still the most impactful for the organization?
- If not, what would it look like to switch gears? What tradeoffs need to be considered for that decision?
It’s most effective to do this type of questioning with a group, rather than isolation, to ensure accountability of how critically you think about your answers. On our own, we can be more easily convinced that we’re doing the right thing, especially when you might not necessarily have friction on your current path.
