Can “not having the answers” actually be your greatest asset?
I was in over my head. Big time.
Standing in front of Packback’s engineering team, I tried to look semi-composed while I explained that our Head of Engineering was leaving and I was being asked to step in as the interim Head of Engineering.
As a designer.
With no coding experience.
And barely any management experience.
I could feel my hands shaking as I talked, and I wondered, “Why should they believe in me, if I don’t even believe I can do this?”
I am the cofounder and the Chief Product Officer of an education company, called Packback.
In 2016, we had just launched the MVP (“minimum viable product”) for our new platform when our Head of Engineering, Karl Hughes, shared the news with myself and our other three founders that he was moving on to his next startup…in two weeks. To say that I was panicking when I heard the news would be an extreme understatement.
At the time, we had a tiny product and engineering team. Outside of our departing head of engineering, we had just three full-time engineers, plus myself as our then-head of product. I truly didn’t know how we would manage and keep the product afloat if we lost Karl, who was both our engineering leader and a critical and beloved part of our team.
Though I was not an engineer, I was asked to step in and manage our engineering team by my cofounders. This decision was less an endorsement of my skills, and more a decision of necessity; our engineers’ time was desperately needed to keep the platform moving forward, rather than being caught up in hiring, performance reviews, and team design. Everyone’s initial assumption about this arrangement — myself included — was that I would step in to keep the team “duct-taped” together long enough to find a suitable replacement.
But in reality, I ended up acting as our interim CTO for 2 years from 2016 to 2018, during which time:
- We doubled our engineering team, and many of our team members on the team today have been with the company for 4+ years.
- We grew annual revenue from our product grew from approximately less than $100K in 2016 to over $2.2 Million in 2018.
- We grew from being a platform supporting a few thousand students a semester to one supporting about 100,000 students per year, requiring our platform to become significantly more scalable.
- Our team put in put in place many of the components of what still define our engineering culture today, like transparent salary bands, transparent leveling criteria, blameless post-mortems, and long-term roadmaps to help protect engineer time and reduce churn.
As the reality set in that I was really going to have to figure out how to run an engineering team as a non-engineer, I realized it would ultimately be on me if our platform had an outage, or if we made the wrong call with hiring, or if we made wrong architectural decisions.
As terrified as I was, I also felt…oddly liberated.
As a young founder, there was always a part of me that felt like I needed to “know all the answers” about my role and about the company. I look back on those early days now and realize that I thought that if I just appeared to have all the answers, I could “fool” everyone into believing that I belonged at the table.
But as I stepped into the role as the interim head of engineering, there was no “fooling anyone”. My team knew I was not an engineer. Pretending that I had all the answers — especially to technical problems — would be the one sure-fire way to lose the respect and trust of my team.
Realizing that no one expected me to have all the answers in this role freed me to feel like I could openly ask questions and make mistakes. And an even bigger realization followed; this had always been true.
That shift in mindset from, “I need to have all the answers”, to “I need to ask the right questions” changed everything.
Since I was the “non-engineer” in the room in our engineering meetings, I was able to voice all the “silly” questions. I realized quickly that many other people in the room often had the same questions, and me putting a voice to the unstated questions allowed discussion to flow easier.
I began to see that I could use these open-ended questions as a manager to spark discussions, challenge our assumptions, open up possibilities, surface risks, and make sure I really understood the limitations and capabilities of our system.
Questions became my go-to management tool as an interim non-technical engineering manager, and still are today in my current role as our CPO.
1. Ask questions to be a better manager, rather than giving solutions
I would guide our team through questions, like:
- “What would happen if our traffic doubled overnight? What part of our site might be the first piece to break down?” If we couldn’t answer that, then we’d explore how to answer that question.
- “What do you see as the top risks of this approach?”, when an engineer brought a proposed architecture for a solution to the team.
- “If you had to design an alternative model, what are other ways we could solve this problem?”
- “What do you see as the number one problem in our platform right now?”
- “If you were to leave Packback, what do you think would be the reason?”, a seemingly scary question that allowed me to understand how to make Packback the best place to work and retain our exceptional team.
These are examples of real questions that I recall asking at different key points in our scaling journey, and that helped our team work through questions around our infrastructure and features together. These kinds of questions guided our brilliant team, giving jumping off points rather than prescriptions.
It was easy to restrain myself from giving prescriptions in a role where I knew that I didn’t know what the right “prescription” would be. But it is even more important to remember lead through questions when you’re managing a team where you do have experience and it might be tempting to prescribe solutions.
A line that has always stuck out to me from the article, Good Product Manager, Bad Product Manager, is:
“Good product managers crisply define the target, the ‘what’ (as opposed to the how) and manage the delivery of the ‘what.’ Bad product managers feel best about themselves when they figure out ‘how’.”
After the last 10 years of building a business, I’d suggest that this sentiment be amended to apply to every manager. Managers focusing on posing the right questions to their team creates a team of owners.
2. Ask questions to become a better designer, rather than “staying in your lane”
As designers, I think we sometimes feel like we can’t or shouldn’t question the technical side of our organization if we are not an engineer ourselves. That’s simply not true, and it is harmful to both the designer and the engineering team.
If you’re a designer and you encounter an engineering concept that you’re not familiar with — or you get told that building a particular feature or UX solution will be technically hard or impossible — I would encourage you to not just accept the answer at face value. Instead, ask questions until you really understand why that is the case. If you don’t understand something technical, keep asking questions until you do.
By knowing the underlying architecture, capabilities, and limitations of the technical system for which you are designing a user experience, you will be able to design more innovative solutions that can take into account the constraints of the system (and know when it is worth it to push to change the system’s constraints).
During my time acting as the interim head of engineering, I came to realize that if you have the right people in the right roles and design the right environment, most management “challenges” simply disappear. I focused on trying to build the environment that supports and attracts creative, passionate, curious engineers. That system focused on a foundation of trust, a bias towards transparency, a focus on clarity, and the ability to question any decision.
A few things that we tried that worked well for us were:
- A public, clear 1+ year roadmap, which acts as a contract between all teams in the organization and against which any new requests are prioritized. This helps to reduce “churn” and switching of directions, and protects the engineering team by viewing their time as “fixed”.
- Blameless post-mortems, through which we discussed issues like outages when they occurred. By focusing on what we can learn from the situation and assuming that any error is due to a system failure and not someone’s “fault”.
- Transparent project management using a tool like Jira and an agile structure, so everyone on the team can see what their teammates are working on, ask questions, commit to planned work, estimate work task size, and track our velocity to make judgements of how to better break down product tickets.
- Transparent leveling criteria and HR practices that promote equality and transparency — We employed transparent salary bands and leveling criteria for roles in our engineering team to ensure that all team members in the same role are compensated and promoted fairly.
While I could not offer our engineering team coding skills, what I could offer was a clear roadmap, clear communication about the “why” behind each project and how it would impact our users, and the ability to be flexible and responsive in my designs/requirements based on feedback from our engineers. This has led to a close and collaborative “single team” culture between our product managers and our engineers at Packback.
Designers have a great deal to offer to support engineering teams, from the ability to clearly present information and vision, mock up prototypes quickly to aid collaboration, insights gathered from user interviews, and knowledge of user experience to help build better internal systems.
When you find yourself “in over your head”…start asking questions. You will be amazed by what you are capable of when you realize you don’t need to have all the answers.