The law of the instrument states that if your only tool is a hammer, you are tempted to treat everything as a nail. In modern business this hammer often is Excel. Every time someone needs a little (or larger) tool to do some work, in many companies the result is an Excel spreadsheet with lots of logic, programming and formatting in it. It’s tempting since in a corporate environment nearly everyone has an office suite on their computer. An obvious solution is hacked together pretty fast and often never again understood, but more on that later.
There are however some fundamental problems with applications becoming spreadsheets:
- They are inherently not multi-user capable.
- They are not versioned. Everyone has some version or the other of the file. Nobody knows which is the newest.
- They are not maintainable or understandable for someone else as the author or later on even by the author.
- Data, code and visualization literally live within the same space.
are those things generally and inherently bad? Aren’t there legitimate
use cases for „Excel apps“? Let’s give all the shortcomings a closer
Not multi-user capable
Without using special server components Office documents are not multi-user capable. The start of all misery often is a mail, spreading a document among several people. Then some or all of them start to make changes. If they don’t synchronize who works in which order on the document (and sending around updated versions of the corpus delicti!) the proliferation of conflicting versions will drive you mad some time later.
Different people will have different versions of the document. Even you yourself might have different versions, if you chose not to overwrite the existing file: My_Important_Calculation_2019-01-05.xlsx, My_Important_Calculation_2019-01-07.xlsx, My_Important_Calculation_2019-01-07_better_version.xlsx … sounds familiar, eh? I hope I don’t need to explain why this is bad.
Lack of maintainability
Ever tried do decipher a formula as long as the Panamericana crammed in a cell the size of a fruit fly? And now imagine trying to understand what the whole worksheet does by clicking into each and every cell and try to figure out what happens therein. I know there are people who are able to grasp an overall view of a worksheet they never saw before. But I prefer to use my brains computational power to solve the underlying business case or problem instead of an encrypted version of it in a worksheet.
Your data (the numbers and texts in cells), your code (formulas) and visualization (some inline created graphics) literally live in the same place, your worksheet. You could try to separate the code by using Visual Basic for applications or some more modern replacement but this solves the problem only partially. And you lose some of the just in time synchronous tooling which is one of the few advantages of the Office solution.
Writing good readable and maintainable code is empathy with your team and your future self. The hardship you go through when you rely on office “applications” for your business mostly was created by yourself and / or your team. At least for the cases you and your team is responsible, you can do better.
Set up an application dedicated to your business problem. There are technical solutions that allow you to do so in a fast and agile way. You can put that solution on a central server so everyone has access. You can back up that server or service to prevent data loss. And your solution will have a much better user experience.
And don’t tell me your company is not a software company because you produce goods or sell services. Thinking this way is sort of a déformation professionnelle (french term for “looking at things from the point of view of one’s profession”). If you deploy some code (in whatever environment), at least part of your company indeed is a software company. Don’t take me for that, maybe you put more confidence in General Electric’s CEO Jeff Immelt who said in an interview with Charlie Rose “Every company has to be a software company”.
Working with agile processes is a best practice approach by now for the software development industry. It allows for small but fast steps towards a greater goal of a project or product vision. You could also apply agile thinking to research projects. Classical research is not that different from an agile process, nay? You take some small step, test a hypothesis, evaluate the result and continue with a next step.
Agility in science
But there is a fundamental difference in the concept of these processes: research allows to dismiss one or even several of the previous steps. In software development you normally don’t throw away the artifacts you built to move where you are now. For research to be agile it needs to be allowed to discard previous steps, or as Alfred North Whitehead said in “Adventures of ideas”:
A science that hesitates to forget its founders is lost.
It’s part of changing paradigms in the classical sense of Thomas S. Kuhn’s ideas in “The structure of scientific revolutions”.
There and back again
Having broadened the view on agility for research, let’s look back at software development. In agile sprints your teams makes decisions that will influence the path of the whole product. So you eventually make fast paced decisions whose effects will stay for a long time. Most software development teams are prepared to make quick technological decisions based on the problem at hand. They are normally not prepared to make estimates on the long term feasability of said decisions.
So you may accumulate technological debt even if you try to avoid. Take some pressure out of the technological decision making process by allowing for revision of architectural decisions. And last but not least establish a culture allowing to make errors. Because being under pressure to avoid errors and increase velocity makes developers susceptible for making errors. But this is a topic for another post.
The last days I listened to some episodes of a german management podcast. They discussed some common management problems or mistakes and how to avoid them. This got me thinking about my own experiences and this post is a combination of ideas from the podcast and my own thoughts. And it certainly is by no means complete or authoritative.
One of the most demotivating habits is not only to set a goal but also explicitly to define how to reach it. If you are at every stage of a project informed about every detail and progress of every task, if you always work on the important tasks yourself, if you think you know more than your coworkers and can do better, if you are able to jump in with any task at hand you probably are micromanaging your team. This is demotivating since you express a lack of trust. Try to delegate tasks. Have confidence in your coworkers because without they don’t have either. Sometimes the line between giving enough information to work on a task and giving too much information so the task can be done without thinking about is a fine one. Especially founders often never learned to delegate by specifying a task at hand as detailed as needed but not more. When the results don’t match their expectations they feel confirmed in their distrust.
Additionally don’t request status information each and every day. This holds true for management, but does certainly not apply to agile processes. So what is the difference between a manager requesting to be updated every day and a daily standup, you may ask. Well the standup is the spreading of information you as a reporting team member think is noteworthy for all (!) other team members. Reporting to your manager socio-dynamically is a totally different process. There is an imbalance in power right from the setting. The (im)balance of power in conversations in general is a topic worth its own post.
The undercover expert
This is a special type of micromanager. All by themselves they think that they can accomplish the technical problems better than anybody else because there is nothing they love as much as fiddling with details and technology. The result is that they work in their company not on their company. And since they are the A-Team, made of Chuck Norris and MacGyver in one person, their idea of management is to control everything. But they will think of this as support for their coworkers. Such a manager also will never give up control, even if they try. This is because stepping out of the way because they trusts someone else to do the job is not part of their worldview.
To pay too much is bad, but to pay poor is even worse. So don’t pay less than average. In fact if you like to get excellent work pay more than average. Money is not everything but money can be a form of appreciation. Or rather paying poor wages is a sign of lack of appreciation. If you now say that you cannot afford to pay competitive wages then you perhaps should not hire additional employees. This sounds sharp but if your revenue is so bad that you need to cut on the wages maybe your business model or way to manage is not optimal. The laws of economy say that you can not expect to buy an excess of any good by paying poor. If you pay poor for any deliverable you have to add for the risk to do so. If you take that into account you have a bit more margin to pay.
And while we’re at it: don’t work with a bonus system. Bonuses have shown to be counterproductive to create engagement with a company or job position. Most people will do anything to comply to the results defined in their agreement on objectives. This includes taking shortcuts that in the short term work to reach a goal but might harm your company if it is not the intended way to reach the goal.
Be authentic. Don’t try. Be it. If you commit to deliver something do so. If you give deadlines or goals, be specific. „Somewhere around March“ is not a date. “Monday, the 25 March at 10am“ is a date. If you define dates or deadlines, take a note and write a mail so everyone knows and can keep track. If you give positive feedback, do so in public, if you have to express criticism, do it in a one-on-one. Meetings with two or more managers and one employee are not feedback but a jury. Avoid this setting in any case. You remember my remark on imbalance of power from above?
While we are at one-on-ones: it’s typical german management style to have exactly one annual personnel talk. This meeting is thought to contain feedback, objectives, personal growth (if this is a topic at all) and salary. That’s a lot of stuff that should not be combined and once a year is too infrequent. There are two main reasons why managers avoid one-on-ones.
First they might think they have not enough time for every coworker to meet once a week or biweekly. This signals „you are not important to me“. And let’s just do some math. The typical management span in a tech company is somewhere up to 10 team members. 10 conversations of half an hour make 5 hours. Every two weeks which has 80 hours if your full time week has 40 hours. That’s not very much for one of your core tasks.
Or they are afraid of the talk. Being afraid to talk to colleagues may have one of two reasons. One is you might be afraid of what you will hear. The other is that you just don’t like to communicate so much at all. If one of those applies to you you might want to think about your job choice. There is a swabian proverb: „Not beaten is praised enough“. Don’t live by that. It never has been true.
Photo by Freepik
Today I paged through a book by Martin Gaedt, called “Rock your idea”. Despite the english title the book is written in German. One of the first and central ideas presented there was:
Innovation means to break the rules.
I’ve been scientific and innovation enabler for several projects and companies now and this is nearly all you need to know about injecting new ideas or technology into companies.
If you want to work out a totally different and optimal solution for a given problem or even want to create a new area of business, you have to break the rules.
- The rules defining what is possible. Maybe someone just invented the technology needed to build your idea. You might at the moment not know that.
- The rules what we think customers need or want. Ever heard that argument “None of our customers asked for that! Why should we build that?”?.
- The rules of the existing business. Ever heard that your idea doesn’t fit into the portfolio of the company? WHAT THE HECK? The portfolio is where the money is, for God’s sake!
- And sometimes even the rules of hierarchy. Having an innovator working ‘at a short leash’ often means preventing innovation. Sometimes managerial control is the worst you can do to harm your company.
So to reformulate the negative arguments to positive actionable items:
- When having a new idea, don’t instantly think about existing technology to build it. When you need it, there will be a solution. There always was one when I needed it. Finding technical solutions is the job of people like me.
- When you don’t know if a customers will buy into your idea, TALK TO THEM. Sometimes you will get a piloting customer aboard for an idea that is nothing more than that: an idea. Sometimes you will have to invest a small amount of money and time into a prototype or mockup to win a customers interest.
- If you only look for ideas fitting into an existing portfolio, I’m sorry to tell you, that your company will not have any chances to survive a future disruptive change in its very own field of business. There will be someone else having a similar idea and with no reluctance to realize it, portfolio or not.
- If you have people working for you on innovative ideas, trust them. At least a bit further than you feel comfortable with. Micromanaging people is a great way to let them look for another company that offers a broader field of work. If you expect your researchers to follow working instructions to the point you’re exactly missing the point.
Some software systems are designed for massive amounts of data to be processed in a very short time. Banking systems, fraud detection, billing systems. Lets pick one, I worked on for a long time: billing systems (for telecom or internet providers for example).
Most of those systems are very large, mostly complex systems, designed to bill millions of customers per month. Some examples are Kenan Arbor (bought by Lucent) or Amdocs. Since these systems need to process vast amounts of data very fast, they are built using compiled sources / binaries. Binary software is not easily customizable. So most of these systems are widely customizable via configuration files. Taking in account all options possible in dynamic configurations results in even more compiled code. I think you got it.
What actually is a billing system?
To give an impression which steps are required in a typical billing scenario, here is a short non-exhaustive list:
Collect billable items from external systems, translate or reformat the data and put it in a database.
Additional for mobile telecom billing: import GSM TAP3 (Transferred Account Procedure version 3) roaming data.
- First step: Rating
Put a “price tag” on every billable item for the billing period in question
- Second step: Billing
Collect rated items as invoice items per customer.
- Third step: Invoicing
Create invoices, on paper or digitally.
- Fourth step: Payment
Withdraw money via saved payment option per customer.
Alternatively: substract invoice total from prepaid deposit.
All of these steps could be “special” for any customers. Think of a subscribed service. Every customer pays $5 per month. But once the company had an introductory offer of 20% off for the first year. So not only are some customers paying only $4 but they are paying $5 after 12 months. Now take into account, that a typical mobile telecom company has something like 20-30 different contract types or rates. Wow, lots of options. Not a problem for a multi-million dollar company but for smaller companies with, let’s say, 100 to 100.000 customers.
Now what if a billing system would be implemented in a scripting language? Admittedly it would be a bit slower (would it? I don’t really know) that a solution in C or C++. But it would be very fast and flexible customizable, if well documented (we developers love to write documentation, don’t we?). Also management summary dashboards would be much more flexible as prebuilt solutions like QlikView (which also would cost additional license fees).
I could visualize for example a solution in Python. This way it would be fast compared to some other scripting languages and could leverage the massive amount of financial and mathematical software components. Build an administration and dashboard component with Flask or Django and run Python scripts on a PostgreSQL database. If more speed is needed you could switch to an Apache Spark architecture, which would also be scriptable in Python via PySpark.
Start on a small budget but don’t let decisions limit your options!
The term human capital was coined by american economist Theodore Schultz in his seminal paper “Investment in Human Capital” from 1961 . He starts by discussing that often the consideration of human beings as a form of capital is seen as unethical. To count human beings as capital is justified by a rationale drawing on comparisons and discussions from the beginning of the 20th century, comparing e.g. this approach to sacrificing a hundred human beings in order to save a gun in war. Well, our views on war have changed since 1906. This might explain why today we tend to abhor counting humans as capital.
But there is a second approach originating in the theories of french sociologist Pierre Bourdieu readily summarized in 1986 . He derives his concept of cultural capital from observations of french upper class children gaining substantial advantages in their life compared to working class children resulting from their education. He states that their parents invest economic capital (money) in the education of their children. They accumulate a certain amount of cultural capital which can later on be converted back to economic capital when the owners of the cultural capital get more profitable jobs because of their better education. This cultural capital is saved in what he calls the embodied form which means that the knowledge and education belongs naturally to the person acquiring it. It can not be sold like a physical item. When investing e.g. in a collection of paintings this capital can be seen as transformed into another form of economic capital since the paintings have a certain economic value. But the consumption and appreciation of art and its display at social events also counts as a form of cultural capital, this time in objectified state. When acquiring an academic title the title itself represents the embodied cultural capital of the title holder in a certain institutionalized state.
In contrast the term human resources is nowadays widely used to describe all that concerns staffing or personnel management. It was first used by american economist John Commons in 1893  and was commonplace (please excuse the pun) in economic literature from the 1910s on. It represents the view of employees as assets to the firm. This interpretation is opposed by the preamble of the United Nations International Labour Organization including the principle “Labour is not a commodity“.
When forced to choose one of the two terms I would opt for “human capital” since its philosophical and sociological implications put the human being at least a bit more in the focus of interest.
 Schultz, T. W.. (1961). Investment in Human Capital. The American Economic Review, 51(1), 1–17
 The Forms of Capital: English version published 1986 in J.G. Richardson’s Handbook for Theory and Research for the Sociology of Education, pp. 241–258.
 John R. Commons, The Distribution of Wealth, New York, 1893
