Where to Start

Following on from Thriving on the Technical Leadership Path, this post suggests some things I have learned and want to share with others interested in supporting or cultivating a long-term career as an engineer, specifically those working on strategy and technical leadership.

One of my main motivations at work is that I really like to get things shipped.

I do love to ship 😍 💪🏻 🚀 pic.twitter.com/1mBpOktQus

— keavy (@keavy) May 18, 2017

I have learned that I have more ‘luck’ with shipping if my preparation is as solid as humanly possible.

Knowing where to even start with a big engineering problem can itself be a daunting challenge, especially when there’s a vast unknown, a wide array of possibilities, or perceived or real pressure to deliver something. The best place to start is finding out what the problem is. This sounds obvious, but it often isn’t. Gaining a deep understanding of the problem(s) is a step many folks skimp on or skip - maybe because someone important has already stated what the problem is, or there’s excitement about a proposed solution, or you think you know already.

When I think of software projects I’ve known that have failed to launch, or worse been unshipped, it was never because the engineers weren’t smart enough or didn’t try their best to deliver a great solution. It was typically because it wasn’t addressing the right problem for the context: from not really being in-line with the product direction of the company, to only addressing a portion of a bigger problem… and that not being enough.

A project has more chance of a successful outcome if it’s fixing the right problems for the context. So deeply understanding the problems, in your organizational and user context, is a great place to start.

To gain that deeper understanding, I like to start my research by talking to people. Depending on the nature of the project that might be customers, fellow employees, or industry peers. Here are some examples, from my experiences:

Customers

While working on the API and its ecosystem at GitHub, my teammates and I spoke to integrators frequently. In the research phase of a big project, I interviewed representatives from different product or service types to get a deeper understanding of their needs and validate our assumptions. We would ask questions about how they used particular features, what they didn’t use, what their workflows were like. We’d dig into where they got stuck, what frustrated them, and what they wished they could do.

A great question I learnt more recently, while sitting in on a colleague interviewing a customer, was “What question do you wish I’d asked you?”. (Thanks Belinda!)

The challenging and fun part of the job is then to try to identify underlying shared problems, and match the needs you’ve heard to possible solutions. Of course, what people say they want might not match the best overall solution. While researching how to make integrations better on the platform we heard many customer requests for more OAuth scopes. But we knew the problems around OAuth Applications were more complex, so providing just more scopes would be a bandaid, at best. Through deep research and product thinking, my team conceived of a fresh approach that met the need of more granular permissions, while also effectively resolving other underlying problems around access and third-party services¹.

Fellow employees

In my current job at Fastly, I was hired to lead the strategy for the company’s public API. As a brand new employee, I didn’t have any knowledge or social capital at the company; everything was new and unknown. So, I started by talking to a range of employees: engineers, managers, product managers, support, docs, sales and security team members. I wrote a set of questions, which I asked each person. A few differed depending on the department, for example Product or Sales people might have different exposure to customers than those in Engineering, but generally I tried to ask the same questions of everyone. Broadly I asked everyone what was working well, or not so well, in terms of people, teams, culture, processes, and technology.

I had an initial brief about the end goals, but have been given a generous amount of scope and autonomy to direct the project. So to help fine-tune the goals, and increase the chances of success, I asked everyone what a successful outcome for them would look like. I also asked what they thought would be the threats and obstacles to my project’s success, and what they would focus on, if they were doing my job.

The responses were fascinating. People generally love to talk about their problems so I gathered a wealth of insights into things like why things were the way they were now, what caused friction, what had been tried before, why that hadn’t worked, what could hinder growth, who could help. In asking questions and listening to people’s experiences, I never judged their responses. This didn’t take much effort - I want to gain some understanding of the choices that were made before I was employed at the company, but not to make any judgements about those choices. However, it seemed helpful to sometimes say this out loud and I was grateful for people’s trust in me to share their experiences, frustrations and hopes.

The insights from people provided a rich and nuanced understanding of the problems. My reams of notes would later inform my strategy, proposing solutions tailored specifically for this organizational context.

Industry peers

One thing I enjoy a lot about working in tech is the relationships I’ve built up with my peers. The generosity of information is something that drew me into this field, and it’s something I continue to feel grateful for. I might not necessarily be the smartest engineer in the room, and that’s OK. Firstly because “always be the worst musician in the band”, plus I know it takes a mixture of skill sets to build a great product. So in my research I always try to talk to and learn from people who have different skill sets, knowledge or experience to me.

In my current job, leading the strategy for APIs, although it’s a field I’ve worked in for several years, I reached out to industry peers from several different companies in the developer tools space. I asked them how they did certain things, if they would recommend that way, what would they do differently if they could do it over. I’ve found great support and camaraderie between professionals like me, tackling similar problems in different places. I would highly recommend more of these conversations.

What do you do with this information?

I like to turn my raw notes into coherent summaries of the points raised, and write up my analysis of the research. I’ll typically talk through the findings with the stakeholders and immediate team interested in the particular project. Also, I believe it’s important to make this research available and discoverable to anyone and everyone in the company. The written internal documentation from this process provides a useful resource not just during the research and discovery phase of a project, but something I or my teammates will refer back to throughout the lifecycle of a project. After sharing this type of research recently, one product manager told me that while he was mostly aware of individual points, that to see the holistic picture written down was invaluable.

---

Part of our job, as strategic technical leaders, is to identify the problems, then translate our understanding into both technical solutions and marketable projects within our own company (which I might write more about in a future post). In order to do that successfully, we need a deep understanding and nuanced knowledge of the problem space: what problems we’re tackling, how our organizational or user context will affect things, what the challenges will be, and how we might get support to see it through. That knowledge is a source of power that I’ve personally found gives me the confidence to be accountable for the direction I set. It also helps broaden our ambition, away from a natural tendency to focus on solutions that feel more comfortable within our existing knowledge and skill sets.

One of the challenges with this people based research is that it takes time and patience. There may be internal pressure to start producing something, which I’ve certainly felt at times, especially as a new employee where no-one has seen me deliver before. There might be external pressure, especially if some in your company view this work as slow or don’t see the value. I’ve been fortunate the last few years to have worked at companies that have seen the value, or at least allowed me enough time to prove it to them. One manager admitted to me she was itching to see results, but admired my ‘maturity’ to do thorough research first.

My experiences have taught me that if you want to produce the right thing, that has rich and lasting impact, this starting point of finding people, talking to and learning from them is fundamental. For me it’s the precursor before the technical research and experiments can truly begin.

To do this work sustainably, senior engineering leadership needs to value and support it. The organizations that get this set themselves up to not just meet their users’ needs, but excite and empower them, enabling those users to grow and be successful.

Not every senior engineer wants or needs to do this type of research (very senior engineers come in several types, but that’s a whole other story), but somebody should be doing it. While there might be some overlap with Product people, my experience has taught me that it’s invaluable for engineers to be engaged in these conversations. If you want to grow as a senior engineer into doing more strategic work, I recommend spending extra time and effort in identifying the problems, questioning, listening, being curious; the solutions will come and they’ll be all the better for it.

Thanks to Andy, Joanna, Michael and Sara for reading a draft of this.

1. The new GitHub Apps addressed complex issues around user access (in a system where a user has one account, for both personal and work access), enabling applications to be first-class actors in the system (rather than have a bot impersonating a user), and making it easier to configure third-party services. See my talk from GitHub Universe 2016 when we launched this for more on the introduction of this new type of application. ↩