Hiring Mobile Engineers vs Training Engineers On Mobile
We have watched many of our large “web first” portfolio companies struggle to make the change from web first to mobile first. By now, most of them (but not all of them) have made the transition. And it is not an easy transition.
Most of them built up “mobile teams” that are made up of mobile product managers, mobile engineers, and mobile designers. These teams are tasked with designing and building mobile apps to compliment the web apps that made these companies successful. This can and does work, but it is suboptimal for a whole host of reasons.
Some of those reasons are:
1) mobile engineers, designers, and product managers are in short supply and are very expensive. on the engineering side, an iOS or Android specialist could cost as much as 1.5x to 2x what a web specialist costs.
2) the web and mobile apps are not two separate things. they are a continuum of user experience from web to mobile or mobile to web, and back. having two entirely different teams building these two applications can cause all sorts of problems.
3) many things need to be rolled out on web and mobile at the same time. localization is a good example of this. so is a new payments system.
The other approach is to train your product, engineering, and design teams in mobile so that your web specialists can become mobile specialists too. This fits nicely into the notion of a “full stack engineer” who can do it all when necessary.
Several of our “web first” portfolio companies have invested in this model with great results. This is not something that you can do overnight. It takes time. So its not a great solution for a raw startup, but there are examples of very young USV portfolio companies where one or two of the leading engineers on the team picked up iOS and Android development skills quickly and led the mobile development efforts.
The thing of it is that a great engineer can learn any new environment or any new language if you give him or her the time and place to do it. The same is true of a great designer and a great product manager.
Mobile requires new skills and new ways of thinking. Mobile is different. But it also can be learned if you make the right investment in your people and partner with the right training partners.
In a board meeting of one of our most successful “web first” companies last week, we learned that they no longer have a mobile engineering team or a mobile product team. All the engineering and product teams do mobile and web at the same time in the same team. They still have some small teams that work on mobile growth and other specific issues that are unique to mobile. But most of the product, design, and engineering work on mobile happens in the same teams that do the web work. They have fully absorbed mobile into the way they plan, design, and make things. That was a watershed moment for me and led to this post.
This all comes back to the question of hire from outside vs invest in your people. Of course you have to do both if you are growing quickly. But as Jerry Colonna told me many years ago now, the companies that invest in their people are the best companies to work for and to invest in. So when you are thinking about how to do something new, don’t always look outside for new blood. Think about getting your best people to learn some new tricks. It can work and it does work.
Was this a Memo to Disqus? Ouch”We have watched many of our large “web first” portfolio companies struggle to make the change from web first to mobile first. By now, most of them (but not all of them) have made the transition.”
That was totally fair criticism
I sense your frustration. Maybe this isn’t a case where they should use in house talent.
Hmm, my guess as an outsider is the goal is to make discussing an article on the web as fun and engaging, and as easy, as joining a SnapChat or WhatsApp conversation, or SMS on iOS.The mobile web approach hasn’t quite worked, but users are reluctant to install a one-off application for something like a commenting system. Not all of the places Disqus is used are communities like this, where notifications and other features of a mobile app would be desired. For instance, it would be nice to have a notification the second Fred posts a new blog in the morning, since the email takes up to a few hours to arrive. Think of it this way, as soon as a user opens a Disqus session with a new article id/URL I would want a notification sent to my Android device. I would want to open the article and only the article in a Readability-like view with the comments front and center below the article, already loaded and ready to go when I get through the article.But let’s go back to a typical site using Disqus, say a political discussion. As a user, I want the comment system to load quickly. I might want it bootstrapped statically in the page, possibly using S2S if this is a WordPress or other CMS installation, or rendered quickly into the page using JS otherwise. I would want the interactive elements to load on demand. I want commenting to be available to me as soon I click reply or post, not a few seconds later. I want refreshing the page to return the comments immediately and not force another round of waiting for the Disqus logo to spin.The biggest issue I’ve had on mobile has been editing comments, losing comments to an engine crash is unacceptable, forcing me to start a reply in Disqus and then copy it into another program to complete editing it. Local storage would be ideal for caching drafts locally, so that if an engine crash or Disqus crash or browser crash or whatever occurs, Disqus knows I have a draft in progress and knows the context of that draft, even if the parent comments haven’t fully loaded.Notifications would also be useful for getting alerts when a comment or thread I have directly participated in has a reply, though this would need to be fully customizable on a per-user basis. It sounds to me like the approach would be a hybrid approach, with a best of breed web application which fully integrates with the host page, isomorphic comment loading for supported backend environments with S2S calls and timestamp based caching of rendered comments in Disqus or it’s CDN, and a small native application which adds progressive enhancement and engagement/notification features for those users that want them.In any case, there are many website commenting systems out there, some with very large properties, but none have been able to capture the market. I believe Disqus is in the best place to do so.
Thanks for your well-thought out comment
This post reminded me of the previous one about Sunken Costs. Programmers/Designers have the same problem as companies, they have invested a lot of their time and effort in some technologies, so how can she throw it all away?This is one of the situations where I can see the full circle about why companies are all about their people. People who can swallow their pride and learn something new, cooperate and trust others to make things bigger than a single person.Consequence: 10/10 of the last received work resume have been discarded searching to fill a new position.
no, but it could be
I have also seen the opposite be true. Companies that are very mobile centric (by birth), that have not taken their mobile strengths into the web and real world. In order to grow mobile, you also need to get to those users that aren’t (yet) on mobile.That continuum is made of 3, not 2 parts:Mobile — Web — Real World
There is a population that is not on mobile?
My point is – they may not know about your App. (I’m thinking user acquisition and branding). The Real World is about touching people outside of the web and mobile, so you can draw them to your brand.
Not sure if that was tongue-in-cheek, but if not, the answer is definitely: Yes. Get away from urban or collegiate areas and you have lots of people who prefer to make contact via desktop or tablet (I don’t really like to call tablets “mobile” as there’s a different experience than that from a smartphone).To expand a little, for example, I’m a mostly-web consumer, yet I buy nothing (literally nothing) via phone. My wife buys a lot of stuff from Lucy and Lululemon, Athleta, etc. online. She finds it via tablet and then purchase is made via desktop or laptop because most sites suck on tablets (or the site may be fine, but tablets suck for some kinds of input). Her best friend, her sister, our daughter, my mom, etc. are the same. Browse by tablet, buy by desktop. And phones are for “emergency” web searches or while running around.I’m not saying this is all of the market, or even most of it, just that it’s part of it.(edit: typo and dropped word)
And phones are for “emergency” web searches or while running around.By this ^ I meant with regard to typical website interaction. Not to exclude the usefulness of a smartphone for many other tasks while on the go. E.g. I use my iPhone all day, every day, but never access my bank accounts via phone (which I do via desktop at least daily), never purchase anything other than an occasional App via the App store, etc. I use the phone to access web resources, but typically end up accessing those things via desktop later. I have several friends within my circle, in tech and out, who operate about the same.So in fairness, these people I mention are “on mobile”, but not for much of their transactional usage.
Agree. Also the elephant in said room is that older people (generally past 40) have a harder time seeing things on mobile and assumes they are always carrying around and have reading glasses that are accessible. Also the fat finger problem. Separately anyone who is a good touch typist (I don’t mean fast hunt and peck) will see an immediate efficiency drop by being confined to a small screen. Unless there is some advantage to using it (which there are for sure but this idea that everything is better with “parkay” is simply not true.)https://www.youtube.com/wat…For me at least mobile is a good inbound notifier or outbound notifier. “Your table is ready”, “Please confirm your haircut appointment”I personally don’t even answer emails by mobile.
Your examples are spot on for a growing demographic, i.e. 40+ year old users using smartphones more and more, but using them in very limited ways still. My mother (nearing 80 yrs) has an iPhone and uses it for texting her grandkids and such, but definitely returns to her laptop for other engagement.My iPhone is a fixed apendage, but I still curse it for most types of input. I do reply to emails via phone if on the move (or relaxing on the patio with an adult beverage ;), but replies are typically terse and often followed up with a later “real reply”.And, yes, I am a touch typist, so do not like small or software-based keyboards (as on a tablet).
Makes me wonder if there will eventually be a “hologram web” that relegates the distinction irrelevant
Fred, what companies can you name that have done a great job bridging the mobile-web or web-mobile continuum (both inside & outside the USV portfolio). I think a list of examples would be useful for all.
http://www.mobilemakers.co/… to get rookies. I think this extends far past engineering. Mobile marketing is a lot different than traditional web marketing too. Where the app lives on the phone, does the user update it-or do they use an old version? How you keep it top of mind so people use it consistently is different too.
Yep. Winning is about winning a race, not just driving a car.
As ever some great points. Having the same team do both mobile and web creates a seamless experience when the changing consumer behavior demands an omni-channel experience and this cannot be done by operating in siloes. The conclusion is something I really liked the investment philosophy of “investing in companies that invest in people”. I had written a counter to one of the former HR of Netflix on HBR where I stood for investing in people for the future instead of letting them go as soon as you grow and your needs of skills change.https://media.licdn.com/med…
My takeaway: it’s even more important than ever to hire extremelely talented and versatile developers, in addition to the culture fit.
Yes, and the more challenges that you give your developers, such as learning mobile languages, the happier they will be.
Mobile design is very challenging for designers, even for designers with digital background. I work with designers and these are struggles I see daily:- Designers still think they are doing graphic design and not UI design. – They have a hard time wrapping their head around designing for human interactions vs a computer mouse.- They have a hard time understanding mobile web vs web.They have a hard time understanding the mobile web vs mobile app ui, specially when it comes to dealing with multiple screen resolutions. -They think that because it displays okay on mobile, that makes it a mobile design. – They have a hard time understanding modularity and responsive. – They do not preview their designs on a mobile screen enough during the design process. – They do not work close enough with developers to streamline processes. – They have a hard time understanding graceful degradations, specially when it comes to not having to rely on desktop specific interactions like mouse over.- When dealing with element sizes, specially buttons and type sizes, most designers struggle to understand the implications of 1x vs 2x screen pixel density.- Designers do not work close enough with copywriters to streamline content or make it mobile friendly… particularly when it comes to the use of progressive enhancement., same for media: mobile phones are often loading assets that are optimized for desktop screen and not for mobile which not only drives people crazy but consumes unnecessary resources.The list goes on.
This is a super list. My background is print design and then web. Now doing mobile I still make every a lot of these mistakes about 5 times a day.My only quibble is the first point about graphic design and UI design. The mobile pendulum has swung way to far to the latter camp and the vast majority of mobile apps have zero soul (look at Material Design for instance – ugh – so boring). Maybe design has to be that way on mobile to be effective and reduce cognitive load, but damn it’s boring and uninspired.
What methodology do you follow?
This comment suggests that a winning mobile development strategy may be to hire a mobile designer/UX ninja to work with existing designers and developers in order to cut down on the learning curve and create a better product.
Indeed, If I were hiring in a startup with limited moneys, someone with more inclination to the UX side vs the UI side of design is the way to go…(Also, depends on the product ) but then, I would remove these labels and get everyone to wear each other’s hats.. best way to get everyone better at what they are best at.
Agree with this. If you nail UX then UI is doing its job. UX, i.e. User Experience is priority one. UI is an important part of the experience, but hardly first.
The better approach would be to train an existing emp who becomes the internal switchover lead for the company.
Sounds like your designers need to skew more UX than they currently do.
Where you worked and I currently work, Visual Designers tend to be Visual Designers and Experience Designers tend to be Experience designers.A disservice the agency model is doing IMO.
I think the workflow between visual designers and UX designers doesn’t help much.I think UX designers need to be better at designing to spec. UX designers leave out details, and almost never attempt pixel perfection. So when the visual designer needs to style everything, she also often has to rejigger the whole layout because the wireframes we only 50% there.But visual designers need to be better at UX thinking. If you’re going to break the wireframes, you need to know how and why you’re making decisions.Its all a big mess, and probably always will be. At design agencies and tech companies, alike.It all comes down to getting the right mix of people who know how to work with each other. Looking for a broad solution for team or workflow structure beyond that is probably a good, ideal thing to do, but probably won’t be too fruitful.
Agree on getting the right mix of people. Last year we billed a 500k design exercise with only 3 designers (a jr. visual, and xd senior and myself) in 6 weeks, and we over-delivered by 5 times. Entire new XD system, multiple on-boarding flows and and entirely new visual design language.I disagree on the first part mainly because it implies that the UI designer’s job begins when the UX designer’s end… In my floor things do not work like that.
I don’t think one needs to come before the other. Everyone has stuff to do that doesn’t involve waiting for other people.An interior designer can source many furnishings before there’s even a house to put them in. Similarly, establishing the look and feel of an app or site doesn’t depend on the wireframes being done.Though all that is dictated by who’s in charge. I was on teams at R/GA where the visual lead wouldn’t allow anyone to work on a project until wireframes were finalized. I worked on other projects where the UX people were almost entirely ignored. It’s all team by team, leader by leader.
Brandon, how common is it for talented people at firms like R/GA (or equivalent) to band together and form a new company as a competitor? How long is the non compete that prevents someone (I assume) from going after clients?
Common.In agencies, you don’t really sign non-competes. Its culturally ingrained in the system for people to jump agencies a lot. But you do sign over rights to any intellectual property you com up with while at the agency, whether its for a client or not, so that can get folks into trouble sometimes.It goes in waves, too. About 2 years ago, I felt like there was a new agency helmed by ex-[insert good agency] people popping up each week. Its been more quiet recently.
and we over-delivered by 5 timesHow was it measured that you “over-delivered by 5 times”?Separately, with creative pursuits, as a generality, less time works to your advantage I have found not disadvantage. The deadline and pressure ads to creativity.$500k sounds like a “what the market will bear” price. Seems to work out to about $700 per hour “worked”. (40*6*3). How much time was originally budgeted to complete the project? Also what is the value of anyone (other than sales) that is needed to complete a project like this?
There was an ask of a clear set of deliverables. As the project progressed and we defined user journeys to cover bases we ended up producing more work than originally plannedbecause the original ask was poorly defined.The six weeks was only the design phase, there was a discovery and strategy phase prior to the design phases. Strategists, Producers and Technology people were heavily involved in the early stages and then more intermittently during the design phase. No sales people, this was for an existing client. There were also other expenses, we conducted surveys, bought gadgets, flights to client presentations etc…
There were also other expenses, we conducted surveys, bought gadgets, flights to client presentations etc…I’m curious how much of this type of thing is actually “prove we have value theater”?  Not saying that it doesn’t have value but one of the ways you can create a moat around what you do and barrier to entry is by making it seem way more involved and difficult than it really is.Plus it seems that if so many people are involved you end up with a camel by committee? (Not a statement a question..) To many cooks? From the “journal of real life examples” I present this example. In high school my girlfriend’s father owned a small HVAC company. One day I went with him on a service call to a restaurant where the A/C wasn’t working. When we got there it was a simple switch that needed to be thrown. What he did though was pull out the ladder and actually spend time poking around a bit. Of course the employees were clueless. Afterwords he told me “No way I can bill them if I only walk in for a minute and solve the problem”. Had to make it appear to involved “work”. Not saying R/GA does this (I have no clue) but I do know that companies (other than the example provided) do this.
For this particular project, it was helpful. This was actually a lean engagement in terms of amount of people involved compared to most projects.And on the last point. I hear you but part of the reason we over delivered is because we make point to do stuff right. When we get an ask, we tend to re-write it to make sure we do not deliver half baked products.
There is an old parable that a lawyer (who was a client of mine when I did IT consulting in high school) told me one time that goes something like this:The huge printing presses of a major Chicago newspaper began malfunctioning on the Saturday before Christmas, putting all the revenue for advertising that was to appear in the Sunday paper in jeopardy. None of the technicians could track down the problem. Finally, a frantic call was made to the retired printer who had worked with these presses for over 40 years. “We’ll pay anything; just come in and fix them,” he was told.When he arrived, he walked around for a few minutes, surveying the presses; then he approached one of the control panels and opened it. He removed a dime from his pocket, turned a screw 1/4 of a turn, and said, “The presses will now work correctly.” After being profusely thanked, he was told to submit a bill for his work.The bill arrived a few days later, for $10,000.00! Not wanting to pay such a huge amount for so little work, the printer was told to please itemize his charges, with the hope that he would reduce the amount once he had to identify his services. The revised bill arrived: $1.00 for turning the screw; $9,999.00 for knowing which screw to turn.
I will add to that excellent story this (by the way I’ve gotten printing presses to work back in the day and yes sometimes a rubber band will do the trick when a spring is missing), this:When given an opportunity such as “we will pay anything just bill us” always quote a price. As your example shows anyone can, after the fact, state “I didn’t know it would be that much.”. And they will. Otoh if you state “I will come in and fix this for $x thousand you have set expectations and sold someone based on value not on time, materials or being reasonable. They can then decide if they want to proceed. And if they are truly desperate they will (if you want for whatever reason to take “advantage” of them). I don’t feel sorry for the newspaper at all. We are talking about getting someone out of a jam has nothing to do with what is fair or not (assuming it’s a one off thing that is). Most likely if the guy had come to the plant and someone else fixed it they would have told him to go pound sand. (Assumes they don’t think they will ever need him).Best thing would be for the newspaper to offer the money rather than give the printer the chance to set the price. Failure of negotiation (in this particular example).
I’ve come across that story and other variations of it. Good one, and a lot of truth to it. In fact just recently I tweeted something on the same lines, about Picasso and a woman who asked him to do a portrait of her:https://mobile.twitter.com/…This one by Red Adair is also good, I had posted it on AVC some time ago:http://www.brainyquote.com/…
collaboration is the secret sauce
Again that’s a problem caused by management not the developers. Doesn’t your process feed back indicate that?
You are saying the same thing I am saying. I never implied this was a problem caused by developers.
OK.It amazes me how many problems there are today in these lean started companies that turned software devs into company leaders!,It’s as if the companies are nothing more than a software project team. There hasn’t been a company built at all. Most don’t know their core offering. They just think software development and nothing more. It’s not all companies but so many that it a real problem.
Sounds like the company hasn’t been restructured properly by management.
R/GA is one of the best agencies that exists.http://adage.com/article/sp…I think the bigger point is that every organization gets it wrong, and it really comes down to individual people and teams.Marissa Meyer was hated by a lot of smart people at Google. Many said she “didn’t get it” from a process perspective, A/B testing slight tints in colors and whatnot. But she got results.If the immediate team gets the work done, and they do it well, by whatever processes they choose, the rest doesn’t really matter.
“If the immediate team gets the work done, and they do it well, by whatever processes they choose, the rest doesn’t really matter.”.That’s not true if you’re trying to build a strong sustainable company. Processes and procedures are what makes a company. Not cowboy emps. Cowboys/girls come and go and I’m all for helping ensure they can get other work. But you build a strong company by making sure that no one person or one team can destroy it by leaving. You do that not by making the people center stage. You do that by making the entity center stage..All this stuff is soon to come crashing down and you’ll see that the companies left standing were built strong not flashy.
I said nothing about cowboys. Letting a team work the way it wants has nothing to do with letting people go rogue, nor does it weaken a company.You might have a team of a visual designer with a UX eye and front end dev. You could have another team of two developers, both with good design chops. These teams will get to the end result differently. If they’re both good teams who’ve historically done good work, it would behoove their manager to let them do their separate thing.Letting teams work differently doesn’t affect the strength of the company, either. If you have 10 teams and lose 1, you still have 9 left. Nothing will crash, unless the other 9 teams are worthless; it has less to do with the workflow of an individual team, and more to do with distribution of projects and good people across the company.I believe that a company should have a strong point of view of how it does things, but I also believe it should be dictated in best practices, not mandates. You have to work with what you have, and when that comes to managing people, you have to be flexible enough to make sure the ones you have can think, collaborate and execute in a way that suits how their individual brain works.Its inflexibility that brings things crashing down. Its the ability to adapt that creates strength.
I’m gonna’ have to disagree with you. And even though we’re kinda’ far apart I think you’ll see what I’m saying given some comments..In this, the knowledge worker age, I am aware it is important to provide people a situation that affords them the ability to perform. While I am also aware that some members of the organization are gate keepers, connectors, etc. Most of the organization is labor or labor management. Software devs are labor. Labor comes and goes. An organization that doesn’t dictate to labor is a very weak organization. Labor knows that. Laborers want to be hired at organizations that have things working smoothly and effectively. They look at it as job security..Then you have leadership. Leadership dictates to management and management dictates to labor management. Leadership must have *thinking room*. They must be free to be creative by their own initiative as long as they understand the company vision..Labor is not suppose to dictate anything to anyone… ever! Labor is suppose to work in predefined boundaries using predefined methods, processes, and procedures. That doesn’t mean labor won’t ever make decisions. But it means they will make almost all decisions within the boundaries set forth by management..In the knowledge worker labor age boundaries are defined differently than the industrial labor age. That’s because knowledge work entails a creative process. But to be a strong company you still MUST have the methods, processes, and procedures all documented and managed properly so that you can improve your product quality and profit margins to the maximum..If you are a start up you will be a *disorganization*. That’s a small team of people who are learning the business model and the methods, processes, and procedures that will create a strong company. The company is weak by circumstance..A company is an entity all it’s own. It can be fined. It can be sold. It can live on past it’s founders existence. It can be dissolved. If it is dissolved the people in it aren’t dissolved. This means the entity cannot be dependent on any particular person or person’s to exist. It must be able to accept new team members and it must be able to make those new members perform in a way that fits that particular organization. This is a difficult level of proficiency to attain but it must be the goal. If the company is bringing in labor the company has a bigger responsibility of making that person perform. If the company is bringing in leadership then the company will looking for that person to bring more to the company..Every time a person comes and goes at an organization the goal is that *the organization* NOT the person is in a better position after the time spent together..What you are describing is a situation where a company has multiple *methodologies* (set of methods, processes, and procedures) that various teams follow. To address your comments. You need to look at each team as an “organization” that follows a certain methodology. Each person on each team may have skills that overlap among methodologies. But when working on a particular team they MUST follow the methodology that team is using or else it will be a dysfunctional team!.There will also be team management that will document and through the use of feedback improve the methodology for future use. This is the only way for an organization to mature and become strong..Lets address creativity. Creativity is not brought about through strict boundaries! The definition of being creative is doing and creating new things. An organization can support creativity but does so not by making the whole organization disorganized. Instead it does so by providing an environment *within* the organization that purposefully adjusts the boundaries. But boundaries still exist.
Rick could you give specific on the procedure and process? Thanks
The processes and procedures are different for every organization and are defined by the organization. That is part of what makes an organization unique.
And user engagement flows may be different in mobile than on the web.
Those are all failings on the part of the company NOT the engineers. How many hours learning has the company provided? Have you updated your style manuals? Have your design process documents been updated? Have your in-house common libraries been updated? Has your company reworked the teams to more closely match the new processes?
Agree 100% Anonymous Rick, I never implied these failings are a result of engineers however.That could not be farer from what I meant to say.I was simply listing observations of behaviors I have observed, I did not go as far as saying what caused these behaviors, please read the comment. The cause of these behaviors is rather the big gap between what designers learn in schools vs the reality of the mobile landscape and/or what designers are used to do when it comes to designing for the web vs mobile.Again, NOTHING to do with engineers.
A person educated only in a school is not educated at all..There are way more competent mobile devs than are needed. Companies just can’t seem to get competent management. I think it comes from this lean do it all yourself bad habits that have been learned during the past decade or so..It’s easy to do things yourself. Being a leader and laying out the processes and procedures that make a company effective and performing is much more difficult!
That list is pretty good to start with – great post.
Thanks James, I thought of a handful more… perhaps will write a blog post and expand on them a bit…
I think the cure for “graphic design” is make designers do wireframes and prototypes before the look-and-feel even enters into the picture, You also have to make sure that part of design process involves looking at the target devices, even if this means scanning white board drawings. Also a designer doesn’t need to be an engineer to make a prototype in Keynote or any of the other tools out there.
Hi Amin, thanks for the excellent comment! One question – I’ve only ever heard about progressive enhancement and graceful degradations talked about for websites/apps. Is there a similar thing on iOS or android apps?
I love your list. Actually I think it proves the point. You can’t just throw people at it you have to work at each and every one of these items.That doesn’t mean don’t retrain and grow people it means just the opposite.The first point on my list of five things a CEO does:1. Find and keep the best people.2. Orchastrate departments so one doesn’t drown out the other3. Make people do the hard stuff4. Visit and understand customers5. Set the strategy which is more importantly what you don’t do.Each point has a corollary Point 1:Employer needs to:1. Provide a good work atmosphere2. Allow and help the employee to grow.Employee needs to:1. Provide best effort2. Work with other employees
Totally agree. This has hit us on a couple of important projects over the last couple years where CEOs thought they’d save money by training web guys to be mobile designers – did NOT work.
the web and mobile apps are not two separate thingsThey can be, but they shouldn’t be.
My company will be in exactly this position in just a short number of months with our website Jivial.com. This advice, coming from someone whose opinion I deeply respect, may have just saved us a lot of frustration and a lot of money. What Fred has written here is a real “pay attention” post. Many thanks. Keep the great posts coming!
I’d argue that mobile first starts at the top. It’s very hard for people who have thought about building a web first business to suddenly start thinking mobile first. It’s an entire organizational change.
“2) the web and mobile apps are not two separate things. they are a continuum of user experience from web to mobile or mobile to web, and back. having two entirely different teams building these two applications can cause all sorts of problems.”Spot on. Which is why thinking mobile-first or web-first or anything like that is dubious in the first place.This is also why neglecting to put design first will bite you in the ass every time.A good** UX designer should be channel agnostic, and should able to map out an experience no matter if it lives on mobile, the desktop, on a TV, in a physical store, or crosses through all of them. To make sense of all this, this person outputs blueprints, aka designs, for others to follow. This is where the workflow needs to start.From there, you need developers that are specialists. In the same way you wouldn’t have a plumber do your masonry, you need different building blocks and builders for mobile vs. web vs. whatever.This is also why you can’t start with building; this is why you need to start with design instead. If you don’t start with the blueprints, your contractors don’t understand how each room of the house relates to the next, and you might get a bathroom whose plumbing connects to an attic and then you have problems.** Unfortunately, there are a lot of bad designers out there who can’t make good blueprints. There are also a lot of good developers out there who approach projects with design thinking. This makes it hard to hire and staff projects because you never know what you’re working with.But the system is the system. Blueprints first, build second.
Nicely said. I’ve been reading Olia Lialina’s work on this, especially where she talks about experience design and how we need to be careful about hiding the relationship between the interface and the user —> http://contemporary-home-co…
I feel the language here is wrong. “Mobile first”, “Web first”. It should be USER first. And from that one sees the entire product as a “whole” regardless of point of entry or device used. Today, the experience must be elegant via mobile, tablet, web (i.e. desktop) or any other method of contact.This supports much of the premise of the post as well.
“mobile engineers, designers, and product managers are in short supply”.Can you post some of your portfolio companies that are hiring? Don’t post jobs ads from recruiters that are phishing for resumes! I see lots of people looking for work in tech saying they can’t find work. So I always ask the people who say there are jobs available to prove it with some leads..I used to think those job seekers were just whiners but I followed up myself on some job postings to be sure. I have 20 years experience in IT with 15 years in software development. All I got for my efforts were mostly people phishing for resumes..Good software engineers don’t need training to take on new mobile development skills. It was an easy task for me and I wasn’t even that interested in mobile. You can simply have someone with mobile skills that already works at the company do some short 1 hour classes each week for the other emps..I used to teach computer science classes and after someone knows the basic looping, branching and other constructs to a language it’s really just a matter of learning whats available in the common libraries of any platform.
Conveniently USV has a job section on its website:http://www.usv.com/jobs
Are there jobs in mobile listed?
Agree, can confirm it’s become much harder for developers to find a job, here in London at least.
I think that companies should train their current employees. At my old job, when we wrote iOS from scratch after being on Android only for about 2 years, the iOS team was given time to learn. Swift came out during that time, and it kinda changed things, but the basic idea that you can teach your devs to use other languages and other platforms is solid. They know your product well, and they can do a better job than someone off the street.Even then, it wouldn’t hurt companies to sponsor good applicants who don’t have the right skillset through one of the bootcamps and give them a job after. 8-12 weeks later, you’ve got the right talent.
Right. Application domain experience is more valuable. It’s better to keep that around and train on whatever new gadgets have come along this year. Most of the time the newest stuff isn’t even needed by the devs. They just apply age old techniques anyway..It’s typical of companies to put youngsters on the hiring lines. They don’t have decades of experience seeing how a company can waste time and money chasing the newest of the new. So they spend big hiring what they *think* the company needs instead of analyzing what the company *actually* needs.
when I worked at a large investment bank, our team built the very first iPad app for that bank. We could have easily outsourced the work but chose to do it in house, and it worked out great; our team worked tremendously hard on it and we had a rock solid release and we were all super, super proud of it.I’m glad Fred is highlighting the fact that a good engineer can (and does) adapt and use any technology. We all picked up iOS and objective-c very quickly, and none of us were special, just motivated and excited to take on a new challenge.Organizationally, this is something we’ve consciously built into the culture of our startup. I think having specialties and preferences is great, but slicing teams by technology and what part of the stack someone works on is suboptimal, in my experience, both at large and small organizations.
Will, me and all my dev friends are right there with you. We love react for the Web, and react-native is crazy promising. Can’t wait to build something with it!
As a developer that does both web and native iOS I can vouch that they are definitely different types of development in many ways. I feel like I needed to build 4-5 decent sized apps, be they prototypes or actual releases, before I had a really good feel for how apps should be designed and coded properly. Besides the different style of coding, a developer will also have to learn the quirks of the Objective-C/Swift languages along with the numerous bugs and oddities with XCode, the device simulators, testing tools, core data, etc. A good experienced developer should be able to dive in and build something workable with a few months of practice but it takes longer to learn how to design really elegant apps.
Great Post.In my experience, either approach can work, but it also depends a lot on culture of the team, nature of the user experience being created and existing skill levels.Mobile is special with different design considerations. And having people who have been there, done that and learnt from making mistakes is incredibly valuable.The two roles that make / break are:1.End-to-End Experience Designer : Owning the entire user experience and workflow2. Full Stack Architect: Owning the front-to-back solution architecture. Individual components get farmed out to specialized teams but this person holds it together.
Agree that of course mobile can be learned, especially by great engineers. At the same time, the ramp-up is usually much longer than people expect, especially to get to a level of real proficiency. There are a lot of false peaks, especially with iPhone development.
In most situations I’ve worked in you’ll hire external experts with knowledge in the area you’re wanting to move into (either permanently or on contract) to supplement your existing web/db/application dev resources. Have the teams work together on features/apps when possible or do a code review/peer review to ensure your internal resources are getting up to speed. I agree that good developers can learn other platforms and languages but learning the best practices and nuances happens much faster when you’re working alongside someone who’s done it before.I agree with the reason’s listed in Fred’s post but I would also add a 4th, especially for legacy organizations. Start-ups have the luxury of beginning from scratch and using the latest and greatest technologies but established companies often have to deal with bolting a mobile site or application onto existing processes and systems. These systems (billing, CRM, marketing, APIs, tracking, testing, etc) come with a lot of technical debt and complexity that the current team has deep knowledge about. You can’t just say, “screw that old billing system you’ve been using since the 90’s, I’m going to implement in-app purchases that don’t integrate and you’ll just have to deal with it!”
learning never ends
Silos don’t work. They never did. All they ever did was segment a hollistic understanding of a project or created ‘who’s idea wins?’ type of scenarios and an awful power hierarchy. Result: failed or at best mediocre results.What’s true for developers and designers is true for every professions these days. Learn more, be more diverse. I have been amazed for years by companies, who on the one hand claim innovation and on the other hand want people, who have done the same thing for 10 years. That is so off reality. Things change a lot and I rather have someone, who has dabbled in other areas, meaning, if something unforeseen happens, that person won’t be out of their depth and it is a more valuable resource for my business in the long run.I now consult and help companies breakd down those silos and ‘glue’ them back together in a more collaborative way.
Who are you ringing make the best training partners?
I totally agree with a blended approach. We’re in the process of going from a web first company to mobile on par with web. Not everything that can be done on mobile makes sense on web and vice versa. So any functionality that needs to be on both needs to be designed for both from the beginning. Getting all of the stakeholders to wrap their heads around this idea has made me want to bang my head against the wall many times. But it still beats having a finished web product that doesn’t make any sense for mobile, and then having to go back and redo webOn the tech side, we’re lucky enough to have devs and designers who can do both
Me: iOS app developer since 2010.I wouldn’t be surprised if someone already mentioned the points I’ll make, but here is why I think the top three reasons to train web developers are invalid:1) Yeah, they are more costly, and for a good reason. The startups I’ve seen that wanted to move from web to mobile have already validated their idea and need better reach and retention. You can’t do that with a half baked mobile app written by inexperienced web developers.2) They **are** two separate things. The native app that doesn’t distinguish itself from the mobile app is a waste of time and energy.3) Sure, localization, payment systems, and even promotions are usually rolled out simultaneously, that doesn’t mean the whole app is gonna be the same. The app review process on iOS, for example, needs special attention and planning, otherwise you’ll miss your target promotion date. Other app functionality are also mobile exclusive, as I mentioned in the previous point.
So basically, hire great engineers. Period.Then train them and give them space to learn Mobile, and have them leave your company for 1.5x or 2x salary.Shortage of engineers is a much bigger problem, it might not be entirely dependant on what a single company can do.