This content originally appeared on DEV Community and was authored by Young Soo Hwang
In the last 7 years, we’ve seen numerous failed tech releases - the time when Google released Allo or when Netflix updated its rating system making it more complicated and confusing than ever. Although backed by big names, they miss the mark and fail to drive revenue or operational changes.
For the most part, this happens because tech objectives and business goals are not aligned, there’s no bigger picture to show how specific innovations contribute to growth and development.
When I moved from an engineering to a management position at oVice, I had to flip the switch from focusing on the “how” to fully immersing myself in the “why” of product development. On that ongoing journey, I’ve learned several valuable lessons I’d like to share with team leaders and engineers.
Lesson #1. Start with the “why”
We’ve known it for decades - technology does wonders when it helps solve tangible problems - think Facebook (connecting with people you are no longer personally in touch with), Airbnb (sharing quick and affordable accommodation solutions in a crazy real estate market), or Uber (capitalizing on the sharing economy to improve mobility).
Yet, more often than not, you see managers requesting tech innovations because they are trendy or because competitors are massively adopting them. As the result, leaders request months of engineers’ productive time and a lot of resources only to create something they have no application or long-term vision for.
I developed several ways to fight the digital FOMO on my team and make sure I adopt technology when I need it, not when it is hot on the market:
- Regularly reviewing client feedback and pinpointing ongoing problems. For example, a lot of our clients request new integrations for oVice. That’s why I can be confident that putting the time into building this feature is a worthwhile and intelligent way to use engineering resources. This reasoning equally applies to internal technology and tools. I regularly collect feedback from my team, discover loopholes in processes, write them down, and start looking for point-based solutions. When I approve the budget for innovation, I come back to the list of issues I identified and put more effort into solving those.
- Setting expectations. It’s hard to determine whether a release succeeded or failed when you don’t know what “success” or “failure” mean to your team. That’s why I set benchmarks for every tech goal I have in mind - what feedback I want to get from the end-user, what internal change I expect, how much time I want the update to save, and so on. I recommend making these estimates as quantitative as possible.
- Not making rash decisions. As I look around the market, now and then, a competitor with an intimidating and exciting feature appears, and I feel a sense of urgency, a need to catch up. Over time, I’ve learned to not trust this impulse and keep ideas on the backburner before putting them into development. Once the wave of excitement is off, I can calmly weigh all factors and make a rational, cold-headed decision - be it developing a new feature, changing the interface of the platform, or introducing a new internal tool to improve the efficiency of the team.
Lesson #2. Take the time to understand the basics of technology
As a tech-first manager, I had no issues with understanding the workings of product infrastructure when I became a manager. While I don’t think that having a degree and firsthand experience in product development is a must-have, I believe that understanding the building blocks of your project is essential for its success.
In my experience, exposure is one of the most powerful and organic ways to understand the basics of product development. I usually recommend the following types of resources:
- Tech blogs and newsletters. These are great because, unlike books or papers, they are written in a layman’s language, constantly updated, and give you digestible nuggets of knowledge. My favorites are HackerNoon, Programming Digest (weekly newsletter), and this community on Dev.to.
- Podcasts and Youtube channels. I love podcasts because they are seamless and easy to catch up on as you go about your day. As for YouTube channels, the visual component helps break concepts down, and reading the comments down the video helps you be part of the conversation and address your concerns.
- Reddit threads. In my experience, understanding development goes hand in hand with understanding developers. Reddit threads give an unbiased view of how programmers reason, what they prioritize, the blockers they face, and the worries they share. Being on the same emotional wavelength with your tech team will make conversations more fluid and fruitful. I regularly check out r/programming, r/softwaredevelopment, r/dailyprogrammer, and other communities.
Lesson #3. Balance your trade-offs
Finding the balance between delivering an update on time and within a designated budget on the one hand and positive market reception on the other is challenging. In my case, I work for a startup - we are always in the race against time. If we take too much time to ship an update, someone else will do it and snatch the first-mover advantage.
On the other hand, “quick and dirty” releases are temporary and will have to be rebuilt, leading to redundant work at least and reputational damage at most.
Development costs come into play as well - in a startup, there are a lot of ways to allocate budgets, so you want to make sure you are not overspending or underfunding your release.
Balancing the three variables out is tricky but necessary - here’s how I go about it.
- Capturing market signals. While I am against mindlessly hopping on the tech bandwagon, falling out of touch with the market and tuning out external risks and opportunities is equally damaging. For example, as I monitor supply and demand, I see that a lot of companies (including big names) are tapping into the niche of our project (collaboration for remote and hybrid work). I also see that there’s a surge of demand for hybrid work platforms - that means the engineering team has to, above all, be fast. From the tech perspective, I observe what features are vital to users - easy-to-use interface, stable connectivity, basic integrations - so I prioritize those.
- Continuous delivery and testing. External market data is valuable but internal insight is priceless. To make sure I have a data backbone for making tech decisions, I am a huge proponent of continuous delivery. It allows the team to replace guesswork with data-driven analysis and know how the market reacts to our vision and ideas.
- Thorough reporting. Taking the time to analyze past releases and see how much traction (be it awareness, revenue, or investor interest) our releases generate helps us understand how to allocate budget and time. Analyzing the roadmap immediately after and in the long run shows which decisions were the most impactful and how my team can reproduce them in the future.
Lesson #4. Understand the structure and responsibilities of tech team members
As a non-tech manager, I no longer contribute to building new features hands-on: instead, I have to delegate tasks and make decisions with the product team. The decision-makers must be involved every step of the way: missing out on the feedback of an important team member will lead to misalignment and miscommunication.
At the same time, I wouldn’t recommend burdening people with participating in discussions outside of their scope - there are better ways to allocate their time. That’s why understanding who is involved in making specific tech decisions and knowing who you should contact is crucial.
Here’s how I keep tabs on the organizational structure of the engineering team:
- Use our organizational chart on Miro to stay up-to-date on people’s positions.
- Have introductory calls with new team members to know what their role entails.
- Share the upcoming call schedule and let people sign up to contribute - this way, teammates can decide whether they want to be included in the discussion.
Understanding the distribution of responsibilities within the engineering team will bring transparency and structure to identifying bottlenecks, getting status updates, and aligning operations.
Lesson #5. Leverage what you have before you create a new solution
Finally, as technology expands its reach and becomes ubiquitous, team leaders start seeing building new features, introducing innovation, or ramping up their internal toolset as the only possible answer.
Today’s startup community is largely technology-driven: buzzwords like AI, blockchain, and big data dominate. However, these are emerging fields with expensive talent so there’s no need to introduce innovation purely for the sake of generating awareness and growing buzz around the product.
To summarize:
- Technology is not the only answer for** attracting investors**: business model and fitting the needs of the market are.
- Technology is not the way to get press attention and generate awareness: building up a media presence, investing in search engine optimization, and creating unique customer experiences are.
- Technology is not the only way to stand out among competitors: customer support, reasonable pricing, and the ability to address the pain points of the prospect are other alternatives leaders should consider. The feedback we get from oVice clients mentions stable infrastructure, security, and innovative tech as selection criteria but people are equally excited about an easy-to-understand billing mechanism and the ability to get step-by-step support from our team. Without the business model and the human component, tech alone could be not enough to tip the scales in our favor.
At its core, technology is a means, not the end itself. So, before they start looking for expensive talent and introducing groundbreaking features just for the sake of it, I’d like to ask managers: “Are you sure there aren’t other ways to reach the same objective?”.
At the same time, rather than building features or internal tools from scratch, you can find answers to tech problems by fine-tuning existing features or exploring open-access resources: plug-ins, libraries, and extensions.
Final words
As I worked both as an engineer and an operations manager on the business side of product development, I realized that business and technology cannot exist as separate entities. Innovation has to stem from clear business goals and see the end-user, not transitory metrics, as its key objective.
Another thing I’d like to mention is that checking in with the engineering team frequently and addressing concerns will help bridge the gap between tech workflows and business objectives. In my team, I do it in oVice - a virtual office space that connects hybrid and remote teams. Here, I can easily connect with the Global, Japanese, or Korean engineers and check that our goals are aligned.
If you are interested in the concept of a virtual office, read more about it here. If you want to talk to me or see the product in action, drop by my virtual office.
This content originally appeared on DEV Community and was authored by Young Soo Hwang
Young Soo Hwang | Sciencx (2022-07-11T04:08:23+00:00) Aligning technology and business goals: 5 lessons I learned after being on both sides. Retrieved from https://www.scien.cx/2022/07/11/aligning-technology-and-business-goals-5-lessons-i-learned-after-being-on-both-sides/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.