How business decisions in the blockchain ecosystem can’t be driven by soft skills alone
Despite my technical ability, I would not consider myself ‘just an engineer.’ In my short, but eventful career, I have been an avid activist, raised venture capital, performed in pitch competitions, co-founded startups and corporate practices, and full-filled the roles of ‘business analyst,’ ‘architect,’ and, most recently, ‘product manager.’ Through these adventures, I have determined a personal mantra of experience:
Hard-skilled positions require singular focus to master. Soft-skilled positions require confidence to master.
Hard-skills like software engineering, product design, empirical research, technical project management, and marketing require years of practice and failure over dozens of projects to master. As someone who did not start out technical, I can assure you that I have learned project management, pitching, and deck creation skills in a much shorter timespan than learning how to code, develop wireframes, or even juggle a soccer ball half-decently.
Soft skilled positions are more nuanced. They require communication skills across text and in-person mediums, confidence, and, political strategy. The difficulty of mastering each of the latter attributes varies more with an individual’s personality and emotional intelligence than it does with a theoretical learning curve. Typically, the higher you progress through an organization, hard skill knowledge decreases and soft skill knowledge increases. In some organizations, I’d dare say that executives don’t even know how their company’s technology functions.
Of course, there exists an innate bias in my analysis of what ‘hard skilled’ and ‘soft skilled’ means. Though I think many of us can agree that, traditionally, there has always existed a cultural power gap between technical and non-technical roles, which could be aptly described as ‘developers/designers and everyone else.’
In this brief, I foolishly attempt to tackle
- The reality of the power-gap between technical and non-technical roles
- The transition in roles and responsibilities that needs to occur in organizational leadership structures (Web 2.0 →Web 3.0)
- How business success will be driven by hybrid-skilled leaders
A Culture of Power Between Roles
In the late 1990s, if you could code, you were considered a genius. Now automated by sites like Wix and WordPress, tasks like developing a landing page for a website carried a high premium at the dawn of the Internet, and icons like Steve Jobs and Bill Gates almost carried an innate sexiness in their ability to commercialize portable hardware and software.
As time continued, the roles of software engineers and designers took a back seat to ‘vice presidents’ and ‘directors’ — people who could effectively operate in a venture capital driven technology industry and sell the vision of a product on a quarterly basis. The hype cycle of the dot com era repeated with mobile phones and mobile apps, and is now in full motion with AI, machine learning, and blockchain technology. Each hype cycle iteration brings forth more technical co-founders that have a strong grasp of both persuasive storytelling and technical know-how.
Market Signals Create a Hunger Games for Developers
Despite the trend toward business leaders with hybrid knowledge (hard and soft skilled), the next blue collar profession seems to be coding, as the starting salary for software engineers corrects itself in tangent to its complimentary roles. The software engineering field is set to expand by 12 percent from 2014 to 2024, and an increasing number of people are transitioning from service industries or dwindling markets to re-imagine themselves as developers and designers. As more engineers enter the market to fill the vast amount of corporate vacancies in Silicon Valley and abroad, a culture of ‘developers as a resource’ has infected startups and multinational companies alike.
Companies waiting to fill engineering vacancies are also looking to minimize engineering employment costs. A massive trend of outsourcing engineering responsibilities continues to steepen. 37% of the companies that already outsource application development plan to increase the amount of work they outsource next year.
Software Engineering roles have been culturally commoditized due to the conflicting nature of the market. On the one hand, the market is signaling for domestic demand for these roles to be filled. On the other hand, the market is looking to outsource technical roles to minimize costs.
Of course, the application development market understands that by outsourcing application development, development quality will most likely decrease, and customer success costs associated with maintaining the product after its been delivered will increase (due to a lack of documentation and staff members to maintain what was developed). All of these considerations lead to the following business thought pattern (a loop):
“We need to hire developers.”
“Domestic developers are expensive, so let’s outsource development.”
“Outsourced development comes with lower quality and higher maintenance costs. Outsourcing development isn’t a sustainable business practice if we hope to maintain brand integrity.”
“We still need to hire developers.”
Maximized Pipelines Leave No Room for Career Development
With not enough developers to deliver, and client pipelines filling to the brim, business stakeholders begin to think of software engineers as ‘coveted resources,’ rather than individuals that have career aspirations and dynamic skillsets that can be used to support the business development process. Maximized pipelines then put an amazing amount of pressure on developers and designers to deliver within expedited project timelines with little break in between projects. Ever heard of the phrase, “All work and no play makes Sarah a dull employee?” Well, if you haven’t you’ll certainly realize what it means when your company’s developer attrition rates increase after the first fiscal year.
For those developers that do remain, it is unlikely they’ll have much time to participate in business decisions that (1) directly affect their workloads, (2) determine how the business moves forward, and (3) highlight project managers or middle management for delivery success. Employees that don’t participate in these discussions will always be considered lower-level, and since there’s always a demand for ‘technical resources,’ it is unlikely that you’ll see technically capable leaders within corporate governance structures. Without such representatives, businesses will not be able to effectively manage client expectations, forecast product development/service opportunities, and create a culture in which technical talent prefers to grow within, rather than escape from.
A Culture of Typecasting Ability Based on Title
Lastly, and I’m not sure if this pattern has evolved from assumptions or lived experiences, but there exists an unsubstantiated culture of typecasting an individual’s professional ability based on their title. Titles are a fickle symptom of hierarchical organizations. They can denote an individual’s level of power with precision, and thus, evoke egos across a company’s employee community that, if left unchecked, can create a title war within middle management. Titles also denote accountability structures. If you’re a ‘software engineer,’ then you best be engineering some software at one point in time during your workday. I have personally changed my title at ConsenSys many times to avoid being typecast and ensure that my fellow team members don’t feel like I’m trying to impose myself over the needs of the team. Initially hired to lead Blockchain for Social Impact Coalition’s delivery team (BSIC is now a foundation, and since then we’ve co-founded ConsenSys Social Impact), I have used the following titles just in FY18:
- Technical Director — Coming from Cisco Systems, I thought this was a cool sounding title
- Social Impact Development Chef — Liked the ‘Chef’ thing that Joseph Lubin started using and thought it was more flat sounding. External partners had no clue what this was. Took note that flat sounding titles when co-leading a team can’t really be used when the partners/clients you interact with have hierarchal title expectations.
- Global Product Development Lead — Instead of using ‘Director’ or ‘Chef,’ I thought I found an in-between title that was straight to the point of what I primarily did (with exception to business strategy and partnership development that takes around 50% of my time)
- Co-creator or Co-founder, ConsenSys Social Impact — Tired of bending to every stakeholders will, I have chosen this title to reflect broader responsibilities and the nature of my work. It reflects what I’ve done at ConsenSys and doesn’t tie me to ‘he’s just a developer, or architect, or business lead, or etc.’
When I was a ‘Technical Director,’ colleagues would act is if I needed to attend a remedial class on business development before engaging with me.
When I was “Social Impact Development Chef”, partners first impression was that I was ‘the fun wacky guy’ on the team.
When I was “Global Product Development Lead”, colleagues, once again, acted as if I needed to watch a documentary on what business was.
As, Co-founder of ConsenSys Social Impact, colleagues, partners, and clients understand that I consistently and effectively operate across business development, architecture development, lower-level software engineering, and partnership development practices.
All of this to say, that technical sounding roles will evoke incorrect assumptions for business stakeholders and vice versa. A culture of assumptions will lead towards stakeholders validating their own, unilateral decisions — and unilateral decisions never bode well for team consensus. A good mantra to use to combat such misunderstandings is the following:
“Assumptions make an ass of us all.” — Unknown
A Transition in Roles & Responsibilities for Web 3.0
An interesting organizational pattern that I’ve seen evolving across Web 3.0 startups is that (1) many companies are opting out of (completely) hierarchical structures, and (2) middle and upper management roles now require an understanding of the technology to be effectively performed. Note, that an ‘understanding of the technology,’ does not simply mean that an individual knows that ‘a blockchain is a ledger.’ It means that they understand the current state of the technology as it relates to scalability, ecosystem maturity, and future ecosystem needs. If you are not at least a theoretical practitioner and self-autodidact in the blockchain ecosystem that constantly learns from others in the space, you will not fit this baseline requirement for understanding the technology, and thus, will not be able to effectively guide business strategy, product development, or research initiatives.
The trend is similar for other, emerging technologies. Business value and technical understanding are being interwoven more closely than ever before. For those practicing in the blockchain ecosystem, you already know that the very nature of smart contracts is encoding business decisions on-chain — quite literally moving money in an instant. If decision makers aren’t hybrid skilled, they cannot effectively guide strategy regarding the technology or any product built atop of it. For blockchain developers, this presents a rare opportunity to provide value beyond software engineering. Now, you are better suited, because of your technical knowledge, to participate in business development, research, and product management. I can personally attest that being a student of the technology has empowered me to work on many different sides of the business.
The End of an Era of Non-Technical Leadership
As organizations become more flat, and technical knowledge becomes more critical to strategic business decisions, the place for blank conjecturing minimizes. Leaders with hybrid skills will, eventually, represent the majority of stakeholders in organizational governance structures, and company culture, hopefully, will benefit from such representation.
Recent Comments