Posted: July 16th, 2010 | Author: Julio Hernandez-Miyares | Filed under: New York City Startup |
As I prepare to leave San Francisco to fly back east to New York City, I prepare as usual with a Grande Coffee Drip at Starbucks availing myself of the free AT&T wireless. The trip was a “success” as measured by what we set out to accomplish by coming out to San Francisco in the first place. No, not a junket masquerading as a business trip or a chance to eat at In & Out Burger which though I did, was just a benefit of me being where they are for a change. It was a way for the principals of Jittr to mix it up and truly focus and commit to the norms necessary to have a fighting chance in the exciting but fiercely competitive landscape that is the Web Startup space whichever particular domain within it one may inhabit.
- It was about long evenings bleeding into night and dawn hashing out our core value or meaning that is the reason for forming and committing to Jittr.
- It was about the timelines we see as necessary to hit to be relevant in a time perspective.
- It was about what we excise from our core product idea to be able to hit a date to as I call it , have a debutante coming out in front of the skeptical masses; masses being those in the same or similar business and their press consorts.
- It is about not freaking out with discovery of every competing site or press release of someone in a similar space getting so much Series A or B or Angel funding
- It is about nurturing our combined personal networks and coming clean and often about our ideas, what we are doing and then listening to the feedback and if warranted, factoring in some of the gems we glean.
Posted: July 8th, 2010 | Author: Julio Hernandez-Miyares | Filed under: Startup |
Building a team is a hard problem, building a good to great team even harder and throw in the idea of a good remote team and now we are talking an activity that is harder and fraught with higher risk and imbued with additional administrative issues that would normally put it out of the reach of any sane startup
Well ODesk to the rescue, sort of.
First an important but irritating caveat that though hopefully implied, I still wish to state explicitly. In my opinion, there is no tool or service out in the marketplace and non expected soon or in our lifetime that deterministically leads one to spin up an “A” like Team especially in the technology development arena. Unfortunately, most of Technology recruitment still and probably always will rely solely on the weight of different technologies you can stuff on a maximum two page resume and which will hopefully ;for the candidate that is ;game whatever keyword sniffing tool they have looking for specific stated technology experiences.
Caveat aside, Odesk is a network of individuals and an application set that provides an infrastructure for building virtual teams.
It is a company , this is no open source amalgamation of systems and people and as in most if not all “body” shop or freelance organizations, it takes a cut of the wage or rate paid to it’s members.
If you are on the demand side of the equation, the commission is well worth it as it offers
- Work Task definition and opening it up for bid from the community of Odesk Freelancers
- Validating work effort (not work product but effort. Are they working when they say they are)
- Payment in non local currencies
- invoicing and payment. The payment is via Credit Card which is perfect for a startup
- Managing Work Flow and communications within the team
The value proposition for Odesk centers around the network of potential team members scattered throughout the world with varying degrees of competency and passion that it pools for someone building a team. Additionally it provides the tooling to define your needs ie work orders, broadcast those needs to the network of Odesk connected potential, sift through the responses and work it till you find the right individual(s) to engage and then manage the assignment over time including the intricacies of payment, conflict resolution, add-on work etc.
Though the core technology architecture and development is not outsourced in this manor at Jittr, we do look to Odesk for staffing various aspects of Design, for instance crafting the various image artifacts with the standard scale and layout for iPhone and Android applications as well as test engineering on various representative handsets for the smartphone applications we develop.
I do want to take this opportunity to state a stirring in my mind that occurs as I avail Jittr of the talents of people in various roles throughout the world. The average wage rage for professional services in the Technology Development area which is a high paying area relatively speaking in all countries is abysmally low when compared to USA wage rates. I pay my cleaning person more per hour then an experienced though way remote individual Senior Software Engineer who’s local currency is in India rupees.
Furthermore, though my main focus is on software engineering talent, I am nibbling at Designers, Product people and other roles and there are a multitude of non technical types that can be engaged via Odesk.
What will be the eventual end state for various professions here in the USA with this evolving network of remote/ low cost professionals available relatively quickly? Well, hopefully it will all boil down to quality in the end.
I will update this post as the evolution of my team building and execution proceeds through the use of Odesk and comparable networks and Systems like Elance.
Posted: July 3rd, 2010 | Author: Julio Hernandez-Miyares | Filed under: New York City Startup, Technology |
I have been wanting to write my observations about the state of Technology Development in the Organization for some time now. What is that ? You ask! Well, nothing to do with actual bits and bytes. That would be too droll and in the end development groups have been writing code and growing old together with their favorite languages since the advent of the computer and will do so until we figure out how engineer a button that produces code that magically fleshes out the requirements that a customer wants,thinks he wants or is what he needs but doesn’t know it. If the scent of Pizza permeated the hallways leading to the room where the meeting was held the voluntary on-time attendance increased markedly. In other words, it is worth the cost to buy pizza to attract the team.
Open Door policy
Of course having an open door policy so that your staff can pop into your office without the administrative hassle of calendar events is a good policy in any context. What I did in partnership with the Business Owners was institute the same policy cross functionality with business owners themselves. Open Door is a cliche and it was a mindset that included going to someone’s office as well as email communications. The point was to create an environment with as few walls as possible , the optimum being no walls between the Business people and the Technologists.
It’s mostly about Trust
In many instances, the root problem in most instances of Technology and Business relationships is about trust , mostly lack thereof. Trust is hard to build , work to maintain and easy to destroy so the practices to have it permeate the relationships between groups is an never ending process. Technology development has the additional difficulty that we practice a craft that sometimes appears like Black Magic to the lay person. Though I always made it a point to vociferously make the point we are not “car mechanics”, there is a certain resonance to the Car mechanic analogy. For most folks that are not familiar with the inner workings of your typical automobile, the rite of car maintenance especially when some expensive repair has to occur always has behind it the doubt one is being taken advantage of because of their ignorance.
By the way, the photo is out of context of what I am writing about but it does mirror my state of mind at the moment. It is a sweeping view of Key Biscayne Beach down in Key Biscayne, Florida of course. They call it “Island Paradise” at least in the entrance to the Village of Key Biscayne.
No, this post will attempt to be more sociological. It’s something I have experienced directly and indirectly and though I have not dedicated myself to doing thorough research on it, based on my experience I believe it is prevalent. What it is , is the difficulty organizations have setting and managing expectations .
The direct part of my experiences are of course both as a developer and over time as a manager and executive managing larger and larger teams. The teams have been in various disciplines such as Search , Publishing , Integration Services, Video etc but in the end it doesn’t matter or change the expectation challenge one iota.
The indirect I would categorize as more then anecdotal but which I have not experienced directly. It represents those where meeting with a company , say a recruitment exercise , the depiction of the challenge for the candidate is explained.
It generally goes something like this – Our development team doesn’t engage with us like a full fledged member of one team. They rest too much on process and though they may execute on what is asked, they don’t take an proactive interest in contributing ideas or to summarize, they are not innovative.
Though this is not a good organizational state to be in and I will go into how I have solved these problems in the past, let me first say there is a glimmer of goodness in it at least for the optimist like myself. I believe strongly it directly hints at the perception which is also true that Technologists are inherently innovative and that any deviation from that behavior is viewed as a problem to be solved. Even though all human activity and roles have plenty of room for innovation, there are some roles that have a greater perceived expectation and where the mantra “just do your job exactly like I asked” is not enough.
Though there are probably as many ways to successfully solve the predicament as there are people tasked to solve the predicament I will lay out the steps I have taken in terms of consistent and simple communications to the Technical Team I recently led while at AOL. To provide a little context, at a high level , I was tasked with leading a Technology Development team supporting two business units. The teams had previously been broken apart through different management chains that we inane to say the least. Now at least the structure made sense with all the roles needed for success under one accountable executive (myself).
As I lay this out I am not sure if they will be in order of importance but here goes anyway.
- Though we are technologists with our own lingo, we need to become conversant with speaking as business people.
No, that does not mean becoming BS artists or such which most business people are not but instead concentrate on the clear, non acronym and technology laden prose. We are here to solve business problems using technology as our craft and most business problems can be clearly stated without delving into the innards of some esoteric algorithm or programming language construct.
- We are Business People first or at least as much as our Business Partners
Related to the above or actually perhaps supercedes it and should be first but anyway the point is, we have the ability and the obligation to think in business terms, like what consumer value or utility is being addressed by what we are doing? Are we doing it in a way that aligns with the time constraints of the marketplace? Yes as Technologists some of the answers to basic business questions will devolve into technical choices but that doesn’t mean we can’t think through them at a more concrete business level and one that connects us in mindset with non-Technologists.
- The Customer is always right but our business/product partners are not customers in the conventional sense.
Back in my high school and college days I made ends meet by being a New York Deli Man. Cutting deli meats for the most demanding and fickle customers known to mankind or at least to me based on my life experiences. If you wanted Baloney cut paper thin or in quarter inch chunks or put through a grinder, well that is what you got though sometimes with a snicker; try to slice 1 pound of paper thin pepperoni and see what I mean. The point is the customer got what they wanted regardless of whether that was the optimum cut and whether they enjoyed it or gave it to their pets was immaterial. The customer is always right in the Deli scenario because there is no inherent interest in the use of the product once is has been procured by the customer. That is a valid mindset for most transactions (I am stretching the point, there are many instances where the use of the product is controlled of course but I hope I made my point).
The required relationship a technology development team must possess with the rest of the organization that consumes it services is a partnership relationship , not a standard customer relationship. The technology team has to feel a vested interest in the absolute utility of what they are being asked be a part of. It’s as though I was cutting the baloney not for some anonymous customer but for myself or a Monday Night Football party I have having at my place.
- Regular formal forums with the business owners
Though I am not a fan of meetings for their own sake and God knows, neither are people who make their living writing code, bi-weekly or monthly formal open forums with the key business owner was something I instituted especially while at AOL. Admittedly if we were in a crunch I would either give a pass to the group that was under some deadline pressure or I would push the meeting to another week. These forums though allowed a discourse centered on business metrics tying it directly to the largely technical activities of the Development team. If the scent of Pizza permeated the hallways leading to the room where the meeting was held the voluntary on-time attendance increased markedly. In other words, it is worth the cost to buy pizza to attract the team.
- Open Door policy
Of course having an open door policy so that your staff can pop into your office without the administrative hassle of calendar events is a good policy in any context. What I did in partnership with the Business Owners was institute the same policy cross functionality with business owners themselves. Open Door is a cliche and it was a mindset that included going to someone’s office as well as email communications. The point was to create an environment with as few walls as possible , the optimum being no walls between the Business people and the Technologists.
- It’s all about Trust
In many instances, the root problem in most instances of Technology and Business relationships is about trust , mostly lack thereof. Trust is hard to build , work to maintain and easy to destroy so the practices to have it permeate the relationships between groups is an never ending process. Technology development has the additional difficulty that we practice a craft that sometimes appears like Black Magic to the lay person. Though I always made it a point to vociferously make the point we are not “car mechanics”, there is a certain resonance to the Car mechanic analogy. For most folks that are not familiar with the inner workings of your typical automobile, the rite of car maintenance especially when some expensive repair has to occur always has behind it the doubt one is being taken advantage of because of their ignorance.
View from the roof of the “new” New York Times Building in New York City looking towards the Bank of America NY Headquarters in the background.
Roof of New York Times Tower
Posted: July 2nd, 2010 | Author: Julio Hernandez-Miyares | Filed under: Cloud Computing |
Spent a few quality hours on Wednesday evening July 1st at a Meetup sponsored by Pivotal Labs to discuss their Tracker Project Management tool.
Quintessential New York style just off of Fifth Avenue on 27th Street in a Class B or perhaps C building that probably served as a garment manufacturing
facility back in the day when those streets were chock full of hand driven garment tracks.
Empire State Building
No, this is not quite the view from the 18th floor of their loft space as I was there to work and learn and not act as a photographer but in fact their view was better with the Chrysler Building and the rest of Gotham glistening as the sun set over the Hudson River. No office space surrounded by quadrangle seas of green in this City unless you include the very public Central Park and the other architecturally renowned parks sprinkled throughout the boroughs.
Pivotal Labs is a software company originating in San Francisco with a major outpost here in the Big Apple with a focus on providing Technical Software Engineering services to clients. Think of like an Agency but with Developers. That is not how I came to know them though. As Software Engineers, they architected and engineered for their own use an internal Project Management Tool to manage their Agile development process and eventually made it available as what I would characterize a Cloud Service. What can be better then that as a start? A project Management tool where the initial customers for the feature set were developers. Though I have no way of verifying , they did say they have to date about 100k users and they have at least one because we at Jittr use it.
What is Tracker? First don’t call it Pivotal Tracker as I did , it is just plan Tracker as the principals like to reinforce.
Well if you are conversant with Agile Story definition and management tools like Rally that provide a fundamental utility to manage and coordinate Agile Development in all it’s phases, that is what it is.
You define a story , describe it, and leave it in the “ICEBOX” which is a metaphor I find attractive. You have a planning session with the team and here a team is small (6 or at most 10) move the estimated in terms of amount of work accepted stories into the Backlog. It uses simple estimation based on either 1,2 and 3 or fibonaci sequence. The fact is they are relative measures. You don’t estimate so much like “this widget will take 23 hours” to build
This product is apt for those shops that want something powerful because of it’s simplicity and focus, cheap (we use the free version because of our current small size), and who want to be able to influence an open group of developers in furthering the efficacy of the existing product.
Who is it not for? Well, if you have money to burn and like paying license fees for the fine dinners or box row seats you may garner by signing a wide expensive perpetual site license. If you are so process driven that without integration with every conceivable project management package or if you need specificity in the estimation activity bordering on creating mirages that you can present as verifiable fact because the tool say’s so.
On the other extreme if anything more disciplined then redacted napkins with the feature descriptions or endless email threads with point -counter point to describe a feature, then the tool is not for you.
Posted: June 29th, 2010 | Author: Julio Hernandez-Miyares | Filed under: Cloud Computing |
Enhanced Web Robots will eventually enable us to
finally get to the life of learning and leisure that computers have so far failed to do. What kind of Robots or Bots as they are lovingly known are we talking about?
Well , you give a natural language command say “what are the food handling and preparation regulations in New York’s Columbia County and what forms and inspections are necessary
to get a certificate that allows me to prepare and sell on outdoor food carts..”.
This is a real life problem I am currently working the old fashioned and best manor today via Google Searches for my Cuban Cuisine Catering company I recently formed.
Thank Goodness for Google to help me find the answers to what is a problem I don’t even knew how to solve at the outset other then the fact I knew there are numerous competing agencies and regulations in the food growing, food preparation and sale business especially when dealing with perishables like dairy and meats.
Why not strive to solve this difficult problem even though it won’t be solved in a quarter or even a few years. At least these Robots won’t have to have vision and those normally physical issues that need to be
solved so I can have a robot that can be my house maid.
Posted: June 23rd, 2010 | Author: Julio Hernandez-Miyares | Filed under: Cloud Computing, Mobile, Technology, Technology Outsourcing |
As Jittr’s focus are Smartphone applications , primarily Android but eventually and soon iphone, we are caught in the dilemna of how to test on a cross section of the handset devices we are targeting.
Test Engineering is one of those technical areas that we wish to outsource to a team in a far away place where supply of engineers is high, competence equally high but costs are way low. India is one such place, though not the only one but since my principals and myself have years of experience with teams in India, that is the out-source geography we are most familiar and comfortable with.
So far so good but we are not talking about testing on an emulator running on Windows or Mac workstation. That is good for development testing. Real test engineering has to test on the actual devices running the actual variant of the Android OS possibly customized by the Wireless Carrier.
Device Anywhere to the rescue!
I just completed the live webinar on DeviceAnyWhere Test Center application. Quite impressive! As an aside, I signed up for a free open trial prior to signing up for and viewing the howTo seminars and put the product (both the Test Center and Test Automation Facility) through it’s paces but the Web based live walkthrough was still worth the hour of investment of my time. This is a profitable (or so they say) startup in Cloud Services with about 2,000 clients and their main claim to fame is making handsets available via the cloud to engineering teams that need to test their mobile applications on as well rounded set of different handsets as possible. They have multiple data centers including one in Europe, the USA of course and a new one opening in Brazil shortly. The data centers are centers where the actual physical devices are located. All testing is done on real handsets which a tester acquires via the Test Center/Automation application prior to running through the test cases.
All activity performed on the physical unit is streamed in a pixel perfect manor to the testers’ workstation which renders in an image which resembles the physical device.
Also, those pixels are captured to form a basis of screenshots that show the visual state of the device as the testing proceeds.
The Test Center also includes it’s own feature to define and manage test cases in a centralized manor. No more having to use Excel or something similar for the same purpose.
The probable use case would be for someone in Jittr, let’s assume myself for the moment, would define the testcases within the test center and then outsource the actual testing to a remote team in India. The Test Center makes this easier to accomplish. The Test Case Manager has the functionality to assign pass or fail to the test, attach screenshots of what was observed on the handset for each particular test
Another useful feature is the ability to share an acquired handset to someone to put the application through it’s paces.This feature I have not exercised yet so I am not sure if the invitee has to download the testcenter application to actually avail oneself of this feature. I find this a potentially useful way to let someone , say one of my principal none technical colleagues, someone like a Product Manager who is remote, run the current state of the application through a real device even if the real device is somewhere hidden out in the clouds. A lot simpler I hope and will confirm then having them install Eclipse and the Android development kit to have the use of an emulator to simulate the functioning of the Android Application.
Overall, appears quite impressive from my kicking the tires and the Webinars and as the world moves quickly in the mobile market, this company as well as others should form the bedrock of the way mobile testing is done except for the absolutely largest companies.
I am in the process of converting from a free trial account to a paid account. They have flexible plans for startups like Jittr where breaking the bank is not an option. I will come back to this post with information as I put it through it’s most important paces which is for real and with a virtual team using it as the foundation for test engineering.
Posted: June 4th, 2010 | Author: Julio Hernandez-Miyares | Filed under: New York City Startup, Startup |
As the title states, this is from a very specific and personal (me) perspective on some of the things I have learned , usually the hard way in the past few months as I work to boot strap my own startup.
It isn’t just me , I am doing this with a ex-colleauge from AOL and we kicked around the idea for many a late night before we (actually more myself took the gamble.
- I am accountable at 100% not just the area of primary concentration
Basic truism and one that is key as otherwise it is easy to get resentful when things don’t go quite the way you want them. As the Chief Technology Office (A highly pompous title for the person who is responsible for the technical architecture and software engineering of the product), I have to accept; and I do; accountability for all other areas of the process that go into providing utility to a user that will help establish out startup. ie Product requirements, Design aspects , monetization potentials.
- Irrespective of 100% accountability, you can’t do it all
Self explanatory but a high risk especially for those in the technology wing that are seduced into thinking that Technology acumen can solve all problems. It can’t because there is more to a business, even one with Technology at it’s core for building new Products, then the bits and bytes that give life to the product.
- “Get the right people on the bus”
I believe this is from Guy Kawasaki’s Art of the Start which a bunch of us enterprising sorts read and re-read circa 2006 when we were seriously contemplating leaving the womb of a big company and going off on our own. Like a real bus at least in the City of New York, there are plenty of stops along the route to let people on and often times more importantly let people off. Also don’t turn a blind eye to those that try to get on the bus without paying the fare either sneaking in through the rear door or by excuses they left the fare home while entering through the front.
- Move on quickly
Don’t dwell on things too long, maybe a nano-second is enough. If a path chosen (a potential partner, product idea, a development tool, etc) doesn’t pan out as originally envisioned , change direction and don’t beat yourself or them over it afterwards.
- Reconsider previous decisions based on new circumstances
Even though you want to move on quickly, it is also often true that new circumstances change the dynamics of why a path originally taken and ditched now seems like a worthwhile path to take again. Risk of waffling in this of course but it should be straightforward to recognize over time that you have fallen into a rut of zig-zagging from one path to another and back repeated ad-nauseum.
- Don’t pack it in and give up at the first , second , nth roadblock
Almost everyday (except days off) will bring up scenarios that make you question having gone out on your own instead of staying within the womb of a more established gig. It may be a subtle form of self hypnosis , but itemize and remind yourself of the points why your chosen path has benefits over the more traditional , comfy established route .
- If you can’t itemize some compelling points from above, then all likelihood you shouldn’t be out on your own
Posted: May 4th, 2010 | Author: Julio Hernandez-Miyares | Filed under: Mobile, Technology, xcode |
Xcode
This is not necessarily an Xcode versus Android post, if it were , it would be a long post. I actually use both (though am more familiar with the Android java centric model based on past experience) and I am enamored to the extent one can be enamored of integrated development frameworks of both platforms
Being a normally fickle person when it comes to these type of things, my “enamored” meter is recently leaning towards Xcode. The reason is simple. Even though my familiarity with Objective-C needs a lot of addressing vis a vis java, Xcode’s InterfaceBuilder draws me in as a convert. I am not prone to wanting to deal with layout issues of any sort. Just not in my dna. Mostly result of a lack of patience of working through the grunt level but critically important aspects of having a well tailored, crisp UI where things line up , the colors make sense and appeal to the user even on an unconscious level and the application’s interface holds together following explicitly documented and promoted style guides. Of course, InterfaceBuilder doesn’t have any magical charms that takes a poorly thought through design and make it work aesthetically. That would be asking too much. Nevertheless I can take something produced by someone expert in design for mobile devices and quickly translate it to an artifact that closely resembles what has been provided.
I feel quite at home with Android’s version of an InterfaceBuilder, defining a layout via XML
and with it’s rudimentary drag and drop of UI artifacts unto a Window canvas but I generally spend most of my time dealing directly with XML to flesh out the UI and then tinkering with the directives to make it look right. The layout view helps of course and I find myself in it often enough. Nevertheless it does not compare to the power of Xcode’s Interface Builder with it tight coupling of device style guides, frames and arrows that show how well centered visual objects are to each other and to the container itself and that visually guide you to get it just right without guess work. Additionally , connecting the visual components to the actual code objects that express the purpose and functionality of the visual components has a much more natural feel within Xcode’s InterfaceBuilder. All of the class objects are defined in header files ie *.h and then through drag and drop operations those objects can be connected with their visual counterparts including events that flow between exercising the UI artifacts and the class methods that implement the behavior.
From a personal perspective and therefore less meaningful , going for the Android development environment is my greater familiarity with java. Once becoming familiar with the pattern of typical Android development which had a relatively steep but short lived curve, becoming conversant with Intents and Pacelable and how they wire the application together, the language never got in the way. Objective-C is in the way not because of any inherent deficiencies but solely because of the less familiarity with it’s syntax then anything else. Once I become comfortable with the syntax, I expect to be more fully drawn to the Cocoa/Xcode
Posted: May 1st, 2010 | Author: Julio Hernandez-Miyares | Filed under: Cloud Computing |
What will they think up next that can be put on the “Cloud”.? Well that is tongue and cheek in in a way. Probably any software service can be adapted to form a service in the Cloud. The Cloud simply defined as something somewhere obviating me of worrying about it’s operation and the only interest and concerns are
- it’s reliability (there when I need it)
- scalability (ramps up with my needs)
- semblance of privacy controls (only those that I grant access get it).
Last week the individual writing up the product requirements for the Social Gaming Mobile app that we are working on at Jittr.com suggested we consider using Pivotal Tracker for managing requirements. Pivotal Tracker is an online tool to manage the Agile methodology with the normal adherence to Stories, Backlogs, Current Sprint Log for accepted and inflight work and the sundry reports that attempt to depict software development productivity such as Velocity ie how many story points are completed in a given sprint development cycle.
It also has an REST based API specification which I have not had the opportunity to try out that allows exercising it’s capabilities and the project information contained therein increasing the flexibility exponentially if the need to integrate with other project based tools arises.
As a very small boot strapping start-up, we are not interested in using this tool to the extent a large company with more defined processes and much larger team and reams of executive or program management who spend their lives monitoring how productive their technology development teams are operating. Nevertheless it’s core capabilities to define stories and share in a centrally accessible location and allow updates whether on the product or development perspective and all for the grand sum of $0 makes it a useful tool in our arsenal to communicate and execute quickly.
After a few weeks, will update this post not only with additional reflections on the quality and efficacy of this tool but also the extent it makes sense to use the discipline of Agile for a startup fitting the profile of Jittr.
Posted: April 25th, 2010 | Author: John | Filed under: Startup |
Earlier in our weekly call, we talked about focusing our energies. I came across this image that I had saved to inspire. 
Credit goes to Bud Caddell @ whatconsumesme.com
