Never stop learning

When you’re straight out of college or university, it’s unquestionable that you must learn after starting your first job. But for how long do you have to learn? When will the time come when you can just lean back, “do your job”, give advices, mentor, etc? Will it ever come?

I once thought “I’ve learned enough”. After spending ~16 years in IT, I had done database/C++/Java programming, mobile and enterprise software development, was developer, tester, dev lead and architect on multinational projects, mentored colleagues, helped them grow, participated in getting new people on board both on projects and at the company … you name it. Generally, I thought it was time for me to have some rest and share experiences.

Certainly, I could have done that. I do share experience ever since, but I could never lean back – and it’s for internal reasons. No matter how exhausted I might have become on a project, after taking 1 or 2 weeks of rest my mind starts working again: what’s next, what will you do now, what lessons can you draw, what new can you learn, can you share anything with people so that they don’t have to learn the hard way?

One way for me to learn is attending conferences. An advantage of the pandemic is that since we can’t travel, conferences go online – cheaper. I’m a keen visitor of conferences and happy to meet people, but since the cost structure of hosting a conference has drastically changed, we may afford conferences that we previously couldn’t. For me, attending a conference gives professional growth, emotional re-fill and generally it’s an inspiration to move further from the current status quo.

I firmly believe that one must not stop learning, ever. Not only in IT, but in general. We simply cannot afford it, for multiple reasons:

• Thanks for globalization, we can learn from truly global experiences. If you don’t do it, you’ll drop behind.
• With the coming age of Artificial Intelligence (AI), life will transform dramatically. My relatives (from non-IT world) don’t believe me that it will ever come soon, but we’re experiencing exponential growth here. I don’t fear of losing job, life will simply transform as to what people will do. If you don’t adapt, you’ll be surprised.
• If you solely rely on what your current job/company gives you, you may be the best worker – for them. But what about you? What are YOUR ambitions, what is YOUR plan?

You know, we’ve been doing some experiments lately: gave everyone access to an online course platform in the team. We thought it would unleash self-learning. Well, it kind of did, but most folks don’t live with it. Why? I believe it’s because motivation must come from inside, you cannot force it externally. You can certainly prescribe some mandatory trainings, if they’re required for your project, but that will not be one’s customized answer for his/her own needs. Companies cannot and will not give the answer to all your needs, but you must think through what you want (to become), make a plan and work towards it.

My advice, thus, to my kids and everyone who’s interested is unsurprisingly: never stop learning and be flexible to adapt. Change is the keyword of the future and this is the best way to prepare for it.

All the best,

Gabor

PM Unconference

I attended a conference last week, on Friday and Saturday. The topic was about project management in general and it was held in Szeged, Hungary, the city where I work. Something like 30-40 professionals got together to discuss about various aspects of PM.

What was particular about this event is that it was an unconference. As the BarCamp concept describes, it is an

open, participatory workshop-events, the content of which is provided by participants

Which means we just got together, we were explained “how the game is played” and got immediately a shot:

• Participants wrote the topic of their interest on a sticker, whether they wanted to give a brief presentation or, on the contrary, wanted to hear other people’s opinion
• Introduced themselves and put the sticker on the white board
• The white board had 3 rooms where the various sessions could be organized, sometimes we optimized if we saw some conflicts between them.

And that’s it! We had like 45 minutes time slots with 10 minutes breaks in between and then … go ahead! The audience was really mixed, from practicing PMs to folks who may once become a PM. We had a “special” guest as well, i.e. a lady from non-IT: she’s leading a local restaurant. It was really eye-opening how much similarity we have between these two professions.

What I liked very much is the pure interactive nature of the discussions, they were very lively. Since no-one could really prepare for their presentations, there were no formal PPTs or PDFs to present, thus presenters either just talked or also drew on the white board. The audience could and was encouraged to ask any questions during the presentations, which really made it a bi-directional conversation.

The topics were really diverse, just to pick up only a few

• How to start a project
• Agile transformation
• How to motivate people and how to help them grow
• Automation of management tasks
• What to measure: performance or working hours
• Company transformation from a start-up
• ROI for employees vs sub-contractors
• etc.

I think everyone was very satisfied at the end of the event, which was confirmed by their feedback on our quick retrospective.

Thanks for the organization, looking forward to the next conference next year!

Best,

Gabor

Delivery best practices – Pre-sales