(Picture by Ian Muttoo CC BY-ND 2.0, https://www.flickr.com/photos/imuttoo/2631466945/)
In my last post I mused about employer policies concerning training and learning of employees. I would like to use this as an introduction to a series of postings related to knowledge management and innovation in firms. Much has been written and discussed about the creation and finding of knowledge. From a practical point of view and in philosophy, which discusses these topics as epistemology. In this first installment I would like to give an overview of what’s ahead and how I would like to structure my texts.
My first approach was to put all of this in two or three postings. Since this is way too much text to be read comfortably I will divide the topics in a more or less natural way like this:
- The idea of human capital in contrast to human resources
- Philosophy and theory of knowledge, from information via knowledge to innovation
- Flow of knowledge in the firm and exchange with external resources
- Knowledge management from a social network point of view
- Challenges for human resources departments concerning knowledge management
- Impediments for knowledge creation and usage (e.g. Not-Invented-Here-Syndrome, NIH)
- The state of open innovation
- Simulation of knowledge flow and NIH using cellular automata
What do you think? Interested? Is something missing? Should I reorder the topics? Let me know!
(Picture by Tommy Ellis CC BY-ND 2.0, https://www.flickr.com/photos/tommyellis/6326877778/)
I remember a conversation with my father-in-law. We were discussing the transition of my freelancing work into an employment. We spoke about the salary and benefits in the contract. He asked, if I had included a surcharge for being on a permanent task. I asked him to explain. And here is the bottom line.
We (in this industry) are knowledge workers. This is a much overly used phrase. It boils down to that our value as an employee or freelancer depends on our knowledge, be it explicit or tacit. If we are hired for a certain position, we need to keep at it. There are several possibilities how we can do that. Going to conferences, taking a training, meet colleagues etc. This needs time. And sometimes money. All this expenditure has to be accounted for. By you or by your employer. He may support you with money or free time or he may not (which is common in Germany). If not the salary has to compensate for your personal investment. So why has he to do that?
Because his order to work on a certain task or field for a (supposedly) very long time distracts you from acquiring additional knowledge. If you would still be freelancing, hopping from gig to gig you would to some extent learn new things. And you would invest some of your time and / or money in getting new things to know. Since you are your own boss.
If you work on a defined focussed task for a longer time, you will be left behind on your fields of expertise. This once was the reason you were hired. After some years, your worth as a coworker will degrade. And this is the reason good employers care for your knowledge.
Heute würde ich mich gerne kurz mit dem Verhältnis von Arbeitgebern und Arbeitnehmern in Festanstellung beschäftigen. In diesem Bereich greift immer mehr der Usus um sich, all-incl Arbeitsverträge zu machen. Das bedeutet, darin stehen so Formulierungen wie
“Mit dem Grundgehalt gelten alle Überstunden bis zur gesetzlichen Höchstgrenze als abgegolten.”
Wenn man seinen Unmut darüber äußert, daß man Arbeitszeit leisten soll, die dann nicht gesondert vergütet wird, heißt es oft: “Oh, das geht nicht. Da haben wir ja keine Kontrolle über die Kosten!”
Um es einmal klar zu sagen:
Keine Überstunden zu vergüten bedeutet, das unternehmerische Risiko auf den Mitarbeiter abzuwälzen.
Ein Unternehmen nimmt einen Auftrag an und hat dafür eine Vergütung vereinbart, die aufgrund der Angaben des Auftraggebers abgeschätzt ist. Wenn da etwas nicht stimmt, ist das kein Risiko, daß ein Arbeitnehmer tragen sollte. Das ist unredlich.
Man kann das auch von der anderen Seite sehen: mein erster Projektvermittler als Freelancer meinte mal auf meine Einlassung: “Ach, das halbe Stündchen hab ich nicht aufgeschrieben!”:
Ihre Arbeitszeit ist das einzige Gut, daß Sie zu verkaufen haben. Verschenken Sie das nicht. Ihnen wird auch kein Geld geschenkt.
Natürlich sollte man das lieben oder wenigstens gern machen, was man beruflich tut. Und was man gern tut, da schaut man nicht auf die Minute. Aber so lange ich kein Geld für nichts geschenkt bekomme, kann ich keine Arbeitszeit für nichts verschenken. Manus manum lavat nannten das die Römer …
From time to time I come across a sort of dispute or even sometimes war at companies of every size: the central IT department tries to impose a certain hardware or software policy on the coworkers they are entitled to take care of.
Every time this happens there are discussions of BYOD vs. company owned devices. The IT departments claim that they can’t guarantee a certain service level, when they don’t have access to the resources used by the coworkers. The supporters of BYOD argument that using their own chosen hard- and software augments productivity and satisfaction.
I have to confess that I’m a strong campaigner for using my own devices and software at work. But to get some insight into this topic we need to separate different requirements determined by the type of job the employees do:
- Office workers need to get things done. With standard tools. They often are happe to have someone to call if things don’t work like expected or needed.
- Software engineers use their (mostly) laptops to build software. They need some control over the environment they work in. Libraries, databases, IDEs, operating systems. They choose the tools hat get the job done. When things don’t work they are able to fix problems by themselves.
These two roughly separated requirement profiles are opposed by two sorts of enterprise environment:
- Proprietary systems and protocols chosen by the IT departments because they know these systems very well and know how to get support from the provider. Things in this category may contain: Microsoft products (Windows, Exchange, …) or enterprise groupware systems like Novell Groupwise, Lotus Notes etc.
- Open protocols and services offer similar options but with a different type of maintenance.
Both approaches require nearly the same amount of maintenance but of different types. Proprietary systems often offer poor support to clients offside of the mainstream. For example have you ever tried to connect an Apple laptop to a Novell file share? Don’t try. You’ll get mad about getting the right client tools, software incompatibilities and stuff like that.
So there is a natural match for BOYD environments: use standardized protocols and services like NFS, SMB (which both have their origin in proprietary systems …) or mail protocols like SMTP and IMAP.
If your users would like to work without tinkering with software or services: use a centralized management system. This doesn’t naturally contain closed source and proprietary tools. But often it does.
For a company with technologically apt users it’s better to adopt the BOYD way to maximize productivity and user satisfaction. The latter often is no valid point with IT service departments. Then it’s the job of the people whose job it is to provide a suitable working environment for happy colleagues to make the service departments to work they way they are supposed to work.
This seems to be a particular problem in Germany where I often enjoy contact to IT service departments featuring a very self-centric philosophy. The notion of being a service department to help others do their job is not very popular.
Several studies show that companies are seen as more attractive to new employees when they allow BYOD policies.
On the other hand there are security considerations to be taken into account. But I don’t know of any company owned system that prevents willful or even lazy security breaches.