Twitter

Saturday, November 30, 2013

The role of the manager, from 1945

One of my favorite books, a 1945 edition I received from my maternal grandfather, is a book called "Up Front" by Bill Mauldin. In it, he provides a great definition of an officer, with applicability to a modern leader/manager:
The ideal officer in any army knows his business. He is firm and just...An officer is not supposed to sleep until his men are bedded down. He is not supposed to eat until he has arranged for his men to eat. He's like a prizefighter's manager. If he keeps his fighter in shape the fighter will make him successful. I respect those combat officers who feel this responsibility so strongly that many of them are killed fulfilling it.

Bill Mauldin
Up Front (1945)

Saturday, March 2, 2013

Use Evernote for GTD

While it is easy to get caught up in the endless cycle of searching for the next big productivity tool, there is much to be said for periodically re-evaluating your systems to ensure you are where you want to be. I recently did so and found "The Secret Weapon" to be an interesting approach - http://www.thesecretweapon.org/

Friday, September 7, 2012

For New Tech Leads


Mike Jansen has a great post on 8th Light that is a must read for all new project leads.  I want to add a few thoughts of my own for those just starting out on the path to leadership.  

Mike's focus is on communication and keeping with that theme I will discuss the following topics: communicating with people, getting communications from customers and bosses, communication solutions, and communicating initiative.

Communicating with People
As developers, we are generally ranked on our technical skills - our ability gives us credibility gives us authority/validity with others on the team.  As a project lead, your role is such that you cannot rely on your technical credibility alone.  Furthermore, it is not uncommon that being a technical lead does not give you titular authority (e.g. you are not a boss of the technical folks) so your ability to lead is going to be highly dependent on your soft skills.  You should invest in developing these to further your abilities.  There are any number of good communications classes that can be found online, and a great book to understand communication and negotiation is the classic "Getting to Yes: Negotiating Agreement Without Giving In" by Fisher, Ury, and Patton.

Getting Communications from Customers and Bosses
How much do you know about what your customers and bosses want?  Do you know the pressures and problems your customers have?  How about what your bosses current pain points are?  Often we are shielded from this as developers, but this is essential information for the technical leader who wants to anticipate problems and prepare for opportunities.  Do you customers want features made available faster?  If so, as a tech lead you might start advocating for Agile methods.  Is your boss under pressure to increase quality without increasing staff?  If so, the tech lead can evangelize TDD and automated testing.  Tech leads should work with their manager to get as close as possible to the communications from customers and bosses.  There is no substitution for being in the room when a customer says what why are most interested in receiving from your product and organization.

Communicating Solutions
We have all sat in the meeting where someone takes the first opportunity to raise all the risks and concerns they have with a project.  This is a classic CYA move and is not helpful to the mission - making great software.  We all understand why it happens, the desire to avoid blame, but frankly, we can do better.  Whether you are a tech lead, project manager, engineering manager, or anyone else in a leadership position (all the way up to the C-Suite), you need to bring solutions/ideas along with the problems.  It is fine to raise a concern - that is what  you should do as a leader - but a concern is just bad news.  You should include options to address the concern along with your recommendation and reasoning.  Give that to your boss, and you will enable him/her to help you most effectively.

Communicating Initiative
There is no one more interested in your career development than you.  Consider how you have learned new languages.  Did you wait until your boss said "go learn X" or do you work to keep abreast of the trends and educate yourself?  All the rock stars I know take ownership for their own technical education, and you should too as a tech lead.  Communicate with your manager and let him or her know what you want to achieve (leadership), your plans (an initial outline of what you believe you need to do in order to develop your skills), and a request for mentorship.  Your boss, if he or she is a good one, wants to help you and by making it easy, your are more likely to get the support you want.  

Treat your journey into leadership like your journey into code: educate yourself, learn from good examples, and work to keep up to date.  

Saturday, August 18, 2012

Failing to Understand Customers

Jeffrey Phillips writes an excellent piece on JC Penny's missteps.  The key observation is that your customers wants and needs matter on incremental innovation and are less a factor for something completely different (the Jobs corollary).  What matters here is how we get customer input and the level it is used within product development.  At a broad level, I separate product development into a three categories:

