When the first iPhone launched in 2007 the features and capabilities of the phone were revolutionary, but it’s often forgotten that the app store as we know it today wasn’t avaible. There was a tremendous hunger among developers who saw the future land rush, but couldn’t build native applications yet.A year later when the app store launched, the phone took off, and we really entered a new era.From the moment that people were able to add applications to their devices, effectively customizing their phone to their life, the dynamic changed. Competition wasn’t really possible
Around midnight last week, we turned on the Seattle local New Year’s Eve broadcast, sponsored by T-Mobile, and happened to turn it on just a the moment the T-Mobile executive was using their sponsorship time to talk about how 5G was going to change the everything for everyone. He gave examples of how 4G had made Uber possible, and a variety of other examples of why the future was going to be wonderful here in Seattle with T-Mobile.A few days later Apple issued its earnings warning with iPhone in China as the cause behind the miss in earnings.
I read this article today which is a very good look at some of the things that happen in IT organizations. I've worked in a couple of teams that operate this way, and it's absolutely a shock to the system.One key element for the author Ian Miell is that his experience and observations are driven by highly regulated financial institutions. Places where audits and regulatory compliance are baked in for good reason. I'm sure it's all true, and that even the horror stories in his story are gentle in comparison to some of the things he has seen.I've
The React ecosystem has become a fantastic tool set for developers on the front end. It has come a long way in the last five years, and for the most part it's a lot of fun to work with. I still remember my first experience with it and how enjoyable it was to build a web application. I never built anything super complicated but it mostly just worked. I've kept mostly up with the ecosystem since, but this week I started working on something in earnest. The most visible change over the last 18 months is the degree to which
It has been a while since I wrote, but I've been busy writing on a couple of topics, including how teams can balance customer voice with their own vision. I probably need a way to figure out a shorter article style, something that can be written in a lot less time. I tend to write and work in complete thoughts, or complete thoughts for me. So I'll try a short piece here.
I've worked on a fair number of projects in my days, and I regret to inform you that we have found our way into a bit of a pickle. Photo by rawpixel / Unsplash In the old days of video games, you would work for months and years, crafting your best product and then send it off to manufacturing. It was out of your hands. Every decision, good or bad would show up on that disc. If you cared about what you were doing, and most people did, you worked way too hard to make sure that you put the very
Program managers, product managers, delivery leads, Scrum Masters, and other roles are everywhere these days, and there is constant tension between these roles and the developer roles at a lot of companies. In my observation there are two key reasons for this tension. One of these reasons is at the organizational control level, the other is in the hands of the individual PM. If you want to be successful in a company building great technology products in a role like this, having the support of the technical team is a must, and it's easier than it might seem. Let's start
Like many people I provide a variety of technical support services for less technical family members. Over the last few years I've been encouraging people over to the Apple ecosystem, largely because it's what I use, and it's getting harder and harder to support windows machines when I haven't used a version of windows as a daily computer for a decade. It's not that I don't think that Android, Windows, etc aren't fine solutions for many people; it's just not what I use myself. When I'm explaining how to resolve or debug some issue, over the phone, with only a
Photo by Patrick Fore / Unsplash These kinds of decisions go by many names, but I usually call them Jellybean decisions. It's the kind of decision that teams often spend a lot of time working through, but in the long run don't have a major long term impact, or switching cost is low later. Once you have decided to eat a handful of jellybeans, how much time do you spend picking out the colors? Sure you might have a favorite, or least favorite, but those colors don't have a major impact in the long run. There is no ANSI standard for
I've been using a Macbook Pro 15" from 2016 for about two years now. I am pretty sure that all my keys work. I've certainly read about a lot of people who have had problems with the keyboard on these models, and today Apple announced a service program Here's the thing about this keyboard. Even with one that I'm pretty sure works correctly, the key feel and typing isn't what people are used to. I won't say it's bad, but it is different. Personally there are some elements I like about it but keyboards for people who type for
I've spent a lot of time observing teams. At first glance almost every team I see is working hard, and trying to do the right thing the best they can. Sure they may not be super effective or efficient, but it's not for lack of trying, and often not their fault. One of the key things I look for is how a team works, and more specifically how they allocate their time. If you really think about it there are really only two things teams do: Productive work, making, building, etc. Communicating, estimating, justifying, and explaining the work, and status
How did your team end up using your current methodology? It's kind of a trick question, because if you are using a branded Agile methodology you have probably already made choices that are highly limiting to your teams empowerment, and the trust of the organization that's needed for long term success. Capital A Agile software development has fully infected many teams. There are so many lessons to be learned from software development history. We stand on the shoulders of giants; but the leadership at many companies are not part of that on-going conversation. This means that you must assume that
It's a fine line for a lot of people, you get to be a manager and it sort of pushes you further away from the work, a few years go by and the time you had previously invested in staying up to date with the latest changes in languages, tools, etc., is now spent working with your team, or on manager problems. You can't contribute in the same way you used to. One of the most difficult challenges a manager faces is to figure out how to maintain the contribution that got you to this new management role. Where do
I am of the school of thought that says software products are complex. Even, or perhaps especially, when you try and make them simple to your users. The technology is a part of it, but most of the complexity comes from the fact that you are designing and building something new. The work to understand the problem space, customer need, and how that intersects with the technology you need to build is all part of that. The most efficient process to implement something is usually not the most effective process to design that same thing. Properly done, teams are constantly
Companies big and small, especially ones that don't have software deep in their founding DNA tend to fail more than they succeed in their software projects. The fabled digital transformations are very expensive, but don't always end up the way people hope. I've seen a few of these, and there are some common factors and trends. Watch this space for more on how to spot things going wrong, and some of the things you could do to avoid the pitfalls.
The US Senate today approved the nullification of the FCC net neutrality rollback. This is a positive step, but to actually matter the house would need to vote the same way. It's nice however to see Democrats and a few Republicans continuing to make an issue of this. It's a very good example of a complex technical topic getting various interpretations based on politics. There are a ton of different constituencies in the commercial space including tech companies, telcos, and media companies. The venn diagram of conflicting interests is surprisingly complex, and that's before you get the money and politics
But how do I turn this into something I can send my executive team? Honestly you shouldn't have to. Your executive team should be smart enough to be involved in the motive creation, and be observing the approach definition process. Depending on the company they may be highly involved in that part of the process. The key to turning this material into something your less connected executives might recognize is in the early alignment stages. If you are actually executing against a model like this, you are producing at least one Rally Point per iteration to show your work. More
There is no fancy name for this. Your team may call them tasks, or stories, or really anything. But no need to get too abstract. It's just work. The difficult little things we all do every day to make something. Break down your Rally Points into individual work items for human people, use some sort of system to track them. Could be post-its, could be jira (if you really really have to). Try and come up with something that is optimized for makers, with a low overhead. In an ideal world you would extract these from the actual work of
Complex software requires a lot of work to scale and stay aligned. Many companies who don't have software in their DNA think that software like many industries will go faster with more teams, more individuals working on those teams, and more people over all. Software development does not have economies of scale. Development has diseconomies of scale — Allan Kelly Communication might be the opposite of software development. It's hugely difficult and time consuming. People literally speak different languages. Rally Points are all about translating your now well understood approaches into work that can be done by small groups. Small groups
We actually don't know enough yet to start fixing this problem, what we need is for the smart, creative, passionate people to start building out an approach, or better yet, multiple approaches. This is a thinking heavy exercise. A well crafted approach might be several pages, it has evidence, and it has context. To do this right you are going to need to: Research the problem, and identify things that might be causing it Identify key factors that could change to improve your problem Think through what levers you might pull to change something, and what might happen when you
Instead of starting with goals, we will start with a motive. A long term why framed as a reason. This motive should be substantial enough that everyone can agree that there is a problem, and a good reason. A motive should avoid a solution, but instead articulate a measurable change and the reason why the team or company needs to make progress on this now. We lose 50% of customers between adding an item into their shopping cart and checkout. We need to reduce that to lower than 20% because it represents 50% of our potential revenue and turning more
Google announced and demoed Duplex this week, and it's really quite something. This is the stuff of science fiction in many ways. The recognition capabilities and dealing with some of the conversational branches is really quite impressive. People seem to be thinking a lot about the fact that the synthesized voice includes fillers like "umm", which is a part of making the voice sound more natural and human. After listening to all the demo calls published on the Duplex site, I pretty quickly identified a couple of repeated tells that felt awkward. The "em hmm" that
Doesn't seem to be confirmed yet by Apple, but lots of stories about Apple restricting the Lighting > USB connection on locked phones after 7 days. What this means is that if someone takes your phone, but doesn't have your passcode, after seven days they will no longer be able to connect that phone to a physical device and copy data off the file system. The file system is all encrypted, but while it sits on device, it's protected by the non-trivial hardware and software protections that Apple has woven throughout their hardware. If you move that data, even encrypted