Thinkers and Doers

Question

Thinkers and Doers

Steve Jones - SSC Editor

SSC Guru

Points: 736212
More actions
January 1, 2019 at 9:15 pm

#378922

Comments posted to this topic are about the item Thinkers and Doers

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply

xsevensinzx One Orange Chip Points: 25560 More actions · Answer 1

I personally love ETL and agree with Andy, it can be a full-time role that someone who has the right mentality, should work solely as the ETL developer for organizations. In my organization, which is where I support a full team of data scientist, it certainly is a full-time role to help them with ETL process that can be automated.

When I worked in the video game industry for many years, my opinion on thinkers versus doers has become skewed to match how they view them. This is where thinkers, people who do nothing but want to be the idea person for a game, was a dime-a-dozen. The industry really had no room for people who just wanted to do nothing but spit out ideas. Everyone had ideas, but very few people could actually act on those ideas and make them into reality.

The reason it's different for data is because you don't have a lot of people wanting to develop data in comparison to people who want to develop the hot new video game. You also don't have a lot of data people who want to just be the thinker, most of them want to be the doers. Where in the video game industry, you could totally sway most of the doers to just sit and talk about video games all day without actually making a video game for the business.

But seeing that, I think it's important to get the doers to be the thinkers too. That means, hiring people who work with the data to be excited about thinking up ideas for the data too. Not just hiring a person who is working in data for the money or to do just one specific thing with one specific tech.

Aaron N. Cutshall SSCrazy Eights Points: 9011 More actions · Answer 2

Steve,

I'd like to comment on the portion of your editorial that went like this: "These days I think architecture is important, at least at a coordinating level. I don't know that it needs to be a full time job, but we need a person not too distracted by daily work examining how we build our systems. Perhaps this is the type of position that someone with a lot of experience that wants to work part time ought to hold."

As an architect, I feel that the position is not as irrelevant as your comment seems to indicate. I have worked in many environments over my 30+ years and have seen the result of multiple systems that were developed without an overall enterprise architect's involvement. Each project went in different directions instead of leveraging common platforms and functionality. This is not an issue only with small environments, but large ones as well. Group A may be running off with on-premises SQL Server, while another is using AWS, and yet another doing something completely different. It's even worse when their goals overlap and they are duplicating efforts but with different architectures.

Having an architect involved in the projects helps to keep things in a common framework. Due to knowledge of Group A's efforts, the architect can help Group B's project to benefit from lessons already learned or to utilize common components/platforms/data. The architect also helps to enforce standards (however they are determined) and to maintain consistency across various initiatives/projects. Time, money, and effort can all be saved and allow projects to be done in a smooth and efficient manner. With so many projects running in an Agile method with short time frames, communication with other groups often is limited which leads to information existing in silos and duplicated efforts.

No matter the size of the company, involving an architect in the data, platform, and overall design is very beneficial. As an architect, I've also been involved in development and QA efforts as well causing such a position to be more than full-time! In most cases, the enterprise architect is the only one with an overall view of the entire enterprise spanning all projects and systems. That's a key resource that cannot be overlooked.

LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com

xsevensinzx One Orange Chip Points: 25560 More actions · Answer 3

Aaron N. Cutshall - Wednesday, January 2, 2019 8:02 AM
As an architect, I feel that the position is not as irrelevant as your comment seems to indicate. I have worked in many environments over my 30+ years and have seen the result of multiple systems that were developed without an overall enterprise architect's involvement. Each project went in different directions instead of leveraging common platforms and functionality. This is not an issue only with small environments, but large ones as well. Group A may be running off with on-premises SQL Server, while another is using AWS, and yet another doing something completely different. It's even worse when their goals overlap and they are duplicating efforts but with different architectures.

Sounds like you are lucky enough to work in environments where those groups all would follow one person's direction. In my experience, you often have too many politics for that to happen correctly unless they all role up to the same person enforcing it. As data is growing beyond the traditional IT team, it's becoming harder to make that happen the way you describe.

Doctor Who 2 SSCrazy Eights Points: 8194 More actions · Answer 4

Interesting article, Steve. Aaron, I like your insights as an architect as well. I work in a large IT department now, so every role is very specialized. I resent not having better insight into how all the pieces fit together, since in my previous job I had to wear multiple hats, including architect. Perhaps that spoiled me. We have an architect division with 6 people in it. I've talked to 2 of them and each has a degree in project management, something I don't have. What I don't understand is why walls have to exist between the various groups. IT is very separate from dev, and both of those are very separate from the architects. Perhaps its just the way things are in larger organizations - they want everyone "to stay in their place".

Rod

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 5

xsevensinzx - Wednesday, January 2, 2019 8:37 AM
Aaron N. Cutshall - Wednesday, January 2, 2019 8:02 AM
As an architect, I feel that the position is not as irrelevant as your comment seems to indicate. I have worked in many environments over my 30+ years and have seen the result of multiple systems that were developed without an overall enterprise architect's involvement. Each project went in different directions instead of leveraging common platforms and functionality. This is not an issue only with small environments, but large ones as well. Group A may be running off with on-premises SQL Server, while another is using AWS, and yet another doing something completely different. It's even worse when their goals overlap and they are duplicating efforts but with different architectures.
Sounds like you are lucky enough to work in environments where those groups all would follow one person's direction. In my experience, you often have too many politics for that to happen correctly unless they all role up to the same person enforcing it. As data is growing beyond the traditional IT team, it's becoming harder to make that happen the way you describe.