It’s a hard decision for a company to turn to sub-contracting. Having realized that they don’t have in-house expertise and don’t want to/can’t staff the new development properly, they turn to another company that they have probably never worked with. The lack of trust is tangible from Day 0. They have the business plan secured, write the tender, requesting for company information (RFI), asking for delivery proposals (RFP), reviewing them, making a decision carefully.

Let’s now examine the other side!

A common approach

The very first thing you can do is gathering enough information to give an insightful proposal. You’ve got to learn a lot of things and must thus study your future client:

• Read about their background,
• Check latest news about them,
• Learn about their leaders,
• See who are the people you’d be potentially working with,
• Which technologies are used,
• Etc

One may ask how the last one can be done: you’d be surprised how much information can be retrieved simply by e.g. visiting a web site. When I did this the last time, for example, I could find traces about used front-end and back-end technologies, CRM system (including marketing), analytics, integration with social networks, user management, security methods, etc. This will help a lot to find the constraints you must be operating within in your proposal and on the project later on.

There’s usually a chance to ask questions and get answers from the client, either in written or on a conf call. Sometimes these calls are exclusive with the client, other times you’re together with other tendering companies listening to each others’ questions and the answers provided. You must focus on the top 5-10 most important questions to ask that are really crucial for your proposal – otherwise you’re wasting a precious opportunity and may also look less professional.

Get aligned internally in the organisation before finalizing the proposal. Don’t win for your bonus/promotion only and then vanish when the project starts saying …

I saw projects where the sales did like this, leaving the account manager and the rest of the team in a massive trouble. Ultimately, these folks should also be accountable for the success of the project to some extent, no? Perhaps, even financially.

Make sure the knowledge transfer from pre-sales to delivery is as efficient as possible. Lot of organisations have an A-team specialized in making proposals and the actual delivery is done by another team. I’ve already seen clients so much impressed by the “A-team” and deeply disappointed by what was following afterwards. Having different teams specialized in different areas is not the problem per se, provided they’re both competent and aligned – latter should follow from the former, actually.

The proposal will probably describe:

• Identified needs, stakeholders in question,
• The solution and how it satisfies the needs,
• Team structure,
• Schedule with dependencies,
• Cost breakdown,
• Etc.

It’s easy to forget about the following two topics, however: risks and assumptions. They both reveal more context beyond the afore-mentioned major areas, make the overall picture more complete. Also, they may become important arguments in your hands, when things are turning to serious. Don’t think, though, that merely calling out risks and assumptions will solve problems automagically – ignoring or forgetting about them will just hurt back on both sides.

Sometimes (often?) tendering companies don’t possess deep domain knowledge – they may just have technical people (e.g. developers) or developed a general-purpose product that now needs to be customized to a specific need. In any case, we should all calculate with a learning curve at the beginning of the project, when making/evaluating proposals.

Did I miss anything? I’m sure I did. Above list is just a collection of best practices that one may not find easily anywhere around. Please share your hints, they’re more than welcome!

This article is part of the series of related posts about delivery best practices. You may find other useful hints at https://gabortorok.wordpress.com/2019/10/08/delivery-best-practices-proven-methods-for-it-project-delivery/.

Best,

Gabor

Delivery best practices – Proven methods for IT project delivery

Many times when I’m in a discussion about project delivery I recognize how diverse our understanding is about this topic. I know that everyone has a different theoretical background and experience, yet there are well-known industry standards and thus I always expect a similar approach, a common ground if you like, as to how to minimize risks and maximize chance of success.

With that purpose in mind, let me share a few practices that I found extremely useful on my (on-going) journey in this profession. This is a series of articles with this one aggregating them at a single place.

1. Pre-sales
2. Starting a project
3. Communication
4. Planning
5. Execution
6. Risk management.

I hope that you’ll also find them useful, I would appreciate if you shared your own experience!

Enjoy reading,

Gabor

Self-development

Having worked for an outsourcing company for almost a decade, my approach to learning had gone through an evolution. What surprised me, though, that it is still evolving now that I’ve worked for another company for almost a whole year. I found the key difference in being even more conscious these days.

At the very beginning, all I had to know is what was closely related to the project, which was usually technology related. This changed after I joined EPAM as it was an outsourcing company, both giving consultancy and participating in the implementation of various projects for many companies. You must have a wider domain knowledge if you want to be successful in this business than what is strictly needed for a given company – you must be familiar with their competitors, their technologies, challenges, future needs, etc. I knew I had to learn, though I was focusing mostly on technology back at that time. Learning Java after C++ was a MUST due to switching company, but I was happy to make that step.

