Episode 2
Engineering service through software
"As a Software Engineer, customer service is making the right engineering decisions that put your product in a positive light for the end user, making whatever compromises that are possible to make the best experience you can for the customer..." Read More
Host:: Omar Samuels
October 1, 2018
Host:
Alright, welcome
to this episode of The Serve! Show podcast, brand new. Today we're going to be talking
to, well, his real name is Carlton Alex Dennis, but I've known him for many
years. And I just call him Alex. We've been friends for a while. Now. How long
has it been? Alex?
Alex:
I would say maybe
15 years? Somewhere around that
Host:
Around that, wow.
Well, Alex is here because, you know, we're talking about customer service. And
he is a software developer. In many ways, he fits the mold, and in many other
ways, he doesn't fit the mold. At the end of the episode, we're going to be
sharing Alex's social media details, you could probably follow him on Twitter.
And if you already do, you will know that he's maybe a little bit of a philosopher
in-waiting. So I'm pretty sure we're in for some interesting insight. But let's
just get right into it. Alex has been doing software development for a long
time. He's worked at places such as Lexis Nexis, which some of you may know.
Right now, he's an Amazon developer, but his views today are his own. He's not
speaking as a spokesperson, or anything like that. So... welcome, Alex.
Alex:
Glad to be here.
Host:
Alright, so like
I'm going to do with all my guests, I want to just jump right in and make the
first thing I want to ask, to set the mood, to give us your perspective... I
want to know, what is customer service to you? How do you see it?
Alex:
Customer service,
I mean, for me, from the point of view of a software engineer... and there's
lots of ways you can think about customer service, but from a software engineer
standpoint, I kind of see customer service as, making the right engineering
decisions that would put your product in a positive light for the end user. So
making whatever compromises that are possible but make it the best experience
you can.
Host:
Okay. So it's
sort of bringing into it already, the whole product aspect, which I've recently
realized... how important that is to the end product. It's, it's not just the
software people, but product development seems to lean heavily on everybody -
the designers, the marketers, the support representatives, everybody. So that's
an interesting take on it. And your particular perspective would be strongly as
a software developer. How long have you been doing software development?
Alex:
I think
professionally... I've been doing software development for roughly 14 years
now, for me.. or 13.
Host:
Are you sure?
Because for as long as I've known you, you've been doing software development.
Alex:
Yeah, I mean, if
you're talking about pre-college days, I mean, I, I've always done software
development on the side doing websites. And yes, when I was in high school, if
you add all that time, then it's probably closer to two decades, almost 20
years. Yeah, actually.
Host:
How did you get
into it? Would you say it's something that maybe you sort of felt drawn to? Or
did you like, just get defaulted into you know, a situation where you were at
high school, you ended up doing computer classes, you liked it, and then one
thing led to another? Or did you feel some personal call towards software
development?
Alex:
I think it's
basically just luck, luck of the draw or happenstance, because my father was
working on a PhD in a school that required everybody to have a laptop. So from
a very, you know, before everybody else knew what the Internet was, my father,
had to use the Internet and we had to have a computer for him to work on his
dissertations. So, because of that, I got introduced to computers from a very
early age, and I think that's, that's sort of is the genesis of it.
Host:
Okay, so you've
been at this a while and you've been sticking with it. So you've seen all kinds
of changes that the software industry development industry has gone through. I
myself, I've been at this for a while too. I've been, you know, coming from the
BBS and the dial-up modem days, and starting out, maybe with Assembly and
Pascal and Basic, and there's something that I've been looking at. Even from
back then there was this notion that programmers are not people person, they
lack interpersonal skills, they don't have good social skills, or the ability
to interpret what user needs are, you know, they're just nerds that you stick
in a room and slide pizza under the door. That is the kind of the way that
people have seen programmers is over the years. Have you seen a change at all
in that? How people see programmers or software developers in today's world?
Alex:
Yeah, I think
it's changed quite a bit. I mean, I remember when I was in high school, and I
would save my lunch money to buy, you know, computer magazines, and programming
magazines, and people just looked at me and say, "Nerd!", like
"What are you doing?" These days, now, I would run into someone and
say, I'm a software engineer, and then all of a sudden, they're like, "Oh,
that's really interesting". I have people coming to me and asking
me,"How do I do that? How do I become a software engineer?" So there
seems to be, a growing recognition that it's a valid job,even sought after.
Host:
Do you think it's
maybe the change, to the word "engineer", that could be making a
difference, where people have always sort of respected the engineer as opposed
to the software developer? Do you think that plays a role at all, where
"Engineer" is now being accepted as describing what you do?
Alex:
I think it's less
about the the wording and more to do with the fact that computing has become
more and more important in everyday life. Things like the iPhone, things like
smartphones are now coming to the point where they're front and center, social
media front and center. And not only, you know, the minute entertainment
sector, but there's also public sector, with politics. And, you know, it's a
huge part of today's culture. So I think people are just kind of recognizing
that it's an important part of every day life.
Host:
You can't escape
it. We were just talking because you just took a Lyft, and we were talking
about, that it was so good. You said it was so good to be in the in the car,
listening to classical music. And I was joking that you could have just fallen
asleep, which you know, where we're going now, with autonomous vehicles, that
could be really where we go with smart car. You jump in a car, you fall asleep,
you reach home, it beeps and wakes you up. But one of the things now is when
you have software developers... because the smart cars are operating on machine
learning, maybe A.I., there is a, let's say, a team of software developers
somewhere in that chain. And so they have a responsibility now to determine how
that piece of tech relates to the real world and deals with people, which in
essence, is customer service. So do you think that there is a heavier weight of
responsibility on software developers these days than it was in the past?
Alex:
Yeah, I think
that's definitely being recognized. In everywhere that I've worked. Especially
since you have people who are setting setting standards, like you know, Apple's
famously been very very strong on design and other companies are trying to get
in. Google's trying to get strong on design. So people are getting used to
very good experiences in their personal life and they want that at work. They
want it everywhere! They want it in all their apps, they want that fluid
interface. And because the affordances that we have in some of our old
technology have been so well-modeled some people say, "Why use an
app?" or "Why use computers?" when they can do things the old
way, because they're so used to it. It's gone through a long history of
refinement that certain others... like say... just calling a cab. Going out
there, hailing a cab and the cab looks the same all the time. And this is like
a certain protocol and easy. Yeah, and so the question is, how do we make
digital, all these new systems as easy as the old systems and at higher scale?
And I think that that's why the human in the humanities is a huge part in where
technology goes.
Host:
I agree with
that. You mentioned the old ways. And one of the other changes that I I've
noticed over the years is when I did software engineering, one of the things
that the lecturer and the teachers and everybody would harp about is that it's
very important, when you become a software developer or programmer to make sure
that you have excellent documentation. And I remember back in the days when you
bought software, you had to get a manual. These days, if you buy something...
I couldn't tell the last time I got a manual. You might get like a quick start
guide. But nobody really gives a manual. You could probably go online and
download a PDF. So it's like user experience and intuitiveness is front and
center. And it seems like humanities, that whole industry of human psychology
and computer interaction... human computer interaction is a bigger deal. Now,
do you think software developers are sorta having to become more rounded? So
they have to become psychologists, they have to be sort of have their feet
dangling in the whole user experience, expertise and design areas? Do you think
software developers are mandated then to be more more rounded techies?
Alex:
I mean, I think
there's a place for it. I think there's a certain product discipline that
software engineers need to know about. There's a a great book called
"Don't make me think" by Steve Krug, which talks about this whole
idea of usability and that applications should be more or less intuitive. And
it talked a lot about how you build applications that are like this. And I feel
like all software engineers should have some base understanding. But I also
think that this is hard. This is a really hard thing to do. And I feel like
there are certain people... there's actually a new discipline that's evolving,
called a UX Designer, which I feel like... is someone who should work along
with software engineers, not that a software engineer shouldn't know this
stuff. But just to say, that more attention DOES need to be to be put into
building good experiences.
Affiliate link: Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (3rd Edition) (Voices That Matter)
Host:
Okay, you touched
on something interesting there that I'm going to ask you about. Let's dive into
roles a little bit. You mentioned the, the UX Designer. So we have UX
designers, we have Designers, we have software people... do you think the
software developer role is now more of an overarching role, and then "What
kind of Software Developer are you?"is becoming a real thing?
Alex:
There's
definitely that. That's definitely happening. I mean, you hear it. If you take
a parallel in the old world, you have mechanical engineers, electrical
engineers, you have all these different types of engineers. This is happening
in software. I mean, you have Machine Learning Engineers, you have, you know,
Distributed Computing Engineers that are doing things at scale. You have...
Front-end Engineers is now a thing that's really, really coming around, because
everyone's realizing that there's, there's more to it than just programming,
there's some amount of understanding the constraints, understanding what you
can do within those constraints. And so it really becomes a discipline.
Host:
There's a book
that I read recently, I really enjoyed it, it's Deep Work by Cal Newport. And
it really looks into being able to go deep in something that you need to learn,
whatever it is that you need to accomplish. And I've been thinking a lot more
about, especially us as techies, becoming masters of our world. Again, back in
the day, when you were becoming a software developer or engineer, you kind of
had to know a little bit of everything. And the technology was moving so fast
that you had to just just learn what was on the surface and move on. But it
seems these days, you really have to pick maybe a few areas that are related,
and go real deep with it, so that you can have a better contribution... you can
be master of your area. So these days, where you need a backend engineer, you
need a backend engineer who understands everything. And so that's kind of what
I'm wondering, when you say, software developers these days, it's not what it
used to be back in the day, software developers seem to have to be more mindful
of all the facets of what it takes to produce a "Product". And when
you look at things, for example, the smartest assistants... when you say,
"Hey, Google", or "Alexa...", or whatever the trigger word
is to wake up the smart assistant... from that moment on, as an end user, you
don't really think about what happens behind it... unless you hit a bad
experience. But for it to be a good experience, it takes everyone. It takes a
Front-end Engineer and a Back-end Engineer, the persons doing the translations,
because everything has to be localized nowadays, with our global village. Do
you in your, maybe your regular work and projects over the years... Do you find
that you've been forced to go deeper? And maybe, I don't know, let go of some
of the things and just say "I'm just not gonna be able to be an expert in
everything"? Is that something you've seen going?
Affiliate link: Deep Work: Rules for Focused Success in a Distracted World
Alex:
Oh, yeah,
definitely. That's become more and more of a thing. What I do, though, I do
feel like as an engineer, it's good to go broad and deep. That's particularly
my, my personal strategy.
Host:
How does that
work?, I mean, you're a dad, you're a family, man, you've got things going on.
That sounds impossible.
Alex:
So one of the
things that's very interesting about engineering or computer engineering,
software engineering, in general, is the proliferation of content online. This
is kind of how I taught myself how to engineer I think, maybe, in some ways,
because in the very early days of the Internet, it was that people who were
building the Internet, were putting things on the internet, and they talked
about what they knew. So there was plenty of information about how to build a
website, kind of where I got started. So I kind of feel like, you know, every
new technology comes out, it's sort of... I think it makes sense to go and
investigate it, you know, spend maybe a weekend doing a tutorial, because there
are plenty... and then just get, like a working understanding of what that
technology is, but then also know within yourself, when to just stop pursuing a
particular thing, but just to know it exists. Oftentimes, knowing that it
exists, will come back around to help you when you have to engineer a solution
with people who are working in those domains.
Host:
That makes sense,
that makes a lot of sense. I want to pick up on that... when you have to, you
know, work with other people working on other things, related things. We're
gonna take a quick break, when we get back, we're gonna we're gonna pick it up
right there and talk a little bit more about that. We'll be right back after
giving our readers an opportunity to support us by checking out this little Advertisement...
Host:
We're back. We're
still talking to Alex, software developer extraordinaire. We're looking at
software development and the software developer role holistically. And kind of
trying to see a broader picture of what it is and how it impacts on customer
service, consumers, the end user who uses it, people who enjoy it in their
daily lives. We want to talk a little bit about, about roles, about the
different roles that the software engineer plays, and how he interacts with
other people. Where I want to start is... there's a show, it's one of my
favorite shows, it's called "Office Space", I'm sure you've watched
it. I'm gonna let us listen to a little clip, and then we'll discuss a little
bit. Just to set it up, it's a software development company, and they're going
through some, let's say, "restructuring". So they brought in
consultants to start to evaluate everybody's roles, and you know, your purpose
at the company, and there's this one guy... well I'm gonna let you hear what
happened...
Clip -
Consultants
What you do at
Initech, is you take the specifications from the customers, and you bring them
down to the software engineers?
Clip -
Product Manager
Yes, yes, that's,
that's right.
Clip -
Consultants
Well, and I just
have to ask, why couldn't the customers just take them directly to the software
people?
Clip -
Product Manager
Well, I'll tell
you why... Because engineers are not good at dealing with customers.
Clip -
Consultants
So you physically
take the specs from the customer?
Clip -
Product Manager
Well... no. My
secretary does that, or they're faxed
Clip -
Consultants
So then you must
physically bring him to the software people?
Clip -
Product Manager
Well, no. Yeah, I
mean, sometimes
Clip -
Consultants
What... what
would you say... you do here?
Clip -
Product Manager
Well look... I
already told you, I deal with the g******n customer. So the engineers don't
have to, I have people skills, I am good at dealing with people! Can't you
understand that? What the hell is wrong with you people!?!?
Affiliate link: Office Space
Host:
That's a scene
from one of my favorite shows. Now,as funny as it is, um, it's not fiction.
I've worked in enough development houses to know that this is a real thing.
it's becoming, I think, less so now. But people, as you talked about, before,
had programmers... the interpretation there, the way they saw them was that
they just... you just got to spit out technical code to them... what exactly
you want, and they just spit something back out at you. You had to have this
intermediary who would humanize what they do. But it seems, um, that's not the
case anymore. I'm not sure what exactly to attribute that to, if it's that the
technology is just gone too deep. But the roles HAVE changed. You are now
dealing as a software developer with... you have to work off specs, you got to
work with the product team, you have to work with the designers, you have to
work with the translators, even the customer representatives, who often times
are the biggest voices and representatives of your customers inside the
company... you have to listen to them, because they are in the trenches, they
know exactly what customers experience a lot of times. What would you
attribute this change to? Why are we now having situations where, the software
developer has to be more sensitive to the customer service needs? What do you
think is causing that?
Alex:
The success of
software.
Host:
The success of
software?
Alex:
Yeah, because I
think I think in the earlier days, when software just started out, it was very
esoteric. It's being used in labs being used in government, it's being used for
high science things. Then, when we got on the Internet, the only people who
would, who found it, were people who are loners are in the corner, and they
were just, you know... btw this is this is all speculation. I don't have any
data to support this, but in the early days, you could do so much on your own
to get an MVP (or Minimum Viable Product), something just out there. Yeah,
without talking to anybody. So those skills just, weren't stuff engineers
necessarily needed to develop.
Host:
Hmm. Okay. So the
picture you painted was that in the early days of the Internet, which I can
relate to, there weren't all these browsers that you could just hop on and
browse to a site, it was about lurking in IRC channels, and finding, all these
different little gatherings and your little, your little tribes of people who like
what you like, and that sort of thing. So maybe a lot of these persons were
like myself, people who were very curious, in my own small corner. And so I
probably didn't talk to people a whole lot. And so I was able to think, oh,
this is what your need is, until I could interpret it into software back in the
day. And what I've seen, I could be wrong. But it seems to me that the
particularly successful techies, the ones who kind of have the tech skills, but
as well as some of those soft skills. Some of the rockstar techies who made
it... a lot of them have been able to interpret what was coming, what the needs
of people are, and then sort of build something to meet that need. And some of
them have really been able to I guess run ahead of the curve and so "head
it off at the pass" so to speak, and by doing that they've just, you know,
hit pay-dirt... and maybe some people have just gotten lucky.
Alex:
Well, I mean,
this is a really complex thing to unpack. One thing you said there, I think
that was particularly important where, maybe these engineers didn't know how to
talk to people necessarily, because it wasn't a required skill for them. But
you did touch on an important point where they talked to each other very
effectively... but then that creates a subculture, which, you know, isn't
mainstream, So that's One. Two: there're lots of problems that you can solve
without necessarily talking to the rest of society. I actually feel like things
like Google, things like Facebook were things that you could build them and
scale them, without necessarily having a lot of input from the rest of the
world. But now we've come to a point where, because things are becoming so
important, and things are getting more nuanced in terms of their applications.
Who that now we require a much stronger relationship between those who are
building this stuff, and the people who they're serving,
Host:
This is deep,
this is deep. Wait, let me unpack that. So, you could basically build any
platform to a point, but once it grows and takes on this life where it becomes
adopted by society, almost, you start to impact enough people who are not like
you, who are outside of the, you know, the techie circles, or, you know, these
unique esoteric kind of groupings, and then you have to start thinking outside
of your own box. And now that, as you say, with the success of software, and it
gets taken general technology has really grown, it's like ushering in a new day
where you can't just sit down and have a platform go from zero to super hero
without contemplating the impact on society. And, you know, especially with
what we're talking about, the customer service angle of it... when Facebook
maybe gets some kind of backlash or criticism about some kind of privacy issue,
it really is a customer service issue as well, because the customer for
Facebook maybe doesn't want things this way, they don't want their data
gathered, they don't want you to share this, they don't want you to sell this.
And of course, you know, everybody has those problems. It's a tightrope between
collecting data and analyzing it, and sharing it and selling it. And people
really feel strongly about those sort of things. So what I'm seeing is like,
it's technology maturing in such a way, and we have the sort of platform
infrastructure, everything now, where you can't go it alone as a techie. You
have to consider how does it impact the end user? How does it impact users...
people. Now "users" even feels like a misplaced word when you talk
about some of these things. It's just people. Especially when you're talking
about things like self-driving cars. I mean, the truth is, you get in a car,
you are a "user", but it's, it's closer to being people. And once you
start dealing with people, you kind of have to think "people first".
I'd love to hear some more comments from our listeners on what they think about
that.
Host:
But let's stick a
pin right there. And let's talk a little bit more about people. You've been a
software developer for a while now. And you've been at it so long that you're
kind of senior and over your career, you've been a team lead, and a manager,
which is kind of almost inevitable in today's world, where you move from, a
senior developer to managing a team. The first thing I want to ask you is,
what advice would you have for new, maybe even struggling developers who found
themselves turned into managers, and they have to manage people? They have to
basically not sacrifice internal customer service levels, which is dealing
with, you know, people on your own team, because Customer service is not just
inside out or outside in, it's also within the company within your own teams.
How can they maintain productivity, as leaders, as managers, without
sacrificing the all important customer service that they give intra-team and
inter-team?
Alex:
There are lots of
ways to think about that. Because, say, for instance, if you're, an engineer,
you become, team lead, probably because you're doing the right things for the
customer... And so you have very good knowledge of the product... and now
you've transitioned to manager. So you already have a high bar on quality. So
then now the question is, how do you keep that quality high when now it's
really primarily not you who are supposed to be writing the code, but other
people? There're a lot of people who say, "Well, you're a manager, but
you're an engineer. So maybe you could still write code." I have tried
this. I've written code as a manager, I've written a lot of code as a manager,
until at some point, I realized that it wasn't really serving the company best
Host:
Why is that? Is
it that you have to pick one?
Alex:
Mostly because
there's only so much that my mind can actually take at once. I think there's
different mental processes, with programming, versus when you're coordinating
across multiple programmers. It's a different type of skill set. And so I think
that if you are constantly trying to be the programmer, you could drop the ball
on inspiring the rest of the team to do work.
Host:
Would you say
that maybe one of the main goals of a team lead is to inspire?
Alex:
Well, when I say
inspire I mean, not really inspire as much as to bolster, more as in to give
them the support that they need. So when I think about in terms of going from
an engineer to a manager, and what I realized eventually, is that my role was
to actually be the manager that I wanted. That is, when I had managers who
didn't understand anything about the code. And they set these ridiculous
deadline, or they didn't give the support, they didn't feel like we should go
to conferences, or we didn't want to give us time to do learning, be curious,
like, just some time to just go and, test out new ideas that will be useful for
the business. Someone who's an engineer knows how important that is, to
engineers.
Host:
You're just
describing that scenario for me and I'm already feeling stressed out. It's
like, this is expected of you, but you don't have the manager who understands
what you need in your role and as a person to grow and to develop. And it
sounds to me like, what you're talking about is trust, maybe? Learning how to
trust your team and have your team trust you?
Alex:
Well, a lot of
it, what it is, is giving them the opportunity to be their best. So if you're
writing code, you're now writing code that someone else could have written and
learnt something from. You've now solved the problem that someone else could
have solved and really understood it. Because... one things I've learned in software
engineering, is that you learn a lot more when you do it yourself. Sometimes
you can do it yourself and you fail, and then someone explains to you how you
failed. You learn a lot more than if you never failed in the first place.
Host:
Ooh, I like that.
And I also... I've noticed a trend where failure... it's a paradox... failure
is becoming something that's (it sounds bad) a little bit more acceptable than
back in the day. And I say, it's a paradox, because I'm thinking about how much
more dependent we are on technology. And I'm thinking "You can't
fail!" You don't want a self-driving car to fail, ever! We were talking
about this earlier, and you were saying, statistically, it must happen, it's
gonna happen. But what's important is how we deal with that, maybe that first
event, but it's hard. How do you put that message out there? Let's say, from a
customer service standpoint, I want to use your self driving car, but you're
going to say to me, "You know, statistically, one of you must die someday".
That doesn't seem like great customer service. How do we approach that in this
in this new day, this new age that we're living in?
Alex:
One of the things
I think that's interesting about software engineering these days, is that we're
beginning to sort of get a stronger understanding about how to actually
architect good software. So certain patterns are now repeating, to the point
where they're kind of solid. in the early days, it wasn't quite clear what you
needed to do. And so you need to have this iterative sort of mentality, because
you need to try a lot of things in order to get things right. Now that we've
gotten to the point where we have a better understanding of what does work
well, you could argue that now it's time to step back and actually try and do
what other engineering disciplines do, which is to have stronger requirements,
and stronger upfront quality measurements. But then once you do that, you're
going to slow down. There's a trade off between, you know, how fast you want to
go, and how much quality you want to have. And I think that's a problem every
industry faces.
Host:
Is it just
something that comes with maturity, where you just have to be responsible?
Because if you even look at Facebook, they started out with the, I guess you
could say, the mantra of just move fast and break things. And there came a
point where they realized, as we were saying, before, it's no longer, some
group of techies enjoying this thing, it as a company, it has to be more
responsible. And so that couldn't work anymore. So maybe it's just a matter of
realizing as your impact on the world gets bigger, you have to step up your
level of customer service, thinking about people thinking about how you impact
them. And I guess as inevitably things go wrong, as you said, How do you make
it right, when it goes wrong? You have to think about that as well.
Alex:
Yeah, I think
that's hard. That's definitely an important thing. I haven't read enough on
this about what do you do when your service goes out, and it affects a billion
people. I mean, we're talking about, you know, the sort of scale of some of the
systems that we have today is so huge. It's sort of unprecedented in terms of
its scope. And then you almost want to say, well, we need better regulation, or
there needs to be sort of third-party verification groups. But then there's a
whole set of politics that comes with that. I think that most often, software
engineer people want to get away from that. Worse, you don't want people policing
you who don't know anything about technology, and as you said, it slows the
whole thing down.
Host:
But as you said,
everything's kind of a balance and the industry is changing all the time. And
we just hope that it changes in the right direction. And I guess the last
thing I want to kind of talk about that is on my mind is that I've also noticed
that, um, you know, as people get more senior in their career as software
developers, software engineers... it's almost like, as that whole field matures,
they're now realizing that not everyone is cut out to be a manager, not
everybody can do that kind of people management. And even though you're a great
developer, you've been doing this for years, there really are more like two
tracks. One is the Leadership Track where you want to be that senior developer
and you're like a black belt in all things, whatever you specialize in, and
you're not really managing people, you're just leading the industry, you're
making waves, you're setting the specs, you're blazing the trail. And the other
side is managing people. And for people managing people, they inspire them,
they maybe stop writing code, they don't review Pull Requests or anything like
that, but they inspire people to to be their best selves, as you say. But
either way you take it, I think there is that responsibility to people in both
tracks. In your own sojourn. Do you think that that's a good way? Do you think
that these are the two paths? Do you see a third path? Or do you think we need
to converge again, because maybe everybody has the capacity to inspire others?
Alex:
I mean, this is
one of those psychological puzzles out there in terms of why are some people
good at some things versus other things? Different people have posited
different things about this. And now I'm stepping out of my expertise here, but
I kind of agree with this sense that... I can't remember who came up with this
idea, but they posited that if you could live long enough, you could learn to
be everything. I think there is some merit to that it's really more a matter of
where your motivation lies. If you're motivated enough, you can change your
brain. I believe, with enough data points given to it that you could completely
change or in a large way, change the way that you you operate. But that being
said, I do think that, you know, right now, there's emerging a non-managerial
path of leadership, which is more of like a thought leader. That's more of
like, you know, the person who can design systems across organizations... and I
think that because software has been so successful. And because now it's been
gaining global reach, we have these particular companies and systems that are
big enough that they do require someone who's an engineer at a higher level...
an engineer who can work with more junior engineers, or, you know, intermediate
engineers, and collaborate with them. And those people tend to, probably,
really more produce specs, but they can take all the things that they've
learned when they're building smaller components, to think about building
larger components that are going to have sub-components built by other people.
Host:
Have you been
involved in the specs building process? Have you ever worked along with
someone, or even had to roll specs out yourself?
Alex:
I have.
Host:
When you're
putting that together, like, you know, the draft or the final specs, how much
forethought is given to it so that you think about the end user? Is it a little
or a lot at that time when you're writing specs?
Alex:
So this is where
it gets interesting, right. Because as you know, in terms of specializations,
there's another particularly important role that has emerged and that is the
Product Manager. This is the person who would be that guy that talks to the
customer and can speak in "customer terms", and should be a super
user. They should really know how to use the product inside-out. It's an
advanced users should know they should be able to talk to new people. They know
exactly what the struggles are for new people, they are the people who collect
all the user data in their mind. And those people should be able to then
disstill to the engineer, you know, these are the requirements. And then the
engineer says, "Okay, these are the requirements, I'm going to build a
system that fits the requirements". Now, often what happens though,
especially when you're starting a new product, which there is no data, there's
very little customer data... you're going off of speculation as to what you
think the customer wants. Maybe that visionary knows something about that
space, because they worked in that space. Maybe they were a travel agent
before, and now they're working on a travel product. But what often happens,
though, and I think this is where the engineer does have some responsibility,
is that I think oftentimes the customer experience, degrades to what the
software engineer decides is most important, especially when you have time
pressures. If you know, that you have the UX designers, and they say, this should
be the experience, and your designers, say that this is the color scheme... and
you have product managers that say, this is what's most important to the
customer... and the engineer comes around and says, "Okay, this is the
time you want me to get this done? This is the compromise that, I'm gonna
make". So then the engineer ends up deciding that customer experience.
Host:
What's
interesting is that a year from now, when the customer complains about
something, and then you go and say, "Why is this like that?", and
somebody says: "Oh, it's because... ... I don't know why". And then
when you check the history, it's just that there was what was essentially a
sprint of some sort. And that was just the time we had to do it. And it impacts
the customer. But it was never intended to be a long term thing, it was a
decision that snowballed, sometimes out of control. So I'm wondering if in the
future, we're going to start seeing roles (I've seen different terms floated
around, like, support heroes) and people within the team structure and
organization and a company whose job it is to follow these things up. Because
oftentimes, as you said, developers are working under pressure and they don't
have time often to stop and say, "Okay, let's clean up code debt", or
to go back and say "We did this and there's like a 'TODO:' in the code as
a comment and everything, how are we going to fix this next time on the next
cycle?". It just never happens. Do you see where maybe we're looking at a
role where Customer service is going to start taking on some additional roles
that will cauterize this sort of thing?
Alex:
I think it's
already happening. I mean, you see certain companies have a role called a Site
Reliability Engineer, where their stated purpose is to make sure that the
system runs well. They're not doing new features, necessarily. What they're
doing is watching the metrics, and they're seeing what customers are doing and
their optimizing the system so that the users have the best experience, making
sure availability is up, making sure things are fast. Now, you could take the
same realm (to software development) in terms of making sure features are
refined, like you could take that one step further and say, you know, is there
a role for someone who's going to refine features separately and apart from the
engineer who's doing the Greenfield work.
Host:
That's what I'm
talking about. Because right now, it seems like what you described is more of a
Back-end Engineer kind of role. And they're looking at crash logs, and looking
at what sort of things are happening, but they're still on the back-end and,
and fixing it from the back-end without much connection to the customer. And I
feel like as, you know, the whole industry and the whole role develops, we're
going to start seeing more... I don't even know what the role is going to be,
but some roles that are dedicated to connecting those dots in-between... and
not in a way that we just saw in Office Space, but it's going to be more
respected, it's going to be a respected position where people start realizing
that these platforms that we're dealing with now, it's not just all fun and
games... it's peoples' lives. And so it's very important to kind of sort out
what the customer wants and how this can really badly impacts someone. So I'm
looking forward to that day. Looking forward to that day.
Alex:
I'm sure many
people are.
Host:
Yes, indeed. This
has been a great talk. Thank you so much, Alex, for, coming to sit down with
us, this is an exciting time, and I feel like we've only scratched the surface.
I'm pretty sure we're going to have a part two with you at some point. For
users who are going to be listening to this podcast, I want to allow them to be
able to continue to follow up with you. What's the best place to keep in touch
with you? Whatis your watering hole online, so to speak?
Alex:
Yeah, so this is
interesting. I I tend to post quite a bit on Facebook, but I keep that kind of
private. But I also have a Twitter: @Alex_Dennis so I mainly post there and I
also, every now and again, post on Medium also @Alex_Dennis.
Host:
Yeah, I've seen
some of your long form articles. They're really thought provoking. Listeners,
please be sure to check it out. So once again, this has been a Serve! podcast
episode. We've been talking to Alex Dennis, philosopher in-waiting and software
developer extraordinaire. Please tune into our next episode, like us, follow
us, share us. We have some awesome things in store for you. Thank you again for
listening. And until the next time, serve!
SHARE
Listen to this episode and share it with someone who would love to learn and be inspired today.