Ray Ventura is a Computer Engineer and Software Developer currently working with LendUp. His past lives span founding a grocery-based startup, Intellectual Property work as an attorney and programming robots for NASA.
In this Codecast, Ray offers generous advice on the soft skills needed for succeeding on a Product team, explains why user engagement matters in building a market-ready product, and hints at the infamous "scope creep" habit great Product Managers help development teams and companies steer clear of.
Key Theme » Collective Ownership
"If you don’t have good Product Managers on your team who are constantly capturing the current state of a product, in a place where everyone can go and view this, you’re going to have more questions. Almost certainly you'll run into more issues than you would have, otherwise...It all sounds sort of very detailed but in the end, these are just ways in which to force everyone to do a better job of communicating: by implementing processing tools to facilitate the sharing of the state of a project, and the state of a feature." – Ray Ventura
"I think one of the hardest things to overcome is just this idea that if it’s obvious to me, it must be obvious to everyone – which isn’t true. One of the things you start to learn is just how diligent you have to be about over-communicating."
"...there’s this notion of the engineer’s relationship to the product and the engineer’s relationship to others. The engineer's relationship to the product is one in which you could very easily find yourself getting whiplash with all the changes that are being made with the product if it’s over-defined, or if there’s no intent with where you’re trying to go."
"...if you want to be a good, standout engineer, be someone who can speak out. Speak up as soon as, 'oh yeah this is isn’t working, it doesn’t make sense.' Do it in a way that’s well-reasoned."
Full Episode » Transcribed
Now we’re officially live! So now I can say, welcome everybody to the Codecast. This is a weekly discussion with awesome developers, people from the industry like Mr. Ray Ventura is a friend of mine and is a long time developer/start upper/product aficionado/everything that you can imagine – also a half marathonist!
He’s here to talk about working on an engineering team, specifically since he’s been on both sides of the management spectrum and also involved in sort of the small nitty-gritty world of product development. I think we have a lot of cool stuff to learn from, Ray officially, welcome to you!
I’m laughing because this is the third time I’ve introduced myself. Hi everyone, my name is Ray Ventura. I currently work at a company called LendUp, a FinTech company. I started my career – I started in engineering – but I actually started my career as an attorney, then left that to start my startup and have moved between sort of “up the chain.” Up the food chain so to speak, in terms of companies at different stages of funding and size.
This current company I am with, they are currently 150 people. So, this whole discussion around working with product seems to be relevant. I can definitely share experience working both at smaller organizations and now something that’s mid-size.
Do you mind, just before we dive into that, just taking a little walk backwards? Since of course you’re coming from a non-traditional background and going into software. How did you even make that transition from attorney into software, in the first place?
Yeah, that’s a great question. While I was an attorney, I spent a lot of time listening to inventors come up with and present ideas – specifically, I was working as an IP attorney. I had my own bunch of ideas. This would have been 2009. I had just started helping a buddy of mine teach a bunch of kids how to code, and this was a friend who had just gone through Y Combinator. We were living in Minnesota and he was kind of my first, I guess, informal advisor/mentor. Granted, we were the same age – but he was someone who had a particular perspective on sort of what it took to be an entrepreneur and start a company.
In my case, I was very much looking into food industry, the food space. One of the things that I was frustrated by was having to go to grocery stores to shop for food. This was before the days of Instacart. We had already seen a ton of – there was I guess, a decade before – we had a seen a boom and bust in the same space. I kind of thought it was time to revisit it.
I basically re-taught myself how to code. I say “re-taught” myself, because the truth was a lot of stuff I ended up learning in undergrad just wasn’t applicable in the web development world. But again, I was kind of motivated by this buddy of mine.
So I just set out to start building an app. I made all the mistakes when I started, and I’m happy to get into that, but basically, that sent me on a course. Here I am now in the (Silicon) Valley. There was a lot in between that but that was the starting point. It was kindling, trying to get my own thing off the ground and trying to teach myself.
So after that – well – I’m trying to think how on topic I want to stay. (Laughter) I think we will keep it engineering focused!
So, specifically after kind of hacking things together on your own what then, or how did you make the transition to a more formal working environment where you’re working as an engineer? What specifically was that like – going from one environment to another?
That’s a great question. It took about two years before I ran out of my own money – or, at least the money I was willing to spend – and I joined a friend’s startup. This was someone who had also gone through Y Combinator, a different friend. Someone who I had met in the process of building my company. It was then that I sort of had to learn to work with other engineers and developers – which is very different. The idea of having specific tasks carved up, and that being sort of the thing I would work on – versus, whatever it was that came to mind in the morning and sort of being my own product manager.
This was someone who had seen the work I had done. It’s always easier, obviously, to work with people that you We’d literally be sitting in coffee shops each building our own businesses – and at that time I was living up in Vancouver. I had moved out from Minnesota to Vancouver.
At the point in which I sort of shut my thing down and joined his, that was I guess my first introduction. At that point, it was myself, the founder, and then two other developers. That was my first introduction to working on a team and developing on a team.
How did you guys manage your workflow?
All it was driven, even then, this was 2012. We were working primarily through GitHub in terms of how we carved up the work. The tasks themselves were – so, to take a step back – the company, what it did was it had created an app called Simplenote. Which is a note taking app. Interestingly enough, we used that app to track our work, or to track our tasks, and it was very unstructured, but it served its purpose. Then once, as we carved up and did the work, each one of us would be responsible for viewing someone else’s code and then that code, you would create a code request, that code request would get reviewed and that the code request would get merged. That was very new to me.
Obviously now I’ve been doing it for so long I take it for granted. I don’t know necessarily whether folks coming out of programs like yours are all sort of following that workflow, but that tends to be the thing that is most common in reality.
How did you guys decide what to actually work on? Was one person acting as sort of a product lead, or were all kind of just throwing features at the wall?
Yeah, yeah. That’s a great question. A company that small, we were still very much looking for product market fit. There were some rough ideas of what we thought that looked like. We had gone from building this note taking app to evolving it to something that would be sort of the backend infrastructure for supporting other folks who were looking to sync any type of data between apps, because that’s what we managed to do very well.
We were essentially trying to – at the time that I joined – we were gearing up for sort of a big launch. Something that would get featured on Hacker News, which was easier to do because this was a company that had gone through [one seed funding round].
All the work was very much focused on the things we thought we needed in order to build a proper developer-focused product. That included like dashboards and ways in which folks could track...Think about it like Parse – as a competitor for Parse – for folks familiar with building. Which was again, like a back-end infrastructure for something like mobile devices and desktop.
It was very unstructured, especially compared to how I work now. But, I think it’s probably not uncommon for a company that is trying to sort it out.
It’s kind of interesting because you go from, kind of relearning how to code to building your own thing – which is almost like somebody learning on their own. Then you start working on another startup with a small team. It’s kind of like going to a program or something and then you kind of graduate into the – I don’t know if I’d call it the big leagues, certainly from an engineering standpoint your next gig is much more formal. So it’s almost like getting your first real engineering job, right? So what was that jump like? What did that highlight that was missing from the previous workflows and the previous interactions that you guys were doing on your team?
Yeah, I think – if I was just to look at what it was between just myself and working with a team: that’s like, one jump. And, that’s interesting, because, again it’s one thing to have all your own ideas, write those ideas down on a notepad and execute on those your little to-do list th will do this throughout the day. That’s not something, a paper and pen is not something that’s easily shared. You think about, even with the three people, the kinds of communication overhead that introduces. You start to appreciate how important it is to note the work that you’re doing and think about those things that maybe aren’t as obvious.
Strong team cohesion demands over-communication.
I think one of the hardest things to overcome is just this idea that if it’s obvious to me, it must be obvious to everyone – which isn’t true. One of the things you start to learn is just how diligent you have to be about over-communicating.
I think, and this is more of a lesson, not just what I learned between that transition – but working on my own and working with people – is just what I’ve seen in the last half decade of now working with teams, is this idea that coding itself is one thing. Once you pick it up, you can reach a level of proficiency that’s good enough. Then there’s all the other stuff that ends up being just as, if not more, important. Which is mostly around communication and sort of working on a team.
That whole moving from – my startup it was called YupEat, and the startup I joined following that – the YC company – they were called Simperium. Moving between Simperium and the company I joined after that, which was significantly bigger – that was a whole other thing. We were using much more formal tools to track our work, and I’m happy to get into that.
Actually I’d love to hear that, maybe half a step on actually what that company was doing and what type of product you’re working on and then maybe how you were working on that.
I went from a company that was basically building developer tools and had also run out of money, but was eventually acquired by Automattic – to a startup called LiveFyre. They were doing real time commenting on big publisher sites. When I joined they were a team of 30 engineers and the company itself was maybe, 60 people-plus.
PM tools to enhance team workflow.
There, we were using formal tools. For those unfamiliar there is a product called JIRA, and JIRA is very popular amongst startups that allows you to sort of manage tasks in a much more well described way. Often times things will get broken up, you may have heard this term “Kanban” but effectively, it's a way for you and for your product owners to keep track and tabs on the work that’s being done.
This is the place where we had formal sprints, which is something we didn’t even have at my previous startup. Again I don’t want to take anything for granted here – so: a "sprint" is basically the final period of work in which you hope to accomplish some milestone. It falls under this umbrella of agile development process, which again this going to be pretty relevant for anyone looking to set out and join a startup. But, this notion of let’s break things up into discrete milestones and assign smaller tasks to developers and have the developer work through those simple requests over the course of a sprint. Often times that’s work overseen by a product owner. So, that’s basically the system in which I was working once I joined this company, Livefyre.
Again, that was very much an eye-opening experience – if for no other reason that now I can see, even though we were an organization of 30 engineers – I could see what everyone was doing, if I wanted to. Just by looking at the tasks in their boards. And depending on how good they were about communicating the work they were doing, I could literally read through the tickets and have a sense for the features we were pushing out.
That becomes really important because, what you will start to notice is there is no shortage of folks who have been around since the beginning – who are unsure about how a product works just because so many hands touch it. If you don’t have good Product Managers on your team who are constantly sort of capturing the current state of a product, in a place where everyone can go and view this, you’re going to have more questions. Almost certainly you'll run into more issues, than you would have, otherwise.
Again, it all sounds sort of very detailed but in the end, these are just ways in which to force everyone to do a better job of communicating: by implementing processing tools to facilitate the sharing of the state of a project, and the state of a feature.
That actually leads into my next question for you, Ray, which having worked on a lot of teams you’ve also had exposure to a lot of engineers. You’ve had a lot of exposure to different types of interactions, situations where things have gone well, where things maybe haven’t gone well. I’m really curious to know some of the – I don’t know if you want to start with the positives or the negatives – but there are success factors and then there are challenge factors when you have a group of engineers working together.
I’m curious to know what’s good, what doesn’t work, what have you seen from the trenches?
It’s funny you comment about that. So I went from LiveFyre to LendUp, LendUp is the company I’m currently with, and I’ve seen huge differences just between these two companies. The compnay I'm with now, LendUp, is a company of a 150 people.
I think one of the things that was most obvious to me in this transition is a lot of the troubles that we ran into as a company at LiveFyre – this is prior to me moving on – was related to a product that was ill-defined.
Be wary of building products that are "ill-defined."
What I mean by that is: we were very much at the mercy of these big publishers. We were doing a lot of one-off work, and that one-off work – there’s this notion of the engineer’s relationship to the product and the engineer’s relationship to others. The engineer's relationship to the product is one in which you could very easily find yourself getting whiplash with all the changes that are being made with the product if it’s over-defined, or if there’s no intent with where you’re trying to go. Even if there are, sort of small course directions along the way, if you’re not very clear about where you’re trying to go, it’s very easy to find yourself sort of getting sort of tossed around. As a result, it makes it difficult just in dealing with other people on your team, and not from an interpersonal standpoint. Just from like a place of: "OK wait – you’re working on what?" This kind of gap in knowledge that exists because one person has been told one thing and another person has been told another.
A lot of that, again, if you’re dealing with a product that’s ill-defined, it’s almost unavoidable. Spending a lot of time upfront to understand and get an appreciation for what that final thing should be, it’s a very important starting point. That’s the thing you want to put the most of your time in upfront, and I say it’s the opposite from where I am now.
One of the things I have seen is we’re (at LendUp) very clear about what we’re trying to do and the Product Managers are very much crucial in defining this "spec," which a spec is just a specification that describes what the final product is meant to be, or the final features are meant to be.
It makes it much more effortless, your own dealings with other engineers, or other team members. In our case, at LendUp, a team is made up of not just engineers but it’s Compliance, and Legal. It can be just any number of people. So clarity across all those different functions has been huge.
I think what you start to see with personalities is a whole other thing. Engineers come in all stripes and I think – this is why I was saying, that once you’ve reached the base level of competence – a lot of it is just interpersonal. I think what we’ve done, here at LendUp we have all of our values written up on the wall. There’s like five of them, and one of them is "No bozos, no assholes." Excuse my "french." Having that be a part of our recruiting strategy has definitely insured at the very least, you have sort of some – you kind of know that the people you are dealing with are generally good. There are things that you are trying to overcome whether it’s differences in how things should be implemented are sincere, coming from a good place rather than ego-driven, a part of the ego. Those are the things that torpedo projects. So what you find is you can get past these things and that’s because you have people genuinely interested in seeing this feature be the best it can be.
That’s a big part of working on teams.
You mentioned three questions in this series here. One is: can you actually describe the actual makeup of the team and your daily interactions, like what types of roles were you dealing with and working with and how is like a team unit structured? I guess probably at LiveFyre, you said there were some pretty valuable lessons to takeaway.
Right, the LiveFyre team was much less – at LiveFyre I was overseeing the Tooling and QA team. I didn’t start with them, but that’s kind of where I ended up. We were primarily responsible for product management. Based on the understanding of what the product should be. So there is literally two full stack developers focused on feature rollout, and a QA team focused on ensuring that stuff we are releasing to our customers wasn't broken. So that’s probably not a typical makeup of a team.
The team at LendUp is very different, we are two back-end engineers, a front-end engineer, someone who basically manages the relationships with our partners – which ends up playing a very crucial role in how we develop our product, and I can get into details as to why. That interaction is slightly different. Once we have a feature one of the things that happens – almost immediately – is an assessment of, sort of a conversation between the back-end team and the front-end, or in my case the two back-end folks and myself about what implementing that feature requires in terms of endpoints. In terms of, if we need to be making changes to the data model, and then what we expect that user interface to look like.
At times, it’s driven by what that front-end user experience should be. At other times, it’s driven by the constraints of what the back-end are. But in any case, it’s all very nebulous to start. But we’re essentially working it into an existing framework. In other words, we have already developed a list of best practices for implementing a new step in our application flow and that’s pretty straightforward. Or, its new and it requires this bit of iterative approach to saying we have to come up with five new endpoints and the front-end interaction should be making requests at these endpoints at five different times in order to get to this new user state.
That sounds pretty big but generally that’s kind of how that plays out at LendUp. So, two very different things. One at LiveFyre was basically self-managed in a lot of ways. Here, once we have the spec, it’s very much driven by this iterative approach between the front-end and back-end, whereas LiveFyre we were doing [combining] full stack development.
That makes a huge difference.
So the question is actually related back to what you were talking about before. It sounded almost like the way a team begins to spiral out a little bit, spiral away from its focus and people don’t know what other people are working on, and it just evokes an image of things come around a little bit over time.
Even if you have a product that’s well specked out right at the beginning, obviously software development is dynamic and everything changes and product specs are going to change. So as you go through this process over time, as any team goes through this process of – "well, we thought we knew what we were building but things changed and now we need to figure out how to work with that."
Who’s job is it to actually really stay on top of that?
As an engineer on the team, am I looking for a Product Manager all the time, [asking,] "why aren’t you telling me what’s going on with my product?" Or, is it my job to talk to all the other engineers to figure it out? How do you prevent that unraveling and spiraling out from happening?
Great developers speak up on successful Product teams.
The worst thing you could do is implement an improvement no one knows about, or modification that no one knows about. If you’re good – you don’t want to be passive in the process – another value that’s up on the wall here is "act like a winner." You kind of expect everyone to speak up when they run into that, you know? "This was specked to be X, but in fact if you were to do that, you’d run into a whole new set of issues which would be better if we abort it."
That comes — this idea of being vocal and communicating it out, I think that comes with confidence and understanding the platform and user interactions. You definitely see it from folks, you often times see folks who have been around longer be more vocal – because they appreciate the nuances and things that may be overlooked by say, a new product manager.
It’s incumbent, I think, on the engineer. Again if you want to be a good, standout engineer, be someone who can speak out. Speak up as soon as, "oh yeah this is isn’t working, it doesn’t make sense." Do it in a way that’s well-reasoned. You don’t want to be just – the other thing you want to avoid is being the guy who's like: "this is dumb or this stupid," you know, and so on. You sort of want to be positive and action-oriented. I think that’s the way to think about dealing with the "evolving spec."
OK. The last one [question] actually relates to that as well, when you were talking about the differences between the engineer who takes charge versus the engineer who kind of sits back, versus the engineer who’s pooh-poohing every change.
How do you, as someone who has presumably been on the other side of the table looking at growing teams and hiring engineers, how do you look at prospective candidates and try to perform that weeding out process to look for the ones who actually meet the criteria that make them successful on a team?
That’s really important. In fact, even here, I do a lot of phone screens and just interviews, interviewing people. I think one thing I definitely look for are folks who have worked on teams and implemented. I love entrepreneurs, that’s one. I think entrepreneurs if they’ve been doing it for a while, appreciate this give and take. It’s not sort of single...you find that some people can be very single minded in the way they view the engineering role. Oftentimes, I find entrepreneurs to be a bit more flexible and adapted. But, in addition to that, those folks who have worked on teams, just hearing how they describe their experiences working on teams, it’s often very telling. Someone who says, "I built this and it never got implemented because no one understood what I was doing."" I think those are huge red flags. Folks who are talking about how they sold it to other team members or this idea they’ve had, they went about implementing, or whatever. I think that speaks volumes because that’s basically what you’re constantly having to do; you’re basically selling yourself and ideas. If you’re good at that, it shows. I don’t know if EQ (emotional intelligence) is necessarily the right term, but there’s an intelligence there I think is necessary for being a good teammate.
I’m trying to think of other things that often times jump out at me. The idea, I think the most important thing when you’re going through this interview process, is focusing on how it is you communicate the times you’ve worked on teams. Then, sort of what your deliverables were and highlighting how you related to the people you worked with on those teams. I think that’s most people who will be interviewing will be listening for. At least that’s definitely true for me.
Communication again, you can tell right off the bat. If I’m on the phone with someone and the questions they’re asking weren’t solid questions, or they’re not able to express themselves well, those things jump out, for sure. It suggests to me that it might be hard to get them to speak up when they need to, while working on a team.
That is totally something that I would love to dive deeper into, but this is for all of you guys, so please speak up! I want to hear some questions from the crowd.
STUDENT Q: [Kit]
Well, first of all thanks Ray, it’s been interesting. I guess, just curious – what you find the qualitative difference between you said working in a small team and worked all the way up to a much larger team, or a company of 150 people.
What does it feel like for your role in that? Do you feel like a cog, do you feel like you shrink down into this perfectly fashioned cog for this one role?
Yeah, I think that’s inevitable. One of the things I found the hardest transition for me was this notion that at one time I was thinking about all the problems, and eventually I had to sort of narrow down the scope of the problem that I had to think about. I think if I'm on a team I’m excited to work with every day – the way it works at LendUp is we have pods. I happen to be working on a team that’s specifically focised on credit cards but then we have all these other pods scattered throughout the office, working on different parts of a product. It still very much feels like you’re all in the same boat. The fact that we’re specializing within our particular areas, to me, makes sense.
I am now technically, an investor in the business in addition to an employee, and what I mean by that is I have equity. I bought in. So, I know that we get the best work if we’re not sort of scattered in terms of the types of problems that we have to work on. I get it – so that makes it easier to accept. This is probably the most efficient way in which to run this business. I also think that if you’re observant and keen, you’ll often find problems whether it’s within the dynamic you’re currently working or outside of it. There’s nothing from stopping me or anyone else from spending all the extra hours, my waking hours, coming up with solutions to those other problems – wherein my solutions would probably get adopted.
That’s always an option. But the reality is yeah, over time as you move to bigger teams, you’ll start to work where the focus gets very narrow. I think that is a consideration for what you want in your own development.
STUDENT Q: [Kit]
And you are enjoying that trade-off?
Yeah, for me it’s been an adjustment but I appreciate it because I actually see the results of the focus. Had you asked me that immediately after undergrad, when I was working at larger – one of the first places I worked was co-op – it was a large company agency while I was in school and it was the worst, but I didn’t have the full appreciation. And it was the worst because I was basically – to your point, very much focused on the smallest widget of the smallest unit – you know?
It feels very different now because one: there’s very much transparency. There's transparency in the organization. I guess for me the finer appreciation that we’re getting better work out of everyone including myself, because I’m focused.
I like it; it makes sense for where we are as far as a company. You know, would I go back in starting my own thing and take a shot at taking on the world, yeah for sure. I think that’s just the thing I have.
It's just your spirit!
STUDENT Q: [Kit]
Well, thanks that makes a lot of sense.
STUDENT Q: [Andrew]
Hey Ray, thanks. I had a question about the relationship between Product Managers and engineers. So far, you've talked about how beneficial it’s been to keep things focused and on track, but has there been a case where a product manager has been too driving – I guess, too head on... Obviously it depends on the context and everything, but sometimes has it been too focused?
No, that’s a great question. I think one of the things that we’ve been good about here, is the people that we have brought on to run projects, or to work with the company – who are Product Managers – are pretty sensitive to that. One of the things I think most engineers have problems with when it comes to Product Managers is this idea that they’re not technical so they won’t understand. I think Product Managers here are focused on the right things. I think the second you have a product manager that’s keen to make judgments on implementation versus feature, what the details of a feature need to be – I think that’s sort of when it crosses the line and that’s where engineers and Product Managers bump heads. So be wary, that’s the thing to look out for sure, if you’re interviewing somewhere.
A Product Manager that has experience as an engineer and who has the suggestions on how things should be implemented, again that might be good – but it might be bad. It might be bad because they’re no longer spending as much of their time in development, so their perspective may no longer be as relevant.
We do have someone here who was previously in my role – and this would have been two years ago, three years ago, who then went on to product management. But, this person has an incredibly high EQ which means he’s very attuned to sort of the needs of the engineer and in addition to that, despite having this kind of intimate knowledge of the code – because he’s one of the original engineers. He knows now that it’s more important for him to get other parts right, which are the definition of this thing. And in our business, that’s hugely important because every time we launch a new product, we’re sort of at the mercy of the regulatory bodies across different states. We're basically loaning money. So getting all the things right around pricing, around how long a payment window can be and all that other stuff is something that can really take up 100% of his time. So, in the end it works
I don’t know if that answers your question.
STUDENT Q: [Andrew]
Yeah it did, thank you. It’s insightful because it depends on the company, right, and the culture they foster. Sometimes they have a Product Manager there, too, as you mentioned, are really sticky on implementation features so that’s something to watch out for, so thank you.
We have a question from the app here.
The question is, I don’t know if you can read this or not, Ray but: “ ‘for folks studying to become a professional developer, at some point they may run into the terms ‘agile’ and ‘waterfall.’ What are these to a developer? What are these to a Product Manager? Which is best for building software that’s market-ready?’ ”
That’s a great question. You’ll often hear – the connotations that go with waterfall often tend to – a developer who hears waterfall often times will snicker and probably rightly so. But, it depends I’ll say that. Agile is often times associated with this sort of, more “modern way” of doing product development.
Let me just make sure I’m getting all the details of the question. The notion of waterfall implies this idea of being incredibly elaborate – upfront – about all the things this product should have as its sort of feature set. Then setting out on this three month long journey of building all these features before releases into the public.
Whereas this notion of agile development is much more about releasing smaller feature sets and getting immediate feedback and sort of tweaking and improving on that, successively. The philosophical difference is this idea that whatever I build today I know won’t be relevant even a month from now, so trying to plan out beyond that is a foolish errand.
That’s basically the philosophy that drives this notion about agile which is like: because we believe this is true, this idea that I can’t anticipate what the market’s going to want a month out from now, my best bet is to continue to push. I recognize my own weak point, I know that it’s much more important for me to get stuff out to the public, get my customers to provide me feedback on that so I can improve and build on that.
I think there is probably room for both in the world. I think the kinds of problems that we work on are mostly problems that fall right under that agile category, but if you were to show up at Tesla, I don’t know that you could build a car working with that methodology, with that agile methodology just because of all the things that go into it. Or, launch a rocket, for that matter!
You’re almost certainly going to, whatever role you find yourself in, in the coming months will almost certainly fit well within that agile development. But I wouldn’t immediately disregard, well it depends...you may not want to be able to disregard that.
(0:47:52 audio distortion).
To an engineer it means potentially working on a product for a month, or working on a code base for a month, two months, three months before actually getting any feedback as to what you’re working on is the right thing, from a product-market fit standpoint – with waterfall. It’s longer cycles and (0:48:27 audio distortion) the code then becomes available to the public. That’s really what it means from an engineering standpoint.
STUDENT Q: [John]
I’ve got a question. So, from the product management point of view, is there anything in particular you feel that engineers really don’t see on a day-to-day basis and I’m thinking specifically in terms of why product monetization and specifically, also in terms of like: software, products or software services that really might not monetize at the VC level. That’s there a lot of effort that the engineers may or may not – how is your perspective on that different from an engineer’s, maybe?
Then, do you have any particular thoughts on the changes in the VC capital scene, all that other sort of thing that’s around, or at least your perceptions of?
I think it depends on how well-rounded that engineer is. You’re probably going to find, I’m very much in the camp of an engineer that cares a lot about the business. I’m at a company now that shares details of how the business is doing. I think you will find some engineers who will be happy to put features out and never ever follow up on whether or not they've been adopted. I think that we here definitely have more – we’re more likely to find engineers here that care about – it’s interesting, one of the things they do is they make every engineer do every quarter is sit with the team that fields calls from our customers.
We get a ton of calls from our customers. So right away, there’s this appreciation of like: "oh yeah, this is a product that’s effecting people's lives, that out and if it’s done well it works to their benefit. If it’s done poorly, I'm screwing someone over."
You’ll often find that Y Combinator companies are very focused on this idea of spending time with a user, and this is just an extension of that. But, forcing every one of their employees spending time with a user.
As far as the whole VC piece goes, I think if you’re working on stuff – I think regardless of whether or not there’s a monetization angle to the work that you’re doing, there’s always going to be a user component that I think is inescapable. As an engineer, as a Product Manager, a Product Manager is often times thought of as being closer to the user than the engineer. If done well, the engineer and the Product Manager are both spending time with the customer. I think it benefits both equally. So yeah, that’s how I think about that.
We probably have time for maybe one, maybe two more. There’s another question lurking out there, if not I will gladly fill in.
I have eight minutes remaining on my computer.
Okay. Well that’s sounds good. So I guess then I’ll close this out with the question that is relevant to the students who are going to be going into final projects over the next week and hopefully anyone else who is listening who will eventually be going into something like final projects or diving into a smaller, medium team project.
Which is basically – if you have a bunch of junior engineers getting together to design and build a project of their own in a short period of time. Let’s just say it’s either a startup or a final project or something, something maybe from your own past – what are the things that they should be looking out for, and then what advice do you have?
Final thoughts: Discourage "scope creep!"
Keep the scope down – don’t let scope creep. You may get yourself in trouble if you try to add on a bunch of things, especially right at the end. You almost certainly are going to overlook something, and then hit a bug. I find if we hit...and this is final projects or startups, the parallels are strikingly similar. The second you introduce some feature last minute, you have almost certainly torpedoed whatever the thing is you were supposed to deliver – so keep that in mind.
Unlike a final project here, we have the luxury of pushing something. Pushing a timeline if we need to, if a surprise comes up, because surprises come up sometimes. We have full control over what the scope of the project is so you don’t find yourself working at four in the morning for two weeks straight. That will hurt.
Spoken like a man who’s earned a few grey hairs the hard way.
I couldn’t agree more on the scope side of the lesson. That's a lesson we have run into many times here, hopefully it will stick.
It’s hard, we’re creative people.
Final projects, startups, I guess the only difference in a startup you’re out of money – final project you’re out of time.
I think that takes us to the end of our road here, and I know you’re going to just disappear on us at some point, in a blaze of melting battery. Let me say one last thank you, Ray, for taking the time to hang out with us, chat with us, teach us a little bit more about that transition from engineering into successful engineering, contextually aware engineering, product-based engineering, all those fun things.
And anyone else who is here, and specifically the students who are here and everyone who is listening later, thank you guys for hanging with us. Ray, is there a way that they can get in touch with you to say thank you, Twitter or whatever, something you’re comfortable publicly sending out?
Thank you, yeah, shoot me an email – it’s firstname.lastname@example.org. I’d be happy to answer any questions.
Cool, thanks again and thanks everyone, I hope you all have a great night.