Then, I faced with other challenges as I was developing professionally – leadership. Fortunately, the company was always behind people wishing to develop and gave all the tools and opportunities to grow. They realized that it’s a prerequisite to growing their business, the math is quite simple: you must educate your people so that you can extend your business based upon them. I’d slowly got to the feeling that I must learn continuously, not because it was a well-known principle in the industry (was it?), but it was in the company’s culture and the environment.

Then, I’d got a little tired about learning. Yes, I admit it. I eventually grew into the role of a solution architect and I thought “I’ve learned enough, it’s time to share instead of running after technologies”. Needless to say how far I was from truth. Just exactly because I was a solution architect I always had to have a solid technology background AND be up-to-date with technology advancements. Of course, it’s impossible to be familiar with everything (cloud, Java, machine learning, Big Data, just to name a few), thus I had to make my choice. Since I was interested in e-commerce, as a business domain, I chose SAP Hybris. Actually, it was a hit of two flies with one stone – technology plus the domain. It was quite an interesting journey, I must say.

After some time, though, I started realizing that I could have even more influence on delivering projects successfully if I manage the them myself. Yeah, you may say: of course. Yet, it’s really a mental shift from designing the architecture to planning and executing the project, right? I had to realize that I like complexity in general, not only at technology level. But this poses different challenges, right, from schedule to scope management, team structure, risk & change management, etc.

How does all this come to self-development? You know, now that I’ve spent some time at another company I had to realize how much it’s up to me how I keep myself educated. I now remember it was similar at other companies, too: they provide you with a light-weight framework for learning and there you go. Here I am with my mixed skill set being interested in management, technologies and business domains and it’s entirely up to me what I learn, how much time I spend on it … eventually how I grow myself to what I want to be in the future.

With all this background, let me share some hands-on tips.

• As I strongly believe in focus, I allocated time slots in my calendar to self-development in the areas above.
• I carefully selected sources from the internet that I trust in delivering quality information and I follow them closely.
• Of course, I’m interested in any news coming on my way, however, I must also pay attention to filtering the “noise”.
• I prefer not to be interrupted during these sessions, if possible.
• I also read books, but I noticed I’m much slower with reading them and often don’t feel the excitement afterwards – I hope it will change, though.
• And finally, I share what I learned with those people who show any interest. It may motivate them to do something similar and also validate my interpretation of the area in question.

Actually, I’m sharing now, too, as I feel this method simply works for me. Probably it will work for others, too.

Good luck!

Gabor

About humility

I participated in a conference over the weekend that EPAM arranges twice a year, this time in Budapest, Hungary. This is an engineering conference, which we call SEC, a short for software engineering conference. Even though, as we like to say,

engineering is in our DNA

we speak more and more about topics that are not strictly about engineering, such as delivery management, user experience design, etc. Which is good and understandable given the trend of EPAM having stronger and stronger foothold on areas typically creative agencies and consultancy companies excel in.

I’d like to talk a little on the last presentation of the day that, I must admit, I expected the least of. It was given by William Benko, a Hungarian speaker whom I had never heard of previously. He’s not even from IT, had no idea why he was there at all. But as soon as the presentation started I soon understood it and to my biggest surprise the essence of what he spoke of still resonates with me very well. Basically, he built a presentation around three words: smart, hunger and humility, which he talked about through a few examples, all completely unrelated to IT. The message of his presentation was like if you combine humility with [wanting to become] smart and hunger [for success] one can make the most beautiful impact – may sound like a cliche, but so true.

The very reason for this blog post is not about smart or hunger, which should come natural in our profession. But as for humility, it’s not something we talk about quite often. Unfortunately. You know, no matter who you work with, what you work on, we’re all human. As such, it’s irrelevant how smart you are, if you’re higher ranked in the org chart, whether you’re a teacher or a student … stay humble. If you’re right, that’s why, if you’re not, that’s why. Not just because “you’ll get what you give“, but simply because giving respect to the other doesn’t cost a dime, but it immediately pays off: you feel better as well as your relationship with the others will be more and more built on trust. Even though our wishes and aspirations may be quite different, the need for being treated as a human is equal and not related to any profession. It starts with as little things as waiting until the other finishes the sentence, through feeling empathy with each other to not telling the other off or yelling at them. And the list goes on, of course. For example, I was once told by one of my teachers that the strongest people show their muscles the least. This is quite a visual example, but I quickly understood its second meaning, too.

