It is becoming increasingly evident that companies should be establishing labs inside their entities, for exploring new deep tech independently.
The labs should have the autonomy to go far-out into futuristic new deep tech without having to worry about current limitations.
The research function should be independent and should encourage creativity.
To a large extent the labs work should not have time pressures.
Productising these research ideas would be the key to differentiating the companies offerings in this hyper-competitive space.
These labs should not be led by architects or EMs. They should be led by people who have experience in doing research, preferably PhD.
Research rigour is important.
Some companies have been doing this for a very long time – Mercedes, Airbus, Sabre etc. Ixigo Kitchen Sink is a classic example from a few years ago. I am hearing of more newer companies starting to do this – Amadeus Labs, Rivigo labs etc.
It would be refreshing to see this happening in all the unicorns. For instance, I would imagine Swiggy would benefit immensely — so much funky stuff can be done on IoT, route planning, kitchen optimization etc. Similarly Go-MMT does a lot of research along with the day-to-day work. I believe that this is not the right approach. You should separate these two out – for best optimality. Else, engineers and PMs are permanently at a conundrum to see which is more important – long term research drivers or short term revenue drivers.
Portfolios: HR sourced UI/UX candidates for me. We took on only resumes which had pointers to their portfolio (in Behance or elsewhere). If they did not have a portfolio, I did not consider them serious enough to be applying to us.
UI/UX designers vs Creative Designers: There is a fair amount of ambiguity that candidates typically play on, between UI/UX and creative designers.
My definition of a UI/UX designer is a combination of visual design and interaction design. In other words, the candidate should have designed web or app flows (or atleast part of them). These guys have the knack of leading a user through a flow. They know the importance of consistency, primary colors, templates etc.
Creative designers (per my definition) are those who focus exclusively on visual design. These are folks who are exceptional at creating marketing collateral content (such as ads, brochures, posters etc). These are guys who are awesome at designing stuff that will catch your attention. They know the contours and contrasts that will stand out. They know the colour palettes that will work better on banner ads vs print vs mobile.
While hiring for your designers, you should be able to distinguish (to a large extent) at the very beginning what kind of work that they have done, and what their strengths are. Most folks tend to sell to you that, they can do both. I am not a full believer in that yet.
Talk to the candidates: My lead designer and I used to have an intro call with every one of these candidates. You can figure out the ambiguity that I talk about (above) very easily in this call. Talk to them to get a feeling of whether they would fit in, into the culture. See if they can express themselves to you. They need not be eloquent (most aren’t) but they need to get their point across.
Sample project: Those, who pass the phone call, I had our lead designer send out a sample project to them. Depending on your timeline to hire, this can be as small as redesigning/reimagining a page on an existing app/website; to as big as redesigning a process (the payment flow for instance). We used to give adequate times for these. The smaller projects are 1-2 days, and the larger ones 3-4 days. There is a reason for this. Designers typically take time. One cannot push designers hard, like you can do to engineers. More number of hours does not equals more work, in the case of designers.
We also took a look at how these sample projects were submitted. It shows the seriousness of the candidate. There will be candidates who will submit PDFs. They will be some who will submit sketch files. And there will be some really good ones, who will give you an invision file, with sample click behavior and everything.
In-house interview: For the in-house interview, the candidate should talk to one Product Manager (PM), one front end engineer, lead designer, and the hiring manager. If all goes well, one round with the HR.
You probably guessed why the above people were chosen to interact with the candidate. Yes. These are the guys who will be working with the designer. They are the stake holders. You need to know how the designer interacts with a PM and a front end developer. These are one of the touchiest relationships.
The PM dreams of impossible stuff to design, and the front-end engineer would refuse to code it up. And the designer is stuck in the middle, typically. How assertive is the designer? How much data is being requested from the PM? Is the designer trying to understand why the front end engineer is saying, something is not possible?
The interview with the designer is typically to touch upon the technicalities. What are the tools he is familiar with? Is he an expert user? Or very novice. How well does he know his interaction design? A lot of this would have come through the sample project. Typically the lead designer (or me) would probe as to why the designer designed the sample project in a certain way. If there is any plagiarism or this was a fluke, this will come out now.
History and lessons learnt: Contrary to what everyone thinks, the designers job is a very hard one – playing to the tunes of multiple people and scenarios. They have to walk a very thin line between being creative, and delivering within time pressures ; between making a noticeable change, and preserving your style guide ; between taking up a largish revamp of a page, and making a dozen tweaks for the short term ; taking a call between what the PM thinks, the designer thinks, and the customer perceives. I typically ask the designer, what are the lessons he has learnt on the job, while being a designer, and listen. I would expect some of these above thoughts to come out. If they did not, he has been too passive a member, and has not contributed enough. I probe into some of these thoughts, and see what are the learnings that the designer has been exposed to.
Endnote: I had hired a lot of engineers in my career, but hiring designers is a totally different ball game. It is not a 0-1 decision problem. You cannot hire a designer because he knows his tools really well. Designers are creative types, and for a large fraction of them, it is hard to gauge attitude and personality. It needs time and effort to hire the best designers. But once you get them, you are set.
Disclaimers: We were a product based company. I was hiring UI/UX designers.
I half-balked at AirBnB, but it looks like it took off. On hind-sight, maybe that was a good idea. You have a couple of rooms with a separate entrance. Rather than finding a rental tenant, you could probably make more money running it as a “hotel room”.
But, CLOO takes the ‘cake’. It is a similar idea for renting your bathroom. Really? You would let a stranger come and use your bathroom? The webpage paints a picture of a harried person in the middle of the city, desperately looking for a loo. I can understand the desperation in a country like India, where it is difficult to find a clean loo in some areas (this is improving big time by the way!). But, in American cities, atleast in a few that I have been to, I have not had this ‘desperation problem’. I would either find public toilets, or find a 7-11 or a gas station, and most are half decent – atleast for a desperate run !
First off, for those who claim that management is not necessary in a technical environment — I respect your opinion, but what I am going to be writing below is not going to interest you. You might as well go to slashdot, or metafilter, or coding horror, or …. (Disclaimer: The fact that I believe that management is necessary in a technical environment does not mean I do not visit the above sites – I am still a geek at <3 .)
Managing a start-up environment is different from managing a mature software business. There are several things that work in a startup but may not work in a mature setup, and vice versa. You should notice that I have emphasized the ‘may not’. There are several companies that I know, which work in startup mode. Some of the below may work in these, if it is part of the culture of the company.
The following points are not arranged in any particular order.
Avoid meetings – have discussions: It may seem like I am just calling it by a different name. It is really not so. There are several significant differences. Some of the key differences are:
In a discussion, there is significantly more participation from the grass roots engineers, than in a meeting.
There is no agenda. There are points of discussion. The key point is here is that, meetings are over when the agenda points are done. Discussions are over, when everyone is convinced.
There is a lot of learning in a discussion. People can ask for clarifications and elaborations.There is no “lets take this discussion offline“. This is the discussion.
Action items are taken by the ‘actioners’ themselves. There is more accountability this way.
Avoid status meetings: Status can be covered either by discussions like the above ; or by just walking over to the cubicle of the developer. I sometimes write down the action items etc on the white board in the cube.
Give more freedom to developers: They are more creative this way. They are more accountable, and they feel good about it. Developers who feel good about code they develop, just are more productive.
Break stereotypes: Get wifi to the coffee room/pantry. Who says the pantry is only for relaxing. If the developers are most productive in the nights, and request for coffee/tea in the night, get it to them. Do they require dinner ordered in – order in. Do not think about, what others will think about it — or whether it has ever been implemented before. Just do it.
Isolate from management: As far as possible, you the technical manager, should be the one who oversees the development. Try and avoid as much as interference from higher management. They do a very important job of bringing business to the company. Let them do it in peace. Try and avoid them giving advise/suggestions/recommendations on what should go into the product, or how easy/difficult it is to develop something. You, the technical manager, should be the conduit between the upper management.
Reward rebels: There are programmers, and there are rebel programmers. These are the bearded ones, which get maximum work done between 11pm and 1am. Encourage through whatever-means-appropriate-means for them to align with the high level objectives of the company, and you have a winner here. Reward the rebel handsomely. One must understand that rebels do not consider money as the only reward. They can be rewarded with better machines, dual monitors, leaves-with-no-questions-asked. These things will equally excite the rebel in your team. Go on, encourage the rebel in your team, and kick-back-and-watch-the-fun.
Infuse energy: Have you ever walked into a start-up office (atleast one that is doing well, and that is managed well). Can you feel the energy. There are heated technical arguments in the hallway. There are ‘rebels’ having good over-ear headphones, listening to some loud music and bobbing their heads, as their hands furiously program. You can see people coding with feet up in the table. You can see someone who has just finished coding a module, get up, and throw up his hands in accomplishment, and drag a few of his mates for a coffee. Thats the energy. Encourage it. You, the technical manager should be part of this energy. Go and hi-five the guy who just finished the module. Participate in the hallway argument. Kick back and have a cuppa coffee with the so-called-junior-developers and share some history. You will not only be considered the cool guy. You will be the one who will be accredited for all the energy (and hence the productivity).
Small perks are valuedmore: Perks such as spending a hundred dollars on a fancy expresso machine are valued much more in a start-up. It reinforces in the workforce the confidence that management is trying to make the place as much fun and comfortable for them. Fresh cut fruits in the morning is another example. Rebel coders rarely have the time to shave, leave alone, have breakfast. They will come to work, and have fruits and coffee. Do not lay your hands on these small ticket items, when management tells you to cut discretionary spending. You can save more in economizing other things. Infact, get the dev team together, make the decision together.
Percolate field news to dev team ASAP: This is something that successful start-ups always do. Some of them do it partially, and get bombed for it. When I say partially, I mean, only bad news from field, in the form of bugs, and enhancement requests, trickle to the dev team. This is no good. Did sales bag another order – however small it is? Share it with the team, and celebrate. Hey the sales team celebrates it. And the dev team usually gets to know about this, and thinks – “dang! I created the feature, and I get nothing.” Percolate good news and bad news from the field down to dev team. You gain two things by doing this. You gain good-will from the team – the team thinks they are a part of the whole gig. And secondly, you get the dev team working more productively towards what the field and the customers require.
Celebrate every occasion: Yes, I mean every occasion. There need not be a lavish 5 course meal. Celebrate with ice-cream. Celebrate with pakoras or samosas (in the Indian context). A feature that has been under development for 6 months, just got done. Celebrate. And call the whole team for it – not just the 3 people on the project. A new customer. Celebrate. 1000th bug fixed. Celebrate. A developer fixes his 250th bug. Celebrate. Give him a uber-debugger award certificate for it ! It is not about the food, or about the time, or about what you are celebrating. It is about, getting the whole team together, and reinforcing the thought, that the team is doing something very cool, and the management recognizes it.
Practise management-by-walking-around (MBWA): I just walk around and gather status. I just go and sit on the developer’s desk, while he lounges in his chair, and explains what he has in plan for the next week. He basks in the glory of fixing his 4 bugs last week. He tells me that he will be on leave on Tuesday. What did I just do ? That was my status meeting. I walk back to my office and note down important things in the conversation. You can get a lot of work done this way – and if you notice, the developer did not get off his chair, and he got back to work, right after you buzzed off. Wow, talk about productive meetings eh ?
Aggressive targets: Set aggressive targets, but after buy-in from the developers. Push the line. Raise the bar. Tell the developer that you are raising the bar. Make him/her raise the bar. Challenge the developer.
These are some thoughts on how managing start-ups can potentially be different from managing a normal software factory. These are not rules. That is the whole point. Take these ideas. Spin them off in your context. And watch the fun unfold.
The opinions expressed in this article are solely mine, and are not of my employer, in any way.
