Leadership advice · Stakeholders, scope and alignment
How engineering leaders work with stakeholders
Aligning engineering with product and the business, explaining technical work to non-technical people, and protecting scope.
Interviews
Questions we asked
Asked on camera at our meetups. Where more than one leader answered, the answers are side by side. Transcripts are lightly edited for reading.
Can you describe a situation where you had to communicate a complex technical concept to a non-technical stakeholder?
2 leaders answered this one.
“As long as the proposition is clear, including the vision, our strategy, the things that we do, I think that creates great alignment across teams.”
Read the full answer
In a previous technical leadership role, I was in an industry that is not necessarily tech-enabled. The biggest thing about leading the technical team of that company was communicating the culture around technology and the culture of innovation that we wanted to cultivate. For us, that meant structures like remote work, a culture of trust, the idea of failing fast, and an experimental culture, in a company that was more used to a traditional setup.
The challenge was that we had to continually deliver our work and present the value of the technology and the platform we were building, despite these seeming luxuries or innovative ways of running a team. And I believe we managed to do that.
First, we documented everything. We built the technology team to be remote, so everything is documented in Notion, with very clear expectations, not only within our team but across teams, that anybody can read: how we work, how other teams can interact with our team and vice versa. Those documents are also communicated in synchronous meetings sometimes, and we treat them as living documents that may change at any time. As long as the proposition is clear, including the vision, our strategy, the things that we do, I think that creates great alignment across teams, even if the culture we're trying to build is different from what people are used to.
“You have to really be patient enough to explain something to them that [doesn't make] them alienated to the concept of AI.”
Read the full answer
This is happening especially now with AI. A lot of people are getting hyped with the idea that they want to develop AI products. But to actually say that what you're building is really AI, you have to really explain it to your stakeholders. Sometimes they just imagine it as something very cool that would increase their profit, and so on.
Right now we are using AI for product-switching scams: you order a product, and you receive a different one. You have to really explain the back side of it to them. So I had to give examples where they could really see it: okay, this is a product-switching scam. Then how do you apply AI? I put the concept of AI on top of that example.
With non-technical stakeholders, you have to really be patient enough to explain something to them that doesn't make them alienated to the concept of AI. Because it's a hype culture right now. So that's one situation where I had to go deeper with them.
How do you handle scope creep and changes in project requirements while maintaining the project timeline and quality standards?
“One of the main issues of scope creep is if you're not guided by what you're trying to hit, a metric, a goal.”
Read the full answer
Number one, we need to first identify the goals of whatever feature or deliverable we're doing. Once that's identified and all the stakeholders are clear about the goals, that's when we go into the details of what exactly we're going to build, so that everyone understands where everything emanates from. One of the main issues of scope creep is if you're not guided by what you're trying to hit, a metric, a goal. That's when scope creep enters, because it doesn't take much to include this, or it doesn't take much to add this. But you lose focus on what exactly you were trying to hit in the first place.
The second thing that we also do is we try to make stakeholders understand, especially the ones who aren't part of the working team, that everything has a cost to it. Every part of the feature that they want to add or remove, there's always a cost to it. And so, something has to give. It's not a hard no for every change request. It's just that we need to adjust something from the current deliverables to accommodate something else.
Can you describe your approach to aligning your engineering team with product management and other cross-functional teams?
“The more you get people involved with the actual problem, with the actual users, the better it is for them to understand and to also create a better solution.”
Read the full answer
That's a very good question, because a lot of organizations, I think, struggle with that. What is important, I think, is that the engineering team, on a high level, understands the business needs or the key features of the product, if you're building a product. Whom are they building it for? What problem does it solve? And how do we measure success? On a very high level, not all the deep metrics and KPIs. But that is, I think, crucial to understand, so that they can have a mindset of understanding the daily user.
Mostly, engineering teams don't build for themselves, they build for someone, and there's a lot of disconnect, because oftentimes engineering is treated as the last thing in the chain, if you go for a classic waterfall approach. People just give you a spec sheet. So the more you get people involved with the actual problem, with the actual users, the better it is for them to understand and to also create a better solution.
How do you handle competing priorities and urgent requests from stakeholders while maintaining focus on your team's goals?
“I don't think as a dev, you have to think of the non-technical stakeholders as the enemy.”
Read the full answer
Thinking Machines is a consultancy, so the stakeholders are changing all the time. It's something I have to deal with a lot. I think it's easy, when you're a dev and the stakeholders are non-technical people, to feel like the stakeholders are the enemy, like you're in completely different areas with completely different interests. But I find that most people, even the ones who are non-technical and come from a different background, are reasonable. Usually people just have different contexts or understandings of the situation.
So when you're able to figure out where that difference or gap in understanding is, what they know that you don't or what you know that they don't, you're typically able to come to at least a compromise or an understanding. It's about figuring out how your contexts differ and where there might be overlap. Because, again, most people I find are reasonable. I don't think as a dev, you have to think of the non-technical stakeholders as the enemy.
Can you provide an example of a time when you had to advocate for your team's needs or ideas to senior management?
“I look for talent where it's not just skills, but also people.”
Read the full answer
Most of the time, I work with engineers, so I look for talent where it's not just skills, but also people. You need someone with people skills who, at the same time, can explain technical jargon to non-tech people. That's what I look for, and that's what I advocate for with management.
Takes
Short takes
Clips edited down to the answer, labelled with what they're about.
Take · On shifting priorities in a startup
In a fast-paced environment like a startup, we should be adaptable to changes.
Read the full transcript
Scope creep is very common in the startup space, and priorities shift, because in a fast-paced environment like a startup, we should be adaptable to changes. For managing a team, initially we need to really set expectations first. Eventually it becomes a culture for the whole team to adjust and adapt to different priorities and changes as the business improves. At the end of the day, we need to produce a sellable product.
Take · On choosing a vendor
Before you even think about the vendor, what would be the demands that you would require?
Read the full transcript
I believe what's important first is to collate what the needs of your team are. Before you even think about the vendor, what would be the demands that you would require? Make a list to make sure everything is neat and organized. Next, you should make a methodology. Before picking a vendor, how are you going to assess them? Is it fair? Is it bound by quantitative measures? Are there qualitative aspects? Those are things you have to determine first. Only then should you begin testing or assessing any vendor. If you follow those principles, I believe you will make the right pick eventually.
Take · On choosing technical solutions
We as architects could be building anything, but if the solution doesn't really deliver them value at the end of the day, then it's not worth doing in the first place.
Read the full transcript
When considering technical solutions, I always make sure that the way I build a solution never drifts from what the clients really want to do. At the end of the day, the clients are the ones using your tools, so it's really important to solve their problems specifically. We as architects could be building anything, but if the solution doesn't really deliver them value at the end of the day, then it's not worth doing in the first place. If you're not able to evaluate that, the project will just fall short of their expectations.
Keep reading
More leadership topics
Your turn
Come to the next eHeads.
Open to every technology leader, especially new ones. It's free.