Creating a sense of urgency in the workplace can be a powerful tool for us to use to motivate our teams. However, like most powerful things, it can be easily misused and can cause more harm than good. When running a software organization, the misuse of sense of urgency can hurt software quality, productivity, retention, and even destroy someone’s reputation. But it’s not all bad, we’ll also talk about how to use a sense of urgency effectively. A recent conversation at a software event made it clear to me just how important it is to talk about this…
Not many of us in the industry would deny that software has the image of being a young man’s world. Is there truth to this perception? What’re some ideas about what causes it? Can we do anything to help?
We all play the role of an Architect at one scale or another. We may not all have the title “Architect”, but in our daily work we make decisions about the architecture of the system. We may choose a language or a framework for new development. We decide which design patterns would be best, and which to avoid. Someone might consider any of these decisions to be “architectural”. Some decisions like which version of a library to use, are relatively small, while others such as monolith vs microservices can be huge. The obvious impact of decisions like these, show the importance that our architecture can hold to the company.
You’ve probably heard in the news that some 11 million Volkswagon cars were loaded with software specifically designed to “cheat” emissions tests. The car would recognise when it was being tested, and switch to a special mode that would drop emissions to the bare minimum. So the cars would pass emissions tests with numbers that were much lower than what the car actually produces when driven on the road.
On October 8th VW’s US CEO was pulled before congress and was asked what knowledge/decisions were there at a corporate level for this. To which he replied that an investigation is still “on-going” and continued with:
“This was a couple of software engineers, who put this in for whatever reasons”
– Michael Horn CEO Volkswagon America
Poaching is defined as when a company hires an employee from a competing company. Some choose to go farther and say when an employee is actively pursued and hired by any other company. However we choose to define it, having our talent poached is always a scary idea. We have one more position to attract and fill. And it always seems to be our best employees who get targeted. But what can we do about it?
I recently read a blog post about work-life balance by Chantal Panozzo where she described her experience working in Switzerland, and I was struck by the stark contrast to the culture here. I got admittedly green with envy while reading about a country providing 14 weeks paid maternity leave, and professional-part-time work with benefits. However the culture we’re talking about in this post is the work culture. The culture created by our coworkers, how we act, what we expect, what we accept. This is something in which we can affect change without the need for legislation or a major shift in our companies.
The office recently had some T-shirts made for our developers. The hope was for all our customers and partners to be able to easily recognise our developers at a conference. Unfortunately the T-shirts didn’t compile.
I just completed the Certified ScrumMaster certification by Scrum Alliance. It was a two day course full of dry-erase markers, slideshows and team activities. Lunch was provided.
Overall, I enjoyed myself. We went over the Scrum roles, the different Scrum Meetings, the Scrum Artifacts and general agile principles. There was plenty of time with each topic to answer questions, and everybody was engaged and part of the discussion. I doodled and took notes with colored sharpies, and there were pipe-cleaners spread about for those of us who like to fidget.
In my last post about the Clean Architecture (link) we talked about dependencies, and how we’d ideally like them all pointing “inwards”. That is, we want all the dependencies pointing away from code that might change, and towards code that is less likely to change. The reason we should be intentional about dependencies, is to limit how often we need to change our code. Changes will ripple along those dependencies. Additionally, we need to handle the behavior of dependencies when unit testing.