As
a designer starting out in the beginning of your career, you may not
know what to expect during your first job. You could be given lots of
work and because you are the new designer on team, you do things without
question. You might think you are expected to know everything because
nobody said you should seek out the things you need to help you.
Having
worked in the design industry almost every summer in college, I’ve
learned a thing or two about how a new designer, such as myself, can
navigate through challenges and learn in environments based on implied
messages of what we should or shouldn’t do. Knowing the basic tools and
techniques of good design is essential, but it’s the small details
surrounding how we work which can help us progress and open doors. Here
are a few tips that growing designers should take into consideration
during their first year on the job to accelerate career growth.
Asking for Help Doesn't Make You Stupid
It’s
okay to ask for help, but the issue that some designers may allude to
when they say asking for help is a big no-no is the phrasing. Instead of
directly asking for help, ask for feedback and advice.
If you need help with doing research, join a research session. If you
need help with moving forward in a project, ask designers to join you in
prioritizing ideas. This will provide you with direction. Instead of
receiving a hard-cut answer, you receive validation and perspective,
things that will help you develop your own point of view. Designers don’t receive answers, they problem solve to get there.
Saying “No” is better than saying “Yes” all the time*
Note
the asterisk. You are in control of what you want to do. You can decide
when you reply to that e-mail or if you want to go that meeting. We are
often given so many things to do that we can’t do all of them, yet we
think we have to. Many designers, especially in the beginning of their
career, do everything they are told to do, and this distracts them from
the work they need to do the most. Decide on what is most important to
help get your work done and prioritize.
Don’t say yes for the things that get in the way of producing quality work.
Delegating
tasks and prioritizing is hard, but if you can do that, you will get so
much done (and more). It’s okay to say no for valid reasons because it
tells people that you know what’s important.
Speak up
During
a critique, we are excepted to provide feedback for our peers, but not
everyone does it because they might be self concious of their thoughts,
or they don’t make the effort to help. Don’t be selfish with ideas.
Ideas are meant to be expressed and help our fellow designers design for
the people. Feedback is a gift. Feedback is what results in more iterations and better experiences.
Take Breaks
I
used to work hard constantly, whether it was at home, with friends and
family…You name it. But then I realized, without fault, I will be
working for the rest of my life and work isn’t ever really “done”. I was
taking the time to work on something fleeting, when I could have been
spending time with the people I loved and the things I loved to do
outside of work. Also, too much work can increase stress which can
increase burnout. It makes sense to do as much work as you can to get to
a certain job or rank, but that takes time. Just do what you can and
relax when you feel overworked or exausted. In the end, health is more important than work because without health, we can’t work.
Be Present
As
tempting as it is to work from home, especially for people who have the
privilege of doing so all the time, it is crucial to be present. Even
if the quality of work has not been affected, as designers,
collaboration is such an important aspect of the way we do things. Being
present in the office can make all the difference, especially when
working with the people on your team. It’s not a team if everyone isn’t present.
If you have any questions about design, message me on LinkedIn and I’ll write about it!
A
prankster who made repeated hoax distress calls to the US Coast Guard
over the course of 2014 probably thought they were untouchable. They
left no fingerprints or DNA evidence behind, and made sure their calls
were too brief to allow investigators to triangulate their location.
Unfortunately
for this hoaxer, however, voice analysis powered by AI is now so
advanced that it can reveal far more about you than a mere fingerprint.
By using powerful technology to analyse recorded speech, scientists
today can make confident predictions about everything from the speaker’s
physical characteristics — their height, weight, facial structure and
age, for example — to their socioeconomic background, level of income
and even the state of their physical and mental health.
One of the leading scientists in this field is Rita Singh of Carnegie Mellon University’s Language Technologies Institute.
When the US Coast Guard sent her recordings of the 2014 hoax calls,
Singh had already been working in voice recognition for 20 years. “They
said, ‘Tell us what you can’,” she told the Women in Tech Show podcast earlier this year. “That’s when I started looking beyond the signal. How much could I tell the Coast Guard about this person?”
Rita Singh is an expert in speech recognition
What your voice says about you
The
techniques developed by Singh and her colleagues at Carnegie Mellon
analyse and compare tiny differences, imperceptible to the human ear, in
how individuals articulate speech. They then break recorded speech down
into tiny snippets of audio, milliseconds in duration, and use AI
techniques to comb through these snippets looking for unique
identifiers.
Your
voice can give away plenty of environmental information, too. For
example, the technology can guess the size of the room in which someone
is speaking, whether it has windows and even what its walls are made of.
Even more impressively, perhaps, the AI can detect signatures left in
the recording by fluctuations in the local electrical grid, and can then
match these to specific databases to give a very good idea of the
caller’s physical location and the exact time of day they picked up the
phone.
This
all applies to a lot more than hoax calls, of course. Federal criminal
cases from harassment to child abuse have been helped by this relatively
recent technology. “Perpetrators in voice-based cases have been found,
have confessed, and their confessions have largely corroborated our
analyses,” says Singh.
Portraits in 3D
And
they’re just getting started: Singh and her fellow researchers are
developing new technologies that can provide the police with a 3D visual
portrait of a suspect, based only on a voice recording. “Audio can us
give a facial sketch of a speaker, as well as their height, weight,
race, age and level of intoxication,” she says.
But
there’s some way to go before voice-based profiling technology of this
kind becomes viable in a court. Singh explains: “In terms of
admissibility, there will be questions. We’re kind of where we were with
DNA in 1987, when the first DNA-based conviction took place in the
United States.”
This
has all proved to be bad news for the Coast Guard’s unsuspecting
hoaxer. Making prank calls to emergency services in the US is regarded
as a federal crime, punishable by hefty fines and several years of jail
time; and usually the calls themselves are the only evidence available.
Singh was able to produce a profile that helped the Coast Guard to
eliminate false leads and identify a suspect, who they hope to bring a
prosecution soon.
Given
the current exponential rate of technological advancement, it’s safe to
say this technology will become much more widely used by law
enforcement in the future. And for any potential hoax callers reading
this: it’s probably best to stick to the old cut-out newsprint and glue
method for now. Just don’t leave any fingerprints.
This
past summer I managed the largest acquisition campaign in my company’s
history. I work at HubSpot, a marketing software company that
popularized lead-gen campaigns and the whole idea of “inbound
marketing,” so this is no small feat (we’ve run massive campaigns over
the years).
The campaign, Four Days of Facebook, drove 10x the number of average leads of a typical acquisition campaign and 6x the lifetime value of projected customers.
But I didn’t do it alone. This campaign involved 11 teams and 33 people who directly contributed to the work.
Cross-functional
campaigns like this can be big, complicated, and challenging which is
why they so often take a boss or recognized leader to make them happen.
So I wanted to share my experience as a “non-boss.” I hope it encourages
other individual contributors out there to get their co-workers in
other departments excited about working on high-impact, cross-functional
projects.
Pre-planning: create alignment
You won’t have all the answers on day one, but make sure every conversation you’re having at this stage focuses on one thing: impact.
You’ll be asking a lot of people to work hard on something outside of
their normal day-to-day, make it clear that your asks will translate
into business results.
Meet with senior leaders of each team before you ask for their employees commitment on helping. Again, make it clear that you won’t be wasting anyone’s time, you’re out to generate big results.
Have a kickoff meeting with the team who will be responsible for delivering the work. At
a high-level, you want to let everyone know that you have senior
leadership buy-in and the project will be worth their time. On a more
tactical level, you’ll also want to get people up-to-speed on the tools
you’ll be using to manage the project.
Go the extra mile to develop a team culture for your team.
You know how developers name their projects crazy-sounding names? It’s
surprisingly effective! Give your temporary team a name that makes
people feel like they’re a part of something, set up an email alias, and
create a Slack channel. Get people excited!
Throughout
the pre-planning stage, keep your vision front and center. For Four
Days of Facebook we were partnering with Facebook, a fact I repeated
constantly.
If people are excited and engaged with your vision, they’ll put up with the inevitable bumps as you achieve lift-off.
During: maintain momentum
The Progress Principle
is the idea that humans love the satisfaction of wins, even if they’re
small. It’s your best friend as you seek to keep multiple teams and
dozens of people aligned and moving in the right direction–constantly
show (and celebrate) forward progress.
Display it:
I put together a registration goal waterfall chart that was updated
everyday to show progress. It’s motivating to close-in on and cross that
goal line.
Never shut up about it:
I linked to information about this campaign in my email signature,
Slack rooms, wherever I had the attention of my co-workers. And that
information was short, sweet, and up-to-date.
Be a good partner: You’re
not technically the manager of the people on a cross-functional team,
but you should implement some management best practices: give people
autonomy, figure out how they like to work and what kind of support they
need from you.
Ask for feedback:
I asked questions constantly– Is this system or process working for
you? Can I set up these reports in an easier way? At one point during
this campaign I asked the senior manager of a few folks working on the
project if she had thoughts on how I could run it better, she told me
she would love to see weekly updates sent to her and other senior
managers. I was avoiding this as I didn’t want to clutter inboxes, but
it ended up being one of my best tools for building internal momentum
around the campaign.
Don’t overlook the fundamentals of good project management. A framework like DARCI
makes roles & responsibilities super easy so you the project lead
can just say, “This meeting is for people who are Responsible and
Accountable only, we’ll be covering deadlines for next week”, or “This
meeting is for people that need to be Informed, it’ll be a milestone
check-in.”
Find a project management framework, and stick to it.
Wrapping up: close-the-loop
I
run 4–5 acquisition campaigns at HubSpot every quarter and running a
campaign of this size and impact was a complete rush and I can’t wait to
do it again. But before jumping into the next big project, it’s
important to do a clean wrap-up, I want people to be excited to work
with me and my team again in the future.
Say thank you:
Do it publicly via a company announcement or email, and privately. I
wrote handwritten notes to every person who contributed to this
campaign.
Share results soon:
Share the quantitative results, but don’t miss Twitter comments from
attendees, feedback from partners, or the accolades of your co-workers.
This is your chance to make it clear that you promised impact and
delivered it.
Look for improvement opportunities:
Because no matter how successful your campaign was, there are
opportunities to do better — Were any deadlines missed? Why? Did any
team members not work well together? Can this be addressed?
It’s
easy to get stuck in a rut of executing one marketing campaign after
the next, and it’s scary to think about leading a big cross-functional
project that could potentially fail publicly.
But
so often the answer to higher impact is better collaboration. Learning
how to lead across teams 10x’ed the impact I was having at my company, I
hope it does the same for you.
My colleagues and I wanted to create something that would make people go “wow” at our latest hackathon.
Because
imitation is the sincerest form of flattery and IoT is incredibly fun
to work with, we decided to create our own version of Amazon Go.
Before I explain what it took to make this, here’s the 3 minute demo of what we built!
There were four of us. Ruslan,
a great full-stack developer who had experience working with Python.
John, an amazing iOS developer. Soheil, another great full-stack
developer who had experience with Raspberry Pi. And finally, there was
me, on the tail end of an Android developer internship.
I
quickly realized that there were a lot of moving parts to this project.
Amazon Go works on the basis of real-time proximity sensors in
conjunction with a real-time database of customers and their carts.
We
also wanted to take things a step further and make the entry/exit
experience seamless. We wanted to let people enter and exit the store
without needing to tap their phones.
In
order to engage users as a consumer-facing product, our app would need a
well-crafted user interface, like the real Amazon Go.
On
the day before the hackathon, I put together a pseudo-design doc
outlining what we needed to do within the 36 hour deadline. I
incorporated the strengths of our team and the equipment at hand. The
full hastily assembled design doc can be seen below.
There were six main components to EZShop, our version of Amazon Go.
A quick diagram I whipped up visualizing the components of this project
The Kairos Facial Recognition API
The Kairos facial recognition API
was a fundamental component for us. It abstracted the ability to
identify and store unique faces. It had two APIs that we used: /enroll and /verify.
/enroll is described as:
Takes a photo, finds the faces within it, and stores the faces into a gallery you create.
We enrolled all new customers into a single “EZShop” gallery. A unique face_id attribute would be returned and stored with the customer’s registered name in our real-time database.
When we wanted to verify a potential customer’s image, we would POST it to the /verify endpoint. This would return the face_id with the highest probability of a match.
In
a real-world implementation, it probably would have been a better idea
to use a natively implemented facial recognition pipeline with
TensorFlow instead of a network API. But given our time constraints, the
API served us very well.
The Realtime Firebase Database
The
Firebase database was another fundamental piece to our puzzle. Every
other component interacted with it in real time. Firebase allows
customized change listeners to be created upon any data within the
database. That feature, coupled with the easy set-up process, made it a
no brainer to use.
The
schema was incredibly simple. The database stored an array of items and
an array of users. The following is an example JSON skeleton of our
database:
New users would be added to the array of users in our database after registering with the Kairos API. Upon entry or exit, the customer’s boolean in_store attribute would be updated, which would be reflected in the manager and personal app UIs.
Customers picking up an item would result in an updated item stock. Upon recognizing which customer picked up what item, the item’s ID would be added to the customer’s items_picked_up array.
I had planned for a cloud-hosted Node/Flask server that would route all activity from one device to another, but the team decided that it was much more efficient (although more hacky) for everybody to work directly upon the Firebase database.
The Manager and Personal Customer Apps
John, being the iOS wizard that he is, finished these applications in the first 12 hours of the hackathon! He really excelled at designing user-friendly and accessible apps.
The Manager App
This iPad application registered new customers into our Kairos API and Firebase database. It also displayed all customers in the store and the inventory of store items. The ability to interact directly with the Firebase database and observe changes made to it (e.g. when a customer’s in_store attribute changes from true to false) made this a relatively painless process. The app was a great customer-facing addition to our demo.
The Personal Shopping App
Once the customer was registered, we would hand a phone with this app installed to the customer. They would log in with their face (Kairos would recognize and authenticate). Any updates to their cart would be shown on the phone instantly. Upon exiting the store, the customer would also receive a push notification on this phone stating the total amount they spent.
The Item Rack, Sensors, and Camera
Soheil and Ruslan worked tirelessly for hours to perfect the design of the item shelf apparatus and the underlying Pi Python scripts.
The item rack apparatus. Three items positioned in rows, a tower for the security camera, and ultrasonic sensors positioned at the rear
There were three items positioned in rows. At the end of two rows, an ultrasonic proximity sensor was attached. We only had two ultrasonic sensors, so the third row had a light sensor under the items, which did not work as seamlessly. The ultrasonic sensors were connected to the Raspberry Pi that processed the readings of the distance from the next closest object via simple Python scripts (either the closest item or the end of the rack). The light sensor detected a “dark” or “light” state (dark if the item was on top of it, light otherwise).
When an item was lifted, the sensor’s reading would change and trigger an update to the item’s stock in the database. The camera (Android phone) positioned at the top of the tower would detect this change and attempt to recognize the customer picking up the item. The item would then instantly be added to that customer’s cart.
Entrance and Exit Cameras
I opted to use Android phones as our facial recognition cameras, due to my relative expertise with Android and the easy coupling phones provide when taking images and processing them.
The phones were rigged on both sides of a camera tripod, one side at the store’s entrance, and the other at the store exit.
A camera tripod, two phones, and lots of tape
Google has an incredibly useful Face API that implements a native pipeline for detecting human faces and other related useful attributes. I used this API to handle the heavy lifting for facial recognition.
In particular, the API provided an approximate distance of a detected face from the camera. Once a customer’s face was within a close distance, I would take a snapshot of the customer, verify it against the Kairos API to ensure the customer existed in our database, and then update the Firebase database with the customer’s in-store status.
I also added a personalized text-to-speech greeting upon recognizing the customer. That really ended up wowing everybody who used it.
The result of this implementation can be seen here:
Once the customer left the store, the exit-detection state of the Android application was responsible for retrieving the items the customer picked up from the database, calculating the total amount the customer spent, and then sending a push notification to the customer’s personal app via Firebase Cloud Messaging.
Of the 36 hours, we slept for about 6. We spent our entire time confined to a classroom in the middle of downtown Toronto. There were countless frustrating bugs and implementation roadblocks we had to overcome. There were some bugs in our demo that you probably noticed, such as the cameras failing to recognize several people in the same shot.
We would have also liked to implement additional features, such as detecting customers putting items back on the rack and adding a wider variety of items.
Our project ended up winning first place at the hackathon. We set up an interactive booth for an hour (the Chipotle box castle that can be seen in the title picture) and had over a hundred people walk through our shop. People would sign up with a picture, log into the shopping app, walk into the store, pick up an item, walk out, and get notified of their bill instantly. No cashiers, no lines, no receipts, and a very enjoyable user experience.
Walking a customer through our shop
I was proud of the way our team played to each individual’s strengths and created a well put-together full-stack IoT project in the span of a few hours. It was an incredibly rewarding feeling for everybody, and it’s something I hope to replicate in my career in the future.
I hope this gave you some insight into what goes on behind the scenes of a large, rapidly prototyped, and hacky hackathon project such as EZShop.
I
don’t really understand most of the proposals to “regulate” Facebook.
There are some concrete proposals on the table regarding political ads and updating antitrust for the data age,
but other punditry is largely consumer advocacy kabuki. For example,
blunting the data Facebook can use to target ads or tune newsfeed hurts
the user experience, and there’s really no stable way to draw a line
around what’s appropriate versus not. These experiences are too fluid.
But while I want keep the government out of the product design business,
there’s an alternate path which has merit: establish a baseline for the
control a person has over their data on these systems.
Today
the platforms give their users a single choice: keep your account
active or delete your account. Sure, some expose small amounts of ad
targeting data and let you manipulate that, but on the whole they
provide limited or no control over your ability to “start over.” Want to
delete all your tweets? You have to use a third party app. Want to
delete all your Facebook posts? Good luck with that. Nope, once you’re
in the mousetrap, there’s no way out except account suicide.
BUT
is that really fair? Over multiple years, we all change. Things we said
in 2011 may or may not represent us today. And these services
evolve — did we think we’d be using Facebook as a primary source of news
consumption and private messaging back when you were posting baby
photos? Did you think they’d also own Instagram, WhatsApp, Oculus and so
on when you created accounts on those services? We’re the frogs, slow
boiling in the pot of water.
What
if every major platform was required to have something between Create
Account and Delete Account? One which allows you to keep your user name
but selectively delete the data associated with the account? For
Facebook, you could have a set of individual toggles to Delete All
Friend Connections, Delete All Posts, Delete All Targeting Data. Each of
these could be used individually or together to give you a fresh start.
Maybe you want to preserve your social graph but wipe your feed? Maybe
you want to keep your feed but rebuild your graph.
Or for Twitter: Delete All Likes, Delete All Tweets, Delete All Follows, Delete All Targeting Data.
Or for YouTube: Delete All Uploads, Delete All Subscriptions, Delete All Likes, Delete All Targeting Data.
The
technical requirements to develop these features are only complicated
in the sense of making sure you’re deleting the data everywhere it’s
stored, otherwise every product already support “null” state — it looks
very much like a new account. This leads me to believe that the only
reason these features don’t exist today are (a) it would be bad for
business and (b) actual or perceived lack of consumer demand.
Anecdotally, it feels like (b) is changing — more and more people I know
wipe their tweets, talk about deleting their histories, and so on.
Imagine the ability to stage a “DataBoycott” by clearing your history if
you think Facebook is taking liberties with your privacy and such. This
is what keeps power in check.
As we’re getting ready to ship your Axum earbuds next month,
we still get lots of questions from customers about the sound quality.
How’s the highs? what made your bass so good?
So I’ll try to explain in 2–3 minutes how implementing Qualcomm’s technology helped us achieve CD-Quality sound.
For those of you who’ve been living under a rock, Qualcomm is the world leader in mobile technologies.
Several years ago they’ve acquired a company from the UK that changed the game in wireless audio.
What’s so special about them?
Well, let’s just say they took the CD-Quality sound and were able to reproduce it over wireless connectivity-
Yes, I know it sounds simple but it’s quite a big problem.
As we said in the past, we’re using it in Axum and that’s 1 of our secrets.
Now
for those of you who want to get technical and learn more (I’ll be
honest with you, once the engineer told me about it I spent the night
digging into it) I’ll explain how it works:
When sending music over wireless connectivity,
it breaks as the bandwidth isn’t big enough.
So what they did?
They split those files into smaller ones,
this way you can stream it over wireless connectivity.
But the best part?
You’ll get the same wired sound quality!
As for the bass, what made it so good is:
Our custom made driver, that we’ve been testing over and over for the last 14 months
Maybe
you saw those $1 speakers that you place on your table and suddenly the
entire table starts shaking from the bass (I’ll ignore their
joy-risking horrible sound quality)? as it turns into the kind of bass
box for the speaker. Great, so one major factor with sound is the
acoustics and shape of the earbuds and that’s why we had to do so many
tests with the plastics and internal design. We knew that every 1mm
change (especially with such a small product) will have a huge impact on
the sound.
In production, like in life, there are no shortcuts.
You want to achieve the best?
You want to make an awesome product?
You want to beat the competition?
Well, in such case you’ll have to outwork your competition!
We knew the ONLY way to achieve success was to push our limits
and make another test, another prototype, another upgrade,
and when we thought “that’s it, Axum is ready…” to try another change,
another solution to make it even better.
And trust me, we wish we could make it on the first try and ship it.
But that’s the beautiful world we’re living it,
full of surprises and great rewards for those who go all-in with their goals.
These kind of things (and hundred more) is what turns Axum,
We
are happy to announce another huge achievement, with the release of the
much awaited ARK Mobile Wallet. That’s right, you can now vote for a
delegate, send ARK, or just check your balance straight from the palm of
your hand. No sync needed, just open the app and conduct your business.
ARK’s
mobile wallet is a hybrid application (using the same codebase for
Android and iOS which helps with coordinated development). Created using
Ionic framework and ARK’s TypeScript API to interact with the ARK network via your mobile phone, anytime, anywhere (as long as you have an internet connection).
The
ARK wallet is still in a Beta version so you might encounter some
quirks and bugs while checking it out. Give it a spin and please provide
us feedback so we can improve our wallet in upcoming releases.
The QR scanner is not compatible with ‘Ionic View — Test Ionic Apps’ so it won’t work on iOS.
This
is currently a workaround as we are still waiting on approval from
Apple (they are very strict with finance and cryptocurrency apps). When
we get final approval for the iOS App store we’ll let you know via
social channels.
Highlighted Features
Import your existing passphrase (import by QR feature or write/paste your passphrase).
Generate a new passphrase.
Encrypt access to your profile with a custom 6 digit PIN (AES256+PBKDF2).
Most transaction types are available: send, receive, vote, unvote, register a delegate.
Connects to both mainnet and devnet.
Option for additional profiles (separate profiles for different ARK addresses or networks).
Option to add contacts and easily transact with them.
Total balance of your combined ARK addresses.
Wallet backup — input your selected PIN to decrypt your wallet and gain view of your private data.
Change PIN — if you want to change your encryption/decryption PIN you can easily do so.
Clear Data — you can clear all your data from the phone (note: this will also delete all of your wallets so if you haven’t yet you should make a backup!).
Overview of network status with an option to change peer.
Current market value, along with weekly movements.
Support for showing data in different FIAT currencies.
Future
In
the upcoming months we are going to be polishing up the ARK mobile
wallet with input from ARKs community developers and users. We also aim
to integrate:
Ledger Nano S support via On-the-Go (OTG) cable/adapter.
Dark theme.
Adding
an option to add custom network types (eg. your own ARK-based chain or
for instance Kapu, Blockpool, …) just from 1 IP address — use ARK wallet
for any current or future ARK based blockchain project!
Ability to allow your fingerprint to act as a PIN to unlock your wallet (optional of course).
Notifications of receiving transactions.
Adding more localizations (you’ll be able to help in this regards to get ARK mobile wallet translated into your local language).
It’s both more serious and less serious than we’ve admitted
I’ve
recently seen a lot of very anxious responses from people in tech at
anything which suggests that their “core skills” may be devalued,
especially in favor of other skills which they haven’t spent their lives
on. Most importantly, this shows up in the argument over “hard” versus
“soft” skills. That anxiety is itself a signal of how important this has
become. But there’s a hidden assumption we’ve been making that (I
suspect) has increased the anxiety far out of proportion: and maybe
perversely, it comes from not taking soft skills seriously enough. Today, I’d like to share some thoughts on what’s actually happening, and a set of things we can do to help fix it for all of us.
The hard and the soft. Left: “Hammer” by 0Four; Right: “Cloth in the Khiva Market” by eatswords.
1. Some observational data
One
of the most reliable ways I can see anxious responses on the Internet
is to suggest that soft skills may eclipse hard skills in importance for
engineers. By “anxious responses,” I don’t mean “disagreement:” I
specifically mean emotionally charged disagreement. And that emotional charge is a very important data point.
One
very reliable pattern I’ve observed in a lot of situations is that the
strength of people’s emotional response to a statement tells you a lot
about how close this statement cuts to their biggest worries. It’s sort
of obvious if you say it that way, but if you apply it as a detection
method, it’s very powerful: strong responses lead you to where the real
problems are, the real threats to people.
(This
trick is shamelessly stolen from psychology, specifically from
psychotherapy, where it’s a reliable way to figure out which issues are
most salient to someone. A good rule of thumb is, the harder something
is to talk about, the more likely that it’s important. It has many other
applications, as well; for example, if you find people very offended by the suggestion that they might be or like something,
that’s often a sign that this “something” is closely associated with a
group that they’re similar enough to that they’re at risk of being
mistaken for it, but that they have a very strong reason not to want to
be affiliated with.)
What’s interesting in this case is that people are so
concerned about the relative value of soft and hard skills, and not,
say, overall economic fluctuations or an oversupply of engineers, two
other things which could just as easily threaten an engineer’s status.
We
can treat the frequency of strong emotional responses as a sort of
covert wisdom-of-the-crowds signal. With regards to cultural matters,
the wisdom of crowds is an even better signal than it is in general,
because the culture is made up of those very same crowds. Reading the
pattern of conversations and responses over the past few years, the
scale of anxiety I see when the issue comes up suggests a pattern: lots
of people have the gut instinct that the rise of “soft skills” is going
to be big, but are afraid of what that may mean for them.
2. What‘s going on beneath that
Stepping
back a bit, it’s not horribly surprising that it would be big. The
reason the “brilliant, irascible loner” has become increasingly rare is
that very little technology is built by a single pair of hands anymore.
My previous job consisted, in no small part, of trying to build and
maintain a consensus among hundreds, sometimes even thousands, of
people, in order to keep everyone moving in one direction. This was
something extremely difficult; like most people in the field, it’s very
far from what I was trained for, and I had the perpetual sense that I
was faking it and hoping nobody would notice.
When
you’re working with large groups of people, communication and
collaboration complexities quickly become the dominant factor in success
or failure. Concepts like “psychological safety” and “mutual trust”
become the things that dominate your day-to-day work far
beyond any specific technical challenge. At the junior level, it’s
because this affects your quality of life: trying to do good technical
work while surrounded by people who hate you is both difficult and
awful. At more senior levels, this becomes more and more of your
responsibility to manage and create. This is closely tied to the deeper
difference between junior and senior roles: a junior person’s job is to
find answers to questions; a senior person’s job is to find the right
questions to ask. The number of purely technical questions requiring any
given level of expertise decreases relatively sharply once you pass a
certain threshold, and the increasing prevalence of everything from
reliable compilers to Stack Exchange means that more and more of the
hard technical questions are straightforward to answer.
[Bad management] is a field that was built up out of people who often believed
that they had good soft skills, while actually having atrocious ones.
The simple fact that people feel not respected by their managers should
be a tremendous red flag.
There
always remain various hard ones, of course, which are critical and
which can’t be solved by any number of inexperienced people except by
them getting experience; that’s why we need to continue to build and
grow our technical skills. But if you continue to grow your skillset,
you’ll quickly discover that the amount of time that needs to be spent
on these extremely difficult technical problems tends towards
significantly less than a full-time job; instead, the crucial (and
incredibly hard) problems that affect a system have more to do with how
that system interacts with the outside world — which is, more and more,
people.
Interestingly,
there’s a lot more crossover between hard and soft skills than many
people realize: when you start to see your system as a component of a
larger system which includes humans as elements, and you start to ask
how humans interact with each other and what their behaviors are, then
many of the same “hard skills” systems design approaches not only make
sense, but can provide even better answers to traditionally purely
“soft” questions. Abuse prevention on multi-user systems and result
ranking of all sorts are two classic examples; in both cases, the
ability to convert freely between very “soft” intuitions about what
people want and very “hard” mathematical expressions of those same
intuitions is priceless.
But
beyond the cases where soft and hard skills overlap within the
technical work itself, a lot of the “soft skills” being required now
have a lot more to do with people management. This is a field which
historically has a bad rep among engineers, because it’s historically
been done by people who had no engineering skills, and crucially, who
lacked respect for said skills
or the people who had them. This is because a lot of management came out
of the early 20th-century version of industrial management, the same
field that gave us phrases like “human resources:” the workers are an
annoyance and an expense, something which has to be “managed” to keep
production quotas high.
This
kind of “management” — I use the term loosely — doesn’t constitute good
soft skills, either. It’s a field that was built up out of people who
often believed that they had
good soft skills, while actually having atrocious or even actively
pathological ones. The simple fact that people feel not respected by
their managers should be a tremendous red flag: a manager’s basic job,
after all, is to coordinate people and get them to work as a team, and
if they can’t hack the most basic aspects of mutual respect themselves, there’s no way they’re going to be able to create that for everyone.
The
fact is that the kinds of “soft skills” we’re talking about aren’t the
ones that come for free to anybody; they’re not the things taught in
“manners classes” or in fraternity hazings. They come from studying
people, paying attention to them, and understanding what they need even
when they can’t express it themselves — and as such are as brutally
difficult a set of skills to acquire as any other professional
expertise. Our habit of treating them like they’re not “real” skills, of
trying to deprofessionalize and devalue them, does us no favors; when
we’re called upon to do them ourselves, we quickly find out that they’re
not trivial.
(I’m
reminded of a Certain Engineer I Know who, when moving the team into a
new building, made the fateful statement that interior architecture
should be easy, he’s an engineer, he doesn’t need to get someone else to
do this. The results were certainly interesting.
Engineers, scientists, and executives all seem prone to the disease of
believing that everyone else’s speciality should be easy.)
xkcd/1831: “”We TOLD you it was hard.” “Yeah, but now that I’VE tried, we KNOW it’s hard.”
3. Good news: there’s a way out.
I
think there is one very “simple” thing we can do to improve this
situation: start to treat these skills like serious professional skills,
value them as such, and both train and hire people for having
them — the exact same way we do with every other critical skill.
A
good first step is to make sure we have, and share, a language for it.
It’s very hard to value something you can’t name. Some common tasks
which we often ignore are “make it possible for everyone to see what’s
going on in the project at once,” “create a shared language for the core
technical ideas so that everyone can explain the same thing,” “make
sure that everyone’s voice is heard, and that important warnings don’t
get lost because someone didn’t feel safe saying so,” and “make sure all
the stakeholders feel a sense of personal ownership in the project and
that their success is tied to its success.” (There are many more) Some
common measures which we often ignore are “how often will a
user/customer experience frustration or negative emotions while using
this product, and how does that affect their long-term usage?,” or “when
someone has a negative experience using the product, what is the
following experience on each time scale from 10ms to one week, and how
does that affect their experience of the product?”
None
of the things in that previous paragraph are new: in fact, they’re all
tied to professional specialities, from project management to user
experience research. But if a team as a whole treats these as side
things rather than as core to their success or failure, they can easily
end up in the middle of a disaster: milestones missed, different groups
building subtly different systems which only clash during final
integration, a critical problem being ignored until it’s too late, a
project being subtly sabotaged because one team actually didn’t want it
to succeed, users hitting one “small” bug and revolting in horror
(leading to anything from mass exodus to legal and regulatory action),
slow erosion of user trust. I’ve seen projects fail for every one of
these reasons — even projects where the purely “technical” aspects of
the engineering were beyond reproach.
To
treat such things as core rather than peripheral, we would expect that
everyone on the team have at least basic knowledge of them, enough to
evaluate their significance even if they aren’t the person running it
themselves. These need to be considered parts of roles on the team, just
like front-end engineering, back-end engineering, security, and site
reliability, and the team needs to think about who’s going to be
covering which job.
It
is more than OK for each engineer to not be individually able to do all
of these jobs. In fact, it would be stunning if any one person could
do all of these jobs. But if we treat some of these jobs as “invisible
labor,” unvalued and unaccounted-for, with skills we pretend don’t
exist, all we do is shoot ourselves in the foot.
We
do this in the obvious way by not provisioning for them. But we do it
in a less obvious way, by frightening ourselves unnecessarily. The
anxiety that this story began with is a symptom that we all know that
something is profoundly missing, and that this missing thing is becoming
more and more important. If we treat this missing thing as “not a real
skill,” something which some people (I’ve often heard “women” and “frat
boys” given as examples, typically
not at the same time) just can do automatically while engineers can’t,
then it becomes frightening because it starts to sound like engineers
are going to get thrown out in favor of random people off the street,
who will then have no respect for the engineers at all. But if we
recognize this as being a real skill — something people practice and get
good at (or bad at) over their entire lives — we have a different
language for it. That’s the language of “Crap, our team has nobody who
knows how to do X, and we’ve been faking it really, really, badly:” a
language painfully familiar to anyone who’s worked on a project before.
It is absolutely true that a lot of the people who are best at these
skills don’t come from an engineering world, because the engineering
world has been steadily failing to train people at them for decades; but
that doesn’t mean that these people don’t have any understanding of, or
respect for, engineering.
At
the risk of stating the obvious: Someone who’s supposed to be doing a
job involving coordinating engineers, or connecting engineering systems
to users, or anything else like that who doesn’t respect engineers is
going to be terrible at that job for obvious reasons, and you shouldn’t
hire them. “This person makes the team feel miserable” is a serious red
flag, not a normal side effect of how any of these jobs work.
But
to state the flip side of this: Everyone on a project needs to value,
and to understand at least enough of the basics of to participate in,
every other skill on the project. If there’s a legal issue relevant to
the system, everyone needs to know that bit of law. If there are user
studies showing that people react well or badly to something, everyone
needs to put those into their designs. If there’s a latency constraint
which makes certain classes of product behavior impossible, everyone
needs to understand the issue. And likewise, everyone needs to
understand and value the human skills: after all, you’re building a
system
Hardik Gandhi is Master of Computer science,blogger,developer,SEO provider,Motivator and writes a Gujarati and Programming books and Advicer of career and all type of guidance.
