I recently stumbled across this HBR-post by Julie Zhuo. It’s a quick read, so take 5min to go through. It does a good job summarizing the 5 major aspects which will change when you grow from managing a team of individual contributors to leading organizations which are
Like in many jobs it is not easy for mine to squeeze in the regular learning to stay on top of new technologies, techniques, process etc. It’s too easy to get busy with the seemingly urgent topics of the day.
There are three strategies that work best for me to keep my self up to date:
This article is about one of those projects.
The „problem“
I’m thinking of selling my current car next year and instead of buying a new one lease a one instead. One of the parameters that affect the cost of leasing is the distance you plan to drive every year for the duration of the contract. My guess is it will be a bit less than 25000km, but I’d like to know for sure as I don’t want pay more than needed but also don’t want to drive more than what is allowed in the leasing contract.
The non-technology solution that I’m using right now and which works perfectly fine consists of a pencil and a post-it note:
Every once in a while I write down the date and the total distance in kilometers (the German word on top says „mileage“). If I do this long enough I should have a pretty good idea what amount of kilometers to put into the leasing contract.
The over-engineered solution
Wouldn’t it be nice if I simply could take a picture and the mileage got recorded somewhere on the internet? Yes, of course, that would be nice and also I can do this all with AWS and a bit of Golang and Dropbox.
So, here is what I’m planning to do:
When I’m sitting in my car, I will take a picture of the dashboard which includes the mileage.
I’ll take that picture and upload it to Dropbox. Dropbox will shoot a message to AWS API Gateway that something changed on the monitored folder. API GW triggers a Lambda function that merely publishes a message to a topic on AWS Simple Notification Service.
Another Lambda function subscribes to that topic. When it gets triggered it calls Dropbox to get the latest files that got created, saves them to AWS S3 and deletes them on Dropbox. It also saves a Dropbox cursor to a table in Dynamo DB. A cursor is a pointer to a certain state of the folder when you last looked at it. So if you pass that cursor into a future list_folder call of Dropbox’s API you get the files that changed since when you called that function the last time. Lambda gets the Dropbox API key from AWS Secretsmanager.
When the image is stored on S3 a third Lambda function is called which utilizes the AWS Rekognition Service to extract the mileage from the dashboard. After extracting the data it saves it to a different table in DynamoDB and deletes the file on S3.
Eventually, I want to build a simple UI that allows me to view the data somewhat graphically. For that, I’ll utilize all the same service that I used above.
S3 will serve a static webpage with some Javascript which will asynchronously call API Gateway. API GW triggers a Lambda function that simply accesses the data in DynamoDB that we previously saved there.
So far I have the basic AWS infrastructure set up and the first Lambda function is done. Now I’m working on the second one and then finally it gets to the most interesting piece of use the Rekognition API.
Over the next couple of weeks, I likely post some details of this project. I hope you’ll find this interesting!
Last week I visited AWS Summit Berlin 2018 and I really enjoyed it even though some presentations were very AWS marketing heavy. I guess that is fair given that it is a free event.
I learned that this year it was the first time that they scheduled it for two full days. Hence the sessions were a good mix of more high-level presentations and some technical deep-dives. I enjoyed both kinds of presentations.
You also had the opportunity to talk to lots of AWS employees and partners which probably was useful for those coming with very concrete topics. For me, I only took the time to learn what some of those companies are doing which definitely was time well spent as well.
If you asked me my three main takeaways here is what I’d like to call out.
1. Don’t start with solutions, start with problems that your customers are having.
This reads so obviously and still, often we are not working like that. Instead of first deeply understanding the need of the customer and the problem that we’d like to solve we are suggesting a premature solution and later are surprised by the fact that we are not meeting „customer expectations“ or rather haven’t solved any real problem or have solved it in a way that doesn’t work for the customer.
To resolve this you can use different methodologies. Design Thinking is one of them, Working Backwards is how AWS fills this concept with life.
It was also pointed out that this process needs to become part of an organizational flow in which you start with Design Thinking, you then work on solving the problem with Agile Teams and operate those solutions with DevOps in mind.
2. Generalists vs. Specialists
In a session about Artificial Intelligence and Machine Learning, the presenter made a point about generalists eventually becoming more important than specialists if you are talking about building successful solutions.
Take experts in artificial intelligence for example. There are only a few true experts in this field available globally. However, there is a huge demand for knowledge of AI / ML in the industry. The way AWS reacted on this is to offer three layers of AI / ML related services. First, the very basic level. It offers you the greatest flexibility, but it also requires you to understand the underlying models and math. The second layer gives you access to frameworks. You still need to understand the ML concept, but you can rely on algorithms doing the actual work. The third layer consists of application services which have a specific purpose and are pre-trained by AWS. E.g. voice recognition, image recognition etc.
So in above example, people who are not experts in AI / ML can apply ML to their solution because of the application services that are being offered by others. The specialist is not needed in that case. Who is needed is someone with a brought view on technology who is able to understand problems and find solutions given existing technology.
I still think there always will be the need for specialists, but I found that point of you refreshing and interesting.
The presenter also shared a fitting quote from Robert A. Heinlein:
“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”
3. Learn
This one is more personal for me. Sometimes it is easy to become complacent. You know what you know and you are good at what you are doing. But what are you really doing? You’re are slowly killing your future. It is important to continue learning and stay curious. Why?
Learn to Learn and be Curious:
Have you visited an AWS Summit in your country? What were your main takeaways?
DevOps has many levels of complexity. The cultural shift and the organizational structure are the hardest ones in my opinion.
Another one is simply the wealth of tools in that space. I really like the page that XebiaLabs put together. They formatted it like the periodic table of elements which helps you to select tools for a certain domain, e.g. repository management.
Unfortunately the page is not quite complete, nevertheless, it is a good starting point.
The last couple of weeks have been pretty busy. Privately our little daughter is rightfully consuming a lot of time and also we have been in the final phase of planning our big garden project which now will commence in May. For work, I’ve been traveling a fair bit being in the US now the second time in a month and on top of that was in Prague last week. Besides that, we are entering a time of change, which is good, but also intense.
I want to keep my schedule with posting something every Monday 6pm and really today I only will manage it with a cheat. I definitely missed German time 6pm, but I can still make Seattle time 6pm!
Recently on Twitter, I found this quote:
“The problem with quick and dirty is that the dirty remains long after the quick has been forgotten” – Steve C. McConnell
Steve McConnell is the author of Code Complete which you can order on Amazon (affiliate link)
It is a book full of wisdom for programmers and one of those books that I like to have a hard copy of. Its content remains true for a very long time.
Back to the quote: „Quick and Dirty“ is so appealing when you are acting under constant time pressure. Everybody seems to be happy at first. The developer can move on to the next task and the product owner gets the feature, extension, bug fix or what-so-ever quickly.
The problem is that just after delivering the item the next urgent thing is lurking around the corner and the quick win is soon to be forgotten. What remains, however, is the hack. Worst case it will cause a bug in future because of unconsidered use-cases or untested side-effects. Best case it will make your system less maintainable, less performant, less readable, less extensible, … the list could go on.
The collection of hacks that your system is built on over time when you have delivered too often „quick and dirty“ is going to make it harder and harder to maintain and extend the application. It will become more error-prone and you will deliver slower and slower until you eventually will have to go into a painful and resource consuming rewrite of large parts of your application.
Don’t be tempted by quick and dirty. Try to do things right and you will be faster in the long run. Constant investment into the architectural health of your system will pay off.
Defining an MVP is a great approach to deliver value quickly to your customers and also to get good feedback on functionality very early in the development process so that you can base future decisions on that feedback.
Let’s start with a definition. What is an MVP? Here is the definition from Wikipedia:
A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.
And another definition from the book The Lean Startup:
Version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
To me the two key goals of a Minimum Viable Product are
So why does the title of this blog say that MVPs suck sometimes? It’s when we deploy an MVP into production and then never listen to the feedback and never invest in future iterations.
In that case, the only value we will get out of an MVP is being quick to market. And of course that in itself is a value but you are risking to get unhappy customers because sure enough by delivering an MVP you are setting the expectation that feedback will be evaluated and eventually the piece of functionality will evolve into something fully featured.
Many of you probably know this picture comparing an MVP to a classic iterative approach.
I fully agree with the second row of the picture, but the important piece here is that the product evolves over time from a skateboard (something minimal to get from A to B) to a car (something pretty efficient and comfortable to get from A to B)! If you keep the skateboard for years without improving it you will end up with unhappy and frustrated customers.
Also, …. the agile teams who worked on the MVP will be disappointed that they cannot iterate on the product. It feels like an unfinished job. You might think that this is unimportant detail, but the contrary is true. It directly impacts the motivation and the engagement of the team. More about that topic in my post about what employees really motivates.
Of course, sometimes it is just fine to stop after the MVP is delivered.
Getting feedback from the market and not iterating on it because you are already asking teams to work on the next top priority is what will hunt you down at some point future and has a negative impact on team morale.
So what’s the alternative? I think there are two, but really there is only one. And also… maybe there are some that did not come to my mind …
In my opinion, only #2 is the only long-term sustainable way to go. Everybody involved in the process of delivering software to customers should push for this. It is not easy because there are always so many important things that one could work on, but it will pay off over time because it allows for focus and the customer feels heard.
I’d love to hear your opinion on the topic!
See for English language below….
Deutsch
Dem wiederkehrenden Besucher wird auffallen, dass manche Artikel in Englisch, andere wiederum auf Deutsch veröffentlicht werden.
Warum?
Der Hauptgrund ist meine eigene Faulheit die Optimierung meiner eigenen Zeit. Ich schreibe in der Sprache, in der ich am besten über das gegebene Thema schreiben kann. Für Themen die sich auf irgendeine Weise auf meinen Beruf beziehen, fällt es mir leichter auf Englisch zu schreiben, da das die Sprache ich die ich beruflich zu 95% einsetze. Artikel über Hobbies fallen mir leichter auf Deutsch. Darüber hinaus ergibt es auch wenig Sinn über z.B. MyPoster.de auf Englisch zu schreiben.
Wird sich das unter Umständen ändern? Vielleicht… „Nothing is as constant as change“. Das aktuelle Ziel ist zunächst einmal jede Woche einen Artikel zu veröffentlichen und ein paar Besucher zu bekommen.
Vielen Dank fürs Lesen!
English
The returning visitor might have noticed that some articles are published in English and some are published in German.
Why?
The main reason is my laziness my attempt to optimize my own time. I always write in the language in which I can express myself the best on a given topic. On topics that are somehow related to my job I’ll always use English as that is the language that I use 95% in my day to day job. Posts about my hobbies are easier for me to write in German. Furthermore it doesn’t make a lot of sense to write an article about MyPoster.de in English.
Will this change eventually? Maybe… „Nothing is as constant as change“. The current goal is to publish a post per week and to get actually some visitors.
So thanks for reading this!
My Development teams at Concur are currently all working on complex, high profile projects. Things are challenging and stressful.
In times like that it is important to remember what really drives motivation of a highly skilled workforce. As probably everybody knows by now: it is not money. Money is important and we need to pay people fairly, but it is not what ultimately motivates them long term. As I said, not a new thought, but in times like these, it is easy to forget.
What really motivates us can be distilled in three words:
Read all about it in „Drive“ by Daniel H. Pink. Or just watch this video:
Once your company has decided to adopt DevOps, that’s when the hard work actually begins. Typically Development and IT-Operations are separated organizationally. How do you bring the two together? What’s the best approach for your company and how do the different approaches compare to each other?
All those questions are non-trivial to figure out. For me, the work of Matthew Skelton and Manuel Pais really helped me to bring order to the various patterns and anti-patterns that exist.
I highly recommend you take a look at their work:
The ability to multitask is often looked at as a positive characteristic of an employee or of a team. I’m often impressed myself with people who are able to keep several balls up in the air. However, what everyone should keep in mind when asking anyone to multitask is the cost that is associated with it.
In „Quality Software Management: System Thinking“ Gerald Weinberg suggests a rule of thumb to calculate the cost of context switching when working on several projects at the same time. When a team is working only on one project they can dedicate 100% of their time on that one project. According to Weinberg, once you add one project 20% of the team’s time is wasted with context switching. When adding a third project only 60% of the time is used on projects. By adding a 4th and 5th project you are wasting more time than you are focusing on actual projects. Jeff Atwood wrote an article in 2006 referencing several studies about the problem: The Multitasking Myth
From the above one can easily think that focusing on one project is something that everyone should aspire to. Personally, I don’t think that is realistic or even pragmatic. First, the requirements for your business will almost never comfort you with the luxury of only focusing on one thing. Secondly, there is such thing as dead time in projects. So periods of time in which you are waiting on something in order to progress with your project. No matter how hard you try to align everything in order to avoid dead time, you will have some.
Knowing there will be dead time you can use this to your advantage by pipelining a certain amount of projects. If project A is blocked people can progress on project B, etc. The cost of context switching is still there, but it is mitigated by the ability to work on something highly prioritized during dead time of another project.
Another false belief is when running only one project 100% of a team’s time will actually be used for working on this project. I’m doing that mistake myself a couple of paragraphs up in this post. You will not be able to spend 100% of your time on a project hence it is wrong to assume it. There are a couple of reasons for this.
One reason is, everyone will do something unrelated to work throughout their day. Several studies have been conducted and on average it seems that out of an 8 hour work day only 7 hours are effectively used for work.
Also, urgent things will interrupt the day. Especially if the development team is also responsible for maintaining an application in production systems. How much of a team’s time goes into solving production issues highly depends on the quality of your software. In any case, things will happen and you need to be aware of that when thinking about how much time can actually be spent on a project.
Thirdly, teams will spend time in meetings, will receive training, will have to monitor production services, etc. Again, how much time goes into that is probably individual for each team, but it needs to be accounted for when thinking of how much time can be dedicated to a project.
Just being aware of all the above already helps. Teams and organizations need to find the right balance between multitasking and focus. Finding that balance requires work from everybody involved in the process including the leadership team. Also embracing agile methodologies will help prevent over-committing and account for the fact that your team is able to spend all their time on a specific project.
What are your thoughts on this topic?
www.stefansiebel.de 