EPAM is in the services business, which means we help other companies to build their own products, solutions. We continuously strive to win new deals with clients we have never worked with, which means we must build trust from scratch very-very often. In another presentation, which was a panel of senior delivery managers sharing lessons learned, one of the panelists said:

At the end of the day people work with people, humans with humans.

Sounds like a cliche, but it can’t be said enough times. It was kind of a coincidence that these guys talked about the same thing, but i’m so happy it happened. The importance of mutual respect must never be under-estimated and forgotten about.

Let’s be smarter, stay hungry, but above all: be humble.

Gabor

Cost of overtime

"We just need to work long hours and the feature will be ready."

"Can you drink a few more coffee to finish this task?"

"I don't care how much work it takes for them, they promised this."

 

Hi,

Have you ever heard similar sentences like the ones above? The more I hear them the more convinced I am that people saying them are not fully aware of the consequences of their request.

I’m sure many are familiar with the following diagram.

*courtesy of Price Systems

When doing any sort of delivery, fix all three of scope, cost, time and you’ll probably face with huge issues later on. Put it in other words, if you fix two of these three factors, leave the third flexible to avoid major risk:

• If you fix cost and time (“it must be delivered by date X and shall not cost more than Y”), let’s leave the scope flexible and focus on an MVP (Minimum Viable Product) first.
• If you fix cost and scope (“all of this functionality must be delivered for up to this amount of money”), let’s be less strict as to the deadline of delivery.
• If you fix scope and time (“this must be delivered by date X”), let’s cost be the moving part.

This is kind of the basics of project management. Experience shows, however, that there’s a fourth factor that is correlated to ALL of the afore-mentioned aspects: it’s quality.

*courtesy of Steve Draper

Above diagram tells that you may be as restrictive with scope, time and cost as you wish, it will surely affect the quality of the deliverable.

But let’s stick to the topic of overtime. A team will do overtime if at least time (from above factors) is fixed and delivery must be accelerated. Quite often, other factors are also fixed, most typically cost, but it’s not rare to see all three being fixed. The effect of overtime seems quite intangible, it’s kind of hardly measurable. This gives the illusion to some that it doesn’t exist at all. Sadly, it does. Overtime may work short-term, it may even bring the desired quality, but it will surely not work long-term. And for long-term, we don’t have to go farther than a few months. Couple of thoughts:

• When people do overtime, they get exhausted. They may recover successfully short-term, but chances are they won’t long-term.
• When exhausted, they make mistakes. The more overtime they do, the less productive they will be: their overall delivery speed will decrease, the chance they make mistakes increases.
• When exhausted, they become less tolerant to stress. Being less stress-tolerant, they’re less motivated. Being less motivated increases attrition. Becoming famous of attrition makes your project infamous, more difficult to staff, i.e. more costly.

A Product Owner must never underestimate the cost of overtime. They might win a short-term gain, but it comes at a price. Eventually more features will be delivered by the set deadline, but quality will suffer. The end users will use features with bugs, which hurts conversion, retention, lead generation and it may lead to churn. Now THAT is the price of overtime.

Product Managers must notice overtime as it’s clearly the sign of wrong assumptions, estimations, expectations. This is the time, when agile delivery comes in handy: find the root cause of overtime and fix it before issues pile up. But even if the delivery method is not agile, risk and change management are very powerful tools here. Continuous risk management helps to monitor issues coming up, classify them and find proper mitigation actions. Change management, on the other hand, helps to schedule these actions, adjust plans, allocate time and resources and in general keep delivery at a healthy level.

The delivery team and the Product Manager are all part of the same team, they share success and failure alike. They must work in symbiosis, depending mutually on one another. That’s why their sustainable good performance is key to success.

Any thoughts?

Gabor

Craft conf, 2017, Day 2 – Impressions cont’d

Following my previous post, Day 1 impressions, let me share what I learned today on the second day of Craft conf 2017.