Very True - but that ends up being a critical reason FOR architecture, not against it. The more distributed things get to be, the more you need to have that "higher view" to help steer the various implementations in a common direction.

Keep in mind that in this setting architecture tends to be advisory, and helps the various teams and constituents first "find" each other, (as simple as "hey - that looks a LOT like that team X did a few years back"), and work on pooling resources so as to not reinvent the same wheel each time. It's also not very reminiscent of the doers vs thinkers as described: we're very much embedded with others as part of a common framework, not thundering down judgement from on high. It also doesn't mean that it has to be a full time occupation, but it IS critical for someone on any given team to have the responsibility to take the "long view" and understand what the series of short-term decisions we keep making during our busy days will do to the technologies that we support.

Taking that extra step back to look out and think whether you could automate something, or dramatically improve the usability of a feature , or avoid trouble in the coming future by steering a slightly different direction, makes you a thinker. As many folks on here have said in other ways, you could save yourself a LOT of doing if you were to just think a bit more.

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

Aaron N. Cutshall SSCrazy Eights Points: 9011 More actions · Answer 6

Matt Miller (4) - Wednesday, January 2, 2019 10:44 AM
Very True - but that ends up being a critical reason FOR architecture, not against it. The more distributed things get to be, the more you need to have that "higher view" to help steer the various implementations in a common direction.
Keep in mind that in this setting architecture tends to be advisory, and helps the various teams and constituents first "find" each other, (as simple as "hey - that looks a LOT like that team X did a few years back"), and work on pooling resources so as to not reinvent the same wheel each time. It's also not very reminiscent of the doers vs thinkers as described: we're very much embedded with others as part of a common framework, not thundering down judgement from on high. It also doesn't mean that it has to be a full time occupation, but it IS critical for someone on any given team to have the responsibility to take the "long view" and understand what the series of short-term decisions we keep making during our busy days will do to the technologies that we support.
Taking that extra step back to look out and think whether you could automate something, or dramatically improve the usability of a feature , or avoid trouble in the coming future by steering a slightly different direction, makes you a thinker. As many folks on here have said in other ways, you could save yourself a LOT of doing if you were to just think a bit more.

Matt,

I totally agree with everything you said. In most projects I found myself in more of a "consulting" role especially to help clarify how everything fits together. I also believe in looking far ahead to prevent issues down the road. There are so many pressures to worry about "today" and to deal with "tomorrow" later. However, some effort into planning and coordination goes a long way to prevent problems especially when multiple groups must arrive at the same point:

LinkedIn: https://www.linkedin.com/in/sqlrv
Website: https://www.sqlrv.com

Doctor Who 2 SSCrazy Eights Points: 8194 More actions · Answer 7

Aaron N. Cutshall - Wednesday, January 2, 2019 4:16 PM
Matt Miller (4) - Wednesday, January 2, 2019 10:44 AM
Very True - but that ends up being a critical reason FOR architecture, not against it. The more distributed things get to be, the more you need to have that "higher view" to help steer the various implementations in a common direction.
Keep in mind that in this setting architecture tends to be advisory, and helps the various teams and constituents first "find" each other, (as simple as "hey - that looks a LOT like that team X did a few years back"), and work on pooling resources so as to not reinvent the same wheel each time. It's also not very reminiscent of the doers vs thinkers as described: we're very much embedded with others as part of a common framework, not thundering down judgement from on high. It also doesn't mean that it has to be a full time occupation, but it IS critical for someone on any given team to have the responsibility to take the "long view" and understand what the series of short-term decisions we keep making during our busy days will do to the technologies that we support.
Taking that extra step back to look out and think whether you could automate something, or dramatically improve the usability of a feature , or avoid trouble in the coming future by steering a slightly different direction, makes you a thinker. As many folks on here have said in other ways, you could save yourself a LOT of doing if you were to just think a bit more.
Matt,
I totally agree with everything you said. In most projects I found myself in more of a "consulting" role especially to help clarify how everything fits together. I also believe in looking far ahead to prevent issues down the road. There are so many pressures to worry about "today" and to deal with "tomorrow" later. However, some effort into planning and coordination goes a long way to prevent problems especially when multiple groups must arrive at the same point:

How true, Aaron. I have witnessed a lot of kicking the can down the road.

Rod

xsevensinzx One Orange Chip Points: 25560 More actions · Answer 8