CategoryExampleInnovation?
Market expansionWe make hammers for the military, why don't we expand into the commercial sectorNo
Incremental InnovationWe make hammers, why don't we create a custom hammer program where users design their hammers on line and, partnering with micro manufacturers, we offer bespoke hammersYes
Radical InnovationWe created a new element stronger than any other known and whose mass varies based on the amount of electrical charge applied to the metalYes


With market expansion, one works with the potential customers to determine their wants and needs.  A very complete picture can be obtained and used to make the decision of whether or not to enter the market.  For example, users may complain that all the hammers they have to choose from seem to fail very quickly, and that they would be willing to pay more for a better hammer.  This shows a clear market opportunity for higher quality hammer (with a lifetime warranty?) at a premium price.  The customer desires are very certain and risk low, so the only question is whether or not one can make what the customer desires at a profit.  Because there is nothing very new here, it is not considered innovation.

Incremental innovation is one side of the innovation spectrum; something new is being brought to market that was never available before, so we consider it innovation.  Since the product is not radically different from what is available today, it is not difficult to present the ideas to customers and get their feedback, and use the feedback to accept, refine, or discard the idea.  However, since what is being offered is new there is risk that initial customer feedback and actual market acceptance will be different, so relying solely on customer expressed desires has risks.

Radical innovation brings to market something never seen before.  Customer needs and wants will have limited applicability since they will have no reference for this product.  Over time, as the product becomes more commonplace, needs and wants will increase in applicability.

Product creators need to match the level of customer input appropriately to the category to avoid ugly missteps

Friday, August 3, 2012

Excellent Advice - The Rapid Response Team

The Rapid Response Team

I strongly second this article based on my own experience.  When we added a team focused on issues found in deployment and had it separate from the team working on product features, our velocity in both areas increased dramatically.  We fixed problems faster and shipped features sooner than we ever had before.  If you want to have happy customers and a product that continually adds value, this is the path to follow.

Sunday, July 29, 2012

Our open hardware/software project


Along with a group of friends, we have been working on an idea that allows people to look up from the mobile screens for social connections.  The idea works around intelligent jewelry/accessories called Totems.
Totems communicate wirelessly by broadcasting an "identity" that says "I am part of this group." For example, a totem may be programmed with an identifier saying "I am part of the Cancer survivors community." When a totem hears the broadcast of a matching community, it lights up to visually indicated that someone from your group (tribe) is around. When you see another totem lighting up like yours, you know you share something in common with that person.
Totems use peer to peer fully private communications and community. Heretofore, all solutions have relied on GPS tracking and reporting back to a central server to determine who is near by that you might be interested in. This approach lacks privacy and had been regularly rejected by the market.
Because we are not an app, we break the tie to the screen and return people to the heads up world. They can see and interact with other totem owners in reality rather than the ersatz world of the app.
More info can be found at our GitHub repo - https://github.com/raygilbert/MyTribalTotem/wiki

Tuesday, June 5, 2012

Building Talent

When it comes to hiring I have always been biased toward using versatilists rather than specialists in almost all situations.  This is especially helpful in today's talent shortage.  With versatilists, it is possible to train up one's team in whatever skills are needed.   All things being equal, I would love to hire experts on whatever technology we are using, but things are usually not equal.  Experts are expensive, especially with current scarcity driving up prices.  Also, experts may not be interested in polyglot approaches where multiple systems and languages are used (e.g. UI in Javascript, web services in Java, network services in Node.js) because their value is tied to their expertise.   Asking a rock-star Java developer to code Python may be difficult because the Java developer knows his/her high value is maintained by keeping with Java.  From a cost point of view, having a Java consultant code Python would be very expensive - one is paying an expert rate for some to work/learn outside of their expertise.

Picking you top versatilists and moving them around technical domains, learning all the while, provides long term value to you and your employees.  Their value increases as they learn more and you get that value at a cost significantly less than hiring experts for each domain the employee now knows.