domingo, diciembre 03, 2017

Como Mantener al Equipo Técnico Motivado

Les dejo unas partes de un artículo de Marty Cagan del SVPG (recomiendo que lo lean todo) como hacer para que todo el equipo motivado:
1. Provide engineers business context
Your engineers need to understand the business context.  So many CEO’s and product managers think they need to shelter their engineers from the ugly details and angry customers.  Nothing could be further from the truth.  These are the people that will save you.  But they need the context.  So share with them the vision, strategy, analytics, business goals, contractual requirements, and legal issues.  Anything that might impact the product.  They can handle it, and they will appreciate it.
2. Connect engineers with customer pain
The magic so often happens when the actual engineers are able to witness the customer pain first hand.  Very little is actually more motivating to an engineer.  They truly want to help fix that pain.  Again, you’re not there to ask the customer what they want built.  But rather, observe them using (or trying to use) your new prototypes or your current product, or whatever they are using today.  Your goal is to understand if the customer can figure out how to do what they need to, and if they love this solution enough to buy it (or more likely, all the reasons they might not buy it).
3. Understand constraints vs. requirements
Lots of people in the company as well as your customers will try to “help” by providing the engineers “requirements.”  This is not helpful.  Requirements are rarely truly required.  Rather, the job of the product manager is to identify the underlying constraints – legal, financial, sales, marketing, manufacturing, etc. – and then providing the engineers with these constraints.  The result is significantly more degrees of freedom for the engineering team in solving the underlying customer or business problem.
4. Give engineers time in discovery
So many teams are essentially running like a little software factory.  Product manager loads up a product backlog and the engineers constantly strive for improved velocity in implementing that backlog.  It’s beyond the scope of this article to talk about all the reason this is not how good product companies work, but it is key to realize that you must give your engineers some time to prototype solutions and test them with actual customers before deciding to spend the time and money to build an actual product.  Giving engineers some time in discovery is easily one of the best ROI things you can do.  Most experienced engineers will tell you that a few hours including them up front can save weeks and month of waste later in the cycle.
5. Measure product team as a whole
Some teams make the big mistake of measuring engineers by one yardstick and product managers by another.  This shows up as a common problem with OKR’s, where the engineers have one set of quarterly objectives and key results, and the product managers another.  This is exactly the wrong approach for product teams.  The team needs to be exactly aligned in terms of their work.
6. Competent and confident product managers
Finally, everything here depends on providing the engineers with a competent, technology and business savvy product manager or co-founder.  The product manager brings deep knowledge of the customer, deep knowledge of the data, deep knowledge of the industry and deep knowledge of the many aspects of your company that impact the product – sales, marketing, legal, finance and more. The product manager also needs to have the confidence to be collaborative with their engineers.  Strong product managers actively engage and seek out the opinions of the engineers versus feeling like they have to know everything.  So many teams don’t get the value out of their engineers because they don’t provide the team with a capable product manager.  Just note that if you think the product manager is someone with a product owner certification, you almost certainly have this problem.
Now it’s important to acknowledge that not all engineers are interested in engaging at the level I’m describing, although it is fairly common that this level of engagement is necessary to achieve the level of a tech lead.  That’s fine.  But you do need at least one engineer on every product team that is willing and able to engage at this level.  And I will also admit that my favorite product teams are those where every engineer is this engaged, but that requires a culture where this is highly valued and specifically recruited for.  It’s the best example of a team of missionaries.
So if you are not seeing the level of innovation your business needs, I hope you’ll give this way of working a try and see for yourself what a team of missionaries can accomplish.

domingo, noviembre 12, 2017

Project Postmortem Survey

Antes de la reunión Postmortem de un proyecto, sin importar que actividad se lleve a caso en la misma, una buena práctica es enviar a todos los participantes las siguientes preguntas (en un Google Form o cualquier otra herramienta) para ir recolectando información y lograr que los participantes vayan pensando de lo que pasó en el proyecto:

  • What do you think went well on the project?
  • What was the single most frustrating part of the project?
  • How would you do things differently next time to avoid these frustrations?
  • Were the goals of the project clear to you?
  • Were you given the adequate resources to achieve those goals?
  • Was the schedule realistic for the deliverables?
  • Are you proud of the project deliverables?
  • What was the most gratifying or professionally satisfying part of the project?
  • If you could change anything from the project, what would you change?
  • Was project communication handled efficiently and effectively?

No olvidar recordar la retrospective prime directive cuando uno envía el form :)

miércoles, septiembre 20, 2017

Porque Eliminar las Evaluaciones de Desempeño

Les dejo un árticulo muy interesante de porque las empresas deberían alejarse del sistema de evaluaciónes de desempeño anual. Leer.

La solución es dar feedback continuamente!