Aaron N. Cutshall - Wednesday, January 2, 2019 4:16 PM
Matt Miller (4) - Wednesday, January 2, 2019 10:44 AM
Very True - but that ends up being a critical reason FOR architecture, not against it. The more distributed things get to be, the more you need to have that "higher view" to help steer the various implementations in a common direction.
Keep in mind that in this setting architecture tends to be advisory, and helps the various teams and constituents first "find" each other, (as simple as "hey - that looks a LOT like that team X did a few years back"), and work on pooling resources so as to not reinvent the same wheel each time. It's also not very reminiscent of the doers vs thinkers as described: we're very much embedded with others as part of a common framework, not thundering down judgement from on high. It also doesn't mean that it has to be a full time occupation, but it IS critical for someone on any given team to have the responsibility to take the "long view" and understand what the series of short-term decisions we keep making during our busy days will do to the technologies that we support.
Taking that extra step back to look out and think whether you could automate something, or dramatically improve the usability of a feature , or avoid trouble in the coming future by steering a slightly different direction, makes you a thinker. As many folks on here have said in other ways, you could save yourself a LOT of doing if you were to just think a bit more.
Matt,
I totally agree with everything you said. In most projects I found myself in more of a "consulting" role especially to help clarify how everything fits together. I also believe in looking far ahead to prevent issues down the road. There are so many pressures to worry about "today" and to deal with "tomorrow" later. However, some effort into planning and coordination goes a long way to prevent problems especially when multiple groups must arrive at the same point:

I mean, I don't disagree what's been said here. I work as a data architect myself, but I am not THE data architect across the entire business. I think you guys are referencing this from a consulting position where you are called in by the business as a sort of a last or final resort to fixing an underlying problem many of us face with having so much disparity across projects, teams, or whatever.

But, I fear that this is the dream and not the reality. In most organizations I've seen, it's becoming harder and harder to do this as technology is making easier to split as well when growth happens with the business, you can't possibly find a single entity that understands every business problem these projects or teams aim to address or solve.

When you work primarily as a consultant, I am sure this is a different experience. But, when you are not and you have that growth of 20 different countries, with 20 different teams across 20 different brands, good luck with that one.

Matt Miller (4) SSC Guru Points: 124210 More actions · Answer 9

xsevensinzx - Thursday, January 3, 2019 7:33 AM
Aaron N. Cutshall - Wednesday, January 2, 2019 4:16 PM
Matt Miller (4) - Wednesday, January 2, 2019 10:44 AM
Very True - but that ends up being a critical reason FOR architecture, not against it. The more distributed things get to be, the more you need to have that "higher view" to help steer the various implementations in a common direction.
Keep in mind that in this setting architecture tends to be advisory, and helps the various teams and constituents first "find" each other, (as simple as "hey - that looks a LOT like that team X did a few years back"), and work on pooling resources so as to not reinvent the same wheel each time. It's also not very reminiscent of the doers vs thinkers as described: we're very much embedded with others as part of a common framework, not thundering down judgement from on high. It also doesn't mean that it has to be a full time occupation, but it IS critical for someone on any given team to have the responsibility to take the "long view" and understand what the series of short-term decisions we keep making during our busy days will do to the technologies that we support.
Taking that extra step back to look out and think whether you could automate something, or dramatically improve the usability of a feature , or avoid trouble in the coming future by steering a slightly different direction, makes you a thinker. As many folks on here have said in other ways, you could save yourself a LOT of doing if you were to just think a bit more.
Matt,
I totally agree with everything you said. In most projects I found myself in more of a "consulting" role especially to help clarify how everything fits together. I also believe in looking far ahead to prevent issues down the road. There are so many pressures to worry about "today" and to deal with "tomorrow" later. However, some effort into planning and coordination goes a long way to prevent problems especially when multiple groups must arrive at the same point:
I mean, I don't disagree what's been said here. I work as a data architect myself, but I am not THE data architect across the entire business. I think you guys are referencing this from a consulting position where you are called in by the business as a sort of a last or final resort to fixing an underlying problem many of us face with having so much disparity across projects, teams, or whatever.
But, I fear that this is the dream and not the reality. In most organizations I've seen, it's becoming harder and harder to do this as technology is making easier to split as well when growth happens with the business, you can't possibly find a single entity that understands every business problem these projects or teams aim to address or solve.
When you work primarily as a consultant, I am sure this is a different experience. But, when you are not and you have that growth of 20 different countries, with 20 different teams across 20 different brands, good luck with that one.

As luck would have it - I am both 😛 . My title is EA for an IT services company that supports affiliated insurance companies (I mostly deal with the US companies, but we have affiliates all over).. The consultation part is that aspect of my role where I act as an internal consultant of sorts with the other groups (hailing from IT and business) to come up with the best solution that supports the business needs longer term. And as you well put it, I am not THE EA, I am one participant in the extended architecture team across the business units (some dedicated architects, some not).

The role isn't to be the super brain that knows everything about every system, just to take a look at the bigger picture, and work with the dev support teams and the customers to suss out the way forward. As a result my purpose is to maintain a broader experience, but not to have the deepest knowledge in each skillset. We work with the security teams on the standards (what level of security is required) and patterns (HOW should it be implemented to actually meet said standards), and we help the dev teams implement those things right.; we work with system and business owners on which needs will bring the biggest gains to the organization, and what improvements will actually make a difference. It'\s a support role for other more direct contributors but still - it's very practical and tangible.

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?