• The first presentation I started with was about HTTP/2. Daniel Stenberg is from Mozilla and he’s been actively working on HTTP/2 in IETF. That sounds like a good start to hear an interesting presentation – and I was right. We were told some highlights on the evolution of HTTP, THE web transport protocol from HTTP/1 through 1.1 to HTTP/2. We learned that the major changes that HTTP/2 brought were multiplexing, the use of compression in headers, the protocol transforming to binary and finally the feature of server push. Multiplexing enables sending multiple requests on the same connection without having to wait for the first to complete. This makes communication an order of a magnitude faster than its predecessors. It was very interesting to learn that even though HTTP/2 is only a few years old, it’s already being replaced by QUIC, Google’s own protocol which is supposed to solve the problem of packet losses, i.e. if a single packet is dropped, then it may block all streams (this problem was introduced by HTTP/2). QUIC being specific to Google, effort is being spent on standardising at IETF.
• The second presentation was about mutation testing. I must admit two things here: I have never heard about this testing method and one of the reasons I chose this presentation was because the presenter was working for SAP Hybris – the company whose product I’m using on a daily basis. Well, I didn’t regret to listen as I learned what mutation testing was about: to evaluate the quality of testing (who tests tests?). On the other hand, it could have been squeezed into 20 minutes or so and it had nothing to do with hybris itself. Not as if it had been promised, yet I was secretly hoping in it. 🙂 Nicolas Fränkel was using PIT and demonstrated how false positives can be identified more easily, i.e. when you write tests and even though they all pass, they’re still wrong. It’s so easy to cover code with tests just for the sake of better code coverage, but we shall never forget that we don’t write tests just for better stats, but ultimately for better software.
• I was truly happy to attend the presentation of Sam Newman who shared his confusion about serverless computing. As it’s just becoming the next big thing, it’s important to understand what’s beyond the hype. I recall the first time I heard about serverless it was literally one year ago, when Adrian Cockcroft gave a speech right about this topic. Now that Tim Wagner’s presentation was dedicated to serverless, it’s a blessing to see “the other side”. Sam started with the name, serverless, and that how confusing it can be to people – as servers are and will always be there. He compared different variations of *aaS (IaaS, PaaS, FaaS, BaaS, CaaS) and concluded that serverless should be PaaS at least. The implication of infinite scaling of computing resources (for functions) is that soon the data store will become a bottleneck – unless that will scale as well (or simply, we reject further incoming calls e.g. via circuit breaker). He also mentioned two interesting aspects:
  • Vendor lock-in, which we shouldn’t really be afraid of. He suggests not to think about lock-in, rather the cost of migration. That is, the question really is: you pay now or later, i.e. invest in introducing an abstraction layer on top of the vendor (e.g. AWS) or pay more for migration when moving away from the current vendor.
  • How serverless devalues things like agile, devops and even micro services.
• I think Cornelia Davis has a very lovable presentation style. She’s very smart and hands-on and gave a great talk on what to expect from PaaS. Yes, I know she’s from Pivotal, yet she could deliver her thoughts without me feeling it was a pitch AND those things I heard were really useful (and actually quite timely for me). She first listed couple of obstacles from silos between dev, qa, prod through risky, manual deployments to changes treated rather as exceptions than the rule. The secret sauce of a successful PaaS includes things like using a single deployable unit, which is promoted across environments without any changes and stays immutable even in production. The ability of self-healing is also very important, when one thing is constant: the fact that things change. Environment parity must go away, self-service should boost agility and frequent deployment must simply remove the fear from change (and actually embrace it).
• I must admit I had expected a very different presentation from Phil Calçado, but I didn’t regret the one I attended. Phil is from DigitalOcean and he talked about the economics of micro services. I learned two very important lessons from Phil today:
  • If an organisation decides to start breaking up the monolith and moves to micro services, it can stop any time somewhere in between – it even had a name, called microlith. It doesn’t have to finish with a “full transformation” of the architecture, but the status quo is specific to each organisation. Phil suggested to start with experimentation first, create checklists and standards next, copy-paste, find/write libraries and tools and end up having a platform. Now, companies may never reach the fourth stage, yet it might still be perfect for them.
  • This is the first time I heard about the inverse Conway’s law, i.e. when the architecture drives the organisation structure, not the other way around. An org must be really flexible to allow to be driven, though, yet it may work.
• Finally, the last presentation I listened to today was about ChatBots from Jason Hand. The concept is so simple, yet brilliant: get an instant messaging tool (platform) and give instructions to a bot to do certain things, typically related to devops. Jason shared an interesting story about an Ops guy working for GitHub, who got an alert on a DDoS attack while he was on his way to the office. He just said: “Hubot, shields up!”, and the problem had gone away by the time he arrived at the office. He pointed out so many advantages of ChatBot:
  • Social: collaboration, knowledge transfer, make work visible, shortened feedback loops, etc.
  • Technical: automation, speed, system of records (ChatBot having an audit trail, etc.

As systems are typically non-linear, we often don’t have a root cause for a problem, but probably the distribution of causes. As such, ChatBots may be very handy in fixing issues and generally giving a boost to productivity.

Well, I got tired a little bit by the end of the conference – two days were just enough. I found that serverless has replaced micro services in popularity, but not entirely. Say micro services one more time has although passed the hype, it’s still everywhere. And I was so glad that I could attend presentations outside my comfort zone/narrow focus area – this is really important for me to see that there’s life out there. 🙂

Hope you enjoyed reading, please share your thoughts!

Thanks,

Gabor

Craft conf, 2017, Day 1 – Impressions

Hi all,

Another year has passed and Craft conf is here again! I was so excited to attend the conference as it had always given me new thoughts, allowed me to recharge and meet new people. It’s now the 4th time for me to attend the conference, actually since the very beginning, and even though it naturally brings less new information as initially, I still do enjoy it.

Let’s jump right into the middle and share what I’ve seen today on the first day:

• Tim Wagner’s keynote presentation was awesome! It was about serverless computing, which has become pretty hot recently. He talked about event-driven architecture, shared specific use cases and even show cased an end-to-end demonstration from code to running serverless app in live. The last 10 minutes or so wasn’t so perfect, though. Based on the real-time feedbacks some people apparently thought that it was more like an AWS pitch, which shouldn’t have happened on a keynote, but with due respect I disagree. Okay, it was a pitch, but it was about AWS and serverless, and one cannot take credit from Amazon pioneering on potentially the next big thing. It’s that simple. I respect that Tim was prepared to answer seemingly unpleasant questions such as when he would NOT recommend lambdas, apparently though he wasn’t that much prepared for the demo as that was the time when he started to massively lose audience.
• Dan North is back, as always. His presentation, Decisions, Decisions didn’t impress me, I must admit. The basic message of “we always make a trade-off” is much of a cliche to me that it’s not worth building a presentation around it. The problem may be really with me, but I didn’t find anything useful in it.
• Randy Shoup’s Effective Microservices in a Data-Centric World was so cool! He’s a VP Engineering at Stitch Fix, whose business model just impressed me: they ask you to fill a survey analysed by stylists and deliver clothes to you. If you love clothes in the package, you buy them, but those you don’t you can simple return. The same amount of data scientists work at Stitch Fix than engineers, which is unbelievable ratio. With this brain power, they do inventory management, machine learning, algorithmic recommendations, etc to make sure you always get what’s the best for you. Randy is a firm believer of TDD, continuous deployment and the use of micro services and shared a couple of hands-on hints with us. They started with a monolith DB, where all apps were accessing shared data in the same DB. They gradually decoupled data into their own respective services responsible for serving requests for the data they own. He talked about the use of event sourcing, different approaches to database joins across segregated data and the challenges with transactions in the world of micro services. Definitely worth watching!
• The build trap from Melissa Perri was so enjoyable! I really love Product Management and the fact that such topics are discussed on a conference full of engineers. The build trap is the ever-accumulating product backlog with features potentially no-one wants. If we don’t measure what real end-users really appreciate and don’t solve their problems, then simply we will not get back our return on investment. By real end users, Melissa didn’t mean a test target group in your company, but your real customers. Engineers and other creative folks must come to meet customers so that they understand what they need to be making and why. These user survey will never be too costly: delivering the pointless is costly. There is a break in the communication between managers and the Team: the team doesn’t understand/know the vision of the company and managers don’t pay attention to the challenges the team is struggling with. The vision must be communicated through measurable and achievable objectives to be reached in a set time frame. Another point on who is creative: I’m just starting to realize that one of the ingredients to successful product management is creative people, no matter where they come from. Whether they’re creative in visual design, software design or just simply can think out of the box – it’s equally good. For that reason, we must not stick with either software engineers or UX designers saying the ultimate truth, as it must be a joint effort.
• Coincidentally, Jeff Gothelf’s talk on Scaling Lean: Principles over Process was a logical continuation of Melissa’s I discussed right above. Jeff made a survey on Twitter about why large companies have scaling issues and although feedbacks included heavyweight processes, bureaucracy, silos between disciplines and teams and finally the general worry about brand, he made the conclusion that it’s often principles what is missing. He had collected a list of principles and shared them with us along with tactics we can use to achieve our goals and keep ourselves to those principles. Let me share only the principles with you, because they’re so great and right to the point that I simply can’t resist. I sincerely recommend you, however, to watch the presentation and learn from it. Here it goes:
  • Principle #1: Customer value = business value. If we make the customer successful, we’ll be successful. You must manage objective key results that are both qualitative and quantitative (measurable), inspirational, time bound and actionable.
  • Principle #2: Value learning over delivery. Let teams pilot things, encourage them to be experimental. Of course, you must carefully balance between experimentation and delivery, still learn, learn, learn.
  • Principle #3: Radical transparency. Transparency brings trust and it doesn’t go only internally, but following Melissa’s advice: go and reach out to your customers. I love the quote of the day: “You decide what is minimum, but customer will decide what is viable”.
  • Principle #4: Humility in all things. I love this, it is so true! Don’t assume you know what to build, bot go and figure it out. Value real roles and people instead of job titles. Talk and talk to both external and internal stakeholders.
• The last presentation I attended during the day was from Adrian Mouat, Chief Scientist at Container Solutions. Adrian is the author of the book, Using Docker, as such, he was talking about deployment techniques with micro services. I was there primarily driven by a “how is it going with containers these days?” interest and I think it was worth it. One of the main conclusions I drew from his talk is that this space is still somewhat immature as companies typically use bespoke, internal solutions mainly using either Kubernetes or Docker Swarm. Adrian took the most typical deployment models like Blue/Green, Canaries, ramped deployment and feature flags and shared some insights on the biggest issues, pros/cons for each from containers’ perspective. It was very useful to get a high-level view on these challenges, but – as he suggested – there are still such major topics to deal with as API versioning, database states, monitoring, more tools and patterns, etc.

 

Hope you enjoyed this post, please let me know what you think!

Best,

Gabor

Key take-aways from Amuse & Crunch conferences, Day 1

Autumn has come, it’s time for another conference. It’s Budapest again, this time it’s Amuse and Crunch. Amuse is about User Experience (UX) and Crunch is about Big Data (BD). The two are being held together as probably neither would attract a big enough audience and equally importantly the organisers are the same. So far so good, I’m interested in both.

I’m, as a solution architect, generally not involved deeply in either, but since I’m interested in product management, too, I would like to have a high-level overview of both. Which puts me in an interesting position: while my colleagues are complaining that some presentations are not deep enough, I generally benefit from most of them as they widen my spectrum well. For example, when telling my colleagues who happen to have BD expertise that I’m attending a presentation on how to build up a UX team from scratch, they laughed out loudly that I’m going to a CSS pres. Ridiculous folks, I know. 🙂 Still, at the same time when we met after the presentation, I was happy that I attended and they weren’t satisfied with theirs. Whiners.

Actually, I often take an unconventional approach when attending conferences: instead of “playing in the safe zone”, I go and listen to such presentations that are out of my comfort zone. And even if I grasp only the highest level and distill everything to a single sentence, I believe it was worth it.

It’s not the first conference from these organisers that I’m attending now. And one of the things that I like pretty much and the use of sli.do. I really like the way they make presentations interactive via technology: you just post any questions during the presentation and if it gets enough votes it’ll be answered by the presenters during the Q&A part. Very nice. Still, I’ve learned two lessons today:

• I attended a presentation on data visualisation, which was very interesting. The presenter was a technology evangelist from Tableau and, unsurprisingly, demonstrated the capabilities of the tool very effectively. I quickly checked the price rate of the tool and found that it was very high: between $1.000-2.000 for average people, like me. I asked the question via sli.do if they were planning to open for the masses via lower rates and to my biggest surprise I got moderated. My question initially showed up in the list of questions for a short period, it had even received couple of up-votes, but when it came to answering the questions, all of a sudden it just disappeared. I think my question was a valid one, it was even asked in a polite way, but it seems it wasn’t politically correct. Oh, my.
• The next story is about the mechanism of up- and down-voting. The presentation was about UX @ LEGO and I liked it pretty much. It was about how to build up a UX discipline & team at a company, like LEGO. I asked the following question: “How do you time-box creative people?”. I deeply believe it’s a valid question. It got ranked as the 2nd most popular question among all. And then I saw it declining: it was liked by 5 voters over time and after a few minutes only by 2. That was the time, when I realised that down-votes work against up-votes. I became the 3rd most popular question and chances were that my question wouldn’t be asked during Q&A. I quickly down-voted the second most popular question (shame on me), after which my question became the 2nd most popular again, but it was too late: the moderator eventually asked the other question and there was no time for a third one. Can you guess what was the 2nd most popular question? “Do you use LEGO at work?”. Grrr ….

But before the first day of the conference, I had attended a workshop yesterday, which was about Lean Analytics. It was AWESOME. Was held by Ben Yoskovitz, who’s the author of the book with the same title and the workshop was full of hands-on insights as well as theory. I couldn’t have imagined a more effective way of learning about product management and analytics. In one sense, it could have been counter-productive as I thought it wouldn’t be worth buying the book after this presentation, but on a second thought I think I really will buy it: I just can’t miss this knowledge from my book shelf. Such a great day!

Then, key take-aways from me from today. Warning: absolutely subjective, but hopefully still informative:

• The presentation from Andy Cotgreave @ Tableau was very inspiring in the sense that we must really go beyond showing raw numbers and “first-instinct diagrams” if we want the audience to quickly grasp and remember of what we really want to say. His example of Iraq’s bloody toll was really interesting and shocking at the same time: the creator of the chart played with colour, direction of chart bars and title. Also, Tableau seems to be a very powerful tool to achieve this purpose, although the price is fairly high if you just want to get familiar with it.
• Dan McKinley from Etsy revealed some insights from data analytics and how it drove business when he was working for Etsy. He shared how easy it was at the early days to think that cool ideas will surely generate more business, but only when they started to measure they realised how far that was from truth. It’s useful to know how much contextual knowledge counts when optimising for conversion as you won’t follow the same strategy for low-cost gadgets versus relatively high-cost furnitures. The most memorable sentence for me was still this one: “You must never assume Product Managers will fully know what they’re asking.” Nicely put.
• Laurissa Wolfram-Hvass was talking about researches done @ MailChimp. It’s the little(?) things that grabbed my attention the best:
  • Usability lunches – free food attracts everyone and it’s a great opportunity to unleash creativity.
  • Visit & film customer offices and use this in the material to present them how much you understood them and their business.
  • Customer panel is a great tool to get your most influental customers at the same table and hear how they’re using your product and what they suffer from the most.
  • Encourage everyone at your own company to do research for the company’s overall benefit.
• Marton Trencseni from Facebook was talking about data science. They do gather metrics mostly about growth and engagements, of course at an unthinkable scale. They do gather metrics at a very granular level and cut data per access interface: all – mobile – iOS – Facebook for iPad is just a single path among all. What I liked the most, though, was the “counter metrics matrix”: they set a target metric (e.g. increase Daily Active People) which they compare with an another metric, which is not necessarily correlated (e.g. # of support tickets). They do different actions depending on how these metrics change:
  • If DAP goes up and the # of support tickets remain, then they keep the new feature.
  • If DAP goes down and the # of support tickets goes up, they decide on a case-by-case basis.
  • If DAP remains and the # of support tickets goes down, they keep the new feature.
  • etc.
• Janne Jul Jensen from LEGO was talking about setting up a UX team from scratch. The biggest challenge wasn’t necessarily the team, but the fact that the discipline was brand new in the company. I truly understand this as I’ve seen it a number of times at my company. It takes a great effort to find your own identity, i.e what UX is at LEGO, and communicate that consistently and repetitively. Also, you must educate people to get rid off misconceptions of a new discipline. Hats off, this must have been a great effort, and I can tell it’s by far not over.
• Mike Olson is an industrial veteran, who co-founded Cloudera. He shared a lot of insights not only from the past, but also put vision on the future of Big Data. All of his examples revealed deep insights and forecast a more advanced future relying on technology and BD processing in particular, still the most moving part was when he was talking about technology serving people in healthcare: either as employees or patients. The two examples of analysing the activities of newborns real-time and doing predictive analytics for regular patients to prevent from sickness and staying in hospital are very useful applications of technology serving humans.

Finally, I liked the after-party in a way that the food, the drinks and the music were all just right. But it’s not the first time that I found that I cannot effectively do networking. And it’s probably not just me: IT guys like me will just simply not go to the other to ask “hey, Dude, who are you and what are you up to?”. Maybe it’s not about my profession, nor my personality. It was the same at QCon in London this Spring: people mostly talked to their colleagues or some folks they had previously met. The next big challenge for the organisers of any conference: how to get complete strangers together to meet, discuss and enjoy conversations with others?

Hope you enjoyed reading this wrap! Any thoughts from your side?

Best,

